msgid content being halved when saving

You seem to be reporting three separate issues.

The messages being “halved” as you say is not an error. This is valid PO syntax. You can disable line wrapping in the plugin settings, (enter zero as the maximum line length). However, I can’t imagine how this could be related to your other two issues.

This messes up the whole translation file, so eventually you end up with many strings not showing translations.

As mentioned, the translation file is not messed up. Note also that WordPress does not read PO files. It reads MO files, which are binary and do not contain wrapped lines anyway.

Translations not showing is a common problem with infinite possible causes. My plugin is only responsible for saving the MO files. Can you verify that the missing strings are present in the files that the editor has saved to disk? If you are unsure, then post them.

Auto translator keeps on claiming that there are untranslated strings despite having translated all of them

This is a possible bug, but will not be due to PO line wrapping. Can you please post a download link for your 100% complete PO file, so I can test this?

Thanks for the swift reply and the insight.
One string that specifically doesn’t work starts with “We noticed “, and which can be found in both the po and mo file. However i can’t find the translated string in the mo file, so i’m not certain if that’s the issue or if i just can’t find it because it’s binary. This is the case for all languages i created custom files for. The string works properly with the Author files though. That’s why i even started comparing the custom files to the author ones and started to notice the multiple line differences.

Here are the 100% completed files:
https://filetransfer.io/data-package/sJoXqsDi#link

• This reply was modified 1 year, 2 months ago by everade.

Re issue 2: The string is present in the MO file, as follows:

"We noticed you're visiting from %1$s. We've updated our prices to %2$s for your shopping convenience. <a>Use %3$s instead.</a>"

Therefore I can’t offer help with this issue.

Re issue 3. This is a bug. The cause is the extra plural form in English that is not used in Japanese. The 17 strings untranslated are the msgid_plural entries. They should have been excluded from the count.

I will fix this and post back when I’ve been successful.

Yes for issue 2, that would be correct. I found it better on different languages which aren’t scrambled, so the translated string is definitely inside the .mo, however it just doesn’t work when the entire file was generated, translated and compiled 100% by Loco.
I just confirmed this by deleting the entire language, then recreate it using Loco, and only translate this particular string with Loco.

I also confirmed its not a caching issue.

When editing and compiling the working system translation using Loco, the string works perfectly fine.

The system translations which were installed automatically work for this particular string. And the .po entries when comparing the po files from the System to my Custom Loco files are identical for this one, so there’s no issue with the string itself.

I assume there’s a bug in the compilation process so that wordpress can’t read it properly. Unfortunately i’ve no idea how the .mo reading process works, but i would assume that if there’s a tiny error in the .mo file, it will stop reading the rest of the file thus failing?!

Here’s the comparison:
https://i.ibb.co/kB67rSs/2023-09-02-12-03-44-Source-of-woocommerce-payments-zh-CN-po-Woo-Commerce-Payments-Plugin-translat.png

Here are some more custom and working system files.
Note: custom folder fail, system folder work on this string:
https://filetransfer.io/data-package/idT4GNqC#link

Again, thank you for your time, appreciate it.
Looking forward to a fix on issue 3. And fingers crossed on issue 2.

• This reply was modified 1 year, 2 months ago by everade.

As I’ve written exhaustively on this forum for the last seven years, there are so many possible reasons a string may not be displayed that I cannot provide support for this kind of problem. There are no exceptions.

There is no problem with the MO compilation. Your file is valid and readable by WordPress (all 1,935 entries). I have verified this against your files with total certainty.

I can only make wild guesses as to why your custom translation fails, but your system one succeeds. A common cause is that your plugin tries to use this particular translation too early (before Loco Translate has been allowed to start). That’s just one example. I am not going to debug your site, or the WooCommerce Payments plugin to find out what’s wrong in your case.

The plural counting bug is fixed in the trunk now.

Thanks for bringing this to my attention. It will make it into version 2.6.7, but I’m not going to rush to release this. The bug existed for a long time, and I don’t regard it as critical.

I’m marking this topic as resolved. If you’re able to demonstrate any reproducible bug in the file loading helper, then please report it in a new thread.

Oh wow, you just told me what’s the problem, and i was able to fix it!

before Loco Translate has been allowed to start

System files work absolutely fine but as soon as you try to read customs it just fails.

That tells me custom files are initiated long after the system files were read, which would mean some plugins aren’t particularly”to fast” but instead Loco custom files are just initiated/read to late.

Since you’re referring to this as a “common problem”:
I think it would be really helpful to all users if you would just add a Notice about this in the “Relocate” tab when selecting “Custom”. That it’s possible that some plugins are faster than Loco and some strings might fail because of it, so in some cases using System or Author may fix it.

You can’t expect end-users to know this, and i think this would reduce support requests.

Please note that I never asked you to debug my website, i haven’t even shared it with you. I understand that you’ve been repeating yourself for the past 7 years and it’s super frustrating. But not every user is a programmer or has insights into the depths of your plugin. I personally did not realize that Loco must initiate anything for the custom folder mo files to be read. I believed Loco compiles them and sets a definition in WordPress so it reads the additional loco folder just like the system folder at the same time.

Either way. I’m happy that i found the root cause for this one.
And i hope that adding that simple notice would help you to get a few less frustrating support requests in the future.

Again, thank you for your time.

I’m glad you fixed your problem. The early loading issue is documented in this FAQ. Yes it’s common, but lots of other causes are common too. I’m not going to add notices all over the interface for potential problems that won’t be relevant to the majority of users. The help tab on every page links to the FAQs.

some plugins aren’t particularly”to fast” but instead Loco custom files are just initiated/read to late.

I disagree:

Firstly, it’s not physically possible for Loco Translate to initialise any earlier. It starts listening on text domain hooks as soon as its bootstrap file is included. No plugin can run sooner than this, unless it’s installed as a Must-Use plugin, which has issues of its own.

Secondly, it’s the responsibility of all plugin developers to avoid calling hookable functions (like loading translations) until all plugins are initialised. This is easily done (for example, on the admin_menu hook), but if developers insist they need translations before any UI is rendered, then that’s on them. They are probably wrong, and it will prevent other plugins from interacting with their functionality.

Well i guess the optimal outcome would be a collaboration with Automattic so you can natively load custom folders and remove some overhead from helper hooks.

This particular plugin I’ve had issues with was even developed by Automattic themselves. I’m not sure if a basic user like me can achieve anything by telling them they’re doing it wrong, but i will try. However it doesn’t affect just this plugin.

I’m really not here to tell you what to do, i’m certain you’re way smarter than me. I’m just looking for a better solution since without custom folders i run into new issues when it comes to updating translations.

And thanks for the FAQ pages, i wasn’t able to find these when navigating your website. Those are helpful indeed.

I’m not really expecting further help or answers from you on this one, just leaving this here. I’m happy with Loco as it is, but i wouldn’t say no to further improvements.

Thanks Tim