As we are continuously working on the localization of all our controls, we'd like to share how the localization is actually progressing at our side.With the RadControls for Silverlight Q1 2009 SP1 we introduced the LocalizationManager. Actually we have used it to localize the RadUpload control for Silverlight. Now we have four more controls localized right from the box: RadTreeView, RadMediaPlayer, RadColorSelector and RadColorPicker. In the attached example you can see them localized. Another control to be localized soon is the RadGridView control. The LocalizationManager allows you to easily localize any of our controls. In addition, we followed the practice to share the same code across Silverlight and WPF. Hence, once a control has been localized for Silverlight, the control's declaration can be reused in WPF.
To localize your own code you can either use resources or you can override the string loading process with your custom logic. Below is a snippet of the LocalizationManager declaration:
To start the localization you should instantiate your manager and assign it to the LocalizationManager.Manager static property. This should happen before the creation of the UI, otherwise some parts might remain not-localized:
Usually, you can store the strings in Resource files or in Your custom holder.
If you prefer this approach you should store the string in a resource file and enable ResXFileCodeGenerator (internal or public) for it. Then, you should instantiate the LocalizationManager object and set its ResourceManager property to your strings' resource manager - for example:
Initialize the LocalizationManager.Manager property with this new object (as shown in the code above). Now you can create the application's UI.
If you rely on culture settings to load the right resource value, you have to write some code inside your application's project file. For example, if you have to support English, German and Japanese strings, you can store the localized strings in strings.resx, strings.de.resx and strings.ja.resx files. For the strings.resx file you can set ResXFileCodeGenerator (internal or public) and for others set No code generation. Then, you can open the project file in a text-mode and append the code below to notify the framework about the supported cultures:
Now you can rely on the UI culture or you can set the localization manager's Culture property:
myLocalizationManager.Culture = new CultureInfo("de");
Using custom string storage:
Another approach is to implement your own storage for the localized strings (i.e. a database). In this case you should inherit the LocalizationManager class and override its GetStringOverride method. Here is the starting frame of the code:
Finally, you should instantiate your manager and assign it to the LocalizationManager.Manager static property:
Below are some code-snippets demonstrating the localization with the LocalizationManager.
Inside XAML code:
Separately from the instantiated LocalizationManager, in your XAML code you can use the LocalizationManager.ResourceKey attached property to initialize your controls. For example, if you want to localize a button on your page, you can use the following code:
In the Code-Behind:
In the code-behind, you can use the LocalizationManager's GetString static method, or, if you have instantiated a LocalizationManager object, you can use its GetStringOverride method, like:
The SetResourceKey method triggers the OnResourceKeyChanged method where a type-oriented initialization occurs. For the time being, we have implemented initialization for the following types:
Valentin Stoychev (@ValioStoychev) for long has been part of Telerik and worked on almost every UI suite that came out of Telerik. Valio now works as a Product Manager and strives to make every customer a successful customer.
Subscribe to be the first to get our expert-written articles and tutorials for developers!