Reputation: 9396
I'm trying localize my ASP.NET 5 / MVC 6 (RC1) project. Unfortunately the official documentation is still missing so I based my experiments mainly on this and this blog posts.
Here is what I did: In Configure
(Startup.cs) I have
app.UseRequestLocalization(new RequestLocalizationOptions
{
RequestCultureProviders = new List<IRequestCultureProvider>
{
new CustomRequestCultureProvider(httpContext => Task.FromResult(new ProviderCultureResult("de-CH"))),
new AcceptLanguageHeaderRequestCultureProvider()
}
}, new RequestCulture("en-US"));
Note that the first entry in my RequestCultureProviders
list always returns the de-CH
culture. So I would expect that the AcceptLanguageHeaderRequestCultureProvider
as well as the default RequestCulture
(en-US
) have no influence.
However when I look at
HttpContext.Features.Get<IRequestCultureFeature>().RequestCulture.Culture.Name;
in some controller action, its value is en-US
and not the expected de-CH
.
I then tried to change the default RequestCulture
in Configure
from en-US
to de-DE
and now when I look at
HttpContext.Features.Get<IRequestCultureFeature>().RequestCulture.Culture.Name;
in my controller action, it has the value de-DE
.
So the question is: Why does ASP.NET fall back to the default culture instead of using the culture de-CH
provided by my CustomRequestCultureProvider
?
Upvotes: 4
Views: 2013
Reputation: 57813
It seems you must also include "de-CH" in the list of supported cultures. For example, the following returns "de-CH" as the culture, but if I comment out the lines setting SupportedCultures
, it displays "en-US". In an MVC application, you might also have to set SupportedUICultures
.
public void Configure(IApplicationBuilder app)
{
app.UseIISPlatformHandler();
var requestLocalizationOptions = new RequestLocalizationOptions
{
SupportedCultures = new List<CultureInfo>
{
new CultureInfo("en-US"),
new CultureInfo("de-CH")
},
RequestCultureProviders = new List<IRequestCultureProvider>
{
new CustomRequestCultureProvider(httpContext => Task.FromResult(new ProviderCultureResult("de-CH"))),
new AcceptLanguageHeaderRequestCultureProvider()
}
};
app.UseRequestLocalization(requestLocalizationOptions, new RequestCulture("en-US"));
app.Run(async (context) =>
{
var envName = context.Features.Get<IRequestCultureFeature>().RequestCulture.Culture.Name;
await context.Response.WriteAsync("Hello World! " + envName);
});
}
The description for the SupportedCultures
property says a value of null
indicates all cultures are supported and that null
is the default, but testing indicates otherwise, as does the source:
/// <summary>
/// The cultures supported by the application. The <see cref="RequestLocalizationMiddleware"/> will only set
/// the current request culture to an entry in this list.
/// Defaults to <see cref="CultureInfo.CurrentCulture"/>.
/// </summary>
public IList<CultureInfo> SupportedCultures { get; set; } = new List<CultureInfo> { CultureInfo.CurrentCulture };
Upvotes: 6