.NET satellite assembly containing code [closed]

Question

Closed. This question needs to be more focused. It is not currently accepting answers.

---

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 8 years ago.

Improve this question

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)?

Answer 1

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:

• upon app start up determine the location/locale that is applicable to the business rules. In my case this information is stored in the database. When you have a more complex requirement than just string localization you cannot rely on the UICulture of the starting thread - when you install Windows it will default to a culture of en-US, you need to accommodate the frequent number of users that fail to correct this.
• use that locale information to dynamically load any pluggable assemblies (using 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.
• applying the previously discovered locale to the UICulture of the initial (UI) thread* assists with getting locale specific strings and themes from theming and general resource (i.e. not string specific) assemblies. When using WPF this allows me to load locale specific colours, control templates, images (some with text), etc.
• I wrote a custom markup extension to use in XAML to inject strings that are dynamically loaded in theme files (the DynamicResource markup extension was insufficient for what I needed).
• I wrote a custom converter to assist with using locale specific images (the inbuilt .Net framework localization functionality doesn't help you when you have images with text in them)

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.