Localization strategies
NOTE: You must be an organization or space admin in order to set up localizations.
Overview
Locales enable you to maintain different versions of your content for different locales. Locales are language-region pairs which means you can have versions of your content for regional variations of the same language. For example, while German is a single language, there are many different German locales: de-DE for German in Germany, de-AT for German in Austria, de-CH for German in Switzerland, and so on.
Contentful provides an extensive selection of locales out of the box. However, you can also create a custom locale using Content Management API if you don't find the desired one in the list.
Localization approaches
The localization approaches you can take with Contentful are the following:
Field-level - A built-in localization pattern provided by Contentful out of the box that allows you to maintain multiple locale fields within an entry.
Entry-level - With this approach, different language versions of the same content are kept in dedicated entries.
Content type-level - Setting up a separate copy of a content type per each locale within the same space.
Space-level - Setting up a separate copy of all content content types in a different space, per locale.
Localization strategy criteria
When choosing a localization approach, the following aspects must be considered:
Governance - The ability to restrict users' activity to a given locale. For example, you would like to grant a user the right to edit one of the German locales or hide the Switzerland-Italian locale from another user - governance allows you to accomplish these tasks.
Asynchronous publishing - The ability to publish content in some locales but not others. This comes in handy when, for instance, a campaign is released in one locale before another.
Fallback behavior - Providing content of another locale when a target locale is empty. For example, for your Canadian-French locale, when it is empty, you would like to have France-French content take its place. Fallbacks make this possible.
Field-level localization
Field-level localization is the best fit for frequently publishing content in multiple languages at the same time - for example, when you to publish your translated content at the same time as your default language content.
Using this pattern, the fields of an entry are duplicated for each locale. For example, for an entry that hastwo fields - Title and Slug - there is a duplicate for each of them for every locale.
Here are the key charasteristics of field-level localization approach:
Publishing flexibility - With field-level localization, you can choose one of the publishing modes to either publish your content in all locales in one click or publish each locale independently:
Publish all locales - Intended for those content creation workflows where all locales must be published at the same time. Therefore, it is convenient to be able to click Publish once and have all locales available.
Locale-based publishing - Works for those content creation workflows where users need the flexibility to publish content asynchronously in each locale - e.g. when multiple editors work with different locales across multiple locations.
Granularity - You can configure specific fields on specific content types to support localization. For example, you set up a page for a Halloween campaign. In this case, you would like the page title to be localized but the event date field to have the same value of October 31 for all translations of this campaign page.
Editing experience - You can view multiple locales at once on the same screen in your entry editor page.
Governance - Roles and permissions are fully integrated into this localization pattern. Using custom roles, you can define complex settings for viewing and editing locales.
Fallbacks - It is straightforward to define what exactly the fallback locales structure looks like.
Entry-level localization
Entry-level localization entails setting up a content type that serves as the container for your localized content. Here is an example content type structure for an article with multiple localized versions:
A container content type "Article - Global" that has a text field "Title" and a reference field to link to the localized articles. For the reference field, localization is enabled.
A content type for localized content "Article - Local" that has a text field "Title" and a text field "Body". This content type would then be referenced in the reference field of the container content type "Article - Global".
In this example, the reference field is localized, not the text field. This way, the entry "Article - Global" refers to one "Article - Local" entry in U.S. English and another in German-Germany:
Pros
Versioning per market - You can support separate versions of your content for each market while also enabling your regional teams to work on their content autonomously.
Fallback - Same way as with field-level localization, the fallback structure can be defined straightforwardly.
Cons
Governance limitations - Unlike field-level localization, you cannot restrict a user to working with a specific locale. A user can create entries in any of the configured locales. However, you can mitigate this by preventing users from attaching those articles by setting up specific content permissions.
Content type- and space-level localization
For both content type- and space-level localization, the idea is to have a strict separation between locales:
Content type-level localization - Each new locale is a new copy of a content type within the same space. For example, you set up one "Article" content type for U.S. English and another one for German (Germany).
Space-level localization - For each new locale, a content model is copied to a separate space. For example, you can create one "Article" content type in the "U.S. English" space and a second "Article" content type in the "German (Germany)" space.
Content type- and space-level localization approaches share the same pros and cons.
Pros
Governance - With custom roles, you can allow users to edit some content types and restrict them from editing others. With space memberships, you can give your users access to some spaces but not others.
Asynchronous publishing - Entries from different content types can be published independently as can entries from different spaces. Additionally, content can have a different structure in different locales. For example, you are trying to model terms and conditions statements. The German (Germany) terms are exactly like the German (Austria) terms except that they require an additional clause. You can design content types to reflect this difference across locales, either within the same space (as in the content type-level localization) or across different spaces (as in the space-level localization).
Cons
The cons are related to the strict separation between locales:
No fallback behavior - Given that content structure can differ across locales, setting up a straightforward fallback behavior is challenging.
Content types synchronization across locales - It is hard to keep your content types synced across locales. This involves checking to make sure that content types resemble each other enough, but not too much - lest they become the same locale - and can occasionally be a manual process. Contentful migration tooling can help evolve content types and take some of the pressure off.