Internationalization and Localization#

Internationalization is the process of preparing an application for displaying content in languages and formats specifically to the audience. Developers and template authors usually internationalize the application. "i18n" is shorthand for "internationalization" (the letter "I", a run of 18 letters, the letter "N").

Localization is the process of writing the translations of text and local formats for an application that has already been internationalized. Formats include dates, times, numbers, time zones, units of measure, and currency. Translators usually localize the application. "l10n" is shorthand for "localization" (the letter "L", a run of 10 letters, the letter "N").

Plone fully supports internationalization and localization.

See also

Wikipedia article Internationalization and localization

Code versus content#

We categorize the things that we want to internationalize and localize in a Plone application into two groups:

  1. Code-level elements. This includes translations of the user interface elements' text strings and localization. The tools used in this group include gettext, Plone and Zope i18n facilities, and react-intl. See the chapter Translating text strings.

  2. User-generated content. For translating user-generated content, Plone uses the package plone.app.multilingual. See the chapter Translating content.

Common concepts#

When you internationalize and localize a Plone application, there are some common concepts used throughout these processes.

Terms#

The following terms are used in this documentation.

locale

A locale is an identifier, such as a language tag, for a specific set of cultural preferences for some country, together with all associated translations targeted to the same native language.

language tag

A language tag is a string used as an identifier for a language. A language tag may have one or more subtags. The basic form of a language tag is LANGUAGE-[SUBTAG].

See also

.po

Portable Object (PO) file. The message file format used by the gettext translation system. See https://www.gnu.org/savannah-checkouts/gnu/gettext/manual/html_node/PO-Files.html.

.pot

Portable Object (PO) template file, not yet oriented towards any particular language.

.mo

Machine Object file. The binary message file compiled from the .po message file.

Locale and language tag conventions#

Plone uses certain conventions for its locales and language tags.

  • When identifying a language only, use two lowercase letters. Examples: en, de.

  • When identifying a language and a country, use two lowercase letters, an underscore (_), and two uppercase letters. Examples: en_GB, pt_BR.

  • When identifying a language and script or character set, use two lowercase letters, an at sign (@), and four title case letters. Example: sr@Cyrl.

General procedure#

Note

This section concerns only code-level translations of text strings.

For user-generated content translations, see Translating content.

In general, the process of internationalization and localization of a Plone application follows these steps.

  1. Create translatable strings in your code. Plone has already done this step within its core code. However, when developing new features or add-ons, you will need to perform this step.

  2. Find and extract all translatable strings from your code with a script, and create a .pot template file out of all these.

  3. Create the .po files for all locales.

  4. Edit the .po files, adding the translated messages into them.

  5. Turn the .po files into .mo files.

  6. Compile and link the .mo files with the gettext library.

See also

Overview of GNU gettext

Implementation details#

Depending on which part of your Plone application that you internationalize and localize, there are different implementation details and tools that are used. These differences depend upon the programming language, either Python or JavaScript, being used by that part.