[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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:
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.
--- Begin Message ---
- From: "Larry Golding (Myriad Consulting Inc)" <firstname.lastname@example.org>
- To: "Larry Golding (Myriad Consulting Inc)" <email@example.com>, Michael Fanning <Michael.Fanning@microsoft.com>, OASIS SARIF TC Discussion List <firstname.lastname@example.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.
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.
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.
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.
--- End Message ---