Re: bison and i18n

[Bruno Haible]

Hi,

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
disk.

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

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

Bruno