We recently began work on a website project using ASP.Net MVC 3.0 where one of the requirements was that the site will be globalized into different languages. However, one of the design considerations is that the content is going to be originally produced in English and then translated and published as available into the other supported languages. What the site needs to do is gracefully degrade to English when the desired globalized content is not available.
Other issues are that some languages are wordier or more compact than English which can affect the graphic design. For example “Structured Investment Vehicles” (30 characters) translates in French to “Véhicules d’Investissement Structurés” (37 characters). The French version requires 23% characters which is—roughly speaking (because of proportional fonts)—about 20% more space than the English version. It’s pretty typical for French phrases to contain 20-30% more characters than the English equivalent which means that resource file strings and just swapping out text can ruin the visual design layout. What is needed is re-layout of parts of views to accommodate the space consumed by different languages.
The idea is that we have English as an invariant which has every view the site uses in the normal place. We then have a /Views/Globalization directory which contains a subdirectory with the ISO 639-1 two-letter macro-language code ( ar = Arabic, fr = French, es = Spanish, etc.) which contain whatever translated content is available. If the browser requests a particular non-English language translation, we want to views to come from the appropriate Globalization directory but if the content doesn’t exist, we fall back to English.
Our solution is to use views, partial views and master pages as the unit of globalization. In order to do this we created a new IViewEngine which extends whatever view engine we would otherwise be using. Our team is comfortable with WebForms so we extended WebFormViewEngine.
Example View Layout
/Views
/Globalization
/ar
/Home
/Index.aspx
/Shared
/Site.master
/Navigation.aspx
/es
/Home
/Index.aspx
/Shared
/Navigation.aspx
/fr
/Home
/Index.aspx
/Shared
/Home
/Index.aspx
/Shared
/Error.aspx
/Footer.aspx
/Navigation.aspx
/Site.master
In the sample above, French is not fully globalized so when French views are served, the Navigation.ascx partial view should be served from /Views/Shared/Navigation.ascx, the Arabic views declare themselves as using the /Views/Globalization/ar/Shared/Site.master rather than /Views/Shared/Site.master and the default English Error.aspx view is always served.
jQuery Script to Switch Languages
/// <reference path="jquery-1.4.4.js" />
/// <reference path="jquery.cookie.js" />
//declare namespace to avoid collisions with extension js in the browser
var mySiteNamespace = {};
mySiteNamespace.switchLanguage = function (lang) {
$.cookie('language', lang);
window.location.reload();
};
$(document).ready(function () {
// attach mySiteNamespace.switchLanguage to click events based on css classes
$('.lang-english').click(function () { mySiteNamespace.switchLanguage('en'); });
$('.lang-french').click(function () { mySiteNamespace.switchLanguage('fr'); });
$('.lang-arabic').click(function () { mySiteNamespace.switchLanguage('ar'); });
$('.lang-spanish').click(function () { mySiteNamespace.switchLanguage('es'); });
});
This little JavaScript attaches a switchLanguage function to elements (such as <a/>) which declare the specified css classes. It sets a language cookie which our custom IViewEngine is looking for.
Extending WebFormViewEngine
The key methods to override when extending WebFormViewEngine are CreatePartialView and CreateView. What we need to do is detect what language the browser is requesting and then choose the correct globalized view if it exists and fall back to the default behavior if it doesn’t. For simplicity, I’m showing code that uses a cookie to determine what language the end user wants but this detection can be as sophisticated as you like.
using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.Mvc;
using System.Text.RegularExpressions;
using System.IO;
namespace System.Web.Mvc
{
public sealed class WebFormGlobalizationViewEngine : WebFormViewEngine
{
protected override IView CreatePartialView( ControllerContext controllerContext, string partialPath )
{
partialPath = GlobalizeViewPath( controllerContext, partialPath );
return new WebFormView( controllerContext, partialPath, null, ViewPageActivator );
}
protected override IView CreateView( ControllerContext controllerContext, string viewPath, string masterPath )
{
viewPath = GlobalizeViewPath( controllerContext, viewPath );
return base.CreateView( controllerContext, viewPath, masterPath );
}
private static string GlobalizeViewPath( ControllerContext controllerContext, string viewPath )
{
var request = controllerContext.HttpContext.Request;
var lang = request.Cookies["language"];
if( lang != null &&
!string.IsNullOrEmpty(lang.Value) &&
!string.Equals( lang.Value, "en", StringComparison.InvariantCultureIgnoreCase ) )
{
string localizedViewPath = Regex.Replace(
viewPath,
"^~/Views/",
string.Format( "~/Views/Globalization/{0}/",
lang.Value
) );
if( File.Exists( request.MapPath( localizedViewPath ) ) )
{ viewPath = localizedViewPath; }
}
return viewPath;
}
}
}
Registration in Global.asax.cs
The final step is to register WebFormsGlobalizationViewEngine when the Application.Start event fires.
protected void Application_Start()
{
ViewEngines.Engines.Clear();
ViewEngines.Engines.Add( new WebFormGlobalizationViewEngine() );
// rest of application start stuff
}
Summing Up
There are a lot of ways to globalize content. This solution has the advantage of being straightforward and flexible. The main disadvantage is that we have to maintain translations of all the views and partial views.
Like this:
Like Loading...