To start with, you are doing wrong thing: "manual" localization, while .NET in general and WPF in particular suggest much more robust, reliable and "automated" way of globalization and localization based on
satellite assemblies. You can start here:
https://msdn.microsoft.com/en-us/library/ms788718%28v=vs.110%29.aspx[
^].
One particular bad thing you are doing is is hard-coding
immediate constants like "english", "spanish", etc. This is not supportable. It's apparent that, with such approach, you have to write such string at least twice. If you misspell, the compiler will never warn you.
Not only your approach is "manual" and self-baked, it's just very bad, especially when compared with real .NET globalization/localization. You can switch culture even during run-time, and, in certain cases, specify "wrong" culture, which is not exactly implemented in the set of localizations. Then the
fallback mechanism will always get you some UI (and non-UI resources), closest to what you wanted. For example, if you want "en-GB" which is missing, you can get "en".
This is the table of culture codes:
https://msdn.microsoft.com/en-us/library/ee825488%28v=cs.20%29.aspx[
^].
I always try to encourage people, including myself, to "reinvent the wheel", but you need to check your invention by comparing it with known approaches which may or may not appear to be better than yours. For this purpose, you really need to read documentation and other source, not only write code…
—SA