Home Explore Blog CI



postgresql

7th chunk of `doc/src/sgml/nls.sgml`
f2efe2caed7e01fab449510724b3a44ab9bad502cc70f32b0000000100000dae
   <itemizedlist>
    <listitem>
     <para>
      Do not construct sentences at run-time, like:
<programlisting>
printf("Files were %s.\n", flag ? "copied" : "removed");
</programlisting>
      The word order within the sentence might be different in other
      languages.  Also, even if you remember to call <function>gettext()</function> on
      each fragment, the fragments might not translate well separately.  It's
      better to duplicate a little code so that each message to be
      translated is a coherent whole.  Only numbers, file names, and
      such-like run-time variables should be inserted at run time into
      a message text.
     </para>
    </listitem>

    <listitem>
     <para>
      For similar reasons, this won't work:
<programlisting>
printf("copied %d file%s", n, n!=1 ? "s" : "");
</programlisting>
      because it assumes how the plural is formed.  If you figured you
      could solve it like this:
<programlisting>
if (n==1)
    printf("copied 1 file");
else
    printf("copied %d files", n):
</programlisting>
      then be disappointed.  Some languages have more than two forms,
      with some peculiar rules.  It's often best to design the message
      to avoid the issue altogether, for instance like this:
<programlisting>
printf("number of copied files: %d", n);
</programlisting>
     </para>

     <para>
      If you really want to construct a properly pluralized message,
      there is support for this, but it's a bit awkward.  When generating
      a primary or detail error message in <function>ereport()</function>, you can
      write something like this:
<programlisting>
errmsg_plural("copied %d file",
              "copied %d files",
              n,
              n)
</programlisting>
      The first argument is the format string appropriate for English
      singular form, the second is the format string appropriate for
      English plural form, and the third is the integer control value
      that determines which plural form to use.  Subsequent arguments
      are formatted per the format string as usual.  (Normally, the
      pluralization control value will also be one of the values to be
      formatted, so it has to be written twice.)  In English it only
      matters whether <replaceable>n</replaceable> is 1 or not 1, but in other
      languages there can be many different plural forms.  The translator
      sees the two English forms as a group and has the opportunity to
      supply multiple substitute strings, with the appropriate one being
      selected based on the run-time value of <replaceable>n</replaceable>.
     </para>

     <para>
      If you need to pluralize a message that isn't going directly to an
      <function>errmsg</function> or <function>errdetail</function> report, you have to use
      the underlying function <function>ngettext</function>.  See the gettext
      documentation.
     </para>
    </listitem>

    <listitem>
     <para>
      If you want to communicate something to the translator, such as
      about how a message is intended to line up with other output,
      precede the occurrence of the string with a comment that starts
      with <literal>translator</literal>, e.g.:
<programlisting>
/* translator: This message is not what it seems to be. */
</programlisting>
      These comments are copied to the message catalog files so that
      the translators can see them.
     </para>
    </listitem>
   </itemizedlist>
  </para>
  </sect2>
 </sect1>

</chapter>

Title: Message Translation Best Practices
Summary
This section outlines guidelines for writing translatable messages, including avoiding runtime sentence construction, handling plural forms, and providing context for translators, to ensure that messages are properly translated and displayed in different languages.