Point taken? You need to externalize strings; do it for the sake of users, the business, and yourself. By externalizing all strings all the time, you’ll be able to prove on demo days that your product UI is equally current for all supported human languages.
Do Pseudo-Language Testing
You can waste a lot of time finding UI and functional bugs during localization testing when it is usually too late to do anything about fixing them. Or you can swat bugs like flies (pun intended) by setting up and testing with a fake human language in the first place, sprint by sprint. This activity is called pseudo-language testing. It’s pretty easy to do if you already know how to set up an alternative UI language to your source language. And you don’t need to speak any language other than the source to succeed.
Let’s say your source English product is going to be translated into one or more target languages. We’ll stay clear of bi-directional languages for now and assume these target languages are Simplified Chinese, French, and German. Here’s what you do: First, setup for a language pack for Pseudo, just as you would do for French, Spanish, Chinese, and for other languages in the future. Then, programmatically, surround the entire set of English strings with non-English characters. For example, let’s assume you have these two English strings in a text file that contains all of the English UI strings:
Enter your name:
Enter your address:
Select characters from the target languages sets, minimally, to create a Pseudo language that you can read.
In a Pseudo language, for example, our two strings could become:
里îßEnter your name:里îß
里îßEnter your address:里îß
When you view the strings in the context of your running software, with the language set to be Pseudo (or whatever name you chose), you will be able to notice bugs such as:
- Embedded string, because you do not see 里îß at all.
- Insufficient space allowed for the translation, because 里îß is missing in full or in part from one end of the strings and/or because the entire string extends outside the space designed for it.
- Improper use of concatenation to create an English “sentence” from two or more individual strings, because you see something like this: 里îßEnter your里îß里îß里îß address:里îß, in which the string shows the special characters used multiple times and sequentially.
Feel free to include characters from additional languages if you want a more thorough test. Thai characters (เข้าสู่) are usually good if you want to test for potential font type and size issues.
Save yourself a lot of trouble and turn your team members into heroes: use pseudo-language testing as your default practice within the agile team. You will more thoroughly and more globally debug the product during early testing. Better yet, you can, perhaps, increase efficiencies and can prove doneness for all supported languages sprint by sprint. Consider this: for one bug you find during pseudo-language testing, you avoid needing to find that same bug multiple times in all target languages, not to mention avoiding the risk of letting international customers find them unnecessarily. By the time your product is delivered in, say, ten or more languages, those numbers add right up!
In 2013, we experienced measurable success across the board by adopting I18n best practices as story doneness criteria. The teams found and fixed forty I18n/functional bugs during the sprints, preventing those forty from becoming 360 bugs (forty multiplied by nine languages) to find and report during localization testing. In-sprint practices let us produce better products for our international customers who use localized products, too. Because the localization team did not have to focus on those 306 I18n bugs, we could focus instead on finding and fixing localization bugs instead.