Extending Drupal World Domination with better multilingual support

In 2003 I selected Drupal to replace an aging PostNuke system on a Hungarian web developer community site (weblabor.hu) that I helped ignite a few years before. Of course I needed it fully translated to Hungarian. If you were using Drupal back then, you may remember that adding a new language to your site meant running ALTER TABLE queries on your locale tables to add new columns, editing your settings file and handling database dumps of your translations (which was the only way to share them too).

Drupal has come a long way since then.

The localization system has had key contributions from Gerhard Killesreiter, Marco Molinari, Kristjan Jansen and myself to become a more user-friendly system supporting industry standard Gettext Portable Object files for transport and a user interface to manage languages and translations. It was further improved in later releases to serve as a language selector for the rest of Drupal and got more versatile options in Drupal 7 thanks to Damien Tournoud and Francesco Placella. The friendliness of the central translation interface for the software improved a lot through the years thanks to Bruno Massa, Young Hahn, Jose Reyero and Konstantin Kaefer and we just had a Google Summer of Code student signed up named Adam Lippai to improve it even more.

With the user interface translation well taken care of, multilingual support for other Drupal components came from contributed modules. Drupal 6 had a big multilingual focus with Jose Reyero and myself leading the introduction of translatable nodes and paths in core. The rest of the work still lay on Jose’s Internationalization module to fill the gaps. Various modules sprung up to help tie other projects into the multilingual feature set, like i18nviews, and arguments started to include multilingual support with popular modules like webform.

With Drupal 7, while I was busy working on general usability improvements, Franceso Placella and Daniel Kudwien took the helm, refactored the language selection process and added translatable field support among other things and now work on the excellent Entity translation and Title modules.

There has also been lots of activity lately with companies like Icanlocalize and Lingotek providing high end Drupal content translation services for enterprises. We can learn a lot from their experience too.

With more and more functionality in core, and more key contributed modules used by site builders, you need an increasing number of supporting translation modules and there is a definite need to improve them. For Drupal to step up its support for multilingual sites, I think we need to improve in various areas:

1. We should take a hard look at the many ways different portions of a Drupal site are translated in the backend. With changes in Drupal core, do we need all of those solutions to exist?
2. Examine the user interfaces and workflows involved in translations. Making a Drupal setting or block or node multilingual all follow entirely different steps and workflows in the Drupal administrative user interface. We absolutely need a strong UX focus in this area to resolve issues. Our biggest concern is that we cannot make assumptions about how a specific site implementation needs to configure translations, and different setups need different workflows, but I’m certain we can come up with better defaults.
3. Educate module developers and maintainers better about multilingual needs. This starts from basics like text contexts for UI strings and reaches into data storage and translation-enabling guidance. Whatever we do in core and in the couple contributed modules, all the rest need to support multilingual to be useful. We need well defined and useful patterns that are hopefully easy to implement.
4. Educate site builders better about the tools available and the useful tricks people use. A great example is a Drupalcamp Montreal 2009 session from Suzanne Kennedy and Alex Dergachev, where they share some tricky (and sometimes a bit ugly) hacks they made to work around certain limitations. As much as we should work to make complex tricks unnecessary, I think we should take their example and do a better job of sharing them when needed.
5. Finally, we should not try and implement for an imaginary Drupal 8 only. Drupal 7 is out and around, and I think the ways we go are better validated in the wild as we put some of them into Drupal 8, so we know we are going in the right direction.

I believe it is clear that this job is way too big for the few dedicated people mentioned above (even as I might have missed some of you, for which I’m very sorry). The tasks range from architecture review, UX efforts, pattern building and documentation to coding. We need people all around, and this is not just about one new shiny feature, it is an effort that should cross thousands of modules as well as Drupal core. The task is big, but the rewards are even higher.

I hope everyone working on multilingual Drupal solutions can find their place in this effort and we’ll see more people contributing.

For those who can help with documentation, module updates and new module writing, Karsten Frohwein is organizing a Multilingual Drupal code sprint that is just coming up in Berlin from May 11th to 15th. Virtual participation is very welcome. I’ve also started a Drupal 7 multilingual support matrix that should eventually provide an overview of the various modules and how they fit into the translation scheme. Please help filling in the gaps and adding modules and solutions that you know of.

Watch this space for more ways you can get involved. I’m excited to work more on this now as part of the Drupal 8 Multilingual core intiative, so see you around in the discussions and issue queues.