feat(localization): Onboard to microbuild loc plugin

[sfoslund]

Details

This PR onboards to the microbuild loc plugin such that the projects that will need to be localized begin generating localize/*/*.lce files in the signed build output. These files will be picked up by the loc team for translation, and eventually the loc team will check .lcl files into this repo.

Test run with these changes: https://dev.azure.com/mseng/1ES/_build/results?buildId=18577457&view=results See relevant files at drop/src/{ projects that need to be localized }/bin/release/netstandard2.0/localize/*.

Motivation

Localization feature

Context

This PR does not address 2 items:

• Including the resulting loc files in signing. I added a TODO in the code to address this as well as created a user story: https://dev.azure.com/mseng/1ES/_workitems/edit/2002189
• Including the resulting loc files in the nuget package. I created a user story to address this: https://dev.azure.com/mseng/1ES/_workitems/edit/2002203

Pull request checklist

• [x] Addresses an existing issue: 2002085

[sfoslund]

@DaveTryon @codeofdusk, 2 quick open questions:

• Do you see any reason we should include loc in the unsigned steps of our pipeline? ATM this PR does not, but it's simple to change that.
• We originally planned on localizing the automation project but looking at it again I don't think that it's actually necessary. Can you please confirm or deny?

[DaveTryon]

• Do you see any reason we should include loc in the unsigned steps of our pipeline? ATM this PR does not, but it's simple to change that.

The non-signed jobs are for compliance reasons and include things CredScan, FxCop, PREfast, PoliCheck, etc. There's a slight chance that we'd need to run PoliCheck on the localized versions--we can probably ask the compliance team for clarification here. Other than that, I wouldn't try to include loc in the compliance jobs.

• We originally planned on localizing the automation project but looking at it again I don't think that it's actually necessary. Can you please confirm or deny?

Doing a quick review of the code, all of the strings defined in the Automation project are messages for Exceptions, which we've determined are out of scope for this feature. As such, I agree that we can omit the Automation project. I also noticed that the ErrorUnhandledExceptionFormat string is no longer used--I think it was used only in the recently removed ExecutionWrapper class.

[sfoslund]

The non-signed jobs are for compliance reasons and include things CredScan, FxCop, PREfast, PoliCheck, etc. There's a slight chance that we'd need to run PoliCheck on the localized versions--we can probably ask the compliance team for clarification here. Other than that, I wouldn't try to include loc in the compliance jobs.

I have sent an email asking the compliance team for guidance on this topic. If they end up confirming that we do need to run these tools on the localized versions then I'll make a follow up PR to do so.