Remove current localization mechanism

[michaelcfanning]

No description provided.

[michaelcfanning]

Verify with GrammaTech that they don't intend to use the feature, otherwise remove.

[michaelcfanning]

As a consequence of this, we no longer require tool.name to be a message (as it can no longer be localized). Instead it can revert to being a string.

Also, reportingDescriptor.name can revert to being a string.
And exception.message will revert to being a string.
@lgolding

[ghost]

Paul confirmed that Grammatech isn't using this feature. In an email, I gave four reasons for removing it:

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 Provide full metadata objects for notifications #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.

UPDATE We now have a customer at MS who wants to localize their SARIF files, but @michaelcfanning, @kupsch, and I agree that the current design will not serve, mostly due to reason #4. This proposal removes the current, inadequate design. We are working on a replacement, but it's not ready, so it is not on the e-ballot.

[michaelcfanning]

EBALLOT PROPOSAL: remove existing localization mechanism. See above for rationale. Because we no longer utilize the message.messageId property to drive localization scenarios, certain SARIF properties can be retyped as multiformatMessageString instances.

API IMPACT

• In the tool object:
  • Remove the language property.
• In the reportingDescriptor object:
  • Change the type of the name property from message object to string.
  • Change the type of the shortDescription property from message object to multiformatMessageString object.
  • Change the type of the fullDescription property from message object to multiformatMessageString object.
• In the exception object:
  • Change the type of the message property from message object back to string (as once it was).

NOTES
The TC is developing a new proposal for localization that may replace the current mechanism that we propose to remove (due to its obvious flaws).

[ghost]

Approved in e-ballot-3.