Today’s technology market spans much more than just North America and Europe. The emerging economies of South America, Asia and Africa have changed the software market and their consumers expect and demand products and services tailored to their linguistic and cultural needs. Failure to meet these needs impairs the competitiveness of your product and, in many cases, allows other companies to take your place in the market. To prepare your software for localization you should pay attention to some localization practices.
A proper localization helps your product meet those needs. However, localization involves more than just hiring a good translation company. It involves planning throughout the development of your product, taking into consideration design elements and a joint effort of the whole team. Following the 5 steps below will help you keep your localization efforts on track and ensure that the process remains as easy as possible.
Begin early
Begin preparing your product for the localization as soon as you identify what your key features and target markets will be. Even if you haven´t clearly identified where you plan to launch your product yet, it is still a good idea to ensure that development and design teams consider the localization when creating the user interface. In other languages words can 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 longer and shorter words.
Leaving the localization process to the last minute can also increase development time and localization costs. Whatever your workflow is, a good localization partner works with your calendar to provide constant support in translating and locating your content. In fact, engaging a localization company early in the development process improves the end result because the company has time to get to know your team and to understand your product. In addition, many localization companies charge more – up to double – for projects with short deadlines. Waiting until your product is ready to begin the localization process can delay its launch and burst the budget.
Develop your own style
After all the time invested into the development and image of your product, the text style of the software cannot lag behind. Issues such as uppercase or lowercase or inconsistent syntax can be a distraction to users, causing them to not understand the content. To achieve uniform style throughout your software, you need to outline rules to follow – when to use uppercase and lowercase letters, syntax choice, and so on, in a style guide.
Luckily, most of the rules described in a style guide can be applied in multiple languages. Some languages, however, may make certain rules obsolete. Languages like Korean, Japanese, and Chinese don’t require rules for uppercase or lowercase letters. Before hiring a localization provider, make sure that it has the necessary features to create style guides for all target languages.
Beyond the text, designers should also consider icons and images to ensure cultural sensitivity and relevance. For example, some users may not be familiar with the mailboxes used in North America or be offended by some foreign symbol. Even so, some icons like the hamburger icon and the save icon (floppy disk) have reached cross-cultural relevance and can be used in different languages.
Formatting and isolating text
You should ensure that all text strings use Unicode character encoding. Unicode allows easier transfer to languages that don’t use Roman characters and 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 implement it before writing the first line of code. On a few occasions where the product does not support Unicode, it may be necessary to use a DBCS or bi-directional (BiDi) enable, code page switching, or text tagging.
In addition to using Unicode encoding, you should also isolate all target text strings in the project source code. Developers should place all target strings in resource files, message files, or a private database. However, these resource files should not include strings that will not be located. These should remain as constant strings in the source code. Isolating localization strings in this way ensures that all text is localized according to your company’s style guidelines and allows your software to switch languages more easily.
Minimize formatting issues
While creating your software, you should consider the variety of formatting issues that can arise due to differences in the conventions used for addresses, currency, dates, and phone numbers. To improve the user experience, the fields to be filled out by them with this kind of information, need to accommodate various lengths and characters. For example, postal codes in Canada are a mixture of six letters and numbers, while those in Brazil use only eight numbers. Thus, a product intended for both countries should accommodate the lengths and character types relevant to both. Implementing such changes after releasing the software requires additional development and bug testing investments and may require features that are no longer available (such as the original programmer).
Developers should also consider formatting. In some countries, such as Japan, some addresses don’t have street names, but instead districts and blocks. In software released in these countries, that part of the code that parses addresses for storage in a database or for printing on transport labels must be able to process those addresses. Failure to do so may result in additional costs of shipping goods to incorrect addresses or dissatisfied customers due to late receipt.
Reuse help content
Help content, whether in the form of tooltips, API documentation or an old fashioned manual, is an integral part of making your product easy to use and ensuring that users are satisfied with their experience. However, help content can also quickly consume your localization budget if it is managed incorrectly. Most localization professionals charge per word, so locating complex sentences and redundant information costs far more than the actual information counts. Keep the help content simple and short to get the most return on your localization investment.
Furthermore, most localization companies only charge for the first time that a string of characters is translated. So whenever possible, developers should strive to recycle these strings to increase the availability of information without raising the cost of localization. For example, the phrase that represents a feature in the manual can be used as a tooltip, which appears when a user hovers over the icon of that feature and the manual section can be reused in the web help. Essentially this allows you to deliver help content in three places for the price of one without adversely affecting the information provided by the help content.
Following these 5 simple steps while developing your software considerably decreases your development time and the cost of localization. This way you will have the best possible product for each target market. For more information on how to prepare your software for localization, get in touch with Magma.
