Lingobit Localizer - Software Localization ToolTools for software Localization DE | DA | FR | ES | IT | JA | NL | PL | PT | RU | TR | ZH
Software Localization

Lingobit Home > Solutions

.NET Localization

.NET Software localization toolLingobit Localizer is an ideal software localization tool for .NET Framework applications, aimed to make collaboration with external translators smooth and efficient.

Currenty, Lingobit Localizer supports .NET 1.0, 1.1, 2.0, 3.0, 3.5 and 4.0 versions.From now on, no source-code is required and all technical details are hidden behind intuitive and easy to learn interface. State of the art automated tools for QA, translation reuse and project management guarantee high productivity and outstanding quality. Lingobit Localizer radically simplifies software translation, inspiring even small businesses and individuals to localize their applications.

Using Lingobit Localizer

Lingobit extracts all localizable resources such as strings, menus and forms directly from assembly file (*.exe, *.dll) and presents them in productive translation environment with such features as translation reuse between versions, automatic validation for common translation errors, exchange wizard for easy collaboration between translator and manager.

After you translate resources, Lingobit Localizer creates satellite assemblies and places them in directories with language code names (for example, en-gb is English – Great Britain). This is a default location for satellite assemblies used in Microsoft .NET Framework. It automatically locates resources in those directories and selects appropriate using language settings.

.Net satellite assembly localization

Satellite assemblies

Satellite assemblies is the default way to localize .NET applications. To make form localizable set form's Localizable property to true. You can do it using Properties Window in Visual Studio. All hardcoded strings could be extracted to assemblies using Lingobit Extractor. It performs about 95% of the work by extracting strings to resources and replacing them with resource loading code.

Main assembly stores resources for neutral culture. If .NET can't find localized resources for current language in satellite assembly, it will load resource for neutral culture. You can read more details about fallback and resource structure at

When you add main assembly into Lingobit Localizer project, localization tool will parse all resources from the file. Then Lingobit Localizer will look for satellite assembly for language that is set as Original in Lingobit project. After it software will created joined set of resources. It allows to localize applications with neutral resources that are moved to separate assembly. Such approach is recommended by MSDN for WPF localization

How .NET selects what language to use for localized application

When you run your localized .NET application Resource Manager checks System.Threading.Thread.CurrentUICulture property for each thread and loads appropriate resources. By default CurrentUICulture property is determined by Windows display lauguage settings. You can change it at Control Panel > Region and Language > Display Language. You can specify language for your thread or use the same culture as specified in Control Panel:

Use Windows settings

Thread::CurrentThread->CurrentUICulture =

Manually select language

CultureInfo ci = new CultureInfo("en-gb");
Thread.CurrentThread.CurrentUICulture = ci;

How to localize signed or strong-named assemblies

Assembly signing (also called strong-name signing) gives an application or component a unique identity that other software can use to identify and refer explicitly to it. A strong name consists of its simple text name, version number, culture information (if provided), plus a public/private key pair. This information is stored in a key file.

If your main assembly is signed you need to sign localized assemblies also. You can do it in Lingobit Locazer at Properties > .NET > Satellite Assebly Output. Both types of key files are supported .snk (without password) and .pfx (with password).

An organization can have a closely guarded key pair that developers do not have access to on a daily basis. In that case you can use Delay Signing. You can read about it at Delay signing is activated by default if you are localizing signed assebmly and key file is not set.

For testing of delay signed assembly you need to switch off key verifycation. You can do it using Strong Name Tool that is distributed with .NET. You can read more about at

sn.exe –Vr myAssembly.dll

If you didn't switch off verifycation, your delay signed satellite assemblies will not be loaded.

Referenced assemblies

.NET localization may require loading of referenced assemblies, because they could store a lot of important information, especially when you use 3rd party controls.

Lingobit Localizer requires loading of original and referenced assemblies in the following situations:

  • Parsing, scan for changes, and create localized
  • Form preview in Reflection Based Mode
  • WPF preview

Lingobit Localizer searches for refereced assemblies in

  • Global cache
  • Folders that are listed in AssemblyFolder and AssemblyFoldersEx registry keys
  • Main assembly folder
  • Folders listed at Project > Properties > .NET > Reference Resolver

.NET localization platforms

.NET Framework has several technologies that use slightly different approaches for localization. Please select the one you need

More information about Lingobit Localizer