Re: bison and i18n

[Stepan Kasal]

Hello,

On Tue, May 31, 2005 at 10:07:24PM +0200, Bruno Haible wrote:
> The drawback regarding the bison-runtime dependency would be void
> if there is agreement to introduce a bison-runtime package _anyway_.

I think this is an important point.

If the bison-runtime contains only the .mo file, then many distributors
will forget to set the dependency.
But if we change bison so that it installs a shared library which will
eventually be used bu the applications, then the dependency will be
discovered automatically.

Then each package using bison would use libison, if it is installed.
If not, it would fall back to an old copy of *.c code, which wouldn't
support localization.

So it is a good idea to introduce libison and a central *.mo file
together.  I discussed the idea in the other mail, and I think this
is a good thing to implement in the longer run.
But there are several questions:
-- does the bison maintainer like my idea?
-- if yes, who and when will find capacities to implement it.

So I think 1)+libison is a good solution.
The question is, whether 3) should be accepted as a temporary solution.
Pro: it's ready.
Contra: one more concept introduced; it'll confuse bison users.

Bruno, you are men of action!  Perhaps you could implement libison? [1]
        ;-)
I don't want to annoy you, of course.  Not only the patch but also
your analysis of the situation and its explanation is very good work.
Thank you very much for it.

[1] The first implementation can be very minimalistic: all we need is
to move all messages to the library.  All the rest can stay in the
generated *.c code for now.
What has to be implemented is the autotools mechanism which would
rerun `bison --libison' to replace the distributed *.c file.

Have a nice day,
        Stepan Kasal