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.

Incoming search terms: