SystemLanguage API

[maxkatz6]

Is your feature request related to a problem? Please describe.

While we are not aiming to ship a single standardized localization solution that fits everybody (at least just yet), we need to provide all the building blocks that might be necessary for the developers.

Next step from now is adding low-level platform API to read current system language used for apps.
PlatformSettings is typically a host for such members.

Following step would be current app language. This language can then be used by different components, third party controls, and built-in controls (like NumericUpDown).
.NET has existing CultureInfo.CurrentUICulture property, but it lacks any culture change notification mechanism.
We can follow API similar to theme variants, that allows app-wide languages.

Describe the solution you'd like

public interface IPlatformSettings
{
+     string SystemLanguage { get; }
+     event EventHandler SystemLanguageChanged;
}

public class Application
{
+     public static DirectProperty<string> ActualLanguageProperty;
+     public static StyledProperty<string?> RequestedLanguageProperty;
     
+     public string ActualLanguage { get; }
+     public string? RequestedLanguage { get; set; }
}

Describe alternatives you've considered

With these APIs, we are considering implementing an opinionated localization framework, as an optional package and not part of Avalonia Core.

Additional context

BCP-47 is expected to be used.

[miloush]

SystemLanguage is slightly confusing, it could refer to the system locale on Windows. Nowadays there is "display language" and then "list of preferred languages" (and then "input language"). Perhaps SystemDisplayLanguage would be less ambiguous?

How would the localization play together with resource loading using per-thread writeable CurrentUICulture?

it lacks any culture change notification mechanism

There is SystemEvents.UserPreferenceChanged event with UserPreferenceCategory.Locale.

[maxkatz6]

+1 for SystemDisplayLanguage.

SystemEvents is a WPF type. IPlatformSettings.SystemLanguageChanged would be an equivalent of that.

[maxkatz6]

How would the localization play together with resource loading using per-thread writeable CurrentUICulture?

We can set CurrentUICulture on the main UI thread, when Application.ActualLanguage is changed. But I am not sure if we need it. Without CurrentUICulture supporting change notifications, it's less than useful for localization purposes.

Application.ActualLanguage should be treated as a reactive property and used with controls for internalization and localization.
The same property can be used with localization solutions using markup extensions, or bindings.

[rabbitism]

similar #18665

[MrJul]

Why a string instead of CultureInfo for the language properties?

[TomEdwardsEnscape]

.NET has existing CultureInfo.CurrentUICulture property, but it lacks any culture change notification mechanism.

Changing display language at runtime is a huge undertaking. In any moderately complicated application, it's about much more than reassigning some Textblock properties. You will have almost certainly have handled data in the current language, possibly from the internet, and must flush all the places where such data is cached. Perhaps you even have to reset some connections to external resources.

Then there are non-textual changes like currencies, date formats, and measurement systems. This can easily necessitate a reload of even more data. If the new language has different text sizes (e.g. complicated Chinese characters) or is written in the inverse direction, huge chunks of your UI need to be chopped, changed, and flipped around.

And all of this for whose benefit? I've never heard of anyone wanting to make frequent changes to their display language. Restarting an application is a perfectly acceptable price for making this sort of change, because it's typically made only once, ever.

For all of these reasons, I would have no interest at all in using a system which permits the application's language to change after startup.

[rabbitism]

Why a string instead of CultureInfo for the language properties?

One potential reason is to avoid usage of CultureInfo when user have to enable InvariantGlobalization

[miloush]

One potential reason is to avoid usage of CultureInfo when user have to enable InvariantGlobalization

There is CultureInfo.InvariantCulture

[MrJul]

From the API review meeting:

There's a bit of confusion here. Do we want to expose that only as a "culture changed" mechanism like stated in the OP?

Where do we stop, there were concerns about this potentially becoming a huge feature with handling every possible platform, system language, synchronization with the thread culture, etc. What about components using this, what is the expected behavior when the app developer isn't in control anymore?

Do other platforms provide such a knob? Is that a good fit for the core library or should it be separate?

string VS CultureInfo: previous crashes in font language parsing in invariant globalization mode were mentioned so that's likely why a string is used here. But do we really want to have our own parsing here? It's very likely that people are going to change the Thread.CurrentUICulture anyway if they're using this API...

Nothing is decided for now, we don't have enough information!
This needs further discussion and research.

[miloush]

Note: anyone trying to do localization please do not use Thread.CurrentCulture which is used for number formatting, use Thread.CurrentUICulture for showing UI in different language.