When I started working in a startup company as a technical writer, little did I know that in a few short years I would be managing software localizers working on three continents. What I learned in that role makes for an interesting tale and might be helpful to someone in a similar situation. If you are currently working in a startup, or hope to do so one day, please let me share a few things that might be useful to you. MultiLingual‘s issue on startups just went live, so you can check that out as well.

A bit about the company

The company was a survivor of the dot-com bust. Its flagship product was a web-based e-procurement product. There were two kinds of customers — individual corporations and e-commerce exchange sites. The large corporations would install the product on their own servers, and allow their suppliers to respond to request for proposals (RFPs) or participate in reverse auctions — auctions where suppliers tried to secure sales by lowering their prices in competition against other suppliers. The e-commerce exchanges would allow their own customers to do the same on systems that they (the exchanges) maintained.

In the early years, all the customers were based in the United States. The development team was aware that internationalizing the product would be a good idea, but this was certainly not a priority. In the first months of the company’s existence it, after all, was easy to understand why. The technology was new, not widely understood and the payoff from a significant investment was uncertain.

That all changed, of course, once one customer — an e-commerce exchange for mining and oil companies — was eager to pay for user interfaces in Portuguese and Spanish. Internationalization and translation were suddenly spoken of in almost reverent tones by everyone. Around this time, I became involved in the effort, probably because the online help was by far the largest chunk of text requiring translation.

Internationalization issues

While the initial internationalization proceeded smoothly, this simple coding requirement became the source of problems as the product evolved and the code base grew. Sometimes junior engineers or contract employees would forget to externalize strings in this or that module. Errors like these usually led to a reprimand and to reminders that all functionality would eventually be translated.

While these minor mishaps were perhaps excusable in less experienced coders working to meet tight deadlines, that was not the case for other offenses. The most grievous sin against internationalization, for example, was committed by a senior consultant. An audit revealed that he had left over 2,000 error messages embedded in the code. This caused significant delays in translating and testing the product.

No text in image files

One of the mistakes that we made early on was to use literally hundreds of PNG files in the product. At that time, the web was so new that the idea of graphics inserted between text or overlaying text seemed like a great idea. While this strategy made for some attractive web pages, it became a huge burden once we began translating the product.

Fortunately, after one or two rounds of translation, the illustrator found a way to automate the creation of the localized images. Later on, the development team worked to remove text entirely from images and enter it in resource files. While exceptions to this rule were sometimes made in response to a customer request, it was largely respected and helped reduced translation costs.

Customer-specific translations

Even when every string was properly externalized, translated and delivered, it sometimes happened that a customer would want to change previously approved translations for one reason or another. Originally, this was seen as a software problem. A bug report was filed by a field engineer and processed accordingly, eventually getting assigned to localization. Then the original translation was replaced with the requested one.

Since some terms employed in the localized UIs were neologisms, it is not surprising that customers would want to change them as the technology was adopted and the language describing it matured. For some customers, however, opening a ticket and waiting for a patch release was too time-consuming a process to change a text string. They wanted to change translations on their own whenever they saw the need, or in response to criticisms from their suppliers.

In response to this demand, and in response to the growing number of bug reports that were simply language issues, the development team created a tool that allowed authorized users to change localized text interactively. By clicking a text string on the served browser page, an authorized user could enter a new string and save it directly to the localized RESX file. While not every customer decided to use this tool, it did considerably reduce the number of language bugs that were submitted.

In addition to providing this tool, we adopted a more customer focused approach to translation. This was especially important since in several of the target languages — particularly Slovenian, Turkish and Russian — there were at that time no standard, agreed-upon translation for certain e-procurement terms. In the case of Slovenian, for example, the translator discovered that he was first to introduce several terms into the language by working directly with the customer who had demanded this language.

Updating resource files

As noted above, many of the customers were large corporations and drove development of customer-specific functionality. This led to custom resource files in addition to standard resource files. Their demands often led to features that were incorporated into the main product.

In the early days, when there was just one customer that wanted the user interface translated into Spanish and Portuguese, updating the standard and custom resource files was a relatively easy task. Over time, as the number of supported languages grew, and as the number of customers grew maintaining and updating the resource files became a full-time task.

It was necessary to create a tool that would compare the English resource files — both base and custom ones — with the localized resource files in order to extract the strings requiring translation. Once those strings were translated, the tool would need to re-integrate them into the existing localized resource files.

We looked for an off-the-shelf software package that could do this, but at the time there were none that met our needs. Happily enough, an engineer volunteered to create a Java-based utility that performed all these tasks remarkably well. Since the number of resources eventually swelled to over 12,000, you can imagine that this utility was essential.

Figure 2 shows the translation update workflow. As shown below, the tool performed two separate comparisons in order to generate a delta or diff file containing the strings to be translated. It compared the current English resource file to the previously translated resource file to capture the resource strings that had been added. Then it compared the strings in the current English resource file to the strings in the previously translated file to see if any of the strings had changed. Then it compared the English files against each of the localized resource files in order to determine which strings needed to be added, deleted or modified for each language.

The diff files containing the new and modified strings were sent out for translation. The agency translators used translation memory from previous assignments to translate the strings. After delivery, the translation tool integrated the newly translated diffs into the existing translated resource files.

Lowering translation costs

While this tool worked well from a technical perspective, the turnaround for agency translations was often slow, or at least too slow for some of our customers. Each translation job required a quote, and each quote required approval. The lag between initial quote request and delivered translations could sometimes exceed eight business days, even for a relatively small translation job.

Delays such as this and the relatively high cost of agency translations did not escape the attention of upper management. One of the conditions of profit maximization is cost minimization and the CFOs of startup companies are acutely aware of this. The end result for localization was constant pressure to lower translation costs.

One of the more interesting attempts at doing this involved the creation of a localization group based in India. The startup, which had by then become profitable, bought a small Indian company that had useful industry data. The CEO of this company had on occasion hired locally based translators for short-term assignments. He suggested that we do the same.

I hesitated at first, knowing from experience how complicated it was to translate the user interface and online help. At the insistence of upper management, however, I slowly assembled a team of translators. This team consisted mostly of expatriates who were living in India for various reasons.

Since these recruits were largely new to professional translation, we organized training for them both on our software products and on the various tools that we used in-house. While few had had previous exposure to software development, most were able to learn enough to adapt to the demands of the job.

After the initial ramp up, we were able to lower translation costs and speed up translation turnaround. This was possible because the translation memories built up from earlier rounds of translation enabled the team to leverage existing translations when formulating new ones. This strategy worked especially well when the remote translators worked on software updates.

The takeaway

If you should find yourself responsible for localization in a startup company, there are four things that you are likely to encounter:

• A lack of knowledge of internationalization
• Coding lapses on the part of the development team
• Customer concerns such as complaints about translated strings
• A persistent demand to lower translation costs

To deal with these issues, it would be best to employ the following strategies:

• Explain whatever needs explaining to whomever
• Remind development managers to enforce internationalization coding standards
• Remember that the customer is king
• Defend the need for quality translation but be open to new approaches, whether technological or labor-related
• Have fun — so many people would relish the chance to do what you do