[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bison and i18n
bison and i18n
Fri, 27 May 2005 13:29:03 +0200
bison-2.0a contains this NEWS entry:
* Bison-generated C parsers use the _ macro to translate strings from
English to the user's language, e.g., _("syntax error"). By default,
_ is defined to be a no-op macro so the strings are not translated.
The way this is implemented, it has several flaws:
1) It puts repeated burden on the translators. Namely, the translators will
have to translate the bison specific messages for each package that uses
a bison generated parser, over and over again. This is very bad.
This wouldn't be a problem if all translators for a given language would
share a common translation memory, but that's far from reality.
In reality, 1. Translators from the TP, GNOME, KDE and smaller translation
projects don't even know about each other; 2. Many translation teams
don't have a common translation memory; 3. The translation of different
packages that use bison will usually be done by different people.
2) The maintainer needs to modify his .y file in a way specific to bison,
namely to define the _() macro so that it uses gettext() or dgettext().
We had this situation already twice in the past:
- The bison skeleton uses NULL, which made it necessary, for the sake
of SunOS 4, to add #include <stddef.h> to the .y file. (Remember
that <stdlib.h> on SunOS 4 doesn't define NULL.)
- The bison skeleton uses alloca(), and on AIX 3 this requires a
#pragma alloca to be added first.
IMO, bison should attempt harder to not require modifications of the
3) The gettext documentation recommends that generated files don't be added
to the POTFILES.in file. If you tell people to add a bison generated .c
file to POTFILES.in, you are making a bad precedent.
The reasons for preferring the source file over the generated file in
- When the translator needs some context, the translator tools should
better show them the real source rather than a generated file.
- Comments for translators might be dropped from the generated file
(depending on the transformation process).
Instead, here is a proposed solution that
1) doesn't put extra burden on the translators,
2) doesn't require modification of the .y file,
3) doesn't violate best practices regarding POTFILES.in,
4) minimizes the changes that maintainers need to do to their
configure.ac + Makefile.am infrastructure,
5) allows different programs to be 100% localized even if they use different
versions of bison and even if they are installed with different
The idea is that
- bison provides a set of .po / .mo files for the use of the programs at
- bison provides an autoconf macro and automake support that copies these
.mo files from an installed bison into the package that uses bison, and
during "make install" into the LOCALEDIR used by the program.
(This also applies to some gnulib modules; expect to see some gnulib modules
to be accompanied with po/ directories in the future.)
Find attached a patch that implements this. I've tested it with GNU awk.
So that in a German locale
$ gawk '+&52#'
gawk: ^ Syntaxfehler
The patch contains a German translation catalog, for testing purposes.
The patch contains also updated documentation. I've removed the paragraph
from the "Bison Parser" section, which is an introductory section, and
preferred to explain these things in a later section in chapter
"Parser C-Language Interface".
I hope you can apply this patch before bison-2.1, because putting repeated
burden on the translators is really a thing one should not do. Better
tell the maintainer to perform an optional 8-step procedure once than to
let the translators re-translate the same things over and over again.
Description: Text document
- bison and i18n,
Bruno Haible <=