Five Ways to Prepare your Software for Localization

Today’s tech market encompasses far more than just North America and Europe. Emerging economies in South America, Asia, and Africa have changed the landscape of both software development and sales, and consumers now expect and demand products and services tailored to their linguistic and cultural needs. Failure to meet these needs harms the competitiveness of your product and, in many cases, allows other companies to clone your product and reap the customers you deserve.

Proper localization helps your product fulfill these needs. However, localization involves more than just hiring a good translation company – it involves thorough planning throughout the development cycle of your product, careful consideration of design elements, and a concerted effort from the entire development team. The following five tips will help you keep your localization efforts on track and ensure that the process is as painless as possible.

Start early

Start preparing to localize your product as soon as you identify its core features and target markets. Even if you haven’t clearly identified where you plan to release the product, it’s still a good idea to ensure that the development and design teams consider localization when creating the user interface. For example, text in other languages may be up to 50% longer or shorter when translated, so elements such as text boxes, dialog windows, and menus should be sized to accommodate both the longest and shortest strings in this spectrum.

Leaving the localization process until the last minute may also lengthen your development time and localization costs. Whether you’re using an agile or waterfall workflow, a good localization partner can work with your schedule to provide incremental support for text translation and localization. In fact, involving a localization company early in the development process often improves the end result because the company has time to get to know your team and understand your product. In addition, many localization companies charge a premium – sometimes even double the cost – for quick turnaround times and same day service. So, if you wait until your product is finished before beginning the localization process, then your project may come in past the deadline and over budget.

Develop your own style

After all the time invested into developing the focus and feel of your product, there’s no reason that the text in your software shouldn’t also convey these attributes. Issues such as inconsistent capitalization or syntax can be distracting to users and may even cause them to misunderstand the content. To achieve a uniform style throughout your software, you need to outline the rules governing things like capitalization and syntax choice in a style guide.

Luckily, many of the rules outlined in a style guide can be applied to multiple languages. Some languages may render certain rules moot, for example, languages such as Korean, Japanese, and Chinese do not require capitalization guidelines. When you initially consult a localization provider, confirm that they have the resources necessary to create style guides for all of your target languages.

In addition to text, designers must also consider the icons and images to ensure cultural sensitivity and relevance. For example, some user may not be comfortable with excessive flesh or be familiar with the mailboxes used in North America. This comes with a slight caveat. Accepted icons such as the hamburger icon and save icon have achieved cross-cultural relevance, so these and other similar icons may be used.

Format and isolate text

You should ensure that all text strings use Unicode character encoding. Unicode allows the easiest transfer into languages that don’t use Roman characters, and it handles most of the world’s writing systems. Implementing Unicode after writing the code is a difficult and time consuming task, so it’s a good idea to establish this in your programming best practices before you write the first line of code. In the rare instance that the product cannot support Unicode, then you may need to find a work around using DBCS enabling, bi-directional (BiDi) enabling, code page switching, or text tagging.

In addition to using Unicode encoding, you should also isolate all target text strings from the source code of the project. Programmers should place all target strings in resource files, message files, or a private database. However, these resource files should not include any strings that will not be localized. Any strings that do not require localization should remain as string constants in the source code. Isolating the localization strings in this way ensures that all text is localized according to your company’s style guidelines and allows your software to transition between languages more easily.

Minimize formatting issues

When creating your software, you should consider the range of formatting issues that may arise due to differences in the conventions used for information such as addresses, currency, dates, and telephone numbers. To improve usability, the input fields in which users enter this kind of information need to accommodate various input lengths and characters. For example, postal codes in Canada are a mixture of six letters and numbers, whereas those in the United States use only five numbers. Thus, an input field in a product intended for both countries must either accommodate the relevant lengths and character types in its validity check or separate input fields must be provided. Implementing such changes after releasing the software requires extra investment in development and bug testing and may require resources, such as the original programmer, that are no longer available.

Developers must also consider formatting when writing routines. Some countries, such as Japan, use district and block divisions in addresses rather than street numbers. In software released in such countries, any routine that parses addresses for storage in a database or printing on shipping labels must be able to process such addresses. Failure to do so may result in extra costs from shipping goods to incorrect addresses or customers who are unhappy due to receiving late shipments.

Reuse help content

Help content, whether in the form of tooltips, API documentation, or an old fashion manual, is integral to make your product easy to use and ensure early adopters are satisfied with their experience. However, help content can also quickly consume your localization budget if improperly managed. Most localization vendors charge by the word, so localizing complex sentences and redundant information costs far more than the information may be worth. Keep help content simple and short to get the most return on your localization investment.

In addition, most localization companies charge only for the first time a string is translated. So, whenever possible, developers should strive to recycle strings in order to increase information availability without increasing localization costs. For example, the sentence that introduces a feature in the manual can be used as the tooltip that appears when a user hovers over the icon for that feature, and the section from the manual can be reused in the web help. In essence, this allows you to provide help content in three places for the price of one without adversely affecting the information conveyed by the help content.

Implementing these five simple guidelines during the development of your software vastly decreases the timeframe and cost of localizing your software. Starting early and incorporating these guidelines also ensures that you deliver the best possible product to every target market. For more information about preparing your software for localization, consult the Microsoft Developer Network or your localization provider.