[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bison and i18n

From: Bruno Haible
Subject: Re: bison and i18n
Date: Tue, 21 Jun 2005 22:55:40 +0200
User-agent: KMail/1.5


After me:
> >  1) Have a bison-runtime package that contains the .mo files, unversioned.
> >  3) Have a package-dependent bison-runtime package, shipped with and
> >     installed by each package that uses a parser.
> > ...
> > The patch I submitted uses approach 3. But I admit that approach 1 is
> > also tempting.

Paul Eggert wrote:
> I see the temptation, but I'm inclined to think that (3) is the better
> choice, at least at first.

The more I think about it, the more I prefer solution 1. It has the advantage
of being simple. So the two drawbacks that we know (bison-runtime.pot can
only grow, and the distributors must learn to split a package into a -runtime
and a -dev package [which they haven't learned so far for gettext...] and
set package dependencies) are the only ones that we'll have to face.

Whereas solution 3 is so complex that more things can go wrong, which are
hard to diagnose:
  - If the package maintainer forgets to distribute the bison-po directory...
  - If the package maintainer forgets to invoke BISON_I18N...
  - If the package maintainer forgets the second bindtextdomain() invocation...
And it doesn't make itself ridiculous by copying the same files onto the user's

> (An advantage to (3) is that the work is already done.  :-)

That doesn't matter. I will redo the patch for (1).


reply via email to

[Prev in Thread] Current Thread [Next in Thread]