Finding Your Own Definition of Done for Software Internationalization

Internationalization (i18n) is one of the first steps to consider when setting out to launch your software to a global user base. Imagine you had a guest room with velcro-backed wall decals that you changed to suit the preference of each guest. Internationalization would be the velcro that allows you to adapt the look and feel of your room without much effort.

Just like any work done to a house, it’s easy to feel that you can never really “finish” internationalizing your software. However, finding your own definition of done (DoD) will allow your development efforts to meet the expectations of your users and reduce rework. So let’s take a look at how you can go about finding the best i18n workflow and strategies for your global software product.

What is the definition of done (DoD)?

A definition of done is a list of tasks that need to be completed before you can consider a piece of work “done.” In the context of agile teams working in software internationalization, this list concerns the current sprint and may include such steps as:

• Choosing an internationalization library
• Deciding on what locale file format you’ll use (e.g., JSON, XLIFF)
• Extracting strings from your codebase to a localization file in your preferred format to make it translatable
• Checking that there aren’t any concatenated strings or hard-coded values
• Allowing the input of data with format variations (e.g., date formats, number conventions and currency formats)
• Designing the UI to account for text expansion
• Creating shortcut key combinations that can be used across all locales
• Ensuring terminology consistency to facilitate translations

These are just a few examples, but you’ll notice that they cover a broad range of things that need to be achieved before localization can start.

The list may also vary depending on the product and its localization needs: Smaller products with fewer features may just require a handful, while larger applications may require more rigorous standards before they are ready for localization.

Can a DoD change over time?

It can—and if often does. DoDs tend to evolve over time as your product grows and new requirements arise.

For example, you might not have wanted to check that buffers are correctly resized to hold translated strings when you were only localizing into one or two languages, but this feature becomes essential once you want to localize into 10 or 20 languages.

Who creates a software internationalization DoD?

While developers are usually best qualified to define a software internationalization DoD, localization experts or localization managers can also contribute to it. It’s important that all stakeholders are included in these discussions because everyone needs to be aware of what to expect from your product when it comes to localization.

Moreover, when everyone engages in the process, localization is more likely to be viewed as integral to software development, i.e., running continually in parallel with development cycles rather than being an afterthought.

When can software internationalization be considered done?

While this may not be a definitive list, and you’ll likely need to refine it to suit your project, here are a few best practices that will help you avoid regrets once you launch your global software:

Well-structured code

Generally, i18n involves structuring your codebase so that it is ready for localization. However, first and foremost, your product must be ready for deployment in a monolingual environment before internationalization starts.

Once you’ve ensured this, you might want to check how you’re storing your strings. If your translatable strings are somewhat intertwined with your code, you may want to consider extracting them and putting them in a separate file.

Another challenge is to remove or rework concatenated strings. This is something that takes a little more effort than you may think. You would need your developer team to work closely with your i18n experts to make sure your software can adapt to a different language and no bugs are introduced through this process.

It’s important to know that code restructuring for i18n goes far beyond simply separating translatable strings. Depending on which languages you seek to localize into, you may need to set up a whole lot of infrastructure, like changes in the user interface, and you will need to adapt your code accordingly.

Proper encoding

Checking what the best encoding type is for the target language is crucial to avoid compatibility issues. Unicode has been established as a standard for most cases that do not require legacy character sets or other encoding schemes.

Within Unicode, UTF-8 is almost always the best choice, unless you have specific requirements that call for another encoding type.
If your data is mostly in western languages, going for UTF-8 will reduce storage space almost by half compared to UTF-16. However, if your data spans a lot of different double-byte languages and scripts like Japanese, Chinese, or Korean, UTF-8 will take more storage.

Correct layout, language length, and language direction

Not all languages are the same length, so your software should not enforce a particular limit. This can lead to user interface errors if the translated strings don’t fit into their containers anymore, and no brand wants to display a truncated app title or error message in the user interface.

For this reason, make sure you lay your UI elements relative to each other without fixing their position or size. All containers should be able to dynamically resize based on the length of the text they must contain. If you need to set a maximum size, the industry standard is to allow for an average of 35% of additional space.

Last but not least, your interface should be designed to flip its orientation or layout based on language direction. While the majority of languages are written from left to right (those of Latin origin, as well as Cyrillic, Greek, and various Southeast Asian writing systems), there are some languages, like Arabic and Hebrew, that are written from right to left. Supporting interface mirroring is crucial to make sure your software is accessible in all languages.

Localized images

To meet the criteria for “done”, your product features need to be integrated into a clean build. A typical case for i18n here is the re-configuration of those fancy-looking images.

Sure, you’d like to release them into the target market and expect them to attract much attention and generate good returns. At this point, you may have already spent a big sum of money on the design. However, instead of publishing these wonderful images directly on your localized product, you need to check if there is any text embedded in them.

Chances are you will find some descriptive or decorative text hard-coded in the images. Make sure you have them extracted and translated, as well. Also, since the length of each language varies, you may need to adjust the spacing between texts and images.

Locale awareness

To ensure the definition of done is met for your internationalization workflow, you may also need to think of the way how users access the localized release. In other words, in what way would your users navigate to the language they are familiar with?

While some multilingual websites and apps force a particular language onto the user based on their IP address or browser settings, this isn’t always the smartest choice. It’s advisable to build software that will allow users to select their preferred language for your software. Make sure your software supports this kind of localization switching, otherwise users will likely reject it due to inconvenience alone.

The easiest solution would be to attach locale names at the end of your web address (e.g., …/es_ES would be for Spanish from Spain). However, a more refined way of doing this is adding a language picker that enables users to jump between the different locales.

Locale awareness also means making sure formats of information meet local standards. For example, what does 09/11 mean? September 11th? November 9th? Depending on the market you choose to sell your product in, a single date format may have a completely different meaning.

You also want to get the measurement right. For example, if you tell someone in Japan you just traveled “17 miles” he or she may have a hard time figuring out how far that is.

Web accessibility (A11Y)

To expand your software’s reach, you should also ensure it’s accessible to users with limitations in their physical capabilities.
The most basic requirements for web accessibility are:

• Text of a size that can be read by people with decreased vision or altered color perception
• Images properly captioned with text equivalents (both on-page and alt text in the back-end)
• Keyboard support for all interactions to help minimize or eliminate reliance on mouse movements, including requiring double-clicks to activate links
• Forms accessible enough to be filled out using just a keyboard
• Table summary attributes for concisely describing the structure of the page
• Headings hierarchy for the structure of larger pieces of information on the page
• Links that clearly describe where they go
• Browser zoom of up to 200%

These points and more are covered in the Web Content Accessibility Guidelines (WCAG), a set of guidelines that show how to make web content more accessible.
Your definition of done for software internationalization will be more comprehensive if you address these aspects. You might need to hire a consultant to do so, but it’s well worth the return.

Use the right technology

Releasing a product into a different market is never a one-time job. To be considered done, your i18n efforts should follow an uninterrupted loop where your team can collaborate in a seamless manner.

What tasks this loop might include depends on the product, your goals, and the complexity of your localization process. Regardless of those factors, you can empower collaborative teamwork by using localization technology in your workflows.

Whenever there is an update—however small it might be—it’s advisable for it to be synchronized to your localized version, often within a short turnaround time. Moreover, given the complexity of i18n, you need to ensure coordination among different parties. Therefore, by relying on software that enables automation, you can create an agile process that seamlessly integrates with your product release cycle.

Automation in this context doesn’t necessarily mean “machine translation”—it rather means an automated solution that manages legacy and new development for i18n purposes and moves files between the build and translators back and forth in a fast and efficient manner.

Now that you’ve gained more knowledge in determining your own definition of done for software internationalization, it’s time to pick a tool that best serves these ends.