Is localization a responsibility of the View or of the ViewModel? Initially, I thought that it clearly belongs into the VM, as it is just data that needs to be displayed by the view. What exactly needs to be displayed is not important to the view. In addition, I have made the experience that XAML is more brittle than ViewModel code. But in a discussion today, some people strongly believed that localization is the responsibility of the view.
Here's some of the advantages I see for both versions:
Advantages of putting them into the View:
- ViewModel is oblivious of localization
- You can see the resource key in the XAML
- Less code
Advantages of putting them into the ViewModel:
- View is oblivious of localization
- The View does not need to know anything except for it's ViewModel
- It's easier to combine and create more complex strings.
In a Wpf application that uses the MVVM pattern, should the localizable elements (string resources) go into the view, or into the viewmodel? Why? What other advantages and disadvantages are there for the two approaches?
Some background info after comments: Assume that the Localization-backend is based on resx (not LocBaml). In addition, assume there was a framework that (View-Variant) could either transparently replace resource-ids in the view with the string, or that (ViewModel-Variant) would automatically generated INotifyPropertyChanged events for localized properties on the ViewModel.
However, I am mainly interested in arguments why it's better from a conceptual or cleaner-code point of view, disregarding the backend.