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.
Major parts of the D8 multilingual system
The Drupal 8 translation system is planned to consist of three distinct pieces: UI translation, entity translation and configuration translation. Drupal already has a robust solution for UI translation, which needs some adjustments (the major discussion in http://groups.drupal.org/node/154394 got us some good ideas to rethink context, but the possible overhaul of this subsystem was not discussed). Drupal has API level support for entity field translation, but (a) the developer experience is not good as noted by Sun, and more education is to be done on the proper use of the API (b) the UI is in contrib and needs to be cleaned up and moved into core (c) title fields are not yet translatable, there is a contributed module solution that needs to move in some way to core. Finally, configuration translation is our biggest unknown, given that major parts of that underlying system are in flux, and the config and context initiatives punted on working on that part for now.
A summarized view of the main components (that was and is being discussed) can be seen at https://docs.google.com/drawings/d/1EJWdw8A_EF-bXwwnB4e4KGBXLRLXjFndvY2t... (this does not link out to drupal.org issues since many of the boxes are bigger to fit one issue and are broken down to smaller pieces - a graphing UI on top of drupal.org issues would be great :).
Whether we need two models for object translation
Entity and configuration translation have two models right now. One can be called the relational model, where you have copies of the objects (node, menu item, contact form, etc) and they are different translations of the same thing. The other can be called the in-object model, where you have one object (node, menu item, contact form, etc) pieces of which are translated for specific languages. The relational model was/is historically a good fit when you needed most of your properties separate, have different permissions for the different objects and separate workflows to be tracked. Separate objects allow for separate workflows, permissions, etc. Many site builders had issues with the relational model however, since many modules are not aware that translation relations exist and that is painful. There are natural use cases for both, and in-object translation in Drupal 7 with translatable fields made the relational model for entities skippable in many cases.
However, many things on entities cannot be separate per language. The Entity translation module works around this by multiplicating details like author information, creation date, etc. by language. Once/if every property can be made different per language and all relations of the entity can have a language associated, we can replicate the relational model. We discussed making properties like published, promoted, author, created date, etc. per language (but not making them fields). Damien and others pointed out they have use cases where field translation can act like the relational model, and we are looking forward to their writeups.
The fundamental argument against the relational model was that modules are not aware of it, so relating other things to the objects is broken. Once we move the translation under the object, the relations work, but they still are not language aware. For them to actually support language, they need to be aware of this anyway. With the relational model they need to be aware to relate to multiple objects, with the in-object model, they need to be able to relate to the object and the language. While it makes the default behavior more comfortable for modules without language support, it does not solve the language support problem.
We discussed that (unfortunately for us), the context and config initiatives punted on working on user interfaces for configuration for now. However Bojhan and Yoroy started a great discussion at http://groups.drupal.org/node/160144 about page structure configuration that is right in the middle of context, configuration and language support. We discussed that the configuration initiative so far considers that context-specific configuration variants will be possible. The extent of that is yet unknown. Whether permissions will be context sensitive for example (you can have different permissions based on your geolocation, time of day, or your preffered language) is in discussion. How can we build configuration user interfaces, that can configure different settings for potentially infinite combinations of contexts we don't know yet. However, if arbitrary context is supported for configuration, then language will be a piece in there. If not, we'd better start thinking of how we'll solve translation there, because i18n module's 80% is about translating configuration. Choice quote: "what's your site name for afternoon when the visitor is from Canada?". Larry noted that context specific configuration (possibly not to this extreme) will need to be supported for the use cases of Spaces and Domain and language should tie in there.
When we'll meet next
There were lots of other small pieces and we'll return to define some of the bigger pieces. Sun already started a discussion for re-architecting UI translation on the developer level at http://groups.drupal.org/node/160704 based on a discussion started at the meeting.
Your comments are welcome. I think it would be great to continue our discussions in about two weeks, will announce soon.