Localization and internationalization, what's the difference?

I was going to ask a question about preparing a desktop application to support multiple languages on the UI.

In my search for existing questions on the topic I was thinking the word "International", so I selected the Internationalization tag and read through some matching questions.

Eventually I realized I should probably be looking under questions tagged Localization instead. However it appears I'm not alone in getting these two terms mixed up.

So, what are they key differences between Localization and Internationalization?

Also, is a clear distinction between them really that important?

Internationalization (i18n)

the process of changing your software so that it isn't hardwired to one language/locale/culture.

Localization (l10n)

the process of adding the appropriate resources to your software so that a particular language/locale is supported. It's bigger in scope than just http://en.wikipedia.org/wiki/Language_localization" title="Wikipedia on language localization">this Wikipedia entry, but it's a good start.

The value of distinguishing between them is that (theoretically) once your program goes through the i18n process, you can then iterate many l10n processes as you need them; also, it's nice to be precise with language.

According to Apple:

> Internationalization is the process of designing and building an > application to facilitate > localization. Localization, in > turn, is the cultural and linguistic > adaptation of an internationalized > application to two or more > culturally-distinct markets.

Internationalization prepares your application for localization. For example, you might encode characters stored in your database in Unicode (utf8mb4 instead of latin1), moving strings to resource files, enabling the use of date, time and currency formats, etc.

When you wish to sell, for example, a Chinese version of your app, you'd then localize it by hiring a translator to build the zh-CN resource files, and use a new date/time/currency format.

L10n can sometimes show where your i18n has failed - for instance, where your dictionaries have a single entry for a word which is used as a noun and a verb in English which doesn't translate to the same word in another language, or UI elements/design are unsuitable for a culture (L/R orientation).

So l10n "generally" happens after i18n, but can feed back into your i18n and require further redesign, so you cannot consider your app fully internationalized until you've done a few localizations.

According to Wikipedia

Internationalization is the process of designing a software application so that it can potentially 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 adding locale-specific components and translating text.

Also, Localization (which is potentially performed multiple times, for different locales) uses the infrastructure or flexibility provided by internationalization (which is ideally performed only once, or as an integral part of ongoing development).

Lot of answers, lot of correct information, but my answer is little bit another point of view.

Internationalization - it is when developer does not have in code direct messages/error messages/buttons names/labels captions/etc in certain language but have a key which is passed to translation function, and translation function according to current user's locale will return final text in english/france/etc...
Translation function works with storage (db/files/associative array/etc).
Storage contains keys which is ussed in coode, and values, which is texts in certain language which application supports.

Localization - it is process of adding new values in new language (for example spain) appropriate to keys into storage without involving developer in this process.

For example, we have storage:

key   | english    | italian           |
------+------------+-------------------+
title | Welcome    | Benvenuto         |
agree | I agree    | Sono d'accordo    |
thank | Thank you  | Grazie            |

Internationalization it is using in code something like confirm(t(agree)); instead of confirm("I agree"); or confirm("Sono d'accordo");
Localization - it is add new locale to our storage, like:

key   | english    | italian           | spanish          |
------+------------+-------------------+------------------+
title | Welcome    | Benvenuto         | Bienvenido       |
agree | I agree    | Sono d'accordo    | Estoy de acuerdo |
thank | Thank you  | Grazie            | Gracias          |

and here developer don't need update code, translation function will correctly carry appropriate texts.

Globalization (G11n): is the process of developing and marketing multilingual software products to a global market.

The development of multilingual software currently goes through two phases: the first phase is internationalization, and the second phase is localization.

Internationalization (I18n): is the process of generalizing a product so that it can handle multiple languages and cultural conventions without the need for re-design (i.e. language & culture neutral).

Localization (L10n): is the process of taking a product and making it linguistically and culturally appropriate to the target locale (country/region and language) where it will be used and sold (i.e. language & culture specific).

It's very simple if you go by the below definitions,

i18n (internationalization) is the

> process of designing an application so that it has the > functionality to change to a different language without resorting to programmatic change of the application.

l10n (localization) is the

> process of creating the actual language-specific texts and formatting.

There are a few very good answers here, so I won't recycle them. However at some point, typically between internationalization testing and localization linguistic testing, internationalization and localization tend to overlap. One person mentions l10n feeding back to internationalization, but if you are doing quality i18n testing, and creating pseudo-localized content, then iterating on development issues during localization should be the exception, not the rule. Interface resizing, and particularly adapting pages to support bi-directional languages like Arabic and Hebrew also tend to blend both localization issues and internationalization engineering.

Suffice it to say, Internationalization involves making changes to the source to support any locale based on requirements. If internationalization is done well...

...Localization involves the adaptation of the content and some levels of presentation (e.g. a bold tag) so that it best addresses needs of specific targeted markets (locales).

Lots of articles & white papers for reference here: http://www.lingoport.com/software-internationalization-articles

Internationalisation - i18n - The abstraction of an application from any particular language/culture.

Localisation - l10n- Plugging in the concrete support for a particular language/culture/locale to the above i18n framework.

Basically by doing i18n first you make l10n much less of a PITA.

In contrast if you create an application in a concrete locale first and then later try to internationalise it, it will be a massive PITA. Its not a simple matter of just swapping out a concrete english string say "Hello World" to Resource.Global.HelloWorld.

Different languages will have different space requirements, layout, emphasis, colours etc.

You need the i18n framework in place from the ground up to easily support this switching between locales for the above differences if you even think you may need to support more than one locale.

Retrofitting it into the application later on is just really hard. You will have to revisit a whole host of architectural considerations and constraints you (or someone else) made the first time round.

Lets understand locale first

locale - 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 identifier and a region identifier.

i18n - Designing and developing software to support multiple locales.

l10n - This is possible only when your software supports i18n. But l10n makes sure, that language, date-format, currency formats etc are shown in context for a specific locale.

For example,

#1. June 3, 1977 will be translated to Spanish as 3 de junio de 1977.

#2. Currency in some countries are separated by '.' vs ','

#3. Show respective currency symbol based on locale's country

#1, #2 and #3 are use-cases for localization.

If the software is designed to support #1 OR #2 OR #3 based on user-locale, then product is l10n enabled.

If it supports multiple locales then its i18n enabled.

I feel localization can go without internationalization but.. internationalization with localization should not be done...

analogical pov: Imagine a shelf on your library that can only take one size book 4x4 inches. Internationalization would be building the shelf with all kinds of different compartments that can allow it to handle any book size or shape. And localization would be setting all the books on the right sections. Think of your Database, business logic and UI as the shelf and the different languages, currencies and text orientation as the books.

Simply,

Internationalization(I18N) is the process of making your software able to adapt to different languages, regions, and cultures.

Localization(L10N) is the process of translating your software into multiple languages. But before you can localize your software, you internationalize it.

There are many definitions of i18n and l10n. The one I use are :

internationalization (i18n) : language specific adaptation of your application (translation)

localization (l10n) : locale specific adaptation of your application (money, number format, date format ...).

For example, we can have the same language for an application distributed in France and in Switzerland (we both speak french, at least in some parts of Switzerland), but we will still need some adaptation to change EUR to CHF.