Tim W

If you can demonstrate that your issue applies with Loco Translate disabled, then please do open a ticket with them. One mention of my plugin, and they’ll send you straight back here.

As WooCommerce and WordPress are both owned by the same multi-million dollar company, perhaps they can work it out between them.

If you establish that the issue applies in the specific context of using my plugin, then feel free to post back.

I don’t have any problem displaying the plugin name or description using woocommerce-currency-switcher-ja.po generated from my plugin.

Whatever you’re doing that differs from the normal workflow, I don’t know what it is. I remember noticing on one your previous post that you were trying to use ja and ja_JP interchangeably. Did you fully resolve that error?

Perhaps the issue really is WooCommerce, but please frame your questions in terms of using Loco Translate, because support for my own plugin is all I can offer here.

What did you generate your Japanese file from?

Looks like this text is a JavaScript translation, and Loco Translate doesn’t currently extract script translations from WordPress core. In fact, until this moment I didn’t know the Core translations had any.

The approach I recommend is to install the “official” GlotPress translations which does have this string. Then if you want to customize the installed translations, use Loco Translate’s copy function. Make sure you select “Merge strings from related JSON files”.

Hello.

For whatever reason, I missed all notifications from the @ mentions in that ticket. As you can see from an earlier thread, I tried to have my voice heard on the topic. I made my case and hoped they would test it at some point. I’m not sure why they asked me if it was still an issue, because nothing seems to have changed since I reported it. However, I did add a workaround in my plugin that forcefully removes early-loaded translations.

I don’t see any change in WP 6.7.2 that “fixes” the problem with load_plugin_textdomain. It can be seen clearly from the code (line 1019) that calling this function does not clear any early-loaded translations, only NOOP translations. i.e. Taking the view that the only real translations that could exist at this point are GlotPress ones. (I explained this is not the case). This is a deliberate optimisation. I don’t expect them to remove it, and I don’t have the energy to open a ticket for WP 6.8 to make my case all over again.

Having said all this – the best fix is that plugin developers stop using translations too early. Adding workarounds in WordPress core won’t encourage them to do so.

In my case I’m looking just to fix woocommerce

The real cause of the problem in your case is probably not WooCommerce itself. It’s more likely some other plugin requesting translations from the woocommerce text domain too early.

There is nothing about the WordPress core that should stop a site being fully translated as desired if only plugins would do as recommended. You could hold our for a “native fix”, but I’d recommend you establish the culprit and ask them nicely to fix their code.

I’m now seeing the /v2/usage endpoint failing, but /v2/translate is still working. This means key validation will appear to fail, but translations may still succeed.

The issue is the absence of the access-control-allow-origin: * header in API responses. It’s still present for the translation responses, so I’m monitoring whether this changes.

Ok. I’m going to mark as resolved as I see no connection to a fault with my plugin. Feel free to reopen if you have evidence to the contrary.

Can you confirm that you have es_ES set on your site and NOT es? If so, this has nothing to do with my plugin.

As the plugin is not translated into Spanish you should tell the author they need to use the correct code in order for anyone to use their translations.

Interesting you say they blamed my plugin for this. How did they establish Loco Translate was the cause?

The Spanish language code in WordPress is es_ES, not es. So if you have WordPress core and WooCommerce translations installed for the correct language then these author translations won’t load, regardless of whether my plugin is installed. What have you set your language to?

Does the author’s translation work with Loco Translate disabled?

What are you asking exactly?

Have you read the pinned post about why prematurely loaded domains are unloaded:
https://www.ads-software.com/support/topic/readme-version-2-7-release/

And the related FAQ post:
https://www.ads-software.com/support/topic/faq-why-are-my-logs-full-of-debugging-lines/

If you don’t want the domain unloaded see the related filter: https://localise.biz/wordpress/plugin/hooks/loco_unload_early_textdomain

If you just don’t want to see debug messages, disable debug mode:
https://localise.biz/wordpress/plugin/hooks/loco_debug

How can I get the core translation back?

Read the WordPress docs: https://developer.www.ads-software.com/advanced-administration/before-install/in-your-language/

This is outside of my plugin support, but I’ll tell you a trick –

Use Loco Translate to add a core language file in German, in the system location. Enter anything into it and save. Then go to WordPress updates and scroll to the bottom. As long as you successfully created a file at wp-content/languages/de_DE.mo then the update screen should say “New translations are available” and you can update them from there.

There are too many possible causes for me to make guesses.

You will have to debug your file loading process. Read how it works.

My plugin doesn’t control language settings, or switching between them.

It’s not conventional to translate just one plugin. There is no mechanism in WordPress [that I know of] that’s designed to achieve that. At any moment there is one language setting, which is either the site language or the currently logged in user’s language. None of this has anything to do with my plugin.

I suggest your colleagues who want English set their profile to English, and your German speakers set their profile to German. Trying to juggle languages for a single plugin sounds like a path to confusion and disappointment.

If you deleted ALL your German translation files (including WordPress core), this is why you no longer see them in Loco Translate -> Languages. You must have the core translations installed for the language to show up as being “installed”.

It’s not possible. Syncing string definitions from your code replaces all strings with what’s in the code.

A workaround is to maintain a PHP file containing all your “manual” strings. The file doesn’t ever need to be run. It just has to exist in order to define the strings.

You can place that file outside the plugin if needed for your workaround, but you’ll have to add its location to the bundle config (advanced tab).