Initial revision

1 files changed, 176 insertions, 0 deletions

diff --git a/README b/README
new file mode 100644
index 0000000..66c49ed
--- /dev/null
+++ b/README
@@ -0,0 +1,176 @@
+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