- Neutral resources: *resx
Strings.shared.resx
is a shared resource and gets embedded into all msbuild dlls- each neutral resource has a directory named
xlf
besides it which contains its localized strings in .xlf format - there is one language per xlf
- the logical name for a resource is:
<Assembly Name>.<Neutral Resx File Name>.resources
. In the ResourceManager this appears as<Assembly Name>.<Neutral Resx File Name>
(without the trailing.resources
). For example, theMicrosoft.Build
assembly uses theMicrosoft.Build.Strings.resources
logical resource name (the resource file isStrings.resx
), and its corresponding ResourceManager usesMicrosoft.Build.Strings
.
- if you need to add / remove / update a resource, only do so in the neutral resx files. xlf files get automatically updated during localized builds.
- converts xlf files to localized resx files
- the localized resx files are generated into the
$(IntermediaryOutputPath)
- produces satellite assemblies for each language
- satellite assemblies are used even on English machines. This is for testing purposes, to ensure that English builds are not different than non English builds
- 3 weeks cadence for master, initiated by loc team
- on demand for master / release branches, initiated by msbuild team
- send a PR with an updated
<target>
element of the xlf resource (do not include other non-localization changes) - we will notify the localization team, which will then take over and review the PR
Code completion ("IntelliSense") for MSBuild project files is provided minimally in Visual Studio by XML Schema files like Microsoft.Build.CommonTypes.xsd
. These files are English-only in the GitHub repo; their localization is managed in the Microsoft-internal VS
repo.
File xsd localization bugs in this repo. The MSBuild team will coordinate with the Visual Studio localization team to redirect it appropriately.
After updating an XSD in the GitHub repo, someone with internal access must update the copy in the VS
repo. To do so:
- Locally clone VS following the standard instructions.
- Locally update your clone of the GitHub msbuild repo to include the merge of the change.
- Start a new branch in the VS repository from the current working branch (probably
master
). - Copy from the msbuild path
src/MSBuild/MSBuild/*.xsd
to the VS pathsrc/xmake/XMakeCommandLine
. - Ensure that the commit message has a full link to the commit used to update the
.xsd
files, likehttps://github.com/microsoft/msbuild/commit/ba9a1d64a7abf15a8505827c00413156a3eb7f62
. - Push and submit through the usual VS PR process, including the
MSBuild
team as reviewers.
Example PR doing this: https://dev.azure.com/devdiv/DevDiv/_git/VS/pullrequest/186890.