Selected Customers

Buy Now

Offers are for commercial and industrial customers only.
All prices are net.

Complete Price Sheet.

Not sure which edition is the right one? Visit our Edition Comparison

Update to Version 4

Sisulizer version 4 is a paid update recommended for all Sisulizer customers.

Update to Sisulizer 4

Still using Sisulizer 3 or Sisulizer 1.x/2008/2010?

Time to update to version 4 now and profit from all new features in version 4.

Software Localization News

Version 4 Build 372 released


The new build comes with many new features. [...]

.NET Support updated


New in May 2018: [...]

Sisulizer 4 Build 366


Build 366 - support for Visual Studio 2017 [...]

10 Years Sisulizer


Celebrate and save Big. [...]

Delphi Berlin, Android, Project Merge...


Build 360 [...]

Our customers use Sisulizer...

to reach international customers with software in their language

to localize their in-house software in the international subsidiaries

to build multilingual custom software for their clients' enterprises

as Localization Service Providers because it is the localization tool of their customers

to localize software at Government Agencies

To teach software localization at Universities

for software localization on Electronic Devices

To translate software for Biomedical Hardware

to localize software in the Mining Industry

to create multilingual software for Mechanical Engineering


Visual .NET Localization (Windows Forms, WPF and Silverlight)

Sisulizer supports three different methods to localize .NET 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:

Project file localization

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 (.resources) and finally link the compiled resource files to satellite assembly files (.dll).

Sisulizer supports C#, Visual Basic and Delphi projects. Project file localization can be used if you have the full source code available and you use either Microsoft Visual Studio or Borland/CodeGear Developer Studio.

Assembly file localization

When using the assembly localization user selects an assembly file (.exe, .dll or .xap) to be localized. Sisulizer scans all the resource data from the application including XAML, form, string, icons, image and version data. On the build process Sisulizer creates the localized satellite assembly files containing localized resources.

If you localize VCL.NET applications you must use assembly localization.

Resource file localization

When using the resource file localization user selects a resource file (.xaml, .baml, .resx or .txt) to be localized. On the build process Sisulizer creates the localized resource files. Sisulizer can automatically compile the created localized resource files to compiled resource files (.resources).

Resource file localization can be used if you have the original resource files (.xaml, .baml, .resx or .txt).

Comparing different localization methods

The following table compares different localization methods.

Feature Assembly Project Resource
No .NET SDK or runtime need to be installed yes yes yes
Gets full menu structure information yes yes -
Sisulizer can run localized applications yes yes yes (.xaml only)
Creating signed satellite assembly files yes yes -
No source codes needed yes - -
Compatible to VCL applications yes - -

The following table contains the recommended localization methods.

Application type Method Notes
Windows Forms Assembly Add assembly file (.exe or .dll) into Sisulizer project.
WPF Project Add Visual Studio project file (.csproj or .vbproj) or Visual Studio solution file (.sln) into Sisulizer project.
Silverlight Assembly Add Silverlight package file (.xap) into Sisulizer project.
VCL.NET Assembly Add assembly file (.exe or .dll) into Sisulizer project. You can not use project localization.

What kind of data can be localized

.NET assemblies contains two kind of resources: managed and unmanaged. Unmanaged are the standard WIN32 resources. .NET applications usually use only icon and version typed WIN32 resources. Managed resources are the resource data that is linked inside the assembly as a managed resource data. Most .NET applications use only one type of managed resource: .resources files. They can contain form data, string data, images, etc. In addition of that it is possible to add any file as a resource to an assembly file. Some applications add XML, HTML or image data such way. Sisulizer can visually localize .resources, XML, HTML or image data. In addition of that any custom file that have been added as a resource can be localized as binary value.

Sisulizer can localize all kind of resource data of .NET assembly files. The following table tells how each resource type is handled.

Resource Type Description
.resources managed These contain either form data or resource table that contains text, images, etc. Original these files are in .resx or .txt format but .NET compiler compiles them into binary .resources format before embedding them to the assembly file.
XML managed These contain data of embedded XML files.
HTML managed These contain data of embedded HTML files.
Image managed These contain data of embedded image files.
Binary managed These contain data of all other embedded files.
Icon unmanaged This contain the icon of the application.
Version unmanaged This contain the version data of the application.

Windows Forms's Localizable property

In order to localize applications using Windows Forms you have to turn true the Localizable property of all forms and user controls.

Read more about Localizable property.

Framework and SDK requirements

Generally Sisulizer does not need .NET framework or SDK. However if you want to create localized assemblies and on certain other situations one or both are needed.


When Sisulizer creates localized satellite assembly files for a .NET project or assembly it need to use .NET framework tools. Without .NET framework tools Sisulizer can not compile resource files or create localized satellite assembly files. If you do not have .NET framework installed you can download it from Microsoft's site. If SDK is installed Sisulizer can extract complete menu and container hierarchies when localizing .NET assembly files.

SDK is installed with Microsoft Visual Studio. The following table contains the default SDK directories:

Development Tool SDK Directory Notes
Visual Studio 2005 C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0  
Visual Studio 2008 C:\Program Files\Microsoft SDKs\Windows\v6.0A  
Visual Studio 2010 C:\Program Files\Microsoft SDKs\Windows\v7.0A
C:\Program Files\Microsoft SDKs\Windows\v7.1
Comes with Visual Studio 2010
Comes with Windows SDK 7.1
Visual Studio 2012 C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A
C:\Program Files\Microsoft SDKs\Windows\v8.0A
64-bit OS
32-bit OS
Visual Studio 2013 C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A
C:\Program Files\Microsoft SDKs\Windows\v8.1A
64-bit OS
32-bit OS
Visual Studio 2015 C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A
C:\Program Files\Microsoft SDKs\Windows\v10.0A
64-bit OS
32-bit OS
Visual Studio 2017 C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A
C:\Program Files\Microsoft SDKs\Windows\v10.0A
64-bit OS
32-bit OS

If you do not have .NET SDK you can download it from Microsoft's site. By default .NET SDKs are installed to the above directories. Sisulizer automatically detects the installed SDKs. If the list does not contain your SDK click Edit and browse the SDK root directory.

Choose the Version sheet of Tools | Platforms | .NET dialog to view installed .NET runtimes and to configure SDK directories.

Importing existing translations

When you create a new Sisulizer project for your .NET project Sisulizer can automatically import existing translations. If you disabled importing during the project creating you can import the existing translations later by using the following instructions.

  • If you use Assembly or Project localization select a language column in Sisulizer translations sheet and choose Column | Import. Import Wizard appears. Select an existing satellite assembly files matching the language (e.g. de\MySample.resources.dll for German) and finnish the wizard. Sisulizer will import the translations from the satellite assembly file the your project.
  • If you use Resource localization do the same steps but instead of selecting a satellite assembly file select language related resources file (e.g. for German).

Signing assemblies with strong names

If any assembly is signed also the localized satellite assembly files must be signed with the same key. If they are not .NET runtime does not load the satelliote assembly file(s). If your have signed your assembly file with SNK file Sisulizer will automatically sign the satellite assembly files it creates. However this automatic signing work only if you use project file localization. If you use assembly file localization you have to make Sisulizer to sign satellite assembly files. To do that add key file parameter to the assembly linker parameter list.

If you use PFX key follow these instructions.

You can either write the text directly or you can right click on the edit field and choose Add key file or Add key container item from the menu.

ApplicationsCommands class

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.

Adding x:Uid attributes

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)

3rd party controls

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.


Sisulizer's NET directory contains both Windows Forms and WPF samples.