This is a recording of the webcast on Titanium for New developers ( a high level overview of Titanium architecture), hosted by Kevin Whinnery at Appcelerator Inc.
This webcast was broadcast on 5th Jan 2011, 9am PST.
In Java, Internationalization of applications is supported through the ResourceBundle class. The strings which need to be translated are packaged in individual resource bundles and each language will have its own resource bundle which is loaded by the ResourceBundle Class based on the application logic.
I was involved in the modification of the Java ResourceBundle class to make it optionally decorate all the strings coming from any specific resource bundle with certain special characters like {{ or [[ so that it will be possible to visually identify any hard coded strings in the application. My role in this project was to specifically hack the XliffResourceBundle class which decorates the strings from Xliff resource bundle files. The decoration process had to be turned off or on by the user and had to obey certain rules/filters which allows the user to decorate specific strings (exclude any numbers/dates etc).
As all strings which support internationalization typically use the resource bundle class to fetch the translated strings, modifying the class itself at the root level will help one to indentify the ones which are not using this class (and hence hardcoded).
But one might ask “why not write a tool to scan through hardcoded strings using regex”. Yes , you could do this, but there are cases where this method wont be sufficient. The strings could still be following your regex pattern and might not be using the resourcebundle class to fetch the translated strings. Only modifying resource nundle class can provide a foolproof way to identify them.
Why ?
Identifying hardcoded strings is very much necessary for any software application which has to be internationalized. Especially when the software is used all over the world. Typically Arab speaking and Chinese users contribute to a major percentage of profits and they prefer localized versions of the user interface. Localizing the UI after a software has become successful will take minimal effort and the results of such a move are quite astounding.
But usually during inital phases of development, no developer will give much importance to externalizing string and coding in a way that makes localization of each UI easier. The tendency is to concentrate on the functionality of the software and make things work well. The problem comes when the functionality breaks during the localiztion process. Also from the profits point of view, localizing the software becomes important. But to the developer, who feels that putting additional efforts to just make the software work under different locales and obey the rules of different regions in showing the dates/currency and timezone implications , it is something of least interest. They are the developers who just copy past code samples from the internet and never give importance to how things work. Such negligence gives rise to performance issues too. But internationalizing existing programs also become difficult is this is the case.
Google latitude is a great way to share your current GPS location with everyone. You can put up the google location badge on your blog and let the world know your exact geographical location.
But the latitude badge does not provide the exact address of your current location in terms of the area names but shows the exact location on the map. Google latitude badge shows only city level address along with the map. So I decided to write my own small PHP script to print out the exact address instead of an approximate one which is shown by default. You could use this code coupled with XMPP integration to show it as you google talk status message (a tutorial and script for this..sometime later)