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))

[Henrique de Moraes Holschuh]

Bruno Haible wrote:
> gettextize is a wizard, but without artificial intelligence. Some
> local intelligence is still needed.

Nice. But all shortcomings of such tools should be properly documented, and
since one is supposed to use gettextize to apply a version update to an
application using gettext, it would be a good thing to support *command line
switches* that can change its mode of operation.

> > 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. It does not in any way requires an AI
engine.  And this feature is _needed_ when one has to deal with DES
libraries that already use _(), for example (some kerberos ones do).

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.

If I code an extra option patch to gettextize, properly document it, and
submit such a patch will you accept it?

It's already reasonably difficult to keep some upstream maintainers (ESR,
for example) from removing gettext support when it causes breakage on their
packages (more often than not the breakage is not gettext's fault, but
that's beside the point), but if I have to tell them that they must use a
patch file on top of everything else...

Not that it is difficult to apply such a patch, but it is the principle of
the thing, really.  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", "ditch whatever old, buggy
gettext release your distro has, and use the newest one to fix those
makefile problems", "what about including the new i18n plural handling
support? it is important for some people", "you should not keep the
gettext-generated files on your cvs tree, cvs is for
non-automatically-generated files only", etc.

If I also tell them to "apply this diff patch over the result of gettextize
every time you package a new tarball", they will tell me to fuck off and
refuse to add i18n to their packages (or much worse, actually remove such
support. I'm fighting against such a removal right now).  Some people can be
very unreasonable about the extra trouble adding i18n to their apps cause.

> original version and reapply this patch set each time they upgrade.

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; everyone that needs such functionality will have to reinvent
the wheel after being hit by the breakage. That is Bad Politics and a Bad
Idea IMHO.

> Your CC lines have been lost through the mail -> archive processing.
Dang, that messes up the Debian BTS a bit, but that can be fixed by hand.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh