When new languages get added, their language codes should be added to *notebook/i18n/nbjs.json*
under the `supported_languages` element.
### Tips for Jupyter developers
The biggest "mistake" I found while doing i18n enablement was the habit of constructing UI messages
from English "piece parts". For example, code like:
```javascript
var msg = "Enter a new " + type + "name:"
```
`var msg = "Enter a new " + type + "name:"`
where "type" is either "file", "directory", or "notebook"....
where `type` is either "file", "directory", or "notebook"....
is problematic when doing translations, because the surrounding text may need to vary
depending on the inserted word. In this case, you need to switch it and use complete phrases,
@ -104,9 +104,9 @@ create the plural form doesn't translate well. Some languages have as many as 5
plural forms for differing numbers, so using an API such as ngettext() is necessary in order
to handle these cases properly.
### Known issues
### Known issues and future evolutions
1. Right now there are two different places where the desired language is set. At startup time, the Jupyter console's messages pay attention to the setting of the ${LANG} environment variable
1. Right now there are two different places where the desired language is set. At startup time, the Jupyter console's messages pay attention to the setting of the `${LANG}` environment variable
as set in the shell at startup time. Unfortunately, this is also the time where the Jinja2
environment is set up, which means that the template stuff will always come from this setting.
We really want to be paying attention to the browser's settings for the stuff that happens in the
@ -117,6 +117,13 @@ of languages in the UI ( never a good thing ).
2. We will need to decide if console messages should be translatable, and enable them if desired.
3. The keyboard shorcut editor was implemented after the i18n work was completed, so that portion
does not have translation support at this time.
4. Babel's documentation has instructions on how to integrate messages extraction
into your *setup.py* so that eventually we can just do:
Any questions or comments please let me know @JCEmmons on github (emmo@us.ibm.com)
./setup.py extract_messages
I hope to get this working at some point in the near future.
5. The conversions from `.po` to `.mo` probably can and should be done using `setup.py install`.
Any questions or comments please let me know @JCEmmons on github (emmo@us.ibm.com)