Drupal 8

Drupal 8's Multilingual Wonderland session video from BADCamp

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!

Just 4.5 months until feature freeze, all hands needed to help with multilingual content in Drupal 8

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.

On using fields API for every input in Drupal and removing translatable strings from code

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!

How to make a Drupal 7 module i18n enabled and what does that teach us for Drupal 8?

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.

User provided vs. code provided translatables and translation sets

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.