Up to date as of October 16th, 2015.
The first eight parts of this extensive series explained several great improvements in the base language system in Drupal 8, then we had five articles explaining all the great new software translation features. We are far from done yet! We still have two major categories of improvements to cover, namely content and configuration language and translation. Before we move on to the details, I wanted to post an introduction because there are very similar motivations and guiding principles around the improvements we made and this is going to make your life way easier compared to Drupal 7!
The glue module maze in Drupal 7
Drupal core in Drupal 7 provides translation capabilities for nodes, but no other content or configuration. Want to translate your blocks or taxonomy terms or menus? No luck. Unfortunately the base system does not understand or support multilingual content and configuration for these, so the rest of the modules cannot depend on that or know what to assume.
In Drupal 7 taxonomy terms are entities, but you have two choices to translate them. Either use the entity_translation contributed module (and the title module) or the i18n module suite. Both attempt to augment the system from the outside to apply their translation scheme on taxonomy terms, and other modules are not really aware of this. Display caching or taxonomy term lookup or autocomplete would not be naturally aware that there may be language concerns involved.
In Drupal 7 menus or blocks are not even entities, so they map to the generic i18n_string service provided by i18n module with their own respective mapping modules (i18n_menu and i18n_block).
Site settings like your site name or user account emails are not exempt from the need for glue modules. The variable suite of base modules are needed to provide the generic API that i18n_variable module will use to provide translation for these variables.
Once you get into contrib land, eg. translating views or webforms, yet more glue modules are needed. For Views, you need i18nviews, for webform, you need webform_localization (note the lack of consistent naming scheme).
These modules provide different levels of integrations and varying user interfaces to support your translation needs. The combination of the original modules as well as i18n, title and variable and the glue modules for each contrib module to make them work with this system ends up in a pretty sizable solution. It works in the end, but this is not what we aim for in Drupal 8.
Drupal 8 has general base solutions in core
Instead in Drupal 8 the configuration and content system is (almost) all encompassing, so you mostly either work with a configuration (entity) or a content (entity). Content entities all have fields. They at least have base fields, but most support configurable fields, so you can customize fields on blocks or taxonomy terms. Both base fields and configurable fields come with native support for multilingual storage, editing and rendering. When you deal with a node or custom block, you can equally have the fields set translatable.
This was made possible by the incredible effort of the configuration management initiative to get a generic configuration system in core and apply it to almost everything that cannot be considered content combined with the huge work of the entity system maintainers and application of the content entity system to much wider systems in core.
When common base systems are used, we don't need specialized mapper modules (and a separate system to map to) to maintain translation information and even contributed modules will be aware of the possibility of language variance and how to deal with it. The common base systems are also great when you need to write code against contact categories or block placements, you can use the same APIs and expect identical behavior.
Best of all, contributed modules applying the same base systems will not stand alone, they would use best practices built in core and work automatically with translations for configuration and content. No need for specialized systems and glue modules!
The extent of multilingual support for content and config
You'll read a lot more about these details in later tidbits. If you don't understand these, that is normal, just wanted to give a quick summary and heads up for what is coming.
The configuration system has full support for multilingual override values, so all elements stored in configuration may have language variants. There is also a contextual access system for configuration, so you can load values with specific language overrides, etc. These overrides are stored with the configuration and are fully deployment friendly as well. Default (shipped) configuration is translatable with the interface/software translation system. Such as shipped Views, content types, fields, etc. This works for all your in-house modules as well as contributed modules. Finally, there is a configuration translation user interface in core that provides a translation user interface almost fully automatically for your configuration (given the developer provided configuration schemas). Just covering these details will take up several tidbits so hold on for the details!
The content entity system also became really impressive. With several elements converted to content entities (menu items, contact forms, custom blocks, etc.) and fieldability available almost universally, storing multilingual content with content entities is natural. Fields provide native multilingual storage and core has a new content translation module that serves a user interface for this functionality applying to all content entity types.
So what is content and configuration then?
I made the following figure to illustrate how the entity system as well as configuration and content relate.
Basically in Drupal 8, there are some configuration elements that are global, but most that you will encounter are itemized and therefore use the configuration entity system. Then almost everything else is based off of the content system. The good news is multilingual coverage is going to be fully available for all of the configuration pieces and content elements. So long as your contributed module or custom code is outside of these APIs, you'll be on your own for multilingual coverage. (Core has path aliases for example which have a custom implementation, but that retains multilingual coverage as a custom implementation.)
Embrace the improvements
For your multilingual needs, the emergence of a generally used entity/field system and a unified configuration system are a bliss. To build new code against these will require less learning and more widely accessible knowledge, and to support foreign language and multilingual sites will be natural due to the base systems doing the heavy lifting. This is just not possible with Drupal 7 however hard we try.
Read on with the upcoming tidbits for more details and insights!
Yet another great article.
Yet another great article. Thanks.
Drupal 8 Hello World module with config_translation support
I have prepared Hello World module with translatable configuration: http://drupal.stackexchange.com/questions/87922/add-multilingual-support...
Any reviews are welcome!
that post reflects current reality
Thanks for doing that post! Good stuff!
At the time of this comment posting your code seems as good as it can be :) The configuration translation API may change somewhat which is one of the main reasons it is not yet covered in this article series. So your code may need some updates, but generally doing the schema is going to be the same and the connecting .yml file may go away in favor of other means of discovery (not yet 100% certain). See https://drupal.org/node/2095289 and https://drupal.org/node/2095291
Module will be updated
Of course this module will be supported on GitHub to be useful on Drupal 8 release day. I also plan to extend this module with Entity Translation examples and some language related stuff. Maybe it will be merged with Examples-8.x later.
If my English was better, I'd suggest my work as a guest post :)
Config Management Initiative: language domain override
I have been following the thread that I started regarding "Language domain to be overridden in settings.php" and was wondering if CMI allows an elegant and workable solution?
Yes, CMI makes it possible to override any config value in settings.php and language settings are now in CMI, so this will be possible.
Add new comment