Re: moving po/Makefile.in.in to automake

[Bruno Haible <bruno at clisp dot org>]

Denis Barbier wrote on 2003-11-12:
> > The 8-year old way of distributing a PO file directory has several drawbacks:
> >  - requires separate files (POTFILES.in, Makevars) for customization,
>
> I can hardly see why this is a drawback.  You added support for a
> separate po/LINGUAS file in 0.11, and it helped a lot. Here you go
> the opposite way, and I do not understand why.

The separate po/LINGUAS has two reasons:
  - It's a place the store the set of languages other than in configure.ac
    (doesn't fit there for packages with multiple po/ directories) and in
    po/Makefile.in.in (which is usually copied from gettext without
    modifications).
  - It allows "late" addition of translations by a Linux distributor, as a
    drop-in into an already released package.

For the other customizations there is no real need to put them into separate
files. And since in most directories, all build-relevant settings are found
in a Makefile.am, it's hard to learn for newbies why it should be different
in po/ directories.

> With your new scheme, one has to re-run Automake and friends when a file is
> marked as containing translatable strings.

Yes. Marking a file as containing translatable strings is a task performed
by a package's maintainer, and it's allowed to require an automake run.
Actually when the maintainer adds the file to xyz_SOURCES in Makefile.am,
it also forces an automake invocation.

> Also did you talk to GNOME folks?  Intltool accepts some extra markup
> in po/POTFILES.in (e.g. file type or encoding), and thus my guess is
> that they prefer a separate file.

They prefer a separate file because the current po/Makefile.in.in mechanism
doesn't permit them to do it another way. Extra flags for xgettext can
always be accomodated through Makefile.am variables.

Bruno