Internationalization

For a piece of software as large as Chamilo, internationalization (or "i18n") is always kind of a complex process. As we move forward, we always try to optimize the processes, but this page hopefully will give you the information you need to customize your Chamilo, contribute translations or documentation and understand the way translations are managed in Chamilo, starting from version 2.0.

We will leave out of this document (for now) the internationalization elements that are out of a pure translation context:

• date formats
• left-to-right vs right-to-left (ltr vs rtl)

Chamilo software internationalization

Adding new terms

Chamilo 2.0

Choosing gettext

Backend translations

Frontend translations

Chamilo 2.0 uses Vue.js, which deals with many elements of the interface. As such, it needs to be aware of, at least, the navigation elements that will appear in the dynamic menus and permanent pieces of the interface.

These translations are stored in assets/locales/ in the JSON format.

To add a new term to the interface, you would need to:

• add it to the backend translations (with the corresponding translations)
• add it to new term to assets/locales/en.json
• php bin/console chamilo:update_vue_translations

Self-contained terms

When creating new terms, it is important to consider adding full terms with variables, rather than several partial strings.

Hi Jim,

A very clear example of this is the welcome part of an e-mail. Say you want to say "Hello Jim," as the introduction of an e-mail... The e-mail body itself is likely to be very varied (the welcome message could always be the same, while the body will always change), but the welcome message can be re-used over and over.

However, if we try to analyze this message, we can see there are 4 parts:

• Hi (an opening word)
• Jim (the name of the person)
• , (a comma) (marking the end of the welcome message)
• a blank line (usually represented by \n in web software)

The first element, then, is that the name will change each time. So we want that name to be a variable. For that, there is a relatively common standard in computer sciences, which is to represent it as %s:

• % to indicate a special marker
• s to indicate a string (d can be used for decimal numbers, too, but string works for everything you need in a translated term)

So our non-translated string should say something like Hi %s,\n.

You might think that you could split this string, so you don't have to deal with the name in a "weird" way. so you could possibly rely on the developer and just translate "Hi". The developer would then add (programmatically) the name, the comma, the newline marker.

But there's an issue with that:

• in Japanese, you would write Jim ^、\n (with a different comma sign and the salutation after the name)
• in Arabic, you would write ،مرحبا جيم\n (right to left, with the comma on the left but the newline on the right)

This is why we ask all new strings to be self-contained, so that the developer only has to replace the variable (the name) inside the string, and not deal with so many conditionals to deal with all languages.

History/legacy

In the past (versions 1.11 and earlier), we used our own system at https://translate.chamilo.org.

Despite us being thankful to the people who built it (on top of a relatively unstable base of Chamilo LCMS) quickly when we needed it, this system had several flaws which slowed us down in the translation process:

• lacking subscription process and approval process
• built for multiple translation files, where we later changed to a one-file structure
• slow export process (in particular when exporting 60 languages)
• lack of practical JS features to speed up the process
• lack of integration with tools (like Google Translate) to help with translations suggestions
• lack of support for Gettext

Nevermind these issues, this system was used from 2010 (the birth of Chamilo) to 2022 (birth of Chamilo 2.0), so hurray for a system that simply worked.

Chamilo user guides internationalization