Drupal 8

Up to date as of October 16th, 2015.

As I've outlined in the previous post Drupal 8 core now has 4 core modules to deal with language support. This tidbit will be about the simple language setup features provided by Language module, which is the base for every other language feature.

Image

Language module provides a simple language overview screen. You can reorder existing languages, remove languages (except the site default language, which on the screenshot is English) and add new languages. It is not anymore possible to have enabled and disabled languages on your site. This feature resulted in a confusing mess where some places and permission combinations allowed for the use of disabled languages and it was used as a means to stage certain new content. Just use proven content staging techniques (or unpublished posts) for new language content.

Up to date as of October 16th, 2015.

Once you install Drupal 8 in a foreign language, you'll have Language and Interface translation modules enabled with the chosen language configured. Drupal 8 has more core modules handling language related features, yet less requirement for contributed modules to be installed for the most important tasks (on my last count, the 4 modules explained here cover functionality of 20+ modules from Drupal 7 and in much better ways).

Why have multiple modules when a multilingual site just needs all the features? Well, there are also foreign language (not multilingual) sites that we aim to support better and multilingual sites can be very different as well. Also, admittedly there are technological reasons to organize the modules by the features they provide.

In Drupal 8 multilingual is one of the groups of core modules, so you'll find these modules under the main core modules in a neat group.

Image

Up to date as of October 16th, 2015.

Starting a new series

The Drupal 8 Multilingual Initiative was announced on May 9th, 2011. Since it's inception, the heroic efforts of people on the initiative resulted in hundreds of issues resolved but there are always more to perfect. We have made huge advances in terms of multilingual support in Drupal 8 thanks to all these changes and you can still help to make it perfect.

I'd love to highlight some of the great improvements that we made to make you excited about what is coming and point out some related places where you can still help to perfect what we have so far. This is number one in a series of short posts to discuss these improvements.

Language first in the installer

Drupal 8 makes language occupy the prominent first step in the installer. And compared to Drupal 7 where you were presented with a wall of textual instructions as to how to locate and download a translation file, place into a specific directory and reload the page, Drupal 8 comes with the realization that these are all tasks we can automate. So we show you about a 100 languages to choose from to install Drupal 8 in.

Image

The new Drupal version also comes with highly improved browser based language detection capabilities, so it will attempt to automatically identify your preferred language for this installation based on what your browser tells us. So in most cases, you'll likely just hit the button to continue and not think much about this.

We not only present you with the list of languages, we also download and import the translations to your system proper. So all the steps you did manually before are now automated. The installer can also fully show up in right to left languages.

Image

Also, if you pick a foreign language here, English will not be among your site's languages anymore either. Drupal 8's assumption is that if you install in a foreign language, you likely want a foreign language website without English showing up at all kinds of places as an option. Compared to Drupal 7 where English was not possible to remove.

I've had the pleasure to present the current state of the Drupal 8 Multilingual Initiative - great work of numerous highly respected individuals - just last week in Portland at DrupalCon Portland 2013. Although I did do live demos at previous editions of this session, at this point we have just too many great improvements, that it does not fit anymore. So for this session, I opted to provide a better overview and more context as to how this affects site building in general for Drupal 8, including the extent of change as it applies to contributed modules.

We are still working on several key pieces of the initiative, and will have meetings every Wednesday leading up to the code freeze coming July 1st, 2013. Join on our meetings to help with the remaining tasks. We have tasks for all experience levels!

Download the slides from https://portland2013.drupal.org/sites/default/files/slides/D8MI-Portlan…

Many of the Drupal 8 core APIs are shaping up now, and as Larry Garfield likes to say "we are still not ready porting Drupal 8 to Drupal 8". Meaning that the new APIs introduced are not used widely at all places where they would be applicable. Views is in core, but not all listings are views, router configuration instead of menu hooks are in core, but most modules use menu hooks, and so on. We of course target the final Drupal 8.0 release to have these conversions done, but we need more help to do them. Let me highlight items that interest me most as the multilingual initiative lead (but most of these rhyme with multi-channel publishing / web-services efforts as well).

Help convert content-like things to content entities

Drupal 8 has a new improved Entity API to manage content entities. What better opportunity to get to know the new content handling APIs than being involved in porting core components to it? Web services and multilingual are both fundamentally in need of a unified handling for content-like stuff in Drupal.

Comments have already been converted to the new entity API (http://drupal.org/node/1778178) which can serve as an example for conversions elsewhere, namely nodes (http://drupal.org/node/1818556), users (http://drupal.org/node/1818570) and so on. See the full list of conversion issues at http://drupal.org/node/1818580. Once these conversions are done, we still need to apply multilingual property handling to do such basic things as editing titles on nodes in different languages (http://drupal.org/node/1498674).

While the existing entity types need conversions, there are also other content-like things in core that need to be converted to entities proper. For example aggregator feeds (http://drupal.org/node/293318) have been converted to content entities but more needs to be worked on. Hands are needed to help with converting menu links (http://drupal.org/node/916388) and custom blocks (http://drupal.org/node/1871772) as well.

Learn Drupal 8 configuration by porting things to the configuration system

The new configuration system in Drupal 8 is great in unifying all configuration elements under one system instead of custom one-off database storages and APIs for configuration.

There is a laundry list of system settings forms to convert to configuration at http://drupal.org/node/1696224 including locale module settings, file system settings, etc. still to be done.

Drupal 8 also comes with configuration entities, which store their data with the configuration system (and are not fieldable). Some of the previously custom coded features such as views, menus (http://drupal.org/node/1814916) and contact form categories (http://drupal.org/node/1588422) have been converted to configuration entities. Others like languages are still to be done (http://drupal.org/node/1754246). Track all related issues at http://drupal.org/node/1802750.

Learn the new configuration schema system by writing schemas for configuration

A configuration schema system was just recently added to core (see http://drupal.org/node/1905070 for documentation and examples). Some configuration files got a schema defined in the initial patch, but there is still more work to be done to adopt this and complete. For example, only some of Views got schemas written, and we need to complete that (http://drupal.org/node/1910606). The meta issue to track and find schema issues is at http://drupal.org/node/1910624.

Why get involved?

I think this is a unique opportunity to (a) get to know Drupal 8 early (b) still have a chance to shape things in Drupal 8 where you find them confusing (instead of bragging about them too late when there is no chance to change) and (c) help Drupal 8 become the great consistent platform we all want it to become. Better web services features and dramatically more extensive multilingual features are also a huge plus!

How to get help if you get stuck?

Most of these issues have someone who got it started and you can find the people who worked on previous complete conversions that I linked to above. Find these people on IRC, get involved in virtual meetings, ask at core mentoring hours. Sometimes all is needed is reviews, help testing or help writing tests.

Thanks for all your contributions!

I've had the pleasure to present the results of the Drupal 8 Multilingual Initiative - great work of numerous highly respected individuals - at the start of this month in Berkeley at BADCamp 2012. The session has some great demo content about where did we get and background information on what is still to be done. We are pretty close with all the essentials but will not be bored for the rest of the Drupal 8 release cycle either to put on more polish and fix the rough edges. Meet us this Friday, the last day before the Drupal 8 feature freeze if you want to get involved!

The content translation problem

One of the great goals of the Drupal 8 Multilingual Initiative (D8MI for short) is to have one unified system for content translation. The basic problem is that with Drupal 7, you have two ways to translate content: copy nodes for different language versions (with the built-in Content translation module) or save different languages under one entity (with the built-in multilingual fields capability). Although the later does not have a user interface in core, the API is there, so well respecting contributed modules need to support both. The reality is that many modules support neither, because node copies are combersome and field language support is painful.

This is both a user and a developer problem. Users need to decide their translation methods up front, and both methods have their advantages and limitations. Node copies allow for best workflow because they have authors, publication status, permissions, core search support, etc. all a given. Field language on the other hand works better with relations (when signing up for nodes, putting nodes into a common menu, etc.) as well as sharing values between translations (product images, non-translated attributes, etc.). The grand plan for Drupal 8 is to figure out a way for a system that marries the advantages of all as possible and have one better configurable system instead of two independent systems. This should make it easier for users and developers alike to work with multilingual entities.

This is an extremely simple idea, yet the implementation is lagging behind enourmously.

My last post where I've explained how Internationalization module re-implements some of Field API and where it does not do that it misses crucial functionality did not get much discussion. Therefore I decided to turn the key point at the end to the center of discussion: that either Drupal core will do fields for all user input (content and configuration alike, all through form your site name to your views empty text), or i18n module needs to do it in contrib. There is a clear need for input widgets, validators, permission handling, storage and output formatters and rendering used consistently. If it is not done by core, it will keep being a bolted-on half-failing approach despite best efforts in contrib. Please discuss at http://groups.drupal.org/node/154434

The other important post that we need your input on is about removing all UI strings from code. There are various issues with having them in code, while there are also various disadvantages to removing them from there. There are performance, translatability and even user experience concerns involved. This post is already getting some discussion, but we need much more. This could be a huge, fundamental change, so all your input is welcome. Don't say we did not ask you. Please discuss at http://groups.drupal.org/node/154394

Your input helps shape Drupal 8 and how Drupal supports building multilingual sites for years to come. Have your voice heard now!

There is great discussion forming on my previous posts on exportables and user provided text as well as the dangers of using t() for user editable data, and I can only hope we can keep that up! In that tradition, I'm cross-posting this piece to groups.drupal.org as well for discussion.

Regular readers could find this boring, but let's reiterate the three working modes that all objects should ideally be able to handle in Drupal to support multilingual site building.

1. Being able to mark an object as in one language.
2. Being able to mark an object as in one language and relate it to others as being a translation set. This is useful when you want to use the different language objects in different relations, track their history separately, have different permissions and workflows for them, etc.
3. Being able to translate pieces of the object that need translation and leave the rest alone. Load the right language variant of the object dynamically as needed. This is very useful for keeping external relations intact and sharing common fields between translations effortlessly.

There are certain things, where not all of these make sense. For the site's name for example, people would probably only use either (1) or (3). For a block for example, people should be able to use either based on their needs. (2) is useful to place blocks differently on translated pages, (3) is good to keep the placement consistent without effort. This can be different on a per-block basis. Same applies to nodes, menus, taxonomy, views, rules, and so on.

In my previous post titled Drupal's multilingual problem - why t() is the wrong answer posted on my blog and on groups.drupal.org for feedback, I've detailed issues with using t() as a translation tool for "user provided data". This post goes into some further details, a discussion of current solutions which could form basis for discussion of future solutions.

How can we even tell the difference between code and user provided translatables?

It is fair to assume that many multilingual sites will not have English as their default language (many not even as any of their supported languages), so we cannot assume that blocks, menus, and so on are entered in English. However, source code based strings are considered part of the user interface, and as such assumed to be written in English. What does this has to do with default configurations set up by modules and How do we reconcile this with the growing popularity of exportables and features (as in Feature module generated versioned export packages)? Let's look at these two questions.