These are thoughts and ideas on implementing support for multiple languages in Etherpad lite. None of this is fixed or bound to make it in for the implementation, the individual items may even be inconsistent with one another... Think of it as a brainstorming session.

Feel free to +1 or -1, add your objections and/or own thoughts/ideas!

Two possibilities:

• Translations should be pugins! Implement an event like translateString, that can be hooked into by plugins like ep_fr-FR, ep_de-DE. (Ordinary plugins, could also use this hook, to make their own interfaces translatable). +1
• Translations should be in core (so, any changes to translations can be pull request'ed on the main repo)

Two possibilities:

• Translations should be resolved alongside the template parsing process, thus on the server
• Translations should be resolved on the client side, since we can outsource CPU that way and can serve the same pad in multiple (interface) languages, easily."

Things to consider:

• Are there strings to be translated, that are not part of the templates / not in html?
• How to / Should we provide translation functionality to plugins? (All plugins are currently in English.)

• At a minimum the host should provide a means to communicate the preferred localization(s) to plugins. As far as providing translations – I am skeptical. Generally speaking, shared translations are doomed to failure, since they are context-sensitive (even simple phrases like “new” can have an implicit dependency on class of an unspecified object). We could provide some shared library for it, but I think our time would be better spent on other things – there’s little difference between that and recommending some decent libraries for implementers to use. ~ @cweider

• I would heavily recommend this implementation of i18n for html pages https://github.com/fabi1cazenave/webL10n which is used on B2G/firefox OS to come. The file format of the extracted strings is good old plain .properties which is well-known among translators (note you can comment every line with #). Push en-US .properties files on http://www.babelzilla.org and you can get major languages rather soon.

• +1, but how to treat strings, that are not part of a template, thus not in html? (see above) -- marcelklehr

• Translations could be done on http://translatewiki.net (like MediaWiki and other awesomely-i18n'd software)

I did a start on this now and implemented one of the possible solutions that are mentioned above:

• translations are resolved on the client side
• The UI will always be displayed in the suiting language (no admin setting for language)
• translations should be in core (this can be changes relatively easy, though)

The pull request lives at https://github.com/ether/etherpad-lite/pull/1153 -- marcel