C# Accessing localized XML at runtime

Question

I have a C# app that needs to be localized. I can use the RESX .NET MUI strategy to do that. Now, I have a separate team that is providing additional localized resources (XML files) post build/compile time. I'd like to take advantage of .NETs MUI strategy which provides a nice fallback mechanism, but I can't seem to find a way to make that happen.

Note, I have thought about adding the localized file names (which I know) in my App's string resources file. However, if at runtime the file doesn't exist, then I'll have problems (and no way to automatically fallback).

So, is there a way to utilize the .NET MUI strategy in this scenario?

Answer 1

Option 1:

You can store the XML files in a resource, and then get a stream object to read it, which uses the same approach as is done with strings, etc. See http://msdn.microsoft.com/en-us/library/zxee5096.aspx for that.

Option 2:

You can also apply the same basic approach as that used by resources yourself. I've found it convenient with web applications which are often based on a lot of files (.aspx, .html, .css, .js, .png, etc) anyway. Say you've got a bunch of directories like:

localised/en/SomeFile1.xml (and etc....) localised/en-US/SomeFile1.xml (and etc....) localised/en-GB/SomeFile.xml localised/fr/SomeFile.xml

I come along with my en-IE prefernces, and you don't match that, but you do match en and that's good enough (okay ideally you should pick up that en-IE is closer to en-GB than en-US, but that's totally into the bonus-credit territory and much better than .NET will do with resources).

Your matching algorithm should be:

1. Try to find a match for the locale sought, return if found.
2. Drop off the end of the locale, so en-GB-OED becomes en-GB, en-GB becomes en- and so on. If that doesn't remove the whole thing, go back to step 1 with this new locale.
3. Try zxx (zxx isn't used by .NET afaik, but it is used with BCP 47/RFC 4647 and ISO 639 for items with no lingual content - e.g. a passport photo of you is locale zxx because it's just as appropriate to go with a French document as a Yoruba or Welsh one).
4. Try a "default" locale as defined by you (or error if your application promises to make a good match).

At that point, you'll be doing slightly better than what resource files do. Still, mostly option 1 is a lot simpler and is far more self-contained.