Multi language for Drupal: current approach and alteratives.

By Jose Reyero on 24 Sep 2004 at 15:15 UTC

INTRO
-----
From me and some other users -and maybe many more potential users-, a key feature Drupal lacks is the ability to have content in multiple languages. There has been some tries to implement it as a separate module, but until now, it is not possible to achive it without some patching to the dabase and/or to the core. I think it is really an important feature and in fact, I've chosen Drupal for some of my developments because -besides the other features- the other open source CMSs I like -Xoops, Mambo...- don't implement it either. So it would be great to get it into the core, maybe for next version.

THE CURRENT APPROACH: i18n module
---------------------------------
Well, this module -which I contributed- really provides multi language, and also interface translation for anonymous users, but I have some problems with it:
- Requires important changes to the database, which cannot be easily undone.
- Requires -with latest Drupal version- some patches to the core.
- I has too many hacks to minimize the patches required that minimal changes to drupal core require continuous updating of the module.
- The content synchronization -nodes and taxonomy- between languages is something that works, but I don't really like how it is implemented because it is getting way too complex, and depends on individual modules implementation to work properly. Also, it is an 'all languages'/'single language' approach: either you have one node type translated for all languages or only a single language version.
- And, the main one, it is an all-or-nothing approach and way too impactant change to gradually find its way into the core.

THE FUTURE
----------
My plan is to redesign the whole thing with a completely different approach, which will make it possible to easily enable/disable it and also to be gradually implemented into the Drupal core. So this is the plan:

1. Add languages to nodes -which is a single field- and then create some patches for the node.module to select the appropiate node list in each case for each language.

2. Create a translation module which will be cleanly implemented and will keep only some list of 'which node is translation of which'

3. Add languages to taxonomy, which will probrably require separation of vocabularies and terms structural data -hierarchies, weights...- from language dependent content -names, descriptions- and some patches for the taxonomy module.

4. .... Well, first 1, 2 and 3, then we'll see

And,

 ...
foreach ($step_by_step_list as $patch) {
  while (!finds_its_way_into_the_core($patch)) {
    cry();
  }
}

Hope this complains with Drupal's coding standards ;-)

So... comments, better ideas, anyone ??

PS: Please don't tell me 'we dont need it, most of Drupal sites are single language'. Which is true but 'most of Drupal sites are single language' because Drupal is single language :-((

Comments

Abosultely agree with you

matteo commented 24 September 2004 at 15:59

I agree 100% with you, and insist on the fact that Drupal would be the ONLY CMS providing such functionality.
IMHO what basically Drupal should provide is interface, node and taxonomy translation, where node translation is not mandatory for all sites.
Such system should be integrated and should work also with modules like flexinode or custom made modules, where additional fields are stored on external tables, so specifications to developers should be written, in order to be i18n-compliant.

I'm not familiar with Drupal internals, so probably I'm not the right person to give suggestions, but for sure such functionalities should be in Drupal Core, in form of hooks or API.

In my case, I hacked Drupal taxonomy to provide terms and vocabulary transaltion, but this is not the right approach, because difficult to maintain, and it's only a partial solution.

Hope Drupal developers will accept ad contribute to implement this feature.

Matteo
http://www.a-cappella.it

What patches are still requir

killes@www.drop.org commented 24 September 2004 at 16:33

What patches are still required?

--
If you have troubles with a particular contrib project, please consider to file a support request. Thanks.

--
Drupal services
My Drupal services

Patches

Jose Reyero commented 25 September 2004 at 10:36

The only one required for the moment is the one sent to the dev list.

What I mean with this forum is that we could do it better, with a different approach that maybe could get into the core some day, which I think is very difficult with the current module.

https://reyero.net

If you are referring to this

killes@www.drop.org commented 25 September 2004 at 18:55

If you are referring to this one http://drupal.org/node/10849, it got applied.

--
If you have troubles with a particular contrib project, please consider to file a support request. Thanks.

--
Drupal services
My Drupal services

Great

chx commented 25 September 2004 at 11:58

Well, I provided the core patch (a bit of crude hack, yes) for 4.5 and i18n capabilites are very important for me. I'm open for any approach and ready to help, just tell me what to do.

--
Drupal development: making the world better, one patch at a time. | A bedroom without a teddy is like a face without a smile.

Thanks

Jose Reyero commented 26 September 2004 at 10:31

About the patch, great!, we at least have a hook into the core. Only that I had thought of a different function -see cvs and the patch I submitted- but I will fix it, no problem.

For the future, my intention is to maintain backwards compatibility with the current module till the 4.5 release and then maybe create a new module or modifying the existing one.

The main problem is that the new approach outlined in my forum will not be backwards compatible with the current multi-table approach, so maybe will be better to have a new module.

My next step: I will have a proof of concept in a few weeks and then submit it for review and discussion.

https://reyero.net

I recommmend that your new pr

killes@www.drop.org commented 26 September 2004 at 18:53

I recommmend that your new proposal will include as few changes to Drupal core as possible. That way it will be easier to get any important changes into core.

See also: http://drupal.org/node/10263 (especially the subpoints to the first topic)
--
If you have troubles with a particular contrib project, please consider to file a support request. Thanks.

--
Drupal services
My Drupal services

Make core capable

Gábor Hojtsy

he/him

Hungarian

Hungary

commented 25 September 2004 at 12:37

As far as I see this issue, it would be the best to make the core capable of hooking in interface and taxonomy translation to it. I bet that still a lot of Drupal sites will be single language, even with strong support for multilanguage content in Drupal, and they should not suffer from more code and slowdown.

So I think we should probably explore ways to make the core capable of helping some module do it, like the node access checks are implemented now.

Absolutely agree

Jose Reyero commented 26 September 2004 at 13:00

Yes, that's the best idea.

I was even thinking of using the node access checks for returning only nodes in a given language in a first 'proof of concept' implementation.

https://reyero.net

reasonable

moshe weitzman commented 25 September 2004 at 14:10

those 3 steps look reasonable to me. looking forward to some patches.

I really don't like your appr

killes@www.drop.org commented 25 September 2004 at 19:07

I really don't like your approach and prefer the approach where you prefix the tables with locales. That approach makes more sense because then es/node/111 will be the same as fr/node/111 but only translated.

I think that people who advocate »i18n to core« should first go to step 2 and create a module that takes care of the workflow of translations.

--
If you have troubles with a particular contrib project, please consider to file a support request. Thanks.

--
Drupal services
My Drupal services

The current one -with table p

Jose Reyero commented 27 September 2004 at 07:30

The current one -with table prefixing- is just a hack to have multi language without patching the core. It works, but it has too many drawbacks as I wrote above. To have a 100% multilingual site -with comments, forums, statistics, etc... - would require prefixing nearly all tables, and you will end up having something more similar to multiple sites than one site with multiple languages.

I think the new one is much more powerful and flexible and will require some initial patches, but will be much simpler in the long term. It will be more like an investment for the future.

Yes, it is nice to know that easy which node is translation of which -when they have same nid- but what when you want only some nodes translated, or you have comments for one language but not for others? Or if you want to have statistics, you will have a different set of data for every language...

I think an object like a node must have a language in itself, and then the translation relations can be keep separately but will be the only thing you have to keep. The rest of Drupal will then be working without having multiple tables for everything.

I.e.
- node/111 is in english
- node/112 is a translation of node/111 to spanish
- each of them will have its own set of related data -comments, stats... -
- then a comment/history/statistic for node/111 will be only for that node in english.

Also with the new one, you can enable/disable multi-language without messing up with the database, something that you cannot do with the current approach.

I mean I will make a proof of concept for the new approach and then, if it works, i will share the results and conclussions. Then we'll see... But on the paper, it looks much better and more promising to me.

https://reyero.net

I am pretty certain that no m

killes@www.drop.org commented 27 September 2004 at 14:59

I am pretty certain that no modifications of the standard Drupal database scheme will get into core for i18n, simply because only very few sites will need it. I am afraid that your solution will generally have too much impact on core and will be rejected for this reason. Hear my warning.

--
If you have troubles with a particular contrib project, please consider to file a support request. Thanks.

--
Drupal services
My Drupal services

Yes Iknow :-( But really,

Jose Reyero commented 28 September 2004 at 14:27

Yes Iknow :-(

But really, the modifications will be minimal. I think all we will need is a 2 characters field 'language' in the node table, and maybe the same in 'vocabulary'. The rest of it will be managed by an independent module is that such a big deal? Then any other modules can take advantage of it

Anyway I am implementing it because I need it and I'd like to continue using drupal for my projects. And as I said before, I don't see a clear path for the future with i18n module with its current approach. It really messes up the database and it cannot be enabled/disabled in an easy way. Furthermore, the database updates have to be applied manually

I mean, for me it will be easier to maintain a slightly patched version of Drupal -which I am using already- than a whole module with so many hacks that minimal changes in core can make it stop working, so whether it gets into core or not is not what worries me most. I just wanted to 'contribute back', and of course save some time with maintenaince of my sites. But it is just 'some time', not big deal.

And once again, that 'only very few sites will need it'. Did you think about how the user base could grow if we add that single feature?

https://reyero.net

very few sites that currently run drupal

badlop commented 29 September 2004 at 12:17

--- no modifications of the standard Drupal database scheme will get into core for i18n, simply because only very few sites will need it

Probably you mispelled the sentence. Those modifications make more sense to me:

no modifications of the standard Drupal database scheme will get into core for i18n, simply because only very few core-Drupal-maintainers will need it
no modifications of the standard Drupal database scheme will get into core for i18n, simply because only very few sites that currently run Drupal will need it

Nobody can claim that 'very few sites will need it' without showing some data that confirm that possibility. I mean: how do you know that? Any proofs, statistics? Any poll I am not aware of, previous studies? Any passage of Nostradamus works I have not read?

I'd like to share some experiences with sites I administrate (or have voice in):

www.jabberes.org is single-language, 'locale' is enough.
tkabber.jabber.ru is multilanguage. If Drupal allowed content translation, the documentation whould be available in different languages.
JabberCentral was started some weeks ago. I proposed to use Drupal. Since the site required full content translation, Drupal and all other CMS were out of the game. If Drupal allowed content translation, now JabberCentral would be using Drupal.
Ejabberd website is quite old. I could get permission from the owner to convert it to Drupal. One of the key features would be having content translation for documentation and news posts. But if I say that the database will be a mess and every update of Drupal will require patches, then the i18n feature will be out of the map.

So, three out of four sites i have decision on would use Drupal i18n capability. I'm sorry, but this assertion that 'very few sites will use it' does not coincide with my experience.

Some contributors are planning to provide patches freely. They are warned that big patches will not go into core, so they will make sure the patches required for i18n are minimal and bugfree. Now the question is simple, and a little rhetorical: Are you, and other people with decision power, going to reject minimal core patches that will improve Drupal, get him in front of other CMS competitors and attract new sites?

World is multiculture, multilingual. Internet can be widely reached.
Maybe current Drupal sites are local, but there is a big market out there for any content translation capable CMS. Drupal could be the right one to capitalize it. I use and prefer Drupal for many good reasons, but it can be even better. If J. A. Reyero future module is good enough (it fits in Drupal arquitecture, is bug free, etc) I'll vote for it.

I would use it too

Gabriel R. commented 29 September 2004 at 13:15

I too would love to use content localisation, both for commercial and personal web sites.

-- NO, don't read this signature!

Many sites would use Drupal i18n capability

Bernard Hurley commented 29 September 2004 at 21:07

I live in the UK in an area with a multiracial multicultural community. There are two projects I have been asked to help with in the past month. One, a web site for a project providing the community translators/interpreters for about 20 languages, and the other a Chinese school. I18n is essential for both of these, and apart from the difficulties of using multiple languages with Drupal, it would also be ideal. There must be many more potential uses of an i18n Drupal.

I think that nobody doubts th

killes@www.drop.org commented 30 September 2004 at 22:18

I think that nobody doubts that there are many would be users of a fully i18ned Drupal. The question is only: How do I get Drupal there and how do I avoid a penalty for users who don't need it?

--
If you have troubles with a particular contrib project, please consider to file a support request. Thanks.

--
Drupal services
My Drupal services

...

magico commented 28 October 2004 at 14:28

....

How about a vote?

joel_guesclin commented 1 October 2004 at 13:55

Why fuss about wondering whether or not there is a demand from Drupal users (not just developers) for i18n in core? Why not have a poll? Question could be just: how important is true multi-lingual Drupal to you? Would die without it / Very / So-So / Bof! / Really don't care...

I am afraid software developm

killes@www.drop.org commented 1 October 2004 at 16:28

I am afraid software development isn't really democratic. ;->>
--
If you have troubles with a particular contrib project, please consider to file a support request. Thanks.

--
Drupal services
My Drupal services

Democratic

Jose Reyero commented 1 October 2004 at 18:40

I am afraid software development isn't really democratic. ;->>

I think free software is just free -and the need to be democratic would just be another restriction to freedom :-)

No, seriously, we have something better than democracy, the freedom to get it and do whatever you want with it -something you cannot do even with your home ih these 'democratic' countries. I am happy with how things work -talking only about Drupal development- and hope to get some consensus to get this multilanguage thing somewhere somehow.

I think it would be interesting to have a poll -let's use Drupal module :-) and see how people feels about it, but just that.

As someone said "The best thing about Democracy is that most of the people get what they deserve" ;-)

https://reyero.net

I support this.

Taran commented 22 November 2004 at 16:46

Multilanguage ability is more necessary than many people seem to think.

I AGREE

ardi1983 commented 30 January 2008 at 16:18

YES

Need for Multilanguage

sottwell commented 24 October 2004 at 09:34

I develop websites for European and Israeli businesses, and they all require multilanguage capabilities, often six or more languages. So far I'm building my own, but it's taking a long time and my clients are getting less than I am happy giving them. I saw a reference to Drupal on Slashdot, and it looked good, but was a disappointment once I did some research (first Google search result brought up this forum discussion). So this is just to add another voice to those who would use Drupal if it had multilanguage capabilities.

sottwell
Mizpeh Ramon
Israel

Multi language needed

cquest commented 27 November 2004 at 22:33

Real multi-language support is also a BIG missing feature for me and I'm sure I'm not alone !

Don't forget multi-language countries like Canada or Switzerland.

More and more sites need to be available is several languages as they reached an international audience.

I hope we'll find a way to had this very important feature into Drupal without having to mess too much with hacks, patches, multiplication of database tables, etc.

Taking care of the people who are doing the translations is also something very important, and updates to translations... when the "original" is modified.

This would be a killer feature for Drupal.

Regarding the default language used by visitors, don't forget the language header field... nice to provide directly the right language to the visitors.

No Question, much needed,

joedrupal-1 commented 13 August 2005 at 04:45

Simple.

The time/money economics are prohibitive on my side re.developing a really good smooth general purpose mutilingual drupal module.

(That is, assuming I had the skill ;-] ).

But let there be no doubt -- given an easy way to do it, I have at least 6 projects which I would roll out in a hot minute *IF* I had a decent multilingual CMS, specifically for English, Japanese and one or two other 2byte Asian languages.

Without a smooth pre-existing code base the time/money/effort economics are prohibitive.

What's more, I know at least 6 other people who could honestly say the same.

Let there be no doubt on this point.

Japan is ***FULLL*** of potential participants.

If I ever get the time I'll jump into the game.

I'm hoping that one of you more experienced people get there first.

I am not too sure about this

Bèr Kessels commented 27 September 2004 at 16:30

I am not too sure about this path too. Simply because I am not sure whether this will work out.
I think, that when this works and wwhen it will have only little impact on the core, there is a chance it will get in. But we should not focus too much on that. There is life after core, so to say.

Personally I think a good solution for multiple languages is one where
a) all content can be translated.
b) all UI is translated.
c) all translated content is related.

Currently the i18n has grown out of hand. It became too big, too complex and still does not work 100% like it should. This is mainly due to choises that *had* to be made, because core dictated them.

But I am also quite sure that it will be really hard to get just anythning into core, just to allow translation. So besides good code, good choises and hard work we need good politics. Because 90% of the users, if not more, do not want multiple languages.

First of all we need to make everyone aware that half of the current locale system is obsolote, unless used with i18n. Locale offers ability to add unlimited amount of language, but Drupal can handle only one in a proper way. This should be fixed, or removed. And if i18n cannot make it to core, then why should the ability to *have* but not *use* more language be there at all?

Secondly we need to make people aware that truly corporate sites do need some form of translation. One that goes beyond simple interface transation. We need to make everyone aware that a big part of places where drupal could be used, cannot use drupal, simply because you cannot use more languages. In fact I am looking, with pain in my heart, at other CMS systems, to use for my services, untill we get Drupals multilingual features on the road again.

We should also consider, that if it turns out to be the best solution, some form of branch, one that contains the required patches, could be kept sidolng with drupal. I am talking about more than a simple
distribution, but no way about forking!

So far about all the poltics,

[Ber | Drupal Services webschuur.com]

Yes, there's life after core

Jose Reyero commented 29 September 2004 at 09:35

Yes, there's life after core ;-)

Currently the i18n has grown out of hand. It became too big, too complex and still does not work 100% like it should. This is mainly due to choises that *had* to be made, because core dictated them.

Yes, that's the point. And also there are too many ugly hacks and workarounds just to avoid patching the core.
Actually, this module was kind of experiment -that's why it has so many options, maybe too many- and I just got surprised of how many people were using it and asking for suport...

I think this multi-language thing is too low level to approach it only as a module. So, from now on, I will go for 'simple core patches' better than 'complex module solution'. Anyway, what's the point of having a module that probably won't work with future releases of Drupal ?

I mean I really don't worry if it gets into the core or not. I prefer to maintain some simple patches that a complex module and a messed up database.

... we need to make everyone aware that half of the current locale system is obsolote...
Absolutely agree, that's another problem. Anyway I will try to have the new i18n working smoothly with locale until a better solution is found.

... , simply because you cannot use more languages. In fact I am looking, with pain in my heart, at other CMS systems, to use for my services
Same here, please let me know if you find one ... ;-) .
I mean, I really like Drupal and I'd really prefer to build on it. But I *need* multillanguage features for most of my sites so I need a solution.

Actually, this forum was also about 'testing the chances of getting i18n features into core', and I have to say I've got a really good impression, better than expected :-)

So let's put hands on the implementation and we'll see.

https://reyero.net

Agree with Reyero approach

joel_guesclin commented 27 September 2004 at 08:58

I agree with Reyero's proposed approach. I have spent a lot of time looking for a multilingual CMS (though I can't claim to have tried them all out in detail), so I can tell you that it is not altogether true that there are none. eNvolution in particular, allows you to attach a language to each user and to content, so that a french-speaking user sees french content, for example. Why didn't I go for eNvolution? Too boxy, too much like PHP-Nuke, far too awkward to understand and administer, didn't like the limited taxonomy possibilities... and in the end I decided to use Drupal.
I had great hopes of i18n module, and spent some time mucking about with it. However, in the end I abandoned it and decided to set up completely different Drupal installations for my different languages, for the following reasons:
- too complicated to set up and too many patches; I didn't like the idea of using something that fiddled so much with core
- I had some difficulty getting it to work
- most of all, it seemed far more oriented towards one-to-one translations, ie sites with more or less identical content in several languages (for example, Canadian sites where everything has to be in English/French.
This last reason was the killer: my site is multi-lingual, but the content is not the same in all languages. The site is essentially political news and analysis - some of this is classified the same in all languages, but there are also parts of the taxonomy specific to each language (for example, in the Spanish taxonomy there is more detail on Spanish politics than in the English taxonomy).

I did think of the option of just not worrying about separating the languages and having all languages available to all users (eg English, Spanish, French articles all posted to the same front page), but this seemed undesirable - too much incomprehensible clutter for people who are not multilingual.

My conclusion was that the only realistic solution (speaking purely from the user/administrator standpoint and knowing almost nothing about the implications from the Drupal internals standpoint), is the one proposed by Reyero:
- each node has a language setting
- each taxonomy term has a language setting
- each user has a language setting
- anonymous visitors can choose a language setting
- only content that matches the selected language is displayed.

How possible it is to do this, but until I get something like this solution, I will stick to organising each language completely separately. It's not very satisfactory, and will impose a substantial administrative overhead, but I think it is simpler and safer.

All in all, I find it very surprising that there is not more interest in making Drupal truly multi-lingual. Surely the vast majority of European company sites have to be multilingual, at least in the local language and English? What is the experience out there?

Anyway, good luck to J Reyero in his enterprise, and I hope to meet his new i18n in 4.6!

language configuration with optional fallback

cgrottolo commented 27 September 2004 at 10:04

I work in a multilanguage environment and the (proprietary) CMS we use there provides a good solution for quite every language setting we have to provide (Intranet: multiple language with one fallback language; Internet: multiple language with translations and no fallback but with language independent objects [i.e. data, part of the images, colors, styles] OR multiple independant languages with common language independant objects). It works basically with a lanugage setting table, where you can define one default language (real language or just container for language independant objects) and as many languages as you want, with or without fallback language:

Three language with no fallback but with default objects:
language fallback default
***********************************
default none y
english none n
german none n
french none n

Three language with french falling back to german and with default objects:
language fallback default
***********************************
default none y
english none n
german none n
french german n

Two language with fallback and default to german
language fallback default
***********************************
german none y
french german n

Maybe this idea can help?

Christoph

Question

Jose Reyero commented 29 September 2004 at 09:46

Yes, interesting, this fallback option is something that I will add to my 'wish list'.

My question is: what happens when the current page -story- doesn't have a translation? Is it possible to have mixed interface/content in different languages? Or are there fallback pages too?

I.e. you are reading a page in English. Then you click on the German flag somewhere in the page but the content is not translated to German yet. Shall we get the interface -and the blocks- in German but the same content in English?

https://reyero.net

If you do not need to transla

killes@www.drop.org commented 27 September 2004 at 14:54

If you do not need to translate your content anyway, then it is obviously better to have several sub-sites that maybe only share the users table. This is not something a i18n module should cater for.

--
If you have troubles with a particular contrib project, please consider to file a support request. Thanks.

--
Drupal services
My Drupal services

Yes, a european corporate web

cialog commented 27 September 2004 at 19:05

Yes, a european corporate website needs to be multilingual ... mostly.

For the most recent drupal implementation i tried hard to put the i18n.module properly in place. But couldn't for various reasons. My URLs often got messed up. Finally I came to the conclusion that from the developers point of view the only practical, solid and upgradable solution would be to have different a drupal installation for each language.

From the client (maintainers) point of view this will be uncomfortable - especially for admins being responsible for more than one language. They'd like to have a node input form that let users create multilingual content in one single form (or in connencted - tabbed sequence - forms) or to choose wether the particular node will be translated at all.

During consulting I'm often challenged to compare drupal to Typo3 ... my weakest arguments at the moment are internationalisation and document (incl. image) management. I'm willing to help drupal evolve this way.

Just my 2c.

tricky isn't it

stevepowell commented 29 October 2004 at 13:46

well all the sites I have ever been involved in should have been multi-language, but they weren't because there was never the right CMS.
but I agree that even specifying the problem is pretty tricky.
I almost agree with Roel and Reyero, but do we really want "only content that matches the selected language is displayed"? For example I work at the moment on a site where there is plenty of content in English and in Bosnian, and most of the users read both. But would much prefer to read contributions in their own language where it exists but would NOT like to miss it if they have to read in another language.
So my suggestion: each user sets a weight for the languages available, with the heaviest weight meaning "don't display at all"
just my twopenceworth

+1

Jose Reyero commented 30 October 2004 at 13:58

read contributions in their own language where it exists but would NOT like to miss it if they have to read in another language
This one, added to my functional specs wish-list

each user sets a weight for the languages available...
This is a little bit more complex, for the future... I think for the moment there will be one site-wide default language and one user preferred language

https://reyero.net

List of functionalities

OrichaFr commented 10 November 2004 at 15:46

I do completely agree, but on one point : I think that it has to be built in the core of the system.

As Joel, I did a review of most CMS tools, one year ago, based on this criteria list :
. Multi-sites : not really a problem, having as much databases as sites is the best approach.
. Each site must have multi-language. On this point, my personal needs are : same exact (node) structure for all 'translated' sites, which doesn't mean same content. For instance : you can have an 'official documents' page on all sites but with different documents on each site.
Sure, different structure/different content might be useful for some people, but it's impossible for me because of the following criterias.
The only exception on this point is the forums area, that can have or not different structures/contents.
. Process of translating and referencing the content as simple as possible : very few people are able to make translations on specialized topics. So when you get the guy, you don't ask him computer skills at administrator level. It must really be : 1. source language page (show and print), 2. target language page (input the translation), 3. hit the 'publish' button and it's done. And no fumble in indexing/referencing the translated page accordingly to the other language sites. And no workflow functionalities needed as I don't want someone translating a page and another one referencing it before publication.

. One unique taxonomy/collaborative book translated in all language.
. Collaborative book can be populated according to different methods : administrator / moderator decision, group of specialists (the 'jury'), number of hits, members notation, ... This function is not language-related but general to the full site : all hits of all 'language' sites, or best notation from all members or guests of all sites...

Which really impose an unique database with same administration rules for all 'language' sites, and same structure for the content.

One year before, there was only one tool I know that had the good 'one database-multiple contents' approach : Typo3. But with a severe constraint : there must be one default language which impose that the translation must be done from an unique source language. For instance, if English is the default language, you must absolutely start from an english page and translate it in other(s) language(s). Too hard for me. I must be able to have one person, a french for instance, publishing a french page, and (same or other persons) translating in english, spanish, ... pages.

So one year before, I really did not know what to do, except that it would cost me a lot of development to get what I would like. But based on what tool ? A not perfect Typo3 lacking collaborative book functionalities ? Or a Drupal with no multi-language approach ?
I was allowed to wait, as I went on an another project, but keeping an eye on (at least) these 2 tools.

Now, Typo3 has a new release implementing multi-language into the core of the tool (as I think it's mandatory). Probably best to develop the collaborative book (and populating methods) as an extension, than building multi-language extension on Drupal ?

then es/node/111 will be

pietro commented 30 September 2005 at 21:07

then es/node/111 will be the same as fr/node/111 but only translated.

i don't think this makes much sense. if your native language is english but you also speaks (some) spanish and you want to browse the site in english but also be able to read spanish posts. with this approach this isn't possible.

Somewhat distantly related

kbahey commented 27 September 2004 at 15:57

Somewhat distantly related topic, and discussion, here is a previous discussion on Some ideas for Arabic translation of Drupal.

--
Drupal performance tuning and optimization, hosting, development, and consulting: 2bits.com, Inc. and Twitter at: @2bits
Personal blog: Ba

Quite interesting read. It

Jose Reyero commented 27 September 2004 at 17:44

Quite interesting read.

It looks like RTL languages will fit on any multilanguage approach as it is only a presentation layer issue, and we only need to keep that rtl flag somewhere.

As I plan to have language as a property of each node, it will be even easier, to render each node as required.

I would be happy to support it in the existing, or future versions of i18n module, please somebody send more specific suggestions. In the meanwhile, I think that what you need is:
- A patch for locale module -just the rtl flag
- Have the charset as a config option - it should have some other uses...

There's a new feature in i18n module -cvs version only- that I called 'language dependent variables'. Maybe you should take a look at it -Read the module docs- because it could be useful in having stylesheets for each language.

And, I have a question: Is it possible to have mixed content English/Arabic/whatever in the same page ?

https://reyero.net

Yes, it is possible

kbahey commented 27 September 2004 at 19:35

To answer your question of mixed content, yes it is possible.

The folks at http://linux-egypt.org/ do it all the time. So does the Egyptian LUG http://eglug.org/

Of course, this requires use of UTF-8 and that the browser of the visitor has support for it. But in general it works well.

Some people in Egypt started a project for a module to do Arabic on a per paragraph basis. I think it was referenced in the discussion above.

--
Drupal performance tuning and optimization, hosting, development, and consulting: 2bits.com, Inc. and Twitter at: @2bits
Personal blog: Ba

Yes, but there are issues....

joel_guesclin commented 16 October 2005 at 16:16

There is no problem mixing English and Arabic character sets in the same page: since Drupal works with UTF-8, the display poses no difficulties in and of itself.

The only issue is the LTR/RTL combination. If you set up your whole site to be RTL, then you will find all the English text aligned right, which is ugly, and in some cases there will be oddities (for example a question mark at the wrong end of a sentence).

I think that the way round this would be to exercise great care in the css, so that you separate the categories of text to be displayed in each language. For example, block text in English, node text in Arabic, something like that.

It should also be possible to manipulate the text within a node (for example) by using the HTML commands to switch between RTL and LTR.

It takes care, but it can be done.

Another, maybe simple approach

Bèr Kessels commented 27 September 2004 at 16:35

Another, maybe simple approach I have been thinking of, is some form of database layer.

We already have database layers in core, and it would be easy to modify one layer to become a mysql-only multilingual layer.
That database layer, together with a simple module could handle all the table duplication/synchronisation. They could also do some field-only duplication, where required.
In theory, such a db layer can do anything. You would need heavy and complex regular expressions, but I think it would not be too hard, less hard than (and much more flexible), for example the prefixing we do now.

Would people think this alternative approach, is one with potential?

[Ber | Drupal Services webschuur.com]

This, too, would have signifi

killes@www.drop.org commented 27 September 2004 at 17:08

This, too, would have significant impact on core. However, if we were to improve our db handling anyway (for example to support miore database engines) it might be possible to get this into core. But I still think that the shared table approach has more portential.

--
If you have troubles with a particular contrib project, please consider to file a support request. Thanks.

--
Drupal services
My Drupal services

I am nore talking about a *ne

Bèr Kessels commented 27 September 2004 at 22:44

I am nore talking about a *new* database layer. That might not be all too clear.

More something like database.i18n.inc. I am not saying that there should be modifications to database.mysql.inc or so!

[Ber | Drupal Services webschuur.com]

Ah, that's quite a bit of cla

killes@www.drop.org commented 27 September 2004 at 23:46

Ah, that's quite a bit of clarification. Maybe that is the way to go.

--
If you have troubles with a particular contrib project, please consider to file a support request. Thanks.

--
Drupal services
My Drupal services

Yes, I've been thinking of it

Jose Reyero commented 27 September 2004 at 18:02

Yes, I've been thinking of it too. But got lost when approaching to reality and started with the implementation details, it is really a *very* difficult issue.

And any kind of new layer would slow down the whole thing. Actually what I'd like to have is an 'object layer' -the node module is kind of it- in which anything -nodes, terms, comments, blocks, themes...- would be an object and would allow for uniform ways of implementing access control/language content/caching/anything you can think of... for all the resources. Ok, let's call it utopia :-)

So for the moment, I'm going ahead with the approach outlined above -I've got a new multilingual site to set up- and will share the results.

https://reyero.net

"I've been thinking of it too

romca commented 1 October 2004 at 16:54

"I've been thinking of it too"

so did I :) , and some of you prabably know - i do agree with Ber Kessels it is not a new database layer, for me, it is only a modification of queries (but without regex) - but as you have said, you have been lost when it came to implementation details , I have not started to code it yet, so I am not lost yet(but I will try to loose myself:)

to others who talked about i18n : I am working on very complicated site and i18n module works for me very well, you must only apply these patches from issues forum and be sure to set your default language before any synchronization (not by hand, in the code) until now 420 multi-language objects were created and heavily edited and without any error, it is absolutely possible to use i18n module, but it is not way for future - if you do not use synchronization, everything will go worse for your site

Jose's approach is mightier than query rewriting and we all are probably looking forward to it

I think this multi-language thing is too low level to approach it only as a module.

not my words, but my opinion too
roman

Where exactly would I set the default language?

minsight commented 1 October 2004 at 19:29

be sure to set your default language before any synchronization (not by hand, in the code)

Where did you do this? It sounds like something that might be of use to me.

I use this inside of i18n_for

romca commented 5 October 2004 at 01:21

I use this inside of i18n_foreach_lang
it basically takes the first lang as default, it there is not anything set yet
-for flexinode, it must be done inside of flexi.module

function i18n_foreach_lang($callback){
  global $languages,$i18n_lang;
  $args=func_get_args();

  if(is_null($i18n_lang)){
  reset($languages);
  $i18n_lang = key($languages);  
  }

Great idea

chx commented 3 October 2004 at 09:33

This is a great idea. If we can convince the core team to provide a hook into db_query we are free to do whatever we like.

And, as I have written Jose, I prefer the prefixed table approach, for eg. upgrading is easier

--
Drupal development: making the world better, one patch at a time. | A bedroom without a teddy is like a face without a smile.

Prefixed Table issue

kbahey commented 8 October 2004 at 20:10

Drupal currenly supports using the same installation and same database for more than one domain/host name. One way of doing this is to have a table prefix set in the conf.php file, which I am using to host 3 domains in the same database.

Would the prefixed table change you suggest affect this in any way?

--
Drupal performance tuning and optimization, hosting, development, and consulting: 2bits.com, Inc. and Twitter at: @2bits
Personal blog: Ba

Yes, multi-lingual support of Drupal needs more ...

leopoldo commented 2 October 2004 at 23:29

Friends,
I discovered Drupal looking for a multi-lingual collaborative approach. I stopped my first installations (4.4) because translation support has several functional troubles. The new release 4.5 has not added significant improvements in multi-lingual support.

Although I have enough skills to code PHP, I do not know well the internals of Drupal. So I can only talk as an user. Some issues to be considered could be:

a) There should be two different translation spaces. The first one for translations required by modules and core, and the second one for user contents. To be able to generate these two separate .pot files is a quite simple way to contribute while your website goes on growing.

b) Mean life of the translations of different sections is quite variant. Tag and short sentences are long-life items, but "Help" sections are short-life items across Drupal version. This reality provokes obsolescence of translation files without a clear fundation.

c) New approachs should take in account the integration of translation-machines, externally as HTTP services or internally as plugins. Some contents (as nodes) are well-oriented to be created by human translator, but entries in a forum are quite dynamic and need automatic translation.

A last word about multi-lingual support. This is a significant dimension of the collaborative framework. Please, imagine the multiplicative effect of a forum with real multi-lingual support.

As mentioned, I have skills of PHP programming. I would like to help J.A.Reyero if his approach is eventually accepted. Please, contact me: lsalgui AT demopunk.net

Democrats by Rupture with Regime
http://www.demopunk.net
http://otrademocraciaesposible.net

Core

Dries commented 3 October 2004 at 10:23

Just to get this out of the way: I'm willing to make changes to core to make il8n possible. There are three key requirements though:

It should have negligible overhead for those not using il8n.
The required code changes should be elegant. Don't make it a hack. Do it right.
Make it easy to setup and easy to translate content. Usability is key.

Possible implementation idea

Dries commented 3 October 2004 at 10:39

I haven't given this much thought, nor have I read up on all different proposals but can't the filter system be used to translate content?

Here is what I have in mind: use the filter API to add a small 'translate'-icon after all filtered text. When you click the icon, you are directed to a page where you can translate the text in one of the available languages (languages continue to be configured through the locale module). All translations are maintained in a single SQL table, called translations. The translations table's SQL key could be hash of the original text, much like the filter system does, or something more advanced.

Depending on the user's locale setting, the filter system can then choose to replace the pre-filtered text (see filter documentation for more information on the pre-filters) with the translated pre-filtered text, filter it using the normal filters, and present it to the user.

By leveraging on the filter API, miminal or no changes are required to core and disabling the il8n filter effictively eliminates all overhead. Also, no special database changes are required which is a big plus to me.

Of course, you'd need to figure out a way to keep the translations table clean so no dead translations are hanging around (if that is considered to be a problem). Also, I'm not sure all content is currently filtered: I know all user-contributed content is, but things like the mission statement and submission guidelines might not be.

If this can done cleanly, this might be worth including in core as part of the existing locale module. The module would share a lot with the locale module so why not combine them into one. That improves usability, avoids confusion, and will be 'group' or centralize all il8n developers/development.

..looks a good idea, but what about search ??

matteo commented 4 October 2004 at 15:26

Dires, this could be a good idea, but how should search work in such a scenario ??

Matteo

Not only search, Also node

Bèr Kessels commented 4 October 2004 at 16:00

Not only search,

Also node-listings and titles, weblink descriptions, and more of such "forgotten" user-submitted content, will not be translated.

Although I believe the filters might be a nice thing, in practice they will hardly work.

I tried this approach, in a much less elegant way for a 4.4 site. I simply added a filter that pulled everything trough a t(). And I tested whether I could actually translate stuff then. I was really surprised by how much stuff was never filtered and thus translatable ("was", because I do not know this for 4.5).

[Ber | Drupal Services webschuur.com]

another ways

romca commented 5 October 2004 at 01:30

When I was thinking of query rewriting, another possible ways appeared

1) have you seen locale.module? - it is doing t() on strings. It would be possible to do t() on queries, being mad?! No, it is only one way of processing of natural language, to first transform it to something simple that can be manipulated - and we already have the simple things, queries, there are only a few queries and bunch of natural language strings

or
2) what about storing lang versions inside one cell
my text
[es]
el texto
[/es]
[ge]
das text
[/ge]

this would make it possible to search, list, even fallback to some language, if other is not present, AND - to keep things simple for other modules

just only food for your minds :)

have a nice ...everything!
rca

search definitively need info in nodes for performance but...

azaril commented 29 October 2004 at 22:34

First: sorry to Matteo and Jose... I've been pretty busy...

I came back to my idea that shouldn't require any modification to core (if we don't mind a bit of performance drop for searches in multilanguage enabled sites).

A premise: I think that interface translation and content translation should be kept separate. Content is created and mantained by different people than interface translations, we could have a repository of interface translations, it doesn't have a sense to have it for content.
So even the interface for mantaining interface translation should have different purposes than the one used for content translations.
I think that default for both should be even chosen indipendently. Most of the time I prefer an English interface cos I got used to PC when there was just a Quit button. I find hard to look for an Esci button.

I won't come back on this point cos I think that interface translation management is working OK at the moment.

As pointed out translated sites are autonomous but related entities.
They may have different history and content... but after all they are the same site in another language. They may be similar but not equal.

What if a vocabularies have language info and nodes are assigned to vocabularies accordingly. Then we would have to build up a table for vocabulary <-> vocabulary translation to provide fall back in case a node <-> node translation was missing.

But this will happen if just someone ask for a translation, so not too much overhead.

Managing content to translate it at different times shouldn't be a problem.
You just go to the page you're interested to translate, if the content is missing you'll be carried in a section of the translated content where it is reasonable to place the translation.
Checking what are the missing nodes will be just a matter of looking at the alias table.

Translation of nodes could be done simply with the alias method as now.
Nodes that belongs to a vocabulary will have an automatic assignment of an alias en/node#, in/node#, relating them would be just a question of changing the alias.
Nodes could also belong to language independent vocabularies, so they won't get an alias and a language characterization.

As a fall back strategy, if a translated node is not found once the user ask to switch language, the language module will look in the correspondence table between tid and move to the most pertinent place of the "translated" vocabulary.

The draw back is that to limit searches in one language you'll have to do a join to see which pages belongs to which vocabulary.

reasonable?

Its not about performance

Jose Reyero commented 30 October 2004 at 14:31

shouldn't require any modification to core
It's not about performance. It is about cleaner implementation.

I always think that computers will get faster, while all of us will get slower :-)

interface translation and content translation should be kept separate
sure, but with some limitations -mainly about usability- Do you want to have a menu to select "content language" and another one to select "interface language" ?
And do we all have clear enough what is 'content' and what is 'interface'? What is the site's title? What are the configurable texts -welcome email, content guidelines, etc...-? And names for taxonomy terms and descriptions?

interface translation management is working OK at the moment
There are oppinions about this. Mine is "it is working OK for the moment, but..
The translations are hard to maintain and at some points -see previous question- it mixes interface and content

What if vocabularies have language info...
I think vocabulary names will have a translation, but language info will be better at the term level.

if a translated node is not found once the user ask to switch language
I'm thinking of an schema in which it simply cannott happen, as every node will have it's own links to its existing translated versions and the language selection block will be mainly used for interface -separating content and interface, as you said before-

The draw back is that to limit searches in one language
I think a search string has a language in itself, so I don't find it a problem to show all nodes that simply match. Google does :-) The 'language restriction' could be only in 'advanced search'

https://reyero.net

I am pessimistic that this ap

killes@www.drop.org commented 4 October 2004 at 17:38

I am pessimistic that this approach will work very well. I also think it is rather filter system abuse than fair use.

The shared table approach is very powerfull but hasn't been fully implemented. The workflow is basically non-existent. But thanks to Drupal's APIs it should be easy to create a translation queue.

--
If you have troubles with a particular contrib project, please consider to file a support request. Thanks.

--
Drupal services
My Drupal services

about the required field

glitch-at-3yanlis-dot-com commented 28 October 2004 at 04:33

hmm.. how about using the "type" field in the node table instead of adding a new field. For example, if node/112 is a "blog" in english, type of node/113 (which is spanish translation of node 112) can be "t:112:sp:blog". and we can parse that field. That seems reasonable to me. But i dont know if this causes a problem with other modules ..

another idea

glitch-at-3yanlis-dot-com commented 28 October 2004 at 06:17

another idea is, by using the hook_nodeapi, as soon as loading the node, we can check the translations table(where translations of nodes kept) and if there is a translation of that node to the current language (which is kept in a session variable), we change the title & body of node to that value.

there is another problem, the theme translation but i think thats the easy part. now i am working on that module, i'll see what i can do.

Good news for future translation schemes

carlmcdade commented 28 October 2004 at 07:16

MySQL 4.1 with unicode support is finally stabile. Unicode support in the database was what was needed all the time. While external text files are convenient using the database provides more flexibility to do a "by content" translation of Drupal.
---------------------------
info for Drupal installation
__________________________
Carl McDade
Information Technology Consult
Team Macromedia
www.heroforhire.net

bad news good news

romca commented 14 December 2004 at 13:08

Hi guys,

I have gone a long way of implementing "query rewriting approach", BEFORE I discovered that it can not be succesful :) :| respectively

Rewrite alone is not as difficult as you might think, but what is a really bad in this is the loss of a context - that means, I can rewrite columns in the query to reflect language settings, but it is not enough.

Imagine that some modules do updates in this way:
1.delete the row
2.insert the row with new data

I could never catch this, I do not know the context of a query - oh, yes, sure you are right, I should have discovered it earlier.

just to show that I am not only talking, you may try what I have done until now, I believe it is 90% complete

add this into you index.php:
include_once "includes/i2.inc";

and this to your database.mysql.inc, oh yes, should I forget to mention that it is only for mysql?

if(function_exists("i2_check_query")) {
$myquery = i2_check_query($query);
}
the source: www.knihovnabbb.cz/tmp/i2.inc.txt

but it is no use of it at all

cheers

roman

l18n is desperately needed - osCommerce approach?

steffen commented 6 February 2005 at 15:52

I just picked up Drupal after having tested a large number of CMS. I picked Drupal because seemingly it had support for multilingual content, which was really important.

I have now, after having played around a bit, had some trouble configuring this. I think it needs to be in the default package.

look at osCommerce - it has multilingual support, and is extremely popular worldwide, and almost every contribution to osCommerce has multiple translations. I suspect Drupal would definitely be much more successful with full l18n support out of the box!

multilingual is important feature

gudra commented 15 February 2005 at 13:16

Mising of multilingual support is the main reason why I still not using Drupal in my portals. I need my portals to be bilingual at least. And the newest I need in lithuanian, english, russian, german, french and spanish.

I am still using PostNuke cause it has couple of modules in which are excelently integrated support of multilingual capabilities of this CMS (pagesseter and contentexpress i.e.).

Users of my site can select language simply from dropdown and not only the CMS strings are translated, but they will see content that belongs to their language or are marked as language indpendent.

I will prefer Drupal only when it will provide true multilingual content manage possibilities for third part modules, without need hack or patch core CMS modules.

I am sorry but words 'everybody should talk like me' smels not good ;)

Good CMS should be language independant and only in this case it will be good for communities worldwide.

What is the state at the moment?

galder commented 3 March 2005 at 21:50

Hello,

I see that some of the comments are not recent. What is the situation now?

Drupal seems to be appropiate for my aims, but this point is very important for me.

Thanks in advance,

Galder

Basque Country

I second the request.

Shannon commented 3 March 2005 at 23:31

I second the request. Localization is important to me as well.

short status report

chx commented 4 March 2005 at 01:11

i18n is in a good shape now, last I checked worked with CVS though it is changing like a whirlwind these days. Alas there are some patches still, but much less than before. I think I know of some taxonomy translation bugs. I'll deal with i18n next Wednesday or so. Not sure about Jose. Both of us has a lot of work and I will have my first ever public speech (on SQLite, at the Hungarian PHP conference) next Saturday.

--
Drupal development: making the world better, one patch at a time. | A bedroom without a teddy is like a face without a smile.

is there anything we can do to help?

Carlos Miranda Levy commented 4 March 2005 at 01:38

current approach does not work for most users and I couldn't find a single patch app that wouldn't give an error message when I tried to apply the patch provided about 3 months ago...

is there anything we can do to help?

is there an alternative approach?

------
Con paciencia y calma,
sube un burro a una palma

Indeed Status report!

whoey commented 5 March 2005 at 18:38

Well I have a development setup of drupal, I had tried it before about a year ago and found the taxonomy extremely confusing for basic users... after messing with others for a while I finally gave Drupal another chance.

I need to build a site with multi-lingual content (5 languages to be exact), and the i18n module seems to do the trick for the content. My only problem is getting the primary/secondary menus to translate as well as the content. I think the biggest problem I'm having has to do with the PHPTemplate theme/module REQUIRING the menus to be defined in its configuration.

Any thoughts?

I had the same issue, here

jmlane commented 6 March 2005 at 03:32

I had the same issue, here is what I did: Intergration with PHPtemplate engine.

I'm still trying to figure out how I can translate the titles of custom defined blocks with i18n. The content can be translated by enclosing it in t() function, but as for the title, no dice so far.

Jonathan

great!

whoey commented 9 March 2005 at 09:10

thanks for that, I'll check it out (test) later this evening when I have a moment.

The only thing that seems to work properly (that I've seen in use) is to have multiple versions running in sub dirs (domain.tld/en etc) for each language... that becomes very complicated, especially if you need 5 setups... I see that v4.6 has multi site support, which will help, but doesn't entirely solve the problems. I like the idea behind i18n, and it has the potential to do great things.

Language & country

elv commented 2 May 2005 at 14:04

I think it's important to remember that some countries have more than a unique official language!

Canada has English and French as official languages
Belgium has 3, Dutch, French and German
Kenyan official language is English but the national one is Kiswahili
It's also true for big countries like China, India...

You could think this problem is easily solved with common multilingual strategies, like websites split into 2 or more subsites, one for each language.
It works well for most websites, like http://www.mozilla-europe.org (look at the bottom of the homepage. Yes indeed, 15 languages!)

But sometimes you don't necessarily want to serve the same pages to everyone in a given language :
A Canadian company may want to display the same pages for english AND french speaking Canadian visitors (with content in the appropriate language), and different english pages for American customers... And the company could also need to share the same content for everyone in every language on some pages!

It sounds like a nighmare to handle but this scenario is quite common, at least in Europe.
In Drupal it may be solved with taxonomies, and by translating pages only if required. But it could also become a big mess, and a lower-level solution may be more appropriate.
Handling a list of "authorized translations" for every page could be a start: If a content is for german speaking people only, a contributor shouldn't be able to create a translation. On the other hand when he creates a new content for a given category or "geographical area", he should see which translations are needed (so he can give the work to translators).

Language and country

pierreluc commented 19 May 2005 at 12:25

I am a little new about that but it s look like they only provide static pages this way. What is their use of drpal then ?

pierre-luc gervais
MadagascarNet

Languages are taxonomy terms or vocabularies.

ñull commented 27 May 2005 at 18:22

First of all, many thanks for making the effort and attempting to make Drupal multilingual. I have been playing with your module and like you say yourself, it does the job, but we are not really happy yet.

When I would have been a bit younger and would have a bit more experience with programming, I would personally have chosen a different approach. The beauty is in simple solutions without changing the core of Drupal too much.

This would be my approach:
- for each language a Taxonomy vocabulary or term.
- a module similar to Taxonomy Access Module that would only allow access to the vocabulary or term based on the chosen language. I was even playing with the thought that when languages would be roles, the Taxonomy Access Module would be sufficient, even allowing to see all languages together: there are multilingual person, you know?
- the same module would make it possible for administrators to relate the different translations of a node with each other and once related would provide an interface to edit them together in one screen. A module like that could serve also other purposes where related nodes need to be edited together.

With the above scheme the different languages would be maintained according to the "spirit" of Drupal. In my opinion the present solution reminds of other CMS and seems like imposing a foreign philosophy. Drupal however is not like other CMS and should not become like them.

OScommerce is mentioned in one of the replies. With OSC you can see the different languages in one page. I think in Drupal a module could be developed that allows you to do the same. to be working on different related nodes in a single form. The ease of editing and translating is only useful for rather static content. I don't think it would be problematic to manually relate nodes with each other by means of a module. It doesn't need to be automatic.

I am not very good at expressing ideas in writing and I hope this was clear enough. My experience and expertise with Drupal is limited so not everything might be possible what I wrote.

Multi Language Support

searchboy commented 21 July 2005 at 19:53

From my point of view, i have been reading all post since last year related to multi language support. I am new to Drupal and this CMS seems like a great tool. The only inconvenient i see for now to go further using this tool is about multi language support. I need a CMS that will help me develop a web site in both French and English without having to install two different version of the CMS.

For sure, if this function works in a near futur, i will start using Drupal CMS. For now, i am using eGroupware that includes a CMS (site manager) giving the ability to build as many sites in any languages.

Multilingual Support is a MUST !

DAfshar commented 4 September 2005 at 11:48

I can't believe that any CMS would not support multilingual support in its core. Whether it be open source or proprietal software, the end user is your target customer. By limiting your software to one language, you therefore limit your marketability.

I have had my eye on several CMS options, Drupal being one of them. I have even seen developers from other CMS platforms migrate to Drupal. And Drupal is impressive but its future limited without the integration of multilingual capabilities.

Hats off to those trying to implement this very difficult but necessary component. As I am not a coder or even a hacker, but merely an end-user, allow me to say that without targeting corporate or organizational users you severely limit your financial options. Drupal has A LOT of potential but Mambo and Joomla are ahead of the game already.

To the developers of Drupal's core, I strongly suggest taking into account the suggestions of the many who have voiced suggestions in this thread. Strengthen the product and build your community until there are no other CMS options except Drupal.

I will continue to watch your progress and good luck to all of you!

Daren Afshar
President
Winery Productions
http://w-p.biz

I agree we definetely need

insomoz commented 9 September 2005 at 19:14

I agree we definetely need something like this, I have a football site, and as its a global game, i would love to tap into hundreds of countries that cannot read or write english very well.

I believe that the first cms that is open source and that is able to do this for guest users will make giant strides....

Multilingual for Esperanto, or just use Esperanto...

simplulo commented 18 September 2005 at 15:21

>I can't believe that any CMS would not support multilingual support in its core.

If you live in a large, mostly single-language country, other languages and even other countries are an afterthought. Europeans love to keep reminding poor expat Americans like me about this (enough already, I get the point!). There are 6000 languages in the world, and only 200 countries. Even if you throw out Indonesia, that leaves a lot of languages. Even if you just focus on Europe, that still leaves some half billion people and 20 languages. Clearly there is a demand, and the CMS that solves this difficult problem will be the product of choice here; webmasters will want to leave the multilingual door open, even if those planned other languages never quite get added.

In our case, we are looking for a CMS to support truly *multi* (>2)-lingual sites, with one language being Esperanto. But we are not yet convinced about Drupal. Where is development headed now? Are there any example of n-language Drupal sites, with n being as large as possible? I am only aware of this list:
http://del.icio.us/tag/i18n+drupal
Even if the i18n module is not perfect, is it enough to justify selecting Drupal over the alternatives?

http://xaneon.com/content-management-systems/drupal-vs-mambo_4.html
"More so, now having lots of practical experience building multilingual sites with both Mambo and Drupal, Drupal's i18n works very well and as it is intended to, and feels fully integrated into the system, not 'hackish' in any way."

"A case for better handling of multi-lingual objects in Drupal" August 25, 2005
http://drupal.org/node/29645
"I have been talking to a number of Drupal advocates this spring, all of which acknowledged that Drupal still does not handle multi-lingual objects all that well, but all were convinced that it was an issue that was taken seriously by core developers and was part of the roadmap."

Where is this roadmap, and where is multi-lingual support on it?
http://drupal.org/search/node/roadmap

Need for multilingual from "a novice"

Bertrand_Lefort commented 21 December 2005 at 02:44

Hello,

I am a Drupal "rookie" so probably I'm not the right person to give suggestions, but :

--- "no modifications of the standard Drupal database scheme will get into core for i18n, simply because only very few sites will need it"

I develop Canadian Web Sites. Canada has two official languages and all the Web sites I have created until now are bilingual. I think that many people will not use Drupal until it becomes a multi-lingual CMS.

I have been using Drupal for a month now and I have used the Internationalisation modules. I like Drupal very much. I found it easy to install and use. I like I18n modules for its "practical" approach. I mean that managing the translation is very simple. Many thanks for Jose A Reyero for creating this great module !!!

What I do not like is that the core is modified and consequently, all modules are not fully compatible or translatable.

---"I am afraid that your solution will generally have too much impact on core and will be rejected for this reason. Hear my warning."

I am a beginner in Drupal, but If I understand, nobody would be able to developp a multilingual site without patching the core. The problem is to introduce a new variable in Drupal URLS that allow all pages to be translated.

Novice question : would it be possible to implement a new function that would allow people to implement a hook that would allow to modify all Drupal's URL :

ex. in common.inc (this is certainly not the perfect place, but...)
(...)

 $usrvar = get_usr_variable();
return '<a href="/'. check_url(url($path, $query, $fragment, $absolute)) . $usrvar .'"'. drupal_attributes($attributes) .'>'. ($html ? $text : check_plain($text)) .'</a>';

Could be used to return:

?q=admin&l=en

It is less "elegant' that the i18n current solution, but it may be usefull for many developpers for all kinds of purposes (it should not interact with other modules).

---"I really don't like your approach and prefer the approach where you prefix the tables with locales. That approach makes more sense because then es/node/111 will be the same as fr/node/111 but only translated."

I prefer the approach where we prefix tables. I prefer independent tables because it is possible to have all drupals modules multilingual and it keeps the other "system" tables (users...) unique. The number of available modules is really great and could be translated with this approach.

I do not like the suggested approach where es/node/111 will be the same as fr/node/111 because when you update a Web site, the content does not change at the same time. Sometimes you have English pages first, sometimes you have french pages first. Having the same node translated, may imply to have a "default langage node table" that will be used to generate node ID.

Many thanks

Bertrand

An example

La Teresto commented 21 February 2006 at 01:20

Hey,

Our website is an example of a "try" using mutilanguage content (in our case 5 languages).

http://www.theearthbeing.org

The static content is successfully translated and even the taxonomy is acceptable, but the fact that so many little things bug :

* No translation for the general information in Settings
* "Access Denied" and "Page not found" pages cannot be correclty used with translation (or I haven't found how yet)
* No translation available for custom fields in the user profiles
* No translation available for automatic messages sent to users when new account is made, etc

makes me conclude that this cannot be seriously presented to a multilingual group of people, unless the website is static. I have had many people complaining about the inefficiency of the user accounts with multilanguage.

I approve the point of view that states that a complete and strong multilingual support for Drupal would make it beyond competition. We should make whatever necessary to achieve this.

La Teresto

What version of Drupal are

phrax commented 23 February 2006 at 01:53

What version of Drupal are you running? 4.6?

Version

La Teresto commented 28 February 2006 at 06:32

We are version 4.6.3 + module i18n and others
I am missing something ?

Menus

JordiTR commented 24 February 2006 at 16:03

How are you creating your navigation menu (which is perfectly translated)?, blocks?, any taxonomy additional module?,...

thanks softps

AboSaleem commented 18 April 2007 at 09:09

thanks

softps

Do we need multi language? Oh YES!!!

gejepe commented 14 July 2007 at 18:07

I do need multi language for most of my sites, at least two, but most of them four or more. I choose Drupal because it is supposed to be multi language, but as it turns out I either have to give anonymous users access to the Locales admin node (no way!) or they have to put up with English.
However, I have two other pieces of software installed that do a decent - http://b2evolution.net - or very good - http://gallery.menalto.com - job at this.
Since I don't know the first thing about programming, and already having trouble learning CSS, I'm probably sinning of ignorance, but as these also run PHP and MySQL, wouldn't it be possible to get code from them to help solve this - for me - MAJOR prob?

GRTZ.,
Gerard