Query Pagination: Make text translatable

[jordesign]

What problem does this address?

Currently the default text within Query Loop pagination is not set to be translatable (it currently uses esc_html(). This means that users with non-english language site still see the text as 'Newer Posts' and 'Older Posts'.

What is your proposed solution?

These strings could be set to use esc_html__() instead

[t-hamano]

From what I've tested, the default text appears to be translated properly, both in the editor and in the front end.

Default (English)

Japanese

I think this is because the default label has a translation function:

gutenberg/packages/block-library/src/query-pagination-next/index.php

Line 25 in 80e9a6b

$default_label = __( 'Next Page' );

gutenberg/packages/block-library/src/query-pagination-previous/index.php

Line 24 in 80e9a6b

$default_label = __( 'Previous Page' );

However, if this label changes, it will be difficult to translate it even if you switch the site language. This is because the user can enter any text and there is no guarantee that it will be present in the translation file. Also, like other blocks, I don't think there is currently a way to localize user-entered attirbutes.

[audunmb]

The sensible default would be to not add text here. Unless the user enters custom text, the default labels should be used.

[t-hamano]

The problem of not being able to translate text entered by the user inside a block is not limited to the Pagination block, but is a problem that affects the entire translation system of the block editor. For example, I would like to close this issue as a duplicate because it is discussed in the following issue:

• Inline Dynamic Content Solutions #21932
• Discussion/i18n: Localising blocks in FSE themes #36061
• Internationalization and localization: translating templates and template parts #27402

[audunmb]

The main problem is that these aren't user-generated strings, they are default inserted text which act as user-generated strings. Removing the default insertions fixes the issue. Maybe it's just an issue with some themes (like Twenty Twenty Three), but as these are default Wordpress themes the issue should be fixed. In that case, move the bug to the themes instead of closing it.

[t-hamano]

@audunmb Thank you for the detailed explanation.

In other words, if a default label is defined in the theme template, it will not be translated as is, right? For example, the TT3 theme has the following definition in the templates/archive.html file.

<!-- wp:query-pagination {"paginationArrow":"arrow","layout":{"type":"flex","justifyContent":"space-between"}} -->
	<!-- wp:query-pagination-previous {"label":"Newer Posts"} /-->
	<!-- wp:query-pagination-next {"label":"Older Posts"} /-->
<!-- /wp:query-pagination -->

Furthermore, unlike patterns, the extension of template files cannot be changed to PHP. In other words, it is not possible to make it translatable as shown below.

<!-- wp:query-pagination {"paginationArrow":"arrow","layout":{"type":"flex","justifyContent":"space-between"}} -->
	<!-- wp:query-pagination-previous {"label":"<?php echo esc_html_e( 'Newer Posts', 'twentytwentythree' ); ?>"} /-->
	<!-- wp:query-pagination-next {"label":"<?php echo esc_html_e( 'Older Posts', 'twentytwentythree' ); ?>"} /-->
<!-- /wp:query-pagination -->

Considering this, I think the fundamental problem is that the PHP templates in the templates directory are not recognized. That's right?

[audunmb]

The very easy solution is to remove the custom labels from the templates for default Wordpress themes.

Users can still add custom text in their language, but if they don't, it defaults to the translated string. Then this won't be an issue, except in a corner case where the user wants custom strings (like "Newer posts" instead of "Next page") and is running a multi-language site.

I guess it's possible to make the label into a block attribute, and as such make it translatable in block editor templates. Though, that is probably better to leave to a plugin for the corner case.

[carolinan]

This should be fixed in Twenty Twenty-Three; if it can be fixed without breaking anything for existing users. It is worth looking closer at.
In Twenty Twenty-Four, many more patterns were used just to solve the translations. That the translation issue has not been solved at a higher level creates extra work and also many additional files.

[t-hamano]

I have submitted a core ticket regarding this issue: https://core.trac.wordpress.org/ticket/60298