Closed brendangadd closed 3 years ago
The Jupyter notebook UI is addressed easily by changing the ENV variable in the Dockerfile but not the entire UI is covered as remote desktop is built off of ml-workspace Funnily enough there is absolutely nothing (not a single issue) on i18n in the ml-workspace.
Investigated file directories which need modification: jupyter_tooling :For this I can use https://github.com/wikimedia/jquery.i18n
.workspace/tools : These values are used in open-tools-widget.js. I think the approach here is to add say "nameFr" and "descriptionFr" to the XY-prog.json and then have a condition that picks between the two (unless I can do something like tool["name"+locale]
where locale is either En or Fr seems like i can.
Putting aside the i18n of the ml-workspace specific widgets for now. I'm looking into the feasibility of "re"-setting the environment variables for language of the container when the 'landing_page' is hit.
This would be similar to the work done in #47 except instead of changing the the argv.json
file, we set the various language env variables (likely need some privileged shell scripts) and then restart jupyter using restart-jupyter.sh. I'm hoping that the jupyter process being respawned would then read the changed env variable and set it according to that
Ultimately this is to avoid users getting stuck with the language that they start up the notebook with (because in this proj we have more flexibility than say Wendy's rstudio problem in that there's a landing page and UI the user can interact with before hitting the desired tool).
So action items for this are:
Branch off of 47 (so i dont need to use the same code), add the french locale to be installed to ubuntu , create a shell script with sudo permissions to change the locale variables, make changes to the languagecheck.js
file to call that shell script, and then call the restart-jupyter (here's hoping I don't need sudo permissions there). Of note, I should probably be careful of that in the sense that if a user gets something running, and then refreshes on the landing page the restart will be called (should be changed to only update iff browser language changed)
1/12 2:30: I don't think this is approach (changing env variable freely) feasible / does not make much sense. May just stick with Wendy's implementation of setting the locale at the notebook server area. I will probably poke Blair about this to confirm my suspicions.
~Found an aspect of Jupyter that does not work / get translated with the locale change. It is some of the jupyter native widgets. This was on my local windows machine with a fresh install of notebook
followed by a LANG=ja_JP jupyter notebook
which is similar to how the notebook is started up in remote desktop here (file is called by the supervisord)~
It goes without saying that I noticed this first in the container, having the French locale installed + LANG env variables set to French and these widgets stayed 'untranslated'.
Looking into use of placing export LANGUAGE=fr_FR
right before the exec $cmd
from start.sh called by notebook called by supervisor
7/12/2020: Those widgets WILL get translated, the user must have their browser language set as fr_FR
Building off of work done in #47 found a good way to get most of the jupyter ui to i18n without setting the environment variable in the dockerfile.
Essentially I use what's in the argv.json
file used by vscode to determine which language to use. See start-notebook.sh where start-notebook.sh
is the file used by jupyter.conf
when starting up the service.
Upon hitting the landing page, a request is sent to languagecheck.js where if the language of the browser does NOT match the language in argv.json
(defaulting to English) the json is updated, and then jupyter is restarted.
When jupyter reaches start-notebook.sh
it will find and start up jupyter with LANGUAGE=fr_FR
or LANGUAGE=en_EN
This became it's own branch because I did not want to change too many things / keep track of what I was doing in my other branch, as well as wanting the changes I made from adding French to vscode. I'll delete any branches after its been merged
@ca-scribner RE: What Brendan was talking about in the standup. I suppose we have a few 'extra' widgets that do not come packaged with the regular jupyter install and are just extras courtesy of the ml-workspace down below
Also cool github has a dark mode now 👀
Support both official languages