Note! WPF is supported only in the beta build of Sisulizer.
Before reading this read general information about .NET localization.
Sisulizer supports three different methods to localize WPF (Windows Presentation Foundation) applications. The methods are:
Each method has it advantages and disadvantages. You must choose the method that best suits your needs.
In addition of localization methods this topic contains information about the following issues:
This article is about WPF localization. Information about Windows Forms (WinForms) localization can be found here.
When using the assembly localization method user selects an assembly file (.exe or .dll) to be localized. Sisulizer scans all the resource data from the application including XAML (stored in BAML, binary XAML), string, icons, image and version data. On the build process Sisulizer creates the localized satellite assembly files containing localized resources.
When using the project localization user selects a project file (.csproj, vbproj, .bdsproj) or solution file (.sln) of the application to be localized. Sisulizer reads the project file(s) to find out the resource files (.xaml, .resx or .txt) that need to be localized. On the build process Sisulizer creates the localized resource files. Sisulizer can automatically compile the created localized resource files into compiled resource files (.baml or .resources) and finally link the compiled resource files to satellite assembly files (.dll).
Sisulizer supports C# and Visual Basic projects. Project file localization can be used if you have the full source code available and you use Microsoft Visual Studio.
When using the XAML file localization user selects an XAML file (.xaml) to be localized. On the build process Sisulizer creates the localized XAML files.
XAML file localization can be used if you have the original XAML files (.xaml).
The following table compares different localization methods.
| Feature | Assembly | Project | XAML |
|---|---|---|---|
| No .NET SDK or runtime need to be installed | yes |
yes |
yes |
| Sisulizer can run localized applications | yes |
yes |
yes (shows localized .xaml files) |
| Creating signed satellite assembly files | yes |
yes | - |
| No source codes needed | yes |
- | - |
Our recommendation is to use either the project file or assembly file localization.
WPF library contains some predefined commands. They are defined in ApplicationCommands class. These command contain some user interface strings such as command's label. These are the strings to be show in the menu items. If you use command's of ApplicationCommands the strings won't stored anywhere in your project or assembly file but are stored in the frameworks assembly files. This is why the strings do not appear to Sisulizer project either.
The best way to localize the menus and toolbars using these commands is to add the header attribute to the item. This makes framework to use the text of in the attribute instead of the default string in the command. The string will also appear to Sisulizer project so it can be localized. For example if you have following XAML line:
<MenuItem x:Uid="newMenu" Command="ApplicationCommands.New"/>
Add Header attribute into it:
<MenuItem x:Uid="newMenu" Header="_New" Command="ApplicationCommands.New"/>
After this the menu item can be localized.
When Sisulizer scans XAML data (either .xaml file or BAML resource inside assembly file) it needs a context information for each component. To get this context information Sisulizer looks for special name/context attributes that contain the name of the control. There are three possible attributes: x:Uid, x:Name and Name. If your XAML data does not contain name attributes Sisulizer will write the following hint to the log file:
21:02:46 Hint fileName.MenuItem[2] component has no name. It is recommended to give a name using either Name, x:Name or x:Uid attribute.
To give a property content information for a component add one of the above context attributes and give a unique value to it. You can automate this process by using MsBuild tool. Use the following command line:
msbuild /t:updateuid myproject.csproj
MsBuild tool can be found from .NET framework directory (e.g. C:\Windows\Microsoft.NET\Framework\v3.5\MsBuild.exe)
WPF resource file, XAML files (.xaml), do not contain type information of the properties or does not even contain information if the element is property of event. This sets some difficulties for localizations. Without type information Sisulizer can not figure out if data is property or event and if property what is the type. In general you want to scan most string data but only certain integer data (e.g. Left, Top). Scanning of integer data is hard coded to Sisulizer and it can property scan layout of all component including 3rd party components. The problem appears when scanning a 3rd party control that is not know by Sisulizer. Without type information Sisulizer can not figure out what custom properties are string typed and what are not. This is why it can just not scan all unknown properties. That would make it to scan all other data type and events too. For all other modern resources types such as VCL's .dfm or WinForms's .resx contain type information. For these platforms Sisulizer can safely scan all string properties without getting huge amount of unnecessary rows. If you want to exclude scanning of a property you can easily exclude it. This same approach does not work for XAML because Sisulizer would scan basically all data including events names. This is why in WPF Sisulizer only scan the known properties such as Text, Left, Top, Background, etc. Sisulizer team has tested all standard WPF controls and all properties of them that are needed to be scanned are scanned. If you use 3rd party WPF controls you have to add the "custom properties" to the included property list in the component mapping.