Page 1 of 4   next page »

Much time, energy, and commitment are required to develop and sell successful software products and Web-based services. Most products of this type are initially developed for a specific language and locale (e.g., U.S. English). To maximize return on investment, products can be customized so they may be available to the largest possible market - the global market. This customization process is known as localization.

Localization includes not only translation of the displayed text, but also adaptation of a product to comply with a country's cultural and legal practices. Examples of cultural conventions include date/time formats, postal address formats, font sizes, appropriateness of colors, numeric or currency formats and symbols, culturally appropriate icons or graphics, etc. The diversity of software platforms and technologies means that tools and technologies that support localization are also diverse and are frequently incompatible with each other. Industry standards drive process and technology efficiencies, and OASIS XLIFF (XML Localization Interchange File Format) has emerged as a standard interchange file format for localization-related data and metadata. This article will introduce the process of localization and summarize the challenges and issues facing those who localize. It will illustrate how XLIFF addresses many of the challenges and issues with descriptions of its architecture, provide examples of how to use it in real life, and discuss how it was developed and where it goes from here.

Localization: A Brief Overview
Having a product available in a different language increases the potential market into which it can be sold. Microsoft, IBM, and Oracle earn more than 60 percent of their sales from international markets. IBM recently reported that 70 percent of Web users speak a primary language other English. Within the United States, 18 percent of the population speak a language other than English at home. The Canadian Translation Bureau has reported that Canada represents 4 to 8 percent of the global translation services market with only 0.5 percent of the world's population.

The software localization industry was born in the mid 1980s as a result of the personal computer revolution. Early projects were very engineering intensive. Software developers would usually throw the final version of the application over the proverbial wall and expect the localization team to do the rest. The user interface and functional code were in the same file, which meant that functionality problems would often be introduced during the translation process. Before translation could begin, a software engineer would first need to change the character set code pages to ensure that software could be translated into the target language. Separating code from the UI required significant software development and localization resources. Physically and logically partitioning the UI data into separate resource containers reduced the severity and frequency of functionality defects introduced by the localization process.

The introduction of the Unicode character set standard and the growing emphasis on internationalization as a standard component of the software engineering practice was a very significant benefit to reducing the time and cost of localization. Internationalization is the process of developing software in such a way that it can run in different international environments without adapting or recompiling the code. Unicode introduced a common character set code page, and it is one of the corner-stones of software internationalization. The World Wide Web Consortium's (W3C) specifications and guidelines have addressed localization issues such as the separation of code and UI, character set issues, and date and time formatting. Cultural and economic factors are motivating many organizations to design and adapt their products for delivery to the global markets.

Today global markets are not content to wait months or even weeks for locally adapted software to be made available to them, so localization must now be done in parallel with the core product development. "Throwing software over the wall" to be localized after a product is sold is no longer an option.

The Internet introduces new challenges into the localization process by enabling more complex distribution models. Products and content are rolled out simultaneously throughout the global markets. The proliferation of diverse architectural frameworks and technologies upon which Internet and e-business applications are built has resulted in different degrees of complexity in both the core development and in localization.

Throughout its history, the localization industry addressed these business challenges through improvements in tools and processes delivered by competing vendors. Their solutions addressed specific technical or process requirements, but were rarely interoperable, which often resulted in vendor lock-in. With XLIFF, the localization industry got together to find a solution to some of the challenges that the industry is now facing.

Localization Challenges Addressed by XLIFF
XLIFF has already provided solutions to difficult localization challenges, including the following.

Challenge: Many different file formats to localize - The typical localization project is composed of data stored within many unique resource formats. Building tools to support the localization of these formats is costly and inefficient.

Solution: Transform or extract all localizable resources, regardless of native format, into XLIFF containers. For example, before XLIFF existed, one major database and enterprise software vendor localized 32 unique resource formats. Some of the formats were proprietary, others were legacy, but most were industry standards (i.e., Java List Resource and Property Resource Bundles, Windows RC Data, .html, .jsp, and various XML). Additionally, each new release introduced additional resource formats, usually XML-based, but each required extensive retooling of the localization tools, which lead to quality problems and scheduling delays. To reduce the retooling work and its consequences, the core development teams were given the responsibility of extracting or transforming the new resource formats to XLIFF before handing off for translation. Three years and three major releases later, the number of unique resource formats supported by the localization tools was reduced from 32 to a much more manageable 17. Additionally, by adopting XLIFF, the tools development team was able to shift resources that had been dedicated to retooling onto building new cost-saving enhancements such as XLIFF's built-in suggested translations features. Listing 1 is an example of a Java properties file and its XLIFF representation.

Challenge: Lack of version management metadata in native resource containers - Localization projects often run concurrently with core development projects, which means that resource files will be made of up of multiple versions or milestones. Version management at the segment level (a segment is the smallest discrete unit of translatable text) is a very useful feature if your goal is to maximize the reuse of previous translations. Web content is often dynamic, and multilingual content must be kept in sync in order to maintain quality. Few if any native resource containers provide a means of tracking the version of the content.

Solution: XLIFF provides metadata structures for tracking versions of source and translated content.

Challenge: Lack of workflow metadata in native resources - During the localization process, data passes through many different hands. Data to be localized is typically externalized by software publishers and handed off to a localization service provider, who in turn may hand it over to translation subcontractors. At each stage of the process, the types of data required are unique to the particular phase (source/target text, Translation Memory, Machine Translation, Termbase, etc.). Introducing automation into a development process saves money and resources and improves quality by ensuring the reproducibility of the process. Native resource files don't usually contain mechanisms for tracking the stage of the process at which changes were introduced to the localization process.

Page 1 of 4   next page »