If the user has their browser set to fr-CA, for instance but my site has the option to view the page in another available language (like English). How can I override the accept-language header so that I can reload using the specified language?
I was attempting to simply change the Accept-Language header and then reload the page, but I'm not sure how to do this. Any thoughts?
UPDATE: Ok, so I'm getting people explaining to me what localization is so I must not have asked this properly.
My site currently has globalization set to auto in the web.config so it will automatically set the thread culture to whichever language was negotiated at app start. By default, the user's browser will send the accept-language header based on the language settings for the browser which, like someone pointed out below, average users have no clue what those are, where those are, or how to change them. In any case, let's call this default behavior that the browser will handle the language headers first. However, as a FEATURE, I want to allow the user to change this accept-language header from the page. For instance, in the application, the language settings will normally be determined by cookie or by user preference (via profile settings), but on the landing/login page (particularly if this your first time logging in on a certain computer), I have no idea who you are so I only have your browser settings to go off of. But let's say that you're traveling on business and accessing this site from an american computer, the page loads in English and you can't read it and you have no idea how to change the browser language. Would it not be nice to have the option to choose your language from a drop down menu or icon or something? I think it would be.
So in order to do that, I need to be able to change that accept-language header and reload the page. This is where I'm not sure how to proceed.
I've tried navigator.language = <selected language>
and xhr.setRequestHeader
but these don't seem to work.
If the user has their browser set to fr-CA, for instance but my site has the option to view the page in another available language (like English). How can I override the accept-language header so that I can reload using the specified language?
I was attempting to simply change the Accept-Language header and then reload the page, but I'm not sure how to do this. Any thoughts?
UPDATE: Ok, so I'm getting people explaining to me what localization is so I must not have asked this properly.
My site currently has globalization set to auto in the web.config so it will automatically set the thread culture to whichever language was negotiated at app start. By default, the user's browser will send the accept-language header based on the language settings for the browser which, like someone pointed out below, average users have no clue what those are, where those are, or how to change them. In any case, let's call this default behavior that the browser will handle the language headers first. However, as a FEATURE, I want to allow the user to change this accept-language header from the page. For instance, in the application, the language settings will normally be determined by cookie or by user preference (via profile settings), but on the landing/login page (particularly if this your first time logging in on a certain computer), I have no idea who you are so I only have your browser settings to go off of. But let's say that you're traveling on business and accessing this site from an american computer, the page loads in English and you can't read it and you have no idea how to change the browser language. Would it not be nice to have the option to choose your language from a drop down menu or icon or something? I think it would be.
So in order to do that, I need to be able to change that accept-language header and reload the page. This is where I'm not sure how to proceed.
I've tried navigator.language = <selected language>
and xhr.setRequestHeader
but these don't seem to work.
- Dont know if I it helps but I use the Accept-Language to deliver the related content and deliver a fallback if there's no locale for the Accepted-Language available on the server – Bernie Commented Aug 30, 2013 at 0:46
2 Answers
Reset to default 7I might be wrong but the locale settings is not something you change in your code. This is determined by the browser's user configuration. If you are using an HttpClient you definitely send the value you want for Accept-Language header to the server, but don't expect to change this from your code and make it effective in ALL the requests originated in the browser.
Common practice is to set a custom cookie with your user's language preference. By default you should populate this cookie with the value on Accept-Language header. In ASP.NET MVC there is a setting so both Thread.CurrentThread.CurrentCulture and Thread.CurrentThread.CurrentUICulture get's set according to the user's browser configuration:
<system.web>
<globalization enableClientBasedCulture="true" uiCulture="auto" culture="auto" />
</system.web>
You can then create an ActionFilter that would check the custom language cookie and will set the Thread.CurrentThread.CurrentUICulture accordingly.
Thread.CurrentThread.CurrentUICulture is used to determine which resources the code should use. While Thread.CurrentThread.CurrentCulture is used for all the numeric and dates handling.
This is how that action filter might look like:
public class LanguageActionFilter : IActionFilter
{
public void OnActionExecuted(ActionExecutedContext filterContext)
{
}
public void OnActionExecuting(ActionExecutingContext filterContext)
{
var langCookie = GetOrSetLanguageCookie(filterContext.HttpContext);
var culture = new CultureInfo(langCookie.Value);
Thread.CurrentThread.CurrentUICulture = culture;
}
private HttpCookie GetOrSetLanguageCookie(HttpContextBase context)
{
var cookie = context.Request.Cookies[Constants.LanguageCookieName];
if (cookie == null)
{
//set the cookie for first time
cookie = new HttpCookie(Constants.LanguageCookieName, Thread.CurrentThread.CurrentUICulture.Name)
{
Expires = DateTime.Now.AddYears(1),
Path = "/"
};
context.Response.Cookies.Add(cookie);
}
return cookie;
}
}
Pleae Note:
- Even when your user selects, let's say "es-Ar" in your interface, and you set your UICulture accordingly for that user, IF the user's browser is configured with en-US dates posted for that user will be parse using the English convention, so float number will.
IE: If the user in USA with a browser set to en_US chooses to use the Spanish interface of your app, when this user post information to the server dates like:
1/5/2015 will be parse as January 5th in the server, rather than May 1st.
Numbers like 1,900 will be parsed as 1900 in the server rather than 1.900.
I learned this the hard way. I have a question here that was never answered.
Please let me know if you have any questions.
The Accept-Language
header is a request header, so it is sent by the browser (or other client software). On your server, you can ignore it by doing nothing. That is, it has no effect as such; all depends on whether your server-side code recognizes it and takes some action. So you cannot and need not change the header sent by the browser.
The user can change the Accept-Language
header sent by the browser using the browser’s preference settings. E.g., in Chrome, go to “Settings”, click on “Show advanced settings...”, scroll down to “Languages”, click on “Language and input settings...”, and then add languages and drag to order them.
This is not something people do often, and most people have no idea of the existence of such settings. So what the browser sends is usually some factory defaults. They can be rather strange, e.g. Accept-Language: fr-CA
would mean, by the protocol, “if you, dear server, have different language versions of the resource I’m requesting for, please give me Canadian French; if you don’t have it, I don’t care which version you give”. This means that if the resource exists in generic French (of French French), or in English, these would have no preference over, say, Swahili or Volapük version. So a more sensible header would normally be Accept-Language: fr-CA, fr, en
, and this is in practice how you should deal with Accept-Language: fr-CA
.