| blob | c93c185317f5d534595da12b83912642dd5d339f |
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
25 </ul>
27 <ul>
31 reference to libintl_gettext”</a></li>
33 references to the same directories/files
36 </span></li>
38 but doesn't output translated
39 strings.</a><br>
40 </li>
41 </ul>
43 <ul>
46 that uses the gettext()
47 function?</a><br>
48 </li>
51 environment variable doesn't have any effect</a></li>
52 </ul>
54 <ul>
56 entries do not both
57 end with '\n'”</a></li>
59 instead of
60 “geändert”</a></li>
62 environment variable is ignored after I set <span
65 source code. How do I tell the
66 C/C++ compiler in which encoding it is (like <span
69 </ul>
71 <h3>General</h3>
73 Three mailing lists are available: <br>
74 <ul>
76 This mailing list is for discussion of features and bugs of the GNU
78 libintl, the gettext-tools, and its autoconf macros.</li>
80 This mailing list is for methodology questions around
81 internationalization, and for discussions of translator tools,
82 including but not limited to GNU gettext.</li>
84 This is the email address of the <a
86 that is the project which manages the translated message
87 catalogs for many free software packages. Note that KDE and GNOME
88 packages are not part of this project; they have their own translation
91 </li>
92 </ul>
94 is archived as part of the <a
98 subscribed on its own; to receive its contents by mail, subscribe to <span
101 The newest gettext release is available on <span
104 <br>
105 Prereleases are announced on the <a
108 Note that prereleases are meant for testing and not meant for use in
109 production environments. Please don't use the “gettextize” program of a
110 prerelease on projects which you share with other programmers via CVS.<br>
111 <br>
112 If you want to live on the bleeding edge, you can also use the
113 development sources. Instructions for retrieving the gettext CVS are
115 Note that building from CVS requires special tools (autoconf, automake,
116 m4, groff, bison, etc.) and requires that you pay attention to the <span
120 releases.</h4>
121 If you are interested in stable gettext releases, you can follow the <a
124 is also available as a newsgroup <a
129 <br>
130 You can also periodically check the download location.<br>
131 <br>
132 If you are interested in testing prereleases as well, you can subscribe
135 list</a>.<br>
136 <h3>Problems building GNU gettext</h3>
138 build error “text relocations remain” in the <span
140 libtool (or more precisely, the version of libtool that was available
141 at the time the gettext release waas made) doesn't support linking C++
142 libraries with some versions of GCC. As a workaround, you can configure
150 On some platforms, this is due to limitations of libtool regarding <span
152 is due to the way the system handles shared libraries, and libtool
153 cannot work around it. Fortunately, on Linux and other glibc based
155 supported if no different version of gettext is already installed (i.e.
156 it works if you uninstall the older gettext before building and
157 installing the newer one, or if you do a plain “<span
163 install</span>” and copy the installed files to <span
165 afterwards.<br>
166 <br>
169 you are welcome to report to the usual bug report address.
170 <h3>Problems integrating GNU gettext</h3>
173 It's not as difficult as it sounds. Here's the recipe for C or C++
174 based packages.<br>
175 <ul>
176 <li>Add an invocation of <span style="font-family: monospace;">AM_GNU_GETTEXT([external])</span>
178 file.</li>
180 It will do most of the autoconf/automake related work for you.</li>
182 file to the package's source directory, and include it in all source
183 files that contain translatable strings or do output via <span
186 <li>In the source file defining the main() function of the program,
187 add these lines to the header<br>
192 </div>
193 and these lines near the beginning of the main() function:<br>
200 </div>
201 </li>
202 <li>Mark all strings that should be translated with _(), like this: <span
204 doing this, try to turn the strings into good English, one entire
205 sentence per string, not more than one paragraph per string, and use
206 format strings instead of string concatenation. This is needed so that
207 the translators can provide accurate translations.</li>
208 <li>In every source file containing translatable strings, add these lines
209 to the header:<br>
214 </div>
215 </li>
220 file to your nearest translation project.</li>
221 <li>Shortly before a release, integrate the translators' <span
225 </li>
226 </ul>
227 You find detailed descriptions of how this all works in the GNU gettext
228 manual, chapters “The Maintainer's View” and “Preparing Program
229 Sources”.
231 reference to libintl_gettext”</h4>
232 This error means that the program uses the <span
235 file from GNU gettext (which remaps it to <span
237 link time a function of this name could not be linked in. (It is
239 library, installed by GNU gettext.)<br>
240 <br>
241 There are many possible reasons for this error, but in any case you
255 you should check are the values of these variables in your environment
257 autoconfiguration result.<br>
258 <br>
259 To find the cause of the error, a little analysis is needed. Does the
260 program's final link command contains the option “-lintl”?<br>
261 <ul>
262 <li>If yes:<br>
264 comes from. To do this, you have to check for <span
268 each directory given as a -L option, as well as in the compiler's
269 implicit search directories. (You get these implicit search directories
272 final link command line; compilers other than GCC usually look in <span
276 /usr/lib /lib; do ls -l $d/libintl.*; done</code><br>
277 </div>
279 comes from. By looking at the dates and whether each library defines <span
282 | grep libintl_gettext</span>”) you can now distinguish three possible
283 causes of the error:<br>
284 <ul>
285 <li>Some older libintl is used instead of the newer one. The fix
286 is to remove the old library or to reorganize your -L options.</li>
287 <li>The used libintl is the new one, and it doesn't contain
288 libintl_gettext. This would be a bug in gettext. If this is the case,
289 please report it to the usual bug report address.</li>
290 <li>The used libintl is a static library (libintl.a), there are
291 no uses of gettext in .o files before the “-lintl” but there are some
292 after the “-lintl”. In this case the fix is to move the “-lintl” to the
293 end or near the end of the link command line. The only libintl
294 dependency that needs to be mentioned after “-lintl” is “-liconv”.</li>
295 </ul>
296 </li>
297 <li>If no:<br>
298 In this case it's likely a bug in the package you are building: The
299 package's Makefiles should make sure that “-lintl” is used where needed.<br>
300 Test whether libintl was found by configure. You can check this by doing<br>
302 '\(INTLLIBS\|LIBINTL\)' config.status</code><br>
303 </div>
304 and looking whether the value of this autoconf variable is non-empty.<br>
305 <ul>
306 <li>If yes: It should be the responsibility of the Makefile to
307 use the value of this variable in the link command line. Does the
308 Makefile.in rule for linking the program use <span
311 <ul>
312 <li>If no: It's a Makefile.am/in bug.</li>
313 <li>If yes: Something strange is going on. You need to dig
314 deeper.</li>
315 </ul>
320 versions >= 0.11, depending on which <span
323 regardless of which gettext you have now installed.</li>
324 <li>If no: So libintl was not found.<br>
326 Does it invoke AM_GNU_GETTEXT?<br>
327 <ul>
328 <li>If no: The gettext maintainers take no responsibilities for
329 lookalikes named CY_GNU_GETTEXT, AM_GLIB_GNU_GETTEXT, AM_GNOME_GETTEXT
330 and similar, or for homebrewn autoconf checks. Complain to the package
331 maintainer.</li>
332 <li>If yes: It looks like the <span
347 This case can also happen if you have configured a GCC < 3.2 with
349 as you used for GNU libiconv or GNU gettext. This is fatal, because
350 these versions of GCC implicitly use <span
357 for GCC.<br>
358 </li>
359 </ul>
360 </li>
361 </ul>
362 </li>
363 </ul>
365 references to the same directories/files
373 is invoked on the package again, it will re-add the <span
384 source package</span> that uses the newest version of gettext. If you
385 start out from a nonfunctional source package (it is nonfunctional
386 since you have omitted some directories), you cannot expect that <span
388 <br>
389 Often this question arises in packages that use CVS. See the section
390 “CVS Issues / Integrating with CVS” of the GNU gettext documentation.
392 which is designed to reconstruct those files and directories created by
394 omitted from a CVS repository.<br>
396 but doesn't output translated
397 strings.</h4>
398 There are several possible reasons. Here is a checklist that allows you
399 to determine the cause.<br>
400 <ol>
401 <li>Check that the environment variables LC_ALL, LC_MESSAGES,
402 LC_CTYPE, LANG, LANGUAGE together specify a valid locale and language.<br>
403 To check this, run the commands<br>
405 <code>$ gettext --help</code><br>
406 </div>
407 You should see at least some output in your desired language. If not,
408 either<br>
409 <ul>
410 <li>You have chosen a too exotic language. <span
412 languages. Choose a less exotic language, such as Galician or
413 Ukrainian. Or<br>
414 </li>
415 <li>There is a problem with your environment variables. Possibly
416 LC_ALL points to a locale that is not installed, or LC_MESSAGES and
417 LC_CTYPE are inconsistent.</li>
418 </ul>
419 </li>
420 <li>Check that your program contains a <span
422 To check this, run your program under ltrace. For example,<br>
424 <code>...</code><br>
425 <code>setlocale(6,
426 "")
428 </div>
429 If you have no ltrace, you can also do this check by running your
430 program under the debugger. For example,<br>
432 <code>(gdb) break main</code><br>
433 <code>(gdb) run</code><br>
434 <code>Breakpoint 1, main ()</code><br>
435 <code>(gdb) break setlocale</code><br>
436 <code>(gdb) continue</code><br>
437 <code>Breakpoint 2, setlocale ()</code><br>
438 <code>;; OK, the breakpoint has been hit, setlocale() is being
439 called.</code><br>
440 </div>
441 Either way, check that the return value of <span
443 return value indicates a failure. </li>
444 <li>Check that your program contains a <span
447 to the same message domain, and then really calls the <span
451 To check this, run the program under ltrace. For example,<br>
453 <code>...</code><br>
454 <code>textdomain("hello-c")
457 <code>dcgettext(0, 0x08048691, 5, 0x0804a200, 0x08048689) =
458 0x4001721f</code><br>
459 </div>
460 If you have no ltrace, you can also do this check by running your
461 program under the debugger. For example,<br>
463 <code>(gdb) break main</code><br>
464 <code>(gdb) run</code><br>
465 <code>Breakpoint 1, main ()</code><br>
466 <code>(gdb) break textdomain</code><br>
467 <code>(gdb) break bindtextdomain</code><br>
468 <code>(gdb) break gettext</code><br>
469 <code>(gdb) break dgettext</code><br>
470 <code>(gdb) break dcgettext</code><br>
471 <code>(gdb) continue</code><br>
472 <code>Breakpoint 2, textdomain ()</code><br>
473 <code>(gdb) continue</code><br>
474 <code>Breakpoint 3, bindtextdomain ()</code><br>
475 <code>(gdb) continue</code><br>
476 <code>Breakpoint 6, dcgettext ()</code><br>
477 </div>
480 function mentioned in the source code; this is due to an optimization
482 When using libintl on a non-glibc system, you have to add a prefix “<span
484 names mentioned here, because that's what the functions are really
485 named, under the hood.<br>
489 the possible cause might be that some autoconf or Makefile macrology
490 has turned off internationalization entirely (like the <span
492 option usually does).<br>
493 </li>
495 file that contains the translation is really there where the program
496 expects it.<br>
497 To check this, run the program under strace and look at the <span
500 | grep '^open('</code><br>
502 ENOENT (No such file or directory)</code><br>
504 O_RDONLY) = 5</code><br>
506 O_RDONLY) = 5</code><br>
508 = 5</code><br>
511 = 5</code><br>
512 <code>...</code><br>
513 </div>
515 return value means that the file has been found.<br>
516 If you have no strace, you can also guess the <span
522 </div>
530 depending on the environment variables checked in step 1.</li>
531 <li>Check that the .mo file contains a translation for the string
532 that is being asked for.<br>
533 To do this, you need to convert the .mo file back to PO file format,
534 through the command<br>
539 <code></code></div>
541 that matches the given string.<br>
542 </li>
543 </ol>
544 <h3>GNU gettext on Windows</h3>
546 “Woe32” denotes the Windows 32-bit operating systems for x86: Windows
547 NT/2000/XP/Vista and Windows 95/98/ME. Microsoft uses the term “Win32” to
548 denote these; this is a psychological trick in order to make everyone
549 believe that these OSes are a “win” for the user. However, for most
550 users and developers, they are a source of woes, which is why I call
551 them “Woe32”.<br>
553 program that uses the gettext()
554 function?</h4>
555 When you use RedHat's cygwin environment, it's as on Unix:<br>
556 <ul>
558 option to the compilation command line, so that the compiler finds the <span
561 option to the link command line, so that the linker finds the <span
563 </ul>
564 When you use the Mingw environment (either from within cygwin, with <span
567 don't know the details.<br>
568 <br>
569 When you use the Microsoft Visual C/C++ (MSVC) compiler, you will
570 likely use the precompiled Woe32 binaries. For running a program that
578 Then<br>
579 <ul>
581 option to all compilation and link command lines. MSVC has six
582 different, mutually incompatible, compilation models (<span
593 as well.<br>
594 </li>
596 option to the compilation command line, so that the compiler finds the <span
598 </li>
600 option to the link command line, so that the linker finds the <span
605 files are created, so that they will be found at runtime.<br>
606 </li>
607 </ul>
610 environment variable doesn't have any effect</h4>
611 If neither LC_ALL, LC_MESSAGES nor LANGUAGES is set, it's the LANG
612 environment variable which determines the language into which gettext()
613 translates the messages.<br>
614 <br>
615 You can test your program by setting the LANG environment variable from
616 outside the program. In a Windows command interpreter:<br>
618 <code>.\myprog.exe</code><br>
619 </div>
620 Or in a Cygwin shell:<br>
622 </div>
623 <br>
624 If this test fails, look at the question “My program compiles and links
625 fine, but doesn't output translated
626 strings.” above.<br>
627 <br>
628 If this test succeeds, the problem is related in the way you set the
629 environment variable. Here is a checklist:<br>
630 <ul>
631 <li>Check that you are using the <span
633 and link command lines. Otherwise you might end up calling the <span
639 <li>Check that you set the environment variable using <span
643 do so, and to deal with the fact that some Unix systems have <span
645 following function.<br>
646 <br>
648 <code>#include <stdlib.h></code><br>
649 <code>#if defined _WIN32</code><br>
650 <code># include <windows.h></code><br>
651 <code>#endif</code><br>
652 <code></code><br>
653 <code>int my_setenv (const char * name, const char * value) {</code><br>
654 <code> size_t namelen = strlen(name);</code><br>
655 <code> size_t valuelen = (value==NULL ? 0 : strlen(value));</code><br>
656 <code>#if defined _WIN32</code><br>
657 <code> /* On Woe32, each process has two copies of the
658 environment variables,</code><br>
659 <code> one managed by the OS and one
660 managed by the C library. We set</code><br>
661 <code> the value in both locations, so that
662 other software that looks in</code><br>
663 <code> one place or the other is guaranteed
664 to see the value. Even if it's</code><br>
665 <code> a bit slow. See also</code><br>
666 <code> <<a
667 href="http://article.gmane.org/gmane.comp.gnu.mingw.user/8272">http://article.gmane.org/gmane.comp.gnu.mingw.user/8272</a>></code><br>
668 <code> <<a
669 href="http://article.gmane.org/gmane.comp.gnu.mingw.user/8273">http://article.gmane.org/gmane.comp.gnu.mingw.user/8273</a>></code><br>
670 <code> <<a
671 href="http://www.cygwin.com/ml/cygwin/1999-04/msg00478.html">http://www.cygwin.com/ml/cygwin/1999-04/msg00478.html</a>>
672 */</code><br>
673 <code> if (!SetEnvironmentVariableA(name,value))</code><br>
674 <code> return -1; </code><br>
675 <code>#endif</code><br>
676 <code>#if defined(HAVE_PUTENV)</code><br>
677 <code> char* buffer = (char*)malloc(namelen+1+valuelen+1);</code><br>
678 <code> if (!buffer)</code><br>
679 <code> return -1; /* no need to set errno =
680 ENOMEM */</code><br>
681 <code> memcpy(buffer,name,namelen);</code><br>
682 <code> if (value != NULL) {</code><br>
683 <code> buffer[namelen] = '=';</code><br>
684 <code> memcpy(buffer+namelen+1,value,valuelen);</code><br>
685 <code> buffer[namelen+1+valuelen] = 0;</code><br>
686 <code> } else</code><br>
687 <code> buffer[namelen] = 0;</code><br>
688 <code> return putenv(buffer);</code><br>
689 <code>#elif defined(HAVE_SETENV)</code><br>
690 <code> return setenv(name,value,1);</code><br>
691 <code>#else</code><br>
692 <code> /* Uh oh, neither putenv() nor setenv() ... */</code><br>
693 <code> return -1;</code><br>
694 <code>#endif</code><br>
695 <code>}</code><br>
696 <code></code></div>
697 <br>
698 </li>
699 </ul>
700 <h3>Other</h3>
702 entries do not both end
703 with '\n'”</h4>
704 It means that when the original string ends in a newline, your
705 translation must also end in a newline. And if the original string does
706 not end in a newline, then your translation should likewise not have a
707 newline at the end.<br>
711 facet of the locale is not set; then gettext() doesn't know which
712 character set to use, and converts all messages to ASCII, as far as
713 possible.<br>
714 <br>
715 If the program is doing<br>
716 <code><br>
718 <br>
720 <code><br>
723 </code><br>
724 or do both of these in a single call:<br>
725 <code><br>
727 </code><br>
728 If the program is already doing<br>
729 <code><br>
731 </code><br>
732 then the symptom can still occur if the user has not set <span
736 nothing or an invalid locale. The fix for the user is then to set <span
740 environment variable is ignored after I set <span
742 This is because “en” is a language name, but not a valid locale name.
744 says:<br>
745 <blockquote>
747 environment variable, but not in the <span
752 denote the language's main dialect.</blockquote>
755 a setting for the entire locale, including monetary information, and
756 this depends on the country: en_GB, en_AU, en_ZA all have different
757 currencies.<br>
759 source code. How do I tell the
760 C/C++ compiler in which encoding it is (like <span
763 Short answer: If you want your program to be useful to other people,
765 (or other non-ASCII characters) in string literals <span
767 only ASCII for string literals, and use <span
769 display-ready form.<br>
770 <br>
771 Long explanation:<br>
772 The reason is that the ISO C standard specifies that the character set
773 at compilation time can be different from the character set at
774 execution time.<br>
775 The character encoding at compilation time is the one which determines
776 how the source files are interpreted and also how string literals are
777 stored in the compiled code. This character encoding is generally
778 unspecified; for recent versions of GCC, it depends on the LC_CTYPE
779 locale in effect during the compilation process.<br>
780 The character encoding at execution time is the one which determines
783 how strings written to standard output should be encoded. This
784 character encoding is specified by POSIX to depend on the LC_CTYPE
785 locale in effect when the program is executed; see also the description
787 Strings in the compiled code are not magically converted between the
788 time the program is compiled and the time it is run.<br>
789 <br>
790 Therefore what could you do to get accented characters to work?<br>
791 <br>
792 Can you ensure that the execution character set is the same as the
793 compilation character set? Even if your program is to be used only in a
794 single country, this is not realistically possible. For example, in
795 Germany there are currently three character encodings in use: UTF-8,
797 convert the accented strings from the compilation character set to the
798 execution character set at runtime, for example through iconv().<br>
799 <br>
800 Can you ensure that the compilation character set is the one in which
801 your source files are stored? This is not realistically possible
802 either: For compilers other than GCC, there is no way to specify the
803 compilation character set. So let's assume for a moment that everyone
804 uses GCC; then you will specify the LC_CTYPE or LC_ALL environment
805 variable in the Makefile. But for this you have to assume that everyone
807 not realistic. People often have no locale installed besides the one
808 they use.<br>
809 <br>
811 doesn't help solving the problem, because on systems like FreeBSD or
812 Solaris, the way how wide string literals are stored in compiled code
813 depends on the compilation character set, just as it does for
815 Moreover, wide strings have problems of their own.<br>
816 <br>
818 doesn't help either because these characters are converted to the
819 compilation character set at compile time; so again, since you can't
820 guarantee that the compilation character set is not ASCII, you're
821 risking compilation errors just as if the real character had been used
822 in the source instead of the Unicode escape.<br>
823 <br>
824 So, in summary, there is no way to make accented characters in string
825 literals work in C/C++.<br>
826 <br>
829 for. The answer is<br>
830 <ol>
832 </li>
833 <li>For other programming languages like Java, for which the compiler
835 </ol>
836 <br>
841 </p>
842 </body>
843 </html>