Rebecca Ray and I had a chat about localization and software as a service (SaaS) products.

This had my dander up because I’ve been tangentially associated with the localization of a Salesforce.com application for the last few months, and there are some gaping holes between how you localize one and how we as an industry have come to understand localizing everything else in the world.

The industry standard, of course, is to externalize everything in need of translation so that it is not part of the code base. Anything else is what we refer to as a “giant localization leap backwards.” Once all of the bits of UI are out of code and into a resource file, we hand it off to computer-assisted translation (CAT) tools that make it easy for translators to do their work. The tools use fuzzy matching and lookups to help in translating consistently throughout the product, documentation, marketing collateral, Website, etc. The resulting translated resource files then go back into the code, and the result is a localized product.

Salesforce.com is doing something different. The bad news is that it’s annoying; the good news is that they realize it and have plans to address it.

(Disclaimer: Salesforce.com is hosting next week’s Localization Unconference in San Mateo, and I plan to attend, so I should not be a churlish guest by slanging their outrageously successful product. I shall be polite.)

Translation in the Cloud

If you use Salesforce.com, you know that you access it on the Web through a browser. It does not reside on your computer the way that, say, a copy of Microsoft Excel does. This “cloud” model is popular, and Salesforce.com is hardly alone in providing it: Intuit, Oracle, SAP, Google Docs and a jillion other vendors and packages run this way. In fact, Lionbridge wants to move the entire localization function into the cloud with its GeoWorkz initiative.

The problem is that, not only is all of your company’s data in the cloud, but everything in the user interface is, too. So, if your company developed an elaborate customization to its version of Salesforce.com’s product – as my client has – and if you suddenly needed to localize all of it, you need to translate a great many strings that reside in the cloud, and which you cannot simply spin down into a resource file and hand off to a translator.

Salesforce.com has done this deliberately. In their fervor to keep everything in the cloud, they have built and made available their Translation Workbench utility, which allows your translators – you do know who your translators are, don’t you? – to translate your customized application in the cloud.

The problem is…

It’s not the Jedi way.

When translators work in the cloud, they have no recourse to the above-described CAT tools that contribute so roundly to their ability to deliver a professional, consistent translation. It’s like “tastes great” and “less filling:” you can’t really have both, despite what the commercials would have you believe.

They need to scribble notes to themselves and remember stuff. If several of them are working on the project, they have to phone or IM one another, instead of having all the history and intelligence reside in the tools. It’s like going back to translating when all you had was a typewriter, a dictionary and a sheet of paper.

The Other Way to Localize a Salesforce.com Application

The forward-thinking localization product manager at Salesforce.com, Shawna Wolverton, is painfully aware of this problem. She told me that the company has in place a somewhat clunky procedure for exporting all translatable strings through the use of a high-end version of  Salesforce.com, the Force.com IDE, the Eclipse IDE, three forceps, a banana and a bicycle pump.

Shawna has made available a document on this procedure, titled “Localizing with the Force.com IDE.” As the document describes the procedure,

The Force.com IDE can offer great time savings by allowing you to work with your translations in XML files and use a simple interface to load the translations into Salesforce.com easily.

Even with my 10% markup, you can obtain the document for free.

The result of this procedure is that you will have XML files which your translators or language service provider can pull into CAT tools, translate and hand back to you for re-import to your application.

Shawna also tells me that they envision an even easier export-import function as an option in the main product sometime in the near future.

“What’s next, Johnny?”

I’m glad you asked.

Ten years ago, we had the same problem, except that instead of translatable content residing in the cloud, it was in our content management systems (CMS). Companies had invested mega-bundles of money to centralize documents in CMS, and people in my position felt, well, silly having to pull documents and files out of the CMS, attach them to e-mail messages or burn CDs with them, and send them to our localization partners. Silly, I say.

The vendors came to our rescue by building interfaces between their CAT tools (or the server versions thereof) and our CMS, so that they could find changed files, pull them out for handoff to translators while we slept, and check them back into the correct language branch in CMS before we knew they’d even been touched.

I have no doubt that this similar predicament will inspire vendors to enable their tools for the cloud, so that they can find your Salesforce.com application, translate the UI while you’re asleep, and let people in other countries work in their own language before you’ve had your first cup of coffee the next morning.

Ain’t technology grand?

John White of venTAJA Marketing is a localization project manager and consultant.

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“

“We are Marketing. We own the user interface.”

An engineer with one of my clients told me, with some bitterness, that a previous regime had summarized its hegemony over the company’s software product with those two sentences. I’ll grant you that it sometimes help in a company to know which lines are not to be stepped over, but I’ll also grant you that you catch more flies with honey than with vinegar.

Most of us don’t mind if Marketing dictates the user interface, unless people with our global perspective tell them that something in the UI won’t work well when the product is localized and they refuse to accept it.

In this case, the fuss is over an HTML-based UI and help system that lives in firmware in a networking device. The old Marketing guard wanted a tabbed look with labels on the tabs (Connections, Security, Setup, Help, etc.), and the tabs had to be graphics. The graphics are .gifs, nobody knows where the source files are, and we’re trying to find an expeditious way to localize the product, including the text on those tabs. (If you’re in localization and haven’t already faced this situation, I can assure you that you don’t have long to wait.)

I’ve floated some ideas by them that might result in a more flexible approach for future versions of the product. The current Marketing team is not so doctrinaire as their predecessors, but they’re not very engaged in this process, either. I offered Ockham’s razor: Let’s remove the tabs and replace them with hyperlinked text near the top of the page, and the problem will go away. They have yet to reply to that.

I’ll give them another week, then make my own arrangements. After all, “We are Localization. We own the rest of the world.”

Before you localize your software product, wouldn’t you like to have an idea of what’s going to break as a result?

If you’ve written it in English, it will surprise and alarm you to learn that that’s no assurance that it will work when the user interface (UI) is in Chinese or Arabic or maybe even Spanish. The most conspicuous vulnerabilities are:

• text swell, in which “prompt” becomes “Eingabeausforderung” in German, for example, and the 40 pixels of width you’ve reserved in the English UI results in only a small part of the German appearing;
• corrupted characters, which will show up in the UI as question marks or little black boxes because characters such as à, ü, ¿, ß, Ø and ??? aren’t in the code page or encoding under which your software is compiled;
• illegible or invalid names of files and paths, which occur when installing your software on an operating system that will handle more kinds of characters than your product will;
• crashes, which occur when your software mishandles the strange characters so badly that the program just giggles briefly and then dies;
• ethnocentric business logic, which leads to ridiculous results when users select unanticipated countries or currencies;
• hard-coded anything, whether currency symbols, standards of measurement (metric vs. English) or UI strings.

In the past, localization efforts have become stranded on these beaches late in the voyage, after the text has been translated and the binaries rebuilt. It needn’t be that way.

Internationalization testing is the process of pushing alien characters and situations down your software’s throat to see what breaks. The more complex the software, the more complex the testing, such that there are companies that specialize in internationalization as much as if not more than localization.

It’s not rocket science, but it doesn’t happen on its own, either. And, you don’t want your customers worldwide doing any more of your internationalization testing than absolutely necessary, because they really don’t appreciate buying the product and then testing it.

The process requires some cooperation between Engineering and QA, which should already be in place for the domestic product and can easily be extended to the international products as well. An upcoming post will explain some of the tools and techniques for proper internationalization testing.