Explore support for i18n

[rlmark]

Capturing this from recent conversations with community members: one thing that would increase the reach of Unison's presence and accessibility would be to support i18n in some capacity for our website.

Considerations:

• Could the i18n take place via transformations of the underlying Doc type?
• Machine vs human translations - programmatic translation services exist but aren't always great for texts of any measurable complexity.
• Moderation and review of translations would need to take place before publication.
• The website in its entirety is a large text body so supporting a subset of internationalized docs may be best.
• Many many others! Please continue discussion, requests, or ideas in this ticket thread.

[gfinol]

Could be interesting to have a "language selector" (button, menu or thing) in Unison share and in the local UI for Doc types. Therefore, for a given term or type in unison, we could link more than one Doc file, maybe one per language.

One way to do it could be to add the international language code (ISO 639-1 or similar) at the end of the name. So, if we have the term myFunction:

• myFunction.doc.en would be the Doc in English.
• myFunction.doc.es would be the Doc in Spanish.
• myFunction.doc.fr would be the Doc in French.
• myFunction.doc.de would be the Doc in German.

This way, the GUI in Unison Share should just count how many languages are available and display them in the language selector.

Of course, adding i18n or any other programmatic translation tool, could help to speed up the process.

For the record, I'll leave here what Android does with the strings.xml file. Because I find it a good way to address the problem.