You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
177 lines
7.7 KiB
177 lines
7.7 KiB
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
|