Improve localization support in views, model metadata, and validation
Currently the way things get localized in model metadata is the same as DataAnnotations - static properties on some class that does the lookup.
The problem is, this doesn't integrate with the rest of ASP.NET localization (e.g., ResourceProviderFactory) and means you end up with a ton of these static properties to do lookups.
A similar situation is true with validation messages - you get a type name and a static property name.
The problem here is that you don't really get any opportunity to insert any control over where/how resources get retrieved. You can create a custom ResourceProviderFactory; you can't really insert yourself into the "new ResourceManager()" mechanism.
The view story isn't that great, either. If you want to localize a string, you either have to use the static property generation thing over standard resx (bypassing ResourceProviderFactory) or do the full GetGlobalResourceObject call for every string in your view.
In general, it feels like localization is a second class citizen. It'd be nice to see some cleaner support for localizing strings in views, for localizing model metadata and validation messages, and for integrating with some of the mechanisms already in use today in ASP.NET for localization.
2 full featured solutions that extend MVC to the point of useful, as far as Localisation is concerned:
Nadeem Afana (@NadeemAfana) , http://afana.me/post/aspnet-mvc-internationalization.aspx, Code: http://afana.me/attachment/aspnet-mvc-internationalization.zip
Rick Strahl (@RickStrahl) : http://west-wind.com/westwind.globalization/ Nuget: Install-Package Westwind.Globalization, Code: https://github.com/RickStrahl/Westwind.Globalization
that provides ResourceProvider extensions, and even Microsoft Translate feature to translate resource files in an accompanying admin webpage.
Both allow the storng of resource strings in Databases.
Another thing: improve the story with new HTML5 input types.
MVC html form helpers output values in CurrentCulture and on the incoming path model binder binds form input with CurrentCulture as well. This is OK.
However, new input types (number, range, date, time etc.) expect and post invariant values.
I have no idea how to solve it, especially since a general solution should take into account the fact that the browser may downgrade new input types to text input and then the user would input the value using what they are accustomed to - so something matching CurrentCulture probably.
There should be at least a way to specify for the model binder (or is it a value provider?) what culture to use.
Also, extend ValueExtensions.ValueFor* to allow formatting with InvariantCulture.
one year on review, any progress?
David De Sloovere commented
I'm really bothered with the fact the annotations need static resources instead of having the ability to use a custom resource provider.
For the applications we develop this is far more important than having views switch automatically by device or some sort. But one is more 'flashy' than the other so I know why some decisions are made. It's just to bad that these things get left behind.
Maybe in the US most application are in one language, but in European countries, this is very different. What LOB application has it's translations in resource file anyway? To me that's not an option. If you want to change one letter, you need to build and deploy again.
I am not seeing anything about localization and i18n in the MVC 4 Roadmap so I hope it doesn't get missed again but I too agree this is one of the most neglected areas in MVC that needs huge overhaul.
Travis Illig commented
Looks like philha posted a sort of convention-based approach on his blog today: http://haacked.com/archive/2011/07/14/model-metadata-and-validation-localization-using-conventions.aspx
I'm fine with something like that, but it'd be nice not to have to "roll my own" when it comes to localization. I sort of feel like it's, "Yeah, ASP.NET has a localization mechanism, and there's this other localization mechanism over here for validation and model metadata, but, you know... hooking all that up is 'an exercise left to the reader.'"
Robert Slaney commented
I would also like to see client side localisation vastly improved as well via jquery / query globalization