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:
By this, you can provide your users a simple and easy-to-remember way to get your application in their desired language.
- 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.
In these cases, the user would rather to have a "fallback" mechanism so he or she can select his/her preferred language. One of the options you can use to achieve this is selecting the language/locale based on a subdomain. By this, you will give the users the following options:
| Desired language | URL address |
|---|---|
| English | en.myapp.com |
| Spanish | sp.myapp.com |
| Finnish | fi.myapp.com |
In order to support this, you will need to create an ActionFilterAttribute, something like this
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
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.
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.
By this, you can provide your users a simple and easy-to-remember way to get your application in their desired language.
