Abbrechen, Wiederholen, Ignorieren?
The English language is more compact than other European languages. This is a well-known problem for GUI designers—the translated text just does not fit, or, if layout managers are used, some dialogs look crooked.
If your applications employ custom GUI layouts crafted by a professional graphic designer, this can make things much worse than average: even with the power of many Java layout managers at your disposal, you will still have to deal with places where there were exactly 120 pixels available for a form field label, and not a pixel more. A form designed with English labels, fits English text perfectly, and Japanese was okay in most cases. As a rule, German text did not fit at all.
Figure 1. The Size of the Translated Text: Compare the original English button text and the translated ones. Japanese was ok, but I had to decrease the font size for the German text to fit the button.
In this case, translation of text strings to German required several iterations, because the first version was so large that no way to fit it into the GUI layout. With some help, German translators managed to rephrase the text, select shorter synonyms, etc. This required more time than expected, so make sure to add some extra days for this stage on your schedule.
To avoid problems of this kind, read this excellent MSDN article. It states what a developer must think about in order to make future localization easy before starting to write code and design GUI. In particular, the article contains concise, specific recommendations on text sizes and free space reservation.
Printing messages to System.out
Windows uses two codepages for each language: ANSI and OEM—except in Asian where it uses Unicode-based locales. When a non-Unicode text is rendered in a graphic context, it is assumed to be encoded as ANSI. When text is printed to the standard output or console, it is supposed to be OEM-encoded. For the English language, these codepages are identical, so an English string will look the same whether you print it to the standard output or display in a GUI control. Yet for many languages these codepages are different. So, if your app prints a Cyrillic string to the standard output and displays the same string in a MessageBox, one of them will be shown wrong.
Many Swing-based GUI applications also have a command-line interface. In the command-line mode, status messages and errors are printed to the standard output. So you need to translate messages and file names from ANSI to OEM encoding.
As far as I know, there is no Java API to translate a string from ANSI to OEM. I ended up writing a custom native method that invokes the AnsiToOEM() Win32 API function.
Note: Sun is aware of this problem, but does not think it is a big issue. See bugs 4153167, 4038677, and related for details.
| Home / Articles
/ Avoid the Lesser Known Pitfalls of Localizing Java Applications / 1 / 2 / 3 |
Next
|
New on the Java Boutique:
New Review:
Time Management Made Easy with the Quartz Enterprise Job Scheduler
Why not just use the Java timer API? This open source scheduling
API boasts simplicity, ease-of-integration, a well-rounded feature
set, and it's free!
New Applet:
Reverse Complement
Reverse Complement is a simple applet that converts DNA or RNA
sequences into three useful formats.
Elsewhere on internet.com:
WebDeveloper Java
Lots of Java information on webdeveloper.com
WDVL Java
Thorough Java resource at the Web Developer's Virtual Library.
ScriptSearch Java
Hundreds of free Java code files to download.
jGuru: Your View of the Java Universe
Customizable portal with online training, FAQs, regular news updates, and tutorials.
|
