Deploying Localized Applications

From RAD Studio
Jump to: navigation, search

Go Up to Creating International Applications Index

The article describes the necessary steps you must take in order to properly deploy your localized application. It is important you do understand how the language selection works and in which order the localized resource DLLs will be selected.

Deploying the Executable and Resource Modules

The deployment process of a localized application involves more steps than for a simple application. In your project you have created a number of localized resource DLLs that must be distributed alongside your application executable. For example, consider that you have an application with the Test.exe executable file. Let us assume you localized this application into two other languages (aside from the default one): fr-FR and de-DE. To make sure your application will use the proper localized versions of the UI on the client machine, you must bundle the localized resource DLLs in the same directory in which the executable file resides. For example, the installed application directory can contain these files:

C:\Program Files\Test\Test.exe
C:\Program Files\Test\
C:\Program Files\Test\

There are possible scenarios, but bundling the localized resource modules alongside your main executable is the simplest way.

Language resource DLL selection order

An application developed with RAD Studio IDE can define multiple languages for its user interface. User interface resources for each language are deployed within a specific resource DLL file. Upon initialization, the application selects the most appropriate language for its user interface elements. This process is carried out automatically before any interaction with the user happens. The application's user interface language is selected based on a detected available localized resource DLL.

To find the localized resource DLL, the application first obtains the preferred language name list. Using this list, the application having the Test.exe executable file attempts to find the localized resource DLL having one of the following extensions:

  1. "Locale override" key. The application checks the Windows registry keys to find whether a "locale override" key has been defined. The following Windows registry keys are verified in the descending priority:
    1. HKEY_CURRENT_USER\Software\Embarcadero\Locales
    2. HKEY_LOCAL_MACHINE\Software\Embarcadero\Locales

A "locale override" is a registry key value that explicitly tells the application (specified in the key value) which locale identification code or language culture name to use.

A "locale override" value should contain:

  • The Name string identifying the fully qualified path to the application executable file. (The fully qualified path to your Test.exe file.)
  • The Data string identifying the locale identification code or language culture name to use. For example, for "German - Germany" locale it can be DEU.

If no Data value is found, the default locale is queried.

  1. Language Culture Name. Language Culture Names have the following format: AB-CD, where AB represents the language code and CD represents the region code. The application will search for files with the AB-CD filename extensions.
  2. Language Code. The application will search for files with extensions equal to two-letter AB language codes.
  3. Three-letter Language Code. Three-letter Language Codes are EFG ISO 639x Values. The application will search for files with the EFG filename extensions.
  4. Two-letter Language Code. Two-letter Language Codes are the first two letters EF of the Three-letter Language Codes ISO 639x Values. The application will search for files with the EF filename extensions.

For example, suppose that UILocale is set to German - Germany and the "locale override" key for Test.exe has the Data value equal to XYZ. Then on startup, the Test.EXE application will search for the following files in the directory from which Test.EXE runs:


If the application finds the localized resource DLL file at one of these steps, the search stops and the application loads the found resource DLL.

If none of the steps above results in a valid localized resource DLL selection, the application simply falls back to the default language it was designed for (usually the language of resources built into your application executable file directly).

See Also