Use same language set for .wxl and .json files #43888
Conversation
- translation infrastructure works better when `Projects` elements use same languages - previous use of two+two codes were an unnecessary complication and cover the same languages - `WiX_CloneLanguages` already updated on loc side to use the default two-letter language codes
dougbu
added
the
area-infrastructure
|
Hey @dotnet/aspnet-build, looks like this PR is something you want to take a look at. |
| @@ -91,6 +91,7 @@ $locJson = @{ | |||
| ) | |||
| }, | |||
| @{ | |||
| LanguageSet = $LanguageSet | |||
There was a problem hiding this comment.
Shouldn't this change be in Arcade?
There was a problem hiding this comment.
I'm rushing a bit because a change on the loc side (the WiX_CloneLanguages change mentioned in the description) broke the current aspnetcore-localization pipeline and caused the messed-up e532948 commit. That commit adds incorrectly-mapped files like src/Installers/Windows/SharedFrameworkBundle/cs-CZ/thm.wxl.
I'm about to put up a PR for Arcade making exactly the same fix but want tomorrow's OneLocBuild task to work cleanly.
|
Will check this in as soon as it's approved since my test build (#20220908.2) already ran successfully. Resulting loc project looked good. It was the regular build from main that borked things. |
ghost
added this to the
|
Merged immediately because CI build has nothing to do w/ the changed file. |
- translation infrastructure works better when `Projects` elements use same languages - previous use of two+two codes were an unnecessary complication and cover the same languages - `WiX_CloneLanguages` already updated on loc side to use the default two-letter language codes
Projectselements use same languagesWiX_CloneLanguagesalready updated on loc side to use the default two-letter language codes