WPF Localisation - using resx 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?
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;

&lt;MenuItem Name="Exit" Header="{x:Static Resources:Strings.MENU_HEADER_EXIT}" /&gt;


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?