-
Notifications
You must be signed in to change notification settings - Fork 1k
Localise JS strings #6673
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I believe this is out of scope for the OTF work -- we scoped for localizing views and templates, localizing JS will require is to construct a separate (probably client-side) localization system and ensure that the two don't fight. IMPO, the right approach here is to audit the JS for English strings and remove them entirely (either by moving functionality to the backend or by returning error codes/hitting a renderer somehow to signal which string to display). That would avoid the need for two separate localization systems, and probably wouldn't involve any substantial changes (from what I've seen, there are relatively few English strings in the JS). |
The only strings in JS files I was able to identify as of hash 17f76cf live in these locations:
Most are trivial, and could potentially be localized from existing resources, leveraging https://www.i18next.com/ or similar. |
https://github.com/guillaumepotier/gettext.js might also be a good option here. |
Most of these have been addressed by merging #15612 (except for the password strength phrases which are tricky to translate due to being mixed with |
Now that we have l10n support, we need to review our JS files and mark any strings for translation.
The text was updated successfully, but these errors were encountered: