Having an application in multiple languages is now a requirement in many projects. In ASP.net, you can tell your application that the language that should be using corresponds to the one the browser is specifying. While this is a really nice feature in the ideal scenarios (since the user gets the applications in the proper language automatically), there are some scenarios where this might be not the expected behavior like:
- If your user’s computer locale is different than the one he or she prefers for using your application (like when he or she is using a different computer than his/her own)
- When the browser settings have been modified to some value diferent than whatever the user prefers and he or she does not have the knowledge to adjust this setting on the browser.
| Desired language | URL address |
|---|---|
| English | en.myapp.com |
| Spanish | sp.myapp.com |
| Finnish | fi.myapp.com |
public class LocalizationFilterAttribute : ActionFilterAttribute
{
public override void OnActionExecuting(ActionExecutingContext filterContext)
{
var locales = new Dictionary();
locales.Add("mx", "es-MX");
locales.Add("sp", "es-ES");
locales.Add("vi", "vi-VN");
locales.Add("fi", "fi-FI");
var subdomain = GetSubDomain();
if (subdomain != string.Empty && locales.ContainsKey(subdomain))
{
Thread.CurrentThread.CurrentCulture = new System.Globalization.CultureInfo(locales[subdomain]);
Thread.CurrentThread.CurrentUICulture = new System.Globalization.CultureInfo(locales[subdomain]);
HttpContext.Current.Response.Write(String.Format("Culture: {0}", Thread.CurrentThread.CurrentCulture.Name));
}
else
{
HttpContext.Current.Response.Write("Culture: Default ");
}
base.OnActionExecuting(filterContext);
}
private string GetSubDomain()
{
var url = HttpContext.Current.Request.Headers["HOST"];
var index = url.IndexOf(".");
if (index < 0)
{
return string.Empty;
}
var subdomain = url.Split('.')[0];
if (subdomain == "www" || subdomain == "localhost")
{
return string.Empty;
}
return subdomain;
}
}
As you may already noticed, with this code you define a list of locales that will be selected according to the provided subdomain. The next step would be registering this filter so it is used in all the views. You can do this in your Global.asax file
public static void RegisterGlobalFilters(GlobalFilterCollection filters)
{
filters.Add(new LocalizationFilterAttribute());
filters.Add(new HandleErrorAttribute());
}
Once you have a way to set the locale for the current thread, all you need to do is the localization process, which can be done as you already have it. In my case, I’m using resource files to have all the translations and have a fallback resource file if any requested text has no translation on any of the language-specific resource files.