Localization
Introduction
All content can be localized. The available locales depend on the languages you have on your Drupal sites. They are propagated automatically to the Content Cloud when connecting a site.
The default language cannot be changed right now. If you don’t want to use English (“en” langcode) as the default, please let us know before we set up your space.
You are free to use any locale identifiers, but identifiers cannot be changed. We recommend using ISO-based identifiers like en or en-us. As the default locale cannot be changed right now, please let us know which locale to use as a default in that case (if it’s not en).
Fallback locales
You can change locales to have a fallback locale. By default, they will use the space locale as a fallback. You can add multiple locales as fallbacks for different layers of localization depth. E.g., for Spain, you may prefer content for Spain with a fallback to standard Spanish, with a fallback to standard English and then US English:
es-esesenen-us
Drupal integration
Language mapping
The languages associated with each translation are directly taken from Drupal. Missing locales are added automatically.
System types
Our system Tags and Assets are localizable as well; Tags are based on Drupal’s Taxonomy Terms and Assets are based on Drupal's File entities.
Locale correction for Drupal files
File entity locales are automatically adjusted based on the parent entity using the file. In Drupal, file entities have a langcode property because they are considered content entities, but files are not translatable and are always assigned the default langcode of the site regardless of what their actual language is. We auto-correct this to adjust the langcodes of the parent entities using the files (if there are any).
(i) E.g. The site's default language is English, and you create a media item in Spanish. When you upload the file to the Spanish media item, the file is stored by Drupal as an English file, which is counter-intuitive and may even make the file invisible depending on your locale fallback settings. That’s why Content Cloud stores both the media item and the file in Spanish.
Advanced
All content has two sets of properties: localized and non-localized fields. While from the outside they appear identical, they are treated as separate versioning spaces for content. If you only update non-localized properties, this will bump the entryVersion and if you only update localized properties, it will bump the localizationVersion. The entryVersion is shared across all translations. So if you publish a new version with updated, non-localized properties, all translations will receive the updated values automatically.
This independent handling of translations makes it possible to create and delete content in any locale, whereas in other systems like Drupal, you cannot change the default locale of content once it’s translated, as all fields reside in the same versioning space.