summaryrefslogtreecommitdiffstats
path: root/src/engine/SCons/Tool/gettext.xml
blob: db76cc975df39518860caf115b9b7177bb8c83cb (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
<!--
__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>