Omission from ballot issue #338

TL;DR: Please approve #338, after which the change draft I submit for your approval will include one additional property, run.language.

Details:

I realized that the ballot proposal for #338, “Introduce new localization mechanism,” is not quite complete. We really do need a language property, because it affects the message string lookup order.

Suppose a tool declares its language as en-US. Then if a viewer wants en-US strings, it should first check to see if the string is inlined in (for example) the result message, and only if not should it look for en-US in run.translations. Whereas if the viewer wants fr-FR strings, it should not look for an inlined string; instead it should immediately look up fr-FR in run.translations.

I also think language is more a property of run than of tool. It means “the language of the messages emitted into the log file during this run.”

I added this information as another “POST-BALLOT NOTE” in the ballot proposal comment.

Thanks,

Larry

sarif message