Update Language Suggest text

[dd32]

follow up from #6599

Currently the homepage language guess text uses these:

• (singular) WordPress is also available in %s.
• (multiple) WordPress is also available in %s (also %s).

Support Forums use:

• (singular) WordPress support forums are also available in %s.
• (multiple) WordPress support forums are also available in %s (also %s).

Plugins use this:

• (singular) The plugin directory is also available in %s.
• (multiple) The plugin directory is also available in %1$s (also: %2$s).
• (singular) This plugin is also available in %1$s. <a href="%2$s">Help improve the translation!</a>
• (multiple) This plugin is also available in %1$s (also: %2$s). <a href="%3$s">Help improve the translation!</a>

Feedback suggests that the (also ...) part is probably not ideal, and in addition the plugin directory uses also: rather than just also.

These strings should probably be updated to read:

WordPress is also available in {locale}, {locale2}, and {locale3}.

That would be "one" string, so we should update our strings from __() to _n() as well, and respect the locale's wp_sprintf_l() translations for how to join those locale names, rather than just using ,.

This would also help with the display of English variants which have brackets in their name (IMHO these are named incorrectly, but that's a different issue):

WordPress is also available in English (Australia) (also English (UK)).

H/t Javi

[ryelle]

There's another request to look into this ​on github, so I decided to check it out. 6600.diff​ is where I've landed so far, but I'm not sure about it.

The github issue also calls out that some locales have the wrong case — the API returns "galego", but proper case is "Galego". To fix that, I'm using \GP_Locales::by_field( 'wp_locale', $guess['locale'] )->native_name; following how plugin-directory/api/routes/class-locale-banner.php works, and that returns the name correctly.

Joining up the languages is where the trouble is. wp_sprintf_l is almost perfect, though I had to require WPORGPATH . 'wp-includes/formatting.php'; to use it.

Requesting a single, non-English language works:

$ curl "https://wordpress.org/lang-guess/lang-guess-ajax.php?uri=%2F" -H "Accept-Language: ja"

<div id="lang-guess">WordPress は <a href='https://ja.wordpress.org/'>日本語</a> で利用可能です。</div>

Requesting two additional languages with English as the main language works:

$ curl "https://wordpress.org/lang-guess/lang-guess-ajax.php?uri=%2F" -H "Accept-Language: en-US,en;q=0.8,ko-KR;q=0.5,es-ES;q=0.3"

<div id="lang-guess">WordPress is also available in <a href='https://ko.wordpress.org/'>한국어</a> and <a href='https://es.wordpress.org/'>Español</a>.</div>

Requesting more than two languages also works, but when the main language is not English, the joining string is not translated.

$ curl "https://wordpress.org/lang-guess/lang-guess-ajax.php?uri=%2F" -H "Accept-Language: es-ES,es;q=0.8,ko-KR;q=0.5,en-US;q=0.3,gl=0.1"

<div id="lang-guess">WordPress también está disponible en <a href='https://es.wordpress.org/'>Español</a>, <a href='https://ko.wordpress.org/'>한국어</a>, and <a href='https://gl.wordpress.org/'>Galego</a>.</div>

I'm assuming the issue is that the translation system isn't actually loaded, which is why the translate_gp function is necessary.

Should this endpoint be refactored to use the core REST API infrastructure? that seems like overkill, but could also be more future-dev-friendly (since we could use WP functionality as normal). Maybe we could share the code with the plugin directory endpoint? Also, there was a request in the Theme Directory redesign to ​have the same feature there, so building up something a bit more reusable might be worth it.

[dd32]

Should this endpoint be refactored to use the core REST API infrastructure? that seems like overkill, but could also be more future-dev-friendly (since we could use WP functionality as normal).

The only blocker there is that this does some GeoIP stuff which leads to this being a very non-cache-friendly URI and loading WordPress is significantly more expensive processing wise than the existing PHP.

You're correct that the translation system isn't loaded, core has a wp_load_translations_early() function which could be used with Multisites SHORTINIT, but unfortunately you can't switch to a arbritrary locale with that mode, as there's some WordPress components which don't work well with early loaded translations and SHORTINIT.

6600.2.diff​ is 6600.diff​ but with loading the translations for wp_sprintf_l() from the Core GlotPress project.

@ryelle do you think that'd resolve the immediate needs here?

[ryelle]

The only blocker there is that this does some GeoIP stuff which leads to this being a very non-cache-friendly URI and loading WordPress is significantly more expensive processing wise than the existing PHP.

Yeah, I suspected something like that.

do you think that'd resolve the immediate needs here?

Yeah, I've tested it with a few different language headers and it works well — it's a little awkward when a language has translated the and but not the main phrase, but maybe with the update to the new project in #6599 it will get better coverage.

When more than one language is suggested, the string now reads as a list, to avoid implying a hierarchy in the suggestions.

This brings over the changes in dotorg-20224 to the plugin locale banner.

Fixes #6600.

Homepage

Requesting a single language (Japanese):

プラグインディレクトリは<a href="​https://ja.wordpress.org/plugins/">日本語</a>でも利用可能です。

Requesting two languages (Spanish, French):

El directorio de plugins también está disponible en <a href="​https://es.wordpress.org/plugins/">Español</a> y <a href="​https://fr.wordpress.org/plugins/">Français</a>.

Requesting three languages (Spanish, French, Italian):

El directorio de plugins también está disponible en <a href="​https://es.wordpress.org/plugins/">Español</a>, <a href="​https://fr.wordpress.org/plugins/">Français</a> y <a href="​https://it.wordpress.org/plugins/">Italiano</a>.

On a plugin

Requesting a single language (Japanese), plugin has translation:

このプラグインは<a href="​https://ja.wordpress.org/plugins/jetpack/">日本語<a>でもご利用いただけます。<a href="​https://translate.wordpress.org/projects/wp-plugins/jetpack">翻訳の改善にご協力ください</a>。

Requesting a single language (Korean), plugin does not have translation:

플러그인이 아직 한국어(으)로 번역되지 않았습니다. <a href="​https://translate.wordpress.org/projects/wp-plugins/wp-plugin-dependencies">번역을 도와주세요!</a>

Requesting multiple languages (Spanish, Korean, Japanese), plugin has translation for all:

Este plugin también está disponible en <a href="​https://es.wordpress.org/plugins/jetpack/">Español<a>, <a href="​https://ko.wordpress.org/plugins/jetpack/">한국어<a> y <a href="​https://ja.wordpress.org/plugins/jetpack/">日本語<a>. <a href="​https://translate.wordpress.org/projects/wp-plugins/jetpack">¡Ayuda a mejorar la traducción!</a>

Requesting multiple languages (Spanish, Korean, Japanese), plugin only has translation for one:

Este plugin también está disponible en <a href="​https://es.wordpress.org/plugins/wp-plugin-dependencies/">Español</a>. <a href="​https://translate.wordpress.org/projects/wp-plugins/wp-plugin-dependencies">¡Ayuda a mejorar la traducción!</a>

[ryelle]

In 12535:

Plugin Directory: Locale Banner: Improve strings for suggesting multiple languages.

When more than one language is suggested, the string now reads as a list, to avoid implying a hierarchy in the suggestions.

This brings over the changes in [dotorg-20224] to the plugin locale banner.

Fixes #6600.

Committed in [12535].