Skip to content
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

Merged
merged 8 commits into from
Oct 31, 2017
Merged

Conversation

takluyver
Copy link
Member

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.

screenshot from 2017-10-23 16-01-42

  • Only transfers translations for languages the user wants.
  • (For strings used in JS) can handle multiple fallbacks - e.g. an Afrikaans speaker could request Afrikaans > Dutch > English, and get each translation in the best available language.

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.

@takluyver takluyver added this to the 5.3 milestone Oct 23, 2017
@takluyver
Copy link
Member Author

The remaining failure on Appveyor appears to be an unrelated problem with installing nbconvert from conda-forge.

@JocelynDelalande
Copy link
Contributor

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.

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 zh, it will never load the zh-CN translation.

@takluyver
Copy link
Member Author

Yeah, I think we should probably rename zh_CN to just zh, and introduce an automatic fallback when loading so that if you specify zh_CN, it will use zh as well. But I think those can be in future PRs: I just wanted to get the translations working first.

@gnestor
Copy link
Contributor

gnestor commented Oct 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 LANG=zh_CN jupyter notebook to run the notebook server... 🤔

@takluyver
Copy link
Member Author

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.

@takluyver takluyver closed this Oct 31, 2017
@takluyver takluyver reopened this Oct 31, 2017
@gnestor
Copy link
Contributor

gnestor commented Oct 31, 2017

Ok let's do it 👍

@hikui
Copy link

hikui commented Aug 11, 2018

Hi @takluyver, the translation doesn't work in the release version. I noticed that .mo and nbjs.json files are gitignored and there's no corresponding compiling process in the setup.py?

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
Copy link
Member Author

There's an issue for someone to integrate the steps to build the translations: #3102

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 31, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants