1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
5 >Native Language Support</TITLE
8 CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK
10 HREF="mailto:pgsql-docs@postgresql.org"><LINK
12 TITLE="PostgreSQL 7.4.1 Documentation"
13 HREF="index.html"><LINK
16 HREF="internals.html"><LINK
18 TITLE="Error Message Style Guide"
19 HREF="error-style-guide.html"><LINK
21 TITLE="For the Programmer"
22 HREF="nls-programmer.html"><LINK
25 HREF="stylesheet.css"><META
27 CONTENT="2003-12-22T03:48:47"></HEAD
33 SUMMARY="Header navigation table"
43 >PostgreSQL 7.4.1 Documentation</TH
51 HREF="error-style-guide.html"
81 HREF="nls-programmer.html"
96 >Chapter 46. Native Language Support</H1
102 >Table of Contents</B
106 HREF="nls.html#NLS-TRANSLATOR"
107 >For the Translator</A
113 HREF="nls.html#AEN54156"
118 HREF="nls.html#AEN54168"
123 HREF="nls.html#AEN54186"
124 >Creating and maintaining message catalogs</A
128 HREF="nls.html#AEN54220"
129 >Editing the PO files</A
135 HREF="nls-programmer.html"
136 >For the Programmer</A
142 HREF="nls-programmer.html#NLS-MECHANICS"
147 HREF="nls-programmer.html#NLS-GUIDELINES"
148 >Message-writing guidelines</A
159 NAME="NLS-TRANSLATOR"
160 >46.1. For the Translator</A
167 programs (server and client) can issue their messages in
168 your favorite language -- if the messages have been translated.
169 Creating and maintaining translated message sets needs the help of
170 people who speak their own language well and want to contribute to
174 > effort. You do not have to be a
176 to do this. This section explains how to help.
184 >46.1.1. Requirements</A
187 > We won't judge your language skills -- this section is about
188 software tools. Theoretically, you only need a text editor. But
189 this is only in the unlikely event that you do not want to try out
190 your translated messages. When you configure your source tree, be
195 also check for the <SPAN
202 > program, which all end users will need
203 anyway. To try out your work, follow the applicable portions of
204 the installation instructions.
207 > If you want to start a new translation effort or want to do a
208 message catalog merge (described later), you will need the
216 >, respectively, in a GNU-compatible
217 implementation. Later, we will try to arrange it so that if you
218 use a packaged source distribution, you won't need
222 >. (From CVS, you will still need
225 >GNU Gettext 0.10.36</SPAN
226 > or later is currently recommended.
229 > Your local gettext implementation should come with its own
230 documentation. Some of that is probably duplicated in what
231 follows, but for additional details you should look there.
243 > The pairs of original (English) messages and their (possibly)
244 translated equivalents are kept in <I
248 >, one for each program (although related
249 programs can share a message catalog) and for each target
250 language. There are two file formats for message catalogs: The
254 > file (for Portable Object), which
255 is a plain text file with special syntax that translators edit.
256 The second is the <SPAN
259 > file (for Machine Object),
260 which is a binary file generated from the respective PO file and
261 is used while the internationalized program is run. Translators
262 do not deal with MO files; in fact hardly anyone does.
265 > The extension of the message catalog file is to no surprise either
273 name is either the name of the program it accompanies, or the
274 language the file is for, depending on the situation. This is a
275 bit confusing. Examples are <TT
282 > (MO file in French).
285 > The file format of the PO files is illustrated here:
287 CLASS="PROGRAMLISTING"
290 msgid "original string"
291 msgstr "translated string"
293 msgid "more original"
294 msgstr "another translated"
295 "string can be broken up like this"
299 The msgid's are extracted from the program source. (They need not
300 be, but this is the most common way.) The msgstr lines are
301 initially empty and are filled in with useful strings by the
302 translator. The strings can contain C-style escape characters and
303 can be continued across lines as illustrated. (The next line must
304 start at the beginning of the line.)
307 > The # character introduces a comment. If whitespace immediately
308 follows the # character, then this is a comment maintained by the
309 translator. There may also be automatic comments, which have a
310 non-whitespace character immediately following the #. These are
311 maintained by the various tools that operate on the PO files and
312 are intended to aid the translator.
314 CLASS="PROGRAMLISTING"
315 >#. automatic comment
319 The #. style comments are extracted from the source file where the
320 message is used. Possibly the programmer has inserted information
321 for the translator, such as about expected alignment. The #:
322 comment indicates the exact location(s) where the message is used
323 in the source. The translator need not look at the program
324 source, but he can if there is doubt about the correct
325 translation. The #, comments contain flags that describe the
326 message in some way. There are currently two flags:
330 > is set if the message has possibly been
331 outdated because of changes in the program source. The translator
332 can then verify this and possibly remove the fuzzy flag. Note
333 that fuzzy messages are not made available to the end user. The
337 >, which indicates that
338 the message is a <CODE
342 template. This means that the translation should also be a format
343 string with the same number and type of placeholders. There are
344 tools that can verify this, which key off the c-format flag.
353 >46.1.3. Creating and maintaining message catalogs</A
356 > OK, so how does one create a <SPAN
360 catalog? First, go into the directory that contains the program
361 whose messages you want to translate. If there is a file
365 >, then this program has been prepared
369 > If there are already some <TT
373 someone has already done some translation work. The files are
385 HREF="http://lcweb.loc.gov/standards/iso639-2/englangn.html"
389 > two-letter language code (in lower case), e.g.,
393 > for French. If there is really a need
394 for more than one translation effort per language then the files
410 HREF="http://www.din.de/gremien/nas/nabd/iso3166ma/codlstp1/en_listp1.html"
414 > two-letter country code (in upper case), e.g.,
418 > for Portuguese in Brazil. If you
419 find the language you wanted you can just start working on that
423 > If you need to start a new translation effort, then first run the
426 CLASS="PROGRAMLISTING"
429 This will create a file
440 > to distinguish it from PO files that
443 >"in production"</SPAN
460 edit it. To make it known that the new language is available,
461 also edit the file <TT
465 language (or language and country) code to the line that looks like:
467 CLASS="PROGRAMLISTING"
468 >AVAIL_LANGUAGES := de fr</PRE
470 (Other languages may appear, of course.)
473 > As the underlying program or library changes, messages may be
474 changed or added by the programmers. In this case you do not need
475 to start from scratch. Instead, run the command
477 CLASS="PROGRAMLISTING"
478 >gmake update-po</PRE
480 which will create a new blank message catalog file (the pot file
481 you started with) and will merge it with the existing PO files.
482 If the merge algorithm is not sure about a particular message it
486 > as explained above. For the case
487 where something went really wrong, the old PO file is saved with a
500 >46.1.4. Editing the PO files</A
503 > The PO files can be edited with a regular text editor. The
504 translator should only change the area between the quotes after
505 the msgstr directive, may add comments and alter the fuzzy flag.
506 There is (unsurprisingly) a PO mode for Emacs, which I find quite
510 > The PO files need not be completely filled in. The software will
511 automatically fall back to the original string if no translation
512 (or an empty translation) is available. It is no problem to
513 submit incomplete translations for inclusions in the source tree;
514 that gives room for other people to pick up your work. However,
515 you are encouraged to give priority to removing fuzzy entries
516 after doing a merge. Remember that fuzzy entries will not be
517 installed; they only serve as reference what might be the right
521 > Here are some things to keep in mind while editing the
528 > Make sure that if the original ends with a newline, the
529 translation does, too. Similarly for tabs, etc.
534 > If the original is a <CODE
537 > format string, the translation
538 also needs to be. The translation also needs to have the same
539 format specifiers in the same order. Sometimes the natural
540 rules of the language make this impossible or at least awkward.
541 In that case you can modify the format specifiers like this:
543 CLASS="PROGRAMLISTING"
544 >msgstr "Die Datei %2$s hat %1$u Zeichen."</PRE
546 Then the first placeholder will actually use the second
547 argument from the list. The
555 follow the % immediately, before any other format manipulators.
556 (This feature really exists in the <CODE
560 family of functions. You may not have heard of it before because
561 there is little use for it outside of message
562 internationalization.)
567 > If the original string contains a linguistic mistake, report
568 that (or fix it yourself in the program source) and translate
569 normally. The corrected string can be merged in when the
570 program sources have been updated. If the original string
571 contains a factual mistake, report that (or fix it yourself)
572 and do not translate it. Instead, you may mark the string with
573 a comment in the PO file.
578 > Maintain the style and tone of the original string.
579 Specifically, messages that are not sentences (<TT
583 >) should probably not start with a
584 capital letter (if your language distinguishes letter case) or
585 end with a period (if your language uses punctuation marks).
586 It may help to read <A
587 HREF="error-style-guide.html"
594 > If you don't know what a message means, or if it is ambiguous,
595 ask on the developers' mailing list. Chances are that English
596 speaking end users might also not understand it or find it
597 ambiguous, so it's best to improve the message.
611 SUMMARY="Footer navigation table"
622 HREF="error-style-guide.html"
640 HREF="nls-programmer.html"
650 >Error Message Style Guide</TD
656 HREF="internals.html"
664 >For the Programmer</TD