The next step is to actually translate the UI text. We will see how to extract the texts from the UI file and translate them.
po
folder using a terminal.id.po
file, which we duplicated from the first part of the action, by typing the following command:intltool-update id
id.po
file using its menu.%x
, %s
, and others must not be modified or changed by translators except when it is requested to do so (for example, when adjusting the date format). The order of the appearance of these formats must not be changed as well.
Original text |
Translated text |
This is a label |
Ini adalah label |
Today's date is %x |
Tanggal hari ini adalah %x |
The price is %^=#6n |
Harganya %^=#6n |
The weight is %.3f %s |
Beratnya %.3f %s |
See you later |
Sampai jumpa |
po
folder inside the src
folder. Inside the po
folder, create an id
folder. After that, create the LC_MESSAGES
folder inside id
. So, altogether we should have a new folder called src/po/id/LC_MESSAGES
.id.gmo
file, which was produced after the rebuild, to hello-i18n.mo
into the folder we created in the previous step. Notice the hello-i18n
name must be exactly the same as the value of the GETTEXT_PACKAGE
variable, which we set earlier.LANGUAGE=id LC_ALL=id_ID.utf8 src/hello-i18n
This part is where the UI text is generated and translated. The resulting .po
files are then taken to the translators' hand and then into the translation queue. This must be done whenever we update any text in the source code. This is exactly done by just entering the following command:
intltool-update id
Note that this will
only update the id.po
file; any remaining files must be updated individually. What this command actually does is it extracts new text from the files stated in the POTFILES
file and merges them with the existing id.po
file. If there is an ambiguity, the translator would be notified in GTranslator
by being shown the text in a fuzzy state. The translator can then fix this issue by providing a new translation for those fuzzy texts.
After all the strings inside the .po
files are translated, all translated .po
files must be returned back to the po
folder. We then perform a build here. Actually, what the build does is it simply issues the following command:
msgfmt -cv id.po -o id.gmo
This step converts id.po
from a text form to id.gmo
in a binary form. The application can only take the binary form, hence we need this step. The bindtextdomain
function in the application sets the folder to the src/po/
folder whenever we are in the development mode. Actually, it will look for the binary .gmo
files in the src/po/<language-code>/LC_MESSAGES
folder. The language code is the code specified in the LANGUAGE
environment variable. If this variable is not specified, it will look for the language code in the LANG
, LC_MESSAGES
, and at last LC_ALL
variables consecutively.
The command we execute to run the application is as follows:
LANGUAGE=id LC_ALL=id_ID.utf8 src/hello-i18n
This sets the bindtextdomain
function to look for the translation in src/po/id/LC_MESSAGES
(because the LANGUAGE
variable is set to id
) and otherwise use id_ID.utf8
as the locale setting. The result is that the UI texts are translated to Indonesian, and the monetary, number, and measurement parameters are also set to Indonesian.
If you have another locale
installed to try, here is a good chance. For example, try to set LC_MEASUREMENT
to en_US.utf8
(United States), LC_MONETARY
to de_DE.utf8
(German), and LC_TIME
to ar_SA.utf8
(Saudi Arabia). Would you be able to get an output similar to the one shown in the following screenshot?