July 19, 2018
Hot Topics:

Localizing, unit testing and using AJAX in ASP.NET MVC applications

  • May 26, 2009
  • By Jani Järvinen
  • Send Email »
  • More Articles »


Many web developers using ASP.NET's traditional WebForms technology have shown keen interest to Microsoft's new, open-sourced ASP.NET extension, and for a good reason. This new extension is called ASP.NET MVC. From a software design perspective, the idea of separating your user interface (the views), operation logic (the controllers) and the data (the models) has many benefits.

For one thing, this separation, although it requires a little bit more work than usual, helps in keeping your applications maintainable. Another great benefit is the ability to better run unit tests against your code. The framework (and its Visual Studio integration package) helps you create unit test skeletons for example from controller methods; your task is to write the actual testing code. Since ASP.NET MVC 1.0 is only three months old, time is still required to create an industry-wide set of best practices. However, certain requirements will not change no matter whether you use traditional WebForms technologies or ASP.NET MVC: you need to test, localize and fine tune your user interfaces. In this article, you will learn about different possibilities to unit test your ASP.NET MVC applications, how to localize them to multiple languages, and finally, how to add an AJAX touch to your user interfaces - which are implemented using views in MVC projects.

Getting started with localization

Creating web application user interfaces in multiple languages is not a new problem. In fact, ASP.NET has had built-in support for localization from the earliest versions. For instance, you might have user local or global resources, and referenced them in your controls and/or .aspx files using the <%$ %> constructs. Since the views in ASP.NET MVC applications are often regular .aspx files, you can use the exactly same methods in your MVC applications (Figure 1).

Click here for larger image

Figure 1. The default look and feel of an ASP.NET MVC application.

In addition to this traditional method of localization, you can also add this logic to your controller classes. Because using the <%$ %> constructs is a working, but somewhat tedious method, you can use the controllers to return altogether different views from the controller based on the currently active language. This can be useful especially if the different language versions of the views do not need to be exactly similar. For instance, you might have an English version of your view that is more extensive than, say, the French version.

Let's see both of the options in action. Assume that you have started a plain ASP.NET MVC application, and haven't done any customizations yet. The default application skeleton Visual Studio creates for you contains the Home and Account controllers. For instance, if you needed to localize the Home/About text, you could do as follows.

First, you could use the traditional method of localization: using resources. For instance, to begin using global resources, you would add the App_GlobalResources folder to your solution. You can do this by right-clicking your project's node in Visual Studio's Solution Explorer, and choosing the Add/Add ASP.NET Folder/App_GlobalResources command. This will create the required folder for you.

The next step is to add the resource files. Again, in Solution Explorer, right-click the newly created folder, and choose the Add/New Item command from the popup menu. This will open the familiar Add New Item Dialog box, from which you should choose the Resources File icon. After you give a name to the resource file and click OK, Visual Studio will add it to your project. You can then start typing your resource strings into the displayed grid (Figure 2). When using resources, you need to have an identifier for each string you want to localize in your application.

Click here for larger image

Figure 2. Localization using resource strings works in ASP.NET MVC applications, too.

It's a good idea to give some thought to these identifiers before you start localizing your application, as you will need these identifiers when you refer to the strings in your view pages. Remember also, that while many strings are unique to each page, there probably are many strings that you can use on more than one view. You might want to reflect this fact on the identifier names. Referring to the localized strings is easy: you can use the <%$ Resources %> construct introduced in ASP.NET 2.0. For instance, if you had a resource identifier named HelloWorldText in a resource file called MyResources.resx, then the following code in the .aspx file would be converted to the correctly localized string depending on the user's preferred language:

  <asp:Literal ID="Literal1" runat="server"
  Text="<%$ Resources: MyResources, HelloWorldText %>" />

For ASP.NET MVC to find the correct localized version, the framework uses a special file naming convention. The resource file MyResources.resx contains the strings in a language that is considered the base language of the application. If the user's browser doesn't specify a language, or you don't specify one in code, then the strings from this base file are used. But if the user's chosen language is for instance German, then the language acronym "de" is appended to the resource file name: MyResources.de.resx. The same is repeated for other languages, for instance the file MyResources.es.resx would contain the Spanish strings.

For localization to work, you might also wish to add a special directive to the .aspx file's @Page tag. For instance, to allow automatic detection of user's browser language preference, add the UICulture="auto" attribute to the tag (the identifier after the colon specifies the default language):

  <%@ Page ... UICulture="auto:en-US" %>

The other option to localizing simple views is the possibility to return different views based on the user's language. This requires some logic in the controller, but the code is easy to write. For instance, you could use logic like this:

  public ActionResult Localized()
    if (Request.UserLanguages.Length > 0)
      string lang = Request.UserLanguages[0];
      if (lang.ToUpper().StartsWith("DE"))
        return View("Localized-DE");
      else return View("Localized-EN");
    else return View("Localized-EN");

Remember that you could also encapsulate this code into a (utility) method. Should you require a combination of these two main options, it's good to know that you can freely mix and match. As this is the case, localizing your ASP.NET MVC applications shouldn't be limited by the available technology.

Page 1 of 3

Comment and Contribute


(Maximum characters: 1200). You have characters left.



Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

By submitting your information, you agree that developer.com may send you developer offers via email, phone and text message, as well as email offers about other products and services that developer believes may be of interest to you. developer will process your information in accordance with the Quinstreet Privacy Policy.


Thanks for your registration, follow us on our social networks to keep up-to-date