4c99916337
Make sure that each va_start has one and only one matching va_end, especially in error cases. If the va_list is used multiple times, do multiple va_starts/va_ends. If a function gets va_list as argument, don't let it use va_end (since it's the callers responsibility). Improved by comments from enami and christos -- thanks! Heimdal/krb4/KAME changes already fed back, rest to follow. Inspired by, but not not based on, OpenBSD. |
||
---|---|---|
.. | ||
doc | ||
intl | ||
lib | ||
m4 | ||
misc | ||
po | ||
src | ||
tests | ||
ABOUT-NLS | ||
acconfig.h | ||
aclocal.m4 | ||
AUTHORS | ||
BUGS | ||
ChangeLog | ||
config.guess | ||
config.h.in | ||
config.sub | ||
configure | ||
configure.in | ||
COPYING | ||
DISCLAIM | ||
gettext2netbsd | ||
INSTALL | ||
install-sh | ||
ltconfig | ||
ltmain.sh | ||
Makefile.am | ||
Makefile.in | ||
missing | ||
mkinstalldirs | ||
NEWS | ||
README | ||
README-alpha | ||
README.gemtext | ||
stamp-h.in | ||
THANKS | ||
TODO |
This is the GNU gettext package. It is interesting for authors or maintainers of other packages or programs which they want to see internationalized. As one step the handling of messages in different languages should be implemented. For this task GNU gettext provides the needed tools and library functions. Users of GNU packages should also install GNU gettext because some other GNU packages will use the gettext program included in this package to internationalize the messages given by shell scripts. Another good reason to install GNU gettext is to make sure the here included functions compile ok. This helps to prevent errors when installing other packages which use this library. The message handling functions are not yet part of POSIX and ISO/IEC standards and therefore it is not possible to rely on facts about their implementation in the local C library. If the installer selects it, GNU gettext tries using the systems functionality; in that case, compatibility problems might occur. We felt that the Uniforum proposals has the much more flexible interface and, what is more important, does not burden the programmers as much as the other possibility does. Please share your results with us. If this package compiles ok for you future GNU release will likely also not fail, at least for reasons found in message handling. Send comments and bug reports to bug-gnu-utils@gnu.org The goal of this library was to give a unique interface to message handling functions. At least the same level of importance was to give the programmer/maintainer the needed tools to maintain the message catalogs. The interface is designed after the proposals of the Uniforum group. So systems having this interface implemented in their C library don't need the library provided here (and it will automatically not be included). If your systems C library implements the second widely available approach (X/Opens catgets) the library can use this and only some stubs will be compiled to provide the needed interface. If neither is locally available a full implementation of the library will be compiled. The configure script provides three non-standard options. These will also be available in other packages if they use the functionality of GNU gettext. Use --disable-nls if you absolutely don't want to have messages handling code. You will always get the original messages (mostly English). You could consider using NLS support even when you do not need other tongues. If you do not install any messages catalogs or do not specify to use another but the C locale you will not get translations. The set of languages for which catalogs should be installed can also be specified while configuring. Of course they must be available but the intersection of these two sets are computed automatically. You could once and for all define in your profile/cshrc the variable LINGUAS: (Bourne Shell) LINGUAS="de fr nl"; export LINGUAS (C Shell) setenv LINGUAS "de fr nl" or specify it directly while configuring env LINGUAS="de fr nl" ./configure Consult the manual for more information on language names. The second configure option is --with-included-gettext This forces to use the GNU implementing the message handling library regardless what the local C library provides. This possibility is much less error prone because possible unreliable effects of the local message handling system are avoided. And perhaps more important: many useful features can only be exploited with this library. The reason is obvious: we cannot dig in the internals of other implementations. It is likely that the discrepancy between the GNU implementation and others will get bigger in the time coming. So better change now! The third option is: --with-catgets The X/Open catgets functions which might be found in the local C library are not used by default. The reason is already described above: the GNU gettext library provides many useful extension which cannot be emulated with catgets(). Beside this the utility programs for generating the catalog used by catgets() vary heavily between different systems. You should select this feature only if you really don't want to use the GNU gettext library and do not want to extended functionality (but I do not see any good reason for such a choice). Other files you might look into: `ABOUT-NLS' - current state of the GNU internationalization effort `COPYING' - copying conditions `INSTALL' - general compilation and installation rules `NEWS' - major changes in the current version `THANKS' - list of contributors Some points you might be interested in before installing the package: 1. If you change any of the files in package the Makefile rules will schedule a recompution of the gettext.pot file. But this is not possible without this package already installed. If you don't have this package already installed and modified any of the files build the package first with --disable-nls When this is done you will get a runnable xgettext program which can be used to recompute gettext.pot. 2. The package contains a file misc/magic.add. This is intended to be added to your /etc/magic file. After adding this the `file' command will recognize GNU message catalog files (.mo files). 3. If your system's C library already provides the gettext interface it might be a good idea to configure the package with --program-prefix=g Systems affected by this are: Solaris 2.x, future GNU and GNU/Linux systems One point to mention here is that at least Solaris 2.3 does not have all function of the Uniforum proposal implement. More specific, the dcgettext() function is missing. For programmers/maintainers it is therefore nowaday better to avoid using this function. 4. Some system have a very dumb^H^H^H^Hstrange version of msgfmt, the one which comes with xview. This one is *not* usable. It's best you delete^H^H^H^H^H^Hrename it or install this package as in the point above with --program-prefix=g 5. On some system it is better to have strings aligned (I've been told Sparcs like strings aligned to 8 byte boundaries). If you want to have the output of msgfmt aligned you can use the -a option. But you also could change the default value to be different from 1. Take a look at the config.h file, built by configure. (If you change the default value the test of msgfmt will fail!) 6. The locale name alias scheme implemented here is in a similar form implemented in the X Window System. Especially the alias data base file can be shared. Normally this file is found at something like /usr/lib/X11/locale/locale.alias If you have the X Window System installed try to find this file and specify the path at the make run: make aliaspath='/usr/lib/X11/locale:/usr/local/lib/locale' (or whatever is appropriate for you). The file name is always locale.alias. In the misc/ subdirectory you find an example for an alias database file. 7. The msgmerge program performs fuzzy search in the message sets. It might run a long time on slow systems. I saw this problem when running it on my old i386DX25. The time can really be several minutes, especially if you have long messages and/or a great number of them. If you have a faster implementation of the fstrcmp() function and want to share it with the rest of use, please contact me. 8. On some systems it will not be possible to compile this package. It is not only this package but any other GNU package, too. These systems do not provide the simplest functionality to run configure. Today are known the following systems: configure name description -------------- ----------- mips-mips-riscos 2.1.1AC RISCos