Skip to content
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

[MRTCore] Add Microsoft.Windows.Globalization.ApplicationLanguages class #4181

Conversation

stefansjfw
Copy link
Contributor

@stefansjfw stefansjfw commented Feb 9, 2024

Changing the application language using PrimaryLanguageOverride property from Windows.Globalization.ApplicationLanguages namespace is not supported for WindowsAppSDK unpackaged apps, only for packaged. To support language change for un-packaged applications Microsoft.Windows.Globalization.ApplicationLanguages.ApplicationLanguages type is introduced in MRTCore. Microsoft.Windows.Globalization.ApplicationLanguages.PrimaryLanguageOverride property is supported both for packaged and un-packaged WindowsAppSDK apps.

Sample app used to verify the change: https://github.com/stefansjfw/testwasdk/blob/master/testlocalwinappsdk/App.xaml.cs#L36

A microsoft employee must use /azp run to validate using the pipelines below.

WARNING:
Comments made by azure-pipelines bot maybe inaccurate.
Please see pipeline link to verify that the build is being ran.

For status checks on the main branch, please use TransportPackage-Foundation-PR
(https://microsoft.visualstudio.com/ProjectReunion/_build?definitionId=81063&_a=summary)
and run the build against your PR branch with the default parameters.

@stefansjfw
Copy link
Contributor Author

/azp run

Copy link

Commenter does not have sufficient privileges for PR 4181 in repo microsoft/WindowsAppSDK

@crutkas
Copy link
Member

crutkas commented Feb 10, 2024

while doubtful /azp run

@crutkas
Copy link
Member

crutkas commented Feb 10, 2024

/azp run

Copy link

Commenter does not have sufficient privileges for PR 4181 in repo microsoft/WindowsAppSDK

@crutkas
Copy link
Member

crutkas commented Apr 23, 2024

This is needed for PowerToys to fully enable language override

static hstring PrimaryLanguageOverride();

private:
static hstring m_language;

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What happens with multiple threads?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

wil::srwlock could be used to protect access to this variable.

Copy link

@jeffstall jeffstall left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've added comments. Please address and update.

@stefansjfw stefansjfw force-pushed the user/stefansjfw/add_primary_language_override branch from eafa77e to 410c575 Compare June 6, 2024 13:13
Thread safe PrimaryLanguageOverride for un-packaged
Use W.G.PrimaryLanguageOverride for packaged
@stefansjfw stefansjfw changed the title [MRTCore] Add global PrimaryLanguageOverride switch [MRTCore] Add Microsoft.Windows.ApplicationModel.ResourcesApplicationLanguages class Jun 19, 2024
@@ -97,6 +97,10 @@ void ResourceContext::Apply()
winrt::check_hresult(MrmSetQualifier(m_resourceContext, eachValue.Key().c_str(), eachValue.Value().c_str()));
}
}
if (!ApplicationLanguages::PrimaryLanguageOverride().empty())
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

PrimaryLanguageOverride

explicit language context should trump PrimaryLanguageOverride

Copy link
Contributor Author

@stefansjfw stefansjfw Jun 26, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With W.G.PrimaryLanguageOverride set, newly created ResourceContext takes PrimaryLanguageOverride into account, i.e. does not override language QualifierValue to default language.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

e.g. if default language is "en-US", PrimaryLanguageOverride is "de-DE", and ResourceContext["Lanauge"]="fr-FR", what's the language that will take effect? I'd think "fr-FR"

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

according to this logic, no, PrimaryLanguageOverride should take precedence over ResourceContext["Language"]. GetLangugageContext returns Windows::Globalization::ApplicationLanguages::Languages() which is affected if W.G.PrimaryLanguageOverride is set. This behavior remains the same with this change

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think in that logic ResourceContext["Language"] still takes precedence. It would be strange to the caller that an explicit request is not honored

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Got it now. You're right. Fixed by latest change. Now explicit set of context Language is not overridden by PrimaryLanguageOverride.

I tested with this WinAppSDK sample. Default language is PrimaryLanguageOverride - de-DE, but fetching resources with m_overrideResourceContext passed is fetching it-IT resources:

image

Check if valid language tag is passed to PrimaryLanguageOverride
@stefansjfw stefansjfw changed the title [MRTCore] Add Microsoft.Windows.ApplicationModel.ResourcesApplicationLanguages class [MRTCore] Add Microsoft.Windows.Globalization.ApplicationLanguages class Jun 26, 2024
@stefansjfw
Copy link
Contributor Author

note: changing namespace to Microsoft.Windows.Globalization.ApplicationLanguages is in progress (as decided during API review)

@stefansjfw
Copy link
Contributor Author

note: changing namespace to Microsoft.Windows.Globalization.ApplicationLanguages is in progress (as decided during API review)

change pushed


THROW_HR_IF_MSG(E_INVALIDARG, !isValidLanguageTag, "The parameter is incorrect");

static wil::srwlock lock;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You have to use the same lock for reading and writing. Otherwise the setter could take an exclusive lock, but another thread could still read the data.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤦 fixed

@stefansjfw stefansjfw requested a review from kmahone June 27, 2024 17:54
@@ -86,3 +86,31 @@ HRESULT GetDefaultPriFile(winrt::hstring& filePath)
bool isPackaged = (hr != HRESULT_FROM_WIN32(APPMODEL_ERROR_NO_PACKAGE));
return GetDefaultPriFileForCurentModule(isPackaged, filePath);
}

bool IsWellFormedLanguageTag(const wchar_t* languageTag)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done. I don't have this header, so I reused the logic to load the DLL manually as in platform.h/.cpp. Tested. Works as expected.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the header should be in SDK. The LoadLibrary code was written before it's added into SDK.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

according to the docs it should be there since Windows 10 Build 17763, but I don't have it on machine (OS version 10.0.22631 Build 22631), VS 22 installed with multiple SDK versions. I double-checked on another machine with the same software versions

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I double-checked again, the header is present in SDK v10.0.20348.0 (and later), even though docs says it should be there before

Copy link
Contributor Author

@stefansjfw stefansjfw Jun 28, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is bumping WindowsTargetPlatformVersion to 10.0.20348.0 for this specific project ok to do ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I pushed the change (including WindowsTargetPlatformVersion bump). I'll revert if it's not ok

@stefansjfw stefansjfw force-pushed the user/stefansjfw/add_primary_language_override branch from 6f37f5c to 2d1c892 Compare June 28, 2024 14:31
@kmahone
Copy link
Member

kmahone commented Jun 28, 2024

/azp run

Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@kmahone
Copy link
Member

kmahone commented Jun 28, 2024

This has been merged as #4523

@kmahone kmahone closed this Jun 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants