The argument for removing localization support

["Larry Golding (Myriad Consulting Inc)" <v-lgold@microsoft.com>]

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:

 

1. 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!)
2. 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.
3. Itâs not useful, as I argued in the email âtool.language considered unnecessary.â
4. 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)" <v-lgold@microsoft.com>
• To: "Larry Golding (Myriad Consulting Inc)" <v-lgold@microsoft.com>, Michael Fanning <Michael.Fanning@microsoft.com>, OASIS SARIF TC Discussion List <sarif@lists.oasis-open.org>
• 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: sarif@lists.oasis-open.org <sarif@lists.oasis-open.org> On Behalf Of Larry Golding (Myriad Consulting Inc)
Sent: Wednesday, February 13, 2019 3:38 PM
To: Michael Fanning <Michael.Fanning@microsoft.com>; OASIS SARIF TC Discussion List <sarif@lists.oasis-open.org>
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 <Michael.Fanning@microsoft.com>
Sent: Wednesday, February 13, 2019 3:18 PM
To: Larry Golding (Myriad Consulting Inc) <v-lgold@microsoft.com>; OASIS SARIF TC Discussion List <sarif@lists.oasis-open.org>
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: sarif@lists.oasis-open.org <sarif@lists.oasis-open.org> On Behalf Of Larry Golding (Myriad Consulting Inc)
Sent: Wednesday, February 13, 2019 1:12 PM
To: OASIS SARIF TC Discussion List <sarif@lists.oasis-open.org>
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 ---