This page has been archived and is no longer updated.

We do not supply this product anymore.


Software localization add-in for Visual Studio.

Published by Neovelop

About NLocalize

Software localization add-in for Visual Studio.

NLocalize is a Visual Studio 2010 plug-in that helps developers localize WPF applications. NLocalize automates many localization tasks including UID generation, text string discovery, text exporting for translation and UI adjustments in other languages. NLocalize uses the WPF localization API (BamlLocalizer) for localization of Windows Presentation Foundation applications. It automates all changes so that applications can be localized via this API.

NLocalize Features

  • Visual Studio 2010 Integration - All localization related settings are stored directly as part of your Visual Studio project. Resources created with NLocalize can also be easily be stored in your version control system.
  • Visual Localization - NLocalize supports a more accurate visual preview of complex WPF user interfaces.
  • Agile Development - Because NLocalize works on your Visual Studio solution and not compiled .exes and dlls you can localize in parallel with your development. This helps you to detect localizability problems early and reduces the time-to-market of the localized versions of your applications.
  • Customizable - Add support for additional resource file formats or translation memories.
  • Easy to Use - NLocaliize won't confront you with dozens of toolbars and icons or complicated configuration dialogs. NLocalize has a simple user interface that is easy to use. This allows you to start localizing your applications faster.

Localization of WPF applications
When compiling applications WPF XAML files are compiled in a binary format (BAML). In a monolingual application BAML files are directly integrated as resources into the main assembly (.Exe or .Dll file) of the application. When localizing WPF applications using the method recommended by Microsoft, its own BAML files are generated for each language containing the translations and other adaptations for the target language. Instead of placing the BAML files in the main assembly, they are written for each language in its own assembly (called a satellite assembly). If the application is started and tries to load BAML files, they are loaded automatically from the satellite assembly of the language, in which the application is running. Microsoft Visual Studio and Microsoft Expression Blend, however, offer no support for the creation of such localized BAML files. Microsoft only provides classes (in the namespace System.Markup.Localizer) with which localization tools such as NLocalize can create such localized BAML files. NLocalize uses these classes to generate localized BAML files.

How will NLocalize modify your projects?
Each element in an XAML file needs a unique ID for localization. This ID is defined by the x:Uid attribute. The .NET Framework includes the MSBuild task “updateuid” that automatically generates x:Uid attributes for all XAML files of a project. NLocalize integrates this MSBuild task into your project, so that all elements in the XAML files in your project automatically receive the x:Uid attributes when translating the project. The main language of your project will be entered in the form of a UICulture entry in the project file. In addition, the neutral resources language attribute is entered in the AssemblyInfo.cs /.vb file. This element determines the language of the “neutral” culture of the assembly. It is also determines whether neutral resources have to be loaded from the main assembly or a satellite assembly. NLocalize stores its own settings such as the list of target languages in the project file of each localized project also.

The NLocalize Build Task
NLocalize itself is integrated by a MSBuild task in the build process. This task is performed for each translation project. The NLocalize build task performs the following actions on every build of your projects:

  • For each target language a resource file is created for each XAML file in the project, if such a resource file does not already exist.
  • The resource file is compared to the XAML file. Changes to the XAML file, for example newly created elements are included in the resource files.
  • One localized BAML file is generated for each XAML file and each target language.

The build process creates a separate satellite assembly for each target language that contains all the BAML files of this language and any other language-specific resources of the project (e.g. Resx files). For that NLocalize enters the NLocalize generated BAML files into a list of files which should be generated into satellite assemblies by the regular build process. The satellite assemblies with localized BAML files are not generated by NLocalize itself, but by the "regular" build process of Visual Studio. Consequently there are no problems with other resources that could be copied by Visual Studio into the satellite assembly. The satellite assembly can also easily be provided with a strong name and signed.