Go to the first, previous, next, last section, table of contents. +
+ + +
+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 The User's View) will work +for installers and end users. + +
+
+Of course, there are many possible ways by which GNU gettext
+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 gettext
+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 `configure.in' file and uses GNU Autoconf.
+
+
+Nevertheless, GNU gettext 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 gettext work for them in all situations.
+There are surely many, out there.
+
+
+Even if gettext methods are now stabilizing, slight adjustments
+might be needed between successive gettext versions, so you
+should ideally revise this chapter in subsequent releases, looking
+for changes.
+
+
+Some free software packages are distributed as tar files which unpack
+in a single directory, these are said to be flat distributions.
+Other free software packages have a one level hierarchy of subdirectories, using
+for example a subdirectory named `doc/' for the Texinfo manual and
+man pages, another called `lib/' for holding functions meant to
+replace or complement C libraries, and a subdirectory `src/' for
+holding the proper sources for the package. These other distributions
+are said to be non-flat.
+
+
+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 gettext. Also, if you have
+many PO files, this could somewhat pollute your single directory.
+In the GNU gettext distribution, the `misc/' directory
+contains a shell script named `combine-sh'. That script may
+be used for combining all the C files of the `intl/' directory
+into a pair of C files (one `.c' and one `.h'). 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.
+
+
+Maybe because GNU gettext 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 gettext
+to flat distributions, we might add some notes about how to proceed
+in flat situations.
+
+
+There are some works which are required for using GNU gettext
+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.
+
+
m4, GNU Autoconf and GNU
+gettext are already installed at your site, and if not, proceed
+to do this first. If you got to install these things, beware that
+GNU m4 must be fully installed before GNU Autoconf is even
+configured.
+
+To further ease the task of a package maintainer the automake
+package was designed and implemented. GNU gettext now uses this
+tool and the `Makefile's in the `intl/' and `po/'
+therefore know about all the goals necessary for using automake
+and `libintl' 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 m4, GNU Autoconf, GNU gettext, or GNU automake
+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
+gettext shall then be installed at the user site if the end users
+want to see the translation of shell script messages.
+
++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 authenticate the origin of the submission as being the representative +of the appropriate translating teams of the Translation Project (forward +the submission to `translation@iro.umontreal.ca' 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 `po/' for distribution. + +
++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 not +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 `ABOUT-NLS' file. + +
++Maintainers should never ever 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 solve a team's problem on your own. + +
+ + +gettextize Program
+Some files are consistently and identically needed in every package
+internationalized through GNU gettext. As a matter of
+convenience, the gettextize program puts all these files right
+in your package. This program has the following synopsis:
+
+
+gettextize [ option... ] [ directory ] ++ +
+and accepts the following options: + +
+gettext code
+available on the system, but it might disturb some mechanism the
+maintainer is used to apply to the sources. Because running
+gettextize is easy there shouldn't be problems with using copies.
+
+
+If directory is given, this is the top level directory of a
+package to prepare for using GNU gettext. If not given, it
+is assumed that the current directory is the top level directory of
+such a package.
+
+
+The program gettextize provides the following files. However,
+no existing file will be replaced unless the option --force
+(-f) is specified.
+
+
gettextize,
+if you have one handy. You may also fetch a more recent copy of file
+`ABOUT-NLS' from Translation Project sites, and from most GNU
+archive sites.
+
+gettext distribution.
+(beware the double `.in' in the file name). If the `po/'
+directory already exists, it will be preserved along with the files
+it contains, and only `Makefile.in.in' will be overwritten.
+
+gettext
+distribution. Also, if option --force (-f) is given,
+the `intl/' directory is emptied first.
+
+
+If your site support symbolic links, gettextize 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 `-h' option while creating the
+tar archive of your distribution will resolve each link by an
+actual copy in the distribution archive. So, to insist, you really
+should use `-h' option with tar within your dist
+goal of your main `Makefile.in'.
+
+
+It is interesting to understand that most new files for supporting
+GNU gettext facilities in one package go in `intl/'
+and `po/' subdirectories. One distinction between these two
+directories is that `intl/' is meant to be completely identical
+in all packages using GNU gettext, while all newly created
+files, which have to be different, go into `po/'. There is a
+common `Makefile.in.in' in `po/', because the `po/'
+directory needs its own `Makefile', and it has been designed so
+it can be identical in all packages.
+
+
+Besides files which are automatically added through gettextize,
+there are many files needing revision for properly interacting with
+GNU gettext. 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.
+
+
+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
+gettext 0.10.35 distribution itself. You may indeed
+refer to the source code of the GNU gettext package, as it
+is intended to be a good example and master implementation for using
+its own functionality.
+
+
+The `po/' directory should receive a file named +`POTFILES.in'. This file tells which files, among all program +sources, have marked strings needing translation. Here is an example +of such a file: + +
+ ++# 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 ++ +
+Dashed comments and white lines are ignored. All other lines +list those source files containing strings marked for translation +(see section How Marks Appears in Sources), in a notation relative to the top level +of your whole distribution, rather than the location of the +`POTFILES.in' file itself. + +
+ + ++PACKAGE=gettext +VERSION=0.10.35 +AC_DEFINE_UNQUOTED(PACKAGE, "$PACKAGE") +AC_DEFINE_UNQUOTED(VERSION, "$VERSION") +AC_SUBST(PACKAGE) +AC_SUBST(VERSION) ++ +Of course, you replace `gettext' with the name of your package, +and `0.10.35' by its version numbers, exactly as they +should appear in the packaged
tar file name of your distribution
+(`gettext-0.10.35.tar.gz', here).
+
+ALL_LINGUAS to the white separated,
+quoted list of available languages, in a single line, like this:
+
+
++ALL_LINGUAS="de fr" ++ +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
ALL_LINGUAS in
+`configure.in', but rather by using the LINGUAS environment
+variable (see section Magic for Installers).
+
+m4 macro for triggering internationalization
+support. Just add this line to `configure.in':
+
+
++AM_GNU_GETTEXT ++ +This call is purposely simple, even if it generates a lot of configure +time checking and actions. + +
AC_OUTPUT directive, at the end of your `configure.in'
+file, needs to be modified in two ways:
+
+
++AC_OUTPUT([existing configuration files intl/Makefile po/Makefile.in], +existing additional actions]) ++ +The modification to the first argument to
AC_OUTPUT asks
+for substitution in the `intl/' and `po/' directories.
+Note the `.in' suffix used for `po/' only. This is because
+the distributed file is really `po/Makefile.in.in'.
+
+
+If you do not have an `aclocal.m4' file in your distribution,
+the simplest is taking a copy of `aclocal.m4' from
+GNU gettext. But to be precise, you only need macros
+AM_LC_MESSAGES, AM_WITH_NLS and AM_GNU_GETTEXT,
+and AM_PATH_PROG_WITH_TEST, which is called by AM_WITH_NLS,
+so you may use an editor and remove macros you do not need.
+
+
+If you already have an `aclocal.m4' file, then you will have
+to merge the said macros into your `aclocal.m4'. Note that if
+you are upgrading from a previous release of GNU gettext, you
+should most probably replace the said macros, as they usually
+change a little from one release of GNU gettext to the next.
+Their contents may vary as we get more experience with strange systems
+out there.
+
+
+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 m4 code will be the same for all projects using GNU
+gettext.
+
+
+If you do not have an `acconfig.h' file in your distribution, the
+simplest is use take a copy of `acconfig.h' from GNU
+gettext. But to be precise, you only need the lines and comments
+for ENABLE_NLS, HAVE_CATGETS, HAVE_GETTEXT and
+HAVE_LC_MESSAGES, HAVE_STPCPY, PACKAGE and
+VERSION, so you may use an editor and remove everything else. If
+you already have an `acconfig.h' file, then you should merge the
+said definitions into your `acconfig.h'.
+
+
+Here are a few modifications you need to make to your main, top-level +`Makefile.in' file. + +
+ ++PACKAGE = @PACKAGE@ +VERSION = @VERSION@ ++ +
DISTFILES definition, so the file gets
+distributed.
+
+SUBDIRS in Makefile.in for it
+to be further used in the `dist:' goal.
+
+
++SUBDIRS = doc lib @INTLSUB@ src @POSUB@ ++ +that you will have to adapt to your own package. + +
+distdir = $(PACKAGE)-$(VERSION) +dist: Makefile + rm -fr $(distdir) + mkdir $(distdir) + chmod 777 $(distdir) + for file in $(DISTFILES); do \ + ln $$file $(distdir) 2>/dev/null || cp -p $$file $(distdir); \ + done + for subdir in $(SUBDIRS); do \ + mkdir $(distdir)/$$subdir || exit 1; \ + chmod 777 $(distdir)/$$subdir; \ + (cd $$subdir && $(MAKE) $@) || exit 1; \ + done + tar chozf $(distdir).tar.gz $(distdir) + rm -fr $(distdir) ++ +
+Some of the modifications made in the main `Makefile.in' will +also be needed in the `Makefile.in' from your package sources, +which we assume here to be in the `src/' subdirectory. Here are +all the modifications needed in `src/Makefile.in': + +
+ ++PACKAGE = @PACKAGE@ +VERSION = @VERSION@ ++ +
top_srcdir
+gets defined. This will serve for cpp include files. Just add
+the line:
+
+
++top_srcdir = @top_srcdir@ ++ +
subdir as `src', later
+allowing for almost uniform `dist:' goals in all your
+`Makefile.in'. At list, the `dist:' goal below assume that
+you used:
+
+
++subdir = src ++ +
@INTLLIBS@ as
+a library. An easy way to achieve this is to manage that it gets into
+LIBS, like this:
+
+
++LIBS = @INTLLIBS@ @LIBS@ ++ +In most packages internationalized with GNU
gettext, one will
+find a directory `lib/' in which a library containing some helper
+functions will be build. (You need at least the few functions which the
+GNU gettext Library itself needs.) However some of the functions
+in the `lib/' 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 `libsupport.a') just between the @INTLLIBS@
+and @LIBS@ in the above example. Instead one has to write this:
+
+
++LIBS = ../lib/libsupport.a @INTLLIBS@ ../lib/libsupport.a @LIBS@ ++ +
+distdir = ../$(PACKAGE)-$(VERSION)/$(subdir) +dist: Makefile $(DISTFILES) + for file in $(DISTFILES); do \ + ln $$file $(distdir) 2>/dev/null || cp -p $$file $(distdir); \ + done ++ +
+
Go to the first, previous, next, last section, table of contents. + +