Repository navigation
Copy localized strings from ContextMenu into the resource root - #12491
Merged
3 commits merged intoFeb 15, 2022
Merged
3 commits merged into
3 commits merged into
Conversation
Member
Author
ghost
added
Area-UserInterface
Member
Author
|
|
Dustin L. Howett (DHowett)
marked this pull request as ready for review
February 14, 2022 23:40
Dustin L. Howett (DHowett)
requested review from
Michael Niksa (miniksa) and
Mike Griese (zadjii-msft)
and removed request for
Michael Niksa (miniksa)
February 14, 2022 23:41
Mike Griese (zadjii-msft)
approved these changes
Feb 15, 2022
Mike Griese (zadjii-msft)
left a comment
Mike Griese (zadjii-msft)
left a comment
Member
There was a problem hiding this comment.
this is so BODGY i love it
Leonard Hecker (lhecker)
approved these changes
Feb 15, 2022
Leonard Hecker (lhecker)
left a comment
Leonard Hecker (lhecker)
left a comment
Member
There was a problem hiding this comment.
The PowerShell script could be simplified, but it works, so... eh.
Member
Author
Eh. Straightforward is better than clever here :) |
Dustin L. Howett (DHowett)
added
the
AutoMerge
|
Hello Dustin L. Howett (@DHowett)! Because this pull request has the p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (
|
ghost
deleted the
dev/duhowett/copyloc
branch
February 15, 2022 15:11
Dustin L. Howett (DHowett)
added a commit
that referenced
this pull request
Feb 16, 2022
We chose to use the "ContextMenu" resource compartment when we changed the package name to Terminal in #12264 because it was more broadly localized than the rest of the application. It appears as though some platform features have trouble with the "more qualified" resource paths that #12264 required. To fix this, we will: 1. Copy all of the ContextMenu localizations into CascadiaPackage's resource root 2. Switch all manifest resource paths to use resources from the package root. Regressed in #12264 Closes #12384 Closes #12406 (tracked in microsoft/PowerToys#16118) (cherry picked from commit 9501b23)
Dustin L. Howett (DHowett)
added a commit
that referenced
this pull request
Feb 16, 2022
We chose to use the "ContextMenu" resource compartment when we changed the package name to Terminal in #12264 because it was more broadly localized than the rest of the application. It appears as though some platform features have trouble with the "more qualified" resource paths that #12264 required. To fix this, we will: 1. Copy all of the ContextMenu localizations into CascadiaPackage's resource root 2. Switch all manifest resource paths to use resources from the package root. Regressed in #12264 Closes #12384 Closes #12406 (tracked in microsoft/PowerToys#16118) (cherry picked from commit 9501b23)
|
🎉 Handy links: |
ghost
mentioned this pull request
|
🎉 Handy links: |
Dustin L. Howett (DHowett)
added a commit
that referenced
this pull request
Mar 8, 2024
Right now, the localization submission pipeline runs every night and sends our localizable resources over to Touchdown. Later, release builds pick up the localizations directly from Touchdown, move them into place, and consume them. This allowed us to avoid having localized content in the repository, but it came with too many downsides: - Users could not contribute additional localizations very easily - We use the same release pipeline and Touchdown configuration for every branch, so strings needed to either slightly match or _entirely match_ across an entire set of active release branches - Building from day to day can pull in different strings, making the product not reproduceable - Calling TDBuild during release builds requires network access from the build machine (so does restoring NuGet packages, but that's neither here nor there) - Local developers and users could not test out other languages This pull request moves all localization processing into the nightly build phase and introduces support for checking loc in and submitting a pull request. The pull request will not be created anew if one already exists which has not been merged. Anything we needed to do on release is now done overnight. This includes moving loc files into the right places and merging the Cascadia resources with the Context Menu resources (so that we can work around a relatively lower amount of translations being chosen for the app versus the context menu; see #12491 for more info.) There are some smaller downsides to this approach and its implementation: - The first commit is going to be huge - Right now, it only manages a single branch and uses a force push; if a PR is not reviewed timely, it will be force-pushed and you cannot see the day-to-day changes in the strings. Hopefully there won't be any. I've taken great care to ensure that repeated runs of this new pipeline will not result in unnecessary whitespace changes. This required changing how we merge ContextMenu.resw into CascadiaPackage to always use the .NET XmlWriter with specific flags. NOTE that this does not allow users to _contribute_ translation fixes for the 10 languages which we are importing. We will still need to pull changes out of those files and submit them as bugs to the localization team separately, and hope they come back around in another nightly build. However, there is no reason users cannot contribute _non-Touchdown_ languages.
Dustin L. Howett (DHowett)
added a commit
that referenced
this pull request
Mar 8, 2024
Right now, the localization submission pipeline runs every night and sends our localizable resources over to Touchdown. Later, release builds pick up the localizations directly from Touchdown, move them into place, and consume them. This allowed us to avoid having localized content in the repository, but it came with too many downsides: - Users could not contribute additional localizations very easily - We use the same release pipeline and Touchdown configuration for every branch, so strings needed to either slightly match or _entirely match_ across an entire set of active release branches - Building from day to day can pull in different strings, making the product not reproduceable - Calling TDBuild during release builds requires network access from the build machine (so does restoring NuGet packages, but that's neither here nor there) - Local developers and users could not test out other languages This pull request moves all localization processing into the nightly build phase and introduces support for checking loc in and submitting a pull request. The pull request will not be created anew if one already exists which has not been merged. Anything we needed to do on release is now done overnight. This includes moving loc files into the right places and merging the Cascadia resources with the Context Menu resources (so that we can work around a relatively lower amount of translations being chosen for the app versus the context menu; see #12491 for more info.) There are some smaller downsides to this approach and its implementation: - The first commit is going to be huge - Right now, it only manages a single branch and uses a force push; if a PR is not reviewed timely, it will be force-pushed and you cannot see the day-to-day changes in the strings. Hopefully there won't be any. I've taken great care to ensure that repeated runs of this new pipeline will not result in unnecessary whitespace changes. This required changing how we merge ContextMenu.resw into CascadiaPackage to always use the .NET XmlWriter with specific flags. NOTE that this does not allow users to _contribute_ translation fixes for the 10 languages which we are importing. We will still need to pull changes out of those files and submit them as bugs to the localization team separately, and hope they come back around in another nightly build. However, there is no reason users cannot contribute _non-Touchdown_ languages. (cherry picked from commit ab4b140) Service-Card-Id: 92019663 Service-Version: 1.18
Dustin L. Howett (DHowett)
added a commit
that referenced
this pull request
Mar 8, 2024
Right now, the localization submission pipeline runs every night and sends our localizable resources over to Touchdown. Later, release builds pick up the localizations directly from Touchdown, move them into place, and consume them. This allowed us to avoid having localized content in the repository, but it came with too many downsides: - Users could not contribute additional localizations very easily - We use the same release pipeline and Touchdown configuration for every branch, so strings needed to either slightly match or _entirely match_ across an entire set of active release branches - Building from day to day can pull in different strings, making the product not reproduceable - Calling TDBuild during release builds requires network access from the build machine (so does restoring NuGet packages, but that's neither here nor there) - Local developers and users could not test out other languages This pull request moves all localization processing into the nightly build phase and introduces support for checking loc in and submitting a pull request. The pull request will not be created anew if one already exists which has not been merged. Anything we needed to do on release is now done overnight. This includes moving loc files into the right places and merging the Cascadia resources with the Context Menu resources (so that we can work around a relatively lower amount of translations being chosen for the app versus the context menu; see #12491 for more info.) There are some smaller downsides to this approach and its implementation: - The first commit is going to be huge - Right now, it only manages a single branch and uses a force push; if a PR is not reviewed timely, it will be force-pushed and you cannot see the day-to-day changes in the strings. Hopefully there won't be any. I've taken great care to ensure that repeated runs of this new pipeline will not result in unnecessary whitespace changes. This required changing how we merge ContextMenu.resw into CascadiaPackage to always use the .NET XmlWriter with specific flags. NOTE that this does not allow users to _contribute_ translation fixes for the 10 languages which we are importing. We will still need to pull changes out of those files and submit them as bugs to the localization team separately, and hope they come back around in another nightly build. However, there is no reason users cannot contribute _non-Touchdown_ languages. (cherry picked from commit ab4b140) Service-Card-Id: 92019665 Service-Version: 1.20
Dustin L. Howett (DHowett)
added a commit
that referenced
this pull request
Mar 8, 2024
Right now, the localization submission pipeline runs every night and sends our localizable resources over to Touchdown. Later, release builds pick up the localizations directly from Touchdown, move them into place, and consume them. This allowed us to avoid having localized content in the repository, but it came with too many downsides: - Users could not contribute additional localizations very easily - We use the same release pipeline and Touchdown configuration for every branch, so strings needed to either slightly match or _entirely match_ across an entire set of active release branches - Building from day to day can pull in different strings, making the product not reproduceable - Calling TDBuild during release builds requires network access from the build machine (so does restoring NuGet packages, but that's neither here nor there) - Local developers and users could not test out other languages This pull request moves all localization processing into the nightly build phase and introduces support for checking loc in and submitting a pull request. The pull request will not be created anew if one already exists which has not been merged. Anything we needed to do on release is now done overnight. This includes moving loc files into the right places and merging the Cascadia resources with the Context Menu resources (so that we can work around a relatively lower amount of translations being chosen for the app versus the context menu; see #12491 for more info.) There are some smaller downsides to this approach and its implementation: - The first commit is going to be huge - Right now, it only manages a single branch and uses a force push; if a PR is not reviewed timely, it will be force-pushed and you cannot see the day-to-day changes in the strings. Hopefully there won't be any. I've taken great care to ensure that repeated runs of this new pipeline will not result in unnecessary whitespace changes. This required changing how we merge ContextMenu.resw into CascadiaPackage to always use the .NET XmlWriter with specific flags. NOTE that this does not allow users to _contribute_ translation fixes for the 10 languages which we are importing. We will still need to pull changes out of those files and submit them as bugs to the localization team separately, and hope they come back around in another nightly build. However, there is no reason users cannot contribute _non-Touchdown_ languages. (cherry picked from commit ab4b140) Service-Card-Id: 92019664 Service-Version: 1.19
This pull request was closed.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
We chose to use the "ContextMenu" resource compartment when we
changed the package name to Terminal in #12264 because it was more
broadly localized than the rest of the application.
It appears as though some platform features have trouble with the
"more qualified" resource paths that #12264 required.
To fix this, we will:
resource root
root.
Regressed in #12264
Closes #12384
Closes #12406 (tracked in microsoft/PowerToys#16118)