- Notifications
You must be signed in to change notification settings - Fork5.5k
Work on loading UI translations#2969
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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
Conversation
takluyver commentedOct 24, 2017
The remaining failure on Appveyor appears to be an unrelated problem with installing nbconvert from conda-forge. |
JocelynDelalande commentedOct 25, 2017
Just tested, it does work. Thanks :-) Note : there is no fallback within a same lang (maybe this is normal behavior) : if I set browser lang to |
takluyver commentedOct 25, 2017
Yeah, I think we should probably rename |
gnestor commentedOct 27, 2017
Great work,@takluyver!! I tried testing and I'm seeing the translations that depend on the browser's language (working in both Chrome and Firefox) but I'm not seeing the translations that depend on the environment variables. I'm using |
takluyver commentedOct 31, 2017
I'm not sure what's going on there - maybe there are other environment variables besides LANG that affect it? I'm inclined to get this merged and keep iterating. |
gnestor commentedOct 31, 2017
Ok let's do it 👍 |
hikui commentedAug 11, 2018
Hi@takluyver, the translation doesn't work in the release version. I noticed that I had to manually follow the README and compiled my own version of end files to make the translation work. Perhaps we should keep .mo and nbjs.json files? |
takluyver commentedAug 11, 2018
There's an issue for someone to integrate the steps to build the translations:#3102 |
To test: set
zh-CNto the most preferred language in browser preferences, then launch the notebook with the LANG environment variable set, i.e.LANG=zh_CN jupyter notebook.Writing the translation JSON into the template and storing it as a JS global seems a bit ugly, but it ensures that the data is there before any Javascript strings are used, without either bundling data for all languages into the JS bundle, or trying to do clever things with requirejs.
The biggest thing that I'm not happy about is that the language for the JS is determined by the browser, and the language for the template strings by an environment variable in the server. If you only set one, you see half the strings translated, with no obvious reason for the difference. Using the browser header seems better, and it allows for multiple fallbacks, but there isn't an obvious way to use that with
jinja2.ext.i18n.