In this article I'm going to review usercontrol and two types of localization methods around them

1. User Controls Overview
2. Localization per user controls
3. Localization on application only
4. Conclusion

1. User Control Overview

"UserControls are the basic unit of reusable Xaml and the code that goes with it." User Controls are sometimes called custom controls. Most Silverlight applications will use and create many usercontrols in an application to simplify the application design in a more object orientated structure. A usercontrol can be used for UI elements (eg: dropdownlist, styled buttons, image viewer etc..) or computational (eg: prime number control etc...) or data retrieval (eg: load xml etc...).

Once you have created something worth re-using, you can instantiated directly in XAML as a custom type user control. eg: <CoolButtonUCNamespace:coolButton x:Name="button1" ButtonText="Click Here" />.

Some samples of user controls but note most controls wont have many UI strings to localize eg:

1. DropDown list would contain 0 UI loc strings (DB Data is content not UI localisation)
2. Image viewer would contain 2 loc string (Previous Image and Next image)
3. RTE (Rich Text Editor) would contain ~40 loc strings (Bold, Italic, Insert Image etc..)

2. Localization per custom controls

On the Silverlight forums people occasionally ask how to do localization on a per control basis? eg: coolButton.xaml with coolButtonResource.de.resx where each control has its own set of resource files. This will mean you need to manage, localize & build many seperate files.

To me this method gives some advantages and disadvantages

Advantages:

1. Clean code separation between app and control
2. No dependencies external to the control

Disadvantages:

1. Cultures & Localization strings are control dependant
2. May lead to translation in-consistency
3. Control culture resources could grow very large (unless ondemand cultures are used)
4. Longer build times

Unless your a usercontrol vendor, this method would not be my first choice.

3. Localization on application only

The excellent Jordan Hammond created a novel way and wrote sample application by registering custom dependency properties and having all controls in generic.xaml.

But if you to have seperate controls, downloadable on demand, but I'll try to explain the logic and basics.

First review the good example of creating a reusable user control http://community.devexpress.com/blogs/theonewith/archive/2008/08/06/custom-silverlight-controls-creating-a-reusable-messagebox-dialog-part-i.aspx 

Note a custom type user control can register custom dependency properties where you can set all localisable resources in its declaration and bind xaml at runtime

eg: <CoolButtonUCNamespace:coolButton x:Name="button1" ButtonText="Click Here" /> as  <CoolButtonUCNamespace:coolButton x:Name="button1" ButtonText="{Binding LocButtonText, Source={StaticResource LocStrings}}" /> using the resx xaml binding as shown in the previous article.

Using this method you can expose all UI string properties in each of your user controls.  This allows you to override the default strings and use a single application resx file per application rather than a rex per control.

Advantages:

1. Simpler loc build setup
2. Better content separation
3. Remove dependence on control not supporting application culture set
4. Translator has full control of all localization strings

Disadvantages:

1. More work required in user control creation
2. More verbose xaml

4. Conclusion

Thanks Jordan to pointing me to this method. I believe the localization per application is better due to the cleaner content and code separation which makes life far easier for the translator. Please share your thoughts below.

Updated: See bluetext control on http://wpf-e.spaces.live.com/blog/cns!2B248D261D0E0035!407.entry for code sample