1*946379e7Schristos<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> 2*946379e7Schristos<html> 3*946379e7Schristos<head> 4*946379e7Schristos <meta http-equiv="content-type" content="text/html; charset=UTF-8"> 5*946379e7Schristos <title>GNU gettext FAQ</title> 6*946379e7Schristos</head> 7*946379e7Schristos<body> 8*946379e7Schristos<h1 style="text-align: center;">Frequently Asked Questions<br> 9*946379e7Schristosfor GNU gettext 10*946379e7Schristos</h1> 11*946379e7Schristos<h1 style="text-align: center;">Questions</h1> 12*946379e7Schristos<h3>General</h3> 13*946379e7Schristos<ul> 14*946379e7Schristos <li><a href="#general_mailinglist">Where is the mailing list?</a></li> 15*946379e7Schristos <li><a href="#general_source">Where is the newest gettext source?</a></li> 16*946379e7Schristos <li><a href="#general_announce">I want to be notified of new gettext 17*946379e7Schristosreleases.</a></li> 18*946379e7Schristos</ul> 19*946379e7Schristos<h3>Problems building GNU gettext</h3> 20*946379e7Schristos<ul> 21*946379e7Schristos <li><a href="#building_solaris_libasprintf">On Solaris, I get a build 22*946379e7Schristoserror “text relocations remain” in the <span 23*946379e7Schristos style="font-family: monospace;">libasprintf</span> subdirectory</a></li> 24*946379e7Schristos <li><a href="#building_rpath_check">During “make check”, some tests 25*946379e7Schristosnamed <span style="font-family: monospace;">rpath-<span 26*946379e7Schristos style="font-style: italic;">Nxyz</span></span> 27*946379e7Schristosfail: “ld: fatal error ... -lrpathz”</a></li> 28*946379e7Schristos <li><a href="#building_install">“make install” fails</a></li> 29*946379e7Schristos</ul> 30*946379e7Schristos<h3>Problems integrating GNU gettext</h3> 31*946379e7Schristos<ul> 32*946379e7Schristos <li><a href="#integrating_howto">How do I make use of <span 33*946379e7Schristos style="font-family: monospace;">gettext()</span> in my package?</a></li> 34*946379e7Schristos <li><a href="#integrating_undefined">I get a linker error “undefined 35*946379e7Schristosreference to libintl_gettext”</a></li> 36*946379e7Schristos <li><a href="#integrating_abuse_gettextize">gettextize adds multiple 37*946379e7Schristosreferences to the same directories/files 38*946379e7Schristosto <span style="font-family: monospace;">Makefile.am</span> and </a><span 39*946379e7Schristos style="font-family: monospace;"><a href="#integrating_abuse_gettextize">configure.ac</a><br> 40*946379e7Schristos </span></li> 41*946379e7Schristos <li><a href="#integrating_noop">My program compiles and links fine, 42*946379e7Schristosbut doesn't output translated 43*946379e7Schristosstrings.</a><br> 44*946379e7Schristos </li> 45*946379e7Schristos</ul> 46*946379e7Schristos<h3>GNU gettext on Windows</h3> 47*946379e7Schristos<ul> 48*946379e7Schristos <li><a href="#windows_woe32">What does Woe32 mean?</a></li> 49*946379e7Schristos <li><a href="#windows_howto">How do I compile, link and run a program 50*946379e7Schristosthat uses the gettext() 51*946379e7Schristosfunction?</a><br> 52*946379e7Schristos </li> 53*946379e7Schristos <li><a href="#windows_setenv">Setting the <span 54*946379e7Schristos style="font-family: monospace;">LANG</span> 55*946379e7Schristosenvironment variable doesn't have any effect</a></li> 56*946379e7Schristos</ul> 57*946379e7Schristos<h3>Other</h3> 58*946379e7Schristos<ul> 59*946379e7Schristos <li><a href="#newline">What does this mean: “`msgid' and `msgstr' 60*946379e7Schristosentries do not both 61*946379e7Schristosend with '\n'”</a></li> 62*946379e7Schristos <li><a href="#translit">German umlauts are displayed like “ge"andert” 63*946379e7Schristosinstead of 64*946379e7Schristos“geändert”</a></li> 65*946379e7Schristos <li><a href="#localename">The <span style="font-family: monospace;">LANGUAGE</span> 66*946379e7Schristosenvironment variable is ignored after I set <span 67*946379e7Schristos style="font-family: monospace;">LANG=en</span></a></li> 68*946379e7Schristos <li><a href="#nonascii_strings">I use accented characters in my 69*946379e7Schristossource code. How do I tell the 70*946379e7SchristosC/C++ compiler in which encoding it is (like <span 71*946379e7Schristos style="font-family: monospace;">xgettext</span>'s <span 72*946379e7Schristos style="font-family: monospace;">--from-code</span> option)?</a></li> 73*946379e7Schristos</ul> 74*946379e7Schristos<h1 style="text-align: center;">Answers</h1> 75*946379e7Schristos<h3>General</h3> 76*946379e7Schristos<h4><a name="general_mailinglist"></a>Where is the mailing list?</h4> 77*946379e7SchristosThree mailing lists are available: <br> 78*946379e7Schristos<ul> 79*946379e7Schristos <li><span style="font-family: monospace;">bug-gnu-gettext@gnu.org</span><br> 80*946379e7SchristosThis mailing list is for discussion of features and bugs of the GNU 81*946379e7Schristosgettext <span style="font-style: italic;">software</span>, including 82*946379e7Schristoslibintl, the gettext-tools, and its autoconf macros.</li> 83*946379e7Schristos <li><span style="font-family: monospace;">translation-i18n@lists.sourceforge.net</span><br> 84*946379e7SchristosThis mailing list is for methodology questions around 85*946379e7Schristosinternationalization, and for discussions of translator tools, 86*946379e7Schristosincluding but not limited to GNU gettext.</li> 87*946379e7Schristos <li><span style="font-family: monospace;">translation@iro.umontreal.ca</span><br> 88*946379e7SchristosThis is the email address of the <a 89*946379e7Schristos href="http://www.iro.umontreal.ca/contrib/po/HTML/">Free Translation 90*946379e7SchristosProject</a>, that is the project which manages the translated message 91*946379e7Schristoscatalogs for many free software packages. Note that KDE and GNOME 92*946379e7Schristospackages are not part of this project; they have their own translation 93*946379e7Schristosprojects: <a href="http://i18n.kde.org/">i18n.kde.org</a> and <a 94*946379e7Schristos href="http://developer.gnome.org/projects/gtp/">gtp</a>.<br> 95*946379e7Schristos </li> 96*946379e7Schristos</ul> 97*946379e7SchristosThe <span style="font-family: monospace;">bug-gnu-gettext</span> list 98*946379e7Schristosis archived as part of the <a 99*946379e7Schristos href="http://mail.gnu.org/archive/html/bug-gnu-utils/"><span 100*946379e7Schristos style="font-family: monospace;">bug-gnu-utils</span></a> archives. <span 101*946379e7Schristos style="font-family: monospace;">bug-gnu-gettext</span> cannot be 102*946379e7Schristossubscribed on its own; to receive its contents by mail, subscribe to <span 103*946379e7Schristos style="font-family: monospace;">bug-gnu-utils</span>.<br> 104*946379e7Schristos<h4><a name="general_source"></a>Where is the newest gettext source?</h4> 105*946379e7SchristosThe newest gettext release is available on <span 106*946379e7Schristos style="font-family: monospace;">ftp.gnu.org</span> and its mirrors, in 107*946379e7Schristos<a href="http://ftp.gnu.org/gnu/gettext/">http://ftp.gnu.org/gnu/gettext/</a>.<br> 108*946379e7Schristos<br> 109*946379e7SchristosPrereleases are announced on the <a 110*946379e7Schristos href="http://mail.gnu.org/pipermail/autotools-announce"><span 111*946379e7Schristos style="font-family: monospace;">autotools-announce</span> mailing list</a>. 112*946379e7SchristosNote that prereleases are meant for testing and not meant for use in 113*946379e7Schristosproduction environments. Please don't use the “gettextize” program of a 114*946379e7Schristosprerelease on projects which you share with other programmers via CVS.<br> 115*946379e7Schristos<br> 116*946379e7SchristosIf you want to live on the bleeding edge, you can also use the 117*946379e7Schristosdevelopment sources. Instructions for retrieving the gettext CVS are 118*946379e7Schristosfound <a href="http://savannah.gnu.org/projects/gettext">here</a>. 119*946379e7SchristosNote that building from CVS requires special tools (autoconf, automake, 120*946379e7Schristosm4, groff, bison, etc.) and requires that you pay attention to the <span 121*946379e7Schristos style="font-family: monospace;">README-alpha</span> and <span 122*946379e7Schristos style="font-family: monospace;">autogen.sh</span> files in the CVS.<br> 123*946379e7Schristos<h4><a name="general_announce"></a>I want to be notified of new gettext 124*946379e7Schristosreleases.</h4> 125*946379e7SchristosIf you are interested in stable gettext releases, you can follow the <a 126*946379e7Schristos href="http://mail.gnu.org/pipermail/info-gnu"><span 127*946379e7Schristos style="font-family: monospace;">info-gnu</span> mailing list</a>. It 128*946379e7Schristosis also available as a newsgroup <a 129*946379e7Schristos href="nntp://news.gmane.org/gmane.org.fsf.announce"><span 130*946379e7Schristos style="font-family: monospace;">gmane.org.fsf.announce</span></a> 131*946379e7Schristosthrough <a href="http://www.gmane.org/"><span 132*946379e7Schristos style="font-family: monospace;">gmane.org</span></a>.<br> 133*946379e7Schristos<br> 134*946379e7SchristosYou can also periodically check the download location.<br> 135*946379e7Schristos<br> 136*946379e7SchristosIf you are interested in testing prereleases as well, you can subscribe 137*946379e7Schristosto the <a href="http://mail.gnu.org/pipermail/autotools-announce"><span 138*946379e7Schristos style="font-family: monospace;">autotools-announce</span> mailing 139*946379e7Schristoslist</a>.<br> 140*946379e7Schristos<h3>Problems building GNU gettext</h3> 141*946379e7Schristos<h4><a name="building_solaris_libasprintf"></a>On Solaris, I get a 142*946379e7Schristosbuild error “text relocations remain” in the <span 143*946379e7Schristos style="font-family: monospace;">libasprintf</span> subdirectory</h4> 144*946379e7Schristoslibtool (or more precisely, the version of libtool that was available 145*946379e7Schristosat the time the gettext release waas made) doesn't support linking C++ 146*946379e7Schristoslibraries with some versions of GCC. As a workaround, you can configure 147*946379e7Schristosgettext with the option <span style="font-family: monospace;">--disable-libasprintf</span>.<br> 148*946379e7Schristos<h4><a name="building_rpath_check"></a>During “make check”, some tests 149*946379e7Schristosnamed <span style="font-family: monospace;">rpath-<span 150*946379e7Schristos style="font-style: italic;">Nxyz</span></span> 151*946379e7Schristosfail: “ld: fatal error ... -lrpathz”</h4> 152*946379e7SchristosIf only a few among the many rpath tests fail, you can probably ignore 153*946379e7Schristosthe problem. The rpath tests are sensitive to incomplete shared library 154*946379e7Schristossupport in the system, and to bugs in libtool that creates the shared 155*946379e7Schristoslibraries. Some known failures are listed in <span 156*946379e7Schristos style="font-family: monospace;">autoconf-lib-link/tests/rpath.README</span>.<br> 157*946379e7Schristos<br> 158*946379e7SchristosTo ignore the problem, just proceed with<br> 159*946379e7Schristos<br> 160*946379e7Schristos<div style="margin-left: 40px;"><code>cd gettext-tools</code><br> 161*946379e7Schristos<code>make check</code><br> 162*946379e7Schristos<code>cd ..</code><br> 163*946379e7Schristos</div> 164*946379e7Schristos<br> 165*946379e7Schristos<h4><a name="building_install"></a>“make install” fails</h4> 166*946379e7Schristos“<span style="font-family: monospace;">make install DESTDIR=<span 167*946379e7Schristos style="font-style: italic;">/some/tempdir</span></span>” can fail with 168*946379e7Schristosan error message relating to <span style="font-family: monospace;">libgettextlib</span> 169*946379e7Schristosor <span style="font-family: monospace;">libgettextsrc</span>, or can 170*946379e7Schristossilently fail to install <span style="font-family: monospace;">libgettextsrc</span>. 171*946379e7SchristosOn some platforms, this is due to limitations of libtool regarding <span 172*946379e7Schristos style="font-family: monospace;">DESTDIR</span>. On other platforms, it 173*946379e7Schristosis due to the way the system handles shared libraries, and libtool 174*946379e7Schristoscannot work around it. Fortunately, on Linux and other glibc based 175*946379e7Schristossystems, <span style="font-family: monospace;">DESTDIR</span> is 176*946379e7Schristossupported if no different version of gettext is already installed (i.e. 177*946379e7Schristosit works if you uninstall the older gettext before building and 178*946379e7Schristosinstalling the newer one, or if you do a plain “<span 179*946379e7Schristos style="font-family: monospace;">make install</span>” before “<span 180*946379e7Schristos style="font-family: monospace;">make install DESTDIR=<span 181*946379e7Schristos style="font-style: italic;">/some/tempdir</span></span>”). On other 182*946379e7Schristossystems, when <span style="font-family: monospace;">DESTDIR</span> 183*946379e7Schristosdoes not work, you can still do “<span style="font-family: monospace;">make 184*946379e7Schristosinstall</span>” and copy the installed files to <span 185*946379e7Schristos style="font-family: monospace;"><span style="font-style: italic;">/some/tempdir</span></span> 186*946379e7Schristosafterwards.<br> 187*946379e7Schristos<br> 188*946379e7SchristosIf “<span style="font-family: monospace;">make install</span>” without <span 189*946379e7Schristos style="font-family: monospace;">DESTDIR</span> fails, it's a bug which 190*946379e7Schristosyou are welcome to report to the usual bug report address. 191*946379e7Schristos<h3>Problems integrating GNU gettext</h3> 192*946379e7Schristos<h4><a name="integrating_howto"></a>How do I make use of <span 193*946379e7Schristos style="font-family: monospace;">gettext()</span> in my package?</h4> 194*946379e7SchristosIt's not as difficult as it sounds. Here's the recipe for C or C++ 195*946379e7Schristosbased packages.<br> 196*946379e7Schristos<ul> 197*946379e7Schristos <li>Add an invocation of <span style="font-family: monospace;">AM_GNU_GETTEXT([external])</span> 198*946379e7Schristosto the package's <span style="font-family: monospace;">configure.{ac,in}</span> 199*946379e7Schristosfile.</li> 200*946379e7Schristos <li>Invoke “<span style="font-family: monospace;">gettextize --copy</span>”. 201*946379e7SchristosIt will do most of the autoconf/automake related work for you.</li> 202*946379e7Schristos <li>Add the <span style="font-family: monospace;">gettext.h</span> 203*946379e7Schristosfile to the package's source directory, and include it in all source 204*946379e7Schristosfiles that contain translatable strings or do output via <span 205*946379e7Schristos style="font-family: monospace;">printf</span> or <span 206*946379e7Schristos style="font-family: monospace;">fprintf</span>.</li> 207*946379e7Schristos <li>In the source file defining the main() function of the program, 208*946379e7Schristosadd these lines to the header<br> 209*946379e7Schristos <div style="margin-left: 40px;"><code><span 210*946379e7Schristos style="font-family: monospace;">#include <locale.h></span><br 211*946379e7Schristos style="font-family: monospace;"> 212*946379e7Schristos <span style="font-family: monospace;">#include "gettext.h"</span></code><br> 213*946379e7Schristos </div> 214*946379e7Schristosand these lines near the beginning of the main() function:<br> 215*946379e7Schristos <div style="margin-left: 40px;"><code><span 216*946379e7Schristos style="font-family: monospace;">setlocale (LC_ALL, "");</span><br 217*946379e7Schristos style="font-family: monospace;"> 218*946379e7Schristos <span style="font-family: monospace;">bindtextdomain (PACKAGE, 219*946379e7SchristosLOCALEDIR);</span><br style="font-family: monospace;"> 220*946379e7Schristos <span style="font-family: monospace;">textdomain (PACKAGE);</span></code><br> 221*946379e7Schristos </div> 222*946379e7Schristos </li> 223*946379e7Schristos <li>Mark all strings that should be translated with _(), like this: <span 224*946379e7Schristos style="font-family: monospace;">_("No errors found.")</span>. While 225*946379e7Schristosdoing this, try to turn the strings into good English, one entire 226*946379e7Schristossentence per string, not more than one paragraph per string, and use 227*946379e7Schristosformat strings instead of string concatenation. This is needed so that 228*946379e7Schristosthe translators can provide accurate translations.</li> 229*946379e7Schristos <li>In every source file containing translatable strings, add these lines 230*946379e7Schristosto the header:<br> 231*946379e7Schristos <div style="margin-left: 40px;"><code><span 232*946379e7Schristos style="font-family: monospace;">#include "gettext.h"</span><br 233*946379e7Schristos style="font-family: monospace;"> 234*946379e7Schristos <span style="font-family: monospace;">#define _(string) gettext (string)</span></code><br> 235*946379e7Schristos </div> 236*946379e7Schristos </li> 237*946379e7Schristos <li>In the freshly created <span style="font-family: monospace;">po/</span> 238*946379e7Schristosdirectory, set up the <span style="font-family: monospace;">POTFILES.in</span> 239*946379e7Schristosfile, and do a “<span style="font-family: monospace;">make update-po</span>”. 240*946379e7SchristosThen distribute the generated <span style="font-family: monospace;">.pot</span> 241*946379e7Schristosfile to your nearest translation project.</li> 242*946379e7Schristos <li>Shortly before a release, integrate the translators' <span 243*946379e7Schristos style="font-family: monospace;">.po</span> files into the <span 244*946379e7Schristos style="font-family: monospace;">po/</span> directory and do “<span 245*946379e7Schristos style="font-family: monospace;">make update-po</span>” again.<br> 246*946379e7Schristos </li> 247*946379e7Schristos</ul> 248*946379e7SchristosYou find detailed descriptions of how this all works in the GNU gettext 249*946379e7Schristosmanual, chapters “The Maintainer's View” and “Preparing Program 250*946379e7SchristosSources”. 251*946379e7Schristos<h4><a name="integrating_undefined"></a>I get a linker error “undefined 252*946379e7Schristosreference to libintl_gettext”</h4> 253*946379e7SchristosThis error means that the program uses the <span 254*946379e7Schristos style="font-family: monospace;">gettext()</span> function after having 255*946379e7Schristosincluded the <span style="font-family: monospace;"><libintl.h></span> 256*946379e7Schristosfile from GNU gettext (which remaps it to <span 257*946379e7Schristos style="font-family: monospace;">libintl_gettext()</span>), however at 258*946379e7Schristoslink time a function of this name could not be linked in. (It is 259*946379e7Schristosexpected to come from the <span style="font-family: monospace;">libintl</span> 260*946379e7Schristoslibrary, installed by GNU gettext.)<br> 261*946379e7Schristos<br> 262*946379e7SchristosThere are many possible reasons for this error, but in any case you 263*946379e7Schristosshould consider the <span style="font-family: monospace;">-I</span>, <span 264*946379e7Schristos style="font-family: monospace;">-L</span> and <span 265*946379e7Schristos style="font-family: monospace;">-l</span> options passed to the 266*946379e7Schristoscompiler. In packages using <span style="font-family: monospace;">autoconf</span> 267*946379e7Schristosgenerated configure scripts, <span style="font-family: monospace;">-I</span> 268*946379e7Schristosoptions come from the <span style="font-family: monospace;">CFLAGS</span> 269*946379e7Schristosand <span style="font-family: monospace;">CPPFLAGS</span> variables 270*946379e7Schristos(in Makefiles also <span style="font-family: monospace;">DEFS</span> 271*946379e7Schristosand <span style="font-family: monospace;">INCLUDES</span>), <span 272*946379e7Schristos style="font-family: monospace;">-L</span> options come from the <span 273*946379e7Schristos style="font-family: monospace;">LDFLAGS</span> variable, and <span 274*946379e7Schristos style="font-family: monospace;">-l</span> options come from the <span 275*946379e7Schristos style="font-family: monospace;">LIBS</span> variable. The first thing 276*946379e7Schristosyou should check are the values of these variables in your environment 277*946379e7Schristosand in the package's <span style="font-family: monospace;">config.status</span> 278*946379e7Schristosautoconfiguration result.<br> 279*946379e7Schristos<br> 280*946379e7SchristosTo find the cause of the error, a little analysis is needed. Does the 281*946379e7Schristosprogram's final link command contains the option “-lintl”?<br> 282*946379e7Schristos<ul> 283*946379e7Schristos <li>If yes:<br> 284*946379e7SchristosFind out where the <span style="font-family: monospace;">libintl</span> 285*946379e7Schristoscomes from. To do this, you have to check for <span 286*946379e7Schristos style="font-family: monospace;">libintl.a</span> and <span 287*946379e7Schristos style="font-family: monospace;">libintl.so*</span> (<span 288*946379e7Schristos style="font-family: monospace;">libintl.dylib</span> on MacOS X) in 289*946379e7Schristoseach directory given as a -L option, as well as in the compiler's 290*946379e7Schristosimplicit search directories. (You get these implicit search directories 291*946379e7Schristosfor gcc by using “<span style="font-family: monospace;">gcc -v</span>” 292*946379e7Schristosinstead of “<span style="font-family: monospace;">gcc</span>” in the 293*946379e7Schristosfinal link command line; compilers other than GCC usually look in <span 294*946379e7Schristos style="font-family: monospace;">/usr/lib</span> and <span 295*946379e7Schristos style="font-family: monospace;">/lib</span>.) A shell command like<br> 296*946379e7Schristos <div style="margin-left: 40px;"><code>$ for d in /usr/local/lib 297*946379e7Schristos/usr/lib /lib; do ls -l $d/libintl.*; done</code><br> 298*946379e7Schristos </div> 299*946379e7Schristoswill show where the <span style="font-family: monospace;">libintl</span> 300*946379e7Schristoscomes from. By looking at the dates and whether each library defines <span 301*946379e7Schristos style="font-family: monospace;">libintl_gettext</span> (via “<span 302*946379e7Schristos style="font-family: monospace;">nm <span style="font-style: italic;">path</span>/libintl.so 303*946379e7Schristos| grep libintl_gettext</span>”) you can now distinguish three possible 304*946379e7Schristoscauses of the error:<br> 305*946379e7Schristos <ul> 306*946379e7Schristos <li>Some older libintl is used instead of the newer one. The fix 307*946379e7Schristosis to remove the old library or to reorganize your -L options.</li> 308*946379e7Schristos <li>The used libintl is the new one, and it doesn't contain 309*946379e7Schristoslibintl_gettext. This would be a bug in gettext. If this is the case, 310*946379e7Schristosplease report it to the usual bug report address.</li> 311*946379e7Schristos <li>The used libintl is a static library (libintl.a), there are 312*946379e7Schristosno uses of gettext in .o files before the “-lintl” but there are some 313*946379e7Schristosafter the “-lintl”. In this case the fix is to move the “-lintl” to the 314*946379e7Schristosend or near the end of the link command line. The only libintl 315*946379e7Schristosdependency that needs to be mentioned after “-lintl” is “-liconv”.</li> 316*946379e7Schristos </ul> 317*946379e7Schristos </li> 318*946379e7Schristos <li>If no:<br> 319*946379e7SchristosIn this case it's likely a bug in the package you are building: The 320*946379e7Schristospackage's Makefiles should make sure that “-lintl” is used where needed.<br> 321*946379e7SchristosTest whether libintl was found by configure. You can check this by doing<br> 322*946379e7Schristos <div style="margin-left: 40px;"><code>$ grep 323*946379e7Schristos'\(INTLLIBS\|LIBINTL\)' config.status</code><br> 324*946379e7Schristos </div> 325*946379e7Schristosand looking whether the value of this autoconf variable is non-empty.<br> 326*946379e7Schristos <ul> 327*946379e7Schristos <li>If yes: It should be the responsibility of the Makefile to 328*946379e7Schristosuse the value of this variable in the link command line. Does the 329*946379e7SchristosMakefile.in rule for linking the program use <span 330*946379e7Schristos style="font-family: monospace;">@INTLLIBS@</span> or <span 331*946379e7Schristos style="font-family: monospace;">@LIBINTL@</span>?<br> 332*946379e7Schristos <ul> 333*946379e7Schristos <li>If no: It's a Makefile.am/in bug.</li> 334*946379e7Schristos <li>If yes: Something strange is going on. You need to dig 335*946379e7Schristosdeeper.</li> 336*946379e7Schristos </ul> 337*946379e7SchristosNote that <span style="font-family: monospace;">@INTLLIBS@</span> is 338*946379e7Schristosfor <span style="font-family: monospace;">gettext.m4</span> versions 339*946379e7Schristos<= 0.10.40 and <span style="font-family: monospace;">@LIBINTL@</span> 340*946379e7Schristosis for <span style="font-family: monospace;">gettext.m4</span> 341*946379e7Schristosversions >= 0.11, depending on which <span 342*946379e7Schristos style="font-family: monospace;">gettext.m4</span> was used to build 343*946379e7Schristosthe package's <span style="font-family: monospace;">configure</span> - 344*946379e7Schristosregardless of which gettext you have now installed.</li> 345*946379e7Schristos <li>If no: So libintl was not found.<br> 346*946379e7SchristosTake a look at the package's <span style="font-family: monospace;">configure.in/ac</span>. 347*946379e7SchristosDoes it invoke AM_GNU_GETTEXT?<br> 348*946379e7Schristos <ul> 349*946379e7Schristos <li>If no: The gettext maintainers take no responsibilities for 350*946379e7Schristoslookalikes named CY_GNU_GETTEXT, AM_GLIB_GNU_GETTEXT, AM_GNOME_GETTEXT 351*946379e7Schristosand similar, or for homebrewn autoconf checks. Complain to the package 352*946379e7Schristosmaintainer.</li> 353*946379e7Schristos <li>If yes: It looks like the <span 354*946379e7Schristos style="font-family: monospace;">-I</span> and <span 355*946379e7Schristos style="font-family: monospace;">-L</span> options were inconsistent. 356*946379e7SchristosYou should have a <span style="font-family: monospace;">-I<span 357*946379e7Schristos style="font-style: italic;">somedir</span>/include</span> in the <span 358*946379e7Schristos style="font-family: monospace;">CFLAGS</span> or <span 359*946379e7Schristos style="font-family: monospace;">CPPFLAGS</span> if and only if you 360*946379e7Schristosalso have a <span style="font-family: monospace;">-L<span 361*946379e7Schristos style="font-style: italic;">somedir</span>/lib</span> in the <span 362*946379e7Schristos style="font-family: monospace;">LDFLAGS</span>. And <span 363*946379e7Schristos style="font-family: monospace;"><span style="font-style: italic;">somedir</span>/include</span> 364*946379e7Schristosshould contain a <span style="font-family: monospace;">libintl.h</span> 365*946379e7Schristosif and only if <span style="font-family: monospace;"><span 366*946379e7Schristos style="font-style: italic;">somedir</span>/lib</span> contains <span 367*946379e7Schristos style="font-family: monospace;">libintl.{a,so}</span>.<br> 368*946379e7SchristosThis case can also happen if you have configured a GCC < 3.2 with 369*946379e7Schristosthe same <span style="font-family: monospace;">--prefix</span> option 370*946379e7Schristosas you used for GNU libiconv or GNU gettext. This is fatal, because 371*946379e7Schristosthese versions of GCC implicitly use <span 372*946379e7Schristos style="font-family: monospace;">-L<span style="font-style: italic;">prefix</span>/lib</span> 373*946379e7Schristosbut <span style="font-weight: bold; font-style: italic;">not</span><br 374*946379e7Schristos style="font-weight: bold; font-style: italic;"> 375*946379e7Schristos <span style="font-family: monospace;">-I<span 376*946379e7Schristos style="font-style: italic;">prefix</span>/include</span>. The 377*946379e7Schristosworkaround is to use a different <span style="font-family: monospace;">--prefix</span> 378*946379e7Schristosfor GCC.<br> 379*946379e7Schristos </li> 380*946379e7Schristos </ul> 381*946379e7Schristos </li> 382*946379e7Schristos </ul> 383*946379e7Schristos </li> 384*946379e7Schristos</ul> 385*946379e7Schristos<h4><a name="integrating_abuse_gettextize"></a>gettextize adds multiple 386*946379e7Schristosreferences to the same directories/files 387*946379e7Schristosto <span style="font-family: monospace;">Makefile.am</span> and <span 388*946379e7Schristos style="font-family: monospace;">configure.ac</span></h4> 389*946379e7SchristosIf <span style="font-family: monospace;">gettextize</span> is used on 390*946379e7Schristosa package, then the <span style="font-family: monospace;">po/</span>, <span 391*946379e7Schristos style="font-family: monospace;">intl/</span>, <span 392*946379e7Schristos style="font-family: monospace;">m4/</span> directories of the package 393*946379e7Schristosare removed, and then <span style="font-family: monospace;">gettextize</span> 394*946379e7Schristosis invoked on the package again, it will re-add the <span 395*946379e7Schristos style="font-family: monospace;">po/</span>, <span 396*946379e7Schristos style="font-family: monospace;">intl/</span>, <span 397*946379e7Schristos style="font-family: monospace;">m4/</span> directories and change <span 398*946379e7Schristos style="font-family: monospace;">Makefile.am</span>, <span 399*946379e7Schristos style="font-family: monospace;">configure.ac</span> and <span 400*946379e7Schristos style="font-family: monospace;">ChangeLog</span> accordingly. This is 401*946379e7Schristosnormal. The second use of <span style="font-family: monospace;">gettextize</span> 402*946379e7Schristoshere is an abuse of the program. <span style="font-family: monospace;">gettextize</span> 403*946379e7Schristosis a wizard intended to transform a <span style="font-style: italic;">working 404*946379e7Schristossource package</span> into a <span style="font-style: italic;">working 405*946379e7Schristossource package</span> that uses the newest version of gettext. If you 406*946379e7Schristosstart out from a nonfunctional source package (it is nonfunctional 407*946379e7Schristossince you have omitted some directories), you cannot expect that <span 408*946379e7Schristos style="font-family: monospace;">gettextize</span> corrects it.<br> 409*946379e7Schristos<br> 410*946379e7SchristosOften this question arises in packages that use CVS. See the section 411*946379e7Schristos“CVS Issues / Integrating with CVS” of the GNU gettext documentation. 412*946379e7SchristosThis section mentions a program <span style="font-family: monospace;">autopoint</span> 413*946379e7Schristoswhich is designed to reconstruct those files and directories created by 414*946379e7Schristos<span style="font-family: monospace;">gettextize</span> that can be 415*946379e7Schristosomitted from a CVS repository.<br> 416*946379e7Schristos<h4><a name="integrating_noop"></a>My program compiles and links fine, 417*946379e7Schristosbut doesn't output translated 418*946379e7Schristosstrings.</h4> 419*946379e7SchristosThere are several possible reasons. Here is a checklist that allows you 420*946379e7Schristosto determine the cause.<br> 421*946379e7Schristos<ol> 422*946379e7Schristos <li>Check that the environment variables LC_ALL, LC_MESSAGES, 423*946379e7SchristosLC_CTYPE, LANG, LANGUAGE together specify a valid locale and language.<br> 424*946379e7SchristosTo check this, run the commands<br> 425*946379e7Schristos <div style="margin-left: 40px;"><code>$ gettext --version</code><br> 426*946379e7Schristos <code>$ gettext --help</code><br> 427*946379e7Schristos </div> 428*946379e7SchristosYou should see at least some output in your desired language. If not, 429*946379e7Schristoseither<br> 430*946379e7Schristos <ul> 431*946379e7Schristos <li>You have chosen a too exotic language. <span 432*946379e7Schristos style="font-family: monospace;">gettext</span> is localized to 33 433*946379e7Schristoslanguages. Choose a less exotic language, such as Galician or 434*946379e7SchristosUkrainian. Or<br> 435*946379e7Schristos </li> 436*946379e7Schristos <li>There is a problem with your environment variables. Possibly 437*946379e7SchristosLC_ALL points to a locale that is not installed, or LC_MESSAGES and 438*946379e7SchristosLC_CTYPE are inconsistent.</li> 439*946379e7Schristos </ul> 440*946379e7Schristos </li> 441*946379e7Schristos <li>Check that your program contains a <span 442*946379e7Schristos style="font-family: monospace;">setlocale</span> call.<br> 443*946379e7SchristosTo check this, run your program under ltrace. For example,<br> 444*946379e7Schristos <div style="margin-left: 40px;"><code>$ ltrace ./myprog</code><br> 445*946379e7Schristos <code>...</code><br> 446*946379e7Schristos <code>setlocale(6, 447*946379e7Schristos"") 448*946379e7Schristos= "de_DE.UTF-8"</code><br> 449*946379e7Schristos </div> 450*946379e7SchristosIf you have no ltrace, you can also do this check by running your 451*946379e7Schristosprogram under the debugger. For example,<br> 452*946379e7Schristos <div style="margin-left: 40px;"><code>$ gdb ./myprog</code><br> 453*946379e7Schristos <code>(gdb) break main</code><br> 454*946379e7Schristos <code>(gdb) run</code><br> 455*946379e7Schristos <code>Breakpoint 1, main ()</code><br> 456*946379e7Schristos <code>(gdb) break setlocale</code><br> 457*946379e7Schristos <code>(gdb) continue</code><br> 458*946379e7Schristos <code>Breakpoint 2, setlocale ()</code><br> 459*946379e7Schristos <code>;; OK, the breakpoint has been hit, setlocale() is being 460*946379e7Schristoscalled.</code><br> 461*946379e7Schristos </div> 462*946379e7SchristosEither way, check that the return value of <span 463*946379e7Schristos style="font-family: monospace;">setlocale()</span> is non-NULL. A NULL 464*946379e7Schristosreturn value indicates a failure. </li> 465*946379e7Schristos <li>Check that your program contains a <span 466*946379e7Schristos style="font-family: monospace;">textdomain</span> call, a <span 467*946379e7Schristos style="font-family: monospace;">bindtextdomain</span> call referring 468*946379e7Schristosto the same message domain, and then really calls the <span 469*946379e7Schristos style="font-family: monospace;">gettext</span>, <span 470*946379e7Schristos style="font-family: monospace;">dgettext</span> or <span 471*946379e7Schristos style="font-family: monospace;">dcgettext</span> function.<br> 472*946379e7SchristosTo check this, run the program under ltrace. For example,<br> 473*946379e7Schristos <div style="margin-left: 40px;"><code>$ ltrace ./myprog</code><br> 474*946379e7Schristos <code>...</code><br> 475*946379e7Schristos <code>textdomain("hello-c") 476*946379e7Schristos= "hello-c"</code><br> 477*946379e7Schristos <code>bindtextdomain("hello-c", "/opt/share"...) = "/opt/share"...</code><br> 478*946379e7Schristos <code>dcgettext(0, 0x08048691, 5, 0x0804a200, 0x08048689) = 479*946379e7Schristos0x4001721f</code><br> 480*946379e7Schristos </div> 481*946379e7SchristosIf you have no ltrace, you can also do this check by running your 482*946379e7Schristosprogram under the debugger. For example,<br> 483*946379e7Schristos <div style="margin-left: 40px;"><code>$ gdb ./myprog</code><br> 484*946379e7Schristos <code>(gdb) break main</code><br> 485*946379e7Schristos <code>(gdb) run</code><br> 486*946379e7Schristos <code>Breakpoint 1, main ()</code><br> 487*946379e7Schristos <code>(gdb) break textdomain</code><br> 488*946379e7Schristos <code>(gdb) break bindtextdomain</code><br> 489*946379e7Schristos <code>(gdb) break gettext</code><br> 490*946379e7Schristos <code>(gdb) break dgettext</code><br> 491*946379e7Schristos <code>(gdb) break dcgettext</code><br> 492*946379e7Schristos <code>(gdb) continue</code><br> 493*946379e7Schristos <code>Breakpoint 2, textdomain ()</code><br> 494*946379e7Schristos <code>(gdb) continue</code><br> 495*946379e7Schristos <code>Breakpoint 3, bindtextdomain ()</code><br> 496*946379e7Schristos <code>(gdb) continue</code><br> 497*946379e7Schristos <code>Breakpoint 6, dcgettext ()</code><br> 498*946379e7Schristos </div> 499*946379e7SchristosNote that here <span style="font-family: monospace;">dcgettext()</span> 500*946379e7Schristosis called instead of the <span style="font-family: monospace;">gettext()</span> 501*946379e7Schristosfunction mentioned in the source code; this is due to an optimization 502*946379e7Schristosin <span style="font-family: monospace;"><libintl.h></span>.<br> 503*946379e7SchristosWhen using libintl on a non-glibc system, you have to add a prefix “<span 504*946379e7Schristos style="font-family: monospace;">libintl_</span>” to all the function 505*946379e7Schristosnames mentioned here, because that's what the functions are really 506*946379e7Schristosnamed, under the hood.<br> 507*946379e7SchristosIf <span style="font-family: monospace;">gettext</span>/<span 508*946379e7Schristos style="font-family: monospace;">dgettext</span>/<span 509*946379e7Schristos style="font-family: monospace;">dcgettext</span> is not called at all, 510*946379e7Schristosthe possible cause might be that some autoconf or Makefile macrology 511*946379e7Schristoshas turned off internationalization entirely (like the <span 512*946379e7Schristos style="font-family: monospace;">--disable-nls</span> configuration 513*946379e7Schristosoption usually does).<br> 514*946379e7Schristos </li> 515*946379e7Schristos <li>Check that the <span style="font-family: monospace;">.mo</span> 516*946379e7Schristosfile that contains the translation is really there where the program 517*946379e7Schristosexpects it.<br> 518*946379e7SchristosTo check this, run the program under strace and look at the <span 519*946379e7Schristos style="font-family: monospace;">open()</span> calls. For example,<br> 520*946379e7Schristos <div style="margin-left: 40px;"><code>$ strace ./myprog 2>&1 521*946379e7Schristos| grep '^open('</code><br> 522*946379e7Schristos <code>open("/etc/ld.so.preload", O_RDONLY) = -1 523*946379e7SchristosENOENT (No such file or directory)</code><br> 524*946379e7Schristos <code>open("/etc/ld.so.cache", 525*946379e7SchristosO_RDONLY) = 5</code><br> 526*946379e7Schristos <code>open("/lib/libc.so.6", 527*946379e7SchristosO_RDONLY) = 5</code><br> 528*946379e7Schristos <code>open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE) 529*946379e7Schristos= 5</code><br> 530*946379e7Schristos <code>open("/usr/share/locale/locale.alias", O_RDONLY) = 5</code><br> 531*946379e7Schristos <code>open("/opt/share/locale/de/LC_MESSAGES/hello-c.mo", O_RDONLY) 532*946379e7Schristos= 5</code><br> 533*946379e7Schristos <code>...</code><br> 534*946379e7Schristos </div> 535*946379e7SchristosA nonnegative <span style="font-family: monospace;">open()</span> 536*946379e7Schristosreturn value means that the file has been found.<br> 537*946379e7SchristosIf you have no strace, you can also guess the <span 538*946379e7Schristos style="font-family: monospace;">.mo</span> file's location: it is<br> 539*946379e7Schristos <div style="margin-left: 40px;"><span 540*946379e7Schristos style="font-family: monospace;"><span style="font-style: italic;">localedir</span>/<span 541*946379e7Schristos style="font-style: italic;">lang</span>/LC_MESSAGES/<span 542*946379e7Schristos style="font-style: italic;">domain</span>.mo</span><br> 543*946379e7Schristos </div> 544*946379e7Schristoswhere <span style="font-style: italic;">domain</span> is the argument 545*946379e7Schristospassed to <span style="font-family: monospace;">textdomain()</span>, <span 546*946379e7Schristos style="font-style: italic;">localedir</span> is the second argument 547*946379e7Schristospassed to <span style="font-family: monospace;">bindtextdomain()</span>, 548*946379e7Schristosand <span style="font-style: italic;">lang</span> is the language (<span 549*946379e7Schristos style="font-style: italic;">LL</span>) or language and territory (<span 550*946379e7Schristos style="font-style: italic;">LL</span>_<span style="font-style: italic;">CC</span>), 551*946379e7Schristosdepending on the environment variables checked in step 1.</li> 552*946379e7Schristos <li>Check that the .mo file contains a translation for the string 553*946379e7Schristosthat is being asked for.<br> 554*946379e7SchristosTo do this, you need to convert the .mo file back to PO file format, 555*946379e7Schristosthrough the command<br> 556*946379e7Schristos <div style="margin-left: 40px;"><code>$ msgunfmt </code><span 557*946379e7Schristos style="font-family: monospace;"><span style="font-style: italic;">localedir</span>/<span 558*946379e7Schristos style="font-style: italic;">lang</span>/LC_MESSAGES/<span 559*946379e7Schristos style="font-style: italic;">domain</span>.mo</span><br> 560*946379e7Schristos <code></code></div> 561*946379e7Schristosand look for an <span style="font-family: monospace;">msgid</span> 562*946379e7Schristosthat matches the given string.<br> 563*946379e7Schristos </li> 564*946379e7Schristos</ol> 565*946379e7Schristos<h3>GNU gettext on Windows</h3> 566*946379e7Schristos<h4><a name="windows_woe32"></a>What does Woe32 mean?</h4> 567*946379e7Schristos“Woe32” denotes the Windows 32-bit operating systems for x86: Windows 568*946379e7SchristosNT/2000/XP and Windows 95/98/ME. Microsoft uses the term “Win32” to 569*946379e7Schristosdenote these; this is a psychological trick in order to make everyone 570*946379e7Schristosbelieve that these OSes are a “win” for the user. However, for most 571*946379e7Schristosusers and developers, they are a source of woes, which is why I call 572*946379e7Schristosthem “Woe32”.<br> 573*946379e7Schristos<h4><a name="windows_howto"></a>How do I compile, link and run a 574*946379e7Schristosprogram that uses the gettext() 575*946379e7Schristosfunction?</h4> 576*946379e7SchristosWhen you use RedHat's cygwin environment, it's as on Unix:<br> 577*946379e7Schristos<ul> 578*946379e7Schristos <li>You need to add an <span style="font-family: monospace;">-I</span> 579*946379e7Schristosoption to the compilation command line, so that the compiler finds the <span 580*946379e7Schristos style="font-family: monospace;">libintl.h</span> include file, and</li> 581*946379e7Schristos <li>You need to add an <span style="font-family: monospace;">-L</span> 582*946379e7Schristosoption to the link command line, so that the linker finds the <span 583*946379e7Schristos style="font-family: monospace;">libintl</span> library.</li> 584*946379e7Schristos</ul> 585*946379e7SchristosWhen you use the Mingw environment (either from within cygwin, with <span 586*946379e7Schristos style="font-family: monospace;">CC="gcc -mno-cygwin"</span>, or from 587*946379e7SchristosMSYS, with <span style="font-family: monospace;">CC="gcc"</span>), I 588*946379e7Schristosdon't know the details.<br> 589*946379e7Schristos<br> 590*946379e7SchristosWhen you use the Microsoft Visual C/C++ (MSVC) compiler, you will 591*946379e7Schristoslikely use the precompiled Woe32 binaries. For running a program that 592*946379e7Schristosuses gettext(), one needs the <span style="font-family: monospace;">.bin.woe32.zip</span> 593*946379e7Schristospackages of <span style="font-family: monospace;">gettext-runtime</span> 594*946379e7Schristosand <span style="font-family: monospace;">libiconv</span>. As a 595*946379e7Schristosdeveloper, you'll also need the <span style="font-family: monospace;">xgettext</span> 596*946379e7Schristosand <span style="font-family: monospace;">msgfmt</span> programs that 597*946379e7Schristosare contained in the <span style="font-family: monospace;">.bin.woe32.zip</span> 598*946379e7Schristospackage of <span style="font-family: monospace;">gettext-tools</span>. 599*946379e7SchristosThen<br> 600*946379e7Schristos<ul> 601*946379e7Schristos <li>You need to add an <span style="font-family: monospace;">-MD</span> 602*946379e7Schristosoption to all compilation and link command lines. MSVC has six 603*946379e7Schristosdifferent, mutually incompatible, compilation models (<span 604*946379e7Schristos style="font-family: monospace;">-ML</span>, <span 605*946379e7Schristos style="font-family: monospace;">-MT</span>, <span 606*946379e7Schristos style="font-family: monospace;">-MD</span>, <span 607*946379e7Schristos style="font-family: monospace;">-MLd</span>, <span 608*946379e7Schristos style="font-family: monospace;">-MTd</span>, <span 609*946379e7Schristos style="font-family: monospace;">-MDd</span>); the default is <span 610*946379e7Schristos style="font-family: monospace;">-ML</span>. <span 611*946379e7Schristos style="font-family: monospace;">intl.dll</span> uses the <span 612*946379e7Schristos style="font-family: monospace;">-MD</span> model, therefore the rest 613*946379e7Schristosof the program must use <span style="font-family: monospace;">-MD</span> 614*946379e7Schristosas well.<br> 615*946379e7Schristos </li> 616*946379e7Schristos <li>You need to add an <span style="font-family: monospace;">-I</span> 617*946379e7Schristosoption to the compilation command line, so that the compiler finds the <span 618*946379e7Schristos style="font-family: monospace;">libintl.h</span> include file.<br> 619*946379e7Schristos </li> 620*946379e7Schristos <li>You need to add an <span style="font-family: monospace;">-L</span> 621*946379e7Schristosoption to the link command line, so that the linker finds the <span 622*946379e7Schristos style="font-family: monospace;">intl.lib</span> library.</li> 623*946379e7Schristos <li>You need to copy the <span style="font-family: monospace;">intl.dll</span> 624*946379e7Schristosand <span style="font-family: monospace;">iconv.dll</span> to the 625*946379e7Schristosdirectory where your <span style="font-family: monospace;">.exe</span> 626*946379e7Schristosfiles are created, so that they will be found at runtime.<br> 627*946379e7Schristos </li> 628*946379e7Schristos</ul> 629*946379e7Schristos<h4><a name="windows_setenv"></a>Setting the <span 630*946379e7Schristos style="font-family: monospace;">LANG</span> 631*946379e7Schristosenvironment variable doesn't have any effect</h4> 632*946379e7SchristosIf neither LC_ALL, LC_MESSAGES nor LANGUAGES is set, it's the LANG 633*946379e7Schristosenvironment variable which determines the language into which gettext() 634*946379e7Schristostranslates the messages.<br> 635*946379e7Schristos<br> 636*946379e7SchristosYou can test your program by setting the LANG environment variable from 637*946379e7Schristosoutside the program. In a Windows command interpreter:<br> 638*946379e7Schristos<div style="margin-left: 40px;"><code>set LANG=de_DE</code><br> 639*946379e7Schristos<code>.\myprog.exe</code><br> 640*946379e7Schristos</div> 641*946379e7SchristosOr in a Cygwin shell:<br> 642*946379e7Schristos<div style="margin-left: 40px;"><code>$ env LANG=de_DE ./myprog.exe</code><br> 643*946379e7Schristos</div> 644*946379e7Schristos<br> 645*946379e7SchristosIf this test fails, look at the question “My program compiles and links 646*946379e7Schristosfine, but doesn't output translated 647*946379e7Schristosstrings.” above.<br> 648*946379e7Schristos<br> 649*946379e7SchristosIf this test succeeds, the problem is related in the way you set the 650*946379e7Schristosenvironment variable. Here is a checklist:<br> 651*946379e7Schristos<ul> 652*946379e7Schristos <li>Check that you are using the <span 653*946379e7Schristos style="font-family: monospace;">-MD</span> option in all compilation 654*946379e7Schristosand link command lines. Otherwise you might end up calling the <span 655*946379e7Schristos style="font-family: monospace;">putenv()</span> function from 656*946379e7SchristosMicrosoft's <span style="font-family: monospace;">libc.lib</span>, 657*946379e7Schristoswhereas <span style="font-family: monospace;">intl.dll</span> is using 658*946379e7Schristosthe <span style="font-family: monospace;">getenv()</span> function 659*946379e7Schristosfrom Mictosoft's <span style="font-family: monospace;">msvcrt.lib</span>.</li> 660*946379e7Schristos <li>Check that you set the environment variable using <span 661*946379e7Schristos style="font-style: italic;">both</span> <span 662*946379e7Schristos style="font-family: monospace;">SetEnvironmentVariable()</span> and <span 663*946379e7Schristos style="font-family: monospace;">putenv()</span>. A convenient way to 664*946379e7Schristosdo so, and to deal with the fact that some Unix systems have <span 665*946379e7Schristos style="font-family: monospace;">setenv()</span> and some don't, is the 666*946379e7Schristosfollowing function.<br> 667*946379e7Schristos <br> 668*946379e7Schristos <div style="margin-left: 40px;"><code>#include <string.h></code><br> 669*946379e7Schristos <code>#include <stdlib.h></code><br> 670*946379e7Schristos <code>#if defined _WIN32</code><br> 671*946379e7Schristos <code># include <windows.h></code><br> 672*946379e7Schristos <code>#endif</code><br> 673*946379e7Schristos <code></code><br> 674*946379e7Schristos <code>int my_setenv (const char * name, const char * value) {</code><br> 675*946379e7Schristos <code> size_t namelen = strlen(name);</code><br> 676*946379e7Schristos <code> size_t valuelen = (value==NULL ? 0 : strlen(value));</code><br> 677*946379e7Schristos <code>#if defined _WIN32</code><br> 678*946379e7Schristos <code> /* On Woe32, each process has two copies of the 679*946379e7Schristosenvironment variables,</code><br> 680*946379e7Schristos <code> one managed by the OS and one 681*946379e7Schristosmanaged by the C library. We set</code><br> 682*946379e7Schristos <code> the value in both locations, so that 683*946379e7Schristosother software that looks in</code><br> 684*946379e7Schristos <code> one place or the other is guaranteed 685*946379e7Schristosto see the value. Even if it's</code><br> 686*946379e7Schristos <code> a bit slow. See also</code><br> 687*946379e7Schristos <code> <<a 688*946379e7Schristos href="http://article.gmane.org/gmane.comp.gnu.mingw.user/8272">http://article.gmane.org/gmane.comp.gnu.mingw.user/8272</a>></code><br> 689*946379e7Schristos <code> <<a 690*946379e7Schristos href="http://article.gmane.org/gmane.comp.gnu.mingw.user/8273">http://article.gmane.org/gmane.comp.gnu.mingw.user/8273</a>></code><br> 691*946379e7Schristos <code> <<a 692*946379e7Schristos href="http://www.cygwin.com/ml/cygwin/1999-04/msg00478.html">http://www.cygwin.com/ml/cygwin/1999-04/msg00478.html</a>> 693*946379e7Schristos*/</code><br> 694*946379e7Schristos <code> if (!SetEnvironmentVariableA(name,value))</code><br> 695*946379e7Schristos <code> return -1; </code><br> 696*946379e7Schristos <code>#endif</code><br> 697*946379e7Schristos <code>#if defined(HAVE_PUTENV)</code><br> 698*946379e7Schristos <code> char* buffer = (char*)malloc(namelen+1+valuelen+1);</code><br> 699*946379e7Schristos <code> if (!buffer)</code><br> 700*946379e7Schristos <code> return -1; /* no need to set errno = 701*946379e7SchristosENOMEM */</code><br> 702*946379e7Schristos <code> memcpy(buffer,name,namelen);</code><br> 703*946379e7Schristos <code> if (value != NULL) {</code><br> 704*946379e7Schristos <code> buffer[namelen] = '=';</code><br> 705*946379e7Schristos <code> memcpy(buffer+namelen+1,value,valuelen);</code><br> 706*946379e7Schristos <code> buffer[namelen+1+valuelen] = 0;</code><br> 707*946379e7Schristos <code> } else</code><br> 708*946379e7Schristos <code> buffer[namelen] = 0;</code><br> 709*946379e7Schristos <code> return putenv(buffer);</code><br> 710*946379e7Schristos <code>#elif defined(HAVE_SETENV)</code><br> 711*946379e7Schristos <code> return setenv(name,value,1);</code><br> 712*946379e7Schristos <code>#else</code><br> 713*946379e7Schristos <code> /* Uh oh, neither putenv() nor setenv() ... */</code><br> 714*946379e7Schristos <code> return -1;</code><br> 715*946379e7Schristos <code>#endif</code><br> 716*946379e7Schristos <code>}</code><br> 717*946379e7Schristos <code></code></div> 718*946379e7Schristos <br> 719*946379e7Schristos </li> 720*946379e7Schristos</ul> 721*946379e7Schristos<h3>Other</h3> 722*946379e7Schristos<h4><a name="newline"></a>What does this mean: “`msgid' and `msgstr' 723*946379e7Schristosentries do not both end 724*946379e7Schristoswith '\n'”</h4> 725*946379e7SchristosIt means that when the original string ends in a newline, your 726*946379e7Schristostranslation must also end in a newline. And if the original string does 727*946379e7Schristosnot end in a newline, then your translation should likewise not have a 728*946379e7Schristosnewline at the end.<br> 729*946379e7Schristos<h4><a name="translit"></a>German umlauts are displayed like 730*946379e7Schristos“ge"andert” instead of “geändert”</h4> 731*946379e7SchristosThis symptom occurs when the <span style="font-family: monospace;">LC_CTYPE</span> 732*946379e7Schristosfacet of the locale is not set; then gettext() doesn't know which 733*946379e7Schristoscharacter set to use, and converts all messages to ASCII, as far as 734*946379e7Schristospossible.<br> 735*946379e7Schristos<br> 736*946379e7SchristosIf the program is doing<br> 737*946379e7Schristos<code><br> 738*946379e7Schristossetlocale (LC_MESSAGES, "");<br> 739*946379e7Schristos<br> 740*946379e7Schristos</code>then change it to<br> 741*946379e7Schristos<code><br> 742*946379e7Schristossetlocale (LC_CTYPE, "");<br> 743*946379e7Schristossetlocale (LC_MESSAGES, "");<br> 744*946379e7Schristos</code><br> 745*946379e7Schristosor do both of these in a single call:<br> 746*946379e7Schristos<code><br> 747*946379e7Schristossetlocale (LC_ALL, "");<br> 748*946379e7Schristos</code><br> 749*946379e7SchristosIf the program is already doing<br> 750*946379e7Schristos<code><br> 751*946379e7Schristossetlocale (LC_ALL, "");<br> 752*946379e7Schristos</code><br> 753*946379e7Schristosthen the symptom can still occur if the user has not set <span 754*946379e7Schristos style="font-family: monospace;">LANG</span>, but instead has set <span 755*946379e7Schristos style="font-family: monospace;">LC_MESSAGES</span> to a valid locale 756*946379e7Schristosand has set <span style="font-family: monospace;">LC_CTYPE</span> to 757*946379e7Schristosnothing or an invalid locale. The fix for the user is then to set <span 758*946379e7Schristos style="font-family: monospace;">LANG</span> instead of <span 759*946379e7Schristos style="font-family: monospace;">LC_MESSAGES</span>.<br> 760*946379e7Schristos<h4><a name="localename"></a>The <span style="font-family: monospace;">LANGUAGE</span> 761*946379e7Schristosenvironment variable is ignored after I set <span 762*946379e7Schristos style="font-family: monospace;">LANG=en</span></h4> 763*946379e7SchristosThis is because “en” is a language name, but not a valid locale name. 764*946379e7SchristosThe <span style="font-family: monospace;">ABOUT-NLS</span> file 765*946379e7Schristossays:<br> 766*946379e7Schristos<blockquote> 767*946379e7SchristosIn the <span style="font-family: monospace;">LANGUAGE</span> 768*946379e7Schristosenvironment variable, but not in the <span 769*946379e7Schristos style="font-family: monospace;">LANG</span> environment variable, <span 770*946379e7Schristos style="font-style: italic;">LL</span>_<span style="font-style: italic;">CC</span><span 771*946379e7Schristos style="font-family: monospace;"> </span>combinations can be 772*946379e7Schristosabbreviated as <span style="font-style: italic;">LL</span> to 773*946379e7Schristosdenote the language's main dialect.</blockquote> 774*946379e7SchristosWhy is <span style="font-family: monospace;">LANG=en</span> not 775*946379e7Schristosallowed? Because <span style="font-family: monospace;">LANG</span> is 776*946379e7Schristosa setting for the entire locale, including monetary information, and 777*946379e7Schristosthis depends on the country: en_GB, en_AU, en_ZA all have different 778*946379e7Schristoscurrencies.<br> 779*946379e7Schristos<h4><a name="nonascii_strings"></a>I use accented characters in my 780*946379e7Schristossource code. How do I tell the 781*946379e7SchristosC/C++ compiler in which encoding it is (like <span 782*946379e7Schristos style="font-family: monospace;">xgettext</span>'s <span 783*946379e7Schristos style="font-family: monospace;">--from-code</span> option)?</h4> 784*946379e7SchristosShort answer: If you want your program to be useful to other people, 785*946379e7Schristosthen <span style="font-style: italic;">don't use accented characters</span> 786*946379e7Schristos(or other non-ASCII characters) in string literals <span 787*946379e7Schristos style="font-style: italic;">in the source code</span>. Instead, use 788*946379e7Schristosonly ASCII for string literals, and use <span 789*946379e7Schristos style="font-family: monospace;">gettext()</span> to retrieve their 790*946379e7Schristosdisplay-ready form.<br> 791*946379e7Schristos<br> 792*946379e7SchristosLong explanation:<br> 793*946379e7SchristosThe reason is that the ISO C standard specifies that the character set 794*946379e7Schristosat compilation time can be different from the character set at 795*946379e7Schristosexecution time.<br> 796*946379e7SchristosThe character encoding at compilation time is the one which determines 797*946379e7Schristoshow the source files are interpreted and also how string literals are 798*946379e7Schristosstored in the compiled code. This character encoding is generally 799*946379e7Schristosunspecified; for recent versions of GCC, it depends on the LC_CTYPE 800*946379e7Schristoslocale in effect during the compilation process.<br> 801*946379e7SchristosThe character encoding at execution time is the one which determines 802*946379e7Schristoshow standard functions like <span style="font-family: monospace;">isprint()</span>, 803*946379e7Schristos<span style="font-family: monospace;">wcwidth()</span> etc. work and 804*946379e7Schristoshow strings written to standard output should be encoded. This 805*946379e7Schristoscharacter encoding is specified by POSIX to depend on the LC_CTYPE 806*946379e7Schristoslocale in effect when the program is executed; see also the description 807*946379e7Schristosin the <span style="font-family: monospace;">ABOUT-NLS</span> file.<br> 808*946379e7SchristosStrings in the compiled code are not magically converted between the 809*946379e7Schristostime the program is compiled and the time it is run.<br> 810*946379e7Schristos<br> 811*946379e7SchristosTherefore what could you do to get accented characters to work?<br> 812*946379e7Schristos<br> 813*946379e7SchristosCan you ensure that the execution character set is the same as the 814*946379e7Schristoscompilation character set? Even if your program is to be used only in a 815*946379e7Schristossingle country, this is not realistically possible. For example, in 816*946379e7SchristosGermany there are currently three character encodings in use: UTF-8, 817*946379e7SchristosISO-8859-15 and ISO-8859-1. Therefore you would have to explicitly 818*946379e7Schristosconvert the accented strings from the compilation character set to the 819*946379e7Schristosexecution character set at runtime, for example through iconv().<br> 820*946379e7Schristos<br> 821*946379e7SchristosCan you ensure that the compilation character set is the one in which 822*946379e7Schristosyour source files are stored? This is not realistically possible 823*946379e7Schristoseither: For compilers other than GCC, there is no way to specify the 824*946379e7Schristoscompilation character set. So let's assume for a moment that everyone 825*946379e7Schristosuses GCC; then you will specify the LC_CTYPE or LC_ALL environment 826*946379e7Schristosvariable in the Makefile. But for this you have to assume that everyone 827*946379e7Schristoshas a locale in a given encoding. Be it UTF-8 or ISO-8859-1 - this is 828*946379e7Schristosnot realistic. People often have no locale installed besides the one 829*946379e7Schristosthey use.<br> 830*946379e7Schristos<br> 831*946379e7SchristosUse of wide strings <span style="font-family: monospace;">L"..."</span> 832*946379e7Schristosdoesn't help solving the problem, because on systems like FreeBSD or 833*946379e7SchristosSolaris, the way how wide string literals are stored in compiled code 834*946379e7Schristosdepends on the compilation character set, just as it does for 835*946379e7Schristosnarrow strings <span style="font-family: monospace;">"..."</span>. 836*946379e7SchristosMoreover, wide strings have problems of their own.<br> 837*946379e7Schristos<br> 838*946379e7SchristosUse of ISO C 99 Unicode escapes "\u<span style="font-style: italic;">xxxx</span>" 839*946379e7Schristosdoesn't help either because these characters are converted to the 840*946379e7Schristoscompilation character set at compile time; so again, since you can't 841*946379e7Schristosguarantee that the compilation character set is not ASCII, you're 842*946379e7Schristosrisking compilation errors just as if the real character had been used 843*946379e7Schristosin the source instead of the Unicode escape.<br> 844*946379e7Schristos<br> 845*946379e7SchristosSo, in summary, there is no way to make accented characters in string 846*946379e7Schristosliterals work in C/C++.<br> 847*946379e7Schristos<br> 848*946379e7SchristosYou might then wonder what <span style="font-family: monospace;">xgettext</span>'s 849*946379e7Schristos<span style="font-family: monospace;">--from-code</span> option is good 850*946379e7Schristosfor. The answer is<br> 851*946379e7Schristos<ol> 852*946379e7Schristos <li>For the comments in C/C++ source code. The compiler ignores them.<br> 853*946379e7Schristos </li> 854*946379e7Schristos <li>For other programming languages like Java, for which the compiler 855*946379e7Schristosconverts all string literals to UTF-8.</li> 856*946379e7Schristos</ol> 857*946379e7Schristos<br> 858*946379e7Schristos<hr style="width: 100%; height: 2px;"> 859*946379e7Schristos<address>GNU gettext FAQ<br> 860*946379e7SchristosBruno Haible <<a href="mailto:bruno@clisp.org">bruno@clisp.org</a>></address> 861*946379e7Schristos<p>Last modified: 24 February 2004 862*946379e7Schristos</p> 863*946379e7Schristos</body> 864*946379e7Schristos</html> 865