1.10
Internationalization and Localization

This chapter discusses how to make use of internationalization (i18n) and localization support in EGT.

UTF-8 Encoding

UTF-8 encoding is supported everywhere in EGT. All text is stored in std::string. No other special storage classes are used. All std::string objects are assumed to be UTF-8 encoded within EGT. For more information on why this is done, see the UTF-8 Everywhere Manifesto.

To help understand details about Unicode and different character sets, see The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!).

Text Translations

Any framework that supports language translations, otherwise known as internationalization or i18n for short, should work without any issue with EGT. This is largely an application level exercise as long as the method supports UTF-8 encoding, or the conversion to and from UTF-8 encoding, as required by EGT. However, the recommended method to perform text translations in an EGT application, for example to display different languages, is using the mature and well established GNU gettext support.

‍GNU gettext offers to programmers, translators, and even users, a well integrated set of tools and documentation. Specifically, the GNU ‘gettext’ utilities are a set of tools that provide a framework to help other GNU packages produce multi-lingual messages. These tools include a set of conventions about how programs should be written to support message catalogs, a directory and file naming organization for the message catalogs themselves, a runtime library supporting the retrieval of translated messages, and a few stand-alone programs to massage in various ways the sets of translatable strings, or already translated strings.

Basically, gettext provides the ability to write all of your strings in one language (usually English) in code, and then allow a "database" of different translations for those strings to be loaded by the application depending on language and locale settings at runtime. In addition, gettext defines a workflow and tools for creating those translation "databases."

Example GNU gettext Steps

Here are the steps necessary to implement the usage of gettext in an EGT application:

Create a .po (Portable Object) file:

make build-po

If new strings are added, update the existing .po file:

make build-merge-po

Use a text editor to open the .po file and add translations to all the strings. You may also need to set the charset as UTF-8:

vi es.po
"Content-Type: text/plain; charset=UTF-8\n"
msgid "Hello World!"
mgsstr "Hola Mundo!"

Generate a .mo (machine readable) file from .po:

make

Set the LANGUAGE environment variable and run:

LANGUAGE=es.utf8 ./i18n
Note
In buildroot, you have to enable the locales you want to add a new text domain for:
Symbol: BR2_GENERATE_LOCALE [=en_US es_MX]

Configure Locales in Ubuntu

$ locale -a
C
C.UTF-8
de_AT.utf8
de_BE.utf8
de_CH.utf8
de_DE.utf8
de_LI.utf8
de_LU.utf8
en_AG
en_AG.utf8
...
POSIX

If a locale does not appear in the list, it will have to be additionally installed.

$ sudo locale-gen fr_FR.UTF-8
Generating locales...
fr_FR.UTF-8... done
Generation complete.

The following file contains a list of all available locales: /usr/share/i18n/SUPPORTED