Note:

If you want to create a new page for developers, you should create it on the Moodle Developer Resource site.

Automated Manipulation of Strings 2.0

From MoodleDocs
Revision as of 10:12, 1 March 2010 by David Mudrak (talk | contribs) (Added AMOS processes)
Automated manipulation of strings
Project state Proposal
Tracker issue MDL-18797
Discussion [1]
Assignee David Mudrak

Moodle 2.0


AMOS stands for Automated Manipulation of Strings. AMOS is a central repository of Moodle strings and their history. It tracks the addition of English strings into Moodle code, gathers translations, handles common translation tasks and generates language packages to be deployed on Moodle servers.

The name was chosen in honour of John Amos Comenius, the author of Janua linguarum reserata (Gate to Languages Unlocked), who may be considered the father of modern education.

Overall picture

lang20amosflow.png

  1. Developers add new string by adding them into appropriate English $strings array definition file (eg /mod/workshop/lang/en/workshop.php). This file is committed into Moodle main CVS repository as a part of the code.
  2. CVS repository is mirrored automatically on the fly in a git repository. This git repository is used for further processing because parsing the strings file and tracking their history is much simpler in this system. The whole history is present in the git clone so there is no need to ask CVS server for anything once it is fetched.
  3. Git repository is regularly checked for any changes in string definition files. Once a modification is detected, the file is parsed and any addition, modification or removal of a string is recorded in an English strings database, together with a meta-information about the author of the change, timestamp, branch, commit identification (git commit hash) etc.
  4. Translators use the strings definition stored in the English strings database as a reference for their translation. Therefore the information about the origin (the branch and the revision) of the translated English string can be stored as meta-info together with the translation. Every translated string is linked with a certain revision of the English source so we can easily find strings there were modified in English to be re-checked etc.
  5. So called translation stage (or cache) is used during the translation. This is similar to the session cache when working with XMLDB. Once the translator is happy with the work, she/he commits (submits) the translation into the database of the translated strings.
  6. Non-English strings database contains the history of the translation of all Moodle strings in all supported languages. This database is used as a source to generate the up-to-date language package in various formats (ZIP to be deployed at the servers, XML to be used by an external translation tools etc).
  7. Moodle site administrators update their installed language packs by downloading the ZIP files generated from the database (or, in the future, they can fetch the pack in other format)

AMOS processes

lang20amosflow2.png

Tracking CVS commits
run as a cron job. Looks for new/modified/removed strings in Moodle source code (core and contrib) and registers these changes in AMOS database.
Uploading strings
both English and translated strings may be registered from uploaded files. This way, 3rd modules not tracked by AMOS automatically (because they are not in our contrib) can be processed in AMOS.
Translating strings via web
AMOS provides an interface for translating stored strings (MDL-21691).
Staging
Strings from various sources end in a staging area. They are stored here temporarily before they are committed into the main strings table.
Committing
A set of strings in the stage is committed into the main strings table.

Thanks to this design, we have a single interface to get data from stage into the main strings repository. For every supported format/way to get strings, just a class implementing 'stageable' interface is needed to convert the input format into the staging area.

Hierarchy of classes is expected to be available for input processing. For example, the process that tracks commits history in CVS prepares a PHP file with the checkout. So we have a class that is able to convert array $string[] defined in PHP file into staging area. Once we have such class, it can be used to process PHP files uploaded by developers/translators, too.

Implementation plan

The implementation proposal evolved from the idea by Petr Skoda discussed at moodle.org. The key point is that translators do not have direct access to the source code repository (CVS) any more. There is a central tool (known as AMOS nowadays) that looks after proper branching and keeping history of the language packs. The current proposal follows.

  1. There a separate Moodle 2.0 site at http://lang.moodle.org MNet'ed with http://moodle.org. This site is intended for our developers, translators and other community members interested in the translation process. Current Languages forum at Using Moodle can be eventually moved into this new languages portal.
  2. AMOS is implemented as a local plugin /local/amos installed at http://lang.moodle.org. Because this is the only Moodle site with this plugin, using /local plugin mechanism is a natural way to implement, develop and maintain it.
  3. There is a course "Moodle Translation" in this portal containing (among other useful things) a clear link to the /local/amos/view.php page.
  4. During Moodle 2.0 beta period, translator use AMOS portal to prepare the translations of the new Moodle release.
  5. AMOS installation at http://lang.moodle.org uses its own git clone of our official git mirror to have access to the English strings. Keeping the git mirror up-to-date and synced is a prerequisition for the proper AMOS functionality.

Use cases

  1. Developers write the code and commits it into CVS. They can create or modify English strings as needed in the current way of direct modification of the strings definition file.
  2. Translators come to http://lang.moodle.org to translate Moodle. No other way is possible yet.
    1. translators can choose the Moodle version (1.8, 1.9 or 2.0) to translate
    2. translators can display the list of missing strings to translate
    3. translators can display the list of English strings that were modified since their last translation so they should be re-checked
    4. translators can display the history of string wording, authors of the change, commit messages explaining the change
    5. other useful tools and filters are available, like displaying all strings containing a given phrase etc. See MDL-18797 for details
    6. after providing new or modified translations, translators "commit" their changes through the web interface, providing a commit message
  3. Administrators can download language packages as ZIP files from http://download.moodle.org or let them update automatically from the Moodle
    1. packages are regenerated automatically as they are at the moment, with the only difference that the database and not CVS is used as their source
  4. Contributors [must think about this yet] - their plugins in CONTRIB can be mirrored into git (one day this will happend anyway ;-)) and then AMOS can process them easily. Or we could add a feature that the contributor can upload the file with English strings definition manually and "register" the strings this way.
Retrieved from "https://docs.moodle.org/dev/index.php?title=Automated_Manipulation_of_Strings_2.0&oldid=16911"
Powered by MediaWiki