Comparing Multilingual Handling in Drupal 5 v. Drupal 6
How Internationalization Will Advance in the Next Release
Many people who’ve heard the buzz about multilingual features making it into Drupal core have asked me if they should go ahead with their multilingual projects on Drupal 5 or push them back to wait for Drupal 6 to be released. Of course there are many factors to consider, but with multilingual websites there’s no doubt that two big factors are workflow and contributed modules.
Jose just pulled together an excellent comparison chart that should help make that decision easier. The chart below compares the multilingual support with Drupal 5 to Drupal 6.
| Language Selection | Drupal 5 | Drupal 6 |
Improvement |
|---|---|---|---|
| Language configuration | Y | Y+ |
Extended language configuration with native name, RTL setting, configurable domain and prefix, and weight for ordering |
| Support for RTL languages | N | Y | Besides the RTL language setting, there's support for themes to switch the presentation direction |
| Configurable language negotiation | N | Y | Language can be chosen automatically by the system based on a number of options, including domain names, path prefixes, and browser language |
| Browser based language detection | N | Y | The browser language is detected automatically |
| Language switcher block | N | Y | There's a block for users to switch the page language as they're browsing the site |
| Multilingual content | Drupal 5 | Drupal 6 |
Improvement |
| Content language | N | Y |
It is possible to specify a node's language. |
| Content translations | N | Y |
Support for translating posts on the site to different languages |
| Language dependent path aliases | N | Y |
Different path aliases can be defined per language – i.e. 'inicio' and 'home' for the home page |
| Install system | Drupal 5 | Drupal 6 | Improvement |
| Web interface for string translation | Y | Y+ | Some performance and usability improvements in Drupal 6 |
| Multilingual requests | N | Y |
Localization system has been extended so it can translate texts now for more than one language in the same page request |
| Email notifications in user language | N | Y | Mail subsystem now supports a language parameter that makes it possible for users to get notifications in their own language instead of notification page's language |
| Language independent logging | N | Y | Logs are now stored independent of language so the administrator can later see them in their own language or any other |
| JavaScript localization | N | Y | JavaScript texts can now be localized |
| Localization with static strings | N | Y |
Localization system can be used for several strings with static texts and little performance impact |
|
Text groups for string translation |
N | Y |
Translation interface now has built-in support for multiple groups of strings |
13 Comments
Important question
These are indispensable features great to see, but I shall ask: does the core support means that not nodes/terms etc. but _strings_ are translated? Only this is approach _conceptually_ correct. Take i18n module for Drupal 5 for example. Translating a node/term means creating a new one with the new language and associating the translated nodes/terms. This contradicts to the semantics of localization (i.e., there is a single entity which has multilingual properties) and therefore makes many modules not cooperate with the i18n system (e.g. Taxonomy Defaults). Setting up truly multilingual sites with Drupal and maintaining its contents will be a nightmare, if not impossible, until this paradigm shift.
the drupal 6 version of i18n
the drupal 6 version of i18n will support both approaches: localizable terms and truly multilingual taxonomies.
There's already a beta version.
Wow.. those are some great
Wow.. those are some great additions that are going in! Awesome job, guys! And the timing couldn't be better either.
additions
As far as I see, it would be good idea, to highlight, what is *not* going to be translatable/localizable directly in Drupal 6 without contributed modules:
- site settings
- categories (taxonomy)
- user defined menus
- aggregator categories
- profile field titles and options
- content type properties
This is still a pretty long list unfortunately, so although we achieved a lot in Drupal 6, man core stuff does not have localization support. You will need to use contributed modules to translate/localize these to your liking.
I would also point out a small change in the Drupal 6 backend: the possibility to collect interface strings used on a page. This allows for better optimization of the interface translation cache as well as developing in-place translation modules (so when you see some untranslated string on the interface, you can translate right on the same page). These features are up to contributed modules to develop, but it is at least possible with Drupal 6.
There are also more performance related suggestions in the patch queue, mostly adding indexes, which could make the system more performant, and the queue is open for usability changes, so there is still room to improve Drupal 6.
Excellent! Just one
Excellent!
Just one question: is this comparison for just drupal core (both drupal 5 and drupal 6) or for drupal core + contributed module i18n?
It looks to me that i18n is incorporated into drupal 6 core !?
Nice work.
only core
The comparison deals with Drupal 5 and 6 core, without contributed modules. Not all of the i18n/localizer module functionality was built into Drupal 6 (because of time constraints), but the core pieces are included.
You will most probably need i18n/localizer (whatever gets updated for Drupal 6 and fit your needs) to build a truly multilingual site with Drupal 6.
Thanks
Thanks for the info!, really apreciate it.
Is all of that into core?
Paco
Gracias! Thanks! Merci! Choukran!
This post was most helpful and quite informative!
GREAT job and thanks for sharing.
é.
Upgrade path from current Dr5 + i18n modules to Dr6
For those of us who have grown to know and love the current i18n modules in conjunction with Drupal 5, are there things we need to be preparing for, based on the inclusion of base i18n features, to transition to Drupal 6? That is, will our using the current i18n contrib module make it difficult to transition to Drupal 6 given that many of the features (and I imagine codebase of i18n) will be part of core?
It's not like I plan on porting our site to Drupal 6 the moment it comes out, but if there's stuff I could be doing now to prepare (or that I can help in as far as documenting transition steps or such) I'd be happy to assist.
- jfr
I wish localization would be
I wish localization would be this simple in other CMS systems. Drupal is way ahead of the pack here in improving usability for all.
Most important of all: site
Most important of all: site name, site footer, costume menu titles and... aren't translatable out of the box or with any of the i18n-related modules. I mean, without a translated site name, An English/Farsi website won't make sense to me. Although with a bit of php knowledge you'd be able to accomplish what you want in drupal.
I'd like to add - as a Farsi language user, one of RTL languages - I don't have much of an option translating taxonomies into Farsi since browsers aren't quite familiar with UTF characters of Farsi in URL; it's already implemented in Wikipedia, however, the actual words and UTF characters won't show up in address bar (except for Opera 9).
status
Well, the i18n or localizer or views status is the territory of the respective maintainers. Some parts of i18n module got into core, so more contributed modules will support multilanguage features, but you will still need a module like i18n to support other essential multilanguage features.
So the not yet released i18n module for Drupal 6 might be broken or conflicting with the core features still.
There d6 version of i18n
There d6 version of i18n -most of it has been already upgraded- will include all update scripts.
The module will drop the parts already handled by core but, the core handling of multilingual issues is quite compatible, so I hope the upgrade will be smooth.