Following on a huge amount of discussion and planning at the Internationalization Group, Jose A. Reyero, Károly Négyesi (chx) and Gábor Hojtsy (myself) prepared a big patch to introduce better language support into Drupal 6.x-dev. We got significant code reviews and correction tips from Dries Buytaert, Steven Wittens and Doug Green. As a result, the development version of Drupal 6 now includes a generic language setup screen with support for right-to-left written scripts, native language names, path and domain based language selection and browser language detection. We also added support for language dependent path aliases, so you can have addresses like "example.com/espanol/contacto" and "example.com/english/contact", or alternatively "english.example.com/contact" and "espanol.example.com/contacto".
Although some of this functionality was available in contributed modules, such as i18n module and localizer module, we plan on making Drupal 6 the first release to include decent language support at the core level, of which this was the first significant step. We tried to test as many aspects of the changes as possible, but still we would welcome more testers for this particular feature, as well as opinions and contributions for new functionality implemented for Drupal 6.
Join us in the Internationalization Group and grab our code from our Subversion repository (information on the group homepage), or test the changes already included in Drupal 6.x-dev, by downloading the latest development tarball.
Comments
Good stuff
That's great news - it would be very nice if we could have better non-Latin sites out of the box.
There is an extremely annoying bug in the current version of Drupal (5.1) when sending e-mails - if the site's name is not in English. Will it be fixed as well?
--
http://www.SoftDynamic.com
Already here
People are already using Drupal's installation profiles to create pre-localized distributions of Drupal. No need to wait for Drupal 6.
--
If you have a problem, please search before posting a question.
Loading translation
Gabor is also working on making it possible to load translations at install time. That functionality is already available as a contributed module for Drupal 5, but is scheduled to become part of Drupal 6.
Yes, I also read somewhere
Yes, I also read somewhere that it's going to become module in
Drupal 6
Translation Drupal PT for http://vomicae.net/
Lol Drupal module 6, :P
Great work guys. Lupin3rd of
Great work guys!
___________________
Katapekkia | Multiblog Sociale
Psicomante Blog
Psicomante's Themes for Drupal
___________________
Computer Graphics & Real Time Rendering
Drupal Development & Computer Graphics
wonderful! this is great
wonderful! this is great news since i am working in a multi lingual company.
however i must bring some reality to the table. at which point will drupal community slow down on new feature integration and concentrate HEAVILY on performance? i run nearly no modules in my development site (only menu and devel...) and on every page drupal eats NO LESS than 5MB memory...
taking into account the speed at which drupal expands. it is very difficult to stop and give up all the new functionality and focus on optimization. but at some point i believe it must be done. is there some kind of global cross-major-drulap-version road map? and at which point will all new features will stop to be added untill all the performance issues are addressed?
Sometimes something interesting appears on http://litwol.com
These improvements are the
These improvements are the first major improvements we've added in more than 6 months. There is plenty of time to look for optimization opportunities. Go ahead and concentrate on Drupal's performance -- your contributions would be much appreciated
I hope it won't increase
I hope it won't increase Drupal weight and won't slow down speed.. If I don't need multilanguage on the specific website, why should I install CMS with the functionality that I don't need? I think that changes to core should be minimal and lightweight, and they should not make cms API more complex, as multilanguage is needed may be in 20-30% of all websites that can potentially be powered by Drupal - I hope developers understand that.
RussianWebStudio: improving the web
no worries
you must have faith!
the people who wrote this patch are the same people who wrote the drupal that we all now enjoy. we aren't going to poison performance for *any* feature.
Have faith...
...young grass hopper.
The Drupal Association have a clear path for development, code freeze, testing, code optimisation, final release.
If you're still curious, then Jeff Eaton can show you the light here: http://jeff.viapositiva.net/node/477
---
Dee
iScene Interactive :: iScene.eu
Clarification...
The Drupal Association does NOT set technical direction: it's role is to support the activities you mention.
--
The future is Bryght.
I think you shouldn't be too
I think you shouldn't be too worried about it.
We are putting some special effort in having minimum performance impact for the case when you only need one language. Also for what we've done so far you can even expect some very small performance gains for the case when your single language is other than English.
However, if you are really concerned about this, you can help with testing and benchmarking. Any feedback will be welcomed.
Then maybe you shouldn't install any cms at all and do your own php coding :-)
https://reyero.net
Then maybe you shouldn't
I do my own coding on very specific websites, but I use Drupal for all other websites. It is reliable, powerful, flexible, small (still small? :) , and open-source.
but there is an almost invisible border between simple flexible platform (that can be used even for 4-page site, actually) and huge monster with default installed wysiwig, multilanguage and big amount of icons for administration :)
But I believe in dru-developers. And I will try your code for testing, surely. :)
RussianWebStudio: improving the web
congratulations! I believe
congratulations! I believe proper i18n is one of the killer features that will keep drupal one of the best CMSes in the world! It is my top favorite feature to be implemented in 6.0 :)
keep up the good work
I'm really looking forward
I'm really looking forward to the results of this implementation!
I work for a Belgian Communication Agency (www.connexion.eu) and we're just starting to use Drupal for multilingual commercial websites. I would be very happy to test the new development and maybe even be involved in the discussions on what can be added to the functionality to make Drupal really suited for multilingual websites. I'm not that experienced yet with Drupal, but in time I would also even like to participate in development.
Until now we have only worked with the Canadian (commercial) CMS Hot Banana (uses ColdFusion). We developed an automated translation workflow for this CMS to allow a non-technical user to export all (or partial) content from his website into XML format. This can be imported into CAT (Computer Assisted Translation) tools, allowing the translator to translate the content without any html code or layout problems. After the translation is exported again from the CAT as an XML, it can be imported into the CMS and is automatically published. More info: http://www.connexion.eu/en/hot-banana/automated-translation/index.cfm.
It would be ideal if Drupal could have a similar system for translating content...
Regards
Koen
XLIFF/CAT
Yes, we keep an eye on XLIFF and CAT tools in general. First, we would like to lay the groudwork. It is highly unlikely that Drupal core will have an XLIFF export/import interface in Drupal 6 (or any time soon), but contributed modules providing this functionality will be supported by core features as much as possible.
By the way, we are looking for more CAT supporting CMS to look at for ideas, so if you have experience with some tools, please contact me on my contact form (click on my user name and Contact tab).
common man sends tons of appreciation
Dear
Jose A. Reyero, Károly Négyesi (chx) and Gábor Hojtsy
Dries Buytaert, Steven Wittens and Doug Green,
The only purpose I am here is to
express my appreciation individually to each one of you
[and respective spouses for their patience]
as well as to the other team members.
Great work.
It may surprise you if I tell you that I know nothing more about Drupal than its spelling.
However, I revere the quality work. This is, in one way or the other, going to benefit millions like me.
The spirit of dedication and camaraderie is uncommon and praiseworthy.
You may consider
I represent the common man on the street
who is smart enough to discover genius at work.
ASHOK KOPARDAY
www.mydoctortells.com _ _ _ we care
Perfect news! I believe that
Perfect news!
I believe that most of multilingual drupal site owners have been waiting for this integration.
Multiple languages and their complicated installation was probably the major weakness of drupal.
I have a question though - what is, very roughly, the estimated time until the release of ver. 6?
6 months? A year? Two years?
www.cringel.com
left my office job and went to Asia
i will quote drupal
i will quote drupal developers from the d5 release: "when there are no more bugs"
Sometimes something interesting appears on http://litwol.com
i have a question: Since
i have a question:
Since language support is being built into the core. i assume its more of a drupal team undertook the effort of improving the language locale or some other language module and bundle it with the drupal core distribution. in that case if i dont need it then i can simply turn it off right? or will this be one of those required core modules that are impossible to turn off?
Sometimes something interesting appears on http://litwol.com
Yes, of course you will be
Yes, of course you will be able to turn it off.
But you won't need that as I don't think it will be enabled as default.
https://reyero.net
In that case we should not
In that case we should not see ANY performance hit. in fact since drupal core developers picked this up i think the whole language related module will be fine tuned to its optimal so people that do use this will see a performance gain.
very good, and thank you for the wonderful job!
now if only i could find that donation button...
Sometimes something interesting appears on http://litwol.com
Drupal Association
There should be one over at http://association.drupal.org/.
hooray! former username:
hooray!
former username: lx_barth
For users using localizer or
For users using localizer or i18n modules, can we smoothly upgrade to 6.0 without lost of multilingual contents?
Great question. Jose and
Great question. Jose and Development Seed have talked about this, and as far as i18n.module goes, we'll be supporting an upgrade path. This is important as parts that were supported in i18n become supported by core, and thus the architecture changes. In fact, Jose plans to maintain a dev version of the i18n module as Drupal 6 development moves along and matures in order to keep an eye out for forward compatibility and really see the field well, making sure to keep a good picture in mind (as well as updated code) of how core and contrib can both best serve each other as things change.
Jose should be blogging about these specific thoughts soon; I'll post back here when he does. We'll also have the video from DrupalCon posted on the blog soon for those who were not there, which aims at explaining a bit on where things stand at a wide angle, and looks at areas that need work, and what the future is looking like.
Ian
Development Seed Blog
So you mean the multilingual
So you mean the multilingual functionality will be heavily depending on or associated with i18n? I think you shouldn't ignore the fact that most people who used both i18n and localizer got a conclusion that localizer is much easier and more straightforward to use than i18n.
I don't mean you should not base new multilingual core on i18n, maybe you need to tell us why you prefer i18n instead of localizer...
Pointless debate
If you would read the relevant group on gdo then you would know that the issue is well researched.
Also core stuff is not particular to any implementation. We currently do language management negotiating, variables and path aliases but the latter has no frontend at all, that's left for contrib. Basically, which requires heavy core modifications and is universal no matter what, gets into core. Then you can build all the solution you want.
--
The news is Now Public | Drupal development: making the world better, one patch at a time. | A bedroom without a teddy is like a face without a smile. | Blog about life in Hungary
--
Drupal development: making the world better, one patch at a time. | A bedroom without a teddy is like a face without a smile.
i18n module vs. localizer vs. Drupal 6
i18n module will not be required. The plan is to support sane defaults in Drupal core for a set of multilanguage features, then allow for contrib to provide even better/extended/replaced support as possible. Roberto Gerola (maintainer of localizer) expressed his wishes to upgrade the localizer codebase to the new Drupal 6 base feature set (which is still heavily under development and expansion), but unfortunately he said he is not "the core developer type", so he is sadly not directly part of the implementation as far as I have understood, and as far as we have seen so far.
Anyway, we know what approaches did localizer take, and we keep that in mind, but I would like to remind everybody that both the i18n module suite and the localizer module suite are big monsters, and implementing all of their features in core is basically impossible. We have an open subversion repository, as well as every patch submitted to Drupal in the open (as part of the "language system" patch queue), so anyone, who has strong feelings about what feature set should we implement can argue one way or the other. We actually redo the user interface of most features implemented from the ground up, and I would expect some users like localizer because of the UI, not because of what underlying database or hooks it uses.
You can find links to the issue queues, places to submit patches and chew on existing patches at the i18n group homepage, as also linked from the post above.
So you mean the
No, not at all. All I am saying is that any functionality that was done in some manner in i18n.module but which may be handled now or handled in the future by core, that the i18n.module will need to adapt itself. An extreme analogy, why would i18n.module handle node creation if core does that and it does it well? Therefore, although i18n.module uses nodes to create translations of other nodes, it certainly does not handle the architecture to create and store nodes because this is done already by core...i18n simply handles making relationships between these nodes, among other things.
So just in general, i18n.module will work for Drupal 6, no matter what gets in core and what does not. Certainly the majority of what is in i18n.module does not belong in core. Like everyone is saying, there's a lot of good resources now in http://groups.drupal.org/i18n/ to get more information on this whole field.
In regards to i18n versus localizer, it's important you consider your options based on your needs. Gabor made a nice comparison chart at the end of 2006 which you can find in the i18n group. At OSCMS it was even mentioned just using a node referencing module to handle one-off content translations, so it totally depends on what you're trying to do and to what extent.
Hopefully this clarifies what I was trying to explain above.
Development Seed Blog
Wow!
That sounds great. Good to see some i18n functionality being added to core. And even better that you guys already prepare a smooth upgrade path for us i18n users :-) Thanks to everyone who contributes to this great project. I will test and provide feedback as soon as I find the time for it.
..- Wonderland
Upgrade
Hi.
Upgrade will not be a problem.
Also with the new engine in core, we'll use the same method to translate nodes,
duplicating them and creating a relationships between them.
For user provided string translation, I don't see critical problems.
in the worst case that the upgrade will not be feasible with a simple SQL
code, I'll write some php code to upgrade the data.
We'll see what will be the new opportunities to integrate a contrib module
for multilingual support in Drupal 6 and then we'll see how to proceed.
Roberto
--
http://www.speedtech.it
testing Drupal 6
You mentioned you'd appreciate testers for language support of Drupal 6.x-dev. If I find bugs or have feedback, should I just give them in the forum, or is there a better way?
_________
uofl forum
---
they would be filed as an issue against drupal 6.x-dev version; see: http://drupal.org/node/add/project-issue
choose drupal as the project hit next, choose 6.x-dev in the version dropdown on next screen.
maybe a stupid question...
...but how can i create a node in different languages? i cannot find any selectbox or so.
not there yet
As the text above explained, we added the *groundwork* of multilanguage support. We are working on language enabling nodes, but Drupal 6.x-dev is not there yet. Our subversion repository has more up to date code, but that is a custom development track, from which we generate patches, which get reviewed by you and other members of the community and get accepted hopefully.
just for your knowledge
this is great news - multilang is really in top5 most wanted features for me - now drupal 6.x will be an great option for building company/ecommerce/corporate/business sites !
--
Using Drupal since 2005
My Drupal blog - http://blog.elimu.pl/category/drupal/
My Web Dev Company - https://palikowski.eu
My personal blog - http://palikowski.net/blog
The beginnings of the new language subsystem is in Drupal 6.x-de
Fantastic news. Yet again, drupal making the world a smaller place. I'm looking forward to seeing developments with this. Keep up the good work.