(gettext.info.gz) Prerequisites

Info Catalog

(gettext.info.gz) Flat and Non-Flat

(gettext.info.gz) Maintainers

(gettext.info.gz) gettextize Invocation

 
 13.2 Prerequisite Works
 =======================
 
 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.
 
    * Before attempting to use `gettextize' you should install some
      other packages first.  Ensure that recent versions of GNU `m4',
      GNU Autoconf and GNU `gettext' are already installed at your site,
      and if not, proceed to do this first.  If you get 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 by 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.
 
    * Your package should use Autoconf and have a `configure.in' or
      `configure.ac' 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.
 
    * Your C sources should have already been modified according to
      instructions given earlier in this manual.   Sources.
 
    * Your `po/' directory should receive all PO files submitted to you
      by the translator teams, each having `LL.po' 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.
 
 
    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 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 option 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.
 

Info Catalog

(gettext.info.gz) Flat and Non-Flat

(gettext.info.gz) Maintainers

(gettext.info.gz) gettextize Invocation