– Oops I broke your software –
This is Part 3 of our in-depth series on the software localization process. So far we’ve talked about setting yourself up for international software success by planning ahead and thinking about things like language requirements, terminology, and context throughout the process. This week, we’ll look at software validation. Validation is by far my favorite part of the software localization process. After all the hard work that went into planning and translation, it’s the point when you finally get to see all of the beautifully translated target language content in its final environment. All the German software strings fit so beautif—wait a minute, that’s not a whole word. Also why are there a bunch of random characters in the middle of that sentence? That can’t be right. And now I’m getting an error message…in English? Okay, I broke your software. But now your customers don’t have to.
Why you should validate your software
Validation is the last check that should take place before your software is released to avoid launching a product with display issues, untranslated content, or other technical issues. No matter how careful you’ve been in getting your software ready for translation, or how careful we are during translation, validation is always a good idea. When we translate software strings, they’re generally first exported from the software and into a format that works well for translation, such as XML, HTML, PO, or XLIFF. These formats are great because they interface with our translation tools, allowing us to take advantage of translation memory, increase consistency, and decrease turnaround time. The resulting drawback, though, is that translators can’t see the content in its final context. Even with the help of screenshots or context tags, the strings might still be out of order, unclear, or confusing. The software validation process helps ensure that everything you’ve worked so hard on is ready to go.
Types of issues we most frequently find during validation
Every piece of software is different, which means that we give a wide variety of feedback depending on the project. Here are some of the most common examples:
Truncated text. When text expands during translation—but buttons, columns, or text boxes aren’t coded to resize automatically—it might not be completely visible.
Encoding problems. For non-Latin scripts or languages with lots of diacritics, it’s important to use a type of encoding that allows for all characters, otherwise they may show up as question marks, boxes, or random characters
Untranslated error messages. Depending on how your software is organized, the error messages might not be in the same file as the software strings. We often find English popups or errors during validation
Inserts that don’t work in context. If your software uses variables or conditional text, these should be checked during validation to make sure the text displays correctly.
How you can avoid mistakes in the first place
There are lots of things you can do to minimize the number of changes that need to be made during validation. A good place to start is to make sure that your English software has all the kinks worked out before sending it to translation. Ideally, all functionality issues should have already been addressed and all the translatable content should be included in the files (including error messages, text that appears in images, etc.). There are also other things that we look out for during translation, but we can only do this if we’re aware of the software’s limitation.
For example, if the layout of your software includes fixed-width object (buttons, columns, or drop-down menus), we can consider string length limitations proactively. Or, if we know that only 20 characters can fit on a button, we can set a length limitation on that string to make sure it will fit in every language. It’s much easier to work with length limitations from the beginning than to work backwards, shortening translations during validation. We can also think proactively about how to translate inserts, which is a challenge that English speakers don’t always consider.
For example, say you have the following string: Click here to launch the {0}. In English, you can replace {0} with {installer}, {applications}, {program}, etc. But in Spanish the gender and number of the variable {0} will affect other parts of the sentence.
By knowing in advance which types of variables will be inserted in the sentence when it’s imported in the application, we can proactively translate these sentences to be grammatically correct in context.
Validation in practice
There’s a lot of different ways to conduct software validation. We can work either from screenshots or videos of the full software set, or through direct access to the translated software (whether from a trial install, through remote access, or in some cases even through on-site validation). The changes we identify are sometimes things we can fix in the translated files. But often the software will need small programming changes directly in the software itself. The work that goes into the validation process will definitely be worth the reward when your final product is polished and error-free.
Once validation is complete and all the changes are implemented, you’ve almost gone through the entire software localization process. But what if your customers still need to learn how to use that translated software? Next week we’ll talk about the last step: translating the user documentation of your products. In our Intro to the series, we give a general overview of the software localization process. In Part 1 we discussed target markets, project specs, and update models. In Part 2 we discussed terminology, consistency, and context.