Adding ITranslator as an attribute of Widget

[thegooman]

trafficstars

Wanted to open this up for discussion. Right, now we have to register and load the translator for every extension and every Widget inside of it, which seems inefficient.

I'm proposing that we add a translator attribute to Widget and take an optional parameter translator in the constructor. If no, translator is given, we can just set the translator as the nullTranslator (dummy-implementation that returns the same string). This would also allow us to translate labels, captions, and other common strings down at the Widget level making it easier for current and future extensions to implement localization.

This would allow us to reduce the amount of redundant code and standardize translation since every Widget would have a translator (possibly nullTranslator) by default. I don't think there would be any breaking changes as this would serve as an optional parameter.

The only issue I can see is that Lumino is depending on a JupyterLab package, but I think that would be okay? Not too sure where this fits in terms of the 3.0 release but wanted to get this conversation going before we start adding translations to every extension.

@goanpeca @blink1073

[jasongrout]

The only issue I can see is that Lumino is depending on a JupyterLab package, but I think that would be okay?

I don't understand all of the technical details here, and wish I had time to dive in. However, we have been very clear that Lumino is the layer below JupyterLab, and people are using Phosphor/Lumino in contexts very much outside of JupyterLab, so I think having a dependency from Lumino to a JLab package is a no-go. Is there another way to do this? Does this mean translation gets pushed down to Lumino? Or is there another layer in between JLab and Lumino that can host this translator?

[goanpeca]

having a dependency from Lumino to a JLab package is a no-go.

Yeah I don't think this is the way to do it.

Does this mean translation gets pushed down to Lumino?

A part of it could I guess 🤷

[blink1073]

I think we can push down the parts that don't rely on a particular REST endpoint.

[thegooman]

Sounds good, I think its something that can be discussed after the 3.0 release. Thanks again for everyone's input.

[vidartf]

Initial opinion: As there are multiple i18n frameworks out there, I think we should only add this if the solution is agnostic about choice of framework. Currently, one of lumino's great strengths is that it is framework agnostic 👍

[bollwyvl]

This recently came up again in discussion, both in Lab, and in the adoptability of lumino for new-start, non-Lab applications that want a number of facets, e.g. translation, accessibility role, etc. These would be very helpful for any downstream application to be able to optionally enable at the Widget level, but be aware of (and hopefully manage) at the Application layer. But I definitely agree that no @jupyterlab, react, whatever, references should be made here, and the choice of translation framework should be left to the implementing application, with a only very simple reference implementation in an example (e.g. a JSON file available at compile time).

I think the ideal for a product team would to be able to specify Application<X> level, where X might be a confection of Translateable, Accessible, etc. I haven't looked into the hooks that would be needed, but being able to reason about these features at the type level would go very far to making this maintainable.