Skip to content
cweider edited this page Sep 24, 2012 · 15 revisions

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 like a brainstorming session.

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

  • "Should be a pugin! Perhaps implement a hook like translateString and there would be a plugin for fr-FR. (Plugins could also use this to make their own interfaces translateable)."
  • "I18n should be core and changes to any language to a specific translation have to be pull request'ed on the main repo."
  • "Translations should be resolved alongside the template parsing process, 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."
  • Are there strings to be translated, that are not in one of the templates?
  • How to provide translation for 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 a 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

General

Resources

For Developers

How to's

Set up

Advanced steps

Integrating Etherpad in your web app

for Developers

Clone this wiki locally