SDK zips are missing NuGet.Tasks.Pack localization content

[mmitche]

<BaseFile>C:\scratch\vmr-compare\non-vmr-assets\sdk\shipping\assets\Sdk/10.0.100-preview.3.25166.6/dotnet-sdk-10.0.100-preview.3.25166.6-win-arm64.zip</BaseFile>
<EvaluationErrors />
<Issues>
<Issue Type="MissingPackageContent" Description="sdk/Sdks/NuGet.Build.Tasks.Pack/CoreCLR/cs/NuGet.Build.Tasks.Pack.resources.dll" />
<Issue Type="MissingPackageContent" Description="sdk/Sdks/NuGet.Build.Tasks.Pack/CoreCLR/de/NuGet.Build.Tasks.Pack.resources.dll" />
<Issue Type="MissingPackageContent" Description="sdk/Sdks/NuGet.Build.Tasks.Pack/CoreCLR/es/NuGet.Build.Tasks.Pack.resources.dll" />
<Issue Type="MissingPackageContent" Description="sdk/Sdks/NuGet.Build.Tasks.Pack/CoreCLR/fr/NuGet.Build.Tasks.Pack.resources.dll" />

[jkoritzinsky]

Looks like NuGet.Client runs the MicroBuild localization targets to generate these files. The VMR currently doesn't run those (and can't outside of the official build), so we need to enable that in NuGet's VMR build (and only such in the official build). Figuring out how to do that now.

[jkoritzinsky]

We may need to set up parallel infra for localization for NuGet based on OneLocBuild or something to get xliff working with them so we don't need to install MicroBuild Localization in our pipelines.

[mmitche]

@jkoritzinsky Is it more expedient to use the microbuild tasks?

[jkoritzinsky]

I spent Friday iterating on a solution here. Here's our two options:

1. MicroBuild Tasks

We can use the MicroBuild tasks as they are today. However, this also means that we need to onboard the NuGet/NuGet.Build.Localization repository to the VMR as the mechanism through which it works in NuGet.Client (checkout a submodule to a branch of the same name as the NuGet.Client branch during the official build) is not tenable. Onboarding this repository should be reasonable as we can easily include only the folders with the localization files, which are all XML.

Alternatively, we could try to switch NuGet.Build.Localization to flow the localization info as a package to NuGet.Client. If we're doing large infrastructure work in NuGet though, I'd prefer we go with the next option as we'd have to pull in people from NuGet as this would be a relatively large change.

2. Onboard to OneLocBuild, or at least XLF

We could onboard NuGet.Client to OneLocBuild with their own OneLocBuild job (not using the Arcade job as they still aren't onboarded onto Arcade) and .xlf files (or use MicroBuild localization with .xlf files if that tooling supports it). If we're able to get onto XLF files, then we can avoid onboarding custom localization tooling into the VMR itself as Arcade provides packages that can handle localization via XLF.

[jkoritzinsky]

It looks like MicroBuild's tasks have some issues with running on non-Windows platforms, so option 1 might not be as easy as I thought.