 |
Solving ASCII problems |
Unfortunally, all properties-files are stored with using ASCII format. It makes some troubles to translators.
If developer wants all symbols to be shown correctly, they all have to be in ASCII format or be written in form:
\uXXX
where XXX - symbol's UTF code.
| How did developers do it in the past |
|
How to do it with Properties Editor (Java i18n tool) |
To convert all specific symbols to necessary format, developer had to use console utility `native2ascii`, included in JDK. He was able to convert it in two ways:
- By entering text string to the utility and copy/pasting its output into properties-file
- Calling it from console in format:
`native2ascii source_properties_file converted_file`
It is obvious, that it is uncomfortable operation. And it is something more uncomfortable because you will be unable to find visually necessary string in the text: it is written in unicode codes. |
|
Developer have not to now anything about converting rules.
Just edit the table: it always shows national locales symbols, but destination file will contain automatically converted text. |
|
 |
Translations navigation |
While you are localizing your Java programms, all of your string resourses are placed into properties-files out of the source code. But still navigation by resources can cause some difficulties: string for differend languages stored in different files.
| How did developers do it in the past |
|
How to do it with Properties Editor (Java i18n tool) |
To fix the string with english word in the russian (for example) translation, you were to open english properties-file, find the necessary string, remember its name, find the string with this name in the russian resource. After doing that you were to use utility `native2ascii` to generate string for russian language and copy it to the file.
|
|
Translations for one string are shown as neighboor cells from one table row. So when you will find necessary string, you will see all translations to another languages and will be able to change one of them. |
|
 |
Working with multiple packages |
Usually creating serious applications never goes without its partitioning to separate logical parts - packages. Each of packages has its own properties-files.
| How did developers do it in the past |
|
How to do it with Properties Editor (Java i18n tool) |
To work with multiple pachages developer is to open many files in one time or switch between them by opening and closing ones. Of course it needs using a file manager doing this operations. |
|
Properties Editor shows all packages as tree and allows you to work with them at the same time. You can save any file when you want it. Opposite the nodes (packages) of tree the number of its files with translations is shown. |
|
 |
Communications with a translator |
To get the translation to new languages, developer must give all string resources to a translator and than include new translation to an application.
| How did developers do it in the past |
|
How to do it with Properties Editor (Java i18n tool) |
Developer had to give files to a translator, who will translate them using usual tools. Doing that translator had to know about putting equal names to translations of one string. After getting a translation developer had to convert each of files using `native2ascii` utility.
If developer was needed in retranslating changed strings, he had to revert conversion of each of the files using `native2ascii` utility with `-reverse` flag. |
|
Just give to the translator all files and install him Properties Editor. Using this product translator will use the same files (without any convertions) as developer will. It will be good decision to let translator to access version contol system (SVN, CVS, etc.) for more easy communications: in this case developer will need to do nothing befor including new translations into an application. |
|