Localization of Validation and Metadata Strings

IViewLocalizer and culture-specific views do not cover all needs, as we have:

• General purpose strings that are not associated with specific views but can be used in several views. Since duplications kill modularity and modifiability, we must avoid duplicating these strings in several resource files and place them in unique places. We associate them with types instead of views. These types should be associated with the role of the strings to be translated. For instance, we may associate all strings needed by a business service that is injected into several controllers to the business service type. Global strings such as the application name can be associated with the Startup class that represents the whole application. We may also create fake empty classes that represent string roles, just to organize resources around them.

• Messages coming from data annotations. They are automatically added to the views so we can’t place them into the indexer of view localizers. These messages are associated with the ViewModels containing the data annotations, so the associated resource files can be associated with those ViewModel types.

Associating resource files to types

Resource files may be associated with types in a way that is completely analogous to the way they are associated with views. So the resource files associated with a Customer type are named as shown below: