Localization refers to the adaptation of a product, application or document content to meet the language, cultural
and other requirements of a specific target market (a locale).

Localization is sometimes written as l10n, where 10 is the number of letters between l and n.

Often thought of only as a synonym for translation of the user interface and documentation, localization is often a substantially more complex issue. It can entail customization related to:

Numeric, date and time formats

Use of currency

Keyboard usage

Collation and sorting

Symbols, icons and colors

Text and graphics containing references to objects, actions or ideas which, in a given culture, may be subject to misinterpretation or viewed as insensitive.

Varying legal requirements

and many more things.

Localization may even necessitate a comprehensive rethinking of logic, visual design, or presentation if the way of doing business
(eg., accounting) or the accepted paradigm for learning (eg., focus on individual vs. group) in a given locale differs substantially from the
originating culture.

Definitions of internationalization vary. This is a high-level working definition for use with W3C Internationalization Activity
material. Some people use other terms, such as globalization to refer to the same concept.

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 is often written i18n, where 18 is the number of letters between i and n in the English word.

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 dependance 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.

Internationalization significantly affects the ease of the product's localization. Retrofitting a linguistically- and
culturally-centered deliverable for a global market is obviously much more difficult and time-consuming than designing a deliverable with the intent
of presenting it globally. (Think back to the Y2K effort and trying to "undo" two-character year fields that were built on the assumption of
"19xx").

So ideally, internationalization occurs as a fundamental step in the design and development process, rather than as an afterthought
that can often involve awkward and expensive re-engineering.