comments, and alter the fuzzy flag.
   </para>

   <para>
    The PO files need not be completely filled in.  The software will
    automatically fall back to the original string if no translation
    (or an empty translation) is available.  It is no problem to
    submit incomplete translations for inclusions in the source tree;
    that gives room for other people to pick up your work.  However,
    you are encouraged to give priority to removing fuzzy entries
    after doing a merge.  Remember that fuzzy entries will not be
    installed; they only serve as reference for what might be the right
    translation.
   </para>

   <para>
    Here are some things to keep in mind while editing the
    translations:
    <itemizedlist>
     <listitem>
      <para>
       Make sure that if the original ends with a newline, the
       translation does, too.  Similarly for tabs, etc.
      </para>
     </listitem>

     <listitem>
      <para>
       If the original is a <function>printf</function> format string, the translation
       also needs to be.  The translation also needs to have the same
       format specifiers in the same order.  Sometimes the natural
       rules of the language make this impossible or at least awkward.
       In that case you can modify the format specifiers like this:
<programlisting>
msgstr "Die Datei %2$s hat %1$u Zeichen."
</programlisting>
       Then the first placeholder will actually use the second
       argument from the list.  The
       <literal><replaceable>digits</replaceable>$</literal> needs to
       follow the % immediately, before any other format manipulators.
       (This feature really exists in the <function>printf</function>
       family of functions.  You might not have heard of it before because
       there is little use for it outside of message
       internationalization.)
      </para>
     </listitem>

     <listitem>
      <para>
       If the original string contains a linguistic mistake, report
       that (or fix it yourself in the program source) and translate
       normally.  The corrected string can be merged in when the
       program sources have been updated.  If the original string
       contains a factual mistake, report that (or fix it yourself)
       and do not translate it.  Instead, you can mark the string with
       a comment in the PO file.
      </para>
     </listitem>

     <listitem>
      <para>
       Maintain the style and tone of the original string.
       Specifically, messages that are not sentences (<literal>cannot
       open file %s</literal>) should probably not start with a
       capital letter (if your language distinguishes letter case) or
       end with a period (if your language uses punctuation marks).
       It might help to read <xref linkend="error-style-guide"/>.
      </para>
     </listitem>

     <listitem>
      <para>
       If you don't know what a message means, or if it is ambiguous,
       ask on the developers' mailing list.  Chances are that English
       speaking end users might also not understand it or find it
       ambiguous, so it's best to improve the message.
      </para>
     </listitem>

    </itemizedlist>
   </para>
  </sect2>

 </sect1>


 <sect1 id="nls-programmer">
  <title>For the Programmer</title>

  <sect2 id="nls-mechanics">
   <title>Mechanics</title>

  <para>
   This section describes how to implement native language support in a
   program or library that is part of the
   <productname>PostgreSQL</productname> distribution.
   Currently, it only applies to C programs.
  </para>

  <procedure>
   <title>Adding NLS Support to a Program</title>

   <step>
    <para>
     Insert this code into the start-up sequence of the program:
<programlisting>
#ifdef ENABLE_NLS
#include &lt;locale.h&gt;
#endif

...

#ifdef ENABLE_NLS
setlocale(LC_ALL, "");
bindtextdomain("<replaceable>progname</replaceable>", LOCALEDIR);
textdomain("<replaceable>progname</replaceable>");
#endif
</programlisting>
     (The