Proposal: localize with x:Uid

[JerryNixon]

With UWP-XAML, Microsoft introduced the x:Uid directive as a mechanism to easily and comprehensively localize a XAML application. It automatically used the PRI subsystem to associate controls and their properties to localized values in locale-specific resource files. Since localization is important, and since the x:Uid approach is so simple and complete, I recommend we consider x:Uid to be part of the XAML Standard for the same of a unified approach for all XAML apps to localize their interfaces.

In addition: I would recommend we change the UWP implementation to allow for code-behind to be able to read x:Uid values, even if it does not make sense for code-behind to write to those properties. Sometimes it makes most sense to create custom localization solutions for certain parts of an interface and reading the value of the x:Uid directive can make that process easier.

Provides a unique identifier for markup elements. For Universal Windows Platform (UWP) XAML, this unique identifier is used by XAML localization processes and tools, such as using resources from a .resw resource file.

Use x:Uid to identify an object element in your XAML. Typically this object element is an instance of a control class or other element that is displayed in a UI. The relationship between the string you use in x:Uid and the strings you use in a resources file is that the resource file strings are the x:Uid followed by a dot (.) and then by the name of a specific property of the element that's being localized.

x:Uid is discrete from x:Name both because of the stated XAML localization scenario, and so that identifiers that are used for localization have no dependencies on the programming model implications of x:Name. Also, x:Name is governed by the XAML namescope concept, whereas uniqueness for x:Uid is controlled by the package resource index (PRI) system.

https://docs.microsoft.com/en-us/windows/uwp/xaml-platform/x-uid-directive

<Button x:Uid="GoButton" Content="Go"/>

[mandalorianbob]

I agree on x:Uid being part of XAML Standard. Also if there was some way to make x:Uid data driven, or to improve data-driven localization, it would be super helpful.

The use case is where you've got data coming from a service. If you're using x:Uid, you have to do a lot of jumps to keep it in XAML, or you just have to give up using x:Uid.

[birbilis]

Could allow to define different provider and provide a default one that uses the PRI.

Wouldn't mind having fallbacks providers too, but guess one could implement their own fallback manager as a provider that uses a priority list of other providers (say top one getting strings from the network, other one getting from cache, last one falling back to local values and caching them etc.)

[mfe-]

In addition: I would recommend we change the UWP implementation to allow for code-behind to be able to read x:Uid values,

Indeed! All XAML declarations must be read- and writeable from Codebehind. But I guess, XAML Standard isn't responsible for such things. The implementation of the XAML Engine needs to make this possible.

[birbilis]

Implementation should be based on some specification, not ad-hoc

[mfe-]

Also I would like to suggest an enhancement to the current x:uid UWP implementation for the XAML Standard.

Make x:uid set able directly to Dependency Properties

Example:

<TextBlock Text={x:Uid=/MyLocalizationresw/Resources/Abort.Content}" /> Example 2:

<TextBlock x:Uid="/MyLocalizationresw/Resources/TextStyle" Text={x:Uid=/MyLocalizationresw/Resources/Abort.Content}" /> Example 3:

`

` Note: I will format the code later. Atm. bad internet connection.

[lostmsu]

+1 to mfe-'s suggestion. Currently, I have a problem whenever I need to share string between a text block and a button, as implicit property binding forces to nest a TextBlock in Content property to avoid string duplication. E.g. ButtonUID.Content == TextBlockUID.Text