Re: Grammatical forms in translatable texts

[Frank Heckenbach]

Akim Demaille wrote:

> >>> YYCASE_(2, YY_("syntax error.\nunexpected token: '%s'\nExpected token: 
> >>> '%s'"));
> >>> YYCASE_(3, YY_("syntax error.\nunexpected token: '%s'\nExpected token: 
> >>> '%s' or '%s'"));
> >>> YYCASE_(4, YY_("syntax error.\nunexpected token: '%s'\nExpected token: 
> >>> '%s' or '%s' or '%s'"));
> >>> YYCASE_(5, YY_("syntax error.\nunexpected token: '%s'\nExpected token: 
> >>> '%s' or '%s' or '%s' or '%s'"));
> >> 
> >> This is sooo different from what compilers do!  Not to mention
> >> that, for lack of a specific prefix, tools such as Emacs will
> >> not be able to highlight this part as belonging to a diagnostic.
> > 
> > That was my first thought, too. But I think the issue is mainly
> > about the line breaks. One could instead put the "form" in one line,
> > or Bison could insert the prefix in each line; of course, this would
> > require a bit of effort (finding the line breaks etc.), but seems
> > doable as well.
> 
> I cannot do that.  I have no idea what the user is doing in yyerror.
> Bison forges the error message, and passes it to the user.  She is
> in charge of delivering it to the user, possibly after having added
> the location somewhere.  And maybe increment some count of number of
> errors, etc.  And possibly opening a GUI alert window to pass the
> message.  Or syslog it.

Yes, right. So perhaps the single-line "form" might be a good
compromise between formatability and translatability.

Another advantage (of either form variant) might be that one
wouldn't actually need to translate 5 cases -- since the token lists
(intentionally) won't form a sentence, they could just be
comma-separated, so only "... Expected token: %s" would need to be
translated.

> (Then again, we are talking about several distinct issues: (i) the canned
> error message that goes into generated parser, and (ii) bison's own
> diagnostics.  Here I'm answer to (i).)

I was also talking about (i). I think Bison's own messages are not
affected, except insofar as Bison uses itself for its parser, but
that would be a special case of (i).

> AFAICT from the different cases where I saw people hack the system
> to get some control over the way tokens are displayed, I believe most
> users don't really care about how correct the resulting sentence is.
> Those who do can go "%define parse.error custom" and take control.

I don't really agree, partly because we're talking about different
kinds of users. The user of Bison, i.e. writer of a parser, might
not care much at all about translations, or not know about
grammatical issues in other languages etc., whereas the end-users of
the parser, or even the translators, often have no say in which kind
of translation strategy the parser employs.

Obviously things differ between languages and personal tastes, but I
for one prefer correct English to bad German. In fact I've often
used "LANG=de_DE LC_MESSAGES=C" myself anyway because of IMHO
questionable translations (esp. of technical terms), and bad German
grammar would be another reason for me to keep doing so.

> I can add "%define parse.error form" if you think that would be
> useful, but I don't want it to change the behavior of "verbose" or
> "detailed".

I think I would be useful only if it's actually used much. Now I
don't worry so much about my own parsers, but other parsers that I
end up using. Adding another option without recommending it (or even
recommending the existing ones) seems more like an xkcd-927
situation to me.

Regards,
Frank