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