Translated data in JSON files are not showing or getting lost

Assuming your plugin is wpcal …

.po file downloaded from glotpress is purged will not contain JS translations.
We always include the latest .pot file in our plugin.

Yes, I can see this. Loco should sync with your .pot file and this seems to be working. Saving my PO generates the same .json files as per the Glotpress download. Namely wpcal-fr_FR-9174183977e3b9c67f2c34835b3a755f.json and wpcal-fr_FR-edf0c96da6429aaca93bc791b8486a1b.json

Even before and after syncing. French translation for JS string is not getting loaded from .json files.

So we’re clear, are you saying your JS translations don’t work from the Glotpress download without modification? Do they work when Loco Translate is disabled?

So after saving, newly generated JSON files losing all the translations which downloaded from WordPress.

I need some clarity here too. Are you editing the installed (Glotpress) PO file to generate your JSONs, or are you saving a custom PO file and compiling from that?

Yeah, WPCal.

The timeline goes like this.
* Translations are downloaded via Glotpress. Say 95% translated.

* Before modifing translation with Loco

• I think PO file from Goltpress is purged will not have the JS only translation strings.
• Same goes with MO file.
• JSON translations are working.
• JSON translations are not showing up in Loco. This looks like an issue.

* After syncing the POT file or Editing any translation(After Loco generating PO, MO and JSON files

• Only common translation strings for PHP and JS are generated in JSON translations.
• Other JS only translation strings are missing in JSON files.
• Translation is broken.

JSON translations are not showing up in Loco. This looks like an issue.

I think this explains what’s happening.

Loco Translate does not read existing JSON files. This is not a bug, but I can see how it could be useful when syncing to check JSON files for missing strings. I’ll look into that.

So in your reports of losing translations, what you mean is that syncing the PO only adds new source strings, not the translations. Correct?

So for example, syncing to your POT adds the source string “yes” but does not pull the translation “oui”. Hence it is also not compiled into JSONs.

If this is the crux of the issue, then we are on the same page. However, it is not necessary to translate strings that are already present in the Glotpress download, and you should not overwrite them either.

The correct approach is to add your own custom PO file and make any changes you want that differ from Glotpress. Any that can stay the same, can be left blank. Loco Translate will merge your translations on each page load.

Regarding my comment about not reading JSON files:

I’ve been treating these like MO files. i.e. they are required at runtime, but should be expendable (rebuilt from PO at any time). The fact that Glotpress purges .js references from PO files is odd. I can understand stripping them from MO files, but PO files are not actually required by WordPress so their only purpose is for translators to edit them using other software. Hence they should contain everything that requires translation. Who is going to open and edit all the possible tiny JSON files?

I’ve noted here that the wp i18n make-json command requires --no-purge as this is not enabled by default. I don’t know anything about how Glotpress operates, but possibly this is something that l10n managers are in control of?

So for example, syncing to your POT adds the source string “yes” but does not pull the translation “oui”. Hence it is also not compiled into JSONs.

Yeah.

I want to recommend your plugin for my users. But I couldn’t find a straight forward solution or steps. Even if I copy language say fr_FR and sync it with the new POT file. There is no single place to see what are all pending strings to be translated.

I saw an option to sync from PO file while copying.
I think Sync button should have the options to Sync from PO or POT file.

Even then JSON strings are not showing in LOCO, can confuse the users.

Do you see any other workaround, that gives full clarity to a translator?

Thanks for your feedback. However, I doubt I can give you satisfactory workarounds for all the things you regard as missing or incorrect.

There is no single place to see what are all pending strings to be translated.

Every PO is self-contained with its own pending strings. There is no merged view. I agree something along these lines would be useful.

I think Sync button should have the options to Sync from PO or POT file.

I acknowledge the need for altering Sync behaviour for files not created in Loco Translate. This setting is maintained as custom headers in the PO file. There is no way to edit them currently.

Do you see any other workaround, that gives full clarity to a translator?

I don’t know exactly what you are trying to work around here, but the simplest method for customising strings (and seeing what is already translated) is as follows:

Copy the installed PO file, selecting Custom location and “copy target translations” but do NOT select “Use this file as template when running Sync” (this ensures your POT will be used). Then run Sync to get the .js strings.

That last step should be made redundant once I’ve fixed the issue mentioned earlier.

Copy the installed PO file, selecting Custom location and “copy target translations” but do NOT select “Use this file as template when running Sync” (this ensures your POT will be used). Then run Sync to get the .js strings.

Yeah, that’s the closest solution I can give to my users.
Thank you, I appreciate your efforts to make translations easy for WP community.

You might also want to check with the community translation project whether they are able to avoid purging .js strings from their POs. As per my earlier comment, I think a PO should represent all translatable sources and their metadata regardless of what they get compiled into. A JSON is not a source file.

I’m leaving this ticket open as a feature request to pull missing translations from JSON when performing sync/merge.

The latest dev version has a fix for this.

The sync process now checks JSON files for existing translations of any “new” strings. This accounts for translations that were purged from the PO file, but which are represented in the template.

I am still against presenting any information about JSON files to the translator. As with MO files, they are not source files. Multiple files can also share the same strings. The PO should be the canonical source for editing.

I’m also disinclined to automatically merge JSON data with the PO data when the editor is displayed. I think it’s a reasonable thing to do during sync, like in your use case, but that’s as far as I’m willing to go for now.

I have now realised the fix won’t help your situation, because you’re copying a PO, but not tracking it after that.

The more I look at this problem, the more issues it throws up. I’m going to rethink how I handle purged .js strings and can’t promise it will make it into the next release.

Thanks for the updates @timwhitlock.

Yeah, it looks complicated as there is no single source of the original translation.
I hope you can find a better fix.

I have since learned that GlotPress always purges JS-only strings from packaged zip files. This is not controllable by l10n managers and indeed not configurable by nature of the code that exports the language pack.

As WordPress does not require PO file at all, I must also assume that one day they could stop being shipped altogether. In that case I will have the same issue with MO files as I have here with JSON files.

So the answer may be to download the full (unpurged) POs directly from GlotPress and I’ll have to build that into Loco Translate. I’ll look into it for the next release as I think it’s going to become increasingly important. It won’t be in 2.5.1, maybe 2.5.2.

So the answer may be to download the full (unpurged) POs directly from GlotPress and I’ll have to build that into Loco Translate.

I think that’s the best solution where we will get a single source of the original translation.

Quick update to say that 2.5.1 went live yesterday without any changes that will help with the problem here.

In the new version 2.5.2-dev (currently in trunk) I’ve added an experimental CLI command which exports the full PO file from GlotPress and overwrites the one installed by WordPress updates from their exported package. You might find it useful/interesting because I notice that your POT doesn’t quite align with what GlotPress extracts from your JS.

You can run it for your plugin like this if you have WP CLI available:

wp loco fetch wpcal --locale=fr_FR

Hi Tim,

Any updates on this?