By Matt Hauser
ComputerWorld.com – April 28, 2011
Let's wave a magic wand and imagine the following scenario about the localization of a software application:
- You have a budget
- You have a project timeline
- You have a project manager
- You have executive approval
Again, this is purely hypothetical as getting all of these planets to align is tough, but work with me here.
So all of these things are in place, now what?
In an ideal world, the decision to localize a software application happens BEFORE the source language version is even created. This means that the product has already been internationalized and is able to handle things like text expansion and/or character based languages without impacting the application functionality.
Step one:
The first step in the process is to identify what there is within your application that needs to be localized. Are you planning to have the entire application available in multiple languages, or just certain elements? Are you going to localize the Graphical User Interface (GUI) AND the associated documentation and help? Some elements of GUI that typically require localization include:
- Dialog boxes
- Application menus
- Error messages
- Alerts
- Pop ups
Step two:
Prepare your files for localization. Most applications contain translatable content in Resource Files (.rc). Web-based applications may contain content in XML, AJAX, JSON or even in database files. You can also invest in third-party tools (like Alchemy Catalyst) that can prep these files for localization by automating the process of separating content from code so that the text can be utilized with Translation Memory assets. You also have the option of sending out compiled files (e.g. .dll or .exe files). When using a tool like Alchemy Catalyst, this allows the translators to see the impact of their work in context to determine how it will impact the overall user interface experience (text will expand or contract based on the language you are going into).
Step three:
Once your files have been sent to your translation vendor or internal translation resource, the third and perhaps most critical step of the process comes into play -- post-localization testing. Post-localization testing is comprised of two key elements -- functional and linguistic testing.
Functional testing relates to how your application looks and behaves in the target language(s). Does it look correct from a layout perspective? Are the dialog boxes rendering properly? Does the application still work the way that it should?
Linguistic testing is verification that the language is correct. In some cases, translations need to be abbreviated to fit into the available real estate, so it is critical that the language is reviewed in context to make sure that the end user understands what they need to do. This process also involves a review to make sure that line/text breaks are correct in the target language and that accented characters are displaying properly.
In some cases, the actual testing phase of the project can be the same cost as the actual translation, so it is important to build this into schedules and timelines. And when it comes to documentation, it is a best practice to localize the application first, since your documentation will probably need to include screenshots of the target language application and references to what is shown on screen should be consistent.
So in planning for software localization projects, consider content localization as well as testing to be most successful. Also have localization in mind while you are developing your application and documentation to reduce costs and timelines as much as possible.
Here's hoping that the ideal scenario mentioned at the beginning of this post comes true for you at some point soon...
Matt Hauser is VP of Technology for TransPerfect Translations.