current community

your communities

more stack exchange communities

company blog
Stack Exchange Inbox Reputation and Badges
tour help
Code Review Stack Exchange is a question and answer site for peer programmer code reviews. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top
up vote 4 down vote favorite
1

I have a small WPF application which I'm not exactly localizing, but not hard-coding resources either. I know WPF doesn't use .resx files for that purpose, but I exposed the resource strings as public ViewModel properties which the view's controls bind to:

using resx = MyApp.Properties.Resources;
...

public string InterferingProcessesText { get { return resx.InterferingProcessesText; } }
public string SettingsText { get { return resx.SettingsText; } }
public string ExecuteInstallerCommandText { get { return resx.ExecuteInstallerCommandText; } }
public string SaveSettingsCommandText { get { return resx.SaveSettingsCommandText; } }
public string RefreshProcessesCommandText { get { return resx.RefreshProcessesCommandText; } }
public string KillInterferingProcessesCommandText { get { return resx.KillInterferingProcessesCommandText; } }

And then if I ever decide to translate the strings I can copy my .resx file and rename it with a culture suffix just like I would have done in WinForms or in any other Web app.

I know I'm supposed to put x:Uid all over my XAML and localize my app the way WPF has it, but just how bad is that, and why?

Yes, it clutters up my ViewModels with public string properties (#region to the rescue!). But does it violate some MVVM principle that will come and bite me in the *** later?

share|improve this question
up vote 6 down vote accepted

I have had the same thought when implementing localisation in WPF, and came to the conclusion that .resx files are fine. I came to that conclusion because alternatives quickly became more complicated than I could be bothered with, and a RESX-based solution works for me.

So, in my various View.xaml files, I use bindings like this;

<MenuItem Name="Exit" Header="{x:Static Resources:Strings.MENU_HEADER_EXIT}" />

Changing languages is simply a matter of creating language-specific versions of the RESX entries. (http://msdn.microsoft.com/en-us/library/vstudio/aa992030%28v=vs.100%29.aspx).

Now in regards to your actual question; I do not think this sort of data belongs in a ViewModel. There is no 'modelling' going on with these strings; they are just label text, and as such are view-only data. If we follow your above suggestion to an overzealous conclusion, we might as well add ViewModel properties (and Bindings) like;

Font InterferingProcessesFont { get { return FontFamily.Arial; }
Color InterferingProcessesFontColor { get { return Color.Black; }
FontStyle InterferingProcessesFontStyle { get { return FontStyle.Normal; }
. 
etc.
.

For my mind, localised labels like this are fixed display settings that will not change for the life of an application, and in most cases, will never change for a particular user. Why clutter a ViewModel with static text?

share|improve this answer
    
Wow I didn't realize I could bind with resx directly in the xaml! I totally agree they don't quite belong there at all! – Mat's Mug♦ Jun 4 '13 at 11:44

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.