There is often a big confusion, and misuse, of the terms i18n and l10n. They are related, but don't have the same meaning; they refer to different levels of implementation and expertise, so proper understanding is important to see where exactly a problem, or development need, belongs.
What those acronyms mean
Well, what do those strange acronyms actually mean? In fact they are abbreviations composed of the first and last letter of a word, and in between there is the number of letters.
- i18n = Internationalization: i, then 18 letters, then n
- l10n = Localization: l, then 10 letters, then n
Isn't that the same?
So, you may ask, isn't internationalization and localization the same? Actually, no.
There is a lot of confusion; in part because the concepts are relatively new; in part also for historical reasons. Historically, support in computers beyond English-only has been done, in the beginning at least, as several ad-hoc solutions, that fitted a single language only. So you had that OS localized for, say French, and that other version for Spanish; and they may well be incompatible even if both languages can actually share a common character set (and a quite simple one).
Said otherwise, historically l10n has been done before thinking about i18n.
But, conceptually, i18n must come first; as internationalization is the process of ensuring a piece of software is actually flexible enough and ready to support multiple potential locales in the first place. No actual language is involved in the i18n process; an application may well never be translated, but if it is properly internationalized then translating it is quite easy (and, more importantly, doesn't require any development or computer skills at all, only knowledge of the target language). Internationalization, then, is making software locale-friendly.
Localization on the other hand is all about (mainly, see below) translating to a given, real, language. Localization, per se, doesn't require internationalization to be done, however if the application hasn't been internationalized first, then that means the localization process would involve quite low level modifications in the source code of the application; that is, development skills. In old times (old old times, most of you don't know about; lucky you) localization was sometimes done by "simply" editing the source code and changing in-source the text strings. That lead to two (or more) different binaries; that is two (or more) different products to support, with different versioning, bug tracking, etc. Sometimes even incompatible with each other. And, if you wanted to port the application to another language, it had to be done all over again (and decided from which version to diverge). Plus, there was never a proper generalizable overview of the problem; if localization to a new language with some specific needs was requested, it could well break everything because it hadn't been planned for.
So, l10n without i18n is bad, very bad. Hopefully, nowadays, and particularly in the free software world, this is uncommon. In our free software world we have very good internationalization frameworks, built into the core of the common toolkits (a toolkit is a set of tools and bricks that developers build applications from). Those frameworks are generic enough to support and encompass all human writing systems currently in use.
The two concepts of i18n and l10n are two different layers. They are interconnected, but they are at different levels - that is, they involve different people, with different skills. That is important to know, as reporting a problem at the wrong level won't help it to be solved.
Internationalization is the process (or the concept of the process) to make an application "international"; that is, make it able to support virtually any language or local setting on Earth.
It always involves changes in the source code, that is it involves developers (who need to be also knowledgeable of the i18n problematic). There are various aspects of i18n, some more complex than others:
- ability to display/print text
- support for any complex font
- support for character normalization
- support for glyph susbstitution and rendering (there is no equivalence between character and glyph; instead some sequences of characters (can be a sequence of just one in simple case) produce some sequences of glyphs (may be a sequence of one in simple case)
- support for glyph reordering (display is not always on the same order as logically spoken/written)
- support for bidirectional rendering (both left to right and right to left)
- ability to manipulate text
- support for text string manipulations in programs
- support for mouse selection, cut and paste, etc (note that you select glyphs on screen, but the buffer selects text (characters) => complex substitution involved)
- character set conversion utilities (because we have to cope with pre-unicode legacy)
- searching text (grep, etc)
- sorting text depending on complex rules
- ability to enter text
- support to define keyboard layouts
- support for hooking with input applications for complex cases where a keyboard mapping isn't enough)
- ability to manipulate/render date/time
- display/input format
- defining first day of week
- defining timezones
- defining non-gregorian calendars
- functions to convert between different formats/calendars
- ability to define and handle local settings
- different units (km/miles °C/°F, etc.), monetary, etc
- different ways to format/display numbers
Localization is the process (or the concept of the process) to make an application "localized"; that is, work for a given local and concrete context, adapted to the user.
It doesn't involve any change in the source code; developers are not involved (well, only a bit, just to add the first hook; when a language is available, a developer has to put it in a list, give access to l10n team, etc).
L10n is about providing the content to fill the containers that the i18n process created.
The various aspects are:
- translating translatable text data (that is the most famous one)
- providing unique localized text data (not a translation of an existing one, but an independent one), if appropriate
- spell checkers (see below)
- keyboard layouts
- input methods (see below)
- sorting rules
These don't involve developers, as I said. Well, in some cases there may be some development involved; it is for some highly specific things, like the creation of a new spell-checker, unique to a language or family of languages, or an input method program (but generic spell-checkers and input methods also exist, where you only need to provide l10n data).
- l10n: l10n problems are only of concern to translators of a given language; nobody else cares or can do anything about it; only the translators for that specific language can fix it.
- i18n: i18n problems are a problem in the i18n infrastructure; it potentially may impact a lot of languages (even if maybe only one actually spots the symptoms), but translators cannot do anything to solve it, only developers can.