-
Notifications
You must be signed in to change notification settings - Fork 5k
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
Work on loading UI translations #2969
Conversation
The remaining failure on Appveyor appears to be an unrelated problem with installing nbconvert from conda-forge. |
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 |
Yeah, I think we should probably rename |
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 |
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. |
Ok let's do it 👍 |
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? |
There's an issue for someone to integrate the steps to build the translations: #3102 |
To test: set
zh-CN
to 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
.