Fallback to loaded translations when .json files with translated strings do not exist

[dimadin]

In #45103, JavaScript translation support was added so it loads .json files for them. But there are few problems with this.

You need to download those files from WordPress.org API, and there are conditions to match in order to both generate them there and be able to download from it.

Another thing is that it breaks workflow that existed since start of i18n in WordPress. Since PO/MO files were used, you could work with PO and immediately see results. This is useful when, for example, you translate. It is not simple to replicate this. There is npm package to convert to JSON, there is WP-CLI command released two days ago, but both tools are complicated for setup and use by average translator, and even then add unnecessary step.

Finally, if for whatever reason .json files are not there or there is a problem with their loading, there would be no translations.

Attached patch is based on work for Gutenberg plugin. Idea is that if normal loading fails for whatever reason, it uses standard translations for that domain.

It still doesn't have any filtering here, but I think that it should have one since other, standard method for loading translations does have one.

[ocean90]

Thanks for the ticket and the patch. Not doing it like Gutenberg was done on purpose, see [43910]. The proposed fallback simply doesn't scale when loading thousands of unused translations.

Filters will be added in #45425 and the current path issues are handled in #45528 and #45488. Also, tools are being build to make generating the JSON files easier, see ​https://github.com/wp-cli/i18n-command/pull/109 for example.

PS: There are also plans to not include the JavaScript translations in the PO/MO files anymore so a fallback to PHP won't help here.

[dimadin]

Thanks, I didn't notice #45425.

Also, tools are being build to make generating the JSON files easier, see ​https://github.com/wp-cli/i18n-command/pull/109 for example.

It is better than now, but it's not always easier. It assumes that every translator has and needs WP-CLI which is not the case. Another thing is that introduces second step for building which is slower than what there is now (now it's CTRL/Cmd + S and that's all).

There are also plans to not include the JavaScript translations in the PO/MO files anymore so a fallback to PHP won't help here.

They might be excluded in PO/MO files in the language packs generated by WordPress.org, however they are still there if you don't get them that way. It's not true that it won't help, you might use desktop software for translating, not do it through GlotPress. (It did help me since I translate that way.)

If latest patch from #45425 is committed, I'll create a plugin based on my patch here and pre_load_script_translation filter.