1 <!-- $Header: /cvsroot/pgsql/doc/src/sgml/nls.sgml,v 1.4 2002/03/22 19:20:15 petere Exp $ -->
6 <firstname>Peter</firstname>
7 <surname>Eisentraut</surname>
11 <title>Native Language Support</title>
13 <sect1 id="nls-translator">
14 <title>For the Translator</title>
17 <productname>PostgreSQL</>
18 programs (server and client) can issue their messages in
19 your favorite language -- if the messages have been translated.
20 Creating and maintaining translated message sets needs the help of
21 people who speak their own language well and want to contribute to
22 the <productname>PostgreSQL</> effort. You do not have to be a
24 to do this. This section explains how to help.
28 <title>Requirements</title>
31 We won't judge your language skills -- this section is about
32 software tools. Theoretically, you only need a text editor. But
33 this is only in the unlikely event that you do not want to try out
34 your translated messages. When you configure your source tree, be
35 sure to use the <option>--enable-nls</option> option. This will
36 also check for the libintl library and the
37 <filename>msgfmt</filename> program, which all end users will need
38 anyway. To try out your work, follow the applicable portions of
39 the installation instructions.
43 If you want to start a new translation effort or want to do a
44 message catalog merge (described later), you will need the
45 programs <filename>xgettext</filename> and
46 <filename>msgmerge</filename>, respectively, in a GNU-compatible
47 implementation. Later, we will try to arrange it so that if you
48 use a packaged source distribution, you won't need
49 <filename>xgettext</filename>. (From CVS, you will still need
50 it.) GNU gettext 0.10.36 or later is currently recommended.
54 Your local gettext implementation should come with its own
55 documentation. Some of that is probably duplicated in what
56 follows, but for additional details you should look there.
61 <title>Concepts</title>
64 The pairs of original (English) messages and their (possibly)
65 translated equivalents are kept in <firstterm>message
66 catalogs</firstterm>, one for each program (although related
67 programs can share a message catalog) and for each target
68 language. There are two file formats for message catalogs: The
69 first is the <quote>PO</quote> file (for Portable Object), which
70 is a plain text file with special syntax that translators edit.
71 The second is the <quote>MO</quote> file (for Machine Object),
72 which is a binary file generated from the respective PO file and
73 is used while the internationalized program is run. Translators
74 do not deal with MO files; in fact hardly anyone does.
78 The extension of the message catalog file is to no surprise either
79 <filename>.po</filename> or <filename>.mo</filename>. The base
80 name is either the name of the program it accompanies, or the
81 language the file is for, depending on the situation. This is a
82 bit confusing. Examples are <filename>psql.po</filename> (PO file
83 for psql) or <filename>fr.mo</filename> (MO file in French).
87 The file format of the PO files is illustrated here:
91 msgid "original string"
92 msgstr "translated string"
95 msgstr "another translated"
96 "string can be broken up like this"
100 The msgid's are extracted from the program source. (They need not
101 be, but this is the most common way.) The msgstr lines are
102 initially empty and are filled in with useful strings by the
103 translator. The strings can contain C-style escape characters and
104 can be continued across lines as illustrated. (The next line must
105 start at the beginning of the line.)
109 The # character introduces a comment. If whitespace immediately
110 follows the # character, then this is a comment maintained by the
111 translator. There may also be automatic comments, which have a
112 non-whitespace character immediately following the #. These are
113 maintained by the various tools that operate on the PO files and
114 are intended to aid the translator.
120 The #. style comments are extracted from the source file where the
121 message is used. Possibly the programmer has inserted information
122 for the translator, such as about expected alignment. The #:
123 comment indicates the exact location(s) where the message is used
124 in the source. The translator need not look at the program
125 source, but he can if there is doubt about the correct
126 translation. The #, comments contain flags that describe the
127 message in some way. There are currently two flags:
128 <literal>fuzzy</literal> is set if the message has possibly been
129 outdated because of changes in the program source. The translator
130 can then verify this and possibly remove the fuzzy flag. Note
131 that fuzzy messages are not made available to the end user. The
132 other flag is <literal>c-format</literal>, which indicates that
133 the message is a <function>printf</function>-style format
134 template. This means that the translation should also be a format
135 string with the same number and type of placeholders. There are
136 tools that can verify this, which key off the c-format flag.
141 <title>Creating and maintaining message catalogs</title>
144 OK, so how does one create a <quote>blank</quote> message
145 catalog? First, go into the directory that contains the program
146 whose messages you want to translate. If there is a file
147 <filename>nls.mk</filename>, then this program has been prepared
152 If there are already some <filename>.po</filename> files, then
153 someone has already done some translation work. The files are
154 named <filename><replaceable>language</replaceable>.po</filename>,
155 where <replaceable>language</replaceable> is the <ulink
156 url="http://lcweb.loc.gov/standards/iso639-2/englangn.html">ISO
157 639-1</ulink> two-letter language code (in lower case), e.g.,
158 <filename>fr.po</filename> for French. If there is really a need
159 for more than one translation effort per language then the files
161 <filename><replaceable>language</replaceable>_<replaceable>region</replaceable>.po</filename>
162 where <replaceable>region</replaceable> is the <ulink
163 url="http://www.din.de/gremien/nas/nabd/iso3166ma/codlstp1/en_listp1.html">ISO
164 3166-1</ulink> two-letter country code (in upper case), e.g.,
165 <filename>pt_BR.po</filename> for Portuguese in Brazil. If you
166 find the language you wanted you can just start working on that
171 If you need to start a new translation effort, then first run the
176 This will create a file
177 <filename><replaceable>progname</replaceable>.pot</filename>.
178 (<filename>.pot</filename> to distinguish it from PO files that
179 are <quote>in production</quote>. What does the T stand for? I
180 don't know.) Copy this file to
181 <filename><replaceable>language</replaceable>.po</filename> and
182 edit it. To make it known that the new language is available,
183 also edit the file <filename>nls.mk</filename> and add the
184 language (or language and country) code to the line that looks like:
186 AVAIL_LANGUAGES := de fr
188 (Other languages may appear, of course.)
192 As the underlying program or library changes, messages may be
193 changed or added by the programmers. In this case you do not need
194 to start from scratch. Instead, run the command
198 which will create a new blank message catalog file (the pot file
199 you started with) and will merge it with the existing PO files.
200 If the merge algorithm is not sure about a particular message it
201 marks it <quote>fuzzy</quote> as explained above. For the case
202 where something went really wrong, the old PO file is saved with a
203 <filename>.po.old</filename> extension.
208 <title>Editing the PO files</title>
211 The PO files can be edited with a regular text editor. The
212 translator should only change the area between the quotes after
213 the msgstr directive, may add comments and alter the fuzzy flag.
214 There is (unsurprisingly) a PO mode for Emacs, which I find quite
219 The PO files need not be completely filled in. The software will
220 automatically fall back to the original string if no translation
221 (or an empty translation) is available. It is no problem to
222 submit incomplete translations for inclusions in the source tree;
223 that gives room for other people to pick up your work. However,
224 you are encouraged to give priority to removing fuzzy entries
225 after doing a merge. Remember that fuzzy entries will not be
226 installed; they only serve as reference what might be the right
231 Here are some things to keep in mind while editing the
236 Make sure that if the original ends with a newline, the
237 translation does, too. Similarly for tabs, etc.
243 If the original is a printf format string, the translation also
244 needs to be. The translation also needs to have the same
245 format specifiers in the same order. Sometimes the natural
246 rules of the language make this impossible or at least awkward.
247 In this case you can use this format:
249 msgstr "Die Datei %2$s hat %1$u Zeichen."
251 Then the first placeholder will actually use the second
252 argument from the list. The
253 <literal><replaceable>digits</replaceable>$</literal> needs to
254 follow the % and come before any other format manipulators.
255 (This feature really exists in the <function>printf</function>
256 family of functions. You may not have heard of it because
257 there is little use for it outside of message
258 internationalization.)
264 If the original string contains a linguistic mistake, report
265 that (or fix it yourself in the program source) and translate
266 normally. The corrected string can be merged in when the
267 program sources have been updated. If the original string
268 contains a factual mistake, report that (or fix it yourself)
269 and do not translate it. Instead, you may mark the string with
270 a comment in the PO file.
276 Maintain the style and tone of the original string.
277 Specifically, messages that are not sentences (<literal>cannot
278 open file %s</literal>) should probably not start with a
279 capital letter (if your language distinguishes letter case) or
280 end with a period (if your language uses punctuation marks).
286 If you don't know what a message means, or if it is ambiguous,
287 ask on the developers' mailing list. Chances are that English
288 speaking end users might also not understand it or find it
289 ambiguous, so it's best to improve the message.
300 <sect1 id="nls-programmer">
301 <title>For the Programmer</title>
304 This section describes how to support native language support in a
305 program or library that is part of the
306 <productname>PostgreSQL</> distribution.
307 Currently, it only applies to C programs.
311 <title>Adding NLS support to a program</title>
315 Insert this code into the start-up sequence of the program:
318 #include <locale.h>
324 setlocale(LC_ALL, "");
325 bindtextdomain("<replaceable>progname</replaceable>", LOCALEDIR);
326 textdomain("<replaceable>progname</replaceable>");
329 (The <replaceable>progname</replaceable> can actually be chosen
336 Wherever a message that is a candidate for translation is found,
337 a call to <function>gettext()</function> needs to be inserted. E.g.,
339 fprintf(stderr, "panic level %d\n", lvl);
343 fprintf(stderr, gettext("panic level %d\n"), lvl);
345 (<symbol>gettext</symbol> is defined as a no-op if no NLS is
350 This may tend to add a lot of clutter. One common shortcut is to
352 #define _(x) gettext((x))
354 Another solution is feasible if the program does much of its
355 communication through one or a few functions, such as
356 <function>elog()</function> in the backend. Then you make this
357 function call <function>gettext</function> internally on all
364 Add a file <filename>nls.mk</filename> in the directory with the
365 program sources. This file will be read as a makefile. The
366 following variable assignments need to be made here:
370 <term>CATALOG_NAME</term>
374 The program name, as provided in the
375 <function>textdomain()</function> call.
381 <term>AVAIL_LANGUAGES</term>
385 List of provided translations -- empty in the beginning.
391 <term>GETTEXT_FILES</term>
395 List of files that contain translatable strings, i.e., those
396 marked with <function>gettext</function> or an alternative
397 solution. Eventually, this will include nearly all source
398 files of the program. If this list gets too long you can
399 make the first <quote>file</quote> be a <literal>+</literal>
400 and the second word be a file that contains one file name per
407 <term>GETTEXT_TRIGGERS</term>
411 The tools that generate message catalogs for the translators
412 to work on need to know what function calls contain
413 translatable strings. By default, only
414 <function>gettext()</function> calls are known. If you used
415 <function>_</function> or other identifiers you need to list
416 them here. If the translatable string is not the first
417 argument, the item needs to be of the form
418 <literal>func:2</literal> (for the second argument).
429 The build system will automatically take care of building and
430 installing the message catalogs.
434 To ease the translation of messages, here are some guidelines:
439 Do not construct sentences at run-time out of laziness, like
441 printf("Files where %s.\n", flag ? "copied" : "removed");
443 The word order within the sentence may be different in other
450 For similar reasons, this won't work:
452 printf("copied %d file%s", n, n!=1 ? "s" : "");
454 because it assumes how the plural is formed. If you figured you
455 could solve it like this
458 printf("copied 1 file");
460 printf("copied %d files", n):
462 then be disappointed. Some languages have more than two forms,
463 with some peculiar rules. We may have a solution for this in
464 the future, but for now this is best avoided altogether. You
467 printf("number of copied files: %d", n);
474 If you want to communicate something to the translator, such as
475 about how a message is intended to line up with other output,
476 precede the occurrence of the string with a comment that starts
477 with <literal>translator</literal>, e.g.,
479 /* translator: This message is not what it seems to be. */
481 These comments are copied to the message catalog files so that
482 the translators can see them.