Re: Run-time internationalized messages

[Hans Aberg]

At 17:19 -0400 2003/05/02, Bruce Lilly wrote:
>I'm somewhat hesitant to call this a bug, let's call it a feature request...
>
>A bison-built parser has compiled in strings such as "syntax error: cannot
>back up", "syntax error, unexpected ", ", expecting ", " or ", "Error:
>popping",
>etc. Once bison has run, those strings are hard-coded into the bison-produced
>C file.  It would be nice if bison provided alternative language versions
>of those strings and a means to select the language when the resulting parser
>is run. Independently of whether or not bison is installed on the system
>running
>the parser (that means that the variants and a means of selecting should
>be written into the C file that bison produces).  Since there are only
>a few short strings, that shouldn't present much overhead.  Ideally,
>the language selection method should be flexible enough that the language can
>be frequently changed during a single run of the parser and can be set
>differently for different processes even if the (pure) parser is built
>into a shared object file. Also, the mechanism should ideally be platform-
>independent (in particular, the existence of anything resembling a file
>system shouldn't be presumed).

The topic of making the printed strings independent of the parser has been
discussed here before, but for different reason:

If one uses multiple parser algorithms/computer output languages, it
becomes nuisance of having to coordinate them all, unless one rationalizes
such things as putting the strings in one special file.

I think that Akim Demaille said that was on some future working list.

I think that the approach in mind here was a static approach. This should
not even be very difficult to do, in view of Bison's current M4 approach:
Simply replace all output strings that the parser uses with macros, then
merely supply a special string macro file. If you then want to change the
parser strings, merely change that output.

Now you evidently want a dynamic approach. One approach might be to put all
the default strings in character arrays, which easily can be changed at
runtime, if the names of the strings are known. If the strings are already
in M4 macros, the only thing that would be needed is a special M4 skeleton
file.

As for the question of making the thing platform independent, there is no
such a thing with respect to output languages like C/C++. So there you are
left out in the cold. When I discussed it in a C++ newsgroup, the best
thing that people really needing this feature (as those writing WWW
browsers/servers and such) currently could find was to give names to each
character according to some encoding, and then use that. For example, using
Unicode:
   unsigned LATIN_CAPITAL_LETTER_A = 0x0041;
   ...
or
   #define LATIN_CAPITAL_LETTER_A 0x0041
   ...
Then use LATIN_CAPITAL_LETTER_A instead of "A". One can probably easily
produce such list of characters by taking down the Unicode Namelist and
convert to C format via a suitable small program.

All remains is finding someone willing to do the job. :-)

  Hans Aberg