|
 |
9c6e0d |
The @file{trunk/Locales} directory exists to store the translation
|
|
|
9c6e0d |
messages used to produce content in different languages.
|
|
|
9c6e0d |
|
|
|
9c6e0d |
Translation messages are organized using the directory structure of
|
|
|
9c6e0d |
the component being translated. For example, if we want to provide
|
|
|
1856b7 |
translation messages for @file{trunk/Manuals/Repository}, then the
|
|
|
1856b7 |
@file{trunk/Locales/Manuals/Repository} directory needs to be created.
|
|
|
9c6e0d |
|
|
|
9c6e0d |
Once the locale directory exists for the component we want to provide
|
|
|
9c6e0d |
translation messages for, it is necessary to create the translation
|
|
|
9c6e0d |
files where translation messages are. The translation files follows
|
|
|
9c6e0d |
the concepts of @command{xml2po} and GNU @command{gettext} tools.
|
|
|
9c6e0d |
|
|
|
9c6e0d |
The basic translation process is as follow: first, translatable
|
|
|
9c6e0d |
strings are extracted from files and a portable object template (.pot)
|
|
|
9c6e0d |
is created or updated with the information. Using the portable object
|
|
|
9c6e0d |
template, a portable object (.po) is created or updated for translator
|
|
|
9c6e0d |
to locale the messages retrived. Finally, a machine object (.mo) is
|
|
|
9c6e0d |
created from portable object to sotore the translated messages.
|
|
|
9c6e0d |
|
|
|
9c6e0d |
Inside the repository there are two ways to retrive translatable
|
|
|
9c6e0d |
strings from files. The first one is through @command{xml2po} command
|
|
|
9c6e0d |
and the second through @command{xgettext} command. The @command{xml2po}
|
|
|
9c6e0d |
is used to retrive translatable strings from XML files (e.g., Scalable
|
|
|
9c6e0d |
Vector Graphics, DocBook, etc.) and the @command{xgettext} command is
|
|
|
9c6e0d |
used to retrive translatable strings from shell scripts files (e.g.,
|
|
|
9c6e0d |
the files that make the @command{centos-art.sh} command-line
|
|
|
9c6e0d |
interface).
|
|
|
9c6e0d |
|
|
|
9c6e0d |
When translatable strings are retrived from XML files, using the
|
|
|
9c6e0d |
@command{xml2po} command, there is no need to create the machine
|
|
|
9c6e0d |
object as we do when translatable strings ar retrived from shell
|
|
|
9c6e0d |
files, using the @command{xgettext} command. The @command{xml2po}
|
|
|
9c6e0d |
produces a temporal machine object in order to create a translated XML
|
|
|
9c6e0d |
file. Once the translated XML file has been created the machine object
|
|
|
9c6e0d |
is no longer needed. On the other hand, the machine object produced by
|
|
|
9c6e0d |
the @command{xgettext} command is required by the system in order for
|
|
|
9c6e0d |
the show shell script localized messages.
|
|
|
9c6e0d |
|
|
|
9c6e0d |
Another difference between @command{xml2po} and @command{xgettext} we
|
|
|
9c6e0d |
need to be aware of is the directory structure used to store machine
|
|
|
9c6e0d |
objects. In @command{xml2po}, the machine object is created in the
|
|
|
9c6e0d |
current working directory as @file{.xml2po.mo} and can be safetly
|
|
|
9c6e0d |
removed once the translated XML file has been created. In the case of
|
|
|
9c6e0d |
@command{xgettext}, the machine object needs to be stored in the
|
|
|
9c6e0d |
@file{$TEXTDOMAIN/$LOCALE/LL_MESSAGES/$TEXTDOMAIN.mo} file in order
|
|
|
9c6e0d |
for the system to interpret it and should not be removed since it is
|
|
|
9c6e0d |
the file that contain the translation messages themselves.
|
|
|
9c6e0d |
|
|
|
9c6e0d |
Automation of localization tasks is achived through the @code{locale}
|
|
|
9c6e0d |
functionality of command-line interface.
|
|
|
9c6e0d |
|
|
|
9c6e0d |
@menu
|
|
|
be55d4 |
* Directories trunk Scripts Bash Cli Functions Locale::
|
|
|
9c6e0d |
@end menu
|
|
|
9c6e0d |
|