In previous versions of XAF the support for localization was not perfect. The culture-specific resources of each module were stored in the module’s assembly, and it was impossible to localize them without rebuilding. As the default XAF modules are available only in English, you had to localize strings, supplied with the modules, in each new application. These included strings like: captions of classes and properties from the Business Class Library, captions of actions supplied with the System Module, validation messages, exceptions messages, etc. To put it bluntly, this was a PITA.
As we all know, the .NET Framework provides a common way of storing the culture-specific strings in satellite assemblies. The MSDN states that the satellite assembly is “A .NET Framework assembly containing resources specific to a given language. Using satellite assemblies, you can place the resources for different languages in different assemblies, and the correct assembly is loaded into memory only if the user elects to view the application in that language.”
Previously, you could localize the DevExpress components, used in your XAF application, via the satellite assemblies. Now this approach is also available with XAF modules too!
To support the satellite assemblies in XAF modules, we made the following changes:
Firstly, the naming convention for the XML file storing the localization differences of the modules was changed. For instance, the Model.DesignedDiffs_de.xafml file is now called Model.DesignedDiffs.Localization.de.xafml. With this convention, Visual Studio places this resource in the satellite assembly automatically. Note the naming convention for user and application difference files remains the same.
Next the algorithm for obtaining the list of languages, available in the Model Editor, was changed. Now, the list can be retrieved from these sources:
1) The Languages key from the configuration file’s appSettings section:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<appSettings>
<!-- ... -->
<add key="Languages" value="en;de;fr" />
<!-- ... -->
</appSettings>
The value of this key consists of available language codes, separated by the semicolon.
2) From the current project/application differences file names.
When the Model Editor is invoked as the Visual Studio designer, only the second source is available. At runtime, these sources are joined. So, if there are no differences for a certain language, but this language is added in the configuration file, then this language can be specified as preferred, and the values stored in the corresponding satellite assembly will be used in the UI.
Note, to load the localized property values from the satellite assembly, the Model Editor or the application must be restarted:
Some of our customers have kindly provided translations for ready-to-use satellite assemblies, you can find these assemblies attached to The collection of localized DevExpress assemblies KB article. At the moment there are no V10.2 satellite assemblies, but they will be there shortly after release. This means that you’ll be able to get satellite assemblies for XAF modules and DevExpress components, used in your application. After installing them, and adding the target language with the Model Editor, you’ll see the translated values, leaving you to translate only your custom strings with the Localization Tool.
Of course, if you don’t like the supplied translations, you can modify them. 
If there are no ready-to-use XAF satellite assemblies for your language, you can create the translations with the Localization Tool. To reuse the translations in the future, you can export them to a CSV file. When localizing new applications, you can import the localization from this file. If you can send this CSV file to us, we’ll build satellite assemblies, based on your translations, and share them so that you and other customers will be able to use them in the future. How’s that for service, eh?
Note that when deploying your application, you should deploy the required satellite assemblies to the client’s machine too. When using the XCopy deployment approach, you should either put the satellite assemblies in the application folder’s subfolder (e.g. MainDemo/de), or register them in GAC.
The benefits of this new approach are:
- Standard XAF modules can be localized simply by downloading and installing the satellite assemblies from the KB article mentioned above.
- You can create the satellite assemblies for your custom XAF modules easily.
- You can add new languages to the deployed application without the necessity to recompile and reinstall it.
- You won’t experience any inconvenience due to these changes when migrating to a new XAF version, as the Project Converter will rename language-specific difference files and add the required languages to the configuration file.
Well that’s all for this post, until next time, happy XAF’ing. 