I am working on localization of a relatively complex .NET application. The requirement is not only to translate UI and switch date and number format - but to have a different algorithms for certain locales (for example - local taxation rules).
Is there a simple way to implement this in .NET (like satellite assemblies for resources)?
Straight localization of application strings is rather simple, you use appropriately named resource files and allow the .Net runtime to do the heavy lifting of ensuring that you have the appropriate resources loaded according to your UICulture settings.
When you start to introduce business rules based on locale it gets a whole lot more complex, there is no inbuilt functionality to help manage this - instead you must write the code yourself. There are a lot of things to consider.
An approach I've used and found to work well is this:
Assembly.Load(name)
). Using a good IoC framework like Unity will help here, you can programmatically register and resolve interfaces to actual class instances. Alternatively Microsoft's Enterprise Library ("EntLib") gives you declarative plugin functionality so you can use a configuration file to dictate what assemblies are discovered and loaded.DynamicResource
markup extension was insufficient for what I needed).Some of this may be applicable to you, if not I hope it helps guide you in the right direction. If possible try and give products like EntLib a go, although that either may be overkill or may not be quite flexible enough for you. The best thing I can advise is to do a serious amount of thinking and designing before you start coding, otherwise it can be difficult to rework if you find you chose the wrong option. Deploying a good structured localisation pattern through your application is not something that should be done in a random or adhoc way.
*normally you wouldn't need to set the culture on background threads (pre .Net 4.5) unless you are doing culture specific string comparisons. If you do need to set a specific culture on a background thread, be aware of when you need it and design for it. Think about injecting culture as a parameter to the functions that need it. Or keep the business locale stored in an application level variable and read it as needed.