path: root/src/engine/SCons/Tool/gettext.xml

<!--
__TOOL_COPYRIGHT__

This file is processed by the bin/SConsDoc.py module.
See its __doc__ string for a discussion of the format.
-->
<tool name="gettext">
<summary>
This is actually a toolset, which supports internationalization and
localization of sofware being constructed with SCons. The toolset loads
following tools:

<itemizedlist mark='opencircle'>
  <listitem><para>
    &t-link-xgettext; - to extract internationalized messages from source code to 
    <literal>POT</literal> file(s),
  </para></listitem>
  <listitem><para>
    &t-link-msginit; - may be optionally used to initialize <literal>PO</literal>
    files,
  </para></listitem>
  <listitem><para>
    &t-link-msgmerge; - to update <literal>PO</literal> files, that already contain
    translated messages,</para></listitem>
  <listitem><para>
    &t-link-msgfmt; - to compile textual <literal>PO</literal> file to binary
    installable <literal>MO</literal> file.
  </para></listitem>
</itemizedlist>

When you enable &t-gettext;, it internally loads all abovementioned tools,
so you're encouraged to see their individual documentation.

Each of the above tools provides its own builder(s) which may be used to
perform particular activities related to software internationalization. You
may be however interested in <emphasis>top-level</emphasis> builders
&b-Translate; and &b-InstallMOFiles; described few paragraphs later.

To use &t-gettext; tools, copy <filename>SConsToolGettext</filename>
folder to your <filename>site_scons/</filename> and simply add
<literal>'gettext'</literal> tool to your environment:
<example>
  env = Environment( tools = ['default', 'gettext'] )
</example>
</summary>
<sets>
</sets>
<uses>
<!-- PLATFORM -->
</uses>
</tool>

<builder name="Translate">
<summary>
This pseudo-builder belongs to &t-link-gettext; toolset. The builder extracts
internationalized messages from source files, updates <literal>POT</literal>
template (if necessary) and then updates <literal>PO</literal> translations (if
necessary). If &cv-link-POAUTOINIT; is set, missing <literal>PO</literal> files
will be automatically created (i.e. without translator person intervention).
The variables &cv-link-LINGUAS_FILE; and &cv-link-POTDOMAIN; are taken into
acount too. All other construction variables used by &b-link-POTUpdate;, and
&b-link-POUpdate; work here too.

<emphasis>Example 1</emphasis>.
The simplest way is to specify input files and output languages inline in
a SCons script when invoking &b-Translate;
<example>
# SConscript in 'po/' directory
env = Environment( tools = ["default", "gettext"] )
env['POAUTOINIT'] = 1
env.Translate(['en','pl'], ['../a.cpp','../b.cpp']) 
</example>

<emphasis>Example 2</emphasis>.
If you wish, you may also stick to conventional style known from
<productname>autotools</productname>, i.e. using
<filename>POTFILES.in</filename> and <filename>LINGUAS</filename> files
<example>
# LINGUAS
en pl 
#end
</example>

<example>
# POTFILES.in
a.cpp
b.cpp
# end
</example>

<example>
# SConscript
env = Environment( tools = ["default", "gettext"] )
env['POAUTOINIT'] = 1
env['XGETTEXTPATH'] = ['../']
env.Translate(LINGUAS_FILE = 1, XGETTEXTFROM = 'POTFILES.in') 
</example>

The last approach is perhaps the recommended one. It allows easily split
internationalization/localization onto separate SCons scripts, where a script
in source tree is responsible for translations (from sources to
<literal>PO</literal> files) and script(s) under variant directories are
responsible for compilation of <literal>PO</literal> to <literal>MO</literal>
files to and for installation of <literal>MO</literal> files. The "gluing
factor" synchronizing these two scripts is then the content of
<filename>LINGUAS</filename> file.  Note, that the updated
<literal>POT</literal> and <literal>PO</literal> files are usually going to be
committed back to the repository, so they must be updated within the source
directory (and not in variant directories). Additionaly, the file listing of
<filename>po/</filename> directory contains <filename>LINGUAS</filename> file,
so the source tree looks familiar to translators, and they may work with the
project in their usual way.

<emphasis>Example 3</emphasis>.
Let's prepare a development tree as below
<example>
 project/
  + SConstruct
  + build/        
  + src/
      + po/
          + SConscript
          + SConscript.i18n
          + POTFILES.in
          + LINGUAS
</example>
with <filename>build</filename> being variant directory. Write the top-level
<filename>SConstruct</filename> script as follows
<example>
  # SConstruct
  env = Environment( tools = ["default", "gettext"] )
  VariantDir('build', 'src', duplicate = 0)
  env['POAUTOINIT'] = 1
  SConscript('src/po/SConscript.i18n', exports = 'env')
  SConscript('build/po/SConscript', exports = 'env')
</example>
the <filename>src/po/SConscript.i18n</filename> as
<example>
  # src/po/SConscript.i18n
  Import('env')
  env.Translate(LINGUAS_FILE=1, XGETTEXTFROM='POTFILES.in', XGETTEXTPATH=['../'])
</example>
and the <filename>src/po/SConscript</filename>
<example>
  # src/po/SConscript
  Import('env')
  env.MOFiles(LINGUAS_FILE = 1)
</example>
Such setup produces <literal>POT</literal> and <literal>PO</literal> files
under source tree in <filename>src/po/</filename> and binary
<literal>MO</literal> files under variant tree in
<filename>build/po/</filename>. This way the <literal>POT</literal> and
<literal>PO</literal> files are separated from other output files, which must
not be committed back to source repositories (e.g. <literal>MO</literal>
files).

<note><para>In above example, the <literal>PO</literal> files are not updated,
nor created automatically when you issue <command>scons '.'</command> command.
The files must be updated (created) by hand via <command>scons
po-update</command> and then <literal>MO</literal> files can be compiled by
running <command>scons '.'</command>.</para></note>

</summary>
</builder>

<!--
<builder name="InstallMOFiles">
<summary>
This is not implemented yet.
Install <literal>MO</literal> catalog files into system directories.

The parameters are:
- <literal>localedir</literal> - system locale base directory, e.g. <literal>/usr/share/locale</literal>
- <literal>source</literal> - list of <literal>MO</literal> files to install
- <literal>domain</literal> - domain, i.e. your package/program name
- <literal>category</literal> - locale category, e.g. <literal>LC_MESSAGES</literal>

The installation goes in standard way. For example, if
<literal>localedir="/usr/share/locale"</literal>, <literal>domain="program1"</literal>,
<literal>category="LC_MESSAGES"</literal>,  <literal>sources=['en.mo', 'fr.mo']</literal>, then the
installation goes as follows:
<example>
en.mo ===&gt; /usr/share/locale/en/LC_MESSAGES/program1.mo
fr.mo ===&gt; /usr/share/locale/fr/LC_MESSAGES/program1.mo
</example>
The <literal>InstallMOFiles</literal> builder uses internaly <literal>InstallAs</literal> builder, so all
the features of <literal>InstallAs</literal> (e.g. <literal>xxinstall-sandbox</literal>) should work.
<example>
TODO: 
</example>
</summary>
</builder>
-->

<cvar name="POTDOMAIN">
<summary>
The &cv-POTDOMAIN; defines default domain, used to generate
<literal>POT</literal> filename as <filename>&cv-POTDOMAIN;.pot</filename> when
no <literal>POT</literal> file name is provided by the user. This applies to
&b-link-POTUpdate;, &b-link-POInit; and &b-link-POUpdate; builders (and
builders, that use them, e.g. &b-Translate;). Normally (if &cv-POTDOMAIN; is
not defined), the builders use <filename>messages.pot</filename> as default
<literal>POT</literal> file name.
</summary>
</cvar>

<cvar name="POAUTOINIT">
<summary>
The &cv-POAUTOINIT; variable, if set to <literal>True</literal> (on non-zero
numeric value), let the SConsToolGettext to automatically initialize
<emphasis>missing</emphasis> <literal>PO</literal> files with
<command>msginit(1)</command>.  This applies to both,
&b-link-POInit; and &b-link-POUpdate; builders (and others that use any of
them).
</summary>
</cvar>

<cvar name="LINGUAS_FILE">
<summary>
The &cv-LINGUAS_FILE; defines file(s) containing list of additional linguas
to be processed by &b-link-POInit;, &b-link-POUpdate; or &b-link-MOFiles;
builders. It also affects &b-link-Translate; builder. If the variable contains
a string, it defines name of the list file. The &cv-LINGUAS_FILE; may be a
list of file names as well. If &cv-LINGUAS_FILE; is set to
<literal>True</literal> (or non-zero numeric value), the list will be read from
default file named
<filename>LINGUAS</filename>.

</summary>
</cvar>

<scons_function name="Dummy">
<arguments>
TODO: Try to remove me.
</arguments>
<summary>
TODO: Try to remove me.
</summary>
</scons_function>