2009-12-10
Internationalization in UI toolkits
I have some experience with many different UI toolkits. The most with Swing, QtJambi, GWT, and some with SWT and Echo2. Some of them providing you with their own i18n techniques. Let's take a closer look...
Swing is the most comfortable tookit because it gives you full Java API, with source code, possibility to dive deep into it's internals and no external libraries or dependencies. And it gives you standard Java i18n engine: ResourceBundle. It's simple, powerful and effective. And it's customizable (if you know Java of course).
Qt Jambi gives you Qt's native internationalization engine. It works in other manner than ResourceBundles. API is clean and simple, every Qt widget have method tr(String) where you can specify default value, but not the key as ResourceBundle suggested. From one point of view it's good because you're hardcoding default values, and you will be sure that on any system it will at least show default version. From the other side - those messages can take a lot of space in your source files, plus they are actually keys in internationalization files, similar to properties files. Having keys like this is not very good, because modifying single char you have to modify all resource bundles, while in ResourceBundle you can leave code "as is", modifying only value but not key.
GWT is totally different. It's using properties files too, but you have to extend Constants interface, and add all your keys as String methods to interface. As for me GWT is the total winner, because you have properties files with key-value pairs and IDE support, and you have compile-time safety because you're getting those strings from Java class. In ResourceBundle you're operating mostly with Strings, and simple typo can waste lots of your time, while using GWT approach you must ensure your keys only once, then you're totally saved from any kinds of typos using Java methods to get your internationalized messages.
No comments:
Post a Comment