A Word Can Make You Miss Your Deadline

Which word can make you miss your deadline? The answer is “any word.” When you are developing a product that will be released in other languages than English, you are adding numerous new risks and constraints to your project.

Some are technical and obvious. For example, if your product will be released in Japanese, it has to support the appropriate fonts. If it doesn't, the Japanese version won't work, even if the English one works perfectly. But font compatibility is not under your control. You and your team need to be aware of translation quirks and consider them before coding. Make sure that the development practices follow international standards that will eliminate such issues.

However, the mere need for alternate language versions also constrains what decisions you can make and when. Typically, localization (Japanese, Swedish, German) happens in parallel with English development, with a certain lag. It can be a few days, weeks or even months. However, at some point the translation of the foreign version has to “catch up” with the English version.

You need to make sure during testing and reviews that,

1) What is in the English version can be properly translated,

2) What is translated truly corresponds to the English version, and

3) The translated product works flawlessly.

Here's the catch. These three things may be tested after the English version is finished and signed off on. During the testing and reviewing of a localized version, you will always find at least one challenging issue that can't be solved except through a change to the English product.

However, be aware that a relatively simple and low-risk last-minute change in the English product, such as rephrasing a sentence which takes only a few seconds to code, often requires several days to implement and re-test for all the localized versions.

This can cost thousands of extra dollars, especially if you are contracting the translation work to an external company. The mistake less experienced software development project managers often make is simple. They underestimate the effect and magnitude of making unexpected changes to the English version.

Here are two main things you can do to prevent this.

• Add a “localization buffer” to the end of your schedule. End of schedule means the effective deadline for any work on the English product included in your project schedule. Any changes that need to be done after that targeted end date must meet very specific and very strict criteria to “get in” to the rework queue. Every change to this version also necessitates changes to the foreign ones.
• Sequence the tasks in a way that quality control of functionality is done separately from quality review of the English text. That can be as simple as copying all of the English text to a spreadsheet for proofing. That way, unclear wording can be found before the test cycle reveals it on an otherwise functioning product. Now, the necessary change can be done earlier and may not necessitate reworking other language versions.