Translation suddenly only 77%

The file’s completion is relative to itself. Other files are not consulted. As your screenshot shows, 2,556 strings in the file are not translated. Are you saying this is not the case?

Copying a file cannot change its completion, but if you synced a 99% complete file, and new strings were added, then this will reduce completion.

But the actual German translation file is 99% completed, see:
https://translate.www.ads-software.com/locale/de/default/wp-plugins/woocommerce/

Where did the new untranslated strings come from ? Can any other woocommerce related plugin have caused this?

My file dont have more strings that the 99% Translated file.

• This reply was modified 1 year ago by tred1975.

This has taken me some time, but I think I know what’s going on.

I think the issue here is that the published translation files (installed by the WordPress updater) have the script translations (held in JSON files) purged from the PO.

The purged strings ARE present in the official woocommerce.pot file, so running Sync in Loco Translate will ADD them to the PO. I’ve tested this, and it finds over 2k new strings, bringing completion down to ~77%.

The source you link to (with its 11k strings) still includes the extra strings, but this is not what gets installed when you do it via WordPress. You get about 8,934 strings in the PO and a whole bunch of JSON files containing the rest.

The solution is to use Loco Translate’s Copy feature, instead of editing the System file. (Never edit or sync the system file). Be sure to enable the Merge strings from related JSON files option. Syncing your copied file will observe the original PO, and copy in the JSON strings. You can let WordPress updates deal with maintaining the original files.

However, I just tested this with German and there’s a problem: The published JSON files are missing the “source” field which tells us what script they belong to. This makes it impossible for Loco Translate to reconstruct them into the PO. You can still use this route to maintain custom translations of the original 8,934 strings, but you won’t be able to merge in the JSON strings until such time as WordPress/GlotPress release files with source references.

An alternative solution is to download the full PO from the source you linked to, instead of installing the published files via WordPress. You’ll probably still find this file needs syncing to the official woocommerce.pot file, but its debatable which is more accurate. Note that GlotPress does not observe developers’ POT files, preferring its own extraction tools. Sometimes this is better, and sometimes worse.

Hi Tim,

first of all big thanks for taking so much time to recreate this issue!

Since i am quite unsure now what to actually do, can you tell exactly what i need to do when i have downloaded the full PO ?

Thanks

You would need to open and save it to prompt Loco Translate to generate all the file’s WordPress needs. Do that from the Loco Translate editor. Then copy it as per the documentation to make any custom changes.

Incidentally, I’m looking now at adding workarounds for this problem. I wasn’t aware that such recent translation work was still missing the source field in JSON files. I’m also going to make the default Sync operation look at JSON files, because this seems an increasingly common area of difficulties.

The published JSON files are missing the “source” field which tells us what script they belong to. This makes it impossible for Loco Translate to reconstruct them into the PO

Quoting myself from above

I’ve pushed a workaround to the dev branch for this problem.

When a Sync operation is instructed to merge JSON files, and finds the “source” field missing, it will now perform a reverse lookup based on all the JavaScript files found under the plugin’s source paths. If one matches the hash, it will be used.

This should help with the Copy workflow as described earlier, but requires the explicit option to include the JSONs. The default Sync (from a developer’s POT file, or from source) still doesn’t merge JSON files. Doing so is problematic, but I’m looking into how it should work.

I’m going to mark this issue as resolved for the time being, as the behaviour is explainable and I’ve shown ways to get around it.