-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Application Developer Localization Override Fix #3460
Application Developer Localization Override Fix #3460
Conversation
TODO: - [ ] Wait on 3437 to finish resource name refactor - [ ] Finish updating GetLocalized calls to use simpler syntax - [ ] Ensure Toolbar Resource Keys are Prefixed with proper "WindowsCommunityToolkit_" prefix like all others - [ ] Optimize? - [ ] Write more test cases?
Thanks michael-hawker for opening a Pull Request! The reviewers will test the PR and highlight if there is any conflict or changes required. If the PR is approved we will proceed to merge the pull request 🙌 |
May also want to investigate adding tests here for x:Uid support within controls...? |
=> ResourceLoader.GetForViewIndependentUse(resourcePath).GetString(resourceKey); | ||
{ | ||
// Try and retrieve resource at app level first. | ||
var result = IndependentLoader.GetString(resourceKey); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hummmmm, have you tried this code path on Xaml Islands? We might need to use the other overload for GetLocalized, that accepts a UIContext, and force the use of this parameter, but I'm not 100% sure. Lets test it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@azchohfi I can just try this out over here, eh?
I'll just add a test that doesn't provide the UIContext? I'll try copying the three tests I have over there...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, create a test, just in case, and test it out on the Xaml Island test project, as the Xaml Islands tests are not automated into the CI.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@azchohfi I tested this out and our API is working fine. However, the test itself was having trouble with the ApplicationLanguages.ManifestLanguages.ToArray()
API as it only returned 1 result instead of 2 like in the default UWP cases... Any ideas? FYI @marb2000
I'll check-in the updates I do have with that line commented out for now.
I think this should be tracked in a different issue. |
The FR test failed. |
Hmm, it worked locally, may be a timing/behavior thing...? I'll try dispatching. |
Seems good to me. |
Also fixed a missed rename from a Debug/Release #ifdef
UnitTests/UnitTests.XamlIslands.UWPApp/FakeTestClasses/Assert.cs
Outdated
Show resolved
Hide resolved
I'll clean-up this PR a tiny bit now that the Markdown one is merged, I'll try and do that tomorrow morning first thing. |
@vgromfeld @azchohfi I've updated the bit of clean-up I wanted to do as part of this. I'm realizing we don't have a good case where we're using x:Uid in a control (we should probably be using this more than we are?), so I don't know if there's a good spot to create a unit test for that scenario yet. @vgromfeld for the x:Uid you added, were you able to change the property in your app resources? As that may be a shortcoming in general too, this solution only fixes the FYI @RosarioPulella |
@michael-hawker I was able to change the <data name="WindowsCommunityToolkit_InAppNotification_LandmarkProperty.Value" xml:space="preserve">
<value>Youpikai</value>
</data> This has to be done for all the application's languages.
And the runtime is throwing 😥:
Other than this "constraint", the |
Thanks @vgromfeld, that's perfect (good to know about the current 'constraint', but I think in this scenario it makes sense). I think we can check-in this fix, note: I renamed the resources to be consistent and a bit shorter with the |
Fixes #3349
This fixes the
GetLocalized
method in order to first look in an application's resource file for the request key before falling back on the specified resource path. This will allow easier overriding of locales using this method.Added test cases to check this, as well as cleaning up syntax and keys in the toolkit.
PR Type
What kind of change does this PR introduce?
What is the current behavior?
A developer can't specify other languages or overrides to any externalized resources within the Toolkit.
What is the new behavior?
A developer can now override a key in any langauge.
PR Checklist
Please check if your PR fulfills the following requirements:
Other information
Left TODO:
GetLocalized
for code-behind cases.