The argument for removing localization support

First of all, you can all thank me for not using my habitual subject line formulation, âLocalization support considered not well thought outâ.
😊

 

At TC #32 on Wednesday Iâll propose to remove all localization support, including
tool.language, from SARIF. I already sent mail (attached) discussing my reservations about
tool.language.

 

More generally, my concerns about our localization support are:

 

Itâs not exercised. Iâm not aware of any SARIF-producing tool that offers multiple language output. (If there were one, Iâll bet itâs author would have complained about #4 below!)

Michael has always objected that the current design imposes constraints on how tools store arrange their resource files on the file system or on the web. Iâve argued back that this
 is necessary to allow tools to locate resources for other languages, but that doesnât make it a good design.

Itâs not useful, as I argued in the email âtool.language considered unnecessary.â

Itâs badly designed. Itâs always bothered me â and I should have raised this earlier; itâs just something I swept under my mental rug â that the contents of
run.resources are a mix a localizable strings and on-localizable metadata. That is, the
rule object (as of #311, the 
reportingDescriptor object) includes messageStrings and
richMessageStrings (localizable) and 
configuration (level, 
rank, and parameters: non-localizable). So if you duplicate the resources into multiple languages, you have to keep the rule metadata in sync across all of them.

 

I especially dislike #4. Weâd really need to redesign this, and Iâm arguing that now is not the time. IMO we are now at the point where, in the interest of closure, we should be jettisoning little-used and poorly designed features, rather
 than spending time to fix them.

 

Thanks,

Larry

 

 

--- Begin Message ---

From: "Larry Golding (Myriad Consulting Inc)" <>

To: "Larry Golding (Myriad Consulting Inc)" <>, Michael Fanning <>, OASIS SARIF TC Discussion List	<>

Date: Wed, 13 Feb 2019 23:44:55 +0000

To support my scenario immediately below, we would replace 
tool.language with tool.availableLanguages. But it would live on
toolComponent, not 
tool, because not every plugin will support the same set of languages.

 

I would not recommend a change like that without more thought, and I’d rather not spend time on that now. I’d like to concentrate on closing SARIF 2.0. We could consider this for SARIF 2.1.

 

But removing tool.language is something I would consider for 2.0, because it’s not breaking anyone now to remove it (I’ll bet), and adding it back later is non-breaking. I think it’s safer to remove a property whose value
 we’re unsure of than to keep it around, and then find out later that it isn’t quite fit for purpose.

 

Larry

 

From:  <>
On Behalf Of Larry Golding (Myriad Consulting Inc)

Sent: Wednesday, February 13, 2019 3:38 PM

To: Michael Fanning <>; OASIS SARIF TC Discussion List <>

Subject: [sarif] RE: tool.language considered unnecessary

 

It’s not strictly required.

 

The spec defines an algorithm for resource lookup:

 

“If you want 
fr-FR, look for a file named fr-FR.sarif-resources under
tool.resourceLocation (now 
toolComponent.resourceLocation). If you can’t find it, look for 
fr.sarif-resources in the same place. If you still can’t find it, do whatever you can to find it – for example, prompt the user”.

 

tool.language defines a starting place for the resource lookup. But it’s not clear that’s what the end user wants. I don’t care if the log file says
fr-FR, I still want the 
en-US messages. For my purposes, the lookup should start with my locale, not with whatever the log file happens to say.

 

There is one scenario, aside from the one I mentioned below, where
tool.language might be useful. Suppose a tool supplies
only French and Italian resources, and suppose they live on the web. Now I open a log file and I want to see resources for my locale,
en-US. The lookup procedure fails: there is no file
en-US.sarif-resources under 
resourceLocation. Now what should I do? If the log file specifies 
tool.language: fr-FR, I at least know that French is available, and maybe my high school French will help a little. Whereas if the log file doesn’t specify a language,
I have no way to know what languages are available – they’re out on the web; it’s not like I can issue a “dir” command on the resource location.

 

Maybe this scenario, together with the one below, is enough to justify the property. Or maybe others can come up with other scenarios for it.

 

Larry

 

From: Michael Fanning <>

Sent: Wednesday, February 13, 2019 3:18 PM

To: Larry Golding (Myriad Consulting Inc) <>; OASIS SARIF TC Discussion List <>

Subject: RE: tool.language considered unnecessary

 

Isn’t that data required if a log file utilizes the localized resources look-up scheme? IOW, all possible strings are stripped from the log file in favor of external localized content. tool.language documents what resources to retrieve.

 

From:  <>
On Behalf Of Larry Golding (Myriad Consulting Inc)

Sent: Wednesday, February 13, 2019 1:12 PM

To: OASIS SARIF TC Discussion List <>

Subject: [sarif] tool.language considered unnecessary

 

Motivation: Most tool object properties are moving to
toolComponent, so we will have 
tool.driver of type toolComponent, and
tool.extensions of type 
toolComponent[]. The only other property left on 
tool is language.

 

Question: The spec says that 
language is “the language of the messages produced by the tool”. If I can read them, I know what language they are. If I can’t read them, I don’t
care what language they are (and I might ask my SARIF viewer to go find the tool’s
en-US strings). Why do I need 
tool.language?

 

The only scenario I can think of is where a result management system used by an English-speaking engineering team consumes a log file with messages in
fr-FR, and decides to help out by downloading the tool’s
en-US strings.

 

Thoughts?

 

Thanks,

Larry

--- End Message ---