Re: gnulib translation handling documentation (was Re: Request for translations: man-db-2.5.1-pre1.pot)

[Bruno Haible]

Hello Colin,

Colin Watson wrote:
> I decided to write some documentation for this (diff attached), which I
> hope you can review and add to Gnulib.

Many thanks for this! I changed the node title and a few other details and 
committed
the change as appended.

> If you require
> a copyright assignment for this, I can certainly do that, though there
> may be a short delay in getting a signature from my employer (I work
> from home so it would have to wait until I'm in the office later this
> month).

Certainly a copyright assignment from you for gnulib is desirable; especially
considering the amount of good stuff that you are doing in all directions.

[Karl please correct me if I'm wrong, IANAL.] Whether you need a signature
from your employer depends on your employment contract (there are
employment contracts that say that you assign copyrights for all your works
to your employer; other contracts say that you assign the copyright for all
the works related to the employment or for which you are paid for) and
whether you have a clear distinction between working times and spare
time when working at home. If in doubt, better get the signature from the
employer (shouldn't be hard if it's Canonical).

Bruno

2008-01-03  Colin Watson  <address@hidden>
            Bruno Haible  <address@hidden>

        * doc/gnulib-tool.texi (Localization): New section.

diff --git a/doc/gnulib-tool.texi b/doc/gnulib-tool.texi
index ce510cb..9d9ec56 100644
--- a/doc/gnulib-tool.texi
+++ b/doc/gnulib-tool.texi
@@ -1,7 +1,7 @@
 @node Invoking gnulib-tool
 @chapter Invoking gnulib-tool
 
address@hidden Copyright (C) 2005, 2006, 2007 Free Software Foundation, Inc.
address@hidden Copyright (C) 2005-2008 Free Software Foundation, Inc.
 
 @c Permission is granted to copy, distribute and/or modify this document
 @c under the terms of the GNU Free Documentation License, Version 1.2 or
@@ -32,6 +32,7 @@ a real run without changing anything.
 * Modified imports::            Changing the import specification.
 * Simple update::               Tracking Gnulib development.
 * Source changes::              Impact of Gnulib on your source files.
+* Localization::                Handling Gnulib's own message translations.
 * VCS Issues::                  Integration with Version Control Systems.
 @end menu
 
@@ -370,6 +371,80 @@ used to set system dependent flags (such as 
@code{_GNU_SOURCE} on GNU systems),
 and these flags have no effect after any system header file has been included.
 
 
address@hidden Localization
address@hidden Handling Gnulib's own message translations
+
+Gnulib provides some functions that emit translatable messages using GNU
address@hidden  The @samp{gnulib} domain at the
address@hidden://translationproject.org/, Translation Project} collects
+translations of these messages, which you should incorporate into your
+own programs.
+
+There are two basic ways to achieve this.  The first, and older, method
+is to list all the source files you use from Gnulib in your own
address@hidden/POTFILES.in} file.  This will cause all the relevant
+translatable strings to be included in your POT file.  When you send
+this POT file to the Translation Project, translators will normally fill
+in the translations of the Gnulib strings from their ``translation
+memory'', and send you back updated PO files.
+
+However, this process is error-prone: you might forget to list some
+source files, or the translator might not be using a translation memory
+and provide a different translation than another translator, or the
+translation might not be kept in sync between Gnulib and your package.
+It is also slow and causes substantial extra work, because a human
+translator must be in the loop for each language and you will need to
+incorporate their work on request.
+
+For these reasons, a new method was designed and is now recommended.  If
+you pass the @address@hidden and @address@hidden
+options to @code{gnulib-tool}, then @code{gnulib-tool} will create a
+separate directory with its own @file{POTFILES.in}, and fetch current
+translations directly from the Translation Project (using
address@hidden or @command{wget}, whichever is available).
+The POT file in this directory will be called
address@hidden@var{domain}-gnulib.pot}, depending on the @var{domain} you gave 
to the
address@hidden option (typically the same as the package name).
+This causes these translations to reside in a separate message domain,
+so that they do not clash either with the translations for the main part
+of your package nor with those of other packages on the system that use
+possibly different versions of Gnulib.
+When you use these options, the functions in Gnulib are built
+in such a way that they will always use this domain regardless of the
+default domain set by @code{textdomain}.
+
+In order to use this method, you must -- in each program that might use
+Gnulib code -- add an extra line to the part of the program that
+initializes locale-dependent behavior.  Where you would normally write
+something like:
+
address@hidden
address@hidden
+  setlocale (LC_ALL, "");
+  bindtextdomain (PACKAGE, LOCALEDIR);
+  textdomain (PACKAGE);
address@hidden group
address@hidden example
+
address@hidden
+you should add an additional @code{bindtextdomain} call to inform
+gettext of where the MO files for the extra message domain may be found:
+
address@hidden
address@hidden
+  bindtextdomain (PACKAGE "-gnulib", LOCALEDIR);
address@hidden group
address@hidden example
+
+(This example assumes that the @var{domain} that you specified
+to @code{gnulib-tool} is the same as the value of the @code{PACKAGE}
+preprocessor macro.)
+
+Since you do not change the @code{textdomain} call, the default message
+domain for your program remains the same and your own use of @code{gettext}
+functions will not be affected.
+
+
 @node VCS Issues
 @section Issues with Version Control Systems

gnulib-patch2
Description: Binary data