|
 |
e935c3 |
|
|
|
e935c3 |
<section>
|
|
|
e935c3 |
|
|
|
e935c3 |
<title>Localization</title>
|
|
|
e935c3 |
|
|
|
e935c3 |
<para>The localization work line exists to provide the translation
|
|
|
e935c3 |
messages required to produce content in different languages.
|
|
|
e935c3 |
Translation messages inside the repository are stored as portable
|
|
|
e935c3 |
objects (e.g., .po, .pot) and machine objects (.mo) under
|
|
|
e935c3 |
@file{trunk/Locales} directory structure.</para>
|
|
|
e935c3 |
|
|
|
e935c3 |
<para>The procedure used to localize content is taken from
|
|
|
e935c3 |
@command{gettext} standard specification. Basically, translatable
|
|
|
e935c3 |
strings are retrived from source files in order to create portable
|
|
|
e935c3 |
objects and machine objects for them. These portable objects are
|
|
|
e935c3 |
editable files that contain the information used by translators to
|
|
|
e935c3 |
localize the translatable strings retrived from source files. On
|
|
|
e935c3 |
the other hand, machine objects are produced to be machine-redable
|
|
|
e935c3 |
only, as its name implies, and are produced from portable
|
|
|
e935c3 |
objects.</para>
|
|
|
e935c3 |
|
|
|
e935c3 |
<para>Since @command{gettext} needs to extract translatable
|
|
|
e935c3 |
strings form source files in order to let translators to localize
|
|
|
e935c3 |
them, we are limitted to use source files supported by
|
|
|
e935c3 |
@command{gettext} program. This is not a limitation at all since
|
|
|
e935c3 |
@command{gettext} supports most popular programming laguages
|
|
|
e935c3 |
(e.g., C, C++, Java, Bash, Python, Perl, PHP and GNU Awk just to
|
|
|
e935c3 |
mention a few ones). Nevertheless, formats like SVG, XHTML and
|
|
|
e935c3 |
Docbook don't figure as supported formats in the list of
|
|
|
e935c3 |
@command{gettext} supported source files.</para>
|
|
|
e935c3 |
|
|
|
e935c3 |
<para>To translate XML based source files like SVG, XHTML and
|
|
|
e935c3 |
Docbook we use the @command{xml2po} program instead. The
|
|
|
e935c3 |
@command{xml2po} comes with the @file{gnome-doc-utils} package and
|
|
|
e935c3 |
retrives translatable strings from one XML file to produce
|
|
|
e935c3 |
portable objects for them.</para>
|
|
|
e935c3 |
|
|
|
e935c3 |
<note> <para>Portable objects produced by @command{xml2po} have
|
|
|
e935c3 |
the same format that portable objects produced by
|
|
|
e935c3 |
@command{gettext}. This make the localization process quite
|
|
|
e935c3 |
consistent from translators' point of view. No matter what the
|
|
|
e935c3 |
source file be, the translator will always face the same
|
|
|
e935c3 |
translation file format (i.e., the portable object format).</para>
|
|
|
e935c3 |
</note>
|
|
|
e935c3 |
|
|
|
e935c3 |
<para>With the portable object in place, the @command{xml2po}
|
|
|
e935c3 |
program is used again to create the final translated XML, just
|
|
|
e935c3 |
with the same definition of the source file where translatable
|
|
|
e935c3 |
strings were taken from (e.g., if we extract translatable strings
|
|
|
e935c3 |
from a SVG file, as result we get the same SVG file but with
|
|
|
e935c3 |
translatable strings already localized ---obviously, for this to
|
|
|
e935c3 |
happen translators need to localize translatable strings inside
|
|
|
e935c3 |
the portable object first, localization won't appear as art of
|
|
|
e935c3 |
magic---). When using @command{xml2po}, the machine object is
|
|
|
e935c3 |
used as temporal file to produce the final translated XML
|
|
|
e935c3 |
file.</para>
|
|
|
e935c3 |
|
|
|
e935c3 |
<tip><para>If you want to have your content localized inside
|
|
|
e935c3 |
CentOS Artwork Repository be sure to use source files supported
|
|
|
e935c3 |
either by @command{gettext} or @command{xml2po}
|
|
|
e935c3 |
programs.</para></tip>
|
|
|
e935c3 |
|
|
|
e935c3 |
<para>@xref{Directories trunk Locales}, for more
|
|
|
e935c3 |
information.</para>
|
|
|
e935c3 |
|
|
|
e935c3 |
</section>
|