Skip to content

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

Closed
nlhkabu opened this issue Sep 20, 2019 · 5 comments
Closed

Localise JS strings #6673

nlhkabu opened this issue Sep 20, 2019 · 5 comments
Assignees
Labels
i18n Internationalization javascript requires change to JavaScript files

Comments

@nlhkabu
Copy link
Contributor

nlhkabu commented Sep 20, 2019

Now that we have l10n support, we need to review our JS files and mark any strings for translation.

@woodruffw
Copy link
Member

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).

@woodruffw woodruffw removed this from the OTF localisation work milestone Sep 23, 2019
@brainwane brainwane added the i18n Internationalization label Sep 30, 2019
@miketheman miketheman added the javascript requires change to JavaScript files label Jul 8, 2023
@miketheman
Copy link
Member

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.

@di
Copy link
Member

di commented Jul 10, 2023

https://github.com/guillaumepotier/gettext.js might also be a good option here.

@cofiem
Copy link
Contributor

cofiem commented Jan 17, 2025

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 zxcvbn output).

@miketheman
Copy link
Member

Thanks for pushing through all that, @cofiem !

I think we're fine with not worrying too much about the messages from zxcvbn - if we want to go that route, we might need to look at migrating to the more recent zxcvbn-ts that has multi-language support.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
i18n Internationalization javascript requires change to JavaScript files
Projects
None yet
Development

No branches or pull requests

6 participants