search

dotnet / aspire

Tools, templates, and packages to accelerate building observable, production-ready apps
https://learn.microsoft.com/dotnet/aspire
MIT License
3.83k stars 458 forks source link

Add more supported UI cultures for Aspire Dashboard #4884

Closed martincostello closed 3 months ago

martincostello commented 3 months ago

Is there an existing issue for this?

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

After I opened #4882 it occurred to me that there are probably more cultures where the preferred formatting for dates is different to the neutral culture, as is the case with en and en-GB.

While supporting every case is probably overkill, there might be more values that are worth adding to the supported languages for the dashboard to respect the formatting defaults of more users of the Aspire dashboard in locations outside of the US, France, Spain etc.

Using the console application source below, on Windows 11 Version 22H2 (OS build 22621.3880) with in the UK with en-GB configured, I get the following list of cultures whose formatting for DateTime.ToString() differs from their parent culture (e.g. comparing en against en-GB):

en-AE: 13/07/2024 1:13:01 PM
en-AG: 13/07/2024 1:13:01 pm
en-AI: 13/07/2024 13:13:01
en-AT: 13/07/2024 13:13:01
en-AU: 13/7/2024 1:13:01 pm
en-BB: 13/07/2024 1:13:01 pm
en-BE: 13/07/2024 13:13:01
en-BI: 7/13/2024 13:13:01
en-BM: 13/07/2024 1:13:01 pm
en-BS: 13/07/2024 1:13:01 pm
en-BW: 13/07/2024 13:13:01
en-BZ: 13/07/2024 13:13:01
en-CA: 2024-07-13 1:13:01 p.m.
en-CC: 13/07/2024 13:13:01
en-CH: 13/07/2024 13:13:01
en-CK: 13/07/2024 13:13:01
en-CM: 13/07/2024 13:13:01
en-CX: 13/07/2024 13:13:01
en-CY: 13/07/2024 1:13:01 pm
en-DE: 13/07/2024 13:13:01
en-DK: 13/07/2024 13.13.01
en-DM: 13/07/2024 1:13:01 pm
en-ER: 13/07/2024 1:13:01 pm
en-FI: 13/07/2024 13.13.01
en-FJ: 13/07/2024 1:13:01 pm
en-FK: 13/07/2024 13:13:01
en-FM: 13/07/2024 1:13:01 pm
en-GB: 13/07/2024 13:13:01
en-GD: 13/07/2024 1:13:01 pm
en-GG: 13/07/2024 13:13:01
en-GH: 13/07/2024 1:13:01 pm
en-GI: 13/07/2024 13:13:01
en-GM: 13/07/2024 1:13:01 pm
en-GY: 13/07/2024 1:13:01 pm
en-HK: 13/7/2024 1:13:01 pm
en-ID: 13/07/2024 13:13:01
en-IE: 13/07/2024 13:13:01
en-IL: 13/07/2024 13:13:01
en-IM: 13/07/2024 13:13:01
en-IN: 13/07/2024 1:13:01 pm
en-IO: 13/07/2024 13:13:01
en-JE: 13/07/2024 13:13:01
en-JM: 13/07/2024 1:13:01 pm
en-KE: 13/07/2024 13:13:01
en-KI: 13/07/2024 1:13:01 pm
en-KN: 13/07/2024 1:13:01 pm
en-KY: 13/07/2024 1:13:01 pm
en-LC: 13/07/2024 1:13:01 pm
en-LR: 13/07/2024 1:13:01 pm
en-LS: 13/07/2024 1:13:01 pm
en-MG: 13/07/2024 13:13:01
en-MO: 13/07/2024 1:13:01 pm
en-MS: 13/07/2024 13:13:01
en-MT: 13/07/2024 13:13:01
en-MU: 13/07/2024 13:13:01
en-MW: 13/07/2024 1:13:01 pm
en-MY: 13/07/2024 1:13:01 pm
en-NA: 13/07/2024 1:13:01 pm
en-NF: 13/07/2024 13:13:01
en-NG: 13/07/2024 13:13:01
en-NL: 13/07/2024 13:13:01
en-NR: 13/07/2024 13:13:01
en-NU: 13/07/2024 13:13:01
en-NZ: 13/07/2024 1:13:01 pm
en-PG: 13/07/2024 1:13:01 pm
en-PH: 13/07/2024 1:13:01 pm
en-PK: 13/07/2024 1:13:01 pm
en-PN: 13/07/2024 13:13:01
en-PW: 13/07/2024 1:13:01 pm
en-RW: 13/07/2024 13:13:01
en-SB: 13/07/2024 1:13:01 pm
en-SC: 13/07/2024 13:13:01
en-SD: 13/07/2024 1:13:01 pm
en-SE: 2024-07-13 13:13:01
en-SG: 13/7/2024 1:13:01 pm
en-SH: 13/07/2024 13:13:01
en-SI: 13/07/2024 13:13:01
en-SL: 13/07/2024 1:13:01 pm
en-SS: 13/07/2024 1:13:01 pm
en-SX: 13/07/2024 13:13:01
en-SZ: 13/07/2024 1:13:01 pm
en-TC: 13/07/2024 1:13:01 pm
en-TK: 13/07/2024 13:13:01
en-TO: 13/07/2024 1:13:01 pm
en-TT: 13/07/2024 1:13:01 pm
en-TV: 13/07/2024 13:13:01
en-TZ: 13/07/2024 13:13:01
en-UG: 13/07/2024 13:13:01
en-VC: 13/07/2024 1:13:01 pm
en-VG: 13/07/2024 1:13:01 pm
en-VU: 13/07/2024 1:13:01 pm
en-WS: 13/07/2024 1:13:01 pm
en-ZA: 2024/07/13 13:13:01
en-ZM: 13/07/2024 1:13:01 pm
en-ZW: 13/7/2024 13:13:01

es-CL: 13-07-2024 13:13:01
es-CO: 13/07/2024 1:13:01 p. m.
es-DO: 13/7/2024 1:13:01 p. m.
es-GT: 13/07/2024 13:13:01
es-MX: 13/07/2024 13:13:01
es-PA: 07/13/2024 1:13:01 p. m.
es-PE: 13/07/2024 13:13:01
es-PH: 13/7/2024 1:13:01 p. m.
es-PR: 07/13/2024 1:13:01 p. m.
es-US: 13/7/2024 1:13:01 p. m.
es-VE: 13/7/2024 1:13:01 p. m.

fr-CA: 2024-07-13 13 h 13 min 01 s
fr-CH: 13.07.2024 13:13:01
fr-DJ: 13/07/2024 1:13:01 PM
fr-DZ: 13/07/2024 1:13:01 PM
fr-MR: 13/07/2024 1:13:01 PM
fr-SY: 13/07/2024 1:13:01 PM
fr-TD: 13/07/2024 1:13:01 PM
fr-TN: 13/07/2024 1:13:01 PM
fr-VU: 13/07/2024 1:13:01 PM

it-CH: 13.07.2024 13:13:01

tr-CY: 13.07.2024 1:13:01 ÖS
```csharp using System.Globalization; // From https://github.com/dotnet/aspire/blob/a5b1448577622557233b9b26f99f84f737bcac84/src/Aspire.Dashboard/DashboardWebApplication.cs#L190 CultureInfo[] parentCultures = [ CultureInfo.GetCultureInfo("en"), CultureInfo.GetCultureInfo("cs"), CultureInfo.GetCultureInfo("de"), CultureInfo.GetCultureInfo("es"), CultureInfo.GetCultureInfo("fr"), CultureInfo.GetCultureInfo("it"), CultureInfo.GetCultureInfo("ja"), CultureInfo.GetCultureInfo("ko"), CultureInfo.GetCultureInfo("pl"), CultureInfo.GetCultureInfo("ru"), CultureInfo.GetCultureInfo("tr"), ]; var now = DateTime.UtcNow; var specificCultures = CultureInfo.GetCultures(CultureTypes.SpecificCultures); foreach (var parent in parentCultures) { var parentFormat = now.ToString(parent); var children = specificCultures .Where(c => c.Parent.Name == parent.Name) .Where(c => c.Name.Length == 5) .Select(c => new { c.Name, Culture = c, Value = now.ToString(c) }) .Where(c => c.Value != parentFormat) .ToList(); if (children.Count == 0) { continue; } foreach (var child in children) { Console.WriteLine($"{child.Name,5}: {child.Value}"); } Console.WriteLine(); } ```

Describe the solution you'd like

Additional cultures/languages for "popular" countries where developers may be using .NET Aspire are added to the supported languages for the Aspire dashboard to allow for their cultural preferences to be used in formatting operations.

Possible values to add from the long-list include:

Additional context

No response

danmoseley commented 3 months ago

There are pieces of this story I don't understand so need to educate myself --

samsp-msft commented 3 months ago

There are pieces of this story I don't understand so need to educate myself --

  • can we add cultures purely for string/number formatting (avoiding the significant cost of localizing more strings) and if so what if any is the cost - doesn't it simply pull from the OS locale database - indeed why would we not simply support any culture the OS has support for, why do we need to list them?

Yes. This is the difference between globalization and localization. Globalization is about how you represent numbers, dates etc where there are regional differences between how they are formatted. The .NET runtime should already have support for a large number of these, AFAIK we just need to enable it in blazor, which will take the locale preferences from the browser headers and then set the context for the page.

https://learn.microsoft.com/en-us/aspnet/core/blazor/globalization-localization?view=aspnetcore-8.0

  • @mairaw @danzhu54 on the dotnet web site which I happened to compare, I see (LocaleDateConfiguration.cs) that you have hard-coded date formats for many cultures. Just curious why that isn't pulled from the OS locale database -- perhaps it's deployed in locale invariant mode somehow? I thought perhaps that relates to my question above.
danzhu54 commented 3 months ago

There are pieces of this story I don't understand so need to educate myself --

  • can we add cultures purely for string/number formatting (avoiding the significant cost of localizing more strings) and if so what if any is the cost - doesn't it simply pull from the OS locale database - indeed why would we not simply support any culture the OS has support for, why do we need to list them?
  • @mairaw @danzhu54 on the dotnet web site which I happened to compare, I see (LocaleDateConfiguration.cs) that you have hard-coded date formats for many cultures. Just curious why that isn't pulled from the OS locale database -- perhaps it's deployed in locale invariant mode somehow? I thought perhaps that relates to my question above.

@danmoseley We created this custom hardcoded list of date configurations because during the time we implemented localization there wasn't a predefined date format that matched what we wanted to display. Perhaps there is one now but we haven't had the bandwidth to revist this.

adamint commented 3 months ago

There are pieces of this story I don't understand so need to educate myself --

  • can we add cultures purely for string/number formatting (avoiding the significant cost of localizing more strings) and if so what if any is the cost - doesn't it simply pull from the OS locale database - indeed why would we not simply support any culture the OS has support for, why do we need to list them?

Yes. This is the difference between globalization and localization. Globalization is about how you represent numbers, dates etc where there are regional differences between how they are formatted. The .NET runtime should already have support for a large number of these, AFAIK we just need to enable it in blazor, which will take the locale preferences from the browser headers and then set the context for the page.

https://learn.microsoft.com/en-us/aspnet/core/blazor/globalization-localization?view=aspnetcore-8.0

  • @mairaw @danzhu54 on the dotnet web site which I happened to compare, I see (LocaleDateConfiguration.cs) that you have hard-coded date formats for many cultures. Just curious why that isn't pulled from the OS locale database -- perhaps it's deployed in locale invariant mode somehow? I thought perhaps that relates to my question above.

Should we just do so then @samsp-msft? Enable support for all cultures beginning with the following (based on our localizations):

martincostello commented 3 months ago

This is done now with #5143, right?