Copy localized strings from ContextMenu into the resource root #12491
Conversation
This file contains 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
DHowett
added
zPreview-Service-Queued-1.13
ghost
added
Area-User Interface
|
|
DHowett
requested review from
miniksa and
zadjii-msft
and removed request for
miniksa
zadjii-msft
approved these changes
Feb 15, 2022
lhecker
approved these changes
Feb 15, 2022
Eh. Straightforward is better than clever here :) |
DHowett
added
the
AutoMerge
|
Hello @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
merged commit 
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)
DHowett
removed
the
zStable-Service-Queued-1.12
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)
DHowett
removed
the
zPreview-Service-Queued-1.13
|
🎉 Handy links: |
ghost
mentioned this pull request
|
🎉 Handy links: |
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.
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
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
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.
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)