Internationalization

We've had a fantastic meeting yesterday. Although we did not get past even the first item of agreeing on the bigger picture, we've cleared a few misunderstandings, agreed on some of the bigger plans and discussed some interesting options for those where we do not yet agree. It was also great to get on the same page with several cross-initiative details. You can find the chat log attached, but here are some highlights for those who could not attend, could use a summary and/or don't have time to read all the log through.

One thing I don't particularly like about the Drupal multilingual support is that it lacks a possibility to have separate settings for the UI, both backend and frontend, and the content. Personally I would prefer to be able to set a default language for the UI on a site, but be able to access content in other languages I understand as well.

After installation of i18n I setup my "article" content-type to be translatable. I have activated the "URL" language negotiation. After translating node/17, I get a new node/18. I activate the language switcher, which links from node/17 to da/node/18. Unfortunately, with the language prefix, this returns a 404.
Manually removing the path prefix from the URL shows the node as expected.

This seems like a bug, but maybe some configuration that I don't understand/find is necessary?

Judging by the low number of comments (zero AKA nil) on my post on how custom user editable data in Drupal 7 modules are now localized and my commentary and Drupal 8 proposal there, I've decided to reformulate the basics of the ideas explained there with more of a focus on high level architecture questions.

Back in D5 or D6, we introduced a rule of "string freeze", meaning we would not change/add any strings in a stable release of Drupal that was not clearly a bug fix (and a critical bug fix, at that, iirc) lest poor, hapless end users do a minor update of core and be slapped in the face with English in their French/German/Swahili site.

I wanted to open this up for discussion up again now that we're in the age of localize.drupal.org. Is this formally hard-and-fast rule something we can look at loosening a bit? It would certainly put a lot more options on the table in terms of incrementally improving D7's UX, and also in terms of backporting non-backwards-compatibility breaking features (which is on the table for the first time in D7, thanks to the testing framework).

Here are a few specific examples that have come up recently:

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! To provide better visibility for this post, I'm also cross-posting on my blog, but commenting is only allowed here.

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.

http://drupal.org/node/1164200 - awaiting packaging.

Make your picks, vote on your favorite sessions!

Sessions focused on multilingual solutions, case studies and integration:

• Multilingual Drupal solutions: use cases and modules
• Building a forum for a multilingual discussion
• "Multilingual security": relaunching osce.org
• Integrating Drupal with the latest translation technology

Session referencing multilingual topics too (but not as their major focus):

• Multi-Site, when one core is enough.
• Evolving from Ubercart to Drupal Commerce

Did I miss any? Ps. there will of course be a core conversation piece at least on the Multilingual core initiative.