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.
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.