Blazor Global/Loc UE pass

[guardrex]

Addresses #19286
Fixes #21619

Internal Review Topic

[guardrex]

@hishamco ... Do you want to put an 👁️ on this? I hate to do anything in this area without having your great advice. If ur too busy tho, no worries ... the PU will get in on this and carve 🔪😨 me up. 😄 I'll give you time to look before pinging them. Keep in mind as you look that I'm no loc expert .... like at all. I have little loc experience.

[hishamco]

Great job, I need to have a test link if there's to check the entire changes LIVE

[guardrex]

Thanks @hishamco ... that's COOL given my almost total lack of loc experience.

I'll get on your remarks in a few minutes. I'm about to open a PU issue for an inconsistency in globalization between WASM and Server that I don't understand. I'm pinging you on the issue ... you may immediately know why it's happening. Stand-by ... that issue will go up in just a minute or two.

UPDATE: PU issue opened at 👉 https://github.com/dotnet/aspnetcore/issues/33639

UPDATE: Feedback is covered thus far (I think 🤔) (next commits with the updates 👇 are in).

[guardrex]

Ok ... I'm learning a little loc. 📚👩‍🏫🏫

UPDATE: Peruvian Spanish does use the comma separator and dot decimal. However, there's still a problem here. Blazor Server is correct on the number format, but Blazor WASM is not correct (dot separator/comma decimal).

https://github.com/unicode-org/cldr/blob/829d6d3d911dbf032a118c3834737445292dc3e8/common/main/es_PE.xml

We'll hold the PR here a bit longer to see how things play out. We probably won't document a short-term bug that will be fixed, but we might call something out if there will be a long delay on it or if there's something else going wrong here ... something that I missed or failed to understand.

[guardrex]

@hishamco ... I slept on the situation with the inconsistency report that I made. Although I guessed wrong about Peruvian Spanish 🙈 ... that all of Spanish used one number format ... at least I was correct about the inconsistency WASM vs. Server.

Yes, I think we should wait a sec to hear how the PU plays it out: If it's a quick bug fix for WASM to correct the globalization of certain Spanish cultures, then we can go ahead. They'll probably patch it back to 3.x, too. If it's a long-term item for them to address, then I think a NOTE is warranted in the topic with a cross-link to a potential PU issue. I'll 👂 for what they decide to do and then react here.

Otherwise, I think the topic is ok thus far. I'm sure that the readers will come after me 🔪😨 for anything I may have messed up.

[guardrex]

@marin-bratanov ... This PR should help ... A LOT 😆 ... there's a lot more loc goodness going in on this PR. However, I think I have a delta from what you reported on #21619. I think u were saying that you need to set BlazorWebAssemblyLoadAllGlobalizationData to true for the framework (WASM apps) to react to an Accept-Language header, but that isn't what I found in testing for that most basic scenario (i.e., the app doesn't try to set the culture, offer a way to set it, or have any localization of resources). I might not have enough of an understanding on this, but when I just set up a Blazor WASM test app and make a request from Opera with Peruvian Spanish as the default (first) language, I get the right globalization without that project file setting. Here's what the test app does ... (btw- The number format for es-PE is probably a bug that they're going to work on shortly on another issue) ... anyway, the date format is correct ....

Project file for this app:

<Project Sdk="Microsoft.NET.Sdk.BlazorWebAssembly">

  <PropertyGroup>
    <TargetFramework>net5.0</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.AspNetCore.Components.WebAssembly" Version="5.0.6" />
    <PackageReference Include="Microsoft.AspNetCore.Components.WebAssembly.DevServer" Version="5.0.6" PrivateAssets="all" />
    <PackageReference Include="System.Net.Http.Json" Version="5.0.0" />
  </ItemGroup>

</Project>

For setting BlazorWebAssemblyLoadAllGlobalizationData to true, that only seems to apply for the other scenarios (or a combination of them) ...

• Statically setting the culture in the app.
• The user is offered the ability to set the culture manually (Microsoft.Extensions.Localization package use, etc.).
• Localization is in use (i.e., the .NET Resources System is in use).

If you think this isn't correct, let's discuss further with @hishamco. I can repro anything that you're not seeing when the user has merely set the Accept-Language header and take it from there. I'm very much a NOOB on loc because I never had an employer that would pay 💲💰 for it. Their philosophy was either 'this app is for the US market' or 'everyone should read English' 🤦. Sad, so sad. Anyway ... I'm learning loc here!!! 😄 lol

[guardrex]

@hishamco ... I'll go over this one more time and merge. I don't want to hold up the whole thing over the (apparent) WASM bug. Thanks again for your help.

Actually ...... 🤔 .... I could drop a NOTE in about the bug, but the topic is using Peruvian Spanish in examples. That breaks things in two ways:

• The bug prevents WASM from displaying the number format correctly.
• The point of choosing Peruvian Spanish was to highlight a different number format from US English. Given that Peru uses comma-separator/period-decimal notation, it's not the best choice.

I'm going to update the example to one of the Spanish-speaking countries that uses the opposite number format from US English.

UPDATE: I've settled on Chilean Spanish (es-CL) for this ... another country in addition to Peru that I'd ❤️ to visit. I'm making the updates now.

[marin-bratanov]

The cases I've tested have used the .net resource system, so it is likely that mine was a small subset of the bigger picture. I will try to take a peek at the live page in the next couple of weeks, but I am sure you've tested more extensively than I did.

[guardrex]

@marin-bratanov ... Yes, setting BlazorWebAssemblyLoadAllGlobalizationData to true is now called out for localization (.NET Resources System) in the live topic. That was one of the updates, so I think we're good if that's all you were calling out in your issue. Here's the latest section ...

https://docs.microsoft.com/aspnet/core/blazor/globalization-localization?view=aspnetcore-5.0&pivots=webassembly#localization

Earlier sections of the topic pertain to using the Accept-Language header value automatically for only globalization (numbers, dates, etc.). If that's all the dev is trying to do, then they don't need that setting. The setting kicks in for everything else: an app that sets a static culture, an app that offers users to set the culture and it's maintained by the app, ... and I was saying ... for localization (.NET Resources System).

If you need to leave additional feedback on the updates, open a new issue with the This page feedback button and form at the bottom of the topic. Thanks again for your earlier issue.

[marin-bratanov]

The article is great and explains much better when one needs the various things related to localization. I especially love the wasm/server toggle at the top. I was trying to say that your tests are much better and more inclusive than mine, and what I saw fits perfectly with what you said. I'm sorry for not being clear enough.