Conversation
User Test ResultsTest specification and instructions User tests are not required |
cdn/dev/js/i18n/i18n.mjs
Outdated
| import translationEN from './en.json' with { type: 'json' }; | ||
| import translationES from './es.json' with { type: 'json' }; | ||
| import translationFR from './fr.json' with { type: 'json' }; |
There was a problem hiding this comment.
This is not scalable to many translations. We need to use dynamic imports, and see also my comment on en.json - the translations need to be scoped.
There was a problem hiding this comment.
refactored by #668 to scope translations with domains
cdn/dev/js/i18n/en.json
Outdated
| @@ -0,0 +1,54 @@ | |||
| { | |||
There was a problem hiding this comment.
This won't scale, because it's just one json file, so strings are going to get all muddled together. We are going to need to split per .js file I think?
There was a problem hiding this comment.
We are going to need to split per .js file I think?
So the strings relating to search.mjs would go in a folder like this?
/cdn/dev/js/i18n/search/en.json, es.json, etc?
There was a problem hiding this comment.
Are we wanting to dynamically load strings in a pattern similar to PHP (Locale.php)
where strings = [domain][language][key].... ?
There was a problem hiding this comment.
So the strings relating to
search.mjswould go in a folder like this?
/cdn/dev/js/i18n/search/en.json, es.json, etc?
Yes
Are we wanting to dynamically load strings in a pattern similar to PHP (Locale.php)
where strings = [domain][language][key].... ?
Something like that yes, with dynamic imports
There was a problem hiding this comment.
k, the bulk of that refactor to follow the PHP pattern is
8088ca2
cdn/dev/js/i18n/i18n.mjs
Outdated
| static objNavigate(obj, path){ | ||
| var aPath = path.split('.'); | ||
| try { | ||
| return aPath.reduce((a, v) => a[v].text, obj); |
There was a problem hiding this comment.
This isn't going to work with a.b.c is it?
There was a problem hiding this comment.
good catch. Updated to fix the nesting so this now works
objNavigate({a: {b: {c: {text:123}}}}, "a.b.c") // returns 123
cdn/dev/js/i18n/i18n.mjs
Outdated
| if (!I18n.translations[language].hasOwnProperty(key)) { | ||
| // key is missing for current language | ||
| console.warn(`key '${key}' missing in '${language}' translations`); | ||
| return ''; |
There was a problem hiding this comment.
Fallback to en string would be better because we know we have those.
Co-authored-by: Marc Durdin <marc@durdin.net>
pagination strings now handled by search.mjs
* Remove crowdinContext Also fix some missing `await t()` syntax
Moves the responsibility for determining locale fallback server-side, so that we can avoid async pollution and have just a single responsible module for locale fallback. Strings are injected into a <script> data element as JSON, reducing the number of network round trips. Test-bot: skip
…weaks chore: rework i18n for js to avoid async and duplication
Keep JS strings in the same folder as related php strings
3 participants
For #384
Most of the PHP keyboard search pages can be localized.
This follows on by allowing the JS keyboard search to also be localized.
Off-the-shelf, i18n-next looked really good, but I opted for something that didn't need a framework:
https://medium.com/@mihura.ian/translations-in-vanilla-javascript-c942c2095170
Some of the changes
The JSON files make it easy to
For example:
I had to rename
search.js-->search.mjsand and addi18n.mjsas modules in order to import the JSON files.Sample screenshots
Test-bot: skip