There are a lot of challenges in internationalization, after being involved in Drupal 7 trying to streamline some of these experiences. It would be great to expand this in Drupal 8 and make sure that we have a delightful multilingual experience, rather than a "you can actually do it now" kind of thinking.
After a meeting with Gábor Hojtsy, I'd like to give a quick summary what some of our ideas area in terms of focus and outstanding work. Where the biggest problem for me at least, is trying to build a picture what the landscape of multilingual is. Below you can see an illustration made by Gabor about the overarching parts of multilingual and how we wish to unify some of these in the initiative.
Any updates to this image will be on https://docs.google.com/drawings/d/1sWuEdI95WsI515ud8bI7860H__9c-i3gCpYR...
- UI translation
This is basically about updating core and any installed contribs. Currently core has little to no workflow for this, so the idea here is to bring l10n_update into core. This allows us to optimize two experiences 1. Installing a language, 2. Updating a language. Where as the first requires us to allow installing other languages during installation (browsing & downloading of them), the second requires us to make a workflow for updating contributed modules to there latest translations an easy process. - Entity/field translation
This ties into the conceptual problem found in usability testing that users do not perceive the page, as a view, a node, a block - but rather all parts of content. However the current multilingual concept provided, requires the user to use different tools for each one of these content parts. Many of them are not even supported in core translation (blocks). The idea here is to at minimum, unify the experiences of these different tools more (where to find them and their interaction patterns).But ideally tie in with Core Context UX: Page & Component library line of thinking, and provide one experience for the translation of all the different content parts. Related technical discussions on entities can be found at What else should be entities in Drupal 8?.
- Configuration translation
Translating something like the "site name", "anonymous user label" and "path of frontpage" for different languages is quite difficult. Many edge cases come in to play, but in general one can assume that doing this requires several contributed modules and some user knowledge about what configuration variable specifically they want to translate. To make this more complex, views can for example expose variables that need to be translated (sometimes several dozens/hundreds) do we want to expose all these for translations - or do they choose which one they want to translate?This is a very complex challenge and ties in deeply with how configuration handling will be done in the configuration initiative.
Approach
Each of these topics will be moving, from both a technical as user experience perspective. But both Entity/field translation and Configuration translation require decisions to be made in the context and configuration initiative. So for the next few weeks, I am going to focus on the UX of UI translation. - and continue being part of the discussions of Entity/field translation and Configuration translation.
I'd love to hear thoughts on whether this is the right approach, and whether the conceptual model described above is correct.
Comments
entities and configuration
For entities, we have a discussion at http://groups.drupal.org/node/155634 to make more things entities where it makes sense.
For configuration, we have http://groups.drupal.org/node/154434 where we discuss to introduce field-like concepts for configuration.
Generally, best for translation is if we can reproduce parts of UIs (widget, validation, etc) for translation, and can include that reproduction in a workflow. Field translation does that on a field level, Node translation (in core) does that on a node form level. Variable translation does that reproducing the whole settings form where you have one multilingual variable. Configuration translation does not / cannot really do that in Drupal 7. I think key to getting the UX closer is to being able to reproduce parts of the UIs more reliably, which the two links I've posted here aim at. Of course those are low level API type approaches, but have huge implications for the UX I think. Eg. if a block is an entity, the UX could be very different to what we have now.
About configuration
About configuration translation we are pretty close to being able to mimic current string translation (with a translation tab) for variables.
The key point for that is collecting metadata about variables and being able to reproduce variable edit widgets from metadata which I think we can already do for around 90% of variables, if variable metadata is declared by modules. The proposed solution is building upon this Variable module, http://drupal.org/project/variable
If you enable 'Variable admin' and try to edit the list of variables on generated forms Admin / Variables you'll see that we are pretty close. Still missing is complex validation and formatting for some of the variables.
Once we can produce widgets for all of the variables moving them to a 'translate' tab is a trivial question though still we need to figure out where to place that tab on a page by page basis, which may be difficult due to lack of consistency of current Drupal administration/configuration. Separating configuration and administration, which we dropped in latest versions of Drupal, was a helpful concept though maybe a bit difficult to grasp by new users.
issues
Drupal.org issues are being opened for separate parts at http://drupal.org/node/1260690 - "META: Improve multilingual user experience in Drupal 8"
current user experience plan
The current user experience pieces are as follows, to give an update for those who want to follow:
Language setup
Language negotiation/selection
The negotiation config is planned to stay largely the same with better defaults. We want to make it optional to configure content language separate, and:
UI translation
Make the UI translation page filters look / work similar to node admin page filters. We are building in l10n_update module, which will happen in steps, the current step being worked on is consolidating .po files into one directory, which has minimal UI implications but could be interesting: http://drupal.org/node/1260586
Content language / translation
In terms of the admin listing page, we want to make it double as a translation dashboard of sorts (or core will have no UI for that, we don't want to duplicate the node admin listing page) and we want to have search there to support translations (as well as every other use case :):
In terms of the entity translation itself, we want to expand field translatability to properties (or make properties fields), so every field/property will be translatable the same way. The UI for content translation as currently planned is being worked on in http://drupal.org/node/1282018 (to use a language-aware edit form instead of a specific translation form).
Configuration language / translation
We don't yet have good ideas as to how to approach this as we don't even know the underlying data layer and what that would allow us to do.
Language listing configuration
Finally, we want to make it possible to limit lists by language. Such as /node. Whether this is even possible in a sane way in core, we don't know yet.
Summary
Are we doing too much at once? Yeah! It so far proved to be successful though because people are interested in a different things. By keeping them engaged all at once, we make progress on multiple fronts and can be father ahead in less time. I don't want to force people to do stuff they don't want or wait around while others work on other things. So yes, we are working on various things that are touching the UI currently.
Crossposting the content
Crossposting the content language battleplan.