Re: Bug#114019 acknowledged by developer (Re: Bug#114019: gettextize will not preserve changes to po/Makefile.in.in, and has no way to be told of extra keywords for xgettext (fwd))

[Bruno Haible]

Henrique de Moraes Holschuh writes:

> > > It should have an option switch to inform it of a new set of keywords to 
> > > use
> > > instead of the default _() and N_() in po/Makefile.in.in's invocation of
> > > xgettext.
> > 
> > That's too complex. Careful maintainers keep a patch set versus the
> 
> Say what?!  It's a matter of sed'ing the po/Makefile.in.in after you copy
> it, and this is not complex at all.

This sed-ing would work for the one particular wish you have about
Makefile.in.in. Other people have different wishes, thus different
modifications: use of multiple domains in the same directory, special
casing some languages, special targets for the maintainers, additional
dependencies, etc.

> I did not ask you to parse whatever makefile is in po/Makefile.in.in and
> update that or magically figure out what the user wants. THAT would be too
> complex.

But that would be the only action that solves more than your
particular small problem.

> I already have to tell them to "forget the very idea of
> supporting non-GNU gettext: tell people [SunOS/other users] to use
> --with-included-gettext or you'll go insane"

gettext 0.10.36 and newer gets this right by default.

> "you should not keep the gettext-generated files on your cvs tree,
> cvs is for non-automatically-generated files only", etc.

That's your personal opinion. As a matter of fact, in the gettext CVS,
the gettext-generated files are in the CVS.

> This is a lot more messy than properly supporting such options in
> gettextize, which is supposedly THE centralized place (script) where to keep
> such knowledge

The centralized place for such knowledge is the Makefile.in.in itself,
not the gettextize script.

Bruno