microsoft / microsoft-ui-xaml

Windows UI Library: the latest Windows 10 native controls and Fluent styles for your applications
MIT License
6.27k stars 674 forks source link

Proposal: Simplify localization with x:Uid #1337

Open lukasf opened 4 years ago

lukasf commented 4 years ago

Proposal: Simplify localization with x:Uid

Summary

Localization with x:Uid could be simplified if all relevant controls would have a default content property for localized text.

Rationale

Often, the same command is available in an app through different ways. It might be placed in a MenuFlyout, in a Button, in a AppBarButton. I would like to use the same localization resource for it, otherwise I would have duplicate localization entries, creating work and confusion for translators. The problem is that all these controls have different properties for the actual text content:

Button --> Content MenuFlyoutItem --> Text AppBarButton --> Label

So for x:Uid="MyAction" I would need to define the following resources: MyAction.Content MyAction.Text MyAction.Label

All three resources would have same original and translated text for all languages! It is pretty annoying having to duplicate lots or resources, just becase a command has now been made available through a different control.

Now my idea:

All relevant controls could have a default property that will be used for localization, if no specific properties are set in the corresponding resources. So if I set x:Uid="MyAction" and only a string resource named "MyAction" exists (with no "." ending), then the Button would use this string as Content, the MenuFlyoutItem would use it as Text, the AppBarButton as Label, a TextBlock would use it as Text, some other controls might use it as Header.

An attribute (e.g. DefaultLocalizationPropertyAttribute) on each relevant XamlControl would be used to identify the default property that is used for localization.

This would save us a lot of effort, it would make resource names shorter and easier to read, and it would allow us to re-use the same resources in different places and different (adaptive) UI views, without duplications and extra effort in the traslation process.

Important Notes

This should not be a breaking change! So if I have a resource "MyAction" and at least one resource "MyAction." is also defined, then the default property mechanism will not be used. It is only used if there is only the "MyAction" resource alone.

ryandemopoulos commented 4 years ago

Hey @lukasf, thanks for filing this idea; it's very 1337. 🤣

I'm adding the needs-winui-3 label; our team is very busy on lifting UWP XAML into WinUI 3 and also starting to prepare for Ignite in November, so it might be a while before we can circle back and evaluate this more closely. The needs-winui-3 label indicates that it's something we can't do in WinUI 2 series (this would touch various elements in the framework itself that go beyond the controls in WinUI today).

Eventually when we start pulling up more WinUI 3 issues we can take another look at this. Sorry for the wait in advance.

lukasf commented 4 years ago

Yeah it's a 1337 one indeeed :D

Yes, getting WinUI 3.0 out has highest priority now, I agree with that approach.

mrlacey commented 4 years ago

I realize this is on hold for further evaluation but as x:Uid is supposed to be a "unique identifier", I don't think it should be used in this way as doing so would risk breaking functionality where the attribute needs to be unique. (TBH, I'm surprised that the compiler doesn't complain when these aren't unique--even within the same file.)

Instead, a new attribute would be a better solution to this issue. ResourceName strikes me as the most descriptive but if length is a concern an abbreviation such as Resource or ResName would be a suitable alternative.

lukasf commented 4 years ago

The documentation of x:Uid explicitly states that for UWP XAML, uniqueness is not required. So we wouldn't break any functionality there.

But I am open for adding a new attribute for simplified localization, if that makes more sense.

akash07k commented 2 years ago

Any update on this? this issue is driving me crazy

Jimex commented 1 year ago

I miss the convenient way that we can make it with WPF.

akash07k commented 1 year ago

@Jimex Same here