bison and i18n

[Bruno Haible]

Hi,

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
   .y file.

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
   POTFILES.in are
     - 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
     --prefixes.

The idea is that
  - bison provides a set of .po / .mo files for the use of the programs at
    runtime,
  - 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: +&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.

Bruno

bison-diffs
Description: Text document