Wednesday, April 3, 2013

Localize your MVC app based on a subdomain

Having an application in multiple languages is now a requirement in many projects. In, 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.
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

In order to support this, you will need to create an ActionFilterAttribute, something like this
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));
                HttpContext.Current.Response.Write("Culture: Default ");
        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.

Jorge Gaona

Software developer with main experience in Microsoft Technologies but who also enjoys working with other languages. More about me

2 comentarios:

  1. This comment has been removed by the author.

  2. Hi!
    If you’re interested in a tool to collaboratively localize apps, I suggest you give a shot. It’s a very user-friendly online translation platform that handles multiple popular language file formats. You’ll see that it has a sum of very useful features to aid your localization workflow.
    Cheers and good luck with your projects!



Copyright @ 2013 A learning journey.