Businesses small and big can participate in a global software market by ensuring their software is localized (L10N) and internationalized (I18N). You do not need a team dedicated to doing I18N/L10N, and implementing it doesn’t have to be complex, but it does require planning to execute correctly. It is often said that the best designs are “invisible,” in that when something is designed well you hardly notice it. The elements of localization go way beyond the description or banner of your application. Things like dates and times, currency symbols, addresses, phone numbers, even the decimal point, must all be localized to make your application feel right to your customers.

When considering how to localize a project start by deciding what languages/locales are important to customers and potential customers. As an example, it will take significant effort to implement right-to-left support (e.g., for Arabic or Hebrew), knowing if it’s important up front will save you time in the long-term if so, and will save you time up-front if not. From a technical standpoint you will also need to investigate what is available in your choice of language and/or framework. For instance, some languages (like Java) natively support locales so that you won’t have to think about the nuances of decimal points or currency formats, only the selection of the correct locale. Other languages may not support this natively, but I’ve yet to encounter a widely used language/framework that doesn’t have additional packages to make this a breeze.

Likewise, libraries exist for every major language/framework that make localization of text possible (and even easy, like i18next for JavaScript). They typically share common implementation patterns, such as having a language file (per language) with all of the text that can be translated in a single file per language. That is, a file that contains each text element that can be translated and its translated equivalent in a given language. It’s important to remember that this text isn’t just the obvious text that is on the screen, it’s also info and error messages, it’s breadcrumbs and site navigation, it’s punctuation, etc. Utilizing such a framework is critical for two reasons: it will enable you to maintain and update your translations easily; it will allow you to add new languages without changing the underlying technical implementation.

Now that you have tackled your technical implementation, you need to turn to the expertise of fluent, professional and native speakers to create or fine-tune your translations. Language and grammar is cultural, and it deeply influences how we think. Moreover, technical text is often difficult to translate, and requires not only a fluent speaker of the language, but also one who is familiar with the domain. As a result, turn to experts when translating text. Because you’ve spent the time to extract translatable text into a single file per language, it is easy to isolate this work from other active parts of your project, and it is easy to update these files as things are changed, added, or removed from your application.

There are many technical nuances to the implementation of I18N/L10N, like character encoding for requests, and storage, text comparisons, and rendered vs. dynamic content. By thinking through the implications and scope of what you need localized for your business and for your customers, you can reduce overall cost of implementation of your application, and expand your potential customer base. Visit us here to discover how we can help you reach your audience.