For most software product managers I know, localisation can be a four-letter word. Localisation is the process of adapting software for non-native environments, usually other nations and cultures. Localisations take a long time and require significant development effort, but they are usually necessary if you want to sell into foreign language-speaking markets. Typically the localisations are of the software user interface, and the documentation and training materials.
While working in product development, I occasionally hear the suggestion that we can have one of the developers or field engineers that speaks the local language localise the product. Although this seems like an efficient solution, there are many reasons to avoid it; here are a few:
- Inconsistencies. Localisation vendors use a database, called a Translation Memory (TM). If you don’t have an existing TM, the localization is likely to be inconsistant. If you do have an existing TM, the developer wouldn’t likely have access, which requires the purchase of a license, their translation may be inconsistent with what already exists. Also if your company does have an existing TM, there is a cost to update the TM with the internal localisation.
- Overhead of coordinating internal localisation. Most people with experience know that this is a non-trivial task; the localisations need to be reviewed and corrected, and this all takes time.
- Opportunity cost of paying engineers to localise rather than code.
- Lack of local knowledge. The developer may not be familiar with regional variations/style.
If you are only looking at a few sentences and are in a screaming hurry, localising internally and then updating the TM is an option, but for the reasons outlined above, you may find it’s less efficient than planned.