[Proposal] LocalizationResourceManager

[TheCodeTraveler]

LocalizationResourceManager

• Proposed
• Prototype: Not Started
• Implementation: Not Started
  • iOS Support
  • Android Support
  • macOS Support
  • Windows Support
• Unit Tests: Not Started
• Sample: Not Started
• Documentation: Not Started

Summary

The LocalizationResourceManager class is a helper class that enables users to respond to culture changes at runtime.

Detailed Design

LocalizationResourceManager.shared.cs

public class LocalizationResourceManager : INotifyPropertyChanged
{
  public static LocalizationResourceManager Current;

  private LocalizationResourceManager();

  public void Init(ResourceManager resource);
  public void Init(ResourceManager resource, CultureInfo initialCulture);
  public object GetValue(string resourceKey);

  public object this[string resourceKey] => GetValue(resourceKey);

  public CultureInfo CurrentCulture { get; set; }
}

Usage Syntax

XAML Usage

N/A

C# Usage

LocalizationResourceManager.Current.PropertyChanged += (_, _) => AppResources.Culture = LocalizationResourceManager.Current.CurrentCulture;
LocalizationResourceManager.Current.Init(AppResources.ResourceManager);

LocalizationResourceManager.Current.CurrentCulture = newCulture;

[TheCodeTraveler]

Closing for the following reasons:

• Duplication of RESX
• Required use of ObservableObject
  • ObservableObject is not implemented in CommunityToolkit.Maui
  • ObservableObject is implemented in CommunityToolkit.MVVM

[TheCodeTraveler]

Reopening based on our discussion during the June Standup: https://www.youtube.com/watch?v=t3g_NrQfE8g

[VladislavAntonyuk]

Why I suggest to keep it in MCT?

1. It works great with TranslateExtension, which depends on MAUI. So if we decide to add TranslateExtension we will need to depend on Community Toolkit dotnet.
2. Based on the first point. Splitting Localization classes on different packages maybe not a great customer experience
3. Minor but it will be easier for XCT users migrate to MCT
4. As for me localization resources are mostly related to UI (like button text or user error messages - not logs), so keep it somewhere in Core library may not give a lot of benefit. User may store Resx files wherever he wants. LocalizationResourceManager only needs ResourceManager reference.

[bijington]

I agree that we should probably offer all or nothing rather than take on a dependency. I am trying to think on whether there could be a compromise but nothing is coming to mind

[VladislavAntonyuk]

It can work as a standalone feature but as I described in the article LocalizationResourceManager and TranslateExtension work better together: https://vladislavantonyuk.azurewebsites.net/articles/Localize-.NET-MAUI-application