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.

Comments

drifter_'s picture

One of my peeves was having to translate the same word many many times because it was showing up in many different contexts: e.g. translating "Hírek" to "News" (using i18nstrings):

- as a content type title
- as a taxonomy term
- as a menu item title
- as a views title
- as a taxonomy term title replaced in views arguments
- as a panels pane title

And even then invariably it would still show up untranslated in several places, needing hacks to be translated properly. So having translation contexts can be useful if it's a linguistic context (as in "view" as a verb or noun), but it can make things difficult if it's just for technical reasons. Maybe there could be some UI to cover this up.

Won't be able to join you in Berlin unfortunately, but hope to join in when I can. Any IRC channels for the sprint?

Gábor Hojtsy's picture

Yes, we'll be in #drupal-i18n. I've added this information to my announcement post (linked above) and the sprint site has this info on a page linked from a sidebar menu.

Raphaël Vittet  "waykoolgeek"'s picture

I am currently learning Drupal to enable me to develop a great project for which multilingual features is critical.

Basically it's a project related to Brazil and should be up and running before the 2014 FiFA Football World Cup in Brazil and even in better shape for the 2016 Olympics in Brazil as well.

And guess what ? The dreamer outcome would be to just simply have my website in almost all the languages of the world !

To narrow perspectives I looked at the demographic figures to understand in which language my site should be in.

By selecting English, Portuguese, Spanish, German, French, italian that should be a start for Europe and Americas and part of Africa.
Adding Chinese-mandarin, Indi-Urdo, Arabic, Japanese and Russian I should be able to touch a big part of the rest of the world.

Then you might think that such need for multilingual is specific for a project like mine.

Total mistake.

Any company who want's to grow,
any community who want's to grow,
must have a multilingual site.

Even those who don't what to grow on a world global level
have to have a multilingual site.

The restaurant at the corner doesn't need it you think ?

Wrong.

Wrong because in many case the restaurants at the corners actually need to have their site in some other languages to attract the members of communities speaking other languages. You know, more languages you offer on your website more visitors you might have on your restaurant.

In Rio recently they opened a Chinese restaurant for Chinese business men.

You know if you are almost the only Chinese restaurant with a website in Chinese in Rio then the Chinese business men typing "Restaurant Brazil" in Chinese in their favorite search engine bar will surely find you.
You quite simply might be the most interesting place for Brazilian business men to meet Chinese business men.

Then maybe it's in your restaurant (with a Drupalized multilingual website) that will be signed the contracts which will shape the future of Brazil, China and the world.

You might think yeah, let's have multilingual super features in Drupal to satisfy those companies and communities of the world.

No, not sufficient.

You know what, the fastest growing number of people to use internet and website building in the next 3 years will be in India, China, Brazil ...

So the whole Drupal system, admin ui, community websites, documentation, video tutorials ...
Should be multi-lingualized.

Assuming every body will use English is wrong. The more user-friendly Drupal want's to become, the more widely adopted Drupal want's to become, the more multi-lingualized it has to become.

Every-lingual is at the core of the future expansion of Drupal.

Because the open source projects which will embrace every-lingual features fully will be the only ones remaining at the top 5 ranking of the most world most adopted CMS in 5 years from now.

(and if anyone interested in using my world-wide Brazilian project as a show case for Drupal every-lingual features is welcome the help me, as I am not gonna make it alone. Contact me at onewave@bluewin.ch)

Add new comment