I've had the great opportunity to share my experience navigating the waters of Drupal core development at at DrupalCon Denver last month. My talk "Thrown Into a Shark Pond? A Guide for Surviving Core Development and Even Enjoying It" was possibly a little sensationally titled, although every Drupal core developers have their ups and downs and sometimes people do feel like they are in a shark attack. I planned to provide good ways forward from different ways that ideas can be blocked from inception through implementation to getting it into core.
When preparing for the session, I realized I'm going to explain a somewhat complicated tree with different decision points and states. I wanted my session to be a useful and clear explanation and let people focus on tips and tricks instead of piecing together this tree in their head, so I decided to design a handout for the attendees (PDF, 250k). This turned out to be pretty great I think, and I got lots of content feedback from xjm, webchick, Moshe Weitzman, Kieran Lal and even Dries at various stages of drafting it. (Getting it printed on-site was a herculean undertaking, but that is really due to the printing shop services available.) At the end, each attendee got a nice color copy of this that they could bring home (and the leftovers I had were distributed at the new contributors sprint at the end of the conference). After all I decided to not theme the talk or the handouts with sharks, in hopes that the handouts would be much more easily reusable later just as well.
After reviewing language support and translation for many of Drupal's pieces, we arrived at a pretty complex question, building multilingual navigation. The question is especially of importance because we often need to put translated content in menus, and the cross of translation of content and translation of menus can easily get us into the woods. Let's build some simple solutions for different use cases to see how to think of multilingual menus.
I know many of you faced the goal explained above. There are tools of different levels of involvement and there is of course no ready-baked answer to this question, but here is my best take so far for the current two active versions and Drupal 8 in development.
The three areas of Drupal language support
(A) First off, you can run a single language foreign language website without a need for content or configuration translation. Because the Drupal user interface comes in a flavor of English, you'll need to translate that. But all your content and configuration can be entered in your language, so you are fine there.
(B) Second, if you need to mark your content with language information, such as if you are running a multilingual blog, where you post in different languages, but will not translate your posts, you need language assignment with multiple language options.
(C) Finally, if you need to have the same content translated, the same navigation replicated or similar navigation produced for different languages, you need translation for your content and configuration.
The three types of data for Drupal translation
When it comes to translation, Drupal data can be separated to three buckets: (1) User interface (2) Content (3) Configuration. Drupal has very extensive support for user interface translation, I'd say too much support for content translation and usually not so bright support for configuration translation. Let's enumerate what Drupal has on offer for each piece.
As some of you might be aware, a group of talented and very determined people sprinted in Berlin about a month ago just to improve the i18n module for almost a week. A lot of great improvements made it in including tests, translatable contact forms and even some great usability improvements. Jose Reyero and Friederike Schmiedebach have great posts about the sprint.
My last post where I've explained how Internationalization module re-implements some of Field API and where it does not do that it misses crucial functionality did not get much discussion. Therefore I decided to turn the key point at the end to the center of discussion: that either Drupal core will do fields for all user input (content and configuration alike, all through form your site name to your views empty text), or i18n module needs to do it in contrib. There is a clear need for input widgets, validators, permission handling, storage and output formatters and rendering used consistently. If it is not done by core, it will keep being a bolted-on half-failing approach despite best efforts in contrib. Please discuss at http://groups.drupal.org/node/154434
The other important post that we need your input on is about removing all UI strings from code. There are various issues with having them in code, while there are also various disadvantages to removing them from there. There are performance, translatability and even user experience concerns involved. This post is already getting some discussion, but we need much more. This could be a huge, fundamental change, so all your input is welcome. Don't say we did not ask you. Please discuss at http://groups.drupal.org/node/154394
Your input helps shape Drupal 8 and how Drupal supports building multilingual sites for years to come. Have your voice heard now!