/ - Diff - | gvSIG desktop 1 - gvSIG

Revision 7940

     @echo off
     color F0
     PROMPT=$g
     echo Extraemos las calves de los ficheros cpp...
     gettext\bin\xgettext -C -n -k_ -o launcher.pot launcher.cpp statusdialog.cpp
     echo Fusionando con Idioma da...
     IF NOT EXIST da\launcher.po copy launcher.pot da\launcher.po
     gettext\bin\msgmerge.exe da\launcher.po launcher.pot -o da\launcher.po
     echo Fusionando con Idioma de...
     IF NOT EXIST de\launcher.po copy launcher.pot de\launcher.po
     gettext\bin\msgmerge.exe de\launcher.po launcher.pot -o de\launcher.po
     echo Fusionando con Idioma es...
     IF NOT EXIST es\launcher.po copy launcher.pot es\launcher.po
     gettext\bin\msgmerge.exe es\launcher.po launcher.pot -o es\launcher.po
     echo Fusionando con Idioma fr...
     IF NOT EXIST fr\launcher.po copy launcher.pot fr\launcher.po
     gettext\bin\msgmerge.exe fr\launcher.po launcher.pot -o fr\launcher.po
     echo Fusionando con Idioma it...
     IF NOT EXIST it\launcher.po copy launcher.pot it\launcher.po
     gettext\bin\msgmerge.exe it\launcher.po launcher.pot -o it\launcher.po
     echo Fusionando con Idioma nl...
     IF NOT EXIST nl\launcher.po copy launcher.pot nl\launcher.po
     gettext\bin\msgmerge.exe nl\launcher.po launcher.pot -o nl\launcher.po
     echo Fusionando con Idioma pt-BR...
     IF NOT EXIST pt-BR\launcher.po copy launcher.pot pt-BR\launcher.po
     gettext\bin\msgmerge.exe pt-BR\launcher.po launcher.pot -o pt-BR\launcher.po
     echo Termiando.

     <HTML>
     <HEAD>
     <!-- This HTML file has been created by texi2html 1.52a
          from autosprintf.texi on 12 June 2003 -->
     <TITLE>GNU autosprintf</TITLE>
     </HEAD>
     <BODY>
     <H1>GNU autosprintf, version 1.0</H1>
     <H2>Formatted Output to Strings in C++</H2>
     <ADDRESS>Bruno Haible</ADDRESS>
     <P>
     <P><HR><P>
     <H1>Table of Contents</H1>
     <UL>
     <LI><A NAME="TOC1" HREF="autosprintf.html#SEC1">1  Introduction</A>
     <LI><A NAME="TOC2" HREF="autosprintf.html#SEC2">2  The <CODE>autosprintf</CODE> class</A>
     <LI><A NAME="TOC3" HREF="autosprintf.html#SEC3">3  Using <CODE>autosprintf</CODE> in own programs</A>
     </UL>
     <P><HR><P>
     <H1><A NAME="SEC1" HREF="autosprintf.html#TOC1">1  Introduction</A></H1>
     <P>
     This package makes the C formatted output routines (<CODE>fprintf</CODE> et al.)
     usable in C++ programs, for use with the <CODE>&#60;string&#62;</CODE> strings and the
     <CODE>&#60;iostream&#62;</CODE> streams.
     </P>
     <P>
     It allows to write code like
     </P>
     <PRE>
     cerr &#60;&#60; autosprintf ("syntax error in %s:%d: %s", filename, line, errstring);
     </PRE>
     <P>
     instead of
     </P>
     <PRE>
     cerr &#60;&#60; "syntax error in " &#60;&#60; filename &#60;&#60; ":" &#60;&#60; line &#60;&#60; ": " &#60;&#60; errstring;
     </PRE>
     <P>
     The benefits of the autosprintf syntax are:
     </P>
     <UL>
     <LI>
     It reuses the standard POSIX printf facility. Easy migration from C to C++.
     <LI>
     English sentences are kept together.
     <LI>
     It makes internationalization possible. Internationalization requires format
     strings, because in some cases the translator needs to change the order of a
     sentence, and more generally it is easier for the translator to work with a
     single string for a sentence than with multiple string pieces.
     <LI>
     It reduces the risk of programming errors due to forgotten state in the
     output stream (e.g. <CODE>cout &#60;&#60; hex;</CODE> not followed by <CODE>cout &#60;&#60; dec;</CODE>).
     </UL>
     <H1><A NAME="SEC2" HREF="autosprintf.html#TOC2">2  The <CODE>autosprintf</CODE> class</A></H1>
     <P>
     An instance of class <CODE>autosprintf</CODE> just contains a string with the
     formatted output result. Such an instance is usually allocated as an
     automatic storage variable, i.e. on the stack, not with <CODE>new</CODE> on the
     heap.
     </P>
     <P>
     The constructor <CODE>autosprintf (const char *format, ...)</CODE> takes a format
     string and additional arguments, like the C function <CODE>printf</CODE>.
     </P>
     <P>
     Conversions to <CODE>char *</CODE> and <CODE>std::string</CODE> are defined that return
     the encapsulated string.
     </P>
     <P>
     The destructor <CODE>~autosprintf ()</CODE> destroys the encapsulated string.
     </P>
     <P>
     An <CODE>operator &#60;&#60;</CODE> is provided that outputs the encapsulated string to the
     given <CODE>ostream</CODE>.
     </P>
     <H1><A NAME="SEC3" HREF="autosprintf.html#TOC3">3  Using <CODE>autosprintf</CODE> in own programs</A></H1>
     <P>
     To use the <CODE>autosprintf</CODE> class in your programs, you need to add
     </P>
     <PRE>
     #include "autosprintf.h"
     using gnu::autosprintf;
     </PRE>
     <P>
     to your source code.
     The include file defines the class <CODE>autosprintf</CODE>, in a namespace called
     <CODE>gnu</CODE>. The <SAMP>`using&acute;</SAMP> statement makes it possible to use the class
     without the (otherwise natural) <CODE>gnu::</CODE> prefix.
     </P>
     <P>
     When linking your program, you need to link with <CODE>libasprintf</CODE>, because
     that's where the class is defined. In projects using GNU <CODE>autoconf</CODE>,
     this means adding <SAMP>`AC_LIB_LINKFLAGS([asprintf])&acute;</SAMP> to <CODE>configure.in</CODE>
     or <CODE>configure.ac</CODE>, and using the @LIBASPRINTF@ Makefile variable that
     it provides.
     </P>
     <P><HR><P>
     This document was generated on 12 June 2003 using the
     <A HREF="http://wwwinfo.cern.ch/dis/texi2html/">texi2html</A>
     translator version 1.52a.</P>
     </BODY>
     </HTML>

     <HTML>
     <HEAD>
     <!-- This HTML file has been created by texi2html 1.52a
          from gettext.texi on 9 December 2003 -->
     <TITLE>GNU gettext utilities - 9  The User's View</TITLE>
     </HEAD>
     <BODY>
     Go to the <A HREF="gettext_1.html">first</A>, <A HREF="gettext_8.html">previous</A>, <A HREF="gettext_10.html">next</A>, <A HREF="gettext_22.html">last</A> section, <A HREF="gettext_toc.html">table of contents</A>.
     <P><HR><P>
     <H1><A NAME="SEC153" HREF="gettext_toc.html#TOC153">9  The User's View</A></H1>
     <P>
     When GNU <CODE>gettext</CODE> will truly have reached its goal, average users
     should feel some kind of astonished pleasure, seeing the effect of
     that strange kind of magic that just makes their own native language
     appear everywhere on their screens.  As for naive users, they would
     ideally have no special pleasure about it, merely taking their own
     language for <EM>granted</EM>, and becoming rather unhappy otherwise.
     </P>
     <P>
     So, let's try to describe here how we would like the magic to operate,
     as we want the users' view to be the simplest, among all ways one
     could look at GNU <CODE>gettext</CODE>.  All other software engineers:
     programmers, translators, maintainers, should work together in such a
     way that the magic becomes possible.  This is a long and progressive
     undertaking, and information is available about the progress of the
     Translation Project.
     </P>
     <P>
     When a package is distributed, there are two kinds of users:
     <EM>installers</EM> who fetch the distribution, unpack it, configure
     it, compile it and install it for themselves or others to use; and
     <EM>end users</EM> that call programs of the package, once these have
     been installed at their site.  GNU <CODE>gettext</CODE> is offering magic
     for both installers and end users.
     </P>
     <H2><A NAME="SEC154" HREF="gettext_toc.html#TOC154">9.1  The Current <TT>`ABOUT-NLS&acute;</TT> Matrix</A></H2>
     <P>
     <A NAME="IDX947"></A>
     <A NAME="IDX948"></A>
     <A NAME="IDX949"></A>
     </P>
     <P>
     Languages are not equally supported in all packages using GNU
     <CODE>gettext</CODE>.  To know if some package uses GNU <CODE>gettext</CODE>, one
     may check the distribution for the <TT>`ABOUT-NLS&acute;</TT> information file, for
     some <TT>`<VAR>ll</VAR>.po&acute;</TT> files, often kept together into some <TT>`po/&acute;</TT>
     directory, or for an <TT>`intl/&acute;</TT> directory.  Internationalized packages
     have usually many <TT>`<VAR>ll</VAR>.po&acute;</TT> files, where <VAR>ll</VAR> represents
     the language.  section <A HREF="gettext_9.html#SEC156">9.3  Magic for End Users</A> for a complete description of the format
     for <VAR>ll</VAR>.
     </P>
     <P>
     More generally, a matrix is available for showing the current state
     of the Translation Project, listing which packages are prepared for
     multi-lingual messages, and which languages are supported by each.
     Because this information changes often, this matrix is not kept within
     this GNU <CODE>gettext</CODE> manual.  This information is often found in
     file <TT>`ABOUT-NLS&acute;</TT> from various distributions, but is also as old as
     the distribution itself.  A recent copy of this <TT>`ABOUT-NLS&acute;</TT> file,
     containing up-to-date information, should generally be found on the
     Translation Project sites, and also on most GNU archive sites.
     </P>
     <H2><A NAME="SEC155" HREF="gettext_toc.html#TOC155">9.2  Magic for Installers</A></H2>
     <P>
     <A NAME="IDX950"></A>
     <A NAME="IDX951"></A>
     </P>
     <P>
     By default, packages fully using GNU <CODE>gettext</CODE>, internally,
     are installed in such a way that they to allow translation of
     messages.  At <EM>configuration</EM> time, those packages should
     automatically detect whether the underlying host system already provides
     the GNU <CODE>gettext</CODE> functions.  If not,
     the GNU <CODE>gettext</CODE> library should be automatically prepared
     and used.  Installers may use special options at configuration
     time for changing this behavior.  The command <SAMP>`./configure
     --with-included-gettext&acute;</SAMP> bypasses system <CODE>gettext</CODE> to
     use the included GNU <CODE>gettext</CODE> instead,
     while <SAMP>`./configure --disable-nls&acute;</SAMP>
     produces programs totally unable to translate messages.
     </P>
     <P>
     <A NAME="IDX952"></A>
     Internationalized packages have usually many <TT>`<VAR>ll</VAR>.po&acute;</TT>
     files.  Unless
     translations are disabled, all those available are installed together
     with the package.  However, the environment variable <CODE>LINGUAS</CODE>
     may be set, prior to configuration, to limit the installed set.
     <CODE>LINGUAS</CODE> should then contain a space separated list of two-letter
     codes, stating which languages are allowed.
     </P>
     <H2><A NAME="SEC156" HREF="gettext_toc.html#TOC156">9.3  Magic for End Users</A></H2>
     <P>
     <A NAME="IDX953"></A>
     <A NAME="IDX954"></A>
     <A NAME="IDX955"></A>
     </P>
     <P>
     <A NAME="IDX956"></A>
     We consider here those packages using GNU <CODE>gettext</CODE> internally,
     and for which the installers did not disable translation at
     <EM>configure</EM> time.  Then, users only have to set the <CODE>LANG</CODE>
     environment variable to the appropriate <SAMP>`<VAR>ll</VAR>_<VAR>CC</VAR>&acute;</SAMP>
     combination prior to using the programs in the package.  See section <A HREF="gettext_9.html#SEC154">9.1  The Current <TT>`ABOUT-NLS&acute;</TT> Matrix</A>.
     For example, let's presume a German site.  At the shell prompt, users
     merely have to execute <SAMP>`setenv LANG de_DE&acute;</SAMP> (in <CODE>csh</CODE>) or
     <SAMP>`export LANG; LANG=de_DE&acute;</SAMP> (in <CODE>sh</CODE>).  They could even do
     this from their <TT>`.login&acute;</TT> or <TT>`.profile&acute;</TT> file.
     </P>
     <P><HR><P>
     Go to the <A HREF="gettext_1.html">first</A>, <A HREF="gettext_8.html">previous</A>, <A HREF="gettext_10.html">next</A>, <A HREF="gettext_22.html">last</A> section, <A HREF="gettext_toc.html">table of contents</A>.
     </BODY>
     </HTML>

     <html>
     <head>
     <meta name="generator" content="groff -Thtml, see www.gnu.org">
     <meta name="Content-Style" content="text/css">
     <title>TEXTDOMAIN</title>
     </head>
     <body>
     <h1 align=center>TEXTDOMAIN</h1>
     <a href="#NAME">NAME</a><br>
     <a href="#SYNOPSIS">SYNOPSIS</a><br>
     <a href="#DESCRIPTION">DESCRIPTION</a><br>
     <a href="#RETURN VALUE">RETURN VALUE</a><br>
     <a href="#ERRORS">ERRORS</a><br>
     <a href="#BUGS">BUGS</a><br>
     <a href="#SEE ALSO">SEE ALSO</a><br>
     <hr>
     <!-- Creator     : groff version 1.17 -->
     <a name="NAME"></a>
     <h2>NAME</h2>
     <table width="100%" border=0 rules="none" frame="void"
            cols="2" cellspacing="0" cellpadding="0">
     <tr valign="top" align="left">
     <td width="10%"></td><td width="90%">
     textdomain - set domain for future gettext() calls</td></table>
     <a name="SYNOPSIS"></a>
     <h2>SYNOPSIS</h2>
     <table width="100%" border=0 rules="none" frame="void"
            cols="2" cellspacing="0" cellpadding="0">
     <tr valign="top" align="left">
     <td width="10%"></td><td width="90%">
     <pre><b>#include &lt;libintl.h&gt;
     char * textdomain (const char *</b> <i>domainname</i><b>);
     </b></pre></td></table>
     <a name="DESCRIPTION"></a>
     <h2>DESCRIPTION</h2>
     <table width="100%" border=0 rules="none" frame="void"
            cols="2" cellspacing="0" cellpadding="0">
     <tr valign="top" align="left">
     <td width="10%"></td><td width="90%">
     The <b>textdomain</b> function sets or retrieves the current
     message domain.</td></table>
     <table width="100%" border=0 rules="none" frame="void"
            cols="2" cellspacing="0" cellpadding="0">
     <tr valign="top" align="left">
     <td width="10%"></td><td width="90%">
     A message domain is a set of translatable <i>msgid</i>
     messages. Usually, every software package has its own
     message domain. The domain name is used to determine the
     message catalog where a translation is looked up; it must be
     a non-empty string.</td></table>
     <table width="100%" border=0 rules="none" frame="void"
            cols="2" cellspacing="0" cellpadding="0">
     <tr valign="top" align="left">
     <td width="10%"></td><td width="90%">
     The current message domain is used by the <b>gettext</b>,
     <b>ngettext</b> functions, and by the <b>dgettext</b>,
     <b>dcgettext</b>, <b>dngettext</b> and <b>dcngettext</b>
     functions when called with a NULL domainname
     argument.</td></table>
     <table width="100%" border=0 rules="none" frame="void"
            cols="2" cellspacing="0" cellpadding="0">
     <tr valign="top" align="left">
     <td width="10%"></td><td width="90%">
     If <i>domainname</i> is not NULL, the current message domain
     is set to <i>domainname</i>. The string the function stores
     internally is a copy of the <i>domainname</i>
     argument.</td></table>
     <table width="100%" border=0 rules="none" frame="void"
            cols="2" cellspacing="0" cellpadding="0">
     <tr valign="top" align="left">
     <td width="10%"></td><td width="90%">
     If <i>domainname</i> is NULL, the function returns the
     current message domain.</td></table>
     <a name="RETURN VALUE"></a>
     <h2>RETURN VALUE</h2>
     <table width="100%" border=0 rules="none" frame="void"
            cols="2" cellspacing="0" cellpadding="0">
     <tr valign="top" align="left">
     <td width="10%"></td><td width="90%">
     If successful, the <b>textdomain</b> function returns the
     current message domain, after possibly changing it. The
     resulting string is valid until the next <b>textdomain</b>
     call and must not be modified or freed. If a memory
     allocation failure occurs, it sets <b>errno</b> to
     <b>ENOMEM</b> and returns NULL.</td></table>
     <a name="ERRORS"></a>
     <h2>ERRORS</h2>
     <table width="100%" border=0 rules="none" frame="void"
            cols="2" cellspacing="0" cellpadding="0">
     <tr valign="top" align="left">
     <td width="10%"></td><td width="90%">
     The following error can occur, among others:</td></table>
     <table width="100%" border=0 rules="none" frame="void"
            cols="2" cellspacing="0" cellpadding="0">
     <tr valign="top" align="left">
     <td width="10%"></td><td width="90%">
     <b>ENOMEM</b></td></table>
     <table width="100%" border=0 rules="none" frame="void"
            cols="2" cellspacing="0" cellpadding="0">
     <tr valign="top" align="left">
     <td width="21%"></td><td width="79%">
     Not enough memory available.</td></table>
     <a name="BUGS"></a>
     <h2>BUGS</h2>
     <table width="100%" border=0 rules="none" frame="void"
            cols="2" cellspacing="0" cellpadding="0">
     <tr valign="top" align="left">
     <td width="10%"></td><td width="90%">
     The return type ought to be <b>const char *</b>, but is
     <b>char *</b> to avoid warnings in C code predating ANSI
     C.</td></table>
     <a name="SEE ALSO"></a>
     <h2>SEE ALSO</h2>
     <table width="100%" border=0 rules="none" frame="void"
            cols="2" cellspacing="0" cellpadding="0">
     <tr valign="top" align="left">
     <td width="10%"></td><td width="90%">
     <b>gettext</b>(3), <b>ngettext</b>(3),
     <b>bindtextdomain</b>(3),
     <b>bind_textdomain_codeset</b>(3)</td></table>
     <hr>
     </body>
     </html>

     <html>
     <head>
     <meta name="generator" content="groff -Thtml, see www.gnu.org">
     <meta name="Content-Style" content="text/css">
     <title>BIND_TEXTDOMAIN_CODESET</title>
     </head>
     <body>
     <h1 align=center>BIND_TEXTDOMAIN_CODESET</h1>
     <a href="#NAME">NAME</a><br>
     <a href="#SYNOPSIS">SYNOPSIS</a><br>
     <a href="#DESCRIPTION">DESCRIPTION</a><br>
     <a href="#RETURN VALUE">RETURN VALUE</a><br>
     <a href="#ERRORS">ERRORS</a><br>
     <a href="#BUGS">BUGS</a><br>
     <a href="#SEE ALSO">SEE ALSO</a><br>
     <hr>
     <!-- Creator     : groff version 1.17 -->
     <a name="NAME"></a>
     <h2>NAME</h2>
     <table width="100%" border=0 rules="none" frame="void"
            cols="2" cellspacing="0" cellpadding="0">
     <tr valign="top" align="left">
     <td width="10%"></td><td width="90%">
     bind_textdomain_codeset - set encoding of message translations</td></table>
     <a name="SYNOPSIS"></a>
     <h2>SYNOPSIS</h2>
     <table width="100%" border=0 rules="none" frame="void"
            cols="2" cellspacing="0" cellpadding="0">
     <tr valign="top" align="left">
     <td width="10%"></td><td width="90%">
     <pre><b>#include &lt;libintl.h&gt;
     char * bind_textdomain_codeset (const char *</b> <i>domainname</i><b>,
                                     const char *</b> <i>codeset</i><b>);
     </b></pre></td></table>
     <a name="DESCRIPTION"></a>
     <h2>DESCRIPTION</h2>
     <table width="100%" border=0 rules="none" frame="void"
            cols="2" cellspacing="0" cellpadding="0">
     <tr valign="top" align="left">
     <td width="10%"></td><td width="90%">
     The <b>bind_textdomain_codeset</b> function sets the output
     codeset for message catalogs for domain
     <i>domainname</i>.</td></table>
     <table width="100%" border=0 rules="none" frame="void"
            cols="2" cellspacing="0" cellpadding="0">
     <tr valign="top" align="left">
     <td width="10%"></td><td width="90%">
     A message domain is a set of translatable <i>msgid</i>
     messages. Usually, every software package has its own
     message domain.</td></table>
     <table width="100%" border=0 rules="none" frame="void"
            cols="2" cellspacing="0" cellpadding="0">
     <tr valign="top" align="left">
     <td width="10%"></td><td width="90%">
     By default, the <b>gettext</b> family of functions returns
     translated messages in the locale's character encoding,
     which can be retrieved as <b>nl_langinfo(CODESET)</b>. The
     need for calling <b>bind_textdomain_codeset</b> arises for
     programs which store strings in a locale independent way
     (e.g. UTF-8) and want to avoid an extra character set
     conversion on the returned translated messages.</td></table>
     <table width="100%" border=0 rules="none" frame="void"
            cols="2" cellspacing="0" cellpadding="0">
     <tr valign="top" align="left">
     <td width="10%"></td><td width="90%">
     <i>domainname</i> must be a non-empty string.</td></table>
     <table width="100%" border=0 rules="none" frame="void"
            cols="2" cellspacing="0" cellpadding="0">
     <tr valign="top" align="left">
     <td width="10%"></td><td width="90%">
     If <i>codeset</i> is not NULL, it must be a valid encoding
     name which can be used for the <b>iconv_open</b> function.
     The <b>bind_textdomain_codeset</b> function sets the output
     codeset for message catalogs belonging to domain
     <i>domainname</i> to <i>codeset</i>. The function makes
     copies of the argument strings as needed.</td></table>
     <table width="100%" border=0 rules="none" frame="void"
            cols="2" cellspacing="0" cellpadding="0">
     <tr valign="top" align="left">
     <td width="10%"></td><td width="90%">
     If <i>codeset</i> is NULL, the function returns the
     previously set codeset for domain <i>domainname</i>. The
     default is NULL, denoting the locale's character
     encoding.</td></table>
     <a name="RETURN VALUE"></a>
     <h2>RETURN VALUE</h2>
     <table width="100%" border=0 rules="none" frame="void"
            cols="2" cellspacing="0" cellpadding="0">
     <tr valign="top" align="left">
     <td width="10%"></td><td width="90%">
     If successful, the <b>bind_textdomain_codeset</b> function
     returns the current codeset for domain <i>domainname</i>,
     after possibly changing it. The resulting string is valid
     until the next <b>bind_textdomain_codeset</b> call for the
     same <i>domainname</i> and must not be modified or freed. If
     a memory allocation failure occurs, it sets <b>errno</b> to
     <b>ENOMEM</b> and returns NULL. If no codeset has been set
     for domain <i>domainname</i>, it returns NULL.</td></table>
     <a name="ERRORS"></a>
     <h2>ERRORS</h2>
     <table width="100%" border=0 rules="none" frame="void"
            cols="2" cellspacing="0" cellpadding="0">
     <tr valign="top" align="left">
     <td width="10%"></td><td width="90%">
     The following error can occur, among others:</td></table>
     <table width="100%" border=0 rules="none" frame="void"
            cols="2" cellspacing="0" cellpadding="0">
     <tr valign="top" align="left">
     <td width="10%"></td><td width="90%">
     <b>ENOMEM</b></td></table>
     <table width="100%" border=0 rules="none" frame="void"
            cols="2" cellspacing="0" cellpadding="0">
     <tr valign="top" align="left">
     <td width="21%"></td><td width="79%">
     Not enough memory available.</td></table>
     <a name="BUGS"></a>
     <h2>BUGS</h2>
     <table width="100%" border=0 rules="none" frame="void"
            cols="2" cellspacing="0" cellpadding="0">
     <tr valign="top" align="left">
     <td width="10%"></td><td width="90%">
     The return type ought to be <b>const char *</b>, but is
     <b>char *</b> to avoid warnings in C code predating ANSI
     C.</td></table>
     <a name="SEE ALSO"></a>
     <h2>SEE ALSO</h2>
     <table width="100%" border=0 rules="none" frame="void"
            cols="2" cellspacing="0" cellpadding="0">
     <tr valign="top" align="left">
     <td width="10%"></td><td width="90%">
     <b>gettext</b>(3), <b>dgettext</b>(3), <b>dcgettext</b>(3),
     <b>ngettext</b>(3), <b>dngettext</b>(3),
     <b>dcngettext</b>(3), <b>textdomain</b>(3),
     <b>nl_langinfo</b>(3), <b>iconv_open</b>(3)</td></table>
     <hr>
     </body>
     </html>

     <html>
     <head>
     <meta name="generator" content="groff -Thtml, see www.gnu.org">
     <meta name="Content-Style" content="text/css">
     <title>GETTEXT</title>
     </head>
     <body>
     <h1 align=center>GETTEXT</h1>
     <a href="#NAME">NAME</a><br>
     <a href="#SYNOPSIS">SYNOPSIS</a><br>
     <a href="#DESCRIPTION">DESCRIPTION</a><br>
     <a href="#AUTHOR">AUTHOR</a><br>
     <a href="#REPORTING BUGS">REPORTING BUGS</a><br>
     <a href="#COPYRIGHT">COPYRIGHT</a><br>
     <a href="#SEE ALSO">SEE ALSO</a><br>
     <hr>
     <!-- Creator     : groff version 1.17.2 -->
     <a name="NAME"></a>
     <h2>NAME</h2>
     <table width="100%" border=0 rules="none" frame="void"
            cols="2" cellspacing="0" cellpadding="0">
     <tr valign="top" align="left">
     <td width="10%"></td><td width="90%">
     gettext - translate message</td></table>
     <a name="SYNOPSIS"></a>
     <h2>SYNOPSIS</h2>
     <table width="100%" border=0 rules="none" frame="void"
            cols="2" cellspacing="0" cellpadding="0">
     <tr valign="top" align="left">
     <td width="10%"></td><td width="90%">
     <b>gettext</b> [<i>OPTION</i>] [[<i>TEXTDOMAIN</i>]
     <i>MSGID</i>]<b><br>
     gettext</b> [<i>OPTION</i>] <i>-s</i>
     [<i>MSGID</i>]...</td></table>
     <a name="DESCRIPTION"></a>
     <h2>DESCRIPTION</h2>
     <table width="100%" border=0 rules="none" frame="void"
            cols="2" cellspacing="0" cellpadding="0">
     <tr valign="top" align="left">
     <td width="10%"></td><td width="90%">
     The <b>gettext</b> program translates a natural language
     message into the user's language, by looking up the
     translation in a message catalog.</td></table>
     <table width="100%" border=0 rules="none" frame="void"
            cols="2" cellspacing="0" cellpadding="0">
     <tr valign="top" align="left">
     <td width="10%"></td><td width="90%">
     Display native language translation of a textual
     message.</td></table>
     <table width="100%" border=0 rules="none" frame="void"
            cols="2" cellspacing="0" cellpadding="0">
     <tr valign="top" align="left">
     <td width="10%"></td><td width="90%">
     <b>-d</b>, <b>--domain</b>=<i>TEXTDOMAIN</i></td></table>
     <table width="100%" border=0 rules="none" frame="void"
            cols="2" cellspacing="0" cellpadding="0">
     <tr valign="top" align="left">
     <td width="21%"></td><td width="79%">
     retrieve translated messages from TEXTDOMAIN</td></table>
     <table width="100%" border=0 rules="none" frame="void"
            cols="2" cellspacing="0" cellpadding="0">
     <tr valign="top" align="left">
     <td width="10%"></td><td width="90%">
     <b>-e</b></td></table>
     <table width="100%" border=0 rules="none" frame="void"
            cols="2" cellspacing="0" cellpadding="0">
     <tr valign="top" align="left">
     <td width="21%"></td><td width="79%">
     enable expansion of some escape sequences</td></table>
     <table width="100%" border=0 rules="none" frame="void"
            cols="2" cellspacing="0" cellpadding="0">
     <tr valign="top" align="left">
     <td width="10%"></td><td width="90%">
     <b>-E</b></td></table>
     <table width="100%" border=0 rules="none" frame="void"
            cols="2" cellspacing="0" cellpadding="0">
     <tr valign="top" align="left">
     <td width="21%"></td><td width="79%">
     (ignored for compatibility)</td></table>
     <table width="100%" border=0 rules="none" frame="void"
            cols="2" cellspacing="0" cellpadding="0">
     <tr valign="top" align="left">
     <td width="10%"></td><td width="90%">
     <b>-h</b>, <b>--help</b></td></table>
     <table width="100%" border=0 rules="none" frame="void"
            cols="2" cellspacing="0" cellpadding="0">
     <tr valign="top" align="left">
     <td width="21%"></td><td width="79%">
     display this help and exit</td></table>
     <table width="100%" border=0 rules="none" frame="void"
            cols="2" cellspacing="0" cellpadding="0">
     <tr valign="top" align="left">
     <td width="10%"></td><td width="90%">
     <b>-n</b></td></table>
     <table width="100%" border=0 rules="none" frame="void"
            cols="2" cellspacing="0" cellpadding="0">
     <tr valign="top" align="left">
     <td width="21%"></td><td width="79%">
     suppress trailing newline</td></table>
     <table width="100%" border=0 rules="none" frame="void"
            cols="2" cellspacing="0" cellpadding="0">
     <tr valign="top" align="left">
     <td width="10%"></td><td width="90%">
     <b>-V</b>, <b>--version</b></td></table>
     <table width="100%" border=0 rules="none" frame="void"
            cols="2" cellspacing="0" cellpadding="0">
     <tr valign="top" align="left">
     <td width="21%"></td><td width="79%">
     display version information and exit</td></table>
     <table width="100%" border=0 rules="none" frame="void"
            cols="2" cellspacing="0" cellpadding="0">
     <tr valign="top" align="left">
     <td width="10%"></td><td width="90%">
     [TEXTDOMAIN] MSGID</td></table>
     <table width="100%" border=0 rules="none" frame="void"
            cols="2" cellspacing="0" cellpadding="0">
     <tr valign="top" align="left">
     <td width="21%"></td><td width="79%">
     retrieve translated message corresponding to MSGID from
     TEXTDOMAIN</td></table>
     <table width="100%" border=0 rules="none" frame="void"
            cols="2" cellspacing="0" cellpadding="0">
     <tr valign="top" align="left">
     <td width="10%"></td><td width="90%">
     If the TEXTDOMAIN parameter is not given, the domain is
     determined from the environment variable TEXTDOMAIN. If the
     message catalog is not found in the regular directory,
     another location can be specified with the environment
     variable TEXTDOMAINDIR. When used with the <b>-s</b> option
     the program behaves like the `echo' command. But it does not
     simply copy its arguments to stdout. Instead those messages
     found in the selected catalog are translated. Standard
     search directory: @localedir@</td></table>
     <a name="AUTHOR"></a>
     <h2>AUTHOR</h2>
     <table width="100%" border=0 rules="none" frame="void"
            cols="2" cellspacing="0" cellpadding="0">
     <tr valign="top" align="left">
     <td width="10%"></td><td width="90%">
     Written by Ulrich Drepper.</td></table>
     <a name="REPORTING BUGS"></a>
     <h2>REPORTING BUGS</h2>
     <table width="100%" border=0 rules="none" frame="void"
            cols="2" cellspacing="0" cellpadding="0">
     <tr valign="top" align="left">
     <td width="10%"></td><td width="90%">
     Report bugs to &lt;bug-gnu-gettext@gnu.org&gt;.</td></table>
     <a name="COPYRIGHT"></a>
     <h2>COPYRIGHT</h2>
     <table width="100%" border=0 rules="none" frame="void"
            cols="2" cellspacing="0" cellpadding="0">
     <tr valign="top" align="left">
     <td width="10%"></td><td width="90%">
     Copyright 1995-1997, 2000-2003 Free Software Foundation,
     Inc.<br>
     This is free software; see the source for copying
     conditions. There is NO warranty; not even for
     MERCHANTABILITY or FITNESS FOR A PARTICULAR
     PURPOSE.</td></table>
     <a name="SEE ALSO"></a>
     <h2>SEE ALSO</h2>
     <table width="100%" border=0 rules="none" frame="void"
            cols="2" cellspacing="0" cellpadding="0">
     <tr valign="top" align="left">
     <td width="10%"></td><td width="90%">
     The full documentation for <b>gettext</b> is maintained as a
     Texinfo manual. If the <b>info</b> and <b>gettext</b>
     programs are properly installed at your site, the
     command</td></table>
     <table width="100%" border=0 rules="none" frame="void"
            cols="2" cellspacing="0" cellpadding="0">
     <tr valign="top" align="left">
     <td width="21%"></td><td width="79%">
     <b>info gettext</b></td></table>
     <table width="100%" border=0 rules="none" frame="void"
            cols="2" cellspacing="0" cellpadding="0">
     <tr valign="top" align="left">
     <td width="10%"></td><td width="90%">
     should give you access to the complete manual.</td></table>
     <hr>
     </body>
     </html>

     <html>
     <head>
     <meta name="generator" content="groff -Thtml, see www.gnu.org">
     <meta name="Content-Style" content="text/css">
     <title>GETTEXT</title>
     </head>
     <body>
     <h1 align=center>GETTEXT</h1>
     <a href="#NAME">NAME</a><br>
     <a href="#SYNOPSIS">SYNOPSIS</a><br>
     <a href="#DESCRIPTION">DESCRIPTION</a><br>
     <a href="#RETURN VALUE">RETURN VALUE</a><br>
     <a href="#ERRORS">ERRORS</a><br>
     <a href="#BUGS">BUGS</a><br>
     <a href="#SEE ALSO">SEE ALSO</a><br>
     <hr>
     <!-- Creator     : groff version 1.17 -->
     <a name="NAME"></a>
     <h2>NAME</h2>
     <table width="100%" border=0 rules="none" frame="void"
            cols="2" cellspacing="0" cellpadding="0">
     <tr valign="top" align="left">
     <td width="10%"></td><td width="90%">
     gettext, dgettext, dcgettext - translate message</td></table>
     <a name="SYNOPSIS"></a>
     <h2>SYNOPSIS</h2>
     <table width="100%" border=0 rules="none" frame="void"
            cols="2" cellspacing="0" cellpadding="0">
     <tr valign="top" align="left">
     <td width="10%"></td><td width="90%">
     <pre><b>#include &lt;libintl.h&gt;
     char * gettext (const char *</b> <i>msgid</i><b>);
     char * dgettext (const char *</b> <i>domainname</i><b>, const char *</b> <i>msgid</i><b>);
     char * dcgettext (const char *</b> <i>domainname</i><b>, const char *</b> <i>msgid</i><b>,
                       int</b> <i>category</i><b>);
     </b></pre></td></table>
     <a name="DESCRIPTION"></a>
     <h2>DESCRIPTION</h2>
     <table width="100%" border=0 rules="none" frame="void"
            cols="2" cellspacing="0" cellpadding="0">
     <tr valign="top" align="left">
     <td width="10%"></td><td width="90%">
     The <b>gettext</b>, <b>dgettext</b> and <b>dcgettext</b>
     functions attempt to translate a text string into the user's
     native language, by looking up the translation in a message
     catalog.</td></table>
     <table width="100%" border=0 rules="none" frame="void"
            cols="2" cellspacing="0" cellpadding="0">
     <tr valign="top" align="left">
     <td width="10%"></td><td width="90%">
     The <i>msgid</i> argument identifies the message to be
     translated. By convention, it is the English version of the
     message, with non-ASCII characters replaced by ASCII
     approximations. This choice allows the translators to work
     with message catalogs, called PO files, that contain both
     the English and the translated versions of each message, and
     can be installed using the <b>msgfmt</b>
     utility.</td></table>
     <table width="100%" border=0 rules="none" frame="void"
            cols="2" cellspacing="0" cellpadding="0">
     <tr valign="top" align="left">
     <td width="10%"></td><td width="90%">
     A message domain is a set of translatable <i>msgid</i>
     messages. Usually, every software package has its own
     message domain. The domain name is used to determine the
     message catalog where the translation is looked up; it must
     be a non-empty string. For the <b>gettext</b> function, it
     is specified through a preceding <b>textdomain</b> call. For
     the <b>dgettext</b> and <b>dcgettext</b> functions, it is
     passed as the <i>domainname</i> argument; if this argument
     is NULL, the domain name specified through a preceding
     <b>textdomain</b> call is used instead.</td></table>
     <table width="100%" border=0 rules="none" frame="void"
            cols="2" cellspacing="0" cellpadding="0">
     <tr valign="top" align="left">
     <td width="10%"></td><td width="90%">
     Translation lookup operates in the context of the current
     locale. For the <b>gettext</b> and <b>dgettext</b>
     functions, the <b>LC_MESSAGES</b> locale facet is used. It
     is determined by a preceding call to the <b>setlocale</b>
     function. <b>setlocale(LC_ALL,&quot;&quot;)</b> initializes
     the <b>LC_MESSAGES</b> locale based on the first nonempty
     value of the three environment variables <b>LC_ALL</b>,
     <b>LC_MESSAGES</b>, <b>LANG</b>; see <b>setlocale</b>(3).
     For the <b>dcgettext</b> function, the locale facet is
     determined by the <i>category</i> argument, which should be
     one of the <b>LC_xxx</b> constants defined in the
     &lt;locale.h&gt; header, excluding <b>LC_ALL</b>. In both
     cases, the functions also use the <b>LC_CTYPE</b> locale
     facet in order to convert the translated message from the
     translator's codeset to the current locale's codeset, unless
     overridden by a prior call to the
     <b>bind_textdomain_codeset</b> function.</td></table>
     <table width="100%" border=0 rules="none" frame="void"
            cols="2" cellspacing="0" cellpadding="0">
     <tr valign="top" align="left">
     <td width="10%"></td><td width="90%">
     The message catalog used by the functions is at the pathname
     <i>dirname</i>/<i>locale</i>/<i>category</i>/<i>domainname</i>.mo.
     Here <i>dirname</i> is the directory specified through
     <b>bindtextdomain</b>. Its default is system and
     configuration dependent; typically it is
     <i>prefix</i>/share/locale, where <i>prefix</i> is the
     installation prefix of the package. <i>locale</i> is the
     name of the current locale facet; the GNU implementation
     also tries generalizations, such as the language name
     without the territory name. <i>category</i> is
     <b>LC_MESSAGES</b> for the <b>gettext</b> and
     <b>dgettext</b> functions, or the argument passed to the
     <b>dcgettext</b> function.</td></table>
     <table width="100%" border=0 rules="none" frame="void"
            cols="2" cellspacing="0" cellpadding="0">
     <tr valign="top" align="left">
     <td width="10%"></td><td width="90%">
     If the <b>LANGUAGE</b> environment variable is set to a
     nonempty value, and the locale is not the &quot;C&quot;
     locale, the value of <b>LANGUAGE</b> is assumed to contain a
     colon separated list of locale names. The functions will
     attempt to look up a translation of <i>msgid</i> in each of
     the locales in turn. This is a GNU extension.</td></table>
     <table width="100%" border=0 rules="none" frame="void"
            cols="2" cellspacing="0" cellpadding="0">
     <tr valign="top" align="left">
     <td width="10%"></td><td width="90%">
     In the &quot;C&quot; locale, or if none of the used catalogs
     contain a translation for <i>msgid</i>, the <b>gettext</b>,
     <b>dgettext</b> and <b>dcgettext</b> functions return
     <i>msgid</i>.</td></table>
     <a name="RETURN VALUE"></a>
     <h2>RETURN VALUE</h2>
     <table width="100%" border=0 rules="none" frame="void"
            cols="2" cellspacing="0" cellpadding="0">
     <tr valign="top" align="left">
     <td width="10%"></td><td width="90%">
     If a translation was found in one of the specified catalogs,
     it is converted to the locale's codeset and returned. The
     resulting string is statically allocated and must not be
     modified or freed. Otherwise <i>msgid</i> is
     returned.</td></table>
     <a name="ERRORS"></a>
     <h2>ERRORS</h2>
     <table width="100%" border=0 rules="none" frame="void"
            cols="2" cellspacing="0" cellpadding="0">
     <tr valign="top" align="left">
     <td width="10%"></td><td width="90%">
     <b>errno</b> is not modified.</td></table>
     <a name="BUGS"></a>
     <h2>BUGS</h2>
     <table width="100%" border=0 rules="none" frame="void"
            cols="2" cellspacing="0" cellpadding="0">
     <tr valign="top" align="left">
     <td width="10%"></td><td width="90%">
     The return type ought to be <b>const char *</b>, but is
     <b>char *</b> to avoid warnings in C code predating ANSI
     C.</td></table>
     <table width="100%" border=0 rules="none" frame="void"
            cols="2" cellspacing="0" cellpadding="0">
     <tr valign="top" align="left">
     <td width="10%"></td><td width="90%">
     When an empty string is used for <i>msgid</i>, the functions
     may return a nonempty string.</td></table>
     <a name="SEE ALSO"></a>
     <h2>SEE ALSO</h2>
     <table width="100%" border=0 rules="none" frame="void"
            cols="2" cellspacing="0" cellpadding="0">
     <tr valign="top" align="left">
     <td width="10%"></td><td width="90%">
     <b>ngettext</b>(3), <b>dngettext</b>(3),
     <b>dcngettext</b>(3), <b>setlocale</b>(3),
     <b>textdomain</b>(3), <b>bindtextdomain</b>(3),
     <b>bind_textdomain_codeset</b>(3),
     <b>msgfmt</b>(1)</td></table>
     <hr>
     </body>
     </html>

     <HTML>
     <HEAD>
     <!-- This HTML file has been created by texi2html 1.52a
          from gettext.texi on 9 December 2003 -->
     <TITLE>GNU gettext utilities - 11  The Translator's View</TITLE>
     </HEAD>
     <BODY>
     Go to the <A HREF="gettext_1.html">first</A>, <A HREF="gettext_10.html">previous</A>, <A HREF="gettext_12.html">next</A>, <A HREF="gettext_22.html">last</A> section, <A HREF="gettext_toc.html">table of contents</A>.
     <P><HR><P>
     <H1><A NAME="SEC177" HREF="gettext_toc.html#TOC177">11  The Translator's View</A></H1>
     <H2><A NAME="SEC178" HREF="gettext_toc.html#TOC178">11.1  Introduction 0</A></H2>
     <P>
     Free software is going international!  The Translation Project is a way
     to get maintainers, translators and users all together, so free software
     will gradually become able to speak many native languages.
     </P>
     <P>
     The GNU <CODE>gettext</CODE> tool set contains <EM>everything</EM> maintainers
     need for internationalizing their packages for messages.  It also
     contains quite useful tools for helping translators at localizing
     messages to their native language, once a package has already been
     internationalized.
     </P>
     <P>
     To achieve the Translation Project, we need many interested
     people who like their own language and write it well, and who are also
     able to synergize with other translators speaking the same language.
     If you'd like to volunteer to <EM>work</EM> at translating messages,
     please send mail to your translating team.
     </P>
     <P>
     Each team has its own mailing list, courtesy of Linux
     International.  You may reach your translating team at the address
     <TT>`<VAR>ll</VAR>@li.org&acute;</TT>, replacing <VAR>ll</VAR> by the two-letter ISO 639
     code for your language.  Language codes are <EM>not</EM> the same as
     country codes given in ISO 3166.  The following translating teams
     exist:
     </P>
     <BLOCKQUOTE>
     <P>
     Chinese <CODE>zh</CODE>, Czech <CODE>cs</CODE>, Danish <CODE>da</CODE>, Dutch <CODE>nl</CODE>,
     Esperanto <CODE>eo</CODE>, Finnish <CODE>fi</CODE>, French <CODE>fr</CODE>, Irish
     <CODE>ga</CODE>, German <CODE>de</CODE>, Greek <CODE>el</CODE>, Italian <CODE>it</CODE>,
     Japanese <CODE>ja</CODE>, Indonesian <CODE>in</CODE>, Norwegian <CODE>no</CODE>, Polish
     <CODE>pl</CODE>, Portuguese <CODE>pt</CODE>, Russian <CODE>ru</CODE>, Spanish <CODE>es</CODE>,
     Swedish <CODE>sv</CODE> and Turkish <CODE>tr</CODE>.
     </BLOCKQUOTE>
     <P>
     For example, you may reach the Chinese translating team by writing to
     <TT>`zh@li.org&acute;</TT>.  When you become a member of the translating team
     for your own language, you may subscribe to its list.  For example,
     Swedish people can send a message to <TT>`sv-request@li.org&acute;</TT>,
     having this message body:
     </P>
     <PRE>
     subscribe
     </PRE>
     <P>
     Keep in mind that team members should be interested in <EM>working</EM>
     at translations, or at solving translational difficulties, rather than
     merely lurking around.  If your team does not exist yet and you want to
     start one, please write to <TT>`translation@iro.umontreal.ca&acute;</TT>;
     you will then reach the coordinator for all translator teams.
     </P>
     <P>
     A handful of GNU packages have already been adapted and provided
     with message translations for several languages.  Translation
     teams have begun to organize, using these packages as a starting
     point.  But there are many more packages and many languages for
     which we have no volunteer translators.  If you would like to
     volunteer to work at translating messages, please send mail to
     <TT>`translation@iro.umontreal.ca&acute;</TT> indicating what language(s)
     you can work on.
     </P>
     <H2><A NAME="SEC179" HREF="gettext_toc.html#TOC179">11.2  Introduction 1</A></H2>
     <P>
     This is now official, GNU is going international!  Here is the
     announcement submitted for the January 1995 GNU Bulletin:
     </P>
     <BLOCKQUOTE>
     <P>
     A handful of GNU packages have already been adapted and provided
     with message translations for several languages.  Translation
     teams have begun to organize, using these packages as a starting
     point.  But there are many more packages and many languages
     for which we have no volunteer translators.  If you'd like to
     volunteer to work at translating messages, please send mail to
     <SAMP>`translation@iro.umontreal.ca&acute;</SAMP> indicating what language(s)
     you can work on.
     </BLOCKQUOTE>
     <P>
     This document should answer many questions for those who are curious about
     the process or would like to contribute.  Please at least skim over it,
     hoping to cut down a little of the high volume of e-mail generated by this
     collective effort towards internationalization of free software.
     </P>
     <P>
     Most free programming which is widely shared is done in English, and
     currently, English is used as the main communicating language between
     national communities collaborating to free software.  This very document
     is written in English.  This will not change in the foreseeable future.
     </P>
     <P>
     However, there is a strong appetite from national communities for
     having more software able to write using national language and habits,
     and there is an on-going effort to modify free software in such a way
     that it becomes able to do so.  The experiments driven so far raised
     an enthusiastic response from pretesters, so we believe that
     internationalization of free software is dedicated to succeed.
     </P>
     <P>
     For suggestion clarifications, additions or corrections to this
     document, please e-mail to <TT>`translation@iro.umontreal.ca&acute;</TT>.
     </P>
     <H2><A NAME="SEC180" HREF="gettext_toc.html#TOC180">11.3  Discussions</A></H2>
     <P>
     Facing this internationalization effort, a few users expressed their
     concerns.  Some of these doubts are presented and discussed, here.
     </P>
     <UL>
     <LI>Smaller groups
     Some languages are not spoken by a very large number of people, so people
     speaking them sometimes consider that there may not be all that much
     demand such versions of free software packages.  Moreover, many people
     being <EM>into computers</EM>, in some countries, generally seem to prefer
     English versions of their software.
     On the other end, people might enjoy their own language a lot, and be
     very motivated at providing to themselves the pleasure of having their
     beloved free software speaking their mother tongue.  They do themselves
     a personal favor, and do not pay that much attention to the number of
     people benefiting of their work.
     <LI>Misinterpretation
     Other users are shy to push forward their own language, seeing in this
     some kind of misplaced propaganda.  Someone thought there must be some
     users of the language over the networks pestering other people with it.
     But any spoken language is worth localization, because there are
     people behind the language for whom the language is important and
     dear to their hearts.
     <LI>Odd translations
     The biggest problem is to find the right translations so that
     everybody can understand the messages.  Translations are usually a
     little odd.  Some people get used to English, to the extent they may
     find translations into their own language "rather pushy, obnoxious
     and sometimes even hilarious."  As a French speaking man, I have
     the experience of those instruction manuals for goods, so poorly
     translated in French in Korea or Taiwan...
     The fact is that we sometimes have to create a kind of national
     computer culture, and this is not easy without the collaboration of
     many people liking their mother tongue.  This is why translations are
     better achieved by people knowing and loving their own language, and
     ready to work together at improving the results they obtain.
     <LI>Dependencies over the GPL or LGPL
     Some people wonder if using GNU <CODE>gettext</CODE> necessarily brings their
     package under the protective wing of the GNU General Public License or
     the GNU Library General Public License, when they do not want to make
     their program free, or want other kinds of freedom.  The simplest
     answer is "normally not".
     The <CODE>gettext-runtime</CODE> part of GNU <CODE>gettext</CODE>, i.e. the
     contents of <CODE>libintl</CODE>, is covered by the GNU Library General Public
     License.  The <CODE>gettext-tools</CODE> part of GNU <CODE>gettext</CODE>, i.e. the
     rest of the GNU <CODE>gettext</CODE> package, is covered by the GNU General
     Public License.
     The mere marking of localizable strings in a package, or conditional
     inclusion of a few lines for initialization, is not really including
     GPL'ed or LGPL'ed code.  However, since the localization routines in
     <CODE>libintl</CODE> are under the LGPL, the LGPL needs to be considered.
     It gives the right to distribute the complete unmodified source of
     <CODE>libintl</CODE> even with non-free programs.  It also gives the right
     to use <CODE>libintl</CODE> as a shared library, even for non-free programs.
     But it gives the right to use <CODE>libintl</CODE> as a static library or
     to incorporate <CODE>libintl</CODE> into another library only to free
     software.
     </UL>
     <H2><A NAME="SEC181" HREF="gettext_toc.html#TOC181">11.4  Organization</A></H2>
     <P>
     On a larger scale, the true solution would be to organize some kind of
     fairly precise set up in which volunteers could participate.  I gave
     some thought to this idea lately, and realize there will be some
     touchy points.  I thought of writing to Richard Stallman to launch
     such a project, but feel it might be good to shake out the ideas
     between ourselves first.  Most probably that Linux International has
     some experience in the field already, or would like to orchestrate
     the volunteer work, maybe.  Food for thought, in any case!
     </P>
     <P>
     I guess we have to setup something early, somehow, that will help
     many possible contributors of the same language to interlock and avoid
     work duplication, and further be put in contact for solving together
     problems particular to their tongue (in most languages, there are many
     difficulties peculiar to translating technical English).  My Swedish
     contributor acknowledged these difficulties, and I'm well aware of
     them for French.
     </P>
     <P>
     This is surely not a technical issue, but we should manage so the
     effort of locale contributors be maximally useful, despite the national
     team layer interface between contributors and maintainers.
     </P>
     <P>
     The Translation Project needs some setup for coordinating language
     coordinators.  Localizing evolving programs will surely
     become a permanent and continuous activity in the free software community,
     once well started.
     The setup should be minimally completed and tested before GNU
     <CODE>gettext</CODE> becomes an official reality.  The e-mail address
     <TT>`translation@iro.umontreal.ca&acute;</TT> has been setup for receiving
     offers from volunteers and general e-mail on these topics.  This address
     reaches the Translation Project coordinator.
     </P>
     <H3><A NAME="SEC182" HREF="gettext_toc.html#TOC182">11.4.1  Central Coordination</A></H3>
     <P>
     I also think GNU will need sooner than it thinks, that someone setup
     a way to organize and coordinate these groups.  Some kind of group
     of groups.  My opinion is that it would be good that GNU delegates
     this task to a small group of collaborating volunteers, shortly.
     Perhaps in <TT>`gnu.announce&acute;</TT> a list of this national committee's
     can be published.
     </P>
     <P>
     My role as coordinator would simply be to refer to Ulrich any German
     speaking volunteer interested to localization of free software packages, and
     maybe helping national groups to initially organize, while maintaining
     national registries for until national groups are ready to take over.
     In fact, the coordinator should ease volunteers to get in contact with
     one another for creating national teams, which should then select
     one coordinator per language, or country (regionalized language).
     If well done, the coordination should be useful without being an
     overwhelming task, the time to put delegations in place.
     </P>
     <H3><A NAME="SEC183" HREF="gettext_toc.html#TOC183">11.4.2  National Teams</A></H3>
     <P>
     I suggest we look for volunteer coordinators/editors for individual
     languages.  These people will scan contributions of translation files
     for various programs, for their own languages, and will ensure high
     and uniform standards of diction.
     </P>
     <P>
     From my current experience with other people in these days, those who
     provide localizations are very enthusiastic about the process, and are
     more interested in the localization process than in the program they
     localize, and want to do many programs, not just one.  This seems
     to confirm that having a coordinator/editor for each language is a
     good idea.
     </P>
     <P>
     We need to choose someone who is good at writing clear and concise
     prose in the language in question.  That is hard--we can't check
     it ourselves.  So we need to ask a few people to judge each others'
     writing and select the one who is best.
     </P>
     <P>
     I announce my prerelease to a few dozen people, and you would not
     believe all the discussions it generated already.  I shudder to think
     what will happen when this will be launched, for true, officially,
     world wide.  Who am I to arbitrate between two Czekolsovak users
     contradicting each other, for example?
     </P>
     <P>
     I assume that your German is not much better than my French so that
     I would not be able to judge about these formulations.  What I would
     suggest is that for each language there is a group for people who
     maintain the PO files and judge about changes.  I suspect there will
     be cultural differences between how such groups of people will behave.
     Some will have relaxed ways, reach consensus easily, and have anyone
     of the group relate to the maintainers, while others will fight to
     death, organize heavy administrations up to national standards, and
     use strict channels.
     </P>
     <P>
     The German team is putting out a good example.  Right now, they are
     maybe half a dozen people revising translations of each other and
     discussing the linguistic issues.  I do not even have all the names.
     Ulrich Drepper is taking care of coordinating the German team.
     He subscribed to all my pretest lists, so I do not even have to warn
     him specifically of incoming releases.
     </P>
     <P>
     I'm sure, that is a good idea to get teams for each language working
     on translations.  That will make the translations better and more
     consistent.
     </P>
     <H4><A NAME="SEC184" HREF="gettext_toc.html#TOC184">11.4.2.1  Sub-Cultures</A></H4>
     <P>
     Taking French for example, there are a few sub-cultures around computers
     which developed diverging vocabularies.  Picking volunteers here and
     there without addressing this problem in an organized way, soon in the
     project, might produce a distasteful mix of internationalized programs,
     and possibly trigger endless quarrels among those who really care.
     </P>
     <P>
     Keeping some kind of unity in the way French localization of
     internationalized programs is achieved is a difficult (and delicate) job.
     Knowing the latin character of French people (:-), if we take this
     the wrong way, we could end up nowhere, or spoil a lot of energies.
     Maybe we should begin to address this problem seriously <EM>before</EM>
     GNU <CODE>gettext</CODE> become officially published.  And I suspect that this
     means soon!
     </P>

... This diff was truncated because it exceeds the maximum size that can be displayed.

Also available in: Unified diff