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.
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
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.
this file contains the localized messages of the Wrapper binary (e.g. wrapper.exe)
The "XX" in the filenames is the abbreviation for the language (possible values for example en, ja, de, etc.).
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
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.
Since Wrapper version 3.5.38, the Wrapper will silently continue if a mo file was not found in the specified lang directory.
This is done to allow the user skipping localization by simply removing the undesired language files.
One may also want to localize only the Java application messages, or only the Wrapper messages, by keeping the appropriate language files.
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: