| blob | 594e75d90fef5cb1a1ac0be34f2afdda3d5ea8c5 |
2 <html>
3 <head>
6 </head>
7 <body>
9 for GNU gettext
10 </h1>
13 <ul>
17 releases.</a></li>
18 </ul>
20 <ul>
22 error “text relocations remain” in the <span
27 fail: “ld: fatal error ... -lrpathz”</a></li>
29 </ul>
31 <ul>
35 reference to libintl_gettext”</a></li>
37 references to the same directories/files
40 </span></li>
42 but doesn't output translated
43 strings.</a><br>
44 </li>
45 </ul>
47 <ul>
50 that uses the gettext()
51 function?</a><br>
52 </li>
55 environment variable doesn't have any effect</a></li>
56 </ul>
58 <ul>
60 entries do not both
61 end with '\n'”</a></li>
63 instead of
64 “geändert”</a></li>
66 environment variable is ignored after I set <span
69 source code. How do I tell the
70 C/C++ compiler in which encoding it is (like <span
73 </ul>
75 <h3>General</h3>
77 Three mailing lists are available: <br>
78 <ul>
80 This mailing list is for discussion of features and bugs of the GNU
82 libintl, the gettext-tools, and its autoconf macros.</li>
84 This mailing list is for methodology questions around
85 internationalization, and for discussions of translator tools,
86 including but not limited to GNU gettext.</li>
88 This is the email address of the <a
90 Project</a>, that is the project which manages the translated message
91 catalogs for many free software packages. Note that KDE and GNOME
92 packages are not part of this project; they have their own translation
95 </li>
96 </ul>
98 is archived as part of the <a
102 subscribed on its own; to receive its contents by mail, subscribe to <span
105 The newest gettext release is available on <span
108 <br>
109 Prereleases are announced on the <a
112 Note that prereleases are meant for testing and not meant for use in
113 production environments. Please don't use the “gettextize” program of a
114 prerelease on projects which you share with other programmers via CVS.<br>
115 <br>
116 If you want to live on the bleeding edge, you can also use the
117 development sources. Instructions for retrieving the gettext CVS are
119 Note that building from CVS requires special tools (autoconf, automake,
120 m4, groff, bison, etc.) and requires that you pay attention to the <span
124 releases.</h4>
125 If you are interested in stable gettext releases, you can follow the <a
128 is also available as a newsgroup <a
133 <br>
134 You can also periodically check the download location.<br>
135 <br>
136 If you are interested in testing prereleases as well, you can subscribe
139 list</a>.<br>
140 <h3>Problems building GNU gettext</h3>
142 build error “text relocations remain” in the <span
144 libtool (or more precisely, the version of libtool that was available
145 at the time the gettext release waas made) doesn't support linking C++
146 libraries with some versions of GCC. As a workaround, you can configure
151 fail: “ld: fatal error ... -lrpathz”</h4>
152 If only a few among the many rpath tests fail, you can probably ignore
153 the problem. The rpath tests are sensitive to incomplete shared library
154 support in the system, and to bugs in libtool that creates the shared
155 libraries. Some known failures are listed in <span
157 <br>
158 To ignore the problem, just proceed with<br>
159 <br>
161 <code>make check</code><br>
162 <code>cd ..</code><br>
163 </div>
164 <br>
171 On some platforms, this is due to limitations of libtool regarding <span
173 is due to the way the system handles shared libraries, and libtool
174 cannot work around it. Fortunately, on Linux and other glibc based
176 supported if no different version of gettext is already installed (i.e.
177 it works if you uninstall the older gettext before building and
178 installing the newer one, or if you do a plain “<span
184 install</span>” and copy the installed files to <span
186 afterwards.<br>
187 <br>
190 you are welcome to report to the usual bug report address.
191 <h3>Problems integrating GNU gettext</h3>
194 It's not as difficult as it sounds. Here's the recipe for C or C++
195 based packages.<br>
196 <ul>
197 <li>Add an invocation of <span style="font-family: monospace;">AM_GNU_GETTEXT([external])</span>
199 file.</li>
201 It will do most of the autoconf/automake related work for you.</li>
203 file to the package's source directory, and include it in all source
204 files that contain translatable strings or do output via <span
207 <li>In the source file defining the main() function of the program,
208 add these lines to the header<br>
213 </div>
214 and these lines near the beginning of the main() function:<br>
221 </div>
222 </li>
223 <li>Mark all strings that should be translated with _(), like this: <span
225 doing this, try to turn the strings into good English, one entire
226 sentence per string, not more than one paragraph per string, and use
227 format strings instead of string concatenation. This is needed so that
228 the translators can provide accurate translations.</li>
229 <li>In every source file containing translatable strings, add these lines
230 to the header:<br>
235 </div>
236 </li>
241 file to your nearest translation project.</li>
242 <li>Shortly before a release, integrate the translators' <span
246 </li>
247 </ul>
248 You find detailed descriptions of how this all works in the GNU gettext
249 manual, chapters “The Maintainer's View” and “Preparing Program
250 Sources”.
252 reference to libintl_gettext”</h4>
253 This error means that the program uses the <span
256 file from GNU gettext (which remaps it to <span
258 link time a function of this name could not be linked in. (It is
260 library, installed by GNU gettext.)<br>
261 <br>
262 There are many possible reasons for this error, but in any case you
276 you should check are the values of these variables in your environment
278 autoconfiguration result.<br>
279 <br>
280 To find the cause of the error, a little analysis is needed. Does the
281 program's final link command contains the option “-lintl”?<br>
282 <ul>
283 <li>If yes:<br>
285 comes from. To do this, you have to check for <span
289 each directory given as a -L option, as well as in the compiler's
290 implicit search directories. (You get these implicit search directories
293 final link command line; compilers other than GCC usually look in <span
297 /usr/lib /lib; do ls -l $d/libintl.*; done</code><br>
298 </div>
300 comes from. By looking at the dates and whether each library defines <span
303 | grep libintl_gettext</span>”) you can now distinguish three possible
304 causes of the error:<br>
305 <ul>
306 <li>Some older libintl is used instead of the newer one. The fix
307 is to remove the old library or to reorganize your -L options.</li>
308 <li>The used libintl is the new one, and it doesn't contain
309 libintl_gettext. This would be a bug in gettext. If this is the case,
310 please report it to the usual bug report address.</li>
311 <li>The used libintl is a static library (libintl.a), there are
312 no uses of gettext in .o files before the “-lintl” but there are some
313 after the “-lintl”. In this case the fix is to move the “-lintl” to the
314 end or near the end of the link command line. The only libintl
315 dependency that needs to be mentioned after “-lintl” is “-liconv”.</li>
316 </ul>
317 </li>
318 <li>If no:<br>
319 In this case it's likely a bug in the package you are building: The
320 package's Makefiles should make sure that “-lintl” is used where needed.<br>
321 Test whether libintl was found by configure. You can check this by doing<br>
323 '\(INTLLIBS\|LIBINTL\)' config.status</code><br>
324 </div>
325 and looking whether the value of this autoconf variable is non-empty.<br>
326 <ul>
327 <li>If yes: It should be the responsibility of the Makefile to
328 use the value of this variable in the link command line. Does the
329 Makefile.in rule for linking the program use <span
332 <ul>
333 <li>If no: It's a Makefile.am/in bug.</li>
334 <li>If yes: Something strange is going on. You need to dig
335 deeper.</li>
336 </ul>
341 versions >= 0.11, depending on which <span
344 regardless of which gettext you have now installed.</li>
345 <li>If no: So libintl was not found.<br>
347 Does it invoke AM_GNU_GETTEXT?<br>
348 <ul>
349 <li>If no: The gettext maintainers take no responsibilities for
350 lookalikes named CY_GNU_GETTEXT, AM_GLIB_GNU_GETTEXT, AM_GNOME_GETTEXT
351 and similar, or for homebrewn autoconf checks. Complain to the package
352 maintainer.</li>
353 <li>If yes: It looks like the <span
368 This case can also happen if you have configured a GCC < 3.2 with
370 as you used for GNU libiconv or GNU gettext. This is fatal, because
371 these versions of GCC implicitly use <span
378 for GCC.<br>
379 </li>
380 </ul>
381 </li>
382 </ul>
383 </li>
384 </ul>
386 references to the same directories/files
394 is invoked on the package again, it will re-add the <span
405 source package</span> that uses the newest version of gettext. If you
406 start out from a nonfunctional source package (it is nonfunctional
407 since you have omitted some directories), you cannot expect that <span
409 <br>
410 Often this question arises in packages that use CVS. See the section
411 “CVS Issues / Integrating with CVS” of the GNU gettext documentation.
413 which is designed to reconstruct those files and directories created by
415 omitted from a CVS repository.<br>
417 but doesn't output translated
418 strings.</h4>
419 There are several possible reasons. Here is a checklist that allows you
420 to determine the cause.<br>
421 <ol>
422 <li>Check that the environment variables LC_ALL, LC_MESSAGES,
423 LC_CTYPE, LANG, LANGUAGE together specify a valid locale and language.<br>
424 To check this, run the commands<br>
426 <code>$ gettext --help</code><br>
427 </div>
428 You should see at least some output in your desired language. If not,
429 either<br>
430 <ul>
431 <li>You have chosen a too exotic language. <span
433 languages. Choose a less exotic language, such as Galician or
434 Ukrainian. Or<br>
435 </li>
436 <li>There is a problem with your environment variables. Possibly
437 LC_ALL points to a locale that is not installed, or LC_MESSAGES and
438 LC_CTYPE are inconsistent.</li>
439 </ul>
440 </li>
441 <li>Check that your program contains a <span
443 To check this, run your program under ltrace. For example,<br>
445 <code>...</code><br>
446 <code>setlocale(6,
447 "")
449 </div>
450 If you have no ltrace, you can also do this check by running your
451 program under the debugger. For example,<br>
453 <code>(gdb) break main</code><br>
454 <code>(gdb) run</code><br>
455 <code>Breakpoint 1, main ()</code><br>
456 <code>(gdb) break setlocale</code><br>
457 <code>(gdb) continue</code><br>
458 <code>Breakpoint 2, setlocale ()</code><br>
459 <code>;; OK, the breakpoint has been hit, setlocale() is being
460 called.</code><br>
461 </div>
462 Either way, check that the return value of <span
464 return value indicates a failure. </li>
465 <li>Check that your program contains a <span
468 to the same message domain, and then really calls the <span
472 To check this, run the program under ltrace. For example,<br>
474 <code>...</code><br>
475 <code>textdomain("hello-c")
478 <code>dcgettext(0, 0x08048691, 5, 0x0804a200, 0x08048689) =
479 0x4001721f</code><br>
480 </div>
481 If you have no ltrace, you can also do this check by running your
482 program under the debugger. For example,<br>
484 <code>(gdb) break main</code><br>
485 <code>(gdb) run</code><br>
486 <code>Breakpoint 1, main ()</code><br>
487 <code>(gdb) break textdomain</code><br>
488 <code>(gdb) break bindtextdomain</code><br>
489 <code>(gdb) break gettext</code><br>
490 <code>(gdb) break dgettext</code><br>
491 <code>(gdb) break dcgettext</code><br>
492 <code>(gdb) continue</code><br>
493 <code>Breakpoint 2, textdomain ()</code><br>
494 <code>(gdb) continue</code><br>
495 <code>Breakpoint 3, bindtextdomain ()</code><br>
496 <code>(gdb) continue</code><br>
497 <code>Breakpoint 6, dcgettext ()</code><br>
498 </div>
501 function mentioned in the source code; this is due to an optimization
503 When using libintl on a non-glibc system, you have to add a prefix “<span
505 names mentioned here, because that's what the functions are really
506 named, under the hood.<br>
510 the possible cause might be that some autoconf or Makefile macrology
511 has turned off internationalization entirely (like the <span
513 option usually does).<br>
514 </li>
516 file that contains the translation is really there where the program
517 expects it.<br>
518 To check this, run the program under strace and look at the <span
521 | grep '^open('</code><br>
523 ENOENT (No such file or directory)</code><br>
525 O_RDONLY) = 5</code><br>
527 O_RDONLY) = 5</code><br>
529 = 5</code><br>
532 = 5</code><br>
533 <code>...</code><br>
534 </div>
536 return value means that the file has been found.<br>
537 If you have no strace, you can also guess the <span
543 </div>
551 depending on the environment variables checked in step 1.</li>
552 <li>Check that the .mo file contains a translation for the string
553 that is being asked for.<br>
554 To do this, you need to convert the .mo file back to PO file format,
555 through the command<br>
560 <code></code></div>
562 that matches the given string.<br>
563 </li>
564 </ol>
565 <h3>GNU gettext on Windows</h3>
567 “Woe32” denotes the Windows 32-bit operating systems for x86: Windows
568 NT/2000/XP and Windows 95/98/ME. Microsoft uses the term “Win32” to
569 denote these; this is a psychological trick in order to make everyone
570 believe that these OSes are a “win” for the user. However, for most
571 users and developers, they are a source of woes, which is why I call
572 them “Woe32”.<br>
574 program that uses the gettext()
575 function?</h4>
576 When you use RedHat's cygwin environment, it's as on Unix:<br>
577 <ul>
579 option to the compilation command line, so that the compiler finds the <span
582 option to the link command line, so that the linker finds the <span
584 </ul>
585 When you use the Mingw environment (either from within cygwin, with <span
588 don't know the details.<br>
589 <br>
590 When you use the Microsoft Visual C/C++ (MSVC) compiler, you will
591 likely use the precompiled Woe32 binaries. For running a program that
599 Then<br>
600 <ul>
602 option to all compilation and link command lines. MSVC has three
603 different, mutually incompatible, compilation models (<span
611 as well.<br>
612 </li>
614 option to the compilation command line, so that the compiler finds the <span
616 </li>
618 option to the link command line, so that the linker finds the <span
623 files are created, so that they will be found at runtime.<br>
624 </li>
625 </ul>
628 environment variable doesn't have any effect</h4>
629 If neither LC_ALL, LC_MESSAGES nor LANGUAGES is set, it's the LANG
630 environment variable which determines the language into which gettext()
631 translates the messages.<br>
632 <br>
633 You can test your program by setting the LANG environment variable from
634 outside the program. In a Windows command interpreter:<br>
636 <code>.\myprog.exe</code><br>
637 </div>
638 Or in a Cygwin shell:<br>
640 </div>
641 <br>
642 If this test fails, look at the question “My program compiles and links
643 fine, but doesn't output translated
644 strings.” above.<br>
645 <br>
646 If this test succeeds, the problem is related in the way you set the
647 environment variable. Here is a checklist:<br>
648 <ul>
649 <li>Check that you are using the <span
651 and link command lines. Otherwise you might end up calling the <span
657 <li>Check that you set the environment variable using <span
661 do so, and to deal with the fact that some Unix systems have <span
663 following function.<br>
664 <br>
666 <code>#include <stdlib.h></code><br>
667 <code>#if defined _WIN32</code><br>
668 <code># include <windows.h></code><br>
669 <code>#endif</code><br>
670 <code></code><br>
671 <code>int my_setenv (const char * name, const char * value) {</code><br>
672 <code> size_t namelen = strlen(name);</code><br>
673 <code> size_t valuelen = (value==NULL ? 0 : strlen(value));</code><br>
674 <code>#if defined _WIN32</code><br>
675 <code> /* On Woe32, each process has two copies of the
676 environment variables,</code><br>
677 <code> one managed by the OS and one
678 managed by the C library. We set</code><br>
679 <code> the value in both locations, so that
680 other software that looks in</code><br>
681 <code> one place or the other is guaranteed
682 to see the value. Even if it's</code><br>
683 <code> a bit slow. See also</code><br>
684 <code> <<a
685 href="http://article.gmane.org/gmane.comp.gnu.mingw.user/8272">http://article.gmane.org/gmane.comp.gnu.mingw.user/8272</a>></code><br>
686 <code> <<a
687 href="http://article.gmane.org/gmane.comp.gnu.mingw.user/8273">http://article.gmane.org/gmane.comp.gnu.mingw.user/8273</a>></code><br>
688 <code> <<a
689 href="http://www.cygwin.com/ml/cygwin/1999-04/msg00478.html">http://www.cygwin.com/ml/cygwin/1999-04/msg00478.html</a>>
690 */</code><br>
691 <code> if (!SetEnvironmentVariableA(name,value))</code><br>
692 <code> return -1; </code><br>
693 <code>#endif</code><br>
694 <code>#if defined(HAVE_PUTENV)</code><br>
695 <code> char* buffer = (char*)malloc(namelen+1+valuelen+1);</code><br>
696 <code> if (!buffer)</code><br>
697 <code> return -1; /* no need to set errno =
698 ENOMEM */</code><br>
699 <code> memcpy(buffer,name,namelen);</code><br>
700 <code> if (value != NULL) {</code><br>
701 <code> buffer[namelen] = '=';</code><br>
702 <code> memcpy(buffer+namelen+1,value,valuelen);</code><br>
703 <code> buffer[namelen+1+valuelen] = 0;</code><br>
704 <code> } else</code><br>
705 <code> buffer[namelen] = 0;</code><br>
706 <code> return putenv(buffer);</code><br>
707 <code>#elif defined(HAVE_SETENV)</code><br>
708 <code> return setenv(name,value,1);</code><br>
709 <code>#else</code><br>
710 <code> /* Uh oh, neither putenv() nor setenv() ... */</code><br>
711 <code> return -1;</code><br>
712 <code>#endif</code><br>
713 <code>}</code><br>
714 <code></code></div>
715 <br>
716 </li>
717 </ul>
718 <h3>Other</h3>
720 entries do not both end
721 with '\n'”</h4>
722 It means that when the original string ends in a newline, your
723 translation must also end in a newline. And if the original string does
724 not end in a newline, then your translation should likewise not have a
725 newline at the end.<br>
729 facet of the locale is not set; then gettext() doesn't know which
730 character set to use, and converts all messages to ASCII, as far as
731 possible.<br>
732 <br>
733 If the program is doing<br>
734 <code><br>
736 <br>
738 <code><br>
741 </code><br>
742 or do both of these in a single call:<br>
743 <code><br>
745 </code><br>
746 If the program is already doing<br>
747 <code><br>
749 </code><br>
750 then the symptom can still occur if the user has not set <span
754 nothing or an invalid locale. The fix for the user is then to set <span
758 environment variable is ignored after I set <span
760 This is because “en” is a language name, but not a valid locale name.
762 says:<br>
763 <blockquote>
765 environment variable, but not in the <span
770 denote the language's main dialect.</blockquote>
773 a setting for the entire locale, including monetary information, and
774 this depends on the country: en_GB, en_AU, en_ZA all have different
775 currencies.<br>
777 source code. How do I tell the
778 C/C++ compiler in which encoding it is (like <span
781 Short answer: If you want your program to be useful to other people,
783 (or other non-ASCII characters) in string literals <span
785 only ASCII for string literals, and use <span
787 display-ready form.<br>
788 <br>
789 Long explanation:<br>
790 The reason is that the ISO C standard specifies that the character set
791 at compilation time can be different from the character set at
792 execution time.<br>
793 The character encoding at compilation time is the one which determines
794 how the source files are interpreted and also how string literals are
795 stored in the compiled code. This character encoding is generally
796 unspecified; for recent versions of GCC, it depends on the LC_CTYPE
797 locale in effect during the compilation process.<br>
798 The character encoding at execution time is the one which determines
801 how strings written to standard output should be encoded. This
802 character encoding is specified by POSIX to depend on the LC_CTYPE
803 locale in effect when the program is executed; see also the description
805 Strings in the compiled code are not magically converted between the
806 time the program is compiled and the time it is run.<br>
807 <br>
808 Therefore what could you do to get accented characters to work?<br>
809 <br>
810 Can you ensure that the execution character set is the same as the
811 compilation character set? Even if your program is to be used only in a
812 single country, this is not realistically possible. For example, in
813 Germany there are currently three character encodings in use: UTF-8,
815 convert the accented strings from the compilation character set to the
816 execution character set at runtime, for example through iconv().<br>
817 <br>
818 Can you ensure that the compilation character set is the one in which
819 your source files are stored? This is not realistically possible
820 either: For compilers other than GCC, there is no way to specify the
821 compilation character set. So let's assume for a moment that everyone
822 uses GCC; then you will specify the LC_CTYPE or LC_ALL environment
823 variable in the Makefile. But for this you have to assume that everyone
825 not realistic. People often have no locale installed besides the one
826 they use.<br>
827 <br>
829 doesn't help solving the problem, because on systems like FreeBSD or
830 Solaris, the way how wide string literals are stored in compiled code
831 depends on the compilation character set, just as it does for
833 Moreover, wide strings have problems of their own.<br>
834 <br>
836 doesn't help either because these characters are converted to the
837 compilation character set at compile time; so again, since you can't
838 guarantee that the compilation character set is not ASCII, you're
839 risking compilation errors just as if the real character had been used
840 in the source instead of the Unicode escape.<br>
841 <br>
842 So, in summary, there is no way to make accented characters in string
843 literals work in C/C++.<br>
844 <br>
847 for. The answer is<br>
848 <ol>
850 </li>
851 <li>For other programming languages like Java, for which the compiler
853 </ol>
854 <br>
859 </p>
860 </body>
861 </html>