Re: Run-time internationalized messages

[Hans Aberg]

At 12:07 -0400 2003/05/03, Bruce Lilly wrote:

>Aside from dealing with the output programming language issue, I can
>imagine a few others:
>
>2. API for language switching
>
>3. Where the language-switching code goes -- in each generated parser
>    file, or in a library archive a la liby.a.
>
>4. How the parser keeps track of the desired language, which will have
>    to work for pure parsers as well as for non-reentrant ones.
>
>5. Actually integrating it into the bison build process, automake, autoconf,
>    etc.
>
>#2, #3, and #4 are related. E.g. if the language-switching code goes
>in each parser (presumably because the implementation can't be handled
>in library code), then it should probably be affected by a prefix
>change (yy -> some prefix).

If you want, in a fully dynamic setting, to properly handle the problem of
that some strings may or may not be properly translated, then I think that
the only way is to give name keys to all the strings outputted. The routine
that writes the strings will first make a lookup to see whether the string
is available or not, and if it is not, a default string, probably in
English, will be supplied.

Strings will stored as pairs: The English lookup table will contain pairs like
  {"parse error unexpected", "parse error, unexpected "}
and the Pig Latin lookup table will contain pairs like
  {"parse error unexpected", "arsepay orerray, edunexpectay "}

Then one can select the language by say a command yylocality("English") or
yylocality("Pig Latin"). The parser will invoke a command like
yyprint(stdout, "parse error unexpected"), which will print according to
the latest chosen language by yylocality(). This way, one can alter output
language whenever one wants to, say in the parser actions if one so wants.

Of course, people may want to extend the system above by adding their own
new string names to the lookup table key set. So one must think of ways how
this lookup table can be conveniently extended with new lookup keys.

This seems me to not be a Bison specific problem, but it will be the same
for all projects where one wants to have dynamic language change. So
perhaps there should be a special GNU project for that.

  Hans Aberg
                  * Email: Hans Aberg <mailto:address@hidden>
                  * Home Page: <http://www.math.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>