[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gnulib translation handling documentation (was Re: Request for trans
From: |
Bruno Haible |
Subject: |
Re: gnulib translation handling documentation (was Re: Request for translations: man-db-2.5.1-pre1.pot) |
Date: |
Fri, 4 Jan 2008 01:15:15 +0100 (MET) |
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