Whether it is a medical device UI or an international training program, it can be daunting for medical device and pharmaceutical companies to figure out how to best internationalize the source code. Do it poorly and you’re stuck in an expensive cycle of delays, sub-par localization results, and unhappy users with potentially far worse complications.

If you don’t know what “internationalization” is and why you need it, allow us (via Lingoport’s excellent Internationalization Library) to give you some background:


Internationalization is the design and development of a product, application or document content that enables easy localization for target audiences that vary in culture, region, or language. Internationalization typically entails:

  • Designing and developing in a way that removes barriers to localization or international deployment. This includes such things as enabling the use of Unicode, or ensuring the proper handling of legacy character encodings where appropriate, taking care over the concatenation of strings, avoiding dependence in code of user-interface string values, etc.
  • Providing support for features that may not be used until localization occurs. For example, adding markup in your DTD to support bidirectional text, or for identifying language. Or adding to CSS support for vertical text or other non-Latin typographic features.
  • Enabling code to support local, regional, language, or culturally related preferences. Typically this involves incorporating predefined localization data and features derived from existing libraries or user preferences. Examples include date and time formats, local calendars, number formats and numeral systems, sorting and presentation of lists, handling of personal names and forms of address, etc.
  • Separating localizable elements from source code or content, such that localized alternatives can be loaded or selected based on the user’s international preferences as needed. Notice that these items do not necessarily include the localization of the content, application, or product into another language; they are design and development practices which allow such a migration to take place easily in the future but which may have significant utility even if no localization ever takes place.

Getting specific: The real work of internationalization

So, in short, internationalization prepares your applications for more efficient, timely localization, which in turn prepares your application for a locale. But still, what’s really entailed in an internationalization project?

Simply put, internationalization is all of the planning and execution that needs to be included in the development of software that lets the software support languages and locale formatting (like numerical formats, dates, times, currencies, postal addresses and more). Applications not only have to be capable of displaying any language, they have to correctly allow the input, storage, processing and retrieval of that multilingual/multi-locale data.

It mostly breaks down to engineering for a few categories of issues, which include:

  • Character encoding: Every character you see on the screen corresponds to a set of zeros and ones that get “interpreted” into what you read on the screen. How an application supports character encoding determines whether it will actually work in Chinese, Japanese, French, German, etc. This is where terms like Unicode or ISO-Latin apply. The right character encoding strategy isn’t always obvious and will depend on a balance of marketing requirements, technical requirements and development budget, especially if the code already exists rather than starting from scratch.
  • String, Images and Resource Management: Every message presented and ultimately translated in an application is referred to in software terms as a string. An important and time consuming part of internationalization involves finding all the user-facing messages (but can also include things like interface sizing), extracting them from the source code, and placing them in some kind of repository files (or database) appropriate to the software architecture. That way you can work on translating the words without breaking the source code. With the right engineering those words can be replaced with any language that the application is supporting. Additionally, string management includes issues like sorting, string concatenation and the like. You’ll also want to identify and manage any images that are embedded in the code (just like strings) so that they may be localized as necessary.
  • Locale-limiting functions: Each programming language has its own set of functions or methods that do things like limit the way a date is interpreted, or how many bytes a character can contain. There are hundreds of these sneaky little things in C/C++ and there are dependencies based on your character encoding choice (e.g. Unicode UTF-8). Other programming languages such as Java and C# have less of these issues, but still have their own possible pitfalls. These functions need to be found and replaced with others that support the locale requirements that will be needed.
  • Locale-limiting programming patterns: Programmers may do many of the right things in terms of extracting strings, using functions that support “wide” characters and the like, but it’s still easy to get in trouble. Think of programming patterns as logic created for a specific application, which doesn’t work once you include issues around multiple locales. Programmatic sorting logic is a good example; a typical developer would sort by alphabetical order rather than by character brush stroke. Programming patterns can be a big nasty area to re-engineer, and it takes experienced examination and planning to manage.
  • Locale operators: Simply determine how the software will detect what locale it needs to support and how it will behave under the circumstances. For instance, does the user manually choose the locale, or does the application check the operating system setting?
  • Third-party product limitations: Most software makes use of other application components. These can include databases, reporting mechanisms (i.e. Crystal Reports), email generators and more. Often these components have their own internationalization support issues, which can create their own challenges to the software developer.

Client requirements: who needs what, when?

No two globalization challenges are the same, but obvious similarities in client requirements are worth examining. In general, a few familiar business events and issues lead to an often frenzied, time-critical push for combined localization and internationalization efforts. According to Lingoport’s Asnes3, these include:

  • 1. Somebody sold something that requires multi-locale support… A classic example is that the company gains a business contract that will necessitate supporting Japanese or another language. In some cases we’ve seen new license deals for entire countries, such as in health care or education. It’s a big hurry up to meet the customer demands.
  • 2. Localization is realized as a competitive necessity. Perhaps the company has already invested in global sales efforts and finds growth is limited given a poor competitive position without internationalization.
    A global company has just purchased another company or intellectual property and wants to make the new product useful for its worldwide sales efforts and product line.
  • 3. The CEO is mandating a new global initiative. This is an important new step for the company’s evolution. You can’t go to a management conference these days without hearing about globalizing revenue opportunities and for good reason.
  • 4. How best to approach the problem becomes the pressing issue. The answer rests in the resources and experience available within the firm. Assuming that localization tasks are outsource (a nearly universal approach, since even the largest firms can’t justify in-house translation teams), the difficult decisions revolve around the very different resources required for internationalization, a specialty that’s seldom supported in-house.

Specifically, engineering and top management must analyze a) if there are idle engineering resource available to tackle internationalization code remediation tasks, and b) if there are, whether those resources have the requisite experience to do the job in a timely, effective manner. Generally, the answer is no.

It’s a matter of time (to market)

Another challenge is that internationalization requirements are often misunderstood and underestimated. How should a globally inclined firm evaluate the merits of combining internationalization with their localization plans?
In brief, the promise of internationalization is that it simplifies, shortens the duration, and reduces the risk of every localization project. But the greatest impact lies in the potential for increasing top and bottom line results by enabling businesses to achieve their international goals sooner, with higher quality and lower support costs. In this light, internationalization becomes a strategic component of every globalization effort.