Aspnetcore: Custom Header for localization

[davidrevoledo]

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

I know the implementation of https://github.com/aspnet/AspNetCore/blob/c95ee2b051814b787b07f55ff224d03d550aafeb/src/Middleware/Localization/src/AcceptLanguageHeaderRequestCultureProvider.cs is great and using accept language is perfect but currently I'm migrating a legacy app who was built to use a custom header "lang" to use localization. I am moving forward the project from asp.net to asp.net core but It wasn't designed with many SOLID practices.

I want to change less componts I can because I don't know currently the impact of changing the header and where it is used in the code, currently fighting with a lot of static HttpContext calls 👎 .hahaha

Describe the solution you'd like

What about if we can add a property to that class to take the language from a custom header instead, if so I can use this implementation and keep the header until I know it is safe to change it.

If you think it does make sense I can apply the change and do the proper tests.

I'm thinking in something like CookieName in CookieRequestCultureProvider
```C#
app.UseRequestLocalization(new RequestLocalizationOptions
{
RequestCultureProviders = new List
{
new AcceptLanguageHeaderRequestCultureProvider
{
HeaderKey = "lang"
}
}
});

or  a new implementation of the provider something like

```C#
            app.UseRequestLocalization(new RequestLocalizationOptions
            {
                RequestCultureProviders = new List<IRequestCultureProvider>
                {
                    new AcceptHeaderRequestCultureProvider("lang")
                }
            });

Thanks.

[davidrevoledo]

If the idea in that case is use CustomRequestCultureProvider and do it manually please close the issue :)

[mkArtakMSFT]

Thanks for contacting us, @davidrevoledo.
We will consider a PR for this, if you're interested.

[davidrevoledo]

@mkArtakMSFT Sure thing, any branch to create it from ? Kindly.

[rynowak]

based on master would be good

[davidrevoledo]

@rynowak thanks Ryan ! :)

[ryanbrandenburg]

Hi @davidrevoledo, we considered this a little more and came to the conclusion that this isn't a change we would want to take. We want people without strong need to use the Accept-Language header because it is the accepted standard. If, like you, people find they must use a different header they can either use the CustomRequestCultureProvider as you suggested, or write their own RequestCultureProvider.

Thanks for the suggestion though, hopefully the conversation is useful for people in the future.

[davidrevoledo]

Sure @ryanbrandenburg make a lot of sense, sometimes the standard does not match the reality specially with apps who weren't built from scratch but is true that there is an easy implementation to avoid include this change in the framework.

Thanks.