Giant Localization Leap Backwards

"All of the strings are embedded in the code."

There was a time when I welcomed - or at least was not very much surprised by - sentences like this one. They came from engineers in response to my questions about the readiness of their software strings to be localized. Strings embedded in code, of course, are more or less inaccessible to localization techniques, since nobody wants to hand off an entire code base to a translator, and no translator wants to wade through an entire code base trying to find strings to translate.

So, when one of my client's engineers said it to me yesterday in reference to an application in a larger product we plan to localize, I briefly welcomed it. It means more work.

But then I realized that combing all of the strings out of the code and into separate, accessible files will require a great deal of time and effort (not mine). Engineers don't usually enjoy working on this kind of task, so it will fall to the bottom of the priority stack, and the product manager won't go to bat for it, and so this particular application will stick out like a sore thumb as a non-localized component in an otherwise localized product suite.

"Is there a phased approach we could take to enabling this app for localization?" the engineer asked.

I appreciated his attempt to save the game, but a partially localized product is rather ugly. We could enable and translate the menu and dialog strings for this release, and go back for the error messages in the next release, but the mongrel product is not very appealing to users in the meantime.

This is disappointing, because we've made such long localization-strides elsewhere in the product suite, and dealing with this newly acquired app feels like such a giant leap backwards. I guess I'll work up some estimates on the time required to enable the application, then make my case to the product manager and development lead to generate some interest and start the process from the beginning.

Isn't that why we localization project managers and international product managers were sent here?

What do you do in your company when engineers tell you that all the strings are embedded in the code?

Keeping an eye on Catalyst

In localization, "Catalyst" is a tool from Alchemy Software. Among other things, it allows you to localize UI elements within software resource files, sometimes without the need to rebuild the software manually into binary format.

Since software binaries come from text files, part of Catalyst's value lies in straddling the divide between allowing the translator to change strings in the these text files (say, from English to Japanese) and displaying them in the binary, run-time format in which the user will see them on screen.

Last month a vendor returned some resource files to me which we had them localize from English to Japanese. I rebuilt the binaries (language-resource DLLs) and ran them. Unfortunately, a number of items were suddenly missing from the Japanese menus, so I had to troubleshoot the problem.

My first thought was that either a person or a tool (or a person using a tool) had modified something that should not be affected by the localization process. I had handed off a resource file containing these lines:

32777 MENU DISCARDABLE
BEGIN
POPUP "&Tools"
BEGIN
MENUITEM "Serial P&ort Settings...", ID_TOOLS_SERIALPORTSETTINGS
MENUITEM "&Network Settings...", ID_TOOLS_NETWORK
MENUITEM "&Battery Settings...", ID_TOOLS_BATTERYSETTINGS
END
END

32779 MENU DISCARDABLE
BEGIN
POPUP "&File"
END


They returned to me a resource file containing these strings:

9 MENU DISCARDABLE
BEGIN
POPUP "ツール(&T)"
BEGIN
MENUITEM "シリアルポートの設定(&O)...", ID_TOOLS_SERIALPORTSETTINGS
MENUITEM "ネットワーク設定(&N)...", ID_TOOLS_NETWORK
MENUITEM "バッテリの設定(&B)...", ID_TOOLS_BATTERYSETTINGS
END
END

11 MENU DISCARDABLE
BEGIN
POPUP "ファイル(&F)"
END

There was nothing wrong with the translation, and the string IDs were intact. The product has long been "double-byte clean," so I knew that the software was not gagging on the Japanese characters.

The problem lay in the menu ID numbers, which are 32777 and 32779 in the English, but which came back in the Japanese files as 9 and 11. The vendor believes that Catalyst changed them, since they had used it to for resizing and QA.

Normally, this renumbering has no effect on how the binary functions. In this case, however, it has a profound effect on how the binary functions, because there is code somewhere in the software that is looking for "32777" and "32779" and when it doesn't find those ID's, it cannot complete the menu. This is poor internationalization in the code base which I have discussed with Engineering, to no avail, so I need to police the resource files in each round of localization.

How is Catalyst working for you? Have you seen similar problems?

Interested in this topic? You might enjoy another article I've written called "Localized Binaries - The Plot Thickens"

Localization in the news

Have you ever stumbled onto something in the course of localizing a product that was private, or maybe even a bit compromising? Here's a news item from telecoms.com that falls into that category:

This time round, Apple is supposedly prepping its iPhone to be a portable gaming machine, wading into a market already dominated by the likes of Nintendo and, to a lesser degree, Sony.

Although the 'official' iPhone applications market is noticeably void of any games at the moment - mainly due to the fact that Apple has banned third party apps from running natively on the device - some hackers claim to have found tell tale signs that games are indeed on the way.

Apparently, the iTunes localisation code makes some reference to a string asking the user if they want to remove the games in question. Naturally, this gave way to rumours that Apple has had a games developer partner lined up for some time and plans to offer gaming products via iTunes. [emphasis mine]

Some alert hacker (or maybe even a translator) must have lobbed a note about this string into the blogosphere, or otherwise publicly asked the question, "Why would they want to remove games?"

Who says there's nothing proprietary or confidential in software resource files?

Pulling the rug out from under the Localization Manager

It's a thrill for the gearhead in me to build my own localized binaries.

Most projects in the wide world don't require this of the localization manager, of course. A staff engineer, or at least a release engineer, is usually tasked with building the binaries that house the localized software resources. There's some delay involved in that, though, since the engineers don't often place very high priority on building these infernal things, let alone building them as often as the localization QA cycles require.

The localizers are able to preview the localized resources in their localization environment (Alchemy, Visual Studio, etc.), but our engineers have an arcane build environment and procedure that I don't care to impose on even my least liked localization vendor, simply because it's an open invitation to failure. Instead, I persuaded the engineer who created the entire scheme to spend three hours duplicating the environment with me so that I could document it and reproduce it on a quick turnaround.

"Why are you going to all this trouble?" the engineer asked me.

"I'm trying to drive you crazy this one time so that I don't drive you crazy eight or nine times over the next few weeks. The translators will find new things to change as they continue localizing the rest of the product, and they'll change the resource files. If I have to bug you with each one of these changes, you may come to view localization as something, well, inconvenient."

"Good. Thanks for sparing me that."

That was for version 2.0.0 of this software. I was able to save precious days by doing my own builds and turning the binaries around to the localizers promptly. I also saved myself all of the credibility and Brownie points I'd have had to mortgage by running to the engineers all the time.

Now that we're localizing version 2.0.1, however, the procedure is changed. The engineers have pulled the rug out from under me, and nothing that used to work, works. Time to bug the engineer again and get the updated Rosetta Stone so that I can build these things.

Localization-surfing InstallShield

I like the way in which InstallShield does what it does. It's too bad they won't give me my own copy of the software, though.

It took me several iterations, but I've successfully navigated the areas in the InstallShield UI that do and do not support wide characters. (I thought there was a time when I could put anything anywhere and have it display properly, but suddenly I was getting corrupted characters in some screens in Asian installers. So much for the ailing memory of the noble localization project manager...)

TITLE_MAIN=Glopware v3.0.1 Ko main (ASCII only)

TITLE_CAPTIONBAR=Glopware v3.0.1 설정 caption

COMPANY_NAME=GlopWeb Inc.

PRODUCT_NAME=Glopware v3.0.1 Ko prodname

PRODUCT_KEY=Glopstart.exe (ASCII only)

PRODUCT_VERSION=3.0.1.12

FOLDER_NAME=Glopware v3.0.1 한국어 folder

PRODUCT_DIR=GlopWeb 3.0.1 Ko proddir (ASCII only)

Your mileage may certainly vary, but I found that, anytime we used double-byte characters in the strings labeled "(ASCII only)", they became corrupted. My hunch is that there's some other variable or setting required to support such characters in those places, but I figured I could give the release engineers only so much grief before I suffered backlash.

If you're a double-byte InstallShield expert, by all means reply with the better localization way.