Taming Localization Resources

I have been working in the “legacy” portion of an application lately. It is state-of-the-art Java Struts from 2000. In their zeal to separate logic and presentation, Sun made it fairly difficult to trace out the origins of specific elements on a web page back to code in the project.

Its not that hard to find all the localization bundles that need updating using a search tool, but testing that everything got translated and put in place is going to be tough for QA and bug fixing.

Problem: .properties files are used for localization strings but also for lots of other things in Java. How do I find just the localization ones? Nobody thought to include a marker comment like #l18n in files that require translation.

Solution: manually check the files and update a perl script with filenames and directory names to skip. Later, write a perl script to add the comment marker to each valid string resource .property file.

Problem: I found all the localization strings, now how do I know which ones have to be updated? How many revisions do I have to go back to get all the changes needed without paying for translating strings that were already done last time?

Solution: If someone had thought to add a comment to the Perl script that gathers the properties deltas with the SVN revision, I would have just done a diff to that – easy. I made that my final step. But what I did was check the translated files for revision numbers and then compare them to the revision numbers of the English source. This allowed me to account for  potential changes that may have been added when the last batch of resources were still being translated.

Key Learning: The automation of the Perl script to gather the properties and then run a diff back to an earlier commit was a timesaver, but not a replacement for manual inspection and checking of the resources. I found some properties that had never been translated and never came up as a bug in the software. I avoided getting system properties needlessly translated.