Skip to content

Translations management

Yannick Warnier edited this page Mar 21, 2024 · 5 revisions

History

WARNING: This page is deprecated. Please use Internationalization instead.

How to translate Chamilo

Starting from the alpha version of Chamilo 2.0, you can help translating at https://crowdin.com/project/chamilo-lms

Internal: creating new strings

In Chamilo 2.0 (and later), we use Gettext. This means you will always have to indicate the variable names as the full English sentence. For example, if you want to create some code that uses the text "Please type you code here:", then inside the PHP code or the template file, your variable will look like this:

get_lang('Please type your code here:')

Internal: importing new strings to CrowdIn

This process is not completely finished yet, but we will have a script that pulls all gettext strings from the Chamilo code and adds them to a english.pot file, which will be manually imported to CrowdIn to enable the new terms there.

Internal: exporting strings from CrowdIn

From CrowdIn, we export strings regultarly in the gettext format, and import them to the language folder in Chamilo 2.0+: translations/ Then the folder is submitted to Git with the command:

git commit -m "Update language terms" translations/

First language files

Chamilo is a fork of Dokeos, which is a fork of Claroline. In Claroline, and then in Dokeos, the decision was taken to have translations managed through PHP-formatted files. Something like this:

<?php
$TheFirstLanguageVariable = "The first language variable";
$SomeOtherLanguageVariable = "Some other language variable";

Also, files would be split by feature-set: one file for forums (forum.inc.php), one file for documents (document.inc.php), one file for exercises (quiz.inc.php), etc. One single common file (trad4all.inc.php) was used for variables shared between several features (terms like "User", "Teacher", "Student", etc).

Initially, those were not issues because:

  • there were only a few languages
  • there were only a few variables
  • contributors were mostly in the same team

Translator tools

But as time went by and the projects grew more popular, the need appeared for more streamlined tools for non-technical translators to contribute. Claroline created thr phpLangEditor extension for Firefox, Dokeos created the Dokeos Language Translator Tool (website) and things got a bit better for translators.

Overlap

Then, as the projects progressed even more and a bit before the birth of Chamilo (2010), issues started to appear because:

  • many terms were used in several features but not globally (learning paths and documents shared a lot of common terms), creating unnecessary duplication
  • the large number of terms started to generate duplication
  • more mature language needs appeared (plural forms, gender-specific forms, etc)

Parallel evolution

With time, Claroline died and the phpLangEditor extension for Firefox disappeared. The DLTT tool for Dokeos translations was replaced with a very basic version of Chamilo LCMS with a plugin for that (at https://translate.chamilo.org), Chamilo LCMS died making it necessary to either re-develop a translation tool, maintain the current one on a old version of PHP somewhere (in an insecure vintage Docker PHP image) or to make a big bold move and change everything to Gettext or XLIFF

Also, translation tools for other projects got more streamlined and more efficient: using standard Gettext/XLIFF/other syntaxes, allowing to share translations suggestions between projects, etc

Importing files to translate.chamilo.org

For one-time translation contributors in the old system, admins of the translation tool can receive a trad4all.inc.php with all or most strings translated and import it into translate.chamilo.org through Administration > CDA > Import language files. The file needs to be in zip format, contained within a directory of the (English) name of the destination language (translated version). Then export the file to Chamilo to add to Git.

Important note: if the imported file contains new variables, these variables will be created, which goes a bit out of our validation process. So after this, make sure the last variables in the cda_variable table are the last ones are ones that were added through the normal process, no through this import.

Decision for a new format

The decision to go with Gettext was made mainly from checking the market of other Open Source solutions and reading the following sources:

A tool was then scouted to deal with those translations. Although Pootle is Open Source and enables that, several tests of importing our strings failed, and we decided to go with CrowdIn. In the future, would CrowdIn fail to meet our expectations or charge for the service, we could be able to work a bit more and enable a self-hosted Pootle platform, but at the time of writing and after several dozen hours of work trying to make Pootle work for us, this all seems like time that could be better spent doing something more useful for Chamilo.

Clone this wiki locally