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.  But GNU gettext tries to use
the systems functionality so that compatibility problem 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@prep.ai.mit.edu


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
will 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 two 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-gnu-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!


Other files you might look into:

`COPYING' -	copying conditions
`INSTALL' -	general compilation and installation rules
`NEWS' -	major changes in the current version
`NLS' -		current state of the GNU internationalization effort
`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 `tupdate' program currently requires Perl installed for proper
    execution.  There are plans for converting `tupdate' into C, so GNU
    gettext does not depend on Perl, but this should be done only once
    all `tupdate' functionality has been satisfactorily prototyped.

7.  The locale name alias scheme implemented here is in a similar form
    implemented in the X Windows Systems.  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 Windows System installed try to find this file and
    specify the path at the make run:

    make aliaspath='/usr/lib/X11/locale/locale.alias:/usr/local/lib/locale'

    (or whatever is appropriate for you).
    In the misc/ subdirectory you find an example for a alias database file.

8.  The programs performing fuzzy search in the message sets might run
    a long time on slow systems.  I saw this problem when running on
    my old i386DX25.  The time can really be several minutes,
    especially if you have long messages and/or a great number of
    them.  The current algorithm, although an optimized form, will
    hopefully be evolved in the next releases.
