Localization Behavior Change

[gsexton]

I've noticed a change in localization behavior and was wondering if someone could point me to some documentation.

I have a plugin, and in the plugin/captions directory are various .mo/.po files. There's an en_US file.

A user in Australia has reported they are not getting captions. They're getting the Slug (mnemonic) value of the caption. I replicated the issue by setting the site language on my test environment to en_AU. I then created en_AU.mo/.po files, and the captions appeared.

I'm a little surprised. I tried creating .mo/.po files without a language specifier, and those weren't picked up. I'm familiar with Java's method for ResourceBundles where it looks for bundle_lang_COUNTRY.properties, bundle_lang.properties, and finally bundle.properties? How is fallback handled in the case where there isn't a specific language_COUNTRY match?

I did review this page:

​https://make.wordpress.org/core/2024/02/27/i18n-improvements-6-5-performant-translations/

but it doesn't really seem on-point.

Thanks for your help!

George

[swissspidy]

Could you perhaps share the code to your plugin so we can better assess what the issue might be?

There's an en_US file.

Why do you have an en_US file?

The default strings in your plugin are supposed to be in en_US, so there's technically no need to have an en_US file (although you can have one to override strings if you need that for some reason).

How is fallback handled in the case where there isn't a specific language_COUNTRY match?

There is no fallback currently (see #28197). If there is no language file for the current locale, nothing gets loaded.

[gsexton]

@swissspidy Thanks for replying.

I admit, I'm not understanding the localization and this is work I did quite a while ago. The source for my plugin is at:

​https://plugins.trac.wordpress.org/browser/connect-daily-web-calendar/#trunk/captions

The customer reports upgrading to 6.5.5 triggered the breakage. I looked through the changelogs and see some stuff around 6.5.3 that look related.

In regards to https://core.trac.wordpress.org/ticket/28197. People got wrapped up in the auto using languages for other locales, and ignored the big obvious wins they could have gotten by looking at the language. Java's is pretty simple and wouldn't be hard to implement and wouldn't have any performance problems.

In Java, I have:

captions.properties
captions_en.properties
captions_en_US.properties
captions_en_AU.properties

If someone from the UK visits the site, it looks for captions_en_UK.properties. When it doesn't find that, it tries captions_en.properties. If it doesn't find that, it returns captions.properties. It's actually a little nicer, because it will actually create a merged set of:

captions_en_AU.properties+captions_en.properties+captions.properties where the left side is more significant. So, I can change the word "colour" in captions_en_AU.properties and they get that along with captions_en.properties.

Anyhow, I'll try to take a look through the WP source to see how it's not working.

[swissspidy]

Sounds good. I'm closing this one for now since there doesn't appear to be an issue with WordPress core and language fallbacks is something that is being developed separately in core right now.

---

One recommendation regarding your translation setup:

Your original strings in your source code are placeholders such as "COM_CONNECTDAILY_Every". However, WordPress expects those originals to be the actual en_US string.

Right now this makes it quite impossible for polyglots to translate your plugin at translate.wordpress.org

Since your plugin is hosted on WordPress.org and can be translated there, there is no need to actually have those files in your plugin folder. I recommend you to migrate those to the translation platform instead.