2 $PostgreSQL: pgsql/doc/src/sgml/nls.sgml,v 1.9 2003/11/29 19:51:37 pgsql Exp $
8 <firstname>Peter</firstname>
9 <surname>Eisentraut</surname>
13 <title>Native Language Support</title>
15 <sect1 id="nls-translator">
16 <title>For the Translator</title>
19 <productname>PostgreSQL</>
20 programs (server and client) can issue their messages in
21 your favorite language -- if the messages have been translated.
22 Creating and maintaining translated message sets needs the help of
23 people who speak their own language well and want to contribute to
24 the <productname>PostgreSQL</> effort. You do not have to be a
26 to do this. This section explains how to help.
30 <title>Requirements</title>
33 We won't judge your language skills -- this section is about
34 software tools. Theoretically, you only need a text editor. But
35 this is only in the unlikely event that you do not want to try out
36 your translated messages. When you configure your source tree, be
37 sure to use the <option>--enable-nls</option> option. This will
38 also check for the <application>libintl</application> library and the
39 <filename>msgfmt</filename> program, which all end users will need
40 anyway. To try out your work, follow the applicable portions of
41 the installation instructions.
45 If you want to start a new translation effort or want to do a
46 message catalog merge (described later), you will need the
47 programs <filename>xgettext</filename> and
48 <filename>msgmerge</filename>, respectively, in a GNU-compatible
49 implementation. Later, we will try to arrange it so that if you
50 use a packaged source distribution, you won't need
51 <filename>xgettext</filename>. (From CVS, you will still need
52 it.) <application>GNU Gettext 0.10.36</application> or later is currently recommended.
56 Your local gettext implementation should come with its own
57 documentation. Some of that is probably duplicated in what
58 follows, but for additional details you should look there.
63 <title>Concepts</title>
66 The pairs of original (English) messages and their (possibly)
67 translated equivalents are kept in <firstterm>message
68 catalogs</firstterm>, one for each program (although related
69 programs can share a message catalog) and for each target
70 language. There are two file formats for message catalogs: The
71 first is the <quote>PO</quote> file (for Portable Object), which
72 is a plain text file with special syntax that translators edit.
73 The second is the <quote>MO</quote> file (for Machine Object),
74 which is a binary file generated from the respective PO file and
75 is used while the internationalized program is run. Translators
76 do not deal with MO files; in fact hardly anyone does.
80 The extension of the message catalog file is to no surprise either
81 <filename>.po</filename> or <filename>.mo</filename>. The base
82 name is either the name of the program it accompanies, or the
83 language the file is for, depending on the situation. This is a
84 bit confusing. Examples are <filename>psql.po</filename> (PO file
85 for psql) or <filename>fr.mo</filename> (MO file in French).
89 The file format of the PO files is illustrated here:
93 msgid "original string"
94 msgstr "translated string"
97 msgstr "another translated"
98 "string can be broken up like this"
102 The msgid's are extracted from the program source. (They need not
103 be, but this is the most common way.) The msgstr lines are
104 initially empty and are filled in with useful strings by the
105 translator. The strings can contain C-style escape characters and
106 can be continued across lines as illustrated. (The next line must
107 start at the beginning of the line.)
111 The # character introduces a comment. If whitespace immediately
112 follows the # character, then this is a comment maintained by the
113 translator. There may also be automatic comments, which have a
114 non-whitespace character immediately following the #. These are
115 maintained by the various tools that operate on the PO files and
116 are intended to aid the translator.
122 The #. style comments are extracted from the source file where the
123 message is used. Possibly the programmer has inserted information
124 for the translator, such as about expected alignment. The #:
125 comment indicates the exact location(s) where the message is used
126 in the source. The translator need not look at the program
127 source, but he can if there is doubt about the correct
128 translation. The #, comments contain flags that describe the
129 message in some way. There are currently two flags:
130 <literal>fuzzy</literal> is set if the message has possibly been
131 outdated because of changes in the program source. The translator
132 can then verify this and possibly remove the fuzzy flag. Note
133 that fuzzy messages are not made available to the end user. The
134 other flag is <literal>c-format</literal>, which indicates that
135 the message is a <function>printf</function>-style format
136 template. This means that the translation should also be a format
137 string with the same number and type of placeholders. There are
138 tools that can verify this, which key off the c-format flag.
143 <title>Creating and maintaining message catalogs</title>
146 OK, so how does one create a <quote>blank</quote> message
147 catalog? First, go into the directory that contains the program
148 whose messages you want to translate. If there is a file
149 <filename>nls.mk</filename>, then this program has been prepared
154 If there are already some <filename>.po</filename> files, then
155 someone has already done some translation work. The files are
156 named <filename><replaceable>language</replaceable>.po</filename>,
157 where <replaceable>language</replaceable> is the <ulink
158 url="http://lcweb.loc.gov/standards/iso639-2/englangn.html">ISO
159 639-1</ulink> two-letter language code (in lower case), e.g.,
160 <filename>fr.po</filename> for French. If there is really a need
161 for more than one translation effort per language then the files
163 <filename><replaceable>language</replaceable>_<replaceable>region</replaceable>.po</filename>
164 where <replaceable>region</replaceable> is the <ulink
165 url="http://www.din.de/gremien/nas/nabd/iso3166ma/codlstp1/en_listp1.html">ISO
166 3166-1</ulink> two-letter country code (in upper case), e.g.,
167 <filename>pt_BR.po</filename> for Portuguese in Brazil. If you
168 find the language you wanted you can just start working on that
173 If you need to start a new translation effort, then first run the
178 This will create a file
179 <filename><replaceable>progname</replaceable>.pot</filename>.
180 (<filename>.pot</filename> to distinguish it from PO files that
181 are <quote>in production</quote>. The <literal>T</> stands for
184 <filename><replaceable>language</replaceable>.po</filename> and
185 edit it. To make it known that the new language is available,
186 also edit the file <filename>nls.mk</filename> and add the
187 language (or language and country) code to the line that looks like:
189 AVAIL_LANGUAGES := de fr
191 (Other languages may appear, of course.)
195 As the underlying program or library changes, messages may be
196 changed or added by the programmers. In this case you do not need
197 to start from scratch. Instead, run the command
201 which will create a new blank message catalog file (the pot file
202 you started with) and will merge it with the existing PO files.
203 If the merge algorithm is not sure about a particular message it
204 marks it <quote>fuzzy</quote> as explained above. For the case
205 where something went really wrong, the old PO file is saved with a
206 <filename>.po.old</filename> extension.
211 <title>Editing the PO files</title>
214 The PO files can be edited with a regular text editor. The
215 translator should only change the area between the quotes after
216 the msgstr directive, may add comments and alter the fuzzy flag.
217 There is (unsurprisingly) a PO mode for Emacs, which I find quite
222 The PO files need not be completely filled in. The software will
223 automatically fall back to the original string if no translation
224 (or an empty translation) is available. It is no problem to
225 submit incomplete translations for inclusions in the source tree;
226 that gives room for other people to pick up your work. However,
227 you are encouraged to give priority to removing fuzzy entries
228 after doing a merge. Remember that fuzzy entries will not be
229 installed; they only serve as reference what might be the right
234 Here are some things to keep in mind while editing the
239 Make sure that if the original ends with a newline, the
240 translation does, too. Similarly for tabs, etc.
246 If the original is a <function>printf</> format string, the translation
247 also needs to be. The translation also needs to have the same
248 format specifiers in the same order. Sometimes the natural
249 rules of the language make this impossible or at least awkward.
250 In that case you can modify the format specifiers like this:
252 msgstr "Die Datei %2$s hat %1$u Zeichen."
254 Then the first placeholder will actually use the second
255 argument from the list. The
256 <literal><replaceable>digits</replaceable>$</literal> needs to
257 follow the % immediately, before any other format manipulators.
258 (This feature really exists in the <function>printf</function>
259 family of functions. You may not have heard of it before because
260 there is little use for it outside of message
261 internationalization.)
267 If the original string contains a linguistic mistake, report
268 that (or fix it yourself in the program source) and translate
269 normally. The corrected string can be merged in when the
270 program sources have been updated. If the original string
271 contains a factual mistake, report that (or fix it yourself)
272 and do not translate it. Instead, you may mark the string with
273 a comment in the PO file.
279 Maintain the style and tone of the original string.
280 Specifically, messages that are not sentences (<literal>cannot
281 open file %s</literal>) should probably not start with a
282 capital letter (if your language distinguishes letter case) or
283 end with a period (if your language uses punctuation marks).
284 It may help to read <xref linkend="error-style-guide">.
290 If you don't know what a message means, or if it is ambiguous,
291 ask on the developers' mailing list. Chances are that English
292 speaking end users might also not understand it or find it
293 ambiguous, so it's best to improve the message.
304 <sect1 id="nls-programmer">
305 <title>For the Programmer</title>
307 <sect2 id="nls-mechanics">
308 <title>Mechanics</title>
311 This section describes how to implement native language support in a
312 program or library that is part of the
313 <productname>PostgreSQL</> distribution.
314 Currently, it only applies to C programs.
318 <title>Adding NLS support to a program</title>
322 Insert this code into the start-up sequence of the program:
325 #include <locale.h>
331 setlocale(LC_ALL, "");
332 bindtextdomain("<replaceable>progname</replaceable>", LOCALEDIR);
333 textdomain("<replaceable>progname</replaceable>");
336 (The <replaceable>progname</replaceable> can actually be chosen
343 Wherever a message that is a candidate for translation is found,
344 a call to <function>gettext()</function> needs to be inserted. E.g.,
346 fprintf(stderr, "panic level %d\n", lvl);
350 fprintf(stderr, gettext("panic level %d\n"), lvl);
352 (<symbol>gettext</symbol> is defined as a no-op if no NLS is
357 This may tend to add a lot of clutter. One common shortcut is to use
359 #define _(x) gettext(x)
361 Another solution is feasible if the program does much of its
362 communication through one or a few functions, such as
363 <function>ereport()</function> in the backend. Then you make this
364 function call <function>gettext</function> internally on all
371 Add a file <filename>nls.mk</filename> in the directory with the
372 program sources. This file will be read as a makefile. The
373 following variable assignments need to be made here:
377 <term><varname>CATALOG_NAME</varname></term>
381 The program name, as provided in the
382 <function>textdomain()</function> call.
388 <term><varname>AVAIL_LANGUAGES</varname></term>
392 List of provided translations -- empty in the beginning.
398 <term><varname>GETTEXT_FILES</varname></term>
402 List of files that contain translatable strings, i.e., those
403 marked with <function>gettext</function> or an alternative
404 solution. Eventually, this will include nearly all source
405 files of the program. If this list gets too long you can
406 make the first <quote>file</quote> be a <literal>+</literal>
407 and the second word be a file that contains one file name per
414 <term><varname>GETTEXT_TRIGGERS</varname></term>
418 The tools that generate message catalogs for the translators
419 to work on need to know what function calls contain
420 translatable strings. By default, only
421 <function>gettext()</function> calls are known. If you used
422 <function>_</function> or other identifiers you need to list
423 them here. If the translatable string is not the first
424 argument, the item needs to be of the form
425 <literal>func:2</literal> (for the second argument).
436 The build system will automatically take care of building and
437 installing the message catalogs.
441 <sect2 id="nls-guidelines">
442 <title>Message-writing guidelines</title>
445 Here are some guidelines for writing messages that are easily
451 Do not construct sentences at run-time, like
453 printf("Files were %s.\n", flag ? "copied" : "removed");
455 The word order within the sentence may be different in other
456 languages. Also, even if you remember to call gettext() on each
457 fragment, the fragments may not translate well separately. It's
458 better to duplicate a little code so that each message to be
459 translated is a coherent whole. Only numbers, file names, and
460 such-like run-time variables should be inserted at runtime into
467 For similar reasons, this won't work:
469 printf("copied %d file%s", n, n!=1 ? "s" : "");
471 because it assumes how the plural is formed. If you figured you
472 could solve it like this
475 printf("copied 1 file");
477 printf("copied %d files", n):
479 then be disappointed. Some languages have more than two forms,
480 with some peculiar rules. We may have a solution for this in
481 the future, but for now the matter is best avoided altogether.
484 printf("number of copied files: %d", n);
491 If you want to communicate something to the translator, such as
492 about how a message is intended to line up with other output,
493 precede the occurrence of the string with a comment that starts
494 with <literal>translator</literal>, e.g.,
496 /* translator: This message is not what it seems to be. */
498 These comments are copied to the message catalog files so that
499 the translators can see them.