How would a Drupal multilingual solution look like?

A few years ago, when I started working with Drupal I was needing some multilingual blog to publish about my work and thoughts in two languages. Then I started this Internationalization module which I've been maintaining for all that time. Now, 7 years and a lot of versions later, it is still is quite hard to build a multilingual site with it.

There is a reason for this -someone would call it an excuse- and that is: Internationalization module is not a multilingual solution. It is an API module, or a toolbox, to build many of these different solutions. Just like Drupal is not a web site, but the tool to build thousands of different great web sites.

'Yes but, How does a multilingual solution look like?'

My favorite example, the one I use for some presentations is this old piece of stone dating from 193 B.C. called Rosetta Stone, written in Egyptian hieroglyphs, demotic script, and Ancient Greek. Yup, 3 languages, 100% translated, 2000 years old, and great usability.

Now, back to 21st century, Drupal and modern content management systems, how could we upgrade the Rosetta stone to work on the digital world?

The basic problem is that many nice features are only useful for a specific user story, actually being a problem when you try to build a different one with your modules. Most of the time some features and nice UI widgets make sense for a specific web site (that have a goal, an audience, etc) but they don't make sense at all for a single module that tries to serve a much wider audience. That's how we get tons of patches and feature requests we need to drop because they are just not generic enough or they make way too many assumptions.

First of all, we need to wrap our minds around a specific user story. Building solutions without a specific goal in mind is mostly useless.

User story 1: A multilingual one-person blog.

Yes, like this humble web site.

Here, only one person that speaks two languages (or one and a half to be accurate) maintains a small web site with posts in two languages. So there's one single authenticated user, that is also the site administrator. One person writes and translates it all.

Also, there are posts in two languages, but just a few of them are translations. Most often, there are blog posts either in English or in Spanish that don't even need translation, as they're just for different audiences (which may be a good excuse to be lazy, ok).

The multilingual UI I'd need for this one is the simplest one, with everything being written and translated on the same place. In this case it makes sense to list everything mixed on one page (I.e. I have a small taxonomies with mixed languages) and if possible to have everything translatable on the very same place.

User story 2: A multilingual huge organization publishing site.

I am not talking about any specific site, but you can think of this big AI site.

This site has a lot of content written by many different people, speaking many different languages. Some people writes and some people translates. Translators or content writers don't need to speak all the languages on the site.

For a case like this you'd need a language oriented translation UI. Say I am the Arabic translator (I wish I'd speak Arabic which I don't). Then I would need just some page where I can see everything that is pending translation into Arabic. Or I could have the Arabic version of the site with some 'translate' link (just for this language) on everything that is not translated.

For a big site with a lot of content you also need some more complex translation workflow. Say we have a piece of content that is already translated, then it is updated, then the translation needs to be updated accordingly. If you multiply by 4 languages and few hundred pieces of content, now you need some specifically designed UI.

Conclusion

Both user stories are multilingual sites. Both are powered by i18n module. Still, the content workflow and the UI for each is completely different. Moreover, UI improvements that are good for one of them (like editing all the languages on the same page) may be counterproductive for the other.

These are just two stories. I could write more, like the story of that European Union site on which everything needs to be translated into 23 languages before it gets published (23?, I hardly keep the count). Yes, just like the Rosetta Stone but we'd need a stone a few meters high in this case. Anyway, the whole point is that there are more than one case, which I think we've already seen.

Then, if we want to build a multilingual solution, we need to think about a user story and that will determine the workflow and UI we'll need. We cannot build a 'good enough for all' multilingual solution.

Modules like Internationalization, if they aim to be reused by these quite different sites, need to focus on what they do -making things translatable in this case- and better make no assumptions about the site workflow or the UI you'll need. Though it may be OK to provide some very basic UI to have at least one way to translate different things, some 'UI improvements' like having a column on the same page to translate to every language will just break when you have 20 languages.

Still I don't know how a web site would support Egyptian hieroglyphs, so I hope we don't really have to build a web site to replace the Rosetta Stone.

By the way, there's this Drupal Internationalization sprint coming, in Berlin, 11-15 May, that I plan to attend. We'll be working on multilingual modules and multilingual solutions for a few days and I hope we can build some real solution there. Auf Wiedersehen!