The last part addressed larger chunks of HTML content. In that case, imperative coding works nicely. For labels, menu links and similar texts however, the standard localization mechanism in .NET is resources, based on manifest resources, and respective satellite assemblies.
Note: This post is part of a series…
Access is handled via the ResourceManager class, additionally Visual Studio will generate an accessor class for each .resx file, that offers members for each key. This eliminates the possibility of typos and provides more convenience through intellisense. For MVC applications it is necessary to change the access modifier for that class to public, as shown here:
The reason is that ASP.NET works with code generation for views (WebForms as well as Razor), thus the generated code lives in another temporary assembly, not the one associated with the web project, and won’t have access to an internal class.
Please note that this applies to the generated accessor class, not the resource itself. One can always use ResourceManager and access a resource in any other assembly.
And to get another point out of the way: With ASP.NET WebForms you might have used the special folders App_GlobalResources and App_LocalResources to place your .resx files in. Don‘t do that with ASP.NET MVC!
The problem is that resources files in these folders are treated differently by Visual Studio and the ASP.NET runtime. There are workarounds to make it work, but why rely on quirks if another approach works without.
If you are interested in the background, Scott has further information.
I chose to place my resources in my own special folder. Since the obvious name for that folder (“Resources”) is already taken (by the default resource file generated from the project settings as well as as namespace by App_GlobalRessources), I named it Localizations:
The resource file Labels.resx and its localized version Label.de-DE.resx contains all navigation labels used in menus and other links.
Adding this folder to the web.configs (the one in the Views folder)…
…makes the view code even more convenient:
@Html.ActionLink(Labels.Navigation_Stock_Index + "…", "Index", "Stock")
Proper localized information in respective .resx files available, and we have the next localization step solved:
Final hint: I can live with that approach, i.e.maintain resources in arbitrary files, that I organize as I like. Should you want to “attach” resources to you views and have them used automatically, you might want to have a look at Matt’s post. It should also be possible to implement a simple fallback scheme that allows keeping general labels automatically in one centralized resource file, while maintaining specific labels in view specific resource files.
That’s all for now folks,