Difference between revisions of "Languages subsystem improvements 2.0"

Jump to: navigation, search
m (Research)
(See also)
Line 51: Line 51:
== See also ==
== See also ==
* [http://live.gnome.org/TranslationProject/GitHowTo How to use Git for GNOME translators]
* [http://live.gnome.org/TranslationProject/GitHowTo How to use Git for GNOME translators]
* [http://translate.sourceforge.net/wiki/ Nice site with tools, localisation problems and alternatives...]

Revision as of 02:09, 21 November 2009

Languages subsystem improvements
Project state Research and planning
Tracker issue n/a
Discussion n/a
Assignee {{{assignee}}}

Moodle 2.0

This is an initial proposal of changes to the language strings processing in Moodle.

Current issues

  1. String files are not branched. We must keep all strings from all branches in place for backwards compatibility and we are unable to easily clean up language packs. Some say the branching and merging is too big toast for our translators.
  2. Plural forms, gender forms and other grammar. We are unable to handle plurals at all. For example, handling plural forms in gettext is traditional, well tested and robust way. MDL-12433 by Sam Marshal shows alternative approach based on logical expressions.
  3. Strings can't be modified. It is difficult to notify translators that some string was modified (expanded, fixed, changed). The current work around it the policy of adding another string with the same suffixed name (like 'license2'). Would be nice if such strings were tagged/highlighted in the translation UI.
  4. We do not use standard formats. Translators can't use specialized tools for translation (PO/gettext editors, community translation portals). Also, I am not aware of any benchmarking showing the performance differences between out native $string[] format compared to, for example, standard .po format.
  5. More syntax checks are required so the translators do not brake Moodle functionality (see MDL-12433)


  1. Do not reinvent the wheel. Keep "do one thing and do it well" principle. Keep it simple and stupid.
  2. Make simple things easy and hard things possible
  3. ...

Use cases

  1. Developers add new strings to the core
  2. Translators translate untranslated core strings and publish their work
  3. Admins want to locally modify the language pack
  4. Contributors add new string to the contributed code
  5. Translators translate untranslated contrib strings and publish their work
  6. ...


This is the list of projects, resources and tools being explored


See also