WordPress.org

Make WordPress Core

Opened 6 weeks ago

Closed 6 weeks ago

Last modified 6 weeks ago

#45530 closed enhancement (wontfix)

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

Reported by: dimadin Owned by:
Milestone: Priority: normal
Severity: normal Version: 5.0
Component: I18N Keywords: has-patch
Focuses: javascript Cc:

Description

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.

Attachments (1)

45530.diff (1.5 KB) - added by dimadin 6 weeks ago.

Download all attachments as: .zip

Change History (4)

@dimadin
6 weeks ago

This ticket was mentioned in Slack in #core by dimadin. View the logs.


6 weeks ago

#2 @ocean90
6 weeks ago

  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Severity changed from major to normal
  • Status changed from new to closed
  • Type changed from defect (bug) to enhancement

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.

Last edited 6 weeks ago by ocean90 (previous) (diff)

#3 @dimadin
6 weeks ago

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.

Note: See TracTickets for help on using tickets.