Add locale-aware GlobalFontFamily and enable dynamic FontFamily

[lindwurm]

Summary

Switched to changing the font family dynamically to use correct one.

before	after

Motivation

The language‑specific font priority isn't working in both the Media Flyout and the Taskbar Widget ("Up Next" isn't affected). As a result, characters aren't rendered using the intended fonts (In the following example, selected font is not suitable for displaying Japanese).

title おしえてアンドロメダ in "Up Next" is using Yu Gothic UI (Japanese font), but Taskbar Widget isn't.

For Japanese users, being forced into an inappropriate fallback font significantly degrades readability and user experience — much like replacing all English text with Comic Sans🙃

  // dictionary of font families for specific languages, priorities are switched around
  private static readonly Dictionary<string, string> _languageFontFamilies = new()
  {
      { "default", "Segoe UI Variable, Microsoft YaHei UI, Yu Gothic UI, Malgun Gothic" }, // default support for multiple languages
      //{ "zh-CN", "Segoe UI Variable, Microsoft YaHei UI, Yu Gothic UI, Malgun Gothic" }, // same as default
      { "zh-TW", "Segoe UI Variable, Microsoft JhengHei UI, Yu Gothic UI, Malgun Gothic" },
      { "ja", "Segoe UI Variable, Yu Gothic UI, Microsoft YaHei UI, Malgun Gothic" },
      { "ko", "Segoe UI Variable, Malgun Gothic, Microsoft YaHei UI, Yu Gothic UI" },
  };

The logic was in place (eg. #317 ), but it wasn’t actually taking effect in all relevant parts of the UI.

Type of Change

• Feature
• Bug fix
• Refactor (no functional changes)
• Style (formatting, naming)
• Other

What Changed

• Added locale-aware global font selection in LocalizationManager.cs
  • Applied dynamic GlobalFontFamily via Application.Current.Resources so UI updates at runtime
  • Kept existing localization loading logic while enabling dynamic font switching based on current culture
• Ensured TextBlock and Control styles in App.xaml use DynamicResource GlobalFontFamily for consistent font application
  • Excluded MicaWPF SymbolIcon from GlobalFontFamily so icon rendering is not broken

Additional Information

Checklist

• Code changes are manually tested and working.
• Formatting and naming are consistent with the project.
• Self-review of changes is done.

• AI tools were used (if yes, I reviewed and fully understand the changes myself).

[unchihugo]

Hi @lindwurm, thank you for looking into this, I wasn't aware that font rendering was spotty!

While I understand that this PR is still a draft, I'd like to add in some context:

1. Based on your screenshots, it looks like the text width helper function for calculating the text width for Next Up and the Taskbar media widget is still using the old font families.
2. Have you investigated why the viewmodel binding isn't properly working and we have to resort to setting global font family?

Thanks in advance!

[lindwurm]

1. Based on your screenshots, it looks like the text width helper function for calculating the text width for Next Up and the Taskbar media widget is still using the old font families.

Certainly this font has a narrow character width but I hadn't even considered about that.

2. Have you investigated why the viewmodel binding isn't properly working and we have to resort to setting global font family?

To be honest, there isn't enough research. That's also why I've left this PR as a draft (maybe I should have created an issue first).

Since the issue occurs only in certain components,

• It has been confirmed that there is no problem with the fallback order of _languageFontFamilies[“ja”]

• but this has not been applied to the affected areas (Media Flyout and the Taskbar Widget)

then I tried to implement that based on hypothesis like:

• There is no global FontFamily resource shared across the entire app, different font resolutions are occurring for each control.