1. translators use single translation interface at http://lang.moodle.org
1.1. the only way at the beginning of Moodle 2.0 beta period
1.2. adding a support for locally installed tools later
1.2.1. local strings customization possible later during 2.0 beta
1.3. translated strings are stored in a database
1.4. language packs are generated from the latest snapshot of the database for each branch
1.5. generated packs can be downloaded as ZIPs or via internal component downloading mechanism
1.6. commiting strings from the master database into a git repository possible in the future if there is a demand for it
2. HTML help files replaced with ordinary strings
2.1. makes the translation easier as we do not need to have other tools to translate help files
2.2. help consists of a paragraph or two of a static HTML only
2.2.1. no links
2.2.2. no images
2.2.3. just strong, em, p, br
2.3. the rest goes to wiki, linked via Documentation for this page
2.4. backward compatibility issues
2.4.1. dropping help files indices in favour of wiki
2.4.2. dropping some automatically generated helps (scales etc.)
2.4.3. dropping some helps that were actually a concatenation of several help files (like Add an activity)
2.5. location
2.5.1. $string['intro'] = 'Workshop intro'; $string['intro_help'] = 'This is the ...';
2.6. migration process
2.6.1. map the current $helppage to the new string to pair it with the text displayed next the field
3. in-place local customization
3.1. known as "I want to click at any text in Moodle interface and translate it in-place"
3.2. form in the footer that shows the list of all strings that were displayed on the current page
4. get_string() implementation improvement
4.1. language packs merging and compiling into run-time format
4.2. support for plural forms and other grammar issues
4.2.1. language pack may contain a library of functions or methods that are called instead of plain getting the value from array
4.2.2. not a trivial job - for advanced translators only
4.2.3. the format is not specified yet - we will start some experiments and will choose the solution as the standard one
5. move language files to the plugin space
5.1. as we have in contributed plugins
5.2. just to make things easier to understand
5.3. downloaded packs goes into $CFG->langpacks and there the structure of Moodle is copied
6. drop _utf8 suffix from language codes
6.1. everywhere, languages are reffered to as "en", "cs", "en_us" or "fr_local" only
6.2. just to make things easier
7. strings cleanup and alchemy
7.1. all plugin types must define "pluginname" and "pluginnameplural"
7.1.1. replaces current "modname" and other sort of strings
7.1.2. consistent way across all module types
7.2. moving strings from central components (like "enrol") into plugins
7.2.1. done automatically at AMOS database level, re-using current translations
7.3. general strings and help review
7.3.1. by Helen