What is new in Localization in ASP.NET Core 3.0

What is new in Localization in ASP.NET Core 3.0

Sep 20, 2019 0 Comments Posted in #Localization 

It has been a while since I wrote my latest blog post for ASP.NET Core community, because my left ankle was broken and did a surgery since then, the thing that let me stay on the bed for around half a year.

Last week I just start writing the first blog post about My Journey with Orchard Core.

Today I will continue again in ASP.NET Core blog posts, and I will start with my favorite Localization :), this will be a short and quick one that show off the new stuff in localization that shipped with ASP.NET Core 3.0.

This release has shipped few features, enhancements and one bug fix, which all of them are done by me, so if you like them I will be great, otherwise don't blame anyone except me :)

1- Add Content-Language header in localization middleware

When you're working with localization you will find yourself usually doing this

app.UseRequestLocalization("en", "ar", "fr"); 

This set the culture properly on the HttpContext, in a way that requesting in a language not supported fallbacks to the default culture and culture variants fallback to languages, etc.

The issue is you will need to manage the response header Content-Language yourself.

Now this has been added optionally to the RequestLocalizationMiddleware by toggling the property ApplyCurrentCultureToResponseHeaders which has been introduced to RequestLocalizationOptions.

app.UseRequestLocalization(new RequestLocalizationOptions
{
    ApplyCurrentCultureToResponseHeaders = true
});

2- Adding AddInitialRequestCultureProvider extension method

When you are working with localization with a custom RequestCultureProvider you will find yourself doing this all the time:

options.RequestCultureProviders.Insert(0, new CustomRequestCultureProvider(async context =>
{

}));

but not anymore, now you can simply use the AddInitialRequestCultureProvider extension to make your life easier

options.AddInitialRequestCultureProvider(new CustomRequestCultureProvider(async context =>
{

}));

It's a tiny feature but it's very useful.

3- Change unsupported culture log level

The issue was the localization middleware will log tons if not hundreds of logs if the requested culture is unsupported, image that you will receive 1 warning log per request which is noisy and trouble over the time.

For that we simply decide to change the LogLevel.Warning to LogLevel.Debug to reduce the amount of logs at least.

4- Fix localization issue after changing rootnamespace

After digging into the issue AspNetCore#10639, seems there was a bug in GetResourcePrefix() that causes the localization not working properly after changing rootnamespace, especially if you're working with class libraries.

Now I'm glad to say that the bug has been fixed and nothing block you to change the rootnamespace if you are using class libraries.

If you're interested you can checkout the following pull requests:

Last but not least I hope to write some docs for update 3.0 in Globalization and localization article, which is discussed here https://github.com/aspnet/AspNetCore.Docs/issues/14225.

Finally I encourage everyone who didn't heard or work with these new bits to have a try.

Happy Coding !!


Comments

Post a comment