Software internationalization - the hidden suspects

This is pretty old software. We've been working on it for over five years, and it's not very complex to begin with: a few standalone Win32 applications in the normal .exe-calls-resource-DLL model.

Localization practices and internationalization techniques are mostly behind us. Several years ago, at the behest of the vendor, we managed to convince the developers to modify the layout and controls in all of the UI so that no resizing would be necessary from one language to the next. That was the biggest thing to get out of the way, as it ate up precious hours between translation and successful build. The problem has to do with the coming and going of developers who weren't there a few years ago, and who move things around and resize them in the English UI. Localization headaches ensue.

I'm not sure, but I think the move from Visual Studio 6 to Visual Studio .NET has played a disruptive role. There's no inherent reason for that architecture change to cause resizing of controls or changes in coordinates, but it is mucking about with other non-translatables, like

1 TEXTINCLUDE DISCARDABLE

changing to

1 TEXTINCLUDE

or

STYLE DS_MODALFRAME | WS_POPUP |

changing to

STYLE DS_SETFONT | DS_MODALFRAME | WS_POPUP

There's certainly nothing to translate here, but these count as changes in the source-language files that should be preserved in the target-language files. It's hard to do this sort of thing without some kind of Computer-Aided Translation (CAT) tool or at least text-manipulation utility.

So, I reckon we hand it off for localization engineering, if not translation. The engineers will jack up the translation, slide out the old architecture as if it were HTML or XML tags, slide in the new architecture, and push the translated strings back down into place.