Drastically reducing the number of screen captures in a document

March 5, 2011

In my experience translation vendors charge per screen capture translated. One way I’ve found to drastically reduce the number of screen captures in some of my documents (and therefore the cost) is to take one screen capture of the entire desktop with several dialog boxes open, and then use this capture throughout the document, cropped to display only the section or dialog box in question.


Should you do the screenshots internally or rely on a vendor?

March 15, 2010

Speaking of software localisations, one of the pain points in the process is capturing localized images of the software (dialog boxes, menus, etc) for use in the documentation. To capture these screens, you first must have the user interface text strings localised into a number of non-native languages, and then incorporate these new languages in the software. Then ‘someone’ must go through the documentation and capture screens of the software in each of the languages. It is often assumed that the someone should be a member of the development team that built the software; but this isn’t always the case. Localisation vendors offer this service if you can provide them with the software and a script for creating the correct scenarios. The decision, of course, should be based on economics. Here are a few things that feed into the costs.

  1. Can a build of the software be easily installed at the translation vendor?
    If it takes day to install and configure your software appropriately for capturing screens with dongles, license keys, etc, you’d better quantify this cost.
  2. Is it easy to change languages in the software?
    Typically the answer is yes, but if No this could be costly with a vendor doing the work.
  3. Does the software need a localized operating system to display the translated user interface correctly?
    Often Asian languages don’t display properly in software that isn’t running under a localized operating system. In my experience, most development teams don’t run localized operating systems for viewing and testing translations.
  4. Can you create a simple script and provide sample files to produce the desired results?
    A translation vendor needs a script and sample files so they can properly capture the screens. It takes time to create this. Estimate how much and calculate the cost.
  5. Who will capture the screens on your development team?
    Typically this will be a technical writer, tester, or developer. Calculate the cost of their time.

As you might have already guessed, keeping screen captures in documentation to an absolute minimum will have a significant effect on your translation costs.

Four reasons you shouldn’t rely on developers to localise

March 3, 2010

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:

  1. 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.
  2. 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.
  3. Opportunity cost of paying engineers to localise rather than code.
  4. 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.