i18n Support

[knolleary]

We haven't decided on what time-scale we want to enable node-red to be internationalized, but it is something we need to have a plan for.

This needs a high-level design that considers how each of the main components will have to be changed to support i18n. The runtime and editor should be fairly straightforward to add support for message catalogues. The hard part is how nodes can provide localized versions; their current architecture doesn't make it entirely obvious how this will be achieved easily.

Then there is the question of what library to use. Amongst the libraries that appear to be candidates are:

• jquery.i18n
• i18next

[kallenboone]

The nodes pose an interesting problem for localization. Much of the text associated with them is in an .html file. From what I understand of the editor code (correct me if I'm wrong), the contents of these .html files are appended to the DOM and data-template-name and data-help-name script elements are used to fill the node config dialog and node help panel, respectively. Currently the contents of the the script elements seem to be used without any processing.

My first thought is to run the markup from these two elements through a basic template engine. All it really needs is a simple find/replace. Both libraries you mentioned allow for specifying an element's PII key using a data-i18n attribute, but that feature doesn't seem to work with nested HTML, which could be a problem since I see a lot of the elements including an tag in addition the text. Doing the swapping once the HTML has been added to the DOM could be unnecessarily complicated, as well.

We could also do the text swapping on the server side. The backend service GET /nodes that returns the node configs would then just do a global find/replace on the html as plaintext, and we can avoid messing with DOM operations outright. Add some caching and I imagine this approach would have better performance than doing the locale swapping on the client side.

In either case, each .html file would need to replace the text snippets with variables. If we set up our variables like ${key}, then we could use a function like

nodeHelpText.replace(/${([a-zA-Z]*)}/g, function(match, key){ return i18n.t(key); });

to perform the replacements. We'd also need a way to specify which PII file to pull the data from. I imagine the core nodes would all use a common file, but additional packages like the web nodes and user nodes would need their own PII file. The client-side approach would make specifying the file easy: just use a property on the object passed to the RED.nodes.registerType() function called in the .html file to set the PII file. I'll have to look more at how the backend stores node information before I determine a good way to specify the PII file with that approach.

These are my initial thoughts. Let me know what you think and whether you have any questions.

[knolleary]

Thanks @kallenboone - that's helpful. I'm going to have a play with i18next and node-i18n this weekend to get a better feel for how they work.

[dceejay]

For low power devices like Pi, the more that can be done client side the better. Or have a passthru non translated mode of operation.

[vergissberlin]

An important aspect for me is the translation UI. It allows to keep track of and maintain the highest possible number of translations.

1. I like the translate ui tool from i18next. http://i18next.com/pages/ext_webtranslate.html But it seems a bit too rudimentary.
2. Pootle is a very common tool and is bettor for a higher count of translations keys. Example: http://translation.typo3.org/
3. Here is another or editor which also support XLIFF format but it is written in phyton.

[drwoods]

The i18next and i18next-client look like good options. I'm not as worried about UI based tooling, but it does seem to have an option for that along with the i18next-parser extension to bulk pull strings from the code (which could also be used to fail builds if new hard-coded strings are being added.)

@kallenboone can you post an example of how we would translate an existing core Node (like HTTP in/out or HTTP request) as a fork and maybe a short diff?
Also, how would builds and runtime behave if not all of the code in a project (like node-red-web-nodes) is translated to additional languages?
Would also like to think of how we would denote translated support on the Node-RED Flows site and the core Nodes readme file in an automated fashion.

[kallenboone]

@drwoods Good questions. I'm working on the fork/diff currently, and I should have something to show in the next day or so.
Ideally, the code would fallback to English (or whatever original language) when a translation is not available. The i18next library supports the fallback functionality. Third party node developers would also likely have the ability to just hardcode their text instead of providing a PII file. How these things pan out in practice will depend on our implementation, of course.
How we would denote translation support also depends on our implementation. The simplest way would be to include a flag in the node's config object in the .html file. We'll likely need some sort of option there to point to the PII directory anyway.

[knolleary]

@kallenboone as I said on the call today, please can you and I sit down to design this before you get too involved in code. There are fundamental architectural issues to address that we need to work together on.

[kallenboone]

@knolleary No prob. I'm available most of tomorrow afternoon for a meeting. Just let me know when is best for you. The fork I'm working on is just a quick proof of concept, nothing that would likely end up in the final code. It's just an example that we can look at as we work through the architecture issues.

[knolleary]

Having looked at i18next, it claims to provide both node.js and browser i18n support, which many of the others don't - they tend to be one or the other.

However, I'm struggling to figure out what version of what library we actually want.

From their home page, they have download links to a v1.8.0 zip file.

They also link to the i18next-client npm package, which is currently v1.8.2 (1 month old). Its README says they are currently looking for contributors for the project - not always a good sign of its long-term prospects.

The page also links to the i18next npm package, which is currently v1.7.10 (2 months old).

This latter one is intended to run within node.js and iincludes a helper function to serve the library to the browser. Unfortunately, the route it uses to serve the library is hardcoded - not suited for embedding in node-red as is - but certainly something we can work around.