> Le 11 mai 2018 à 05:19, Frank Heckenbach <[email protected]> a écrit : > > Akim Demaille wrote: > >>> I also find the code a bit strange at all; why have a number of format >>> strings >>> that differ only in the number of "or %s" parts, and which must all be >>> translated individually? Rather than adding repeated parts in a loop, or >>> using >>> a more flexible wording such as "expecing one of the following: « ? >> >> Because of internationalization: you don't know how it would be >> translated, how punctuation would be, etc. > > In my suggestion only the text "expecing one of the following:" > would need to be translated.
Yes, I see that, but it seems less natural, and will require special treatment for the case 1 anyway. So far everybody agreed that if there are too many options, listing them is useless, so that « limitation » is not a real one, it is a feature. Would you agree with that? > It would be followed by a list of > tokens only, with no more text. Since token names themselves are not > translated either AFAIK, No, they are not, indeed. > the separator doesn't need to be (i.e., > even if some language uses some other than commas to separate lists, > it would be strange to use them in a list of English token names). > If that's really problematic, it will be hard for internationalized > programs to output any lists at all ... > >>> Anyway, this patch does just the minimum necessary to avoid the warning (and >>> make the code more robust in case someone changes >>> YYERROR_VERBOSE_ARGS_MAXIMUM), by using "default" instead of "case 0 ». >> >> But it would be incorrect anyway. > > I think not strictly incorrect. It would just default to outputting > no token names (as it's currently supposed to do in this case, > anyway). Yes. I meant « incorrect » more in the sense of « inconsistent ». The behavior would not be visibility wrong for the user, but not what the developer would have expected. I’m referring to the same things than you in: > Actually I do find the code rather fragile; the definition of > YYERROR_VERBOSE_ARGS_MAXIMUM does not even have a comment pointing out the > ramifications of changing it. >> Would `default: abort` suit you? > > Mostly what bothers me is the compiler warning, so anything that > avoids that is basically fine with me. I’ll try that then.
