Add extra check to handle formal and informal locales.

[IreneStr]

Changelog:

• Fixes a bug where a 'You're using WordPress in a language we don't support yet.' notice would be shown for formal and informal locales when the locale actually was supported.

Technical choices:

The wp_locale in the translation_sets object do not contain the _formal or _informal part. For example: the wp_locale of Dutch (Formal) is nl_NL. The information that it's formal is only in the slug property. Because this->locale does have the _formal or _informal part, the comparison with the wp_locale had an incorrect result for informal and formal languages. This commit adds an extra check in which the slug is appended to the locale if the slug is not 'default' (i.e. is 'informal' or 'formal'). This string is compared to this->locale to make sure the correct $set is returned.

Test instructions:

On wordpress-seo trunk:

• Go to settings >General and change the language to Deutsch (Sie).
• Go to SEO > General. Even though German Formal is 99% translated, you'll see a 'You're using WordPress in a language we don't support yet.' notice on the dashboard.

Copy the code changes from this PR to wordpress-seo's vendor > yoast > i18n-module > src > i18n-module.php.

• [> 90% translated formal language] (Keep the language set to Deutsch (Sie)) Go to SEO > General. See no translation-related notice.
• [> 90% translated non-formal language] Set the language to English (US). See no translation-related notice.
• [partly translated formal language] Set the language to Dutch (Formal). You'll see "Zoals u kunt zien is er een vertaling van deze plugin in Dutch (Formal). Deze vertaling is momenteel voor 57% klaar... ".
• [partly translated informal language] Set the language to Deutsch (Schweiz, Du). You'll see "Wie du sehen kannst, existiert eine Übersetzung dieses Plugins in German (Switzerland) Informal. Diese Übersetzung ist aktuell zu 61% fertiggestellt. "
• [partly translated non-formal language] "You're using WordPress in Esperanto. While Yoast SEO has been translated to Esperanto for 8%, it's not been shipped with the plugin yet."

[afercia]

Testing a bit this, there are 2 important steps to follow to test properly, otherwise you'll get unexpected results:

• delete the transients each time before refreshing the SEO > General page or after you've changed the code: otherwise you'll end up with a stored transient e.g. _transient_yoast_i18n_wordpress-seo_de_DE_formal that will give you the stored translation set
• when you install a new language for testing, remember to go to Dashboard > Updates and run the translations updates: for me, the DE_formal mo/po files were missing so some checks (translation_exists and translation_exists) were failing, making the notice still displayed

That said, I think the new check added in this PR should be within the foreach loop? Currently, it's outside of the loop so it always checks the last translation set returned by the api response, which is Zulu 🙂

[IreneStr]

To delete the transient:

• vagrant ssh in the WordPress vagrant.
• cd /srv/www/wordpress-develop/public_html/
• wp transient delete-all

[abotteram]

CR 👍

Also I acceptance tested. But will let someone else take a look at it as well.

[afercia]

Code wise, 👍 However, because of... WordPress 🙂I'm not sure the actual behavior is what we'd want.

Today I've learned that when switching language, WordPress downloads its own .mo/.po files but it doesn't downloads the .mo/.po files for plugins (and themes).

Our I18n-module checks for is_textdomain_loaded() which sets $this->translation_loaded and prints out the notification messages based on that. is_textdomain_loaded() returns true when the related .mo file exists.

Thus, after switching language $this->translation_loaded is false and the printed messages are misleading. Note that $this->translation_loaded is true only after users go in the Updates page and click "Update Translations" (this actually downloads the plugins/themes .mo/.po files).

To reproduce:

• on WordPress trunk, delete the whole build/wp-content/languages directory
• activate Yoast SEO and, to double check, also another plugin e.g. WooCommerce
• go to Settings > General Settings
• change language to Deutsch (Sie) and save
• observe the build/wp-content/languages directory and see only the WordPress de_DE_formal .mo/.po files have been downloaded
• go to SEO > General
• see the wrong notification message:

• go to the Updates page and update the translations (click "Übersetzungen aktualisieren")
• observe the build/wp-content/languages directory and see two new sub-directories have been created: plugins and themes
• the plugins directory finally contains the wordpress-seo de_DE_formal files
• go to SEO > General
• see there's no notification message: this is the expected behavior:

This happens with all languages: the wrong notification message is displayed until users update the translations and the .mo/.po files get actually downloaded.

Dutch formal without .mo/.po files:

Esperanto without .mo/.po files:

Not sure why WordPress doesn't immediately downloads the plugins/themes translations, will ask upstream. From our side, in this scenario the messages that depends on $this->translation_loaded will be misleading. Maybe we should suggest users to update the translations first?

[afercia]

Thanks to @swissspidy for shedding some light on the WordPress behavior. Looks like it always worked this way: changing language in Settings -> General doesn't handle plugin/theme language packs. This part should be addressed upstream.

From our side we should probably change the notification messages because especially the it's not been shipped with the plugin yet is misleading when there are no mo/po files yet.

I'd lean towards merging this PR because it's an improvement anyways and create a new issue.