Internationalization (i18n)

Internationalization is the work of making software or content ready for other languages and regions before anyone translates it. The W3C defines it as the design and development of a product, application or document content that enables easy localization for audiences that vary in culture, region or language. Localization is the step that follows: adapting the product for one particular market.

Why it is written i18n#

The W3C's article also explains the abbreviation. Internationalization is long, so it is shortened to i18n, the 18 being the number of letters between the first i and the last n. Localization becomes l10n the same way. A word shortened by counting its letters is called a numeronym.

What internationalization covers#

The W3C lists four kinds of work:

1. Removing barriers to localization, such as text encodings that cannot hold every script; in practice, using Unicode throughout.
2. Supporting features a later language will need, such as markup for text that runs right to left and a way to say what language each piece of text is in.
3. Letting code follow local preferences: dates, calendars, number formats, sorting and the way names are written.
4. Separating the parts that get localized from the code, so a translated version can be loaded or chosen without changing the code.

Internationalization on a website#

For a website, the fourth item is the one people meet first. WordPress's developer handbook, for example, asks plugin authors to wrap each translatable string in one of its translation functions, with the plugin's text domain, and to translate whole phrases with placeholders instead of joining pieces; the string translation entry covers how that works.

The rest shows up later, when a translated page breaks. In a worked example, a shop template builds the sentence "3 items in your cart" by gluing a number to fixed English words. Translated piece by piece, the sentence comes out with the wrong word order or the wrong plural in a language that orders or inflects it differently, and a translator who receives the pieces separately cannot repair it, because the fault is in the template. A price printed as 1,234.50 in the theme's code looks wrong to a Dutch or Italian reader, who writes 1.234,50 or 1234,50. And a page without a correct lang attribute stops a browser from applying a language's rules, such as Turkish capital letters.

Where LangRelay fits#

LangRelay works at the localization end. It translates the text in your rendered pages, whether it came from the editor, the theme or a plugin, so a theme does not need every string wrapped before its pages can be translated. It also takes care of part of the website's i18n for each language version: the lang attribute on the page, the hreflang set, and an address of its own under the language's prefix.

What it cannot fix is a template that builds sentences from fragments or prints numbers in one fixed format. Those are internationalization faults in the theme, and they are worth fixing before you add languages. Website localization covers the step after i18n, and localization vs translation where translation ends inside it.