JSON translation file

  • Resolved sousou9028

    (@sousou9028)


    3 years, 5 months ago

    Hello,

    we have a rather complex problem with loco for the translation of a part of the give wp plugin. There is a simple solution? knowing that I am a novice. cordially.

    context : https://feedback.givewp.com/bug-reports/p/the-donor-dashboard-should-be-translatable

    What's bizarre at this point is that the JS strings are showing up in the POT file. In fact, if you use the i18n.gettext JS filter then the translations work just fine. It seems like one of two things are happening:
The JSON translation file (generated by Loco, in your case) isn't being loaded on the Donor Dashboard when the page loads.
The JSON file is being loaded but isn't being applied by i18n to the scripts.
This is supposed to be handled by wp_set_script_translation, which we are setting. I'm not sure where the disconnect is happening.
If any of your able able to learn anything, please report it here. I will prioritize getting fixes into GiveWP core as we learn more about this.
Thank you!

    The page I need help with: [log in to see the link]

Viewing 2 replies - 1 through 2 (of 2 total)
  • Plugin Author Tim W

    (@timwhitlock)

    There is no simple solution if you are a novice. WordPress’s new-ish JSON translation system is ill conceived and fragile. I will try to explain why in the simplest terms I can, but depending on where your problem lies this may be best handed back to to the GiveWP developers.

    The file names for .json files are derived from the .js scripts which use them. This means that the software generating the .json files must produce the exact same result that WordPress does when the .js script is added to your page.

    In the case of Loco Translate (and probably other PO editors) the .js file reference is read from the .po file. It then imitates as closely as possible what WordPress would do if this script was queued for loading into your page.

    Why wouldn’t it work then?

    Because (1) the file reference could have been extracted from a different file than the one you load into your page, or (2) there could be a difference in the way the paths are expressed (see example below), or (3) some filter could be modifying your script paths, or (4) any one of infinite possible reasons two values could be computed differently. Ultimately the file editor (json compiler) doesn’t execute the code of your website to see what it’s going to do and cannot reliably predict the result.

    Here’s an example thread from last week: Strings from Javascript not translated. The root cause here was that the author was queueing their .js file using a relative path that differed from the one in the .po file.

    But they both point to the same file!! Yes. “foo/bar.js” and “foo/baz/../bar.js” point to the same file but they are not the same and will produce different .json file names. Hence the JSON loader is a terrible system.

    WordPress makes one allowance for differing .js file references. You are allowed “foo.min.js” which will be normalized to “foo.js”, but that’s it. If you want to do more than this you can use a filter.

    So what can you do about your problem?

    Debugging your site is the only way to find out what’s going on. If you are not able to do this then you are stuck.

    I suggest using the load_script_textdomain_relative_path to log every script that is queued and the relative path that is derived. Then find your script in the log and check if it matches the reference in the .po file.

    If you identify a mismatch in the relative paths, then you can use the same filter to fix the problem. Loco Translate observes this filter too, so normalizing the relative path here should take effect for both the .json compilation and also the runtime script loading.

    If you find in your investigation that Loco Translate is generating the wrong .json file name and you think this is fixable, then please report it as a bug in a separate thread.

    Further notes on Loco Translate’s JSON support here: https://localise.biz/wordpress/plugin/manual/json

    Plugin Author Tim W

    (@timwhitlock)

    Additionally – although I don’t think it applies in your case – PO files hosted on Glotpress (and installed by WordPress) are known to purge strings that are used only in .js files. This is a known issue with Loco Translate that I am working on now.

    The same occurs if strings are extracted using “wp i18n make-json” without the –no-purge option.

    If in your case the .js references are in the .pot file AND your .po files are synced to this .pot file, then this is likely a non-issue.

Viewing 2 replies - 1 through 2 (of 2 total)
  • The topic ‘JSON translation file’ is closed to new replies.