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