Localizing ASP.NET MVC

I've noticed that there has been a bit of confusion regarding localization in ASP.NET MVC so I thought I'd write up the solution to try to clear things up. ASP.NET has quite a reasonable localization model as by default it uses the ResourceManager and .resx files all wrapped up fairly neatly using the Generate Local Resources menu option in Visual Studio. Whereas there are some gaps the model is reasonably sound. Where this solution has learnt from previous localization models is in the resource provider model where you can replace the ResourceManager/.resx solution with an alternative resource implementation of your own design such as a WCF resource service. If you are unfamiliar with ASP.NET localization you should get up to speed with it before looking at localization in ASP.NET MVC.


ASP.NET MVC utilizes most of the ASP.NET localization model so the basics of using a resource provider and the default provider using the ResourceManager and .resx files is no different. The difference is that ASP.NET server side controls are either not possible without the the ASP.NET page model or difficult and are mostly unwanted in the 'pure' world of MVC. This difference is important in localization terms because Visual Studio's Generate Local Resources menu option expects to find ASP.NET server side controls. By default, the Generate Local Resources menu option creates a new .resx file in the App_LocalResources folder corresponding to the .aspx/.ascx page or control (so App_LocalResources\Default.aspx.resx is created to correspond to Default.aspx). Generate Local Resources iterates through every control looking for properties that are decorated with the LocalizableAttribute (set to true). Each control with any such property is modified to have a meta:resourcekey tag and the value of the property together with a key is added to the corresponding .resx file. The property is then said to be implicitly bound to the resource.


There are two problems with localizing MVC: there are no HTML properties that are decorated with the LocalizableAttribute and the HTML controls are not server side. The first issue means that Generate Local Resources does not find any properties to localize so the .resx file is not populated with resource entries and the HTML controls are not marked with a meta:resourcekey tag. What is important to note here, though, is that this is simply the nature of the Generate Local Resource menu option. The model still works so if you manually add a meta:resourcekey and you manually add the corresponding entry in the resx file (and the HTML control is server side) then localization will occur just as it does in an ASP.NET application. The second problem is that HTML controls are not server side by default. Localization occurs on the server and there's just no getting round this if you want to make use of all of the ASP.NET localization infrastructure. The solution is to change the HTML controls to be server side.

So here's an example with this humble HTML button control:-

<input type="button" value="Press Me"/>

To localize it for ASP.NET MVC first run Tools | Generate Local Resources. This will create the necessary .resx file and make minor modifications to the page (but not to the HTML control itself). To localize the control you need to add a runat tag and a meta:resourcekey tag:-

<input type="button" value="Press Me" runat="server" meta:resourcekey="PressMeButtonResources"/>

Then open up the associated .resx file (in the App_LocalResources folder) and add an entry with the key "PressMeButtonResources.value" and the value "Press Me (From resx)". When you run the site you will see that the button shows the value from the .resx file and not the value from the .aspx file. The button is now localizable.

 

Of course, all of the rest of the UI including the static text in the HTML, text in JavaScript, text in the code behind, text in libraries and text and resources everywhere still need to be localized but the solutions to localizing all of this text are the same for ASP.NET MVC as they are for ASP.NET so I'm not going to cover them here.

 

What is needed for MVC is an equivalent to Generate Local Resources that performs the same task except that instead of identifying properties as localizable based on having the LocalizableAttribute it uses some other means such as having a dictionary of 'known localizable properties'. For example the value property of an HTML INPUT control with type="Button" is always localizable and it does not need to be marked with a
LocalizableAttribute for this to be true.

 

By the way, if you're not using ASP.NET MVC and your regular ASP.NET application has lots of HTML and you're wondering about how to localize that then you have many more (better) options open to you. The main one of these is to convert your HTML controls to equivalent ASP.NET server side controls. If this is your plan then you should take a look at the I18NRefactorings (an add-in for the free DXCore) in the download at http://www.dotneti18n.com/Downloads.aspx that will help automate this process. I will blog about this separately at a future date.

Currently rated 3.6 by 11 people

  • Currently 3.636364/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Posted by: guysmithferrier
Posted on: Friday, May 15, 2009 at 9:44 PM
Tags:
Categories: Internationalization | .NET Internationalization Book
Actions: E-mail | Kick it! | DZone it! | del.icio.us
Post Information: Permalink | Comments (9) | Post RSSRSS comment feed

Related posts

Comments

blog.cwa.me.uk

Saturday, May 30, 2009 9:57 PM

pingback

Pingback from blog.cwa.me.uk

Reflective Perspective - Chris Alcock » The Morning Brew #349

Bryan Avery gb

Saturday, May 30, 2009 10:15 PM

Bryan Avery

Nice post, and a good explanation and process for I18N of MVC.

I agree it would be nice to have direct HTML resource files, it seems as if I18N is always left to later and not considered a serious development process in the build of application development environments.

GuySmithFerrier gb

Sunday, May 31, 2009 7:54 AM

GuySmithFerrier

That's very true. Especially so for WPF and Silverlight. Still, ASP.NET itself didn't get anything other than a grow-your-own solution until ASP.NET 2.0 and that turned out fairly well.

Guy

blogs.msdn.com

Wednesday, June 10, 2009 7:39 PM

pingback

Pingback from blogs.msdn.com

Mike Ormond's Blog : ASP.NET MVC Localisation

codedstyle.com

Wednesday, June 10, 2009 8:10 PM

pingback

Pingback from codedstyle.com

ASP.NET MVC Localisation | Coded Style

ZK@Web Marketing Blog

Saturday, July 11, 2009 4:32 PM

ZK@Web Marketing Blog

ASP.NET MVC is built on the ASP.NET framework, so existing WebForms developers can make use of the existing classes and framework knowledge they possess (Forms/Windows Authentication, Membership Roles, Session/Profile state, Health Monitoring etc…). ASP.NET MVC projects also have the added benefit that they can include traditional WebForms pages and User Controls (though I wouldn’t recommend mixing the two if you can help it), so the transition can be made without throwing all your existing pages away.

Kasinos deutsch us

Saturday, July 11, 2009 4:42 PM

Kasinos deutsch

The framework itself is nothing surprising if you’ve looked at Rails, Django, CodeIgniter, et. al. What was interesting to me is to see how the framework is colored by running in the CLR. On the plus side, you get LINQ and a really good VM. On the downside, you have to use for loops and nullable types (wink, nudge). The rest is pretty much what you’d expect to see when you transliterate an MVC framework to C#, though they did display some creativity in making it decent to look at in terms of code style

asp.net

Friday, August 28, 2009 10:18 PM

asp.net

Thanks for clearing this up, my colleague told me that MVC utilizes very little of the ASP.NET localization model, but obviously he was misinformed, i will be happy to reinform him!

Naresh Yadav us

Tuesday, October 27, 2009 2:18 AM

Naresh Yadav

Good explanation. I did not know ASP.NET supports localization to this extent.