Internationalization prior to Localisation

[candeira]

I notice that the documentation says "This is a thing that supports creating English-language text from a graph description." However, it could also create Spanish-language text, or Chinese-language text.

I have one suggestion that the code is internationalised, by cleanly separating the code into two layers:

• one that makes inferences about the graph, and generates an internal representation of the graph description; and
• a second layer of code that expresses the inferred description into a natural language. This second natural language layer could then be extended by localising the module, that is by writing a different submodule for a different natural language.

[tleeuwenburg]

Hi Javier,

Thanks for stopping by! Fortunately, the code is already structured that way. The scope of English-language refers more to current functionality (user-focused) than limitation (developer-focused). I would love to support a second language -- for the basic functionality that's there now I don't think it would be hard to build, particularly with a little help. I had been considering doing one just doing a Google translate of the English text, but I expect that a "native" version would be better?

If you happen to have the time, I'd be more than happy to take you through the code so you can see how to add the functionality, but if not that's totally fine. It's on the wishlist :).

Cheers, -T

[candeira]

One way to do this could be via gettext and similar standard means of internationalisation. However, I like to see the the actual NLT production as a rendering process which uses language-specific code and templates. We would bake the different languages into the original Python code. Let's get together for a first draft at least.

[moved discussion about meeting to email]