Every eBox module has it's own gettext domain for the text strings it owns, the domain name is derived from the module name. Modules must set their gettext domain both in their constructor and in each one of their CGIs as explained in Section 3.1.1 and Example 5.7 respectively.

All files that contain translatable strings, including mason templates, must include the EBox::Gettext perl module. Also, every translatable string must be marked as such, using the __ function as the following example shows:

print __("Hello world");
			

This will enable the eBox build system to detect and extract all the translatable strings.

If a string includes a variable you should not concatenate it:

print __("Edit ") . $group . __(" members"); # wrong
			

This would make it impossible to correctly translate the whole sentence. The right way to do it is to use the __x function, which is a variant of __ which lets you include variables:

print __x("Edit {group} members", group => $group); # right
			

This way the translator can place the variable group in the right position in the sentence.

If you want to mark a string as translable but determining not to translate it, you should use __n function. An example of usage is the following:

my $options = [__n('Foo'), __n('Bar'), __n('Foobaz') ]; # As many as you want
print __($options[$index]);
			  

The example showed above gives the chance to translator to translate only the option selected leaving the remainder (a high number normally) without a translation.

If you follow this rules correctly, the build system will automatically generate PO files with all translatable strings included. These PO files can be easily translated, as explained in the next section.

Using GNU gettext as an i18n platform means we have the most widely used format for translations: PO files. Every eBox module has its one PO file for every available language. A translator just needs to translate all strings listed in that file in order to have a completely translated module. In case you are starting a translation for a new language from scratch, all you need to do is ask for a PO file to be generated for your language.

A PO file contains the text strings in the original language (English) along with their translations. Each string may be in one for three possible states: translated (a translation exists for that string), fuzzy (a translation exists, but the original string has changed slightly) or untranslated:

# translated string
msgid "Name"
msgstr "Nombre"

# fuzzy string
#, fuzzy
msgid "Interfaces"
msgstr "Interface"

# untranslated string
msgid "External"
msgstr ""
			

If the string includes the value of a variable when it is shown in the user interface you will see an entry like this one in the PO file:

msgid "Edit {group} members"
			

In this case you just have to rewrite the sentence placing the name of the variable (in curly braces) in its proper place, but without translating it. The correct translation for this string in Spanish would look like this:

msgstr "Editar miembros de {group}"
			

The preferred way to translate PO files is using our Web interface which is developed by Pootle, a Web application introduced in order to lower the barrier to start translating eBox.

Even though it's possible to translate a PO file using any UTF-8 enabled text editor or some of the created specifically for this task, such as KBabel (*nix) or poEdit (multi-platform). This is the unrecommended way to translate, however, it could be useful for translators which have to start its home localisation from scratch sending the po files to the eBox team after editing with these tools.