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