Hi Andreas,

Thank you for sharing your insights and the attached project. I understand the complexity you're facing with the culture context when updating components from background threads. It's great to hear that your team is considering a change in the localization mechanism.

Here's a brief overview of what you can consider. Please note that these questions about the localization fall outside the scope of our official support services, because has no direct relation with the product. The responses provided are based on my understanding and assumptions and may not reflect complete accuracy.

• Culture Management - Since CultureInfo.CurrentCulture and CultureInfo.CurrentUICulture are AsyncLocal, they retains its values across asynchronous calls. To ensure the correct culture is used, you might need to explicitly set the culture at the beginning of each operation that requires it. This can be done by setting CultureInfo.CurrentCulture and CultureInfo.CurrentUICulture to the desired culture before calling InvokeAsync(StateHasChanged).

• Custom Implementation - If you have a custom solution that works well, as shown in your prototype, it might be worth integrating it into your existing system. This could involve wrapping your culture setting logic in a helper function or service that ensures the correct culture is set whenever necessary.

Additionally, I just want to point-out that this ticket is a public thread, so the whole community can benefit from it, if needed. Your cooperation is much appreciated.

Regards,
Tsvetomir
Progress Telerik

Hi Andreas,

Thank you for coming back with feedback.

I've discussed the pointed implementation in the FormatHelper with the team. As a result, I can briefly inform you that formatting numbers, dates, and times according to the user's cultural settings is essential for clarity, accuracy, and a positive user experience. It helps prevent misinterpretation (e.g., date or decimal confusion) and makes users feel more comfortable by presenting information in a familiar format. This practice is a widely accepted convention in internationalization and localization, supported by most modern development frameworks. We follow these conventions that are widely accepted as standard practice:

• Internationalization (I18N)
• Localization (l10n)
• Web content accessibility guidelines (WCAG) - emphasize the importance of making web content accessible to users with diverse needs, including those related to language and culture. While WCAG does not explicitly mandate cultural formatting of dates, numbers, or times, it underscores the necessity of ensuring content is understandable to a broad audience.

I hope the above provides you more clarity around the implementation around the FormatHelper. With that being said, I'm changing the status of the item as "Declined"

On the other hand, to update components from background threads is recommended to use InvokeAsync(StateHasChanged). You can gather, more information about that approach in this Blazor University article - https://blazor-university.com/components/multi-threaded-rendering/invokeasync/

Regards,
Tsvetomir
Progress Telerik

Hi Andreas,

After a recent evaluation of your request with the Blazor team. We have the following questions regarding your scenario:

• Why do you want to display a format that will be different from the actual culture?
• Why do you need to specific custom format only in the Grid?
• Why don't you use some of the standard format specifiers?

The current implementation of the FormatHelper is focused on complying with the culture of the user. Customizing such a behavior will lead to a discrepancy between the Grid component and the other date-related components in the application. If you have such an option, the user's culture will be ignored only in the Grid, which will lead to a difference with other dates in the application.

I hope the above information sheds some light on your scenario. I'm changing the status of the item to "Need More Info" and look forward to your reply.

Regards,
Tsvetomir
Progress Telerik