drrxbracho

Thanks for the reply, @properlypurple. That did the trick, I was looking in the wrong place.

All the best.

Hi @jordesign

I had no idea the strings were editable, it didn’t occur to me to try! With that, I have a workaround: I duplicate the blocks, a set for each language with exclusive visibility when it is the default language. So, I’ll just have double pagination-next and -previous blocks.

In general, the whole issue of internationalization with block themes is very weak, but the blocks themselves help kludge something that works. I’m sure there are efficiency penalties, etc.

Thanks for the help, I’ll close the issue.

Rafael

PS. I just went to GitHub, the issue you opened, and the response will be that calling esc_html__() is an error when called with non-static strings, a feature of how gettext() works, it seems. What the block needs is an overall I18N strategy for block themes, I think.

• This reply was modified 1 year ago by drrxbracho. Reason: Added the PS

I got a reply on the WordPress core forum explaining that my sleuthing, as I called it, was indeed faulty because the gettext functions may only be called with static strings, so the pseudo code in the template home.html:

<!-- wp:query-pagination-next {"label":"Older Posts"} /-->

should be passing the translated string. In other words, they say that the translation has to be done by the theme.

Anybody has any ideas?

Rafael

One more thing, my site just updated to WordPress 6.4 and the erroneous code (according to my sleuthing which could be faulty) is still there.

Rafael

Thank you for replying, @jordesign

I only have twentytwentythree loaded but other themes may not show the problem because it depends on how the query-pagination blocks are called.

In the template home.html of twentytwentythree, they are called with the strings “Newer Posts” and “Older Posts” which, as I mentioned, are not translated. That said, the default strings are translated, so if another theme didn’t override the default, the bug will not show up.

I don’t have a sandbox where to test changes, but I believe it’s a matter of modifying the blocks query-pagination-next and -previous to call esc_html__() instead of esc_html()

Rafael

UPDATE: I found the strings in the home.html template of the twentytwentythree theme! That is the Home template before the modifications I made, so such mods must be stored somewhere else and perhaps that’s where I can translate the strings?

Rafael

@kgagne I apologize, I thought you were a WordPress developer. I’m surprised they don’t monitor these forums.

I followed the link you provided but it is about problems with an app, not with the behavior of WordPress in a browser, which is what I use.

At any rate, thanks a lot.

• This reply was modified 1 year, 2 months ago by drrxbracho.

@kgagne Is there an agreement on the existence of the problem I mention? If so, will it be fixed soon?

I’m not sure that mobile editing is high on your list, you remain too desktop centric, in my opinion.

Thanks.

Yes, that is correct. On a desktop, the behavior is that when you click in a block, say a paragraph, the toolbar appears above the block. On a mobile device, the toolbar remains at the very top of the entire post. Not only paragraphs, any block.

Of course, I only have Android devices. I use mostly the Samsung Internet browser (that is its name), but I have also tried with Firefox and Chrome just now.

All present the same behavior: you scroll down to a paragraph to be edited and the block toolbar remains at the top of the entire post, so doing anything requires scrolling up. An example would be selecting a word to make it italic or bold, or even to make it a URL link.

Thank you so much for looking into this!

Rafael

Yes, I mentioned that in the question. Which remains, how do I get List View back? Clearly having to exit and reenter is not a user-friendly situation.

Never mind, it seems to be a browser problem. I was using Firefox Developer édition.