How to use

Solving ASCII problems

Unfortunately, all properties files are stored with the help of ASCII format. This generates trouble for translators. If a developer wants all symbols to appear correctly, they all have to be either in ASCII format or written in the following form: \uXXX where XXX is the symbols UTF code.

How developers did it in the past

In order to convert all specific symbols to the necessary format, a developer had to use console utility native2ascii, included in JDK. He could convert it in two ways:

- By putting a text string in the utility and copy-pasting its output into the properties file
- By calling it from the console in the following format: `native2ascii source_properties_file converted_file` It is obvious, that such operation is an inconvenient one.

Another problem is that you are unable to visually find the necessary string in the text because it is written as unicode codes.

How to do it with Properties Editor (Java i18n tool)

A developer does not require any knowledge of converting rules. Just edit the table: it will always show the national locales symbols and the destination file will contain automatically converted text.

Navigating translations

When localizing your Java programs, all of your string resources are put into properties files from the source code. But navigating resources can still bring up some difficulties, e.g. a string in different languages being stored in different files.

How developers did it in the past

To fix the string, which would have an English word in Russian, for example, translation, you had to open the English properties file, find the necessary string, remember its name, and then find the string with this name in the Russian resource. After doing that you had to use the utility native2ascii to generate the string in Russian and copy-paste it into the file.

How to do it with Properties Editor (Java i18n tool)

Translations for a single string are shown as neighboring cells in a single table row. So when you find the necessary string, you will see all the translations into other languages and will be able to change one of them.

Working with multiple packages

The creation of an application usually involves its partitioning into separate logical parts packages. Each of the packages has its own properties files.

How developers did it in the past

In order to work with multiple packages a developer must have many files opened at the same time or switch between them by opening one and closing another. Of course, these operations require the usage of a file manager.

How to do it with Properties Editor (Java i18n tool)

Properties Editor shows all packages as a tree and allows you to work with them simultaneously. You can save any file whenever you want. The list of the trees files with translations is shown opposite its nodes (packages).

Communications with a translator

To get the translation in other languages, a developer has to give all string resources to a translator and then include new translation into an application.

How developers did it in the past

A developer had to give the files to a translator, who would translate those using common translation tools. Doing that a translator had to keep in mind to use same translation names in one string. After getting a translation developer had to convert each of the files using native2ascii utility.

If a developer needed to retranslate the changed strings, he had to reverse conversion of each of the files using native2ascii utility with the -reverse flag.

How to do it with Properties Editor (Java i18n tool)

Just give your translator all the files and have him install Properties Editor. Using this product a translator will use the same files (without any conversions) as a developer will. It will be a wise decision to provide your translator with an access to the version control system (SVN, CVS, etc.) for a more easy communication: in this case a developer wont have to do anything other than including new translations into an application.