The current method is to click through every dialog, and manually verify all captions have been translated. One of the major problems with this approach, is that it's very time consuming. This is also error prone, since it's possible that not all error/warning messages have been verified.

Is there a better, faster way to accomplish this task?


Since I don't have the ability to change how the application was designed, and no control over the development process. what options are available to insure all text that appears in the application is properly displayed in the appropriate language?

  • 1
    "Since I don't have the ability to change how the application was designed, and no control over the development process. what options are available to insure all text that appears in the application is properly displayed in the appropriate language?" You can click through all the UI to verify it, or perhaps search through all the source code to verify it. Either way will still likely be time-consuming. No free lunch here. Commented Mar 22, 2012 at 16:12
  • Tester101, if the localized resources are not in a separate resource file then they are hard-coded into the code. That means, that would would have complete and separate build branches for each language. I seriously doubt this is the case unless your dev's have just awaken for the first time since 1980. :-) You should probably ask your dev team where the localizable and localized resources are. Commented Mar 24, 2012 at 0:32

3 Answers 3


There are conventions that will facilitate faster testing. For example, if every translatable caption is fetched from a message catalog, you could merely check whether the message catalogs have been translated. (Different development environments use different terms for "message catalog", but hopefully the concept is clear.)

It is possible to tailor a UI framework so that developers are more likely to use message catalogs rather than hard-coded strings. In my experience, developers do not like to work with that kind of framework because they are forced to deal with internationalization before they want to.


Even if your developers use message catalogs consistently, there is no guarantee that the translated text will render appropriately on the page. For example, if a translated string is too long, it may wrap or truncate or impact the geometry of the page in undesirable ways. If a message contains application-supplied values, it is also possible that the values are supplied in the wrong order. For example, while the English error message might be:

File data.txt is missing from directory /home/Tester101

the Spanish error message might be:

/home/Tester101 archivo no se encuentra en el directorio data.txt

Ultimately, regardless of how the application was designed, there is no substitute for scrutinizing every page with your own eyes.

  • Lets say I can't change the way developers write code, so I have to work with what they create. What options are available to me in this situation?
    – Tester101
    Commented Mar 22, 2012 at 15:39

This is a difficult one because even if you do get a great scenario where you can get all of the copy stripped out, you could still run into encoding issues in the application or several other things that could screw up a translation like @user246 mentions.

Some tools have been adapted for a few platforms like content management systems, to help facilitate this. Internationalization modules and the like for systems like Drupal. If something along those lines is available, they tend to give a pretty comprehensive breakdown and will even compare one translation against another.

Outside of that, if there is a lot of copy to sweep and compare I've started resorting to writing a spider/scraper. I'm not sure how feasible it would be for an installed/local application, but for web copy it is somewhat of a brute force way to compare text. If the copy is externalized in any way (.po files for instance) you could use a line-by-line comparison tool such as Beyond Compare to go line by line outside of the application if you aren't into the automation end of things.

Nothing really compares to your own eyes and/or the eyes of a native speaker of the localized language (for context) though.


Usually when you have properly internationalized your application, all the text strings (and other localization elements) have been moved into resource files where they are relatively simple to translate for a particular locale.

The Internationalization project may be time-consuming, but it makes the individual Localization projects far simpler and far less error-prone.

  • What about when an application is not "properly" internationalized?
    – Tester101
    Commented Mar 22, 2012 at 15:44
  • 1
    Then you incur the penalty every time you attempt to localize. Like many things in software, it's "pay me now" or "pay me later (and repeatedly)". Commented Mar 22, 2012 at 16:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.