In computing, internationalization and localization (American) or internationalisation and localisation (British), often abbreviated i18n and l10n respectively,[1] are means of adapting computer software to different languages, regional peculiarities and technical requirements of a target locale.[2]
Internationalization is the process of designing a software application so that it can be adapted to various languages and regions without engineering changes. Localization is the process of adapting internationalized software for a specific region or language by translating text and adding locale-specific components.
Localization (which is potentially performed multiple times, for different locales) uses the infrastructure or flexibility provided by internationalization (which is ideally performed only once before localization, or as an integral part of ongoing development).[3]
Naming
The terms are frequently abbreviated to the numeronymsi18n (where 18 stands for the number of letters between the first i and the last n in the word internationalization, a usage coined at Digital Equipment Corporation in the 1970s or 1980s)[4][5] and l10n for localization, due to the length of the words.[1][6] Some writers have the latter term capitalized (L10n) to help distinguish the two.[7]
Some companies, like IBM and Oracle, use the term globalization, g11n, for the combination of internationalization and localization.[8]
Microsoft defines internationalization as a combination of world-readiness and localization. World-readiness is a developer task, which enables a product to be used with multiple scripts and cultures (globalization) and separates user interface resources in a localizable format (localizability, abbreviated to L12y).[9][10]
Hewlett-Packard and HP-UX created a system called "National Language Support" or "Native Language Support" (NLS) to produce localizable software.[2]
Some vendors, including IBM[11] use the term National Language Version (NLV) for localized versions of software products supporting only one specific locale. The term implies the existence of other alike NLV versions of the software for different markets; this terminology is not used where no internationalization and localization was undertaken and a software product only supports one language and locale in any version.
Scope
The internationalization and localization process (based on a chart from the LISA website)
According to Software without frontiers, the design aspects to consider when internationalizing a product are "data encoding, data and documentation, software construction, hardware device support, and user interaction"; while the key design areas to consider when making a fully internationalized product from scratch are "user interaction, algorithm design and data formats, software services, and documentation".[2]
Translation is typically the most time-consuming component of language localization.[2] This may involve:
For film, video, and audio, translation of spoken words or music lyrics, often using either dubbing or subtitles
Text translation for printed materials, and digital media (possibly including error messages and documentation)
Potentially altering images and logos containing text to contain translations or generic icons[2]
Different translation lengths and differences in character sizes (e.g. between Latin alphabet letters and Chinese characters) can cause layouts that work well in one language to work poorly in others[2]
Computer software can encounter differences above and beyond straightforward translation of words and phrases, because computer programs can generate content dynamically. These differences may need to be taken into account by the internationalization process in preparation for translation. Many of these differences are so regular that a conversion between languages can be easily automated. The Common Locale Data Repository by Unicode provides a collection of such differences. Its data is used by major operating systems, including Microsoft Windows, macOS and Debian, and by major Internet companies or projects such as Google and the Wikimedia Foundation. Examples of such differences include:
Writing direction is left to right in most European languages, right-to-left in Hebrew and Arabic, or both in boustrophedon scripts, and optionally vertical in some Asian languages.[2]
Complex text layout, for languages where characters change shape depending on context
Capitalization exists in some scripts and not in others
Different languages and writing systems have different text sorting rules
Different languages have different pluralization rules, which can complicate programs that dynamically display numerical content.[12] Other grammar rules might also vary, e.g. genitive.
Different languages use different punctuation (e.g. quoting text using double-quotes (" ") as in English, or guillemets («») as in French)
Keyboard shortcuts can only make use of buttons on the keyboard layout which is being localized for. If a shortcut corresponds to a word in a particular language (e.g. Ctrl-s stands for "save" in English), it may need to be changed.[13]
National conventions
Different countries have different economic conventions, including variations in:
Currency (symbols, positions of currency markers, and reasonable amounts due to different inflation histories) – ISO 4217 codes are often used for internationalization
In particular, the United States and Europe differ in most of these cases. Other areas often follow one of these.
Specific third-party services, such as online maps, weather reports, or payment service providers, might not be available worldwide from the same carriers, or at all.
Time zones vary across the world, and this must be taken into account if a product originally only interacted with people in a single time zone. For internationalization, UTC is often used internally and then converted into a local time zone for display purposes.
Different countries have different legal requirements, meaning for example:
Regulatory compliance may require customization for a particular jurisdiction, or a change to the product as a whole, such as:
Local customs and conventions, such as social taboos, popular local religions, or superstitions such as blood types in Japanese culture vs. astrological signs in other cultures
Business process for internationalizing software
To internationalize a product, it is important to look at a variety of markets that the product will foreseeably enter.[2] Details such as field length for street addresses, unique format for the address, ability to make the postal code field optional to address countries that do not have postal codes or the state field for countries that do not have states, plus the introduction of new registration flows that adhere to local laws are just some of the examples that make internationalization a complex project.[7][17] A broader approach takes into account cultural factors regarding for example the adaptation of the business process logic or the inclusion of individual cultural (behavioral) aspects.[2][18]
Already in the 1990s, companies such as Bull used machine translation (Systran) on a large scale, for all their translation activity: human translators handled pre-editing (making the input machine-readable) and post-editing.[2]
Engineering
Both in re-engineering an existing software or designing a new internationalized software, the first step of internationalization is to split each potentially locale-dependent part (whether code, text or data) into a separate module.[2] Each module can then either rely on a standard library/dependency or be independently replaced as needed for each locale.
The current prevailing practice is for applications to place text in resource files which are loaded during program execution as needed.[2] These strings, stored in resource files, are relatively easy to translate. Programs are often built to reference resource libraries depending on the selected locale data.
The storage for translatable and translated strings is sometimes called a message catalog[2] as the strings are called messages. The catalog generally comprises a set of files in a specific localization format and a standard library to handle said format. One software library and format that aids this is gettext.
Thus to get an application to support multiple languages one would design the application to select the relevant language resource file at runtime. The code required to manage data entry verification and many other locale-sensitive data types also must support differing locale requirements. Modern development systems and operating systems include sophisticated libraries for international support of these types, see also Standard locale data above.
Many localization issues (e.g. writing direction, text sorting) require more profound changes in the software than text translation. For example, OpenOffice.org achieves this with compilation switches.
Process
A globalization method includes, after planning, three implementation steps: internationalization, localization and quality assurance.[2]
To some degree (e.g. for quality assurance), development teams include someone who handles the basic/central stages of the process which then enables all the others.[2] Such persons typically understand foreign languages and cultures and have some technical background. Specialized technical writers are required to construct a culturally appropriate syntax for potentially complicated concepts, coupled with engineering resources to deploy and test the localization elements.
Once properly internationalized, software can rely on more decentralized models for localization: free and open source software usually rely on self-localization by end-users and volunteers, sometimes organized in teams.[19] The GNOME project, for example, has volunteer translation teams for over 100 languages.[20]MediaWiki supports over 500 languages, of which 100 are mostly complete as of September2023[update].[21]
When translating existing text to other languages, it is difficult to maintain the parallel versions of texts throughout the life of the product.[22] For instance, if a message displayed to the user is modified, all of the translated versions must be changed.
In a commercial setting, the benefit of localization is access to more markets. In the early 1980s, Lotus 1-2-3 took two years to separate program code and text and lost the market lead in Europe over Microsoft Multiplan.[2] MicroPro found that using an Austrian translator for the West German market caused its WordStar documentation to, an executive said, not "have the tone it should have had".[24]
However, there are considerable costs involved, which go far beyond engineering. Further, business operations must adapt to manage the production, storage and distribution of multiple discrete localized products, which are often being sold in completely different currencies, regulatory environments and tax regimes.
Finally, sales, marketing and technical support must also facilitate their operations in the new languages, to support customers for the localized products. Particularly for relatively small language populations, it may never be economically viable to offer a localized product. Even where large language populations could justify localization for a given product, and a product's internal structure already permits localization, a given software developer or publisher may lack the size and sophistication to manage the ancillary functions associated with operating in multiple locales.
Mojibake is the garbled or gibberish text that is the result of text being decoded using an unintended character encoding. The result is a systematic replacement of symbols with completely unrelated ones, often from a different writing system.
A text file is a kind of computer file that is structured as a sequence of lines of electronic text. A text file exists stored as data within a computer file system.
Windows-1252 or CP-1252 is a legacy single-byte character encoding that is used by default in Microsoft Windows throughout the Americas, Western Europe, Oceania, and much of Africa.
In computing, a locale is a set of parameters that defines the user's language, region and any special variant preferences that the user wants to see in their user interface. Usually a locale identifier consists of at least a language code and a country/region code. Locale is an important aspect of i18n.
In computing, gettext is an internationalization and localization system commonly used for writing multilingual programs on Unix-like computer operating systems. One of the main benefits of gettext is that it separates programming from translating. The most commonly used implementation of gettext is GNU gettext, released by the GNU Project in 1995. The runtime library is libintl. gettext provides an option to use different strings for any number of plural forms of nouns, but this feature has no support for grammatical gender. The main filename extensions used by this system are .POT, .PO and .MO.
International Components for Unicode (ICU) is an open-source project of mature C/C++ and Java libraries for Unicode support, software internationalization, and software globalization. ICU is widely portable to many operating systems and environments. It gives applications the same results on all platforms and between C, C++, and Java software. The ICU project is a technical committee of the Unicode Consortium and sponsored, supported, and used by IBM and many other companies. ICU has been included as a standard component with Microsoft Windows since Windows 10 version 1703.
A numeronym is a word, usually an abbreviation, composed partially or wholly of numerals. The term can be used to describe several different number-based constructs, but it most commonly refers to a contraction in which all letters between the first and last of a word are replaced with the number of omitted letters . According to Anne H. Soukhanov, editor of the Microsoft Encarta College Dictionary, it originally referred to phonewords – words spelled by the letters of keys of a telephone pad.
Pseudolocalization is a software testing method used for testing internationalization aspects of software. Instead of translating the text of the software into a foreign language, as in the process of localization, the textual elements of an application are replaced with an altered version of the original language. For example, instead of "Account Settings", the text may be altered to display as "!!! Àççôûñţ Šéţţîñĝš !!!".
Globalize is a cross-platform JavaScript library for internationalization and localization that uses the Unicode Common Locale Data Repository (CLDR).
The Okapi Framework is a cross-platform and open-source set of components and applications that offer extensive support for localizing and translating documentation and software.
Language localisation is the process of adapting a product's translation to a specific country or region. It is the second phase of a larger process of product translation and cultural adaptation to account for differences in distinct markets, a process known as internationalisation and localisation.
A template processor is software designed to combine templates with data to produce resulting documents or programs. The language that the templates are written in is known as a template language or templating language. For purposes of this article, a result document is any kind of formatted output, including documents, web pages, or source code, either in whole or in fragments. A template engine is ordinarily included as a part of a web template system or application framework, and may be used also as a preprocessor or filter.
The Translate Toolkit is a localization and translation toolkit. It provides a set of tools for working with localization file formats and files that might need localization. The toolkit also provides an API on which to develop other localization tools.
Gtranslator is a specialized computer-assisted translation software and po file editor for the internationalization and localization (i18n) of software that uses the gettext system. It handles all forms of gettext po files and includes features such as Find/Replace, Translation Memory, different Translator Profiles, Messages Table, Easy Navigation and Editing of translation messages and comments of the translation where accurate. Gtranslator includes also a plugin system with plugins such as Alternate Language, Insert Tags, Open Tran, Integration with Subversion, and Source Code Viewer. Gtranslator is written in the programming language C for the GNOME desktop environment. It is available as free software under the terms of the GNU General Public License (GPL).
A resource bundle is a Java .properties file that contains locale-specific data. It is a way of internationalising a Java application by making the code locale-independent.
Transifex is a globalization management system (GMS), a proprietary software, and a web-based translation platform. It targets technical projects with frequently updated content, such as software, documentation, and websites, and encourages the automation of the localization workflow by integrating with common developer tools.
Website localization is the process of adapting an existing website to local language and culture in the target market. It is the process of adapting a website into a different linguistic and cultural context— involving much more than the simple translation of text. This modification process must reflect specific language and cultural preferences in the content, images and overall design and requirements of the site – all while maintaining the integrity of the website. Culturally adapted web sites reduce the amount of required cognitive efforts from visitors of the site to process and access information, making navigation easier and attitudes toward the web site more favorable. The modification of the website must additionally take into consideration the stated purpose of the new website with a focus on the targeted audience/market in the new locale. Website localization aims to customize a website so that it seems "natural", to its viewers despite cultural differences between the creators and the audience. Two factors are involved—programming expertise and linguistic/cultural knowledge.
Social localisation (from Latin locus and the English term locale, "a place where something happens or is set") is, like language localization the second phase of a larger process of product and service translation and cultural adaptation to account for differences in distinct markets and societies, a process known as internationalization and localization.
In computing, a hardware code page (HWCP) refers to a code page supported natively by a hardware device such as a display adapter or printer. The glyphs to present the characters are stored in the alphanumeric character generator's resident read-only memory and are thus not user-changeable. They are available for use by the system without having to load any font definitions into the device first. Startup messages issued by a PC's System BIOS or displayed by an operating system before initializing its own code page switching logic and font management and before switching to graphics mode are displayed in a computer's default hardware code page.
↑ Esselink, Bert (2006). "The Evolution of Localization"(PDF). In Pym, Anthony; Perekrestenko, Alexander; Starink, Bram (eds.). Translation Technology and Its Teaching (With Much Mention of Localization). Tarragona: Intercultural Studies Group – URV. pp.21–29. ISBN84-611-1131-1. Archived from the original(PDF) on 7 September 2012. In a nutshell, localization revolves around combining language and technology to produce a product that can cross cultural and language barriers. No more, no less.
↑ "Concepts (GNU gettext utilities)". gnu.org. Archived from the original on 18 September 2019. Retrieved 16 September 2023. Many people, tired of writing these long words over and over again, took the habit of writing i18n and l10n instead, quoting the first and last letter of each word, and replacing the run of intermediate letters by a number merely telling how many such letters there are.
↑ Reina, Laura Arjona; Robles, Gregorio; González-Barahona, Jesús M. (2013). "A Preliminary Analysis of Localization in Free Software: How Translations Are Performed". In Petrinja, Etiel; Succi, Giancarlo; Ioini, Nabil El; Sillitti, Alberto (eds.). Open Source Software: Quality Verification. IFIP Advances in Information and Communication Technology. Vol.404. Springer Berlin Heidelberg. pp.153–167. doi:10.1007/978-3-642-38928-3_11. ISBN978-3-642-38927-6.
Smith-Ferrier, Guy (2006). .NET Internationalization: The Developer's Guide to Building Global Windows and Web Applications. Upper Saddle River, New Jersey: Addison Wesley Professional. ISBN0-321-34138-4.
Esselink, Bert (2000). A Practical Guide to Localization. Amsterdam: John Benjamins. ISBN1-58811-006-0.
Ash, Lydia (2003). The Web Testing Companion: The Insider's Guide to Efficient and Effective Tests. Indianapolis, Indiana: Wiley. ISBN0-471-43021-8.
DePalma, Donald A. (2004). Business Without Borders: A Strategic Guide to Global Marketing. Chelmsford, Massachusetts: Globa Vista Press. ISBN0-9765169-0-X.
This page is based on this Wikipedia article Text is available under the CC BY-SA 4.0 license; additional terms may apply. Images, videos and audio are available under their respective licenses.
