Let the host application supply TableView's strings - #456
Open
SolidRockProgrammer wants to merge 3 commits into
Open
SolidRockProgrammer wants to merge 3 commits into
SolidRockProgrammer wants to merge 3 commits into
Conversation
The automation peers returned English literals for their localized
control types ("table view", "column header", "row header", "cell")
and composed row names as "Row {n}", so a screen reader on a German,
Japanese or Chinese UI announced those in English while every other
TableView string already went through TableViewLocalizedStrings.
Move them to the .resw files in every shipped language, with
FormatRowNumber composing "Row {0}" through the current culture.
The tests swap each resource for a sentinel, so they fail on a peer
that returns a literal even under en-US.
The FormatRowNumber test proved the formatter reads RowNumber, but not that the three peers call it: restoring their English literals left every test green. Each new test realizes a row in a loaded TableView, swaps RowNumber for a sentinel and reads the peer's name.
TableViewLocalization.StringResolver lets an application answer any TableView string by its resource key - for a language the library does not ship, or for its own wording of the automation control types and row names. It is read on every access, so a language change at run time is followed. A null or empty answer, or a resolver that throws, keeps the library's own value; a malformed RowNumber format falls back to the library's. TableViewLocalization.Keys lists the keys without loading the resources.
This branch has not been deployed
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
2 participants
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.
Builds on #449 (its two commits are the base of this branch; only the last commit is new here).
Adds
TableViewLocalization.StringResolver, a publicFunc<string, string?>an application can set to answer any TableView string by its resource key (the names inWinUI.TableView.resw;TableViewLocalization.Keyslists them):Behaviour:
RowNumberthat is not a valid composite format falls back to the library's;Keysdoes not load the resource set (it would throw outside a running app).Each
TableViewLocalizedStringsproperty becomesget => Resolve(nameof(X), field); nothing else changes for an app that sets no resolver.Tested: shipped in Datgel Hub (via our fork) and verified there with unit tests and a UI Automation run. On this branch, the full suite on hosted Windows via
vstest.console+ the.appxrecipe(ci-build.yml's Run Tests step does not actually invoke vstest, see #449): 383/383, including nine newTableViewLocalizationTests. On our fork's branch, ignoring the resolver turned exactly the five tests that need the host's answer red.