World Map
Java Service Wrapper is the easiest way to make your product more reliable.
  • Free Trial
  • Buy Now
Internationalization / Localization

Internationalization / Localization

Starting with Wrapper version 3.5.0, the code base has been internationalized and is able to run localized. Initially the available languages are English and Japanese, but we hope to provide gradually more and more localizations.

Localization Files

The Wrapper will load the Localizations file on startup, depending on the language of the OS. It is also possible to load a language explicitly specified in the wrapper.lang property. If the Wrapper is not supporting a language, i.e. the localization files were not found, the Wrapper will try to fall back, first, to the OS language, if this is also is failing, subsequently it will fall back to English.

In order to be able to run the Wrapper fully localized 2 resource files are necessary: The files are located in the [wrapper]\lang directory.

  • "" file:

    this file contains the localized messages of the Wrapper binary (e.g. wrapper.exe)

  • "" file:

    this file contains the localized messages of the Wrapper library (e.g. wrapper.dll) and the Java API of the Wrapper (e.g. wrapper.jar)

The "XX" in the filenames is the abbreviation for the language (possible values for example en, ja, de, etc.).

"" file:

Besides the wrapper_XX and wrapperjni_XX resource files, you might notice that there is a 3rd mo file called This file contains the localized messages for the TestWrapper Example Application & DemoApp Application. This file is not necessary if you are running your own Applications with the Wrapper, and therefore is safe to remove on deploy. The TestWrapper & DemoApp applications make use of the WrapperResources class. This API is public and can be used for any Java Application. For more information on how to use the Wrapper to localize your Java Application, please have a look at "Localization API" page.

Encode in Configuration Files

After the Wrapper being internationalized it is running internally in UNICODE, however on reading the configuration file, it needs information on how the non-ASCII characters in the configuration file are encoded. This declaration has to be in the first line of the configuration file.

Example: (Setting the configuration file encoding to UTF-8)
# Configuration files must begin with a line specifying the encoding
#  of the file.

So far the supported encodings for the configuration file are:


If the #encoding header has not been defined, the Wrapper will not try to convert any characters and read the configuration file in the current system encoding, the Wrapper is being run.