Ok, maybe I was to quick to judge, I didn't spend enough time studying it. I looked at some screen shots, and it seemed like the translation tool knew things about the app, but I was apparently mistaken. Sorry.
The tool loads a directory of xml files; each file is rendered as a tab in the translation GUI. The framework exports the strings from each SWF form as a separate xml file into a directory that matches the native locale’s identifier (eg en-US) and gives it a friendly name based off the form’s title/caption and/or file name. So the end result is a naturally user-friendly approach to translation instead of having all the apps strings dumped together into one PO file as is the norm, and translators can reference the app they are translating’s UI as they methodically translate a component at a time.
The tool loads a directory of xml files; each file is rendered as a tab in the translation GUI. The framework exports the strings from each SWF form as a separate xml file into a directory that matches the native locale’s identifier (eg en-US) and gives it a friendly name based off the form’s title/caption and/or file name. So the end result is a naturally user-friendly approach to translation instead of having all the apps strings dumped together into one PO file as is the norm, and translators can reference the app they are translating’s UI as they methodically translate a component at a time.