This is about current status of multilingual features in Drupal, how they play together and some proposed approach to have them fully integrated in Drupal. A complete report on this subject, which I hope will be improved with your feedback and some more discussion, is available here: Drupal: i18n Report [Development Seed]

Currently, we have the 'locale module' -core-, which deals with language management and interface translation and 'i18n module', which provides support for multilingual content, translations, but also some language management, providing a block for the users to select interface language.

This is some mixed approach, that is somehow confusing, causes some overlapping and wouldn't be there if we had some clean off the ground implementation of multilingual features in Drupal. This proposal would be in the line of providing this kind of implementation, with some support in core, and some lightweight modules/APIs managing very specific parts of the whole 'multilingual' system.

Though the Internationalization module will be updated for Drupal 4.7, the long term goal of this module is to provide multilingual support for Drupal in a way that can be later somehow integrated into Drupal core. I don't mean it could be just dropped into the core as it is now. I wouldn't pretend it to be 'core quality' code, and worse, it has an important number of hacks and workarounds just to avoid core patches.

What I mean is that it's proven to be a workable and consistent approach to the problem of managing multilingual content in Drupal. And it's about time at least some part of it can be integrated into the system, thus providing some generic support for multilingual objects which could be available for other modules to take advantage of it.

The main question about any future implementations in order to achieve a truly multilingual Drupal is how much -limited- support should be built in into the core, how much in core modules, and how much can be provided by contrib modules.

My premise here will be *Let's not have in the core things that don't need to be there*. Ideally, as I see it, there should be some limited support in Drupal core, then some functionality that can be enabled as a core module, and then some contrib modules providing specific features, but that don't need to patch the core because we already have some language-oriented pluggable support already built in into Drupal.

While it may seem that any part of the functionality may be implemented either as a core module or as a contrib module indistinctly, the distinction between 'core modules' and 'contrib modules' is actually crucial because of the policy of 'not having specific functions in Drupal core for calling non core modules', which anyway is a good policy IMHO.

Of course, there are some other views on how this can be achieved. So this is only one proposal and one invitation for people to provide feedback on this issue, and open up the discussion about whether the time has come to have a true multilingual Drupal.

So first, let's make it truly multilingual. Then... world dominance ;-)

Comments

JordiTR’s picture

Hi José and everybody. Thanks Jose for your contribution.

Are we still discussing why Drupal should be multilingual? Is not Drupal comming from Europe? How many countries in Europe have two or trhree (or sometimes even more) official or co-official languages? Which company on a non-english country is going to do a web site only on its local language? We need multilingual support for yesterday, or other open source CMS systems will cover this niche. Specially on the enterprise arena not being easily multilingual is enough to not being considered. All that IMHO :-)

richie’s picture

IMHO: every good CMS should be multilingual from ground. I'd vote for internationalization in core.
--
richie

Jose Reyero’s picture

> Are we still discussing why Drupal should be multilingual?

No, actually what we are discussing is 'how' it should be implemented. And how we can have a clean, consistent implementation that makes everyone -well, most of the people :-) - happy...

JordiTR’s picture

> No, actually what we are discussing is 'how' it should be implemented.

Ah! I just hope it doesn't take too long... ;-)

simplulo’s picture

Bèr also posted about the new i18n direction:
"Drupal and i18n, the holy grail?"
http://www.webschuur.com/node/525

After the i18n work for 4.7, is the way fairly clear?

What can ordinary mortals do to accelerate this? Find you manpower, money, or pizza?

elv’s picture

As an European webdesigner I think at least a basic level of multilinguism should make it to core. It's crucial !

So, what is a basic level ?
- translate every content in other languages
- set a default / fallback language
- choose how to handle pages not in the language you selected : do you display them in the fallback language, or do you make them invisible ?

It look pretty much like Jose's i18n module : the same site for every language.

More advanced levels could be handled by contrib modules :
- specific contents for different languages (no translation required)
- different settings for subsites
- translation for custom fields, blocks, everything
- different versions of attached files or links (ex: PDF files in the right language if available)
- etc.

quetzal’s picture

I totally agree with your "basic level". Something I am missing in the i18 module is your third point : I'd like pages that are not translated to show either in English or in their original language.

Christina N’s picture

I think you are doing a great job with this, and your proposal sounds fine to me.
I believe it's a good idea to not have more in the core than what really needs to be there as well.

Christina, Web Developer currently working on the lose 30 pounds project.