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 11 hours, 11 minutes ago by .
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 hour, 18 minutes ago by .
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.