-
Notifications
You must be signed in to change notification settings - Fork 10.5k
Description
Is there an existing issue for this?
- I have searched the existing issues
Is your feature request related to a problem? Please describe the problem.
When using globalization, localization, and time zone features in Blazor WebAssembly, the application is forced to download all cultures, resulting in a massive increase in download size. This significantly impacts application performance and user experience, especially for users on slower connections.
For applications that only need to support a limited set of cultures (e.g., en-US, ckb, zh-CN), downloading culture data for 500+ cultures is wasteful and unnecessary.
Describe the solution you'd like
Provide a simple configuration option to specify which cultures should be included in the Blazor WASM build. This could be similar to how IL trimming works.
Proposed solution:
Add a configuration option in the .csproj file to specify allowed cultures:
<PropertyGroup>
<InvariantGlobalization>false</InvariantGlobalization>
<BlazorWebAssemblyIncludeCultures>en-US;ckb;zh-CN</BlazorWebAssemblyIncludeCultures>
</PropertyGroup>
Or in Program.cs / app configuration:
builder.Services.Configure<WebAssemblyHostBuilder>(options =>
{
options.IncludeCultures("en-US", "ckb", "zh-CN");
});
- Using InvariantGlobalization - This removes all culture support, which is too restrictive when you need even one specific culture.
- Manual IL trimming configuration - Complex and not officially documented for culture-specific trimming.
- Custom build scripts - Brittle and difficult to maintain across .NET updates.
Additional context
Impact on download size:
Full ICU data can add 10-20+ MB to the download size
For apps requiring only 2-3 cultures, this is an unacceptable overhead
Mobile and bandwidth-constrained users are particularly affected
Comparison with other frameworks:
Many other frameworks (including some JS frameworks) allow cherry-picking i18n data
This is a common pattern in modern web development
Current workaround complexity:
The lack of built-in support forces developers to either:
Accept the massive download penalty
Disable globalization entirely (losing needed functionality)
Implement complex custom build processes
This feature would significantly improve Blazor WASM's competitiveness for international applications while maintaining small bundle sizes.