X-Git-Url: https://git.saurik.com/wxWidgets.git/blobdiff_plain/66f55ec64c250fc51147815bf905a86e943bfd16..a9249b2eb2a40d8c71f828669045c4ddaa8dc5ff:/docs/html/gettext/gettext_10.html

diff --git a/docs/html/gettext/gettext_10.html b/docs/html/gettext/gettext_10.html
new file mode 100644
index 0000000000..2b8d78b953
--- /dev/null
+++ b/docs/html/gettext/gettext_10.html
@@ -0,0 +1,656 @@
+<HTML>
+<HEAD>
+<!-- This HTML file has been created by texi2html 1.54
+     from gettext.texi on 25 January 1999 -->
+
+<TITLE>GNU gettext utilities - The Maintainer's View</TITLE>
+<link href="gettext_11.html" rel=Next>
+<link href="gettext_9.html" rel=Previous>
+<link href="gettext_toc.html" rel=ToC>
+
+</HEAD>
+<BODY>
+<p>Go to the <A HREF="gettext_1.html">first</A>, <A HREF="gettext_9.html">previous</A>, <A HREF="gettext_11.html">next</A>, <A HREF="gettext_12.html">last</A> section, <A HREF="gettext_toc.html">table of contents</A>.
+<P><HR><P>
+
+
+<H1><A NAME="SEC67" HREF="gettext_toc.html#TOC67">The Maintainer's View</A></H1>
+
+<P>
+The maintainer of a package has many responsibilities.  One of them
+is ensuring that the package will install easily on many platforms,
+and that the magic we described earlier (see section <A HREF="gettext_7.html#SEC35">The User's View</A>) will work
+for installers and end users.
+
+</P>
+<P>
+Of course, there are many possible ways by which GNU <CODE>gettext</CODE>
+might be integrated in a distribution, and this chapter does not cover
+them in all generality.  Instead, it details one possible approach which
+is especially adequate for many free software distributions following GNU
+standards, or even better, Gnits standards, because GNU <CODE>gettext</CODE>
+is purposely for helping the internationalization of the whole GNU
+project, and as many other good free packages as possible.  So, the
+maintainer's view presented here presumes that the package already has
+a <TT>`configure.in'</TT> file and uses GNU Autoconf.
+
+</P>
+<P>
+Nevertheless, GNU <CODE>gettext</CODE> may surely be useful for free packages
+not following GNU standards and conventions, but the maintainers of such
+packages might have to show imagination and initiative in organizing
+their distributions so <CODE>gettext</CODE> work for them in all situations.
+There are surely many, out there.
+
+</P>
+<P>
+Even if <CODE>gettext</CODE> methods are now stabilizing, slight adjustments
+might be needed between successive <CODE>gettext</CODE> versions, so you
+should ideally revise this chapter in subsequent releases, looking
+for changes.
+
+</P>
+
+
+
+<H2><A NAME="SEC68" HREF="gettext_toc.html#TOC68">Flat or Non-Flat Directory Structures</A></H2>
+
+<P>
+Some free software packages are distributed as <CODE>tar</CODE> files which unpack
+in a single directory, these are said to be <STRONG>flat</STRONG> distributions.
+Other free software packages have a one level hierarchy of subdirectories, using
+for example a subdirectory named <TT>`doc/'</TT> for the Texinfo manual and
+man pages, another called <TT>`lib/'</TT> for holding functions meant to
+replace or complement C libraries, and a subdirectory <TT>`src/'</TT> for
+holding the proper sources for the package.  These other distributions
+are said to be <STRONG>non-flat</STRONG>.
+
+</P>
+<P>
+For now, we cannot say much about flat distributions.  A flat
+directory structure has the disadvantage of increasing the difficulty
+of updating to a new version of GNU <CODE>gettext</CODE>.  Also, if you have
+many PO files, this could somewhat pollute your single directory.
+In the GNU <CODE>gettext</CODE> distribution, the <TT>`misc/'</TT> directory
+contains a shell script named <TT>`combine-sh'</TT>.  That script may
+be used for combining all the C files of the <TT>`intl/'</TT> directory
+into a pair of C files (one <TT>`.c'</TT> and one <TT>`.h'</TT>).  Those two
+generated files would fit more easily in a flat directory structure,
+and you will then have to add these two files to your project.
+
+</P>
+<P>
+Maybe because GNU <CODE>gettext</CODE> itself has a non-flat structure,
+we have more experience with this approach, and this is what will be
+described in the remaining of this chapter.  Some maintainers might
+use this as an opportunity to unflatten their package structure.
+Only later, once gained more experience adapting GNU <CODE>gettext</CODE>
+to flat distributions, we might add some notes about how to proceed
+in flat situations.
+
+</P>
+
+
+<H2><A NAME="SEC69" HREF="gettext_toc.html#TOC69">Prerequisite Works</A></H2>
+
+<P>
+There are some works which are required for using GNU <CODE>gettext</CODE>
+in one of your package.  These works have some kind of generality
+that escape the point by point descriptions used in the remainder
+of this chapter.  So, we describe them here.
+
+</P>
+
+<UL>
+<LI>
+
+Before attempting to use you should install some other packages first.
+Ensure that recent versions of GNU <CODE>m4</CODE>, GNU Autoconf and GNU
+<CODE>gettext</CODE> are already installed at your site, and if not, proceed
+to do this first.  If you got to install these things, beware that
+GNU <CODE>m4</CODE> must be fully installed before GNU Autoconf is even
+<EM>configured</EM>.
+
+To further ease the task of a package maintainer the <CODE>automake</CODE>
+package was designed and implemented.  GNU <CODE>gettext</CODE> now uses this
+tool and the <TT>`Makefile'</TT>s in the <TT>`intl/'</TT> and <TT>`po/'</TT>
+therefore know about all the goals necessary for using <CODE>automake</CODE>
+and <TT>`libintl'</TT> in one project.
+
+Those four packages are only needed to you, as a maintainer; the
+installers of your own package and end users do not really need any of
+GNU <CODE>m4</CODE>, GNU Autoconf, GNU <CODE>gettext</CODE>, or GNU <CODE>automake</CODE>
+for successfully installing and running your package, with messages
+properly translated.  But this is not completely true if you provide
+internationalized shell scripts within your own package: GNU
+<CODE>gettext</CODE> shall then be installed at the user site if the end users
+want to see the translation of shell script messages.
+
+<LI>
+
+Your package should use Autoconf and have a <TT>`configure.in'</TT> file.
+If it does not, you have to learn how.  The Autoconf documentation
+is quite well written, it is a good idea that you print it and get
+familiar with it.
+
+<LI>
+
+Your C sources should have already been modified according to
+instructions given earlier in this manual.  See section <A HREF="gettext_3.html#SEC13">Preparing Program Sources</A>.
+
+<LI>
+
+Your <TT>`po/'</TT> directory should receive all PO files submitted to you
+by the translator teams, each having <TT>`<VAR>ll</VAR>.po'</TT> as a name.
+This is not usually easy to get translation
+work done before your package gets internationalized and available!
+Since the cycle has to start somewhere, the easiest for the maintainer
+is to start with absolutely no PO files, and wait until various
+translator teams get interested in your package, and submit PO files.
+
+</UL>
+
+<P>
+It is worth adding here a few words about how the maintainer should
+ideally behave with PO files submissions.  As a maintainer, your role is
+to authentify the origin of the submission as being the representative
+of the appropriate translating teams of the Translation Project (forward
+the submission to <TT>`translation@iro.umontreal.ca'</TT> in case of doubt),
+to ensure that the PO file format is not severely broken and does not
+prevent successful installation, and for the rest, to merely to put these
+PO files in <TT>`po/'</TT> for distribution.
+
+</P>
+<P>
+As a maintainer, you do not have to take on your shoulders the
+responsibility of checking if the translations are adequate or
+complete, and should avoid diving into linguistic matters.  Translation
+teams drive themselves and are fully responsible of their linguistic
+choices for the Translation Project.  Keep in mind that translator teams are <EM>not</EM>
+driven by maintainers.  You can help by carefully redirecting all
+communications and reports from users about linguistic matters to the
+appropriate translation team, or explain users how to reach or join
+their team.  The simplest might be to send them the <TT>`ABOUT-NLS'</TT> file.
+
+</P>
+<P>
+Maintainers should <EM>never ever</EM> apply PO file bug reports
+themselves, short-cutting translation teams.  If some translator has
+difficulty to get some of her points through her team, it should not be
+an issue for her to directly negotiate translations with maintainers.
+Teams ought to settle their problems themselves, if any.  If you, as
+a maintainer, ever think there is a real problem with a team, please
+never try to <EM>solve</EM> a team's problem on your own.
+
+</P>
+
+
+<H2><A NAME="SEC70" HREF="gettext_toc.html#TOC70">Invoking the <CODE>gettextize</CODE> Program</A></H2>
+
+<P>
+Some files are consistently and identically needed in every package
+internationalized through GNU <CODE>gettext</CODE>.  As a matter of
+convenience, the <CODE>gettextize</CODE> program puts all these files right
+in your package.  This program has the following synopsis:
+
+</P>
+
+<PRE>
+gettextize [ <VAR>option</VAR>... ] [ <VAR>directory</VAR> ]
+</PRE>
+
+<P>
+and accepts the following options:
+
+</P>
+<DL COMPACT>
+
+<DT><SAMP>`-c'</SAMP>
+<DD>
+<DT><SAMP>`--copy'</SAMP>
+<DD>
+Copy the needed files instead of making symbolic links.  Using links
+would allow the package to always use the latest <CODE>gettext</CODE> code
+available on the system, but it might disturb some mechanism the
+maintainer is used to apply to the sources.  Because running
+<CODE>gettextize</CODE> is easy there shouldn't be problems with using copies.
+
+<DT><SAMP>`-f'</SAMP>
+<DD>
+<DT><SAMP>`--force'</SAMP>
+<DD>
+Force replacement of files which already exist.
+
+<DT><SAMP>`-h'</SAMP>
+<DD>
+<DT><SAMP>`--help'</SAMP>
+<DD>
+Display this help and exit.
+
+<DT><SAMP>`--version'</SAMP>
+<DD>
+Output version information and exit.
+
+</DL>
+
+<P>
+If <VAR>directory</VAR> is given, this is the top level directory of a
+package to prepare for using GNU <CODE>gettext</CODE>.  If not given, it
+is assumed that the current directory is the top level directory of
+such a package.
+
+</P>
+<P>
+The program <CODE>gettextize</CODE> provides the following files.  However,
+no existing file will be replaced unless the option <CODE>--force</CODE>
+(<CODE>-f</CODE>) is specified.
+
+</P>
+
+<OL>
+<LI>
+
+The <TT>`ABOUT-NLS'</TT> file is copied in the main directory of your package,
+the one being at the top level.  This file gives the main indications
+about how to install and use the Native Language Support features
+of your program.  You might elect to use a more recent copy of this
+<TT>`ABOUT-NLS'</TT> file than the one provided through <CODE>gettextize</CODE>,
+if you have one handy.  You may also fetch a more recent copy of file
+<TT>`ABOUT-NLS'</TT> from Translation Project sites, and from most GNU
+archive sites.
+
+<LI>
+
+A <TT>`po/'</TT> directory is created for eventually holding
+all translation files, but initially only containing the file
+<TT>`po/Makefile.in.in'</TT> from the GNU <CODE>gettext</CODE> distribution.
+(beware the double <SAMP>`.in'</SAMP> in the file name). If the <TT>`po/'</TT>
+directory already exists, it will be preserved along with the files
+it contains, and only <TT>`Makefile.in.in'</TT> will be overwritten.
+
+<LI>
+
+A <TT>`intl/'</TT> directory is created and filled with most of the files
+originally in the <TT>`intl/'</TT> directory of the GNU <CODE>gettext</CODE>
+distribution.  Also, if option <CODE>--force</CODE> (<CODE>-f</CODE>) is given,
+the <TT>`intl/'</TT> directory is emptied first.
+
+</OL>
+
+<P>
+If your site support symbolic links, <CODE>gettextize</CODE> will not
+actually copy the files into your package, but establish symbolic
+links instead.  This avoids duplicating the disk space needed in
+all packages.  Merely using the <SAMP>`-h'</SAMP> option while creating the
+<CODE>tar</CODE> archive of your distribution will resolve each link by an
+actual copy in the distribution archive.  So, to insist, you really
+should use <SAMP>`-h'</SAMP> option with <CODE>tar</CODE> within your <CODE>dist</CODE>
+goal of your main <TT>`Makefile.in'</TT>.
+
+</P>
+<P>
+It is interesting to understand that most new files for supporting
+GNU <CODE>gettext</CODE> facilities in one package go in <TT>`intl/'</TT>
+and <TT>`po/'</TT> subdirectories.  One distinction between these two
+directories is that <TT>`intl/'</TT> is meant to be completely identical
+in all packages using GNU <CODE>gettext</CODE>, while all newly created
+files, which have to be different, go into <TT>`po/'</TT>.  There is a
+common <TT>`Makefile.in.in'</TT> in <TT>`po/'</TT>, because the <TT>`po/'</TT>
+directory needs its own <TT>`Makefile'</TT>, and it has been designed so
+it can be identical in all packages.
+
+</P>
+
+
+<H2><A NAME="SEC71" HREF="gettext_toc.html#TOC71">Files You Must Create or Alter</A></H2>
+
+<P>
+Besides files which are automatically added through <CODE>gettextize</CODE>,
+there are many files needing revision for properly interacting with
+GNU <CODE>gettext</CODE>.  If you are closely following GNU standards for
+Makefile engineering and auto-configuration, the adaptations should
+be easier to achieve.  Here is a point by point description of the
+changes needed in each.
+
+</P>
+<P>
+So, here comes a list of files, each one followed by a description of
+all alterations it needs.  Many examples are taken out from the GNU
+<CODE>gettext</CODE> 0.10.35 distribution itself.  You may indeed
+refer to the source code of the GNU <CODE>gettext</CODE> package, as it
+is intended to be a good example and master implementation for using
+its own functionality.
+
+</P>
+
+
+
+<H3><A NAME="SEC72" HREF="gettext_toc.html#TOC72"><TT>`POTFILES.in'</TT> in <TT>`po/'</TT></A></H3>
+
+<P>
+The <TT>`po/'</TT> directory should receive a file named
+<TT>`POTFILES.in'</TT>.  This file tells which files, among all program
+sources, have marked strings needing translation.  Here is an example
+of such a file:
+
+</P>
+
+<PRE>
+# List of source files containing translatable strings.
+# Copyright (C) 1995 Free Software Foundation, Inc.
+
+# Common library files
+lib/error.c
+lib/getopt.c
+lib/xmalloc.c
+
+# Package source files
+src/gettextp.c
+src/msgfmt.c
+src/xgettext.c
+</PRE>
+
+<P>
+Dashed comments and white lines are ignored.  All other lines
+list those source files containing strings marked for translation
+(see section <A HREF="gettext_3.html#SEC15">How Marks Appears in Sources</A>), in a notation relative to the top level
+of your whole distribution, rather than the location of the
+<TT>`POTFILES.in'</TT> file itself.
+
+</P>
+
+
+<H3><A NAME="SEC73" HREF="gettext_toc.html#TOC73"><TT>`configure.in'</TT> at top level</A></H3>
+
+
+<OL>
+<LI>Declare the package and version.
+
+This is done by a set of lines like these:
+
+
+<PRE>
+PACKAGE=gettext
+VERSION=0.10.35
+AC_DEFINE_UNQUOTED(PACKAGE, "$PACKAGE")
+AC_DEFINE_UNQUOTED(VERSION, "$VERSION")
+AC_SUBST(PACKAGE)
+AC_SUBST(VERSION)
+</PRE>
+
+Of course, you replace <SAMP>`gettext'</SAMP> with the name of your package,
+and <SAMP>`0.10.35'</SAMP> by its version numbers, exactly as they
+should appear in the packaged <CODE>tar</CODE> file name of your distribution
+(<TT>`gettext-0.10.35.tar.gz'</TT>, here).
+
+<LI>Declare the available translations.
+
+This is done by defining <CODE>ALL_LINGUAS</CODE> to the white separated,
+quoted list of available languages, in a single line, like this:
+
+
+<PRE>
+ALL_LINGUAS="de fr"
+</PRE>
+
+This example means that German and French PO files are available, so
+that these languages are currently supported by your package.  If you
+want to further restrict, at installation time, the set of installed
+languages, this should not be done by modifying <CODE>ALL_LINGUAS</CODE> in
+<TT>`configure.in'</TT>, but rather by using the <CODE>LINGUAS</CODE> environment
+variable (see section <A HREF="gettext_7.html#SEC37">Magic for Installers</A>).
+
+<LI>Check for internationalization support.
+
+Here is the main <CODE>m4</CODE> macro for triggering internationalization
+support.  Just add this line to <TT>`configure.in'</TT>:
+
+
+<PRE>
+AM_GNU_GETTEXT
+</PRE>
+
+This call is purposely simple, even if it generates a lot of configure
+time checking and actions.
+
+<LI>Have output files created.
+
+The <CODE>AC_OUTPUT</CODE> directive, at the end of your <TT>`configure.in'</TT>
+file, needs to be modified in two ways:
+
+
+<PRE>
+AC_OUTPUT([<VAR>existing configuration files</VAR> intl/Makefile po/Makefile.in],
+<VAR>existing additional actions</VAR>])
+</PRE>
+
+The modification to the first argument to <CODE>AC_OUTPUT</CODE> asks
+for substitution in the <TT>`intl/'</TT> and <TT>`po/'</TT> directories.
+Note the <SAMP>`.in'</SAMP> suffix used for <TT>`po/'</TT> only.  This is because
+the distributed file is really <TT>`po/Makefile.in.in'</TT>.
+
+</OL>
+
+
+
+<H3><A NAME="SEC74" HREF="gettext_toc.html#TOC74"><TT>`aclocal.m4'</TT> at top level</A></H3>
+
+<P>
+If you do not have an <TT>`aclocal.m4'</TT> file in your distribution,
+the simplest is taking a copy of <TT>`aclocal.m4'</TT> from
+GNU <CODE>gettext</CODE>.  But to be precise, you only need macros
+<CODE>AM_LC_MESSAGES</CODE>, <CODE>AM_WITH_NLS</CODE> and <CODE>AM_GNU_GETTEXT</CODE>,
+and <CODE>AM_PATH_PROG_WITH_TEST</CODE>, which is called by <CODE>AM_WITH_NLS</CODE>,
+so you may use an editor and remove macros you do not need.
+
+</P>
+<P>
+If you already have an <TT>`aclocal.m4'</TT> file, then you will have
+to merge the said macros into your <TT>`aclocal.m4'</TT>.  Note that if
+you are upgrading from a previous release of GNU <CODE>gettext</CODE>, you
+should most probably <EM>replace</EM> the said macros, as they usually
+change a little from one release of GNU <CODE>gettext</CODE> to the next.
+Their contents may vary as we get more experience with strange systems
+out there.
+
+</P>
+<P>
+These macros check for the internationalization support functions
+and related informations.  Hopefully, once stabilized, these macros
+might be integrated in the standard Autoconf set, because this
+piece of <CODE>m4</CODE> code will be the same for all projects using GNU
+<CODE>gettext</CODE>.
+
+</P>
+
+
+<H3><A NAME="SEC75" HREF="gettext_toc.html#TOC75"><TT>`acconfig.h'</TT> at top level</A></H3>
+
+<P>
+If you do not have an <TT>`acconfig.h'</TT> file in your distribution, the
+simplest is use take a copy of <TT>`acconfig.h'</TT> from GNU
+<CODE>gettext</CODE>.  But to be precise, you only need the lines and comments
+for <CODE>ENABLE_NLS</CODE>, <CODE>HAVE_CATGETS</CODE>, <CODE>HAVE_GETTEXT</CODE> and
+<CODE>HAVE_LC_MESSAGES</CODE>, <CODE>HAVE_STPCPY</CODE>, <CODE>PACKAGE</CODE> and
+<CODE>VERSION</CODE>, so you may use an editor and remove everything else.  If
+you already have an <TT>`acconfig.h'</TT> file, then you should merge the
+said definitions into your <TT>`acconfig.h'</TT>.
+
+</P>
+
+
+<H3><A NAME="SEC76" HREF="gettext_toc.html#TOC76"><TT>`Makefile.in'</TT> at top level</A></H3>
+
+<P>
+Here are a few modifications you need to make to your main, top-level
+<TT>`Makefile.in'</TT> file.
+
+</P>
+
+<OL>
+<LI>
+
+Add the following lines near the beginning of your <TT>`Makefile.in'</TT>,
+so the <SAMP>`dist:'</SAMP> goal will work properly (as explained further down):
+
+
+<PRE>
+PACKAGE = @PACKAGE@
+VERSION = @VERSION@
+</PRE>
+
+<LI>
+
+Add file <TT>`ABOUT-NLS'</TT> to the <CODE>DISTFILES</CODE> definition, so the file gets
+distributed.
+
+<LI>
+
+Wherever you process subdirectories in your <TT>`Makefile.in'</TT>, be sure
+you also process dir subdirectories <SAMP>`intl'</SAMP> and <SAMP>`po'</SAMP>.  Special
+rules in the <TT>`Makefiles'</TT> take care for the case where no
+internationalization is wanted.
+
+If you are using Makefiles, either generated by automake, or hand-written
+so they carefully follow the GNU coding standards, the effected goals for
+which the new subdirectories must be handled include <SAMP>`installdirs'</SAMP>,
+<SAMP>`install'</SAMP>, <SAMP>`uninstall'</SAMP>, <SAMP>`clean'</SAMP>, <SAMP>`distclean'</SAMP>.
+
+Here is an example of a canonical order of processing.  In this
+example, we also define <CODE>SUBDIRS</CODE> in <CODE>Makefile.in</CODE> for it
+to be further used in the <SAMP>`dist:'</SAMP> goal.
+
+
+<PRE>
+SUBDIRS = doc lib @INTLSUB@ src @POSUB@
+</PRE>
+
+that you will have to adapt to your own package.
+
+<LI>
+
+A delicate point is the <SAMP>`dist:'</SAMP> goal, as both
+<TT>`intl/Makefile'</TT> and <TT>`po/Makefile'</TT> will later assume that the
+proper directory has been set up from the main <TT>`Makefile'</TT>.  Here is
+an example at what the <SAMP>`dist:'</SAMP> goal might look like:
+
+
+<PRE>
+distdir = $(PACKAGE)-$(VERSION)
+dist: Makefile
+	rm -fr $(distdir)
+	mkdir $(distdir)
+	chmod 777 $(distdir)
+	for file in $(DISTFILES); do \
+	  ln $$file $(distdir) 2&#62;/dev/null || cp -p $$file $(distdir); \
+	done
+	for subdir in $(SUBDIRS); do \
+	  mkdir $(distdir)/$$subdir || exit 1; \
+	  chmod 777 $(distdir)/$$subdir; \
+	  (cd $$subdir &#38;&#38; $(MAKE) $@) || exit 1; \
+	done
+	tar chozf $(distdir).tar.gz $(distdir)
+	rm -fr $(distdir)
+</PRE>
+
+</OL>
+
+
+
+<H3><A NAME="SEC77" HREF="gettext_toc.html#TOC77"><TT>`Makefile.in'</TT> in <TT>`src/'</TT></A></H3>
+
+<P>
+Some of the modifications made in the main <TT>`Makefile.in'</TT> will
+also be needed in the <TT>`Makefile.in'</TT> from your package sources,
+which we assume here to be in the <TT>`src/'</TT> subdirectory.  Here are
+all the modifications needed in <TT>`src/Makefile.in'</TT>:
+
+</P>
+
+<OL>
+<LI>
+
+In view of the <SAMP>`dist:'</SAMP> goal, you should have these lines near the
+beginning of <TT>`src/Makefile.in'</TT>:
+
+
+<PRE>
+PACKAGE = @PACKAGE@
+VERSION = @VERSION@
+</PRE>
+
+<LI>
+
+If not done already, you should guarantee that <CODE>top_srcdir</CODE>
+gets defined.  This will serve for <CODE>cpp</CODE> include files.  Just add
+the line:
+
+
+<PRE>
+top_srcdir = @top_srcdir@
+</PRE>
+
+<LI>
+
+You might also want to define <CODE>subdir</CODE> as <SAMP>`src'</SAMP>, later
+allowing for almost uniform <SAMP>`dist:'</SAMP> goals in all your
+<TT>`Makefile.in'</TT>.  At list, the <SAMP>`dist:'</SAMP> goal below assume that
+you used:
+
+
+<PRE>
+subdir = src
+</PRE>
+
+<LI>
+
+You should ensure that the final linking will use <CODE>@INTLLIBS@</CODE> as
+a library.  An easy way to achieve this is to manage that it gets into
+<CODE>LIBS</CODE>, like this:
+
+
+<PRE>
+LIBS = @INTLLIBS@ @LIBS@
+</PRE>
+
+In most packages internationalized with GNU <CODE>gettext</CODE>, one will
+find a directory <TT>`lib/'</TT> in which a library containing some helper
+functions will be build.  (You need at least the few functions which the
+GNU <CODE>gettext</CODE> Library itself needs.)  However some of the functions
+in the <TT>`lib/'</TT> also give messages to the user which of course should be
+translated, too.  Taking care of this it is not enough to place the support
+library (say <TT>`libsupport.a'</TT>) just between the <CODE>@INTLLIBS@</CODE>
+and <CODE>@LIBS@</CODE> in the above example.  Instead one has to write this:
+
+
+<PRE>
+LIBS = ../lib/libsupport.a @INTLLIBS@ ../lib/libsupport.a @LIBS@
+</PRE>
+
+<LI>
+
+You should also ensure that directory <TT>`intl/'</TT> will be searched for
+C preprocessor include files in all circumstances.  So, you have to
+manage so both <SAMP>`-I../intl'</SAMP> and <SAMP>`-I$(top_srcdir)/intl'</SAMP> will
+be given to the C compiler.
+
+<LI>
+
+Your <SAMP>`dist:'</SAMP> goal has to conform with others.  Here is a
+reasonable definition for it:
+
+
+<PRE>
+distdir = ../$(PACKAGE)-$(VERSION)/$(subdir)
+dist: Makefile $(DISTFILES)
+	for file in $(DISTFILES); do \
+	  ln $$file $(distdir) 2&#62;/dev/null || cp -p $$file $(distdir); \
+	done
+</PRE>
+
+</OL>
+
+<P><HR><P>
+<p>Go to the <A HREF="gettext_1.html">first</A>, <A HREF="gettext_9.html">previous</A>, <A HREF="gettext_11.html">next</A>, <A HREF="gettext_12.html">last</A> section, <A HREF="gettext_toc.html">table of contents</A>.
+</BODY>
+</HTML>