Use jinja2 to load i18n strings from settings

[fcollonval]

This introduces jinja2 has preprocessor on settings file to transform the internationalized strings.

title and description are still read directly from the json file except if they match jinja2 transform structure.

Fixes #1

[welcome]

Thanks for submitting your first pull request! You are awesome! 🤗

If you haven't done so already, check out Jupyter's Code of Conduct. Also, please make sure you followed the pull request template, as this will help us review your contribution more quickly.

You can meet the other Jovyans by joining our Discourse forum. There is also a intro thread there where you can stop by and say Hi! 👋

Welcome to the Jupyter community! 🎉

[goanpeca]

Wohoo @fcollonval thanks for this. So how will this be used :) do you have an example we can put somewhere?

[fcollonval]

The first use would be related to jupyterlab/jupyterlab#10254 to support translation of (sub)menu labels.

I based the test example on it:

{
  "jupyter.lab.menus": {
    "main": [
      {
        "id": "jp-mainmenu-view",
        "items": [
          {
            "type": "submenu",
            "submenu": {
              "id": "jp-mainmenu-view-codemirror-theme",
              "label": "{{ _('Text Editor Syntax Highlighting') }}"
            },
            "rank": 40
          }
        ]
      }
    ]
  }
}

[goanpeca]

Ok some thoughts:

"label": "{{ _('Text Editor Syntax Highlighting') }}"

We should probably have a translator object for consistency (what we use on server and frontend)

"label": "{{ trans._('Text Editor Syntax Highlighting') }}"

Now this can be used for scrapping strings, but how do we used it in the frontend/backend?

[goanpeca]

And I would recommend we also use context so

"label": "{{ trans._p('menu-settings', 'Text Editor Syntax Highlighting') }}"

menu-settings or something similar

Now this can be used for scrapping strings, but how do we used it in the frontend/backend?

[goanpeca]

And I would recommend we also use context so

"label": "{{ trans._p('menu-settings', 'Text Editor Syntax Highlighting') }}"

menu-settings or something similar

Now this can be used for scrapping strings, but how do we used it in the frontend/backend?

[fcollonval]

We should probably have a translator object for consistency (what we use on server and frontend)

The _ or gettext is directly coming from jinja2 i18n extension: https://jinja.palletsprojects.com/en/3.0.x/templates/#i18n

So it will add some complexity to use another name.

how do we used it in the frontend/backend?

I think to do that at the schema file loading step - I still have to figure out how to have the translation loaded and available at that time:

https://github.com/jupyterlab/jupyterlab_server/blob/d1bb60373702d4f4967d664c9fd56565bf4e8d8d/jupyterlab_server/settings_handler.py#L22

[goanpeca]

The _ or gettext is directly coming from jinja2 i18n extension: https://jinja.palletsprojects.com/en/3.0.x/templates/#i18n

So it will add some complexity to use another name

Yes but the tooling we use relies on a trans object, so we would be changing things and introducing a different syntax. Also this could also be handled at the frontend level, no?

Well I would do something like:

from jinja2 import Template

template = Template(JSON_FILE)
new_json = template.render(trans=trans)

Or just use babel directly, so that we can provide the objects ( trans._(. etc.)

I think to do that at the schema file loading step - I still have to figure out how to have the translation loaded and available at that time:

That should not be too hard. The question is. Are we parsing that on the server so the frontend will receive a translated JSON file?

[fcollonval]

the tooling we use relies on a trans object

Sorry I saw the example with context after. So yes it make sense to bring our own function to handle the translation.

Are we parsing that on the server so the frontend will receive a translated JSON file?

I had that in mind. But I did not though about doing it in the frontend actually... What would you suggest?

[goanpeca]

I had that in mind. But I did not though about doing it in the frontend actually... What would you suggest?

Well I read that

I think to do that at the schema file loading step - I still have to figure out how to have the translation loaded and available at that time:

And now I am thinking that... it might be tricky. So doing it on the frontend might actually make it a bit easier?

@blink1073 , @afshin what do you think about this?

[fcollonval]

So doing it on the frontend might actually make it a bit easier?

I know that for jupyterlite if this is done on the frontend will be easier 😉

[goanpeca]

I know that for jupyterlite if this is done on the frontend will be easier 😉

Hahaham, well we would need to bundle the translations so jupyterlite could use them, so that brings an interesting question. Now that you mentioned it, how could we approach that? Making npm packages for the language-packs as well?

[fcollonval]

Closing this one as a better mechanism will be coming with #8