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.