Core

You did not read that wrong! Yes, Drupal 8 features are frozen, and the massive Drupal 8 Multilingual Initiative is not there to let you even translate a node title or the site name. We made massive amounts of progress with heroic efforts from key contributors, but we are not nearly close to be done yet. Yes, your help is needed! The way the Drupal core release cycle is set up, many things that you might consider features are not classified as such (verified with core maintainers) in the process. Feature freeze means all base features should be in core, however, many things that need to be integrated with these new features are not done yet. Otherwise what would we do for months on still, right? So let's look at the two use cases with this in mind. Start with the bad news!

Translate site name

The biggest feature that will still not be native in Drupal 8 is translation of user provided configuration. We still have lot to work on translating shipped configuration. We've worked hard for months to get a configuration schema system accepted so we can have a programatic understanding of the translatable pieces of configuration. We started work on that in 2012 June at Drupal Dev Days, and it took several forked issues, alternate proposals, personal, IRC and phone meetings to get a universal understanding that a configuration schema system is needed in the first place, with the actual implementation not too far from the original proposals, that landed in core. We would have loved to achieve this milestone sooner but that did not work out.

So the sad news is you will not be able to translate your site name or custom created Views with Drupal 8 core only. Drupal 8 core should be capable to translate shipped configuration though, that is email texts, image styles, default content types, default fields, etc. shipped with Drupal core. The text for these should eventually end up on http://localize.drupal.org for translation. You'll need to use a contributed module to translate user entered configuration though (such as user created Views and your site name). Good news is that the underlying schema system and the configuration override system in core (as well as the soon to be committed configuration context system) supports this use case too, so the missing piece is a user interface to be generated for configuration translation. A very early version of that user interface can be seen in http://drupal.org/sandbox/reyero/1635230.

So as of right now you cannot even translate the shipped email texts, but that is a feature targeted for Drupal 8 core (in combination with http://localize.drupal.org as usual for software translation). Translating configuration created on the user interface and not shipped with modules/themes/profiles will need a contributed module.

Translate node titles

All right, this is a flat out regression, right? Right! Drupal 8 trades node-copy translation that is native to Drupal 7 (using the Content translation module in Drupal 7), where translating a node creates a new copy of the node. In Drupal 8, the module named the same on the user interface (Content translation) works totally differently. It does not create new copies but stores translations in fields under the entity. This has several advantages. For one, it lets us support all kinds of entity types, for example, fields on users, taxonomy terms, comments, etc. We also provide a neat cross-entity configuration screen to set up all your entity types for language.

Yet, node titles remain non-translatable. The basic reason for that is that node titles are not "fields" on nodes, they are good old properties. Properties do not support multilingual storage natively. We introduced a multilingual property system earlier (for the entity_test entity type), and the integration to other entity types did not yet happen. Why? Well, the more sweeping next generation Entity API conversions are still widely underway. Comment entities are done (with performance regressions that are being worked out) and we are hard at work on nodes. There are still files, users, taxonomy terms, etc. ahead.

And then the multilinugal property conversions can happen on top of the new entity system much easier since that system has built-in support for them. That is still not a trivial task and we'll definitely need all hands possible to achieve.

(Side note: once node properties become multilingual, we also need to provide a migration path in core for the legacy content translation module and remove that module from core for good.)

How can I help?

The configuration schema system is easy! We have documentation at http://drupal.org/node/1905070 and a visual configuration browser that applies the schema at http://drupal.org/sandbox/reyero/1635230. There is a huge set of issues at http://www.drupal8multilingual.org/issues/schema to fill in the blanks of schemas where not yet provided or incorrectly written. Tips to help are in the meta issue at http://drupal.org/node/1910624#comment-7088154

The entity API conversions are more involved work. You can participate in the conversion issues at http://drupal.org/node/1818580 - however the process so far has been to attack one type at a time, and nodes are in focus righ now (http://drupal.org/node/1818556). Performance expertise, reroll experience and all kinds of other skills are needed here.

So how can you call Drupal 8 feature frozen? And when will it ever be ready?

Reality is features from the point of the development process are not necessarily the same as user's perceptions. While we wanted to get in solutions sooner (eg. targeted configuration schema and context for Dec 1st 2012), their declared belonging to a later development phase does not help to get reviewers and push them harder for inclusion. We are doing our best to not let this affect the eventual readiness of Drupal 8, but in the state we are in, we are not looking at an integration phase where we can sit back and relax.

The current planned deadline for the integration phase (when all entity properties should be multilingual and all configuration should have schemas) is July 1st 2013. There are three big sprints until then that we plan to use to boost our standing (please come and sign up for these):

• Drupal sprint weekend, March 9th and 10th all around the globe
• Sprints on the weekends both before and after DrupalCon Portland, May 18-19th and 24-26th
• Sprints all week before Drupal Dev Days Dublin, June 24-27th

Sitting around and waiting for later opportunities does not help, so jumping on these issues would be especially helpful. If you have no better idea, start reviewing the configuration schema issues today!

A huge thanks once again for all contributors

I'd like to reiterate once again that all the people on the multilingual intiative worked exceptionally hard (in some cases all the way to burning out) to make Drupal 8 as multilingual as possible for you all. The gaps in implementation are not at all due to people doing poor work, they are due to all the uncertainties involved in working on an Open Source project with set goals but heavy interdependencies and lack of resource commitments possible. As well as all the bliss and baggage of making large scale decisions in an open issue queue format.

See http://www.drupal8multilingual.org/team for more information on our team.