Marcia Rose Sweezey and Stefan Visuri explain two best practices that are defined for agile teams in their organization. Read on to discover how externalizing strings and conducting pseudo-language testing during each iteration and sprint will give you the most payback for the least investment.
Internationalization (I18n) is everything we do to ensure that products can be localized. This means that products are adapted for use in global markets, with one of the most obvious adaptions being translation. Implementing basic I18n best practices will help you achieve a more flexible source product and one that is ready to go global. If you are a developer externalizing strings should be at the top of your I18n To-Do list, right after Unicode-enabling. If you are a test engineer, you’ll want to focus on pseudo-language testing.
If you are moving from waterfall to agile, be sure you and your team can define how you will ensure that I18n practices are incorporated to all of your iterations. You can create individual stories or include test criteria with stories. In this article, we will describe a particular case in which, we, the localization team, created a set of I18n best practices that were posted on the architecture wiki. We provided training to the agile team members and answered questions during twice-weekly Scrum-of-Scrum meetings as well as on a regular basis throughout the project. The agile team members adopted the practices as doneness criteria for all stories. Over twenty best practices are defined for agile teams in our organization. For this article, we selected just two of them on the basis of prioritization. That is, we believe if you do nothing else, externalizing strings and conducting pseudo-language testing during each iteration and sprint will give you the most payback for the least investment. We’ll tell you about results on our last project at the end of this article.
Externalize All Strings
Words that are embedded in the code cannot be translated to a target language in any sane way. Let’s face it, unless your company has no possibility of ever taking its product global, some manager is going to greet you one day with “Good news! Our product is going to be translated to six languages!” If you’ve hard-coded the UI strings, then what you should really hear in your head is “Tough luck! You have to re-engineer the product—fast!” To avoid the bad news and the subsequent boring and problem-riddled job, just externalize all strings, all the time. In addition to quality-of-life purposes, you have significant usability and business reasons for externalizing strings. As an example, assume that someone translates a product from source English to Simplified Chinese. If even some strings are embedded, here’s what your customer in China might see:
Figure 1. Mock-up of a screen showing what can happen if we do not externalize strings. This graphic does not represent a real screen or real translations.
You may not think it’s a big deal. It’s just a couple of words in English. Right? So let’s try it another way other way around. In this case, someone translates a product from source Chinese to English, strings are embedded, and you get this screen for your personal use:
Figure 2. This image details the same problem as Figure 1.