There is an effort to bring internationalization (i18n) tools to Drupal core. But to make this happen first we need your help! We are about to introduce content translation capabilities into Drupal, and to do it best, we would like to ask for your feedback in two areas.

  1. If you have used any system which has decent internationalization support, please provide us with a link and a short overview of how that system is good in internationalization. We are looking at how well others do it to learn from them.
  2. If you have built a site with Drupal or some other system, where internationalization was a requirement, we would welcome a writeup of how did i18n fit into that system, what were the requirements and the desired workflow. We are looking for use cases to build a map of what should we think about when planning the Drupal internationalization subsystem.

If you provide some feedback, your needs and requirements might eventually get satisfied in the final implementation. If you keep your ideas yourself, we might end up with a system, which solves our problems nicely, but not yours. You can also join the internationalization working group, if you would like to be a more active contributor to the movement.


Robardi56’s picture

When you say you are looking to introduce "content translation capabilities", does it mean you are looking for a way to introduce translation of admin and user interface, or you really mean content created like page, calendar events and so on ?


Gábor Hojtsy’s picture

Locale support is already well done as far as I see, although there are some small spots, where it is not yet perfect. Maybe you don't have Drupal translated to your language because nobody have done it yet? The infrastructure is right in place.

We are looking into adding *content* translation capabilities, which might mean pages, stories, news items, calendar events, menu items, navigation links, site mission statements and such. What will come out largely depends on what needs the community express and whether we can find the right solutions. Now we are collecting needs and ideas, so the exact goals are not defined yet.

mcurry’s picture

How does one switch content languages on-the-fly, assuming one has translated content in the database? Browser headers? User preferences? What's the best approach for this?

Or have I missed a handbook page on this subject...?

Michael Curry -

hass’s picture

...switching on anything the client provide... browser preferred content language is not save (with Bot's). only a save language detection can be done by a unique url or if the user is logged in on with the user preferences... see my comment #5 on for more info.

Dries’s picture

Hi Brakkar, we're looking to translate the actual content. Translating the user interface is taken care of by the locale module, which has been part of Drupal core for a very long time. What we are trying to do is move the i18n module to core (and to get it to the next level while we are at it). Does that answer your question? Hope it does.

Robardi56’s picture

Hi Dries,
yes, it does answer my question, thanks. Again, a great move from Drupal to provide content translation, but i'm afraid I don't know any decent other system to be inspired from about this matter.
Sorry, you can delete my posts on this topic if you feel it adds confusion.


ldsandon’s picture

IMHO the simplest way to achieve this is to add a language field to each "content" in the database and fetch the proper one depending on the current selected language - without playing with URLs or the like. You can add an "all" tag for contents to be served for any language, and maybe a selectable "default" language to be used when the "current" language is not available.

When editing contents the user could simply switch to another active language and Drupal should fetch the correct data, and if not available select the default current content to be translated.


Roberto Gerola’s picture

I've developed a module alternative to Internationalization module.
A list of current features, based also on feedback and requests of users :

  • supports 3 different types of url for language switching :
    • through hostname :,
    • appending the locale parameter followed by the language : ?locale=en, ?locale=it, ?locale=fr ...
    • creating url alias with the prefix of the country code : it/home, en/ home, fr/home
  • provides a language switch block
    You can put everywhere the language switching block calling the PHP function : localizer_changelanguageblock();
    In your HTML code, simply add :
    <?php localizer_changelanguageblock(); ?>
  • translates the node's content
  • translates the user's menus
  • localized latest posts listing support
  • provides a news block with a new break tag : <!--newsbreak-->
  • blog listing and block support
  • taxonomy listing support
  • supports translating of taxonomy terms through locale module (it translates only the terms, you don't have to categorize every localized content with its own, localized, terms)

You can get it here :
I'm finishing in this hours poll support.

Perhaps you can grab from it some ideas for a new implementation in Drupal core.



Carlitus’s picture

I think it's the best option (in SEO and user terms) and i hope it will be implemented in i18n soon.

liquidcms’s picture

Haven't read entire thread here yet but one point that hopefully has been made (and showed up in Roberto's post here) is that a FULL bilingual site requires bilingual URLs as well.

So, in Roberto's case, i18n would need to be able to support en/home and fr/accueil (not fr/home)

Currently i think there are 2 ways to do i18n menus:

1. 2 sperate menu blocks
2. translate the menu items

I prefer #2 since i dont need to make more menus and keep them sorted out and in same order. Plus i think it will work with cat_menu module (when it is ready for prime time).

HOWEVER, i dont think current i18n has supoprt for translating the URL in this case.

more on this with my partial fix at:

Peter Lindstrom

Dries’s picture

Posted my ideas. Thanks for the work, Gabor.

Florian’s picture

I have a few multi-language websites runing on Drupal but I have done that using multi-site installations. Take a look at the websites below: - - -

Well this aproach, of having nodes in different databases is safe (strong implementation, SEO safe - no duplicate content, a.s.o.) and easy to be done but there are no posibilities of searching the entire content (this is done only by per sub-site basis).

Now I am working on a big project in all the European languages so I approach the i18n concept which looks ok but there is a tremendous efort regarding links translation. Note that I am using nice-menu. There are limited possibilities to give translation rights on a per language basis, also, and my big problem is content duplication.

We have to think on what will be common and what content will be different. Well the nodes, menus and language dependant variables, well done by the i18n module, except the menus. But we still must have language content in different tables. This will avoid content duplication and the data must be reused properly on a per language basis.

i18n must install prefixed tables for each node to be translated and links those nodes. We will need a second prefixed table for menus. It is like we will have:
en_node (this is on a basic instalation);
fr_node, hu_node, .... (this is done by hand, or by i18n)

The big problem i18n has is that it creates links using a redundant pattern which lead to duplicate content:
/node/1 ... /en/english-title, /node/2 ... /lang/lang-title and each page is accesible using te clean url with en, lang, or without.
This must become:
/node/1 ... /english-title, /node/2 ... /lang-title

My new project (European Copyright) will be done in a few weeks using multi-site approach but I am still wondering if it worth waiting for Drupal 5.0 with internationalisation support.

The World is a big puzzle but not a solved one!


Dries’s picture

My new project (European Copyright) will be done in a few weeks using multi-site approach but I am still wondering if it worth waiting for Drupal 5.0 with internationalisation support.

It is not Drupal 5.0 that will have i18n in core but Drupal 6.0 or Drupal 7.0. In other words, better not to wait because it might take us up to a year. ;)

Btw, it is better to describe your use-cases rather then your technical implementation.

marc.bau’s picture

i posted myself more then 15 bugs on i18n module after 3 hours testing and i can say - this module is completly unusable! some of them are realy blockers (menu not expanding, fontpage looses language, articles not exist in selected language switch content the language, and so on). i'm sure if i do more testing i will find tons of more bugs and i cannot understand if someone is using this module. i'd like to translate my page - but this is not possible with this module. every click done the user looses his selected language. frontpage isn't working and so on and so on. i removed this from the testsystem and stayed in german only now.

i hope you get it into drupal ASAP... one year is realy a very long time :-(((

marc.bau’s picture

it will be better to have the node table extended with a languageID field what is a reference to language table...

Gábor Hojtsy’s picture

The current i18n module implementation is not using table prefixes to store nodes as you show here. Language information is attached to nodes themselfs using the i18n_nodes table.

WJ’s picture

WJ’s picture

Hello Florian and any senior helpers,

Thanks for your sharing and guiding in

Your multi-site approach looks quite familiar as that of Wikipedia to present multiple languages. For examples, Wikipeida may show same topic in different languages via
http://en.wikipedia/org/wiki/... and

Nevertheless, your arrangement still looks a bit different and unique, which is judged not using some sort of wiki software.

Could you share more insights and explain what differences are there?


leflores’s picture

I made a site with i18n support (, and faced several issues that I believe should be addressed before bringing this module to the drupal core. The most difficult to deal is related to images.

Image nodes are treated as regular nodes, so if I would like to provide a multilingual image I need to upload the same image for every languge that the site supports.

Other modules that works with images have the same problem. For example in our site we have used CCK to provide a hotel information page (see this:, as we also need to provide multilingual hotel pages and we did not like to have to upload every hotel image twice we had to create two separate CCK one in english where the images were uploaded, and other in panish where we referenced the images from the english CCK.

All this is complicated, there have to be a way where a image could be used by each translation of the node.

Luis Flores

Dries’s picture

Maybe we just need better asset management for that? It might not be a problem specific to i18n module because reusing images (in general) can be a pain. Food for thought.

magoo’s picture

Currently (in 5.7), if you have a CCK image field in a content type and i18n modules installed, you will have a problem when you want to upload another picture in the translated node.

The result will be the deletion of the original picture! So the first node will not have any picture anymore.

I agree that setting up a multilingual site on one installation is a pain in the a*#. Especially when you need some kind of control over the presented elements. My current issue is to define a way to have a block on the frontpage containing several fields of a webmaster defined node (i.e. not the teaser OotB). This node is translated and must be presented with the correct language.

I would have though using a view and a nodequeue of size 1 would have helped, but it does not handle the translation: it only hides the node (return an empty set) to the other languages.

I am currently clueless as I don't want (have time) to hack a module for this.


spazio’s picture

I have set up a site, which we want to develop into a community blog
( concerning issues about Asia. I installed the i18n modules and it works fine for on the site. There a number of new articles in the pipeline and we will see soon how well it works in regards to our needs.

I think it is a great to include internationalization in core!

All the best!


marc.bau’s picture

you site isn't switching the language... every klick i do on the language switcher links - the site is in german...

tadashi’s picture

It switches language, but for the ui only, not content.

Not sure how useful Arabic speakers are going to find an Arabic navigation menu when the content is all in German ;)

abaryudin’s picture

I use i18n in my site - and it is quite useful. Most of the content is in English, but the main pages are translated into Russian. Using i18n as it is makes the task quite easy and straightforward. It has cetrain glitches here and there, the fact that you need to specify URL aliases manually in order to be redirected to a proper page (en/article.html - ru/article.html for example) and the language switcher is simply ugly - I would like to see one built-in in the theme (obviously, I can add it myself, but I like the fact that so far I have never touched Drupal source - and I like to keep it that way).

I don't think that the solution, mentioned above, namely to use mult-site installation, is a good one - i18n module keeps all your site in one database and retains at least some relationship between the original document and its translation.


aaron’s picture

Grasshopper Arts was developed about a year ago using i18n and Drupal 4.6. This puppet theater company wanted to have a fully bilingual site in English and Spanish. They needed both the menu and content to switch easily, and wanted to be able to easily translate content.

There were difficulties at the time translating the module, particularly because they originally wanted to use taxonomy_automenu for automatic category menus. However, because of the difficulties involved in making that work, I proposed a simpler menu system, using menu blocks for the two languages, that worked better in the end.

There was a learning curve involved in using i18n, and had to both install core patches and tweak things to make it work. I think that Internationalization is an essential for Drupal, and even without i18n being part of core, it helps to put Drupal far ahead of the other CMS's.

Having taken a peek at 4.7's i18n module, I see that many of the original issues from the earlier version have been addressed. I vote in favor of integrating it into core, because it ensures no further core patches as the module develops and because of the marketability.

jcerdan’s picture

I've been building 3 or 4 sites using i18n module from José Reyero and it looks really good. But I think that some things should be improved: in fact, block or menus should improve it way translations are handled. It looks horrible to create 4 menus (one for each language) and then have 4 blocks appeared and have to join them on a 1 multilingual block.
It's not a bad idea, but I think that when creating a new Menu, you should have to choose if it's going to be a translated menu. Then translations should go the way nodes are translated. Finally, only one block should appear and translations should be automatically handled by the system.

scb’s picture

I think that would be a gret feature. Some kind of "resurce manager" common to the whole drupal site, with a file-manager-like (or ftp-like) interface, where one could manage all non-textual resources (uploaded files, images, including CCK imagefields, etc.). Those resources would not be necessarily nodes (like in image module), but files, which would just be referenced somehow by their container nodes, or even controlled by some hooks (hook_resource_add, etc.)
This would help i18n (the concept, not the module) a lot, avoiding unnecessary content replication. Such a common "resource pool" might lead to confusion, though...
I don't know if such a module (or similar) exists already...
(Excuse me if this is slightly OT)

jbjaaz’s picture

Is straight translation really the way to go? I once did an internship at a company called Lionbridge. There main business was to translate software. Early on, they told me that in most cases you can't just translate word for word. Some languages, like the asian languages, depend on the context. The context influences the translation more than anything.

The only example I can remember was when windows first shipped its chinese version, it horribly failed because translations were just incorrect.

Actually, last week a friend of mine had his CD reviewed by a german zine. He put the review through googles german to english translation and what came out was completely nonsensical. I mean you could pick out fragments here and there, but most of it was "lost in translation". (sorry, I couldn't resist)

I'm not saying, don't do straight translations. But I would like to see others comment on their thoughts on this. Are some languages easier to translate than others? Has anyone had a page translated automatically and recieved complaints that the way something was worded was insulting.


robertDouglass’s picture

The issue at hand is more along the lines of "how do we want to represent different translations of content in the database? Should they each be nodes? Should they be revisions of the same node? What should the URLs look like?" etc. The actual translations will be done by humans, as needed, on a site-by-site basis.

- Robert Douglass

Lullabot | My Drupal book | My Digg stories

andremolnar’s picture

Use cases:
Mulitilingual sites often have multilingual domains
language switching must be available by host or domain name -, example.ft,

Translate only what you want and when you want.
Not all nodes need to be translated. Not all nodes can be translated at once. Give users the option of what to translate and what to leave alone. Give users the option of what to display when there is no translation (404 or node in default language).

Unify interfaces for translation.
Different mechanisms are used to create different site elements (menus, categories, nodes). This does not mean that users should be required to learn three or more ways to translate elements that show up on a site. (I don't even know if this is possible or how one would go about it - but it is a usability concern).

General comments.
At least 2 other modules have been written to do what i18n should do (localizer and tr). Both seem to do a better job of internationalization than i18n. Both seem to have been written because i18n was un-workable and/or un-patchable. Consider a ground up re-write of i18n.


carlmcdade’s picture

One of the things I have had to do extensively when doing i18n is to add a language column to database tables. Without doing this nothing ever becomes easy to do. This is especially true when using taxonomy. Term data has to have a language column or things just stop working or you get lots of duplication. Having the language columns also cuts down on the size of queries involved and keeps you from having to join to a large table for simple information. Thus increasing the speed of queries.

Templates are another area. To get the right encoding you really need to be able to have the ability to switch the page languages used. Just doing utf-8 does not cover all the problems that come up.

Hiveminds Magazine
for web publishers and community builders

Gábor Hojtsy’s picture

Templates are another area. To get the right encoding you really need to be able to have the ability to switch the page languages used. Just doing utf-8 does not cover all the problems that come up.

What do you mean with this? We are using utf-8 and provide a locale module already in core, which translates the interface strings. What do you mean by "to get the right encoding"? It is already possible to switch the page language used (for registered users, if more interface languages are installed on the site). Maybe we are thinking about different things?

hass’s picture

i think he is talking about, some sites may need UTF-16 or special Korea encodings or things like this, isn't it? some chars of this world are not included in the UTF-8 charset...

we should criticise, why there is so much UTF-8 today and we must upgrade in some time to UTF-16... i don't know - but this sounds like the step from 16bit windows to 32bit at a time we know - solaris has used 64bit for years... :-). A sensless intermediate step on internationalisation, isn't it?

carlmcdade’s picture

Exactly. Changing the characterset and direction requires that you go into the template and do it manually. There should be settings for them when adding a language.

There should also be an option to set your own complete HTML header for a language.

Hiveminds Magazine
for web publishers and community builders

Gábor Hojtsy’s picture

In what case would you need to change the charset? What characters are not possible to display/request in UTF-8?

Gábor Hojtsy’s picture

What do you mean by upgrading to utf-16 from utf-8, why is it a requirement? These are just different representations for the same characters. Read and/or other FAQs and/or the spec, if you think differently.

UTF-8 (8-bit UCS/Unicode Transformation Format) is a variable-length character encoding for Unicode created by Ken Thompson and Rob Pike. It is able to represent any universal character in the Unicode standard ...

hedac’s picture

Current implementation of translations is on a wrong way in my humble opinion... i18n works creating another node and creating another term and creating relations of those nodes and those terms... This only creates problems of duplication and references.

Also... sometimes a content type has many fields which are not depending on the language... such as.. dates, names, locations, images.... and there is no need to duplicate it in the database. So...

I would implement a different aproach to translations of content. It is more logical to create different fields inside the node with the different languages, and then render only the correct language for those needing translation. This can be done in some way now with CCK nodes.. as I wrote here: Just an idea
Then it is needed to translate the taxonomy terms and vocabularies on the fly too. with the locale module.

The node is the fundamental piece of information. Language should be only a screen output variable of it. It shouldn't have to be another another node, because this complicates everything and sometimes wastes database space. It's like having one site with different languages outputs (which is what we want) vs. having multiple sites with different languages and similar contents all with the same template.

Roberto Gerola’s picture

I think it depends.
In some circumstances you need different nodes for different languages, not only a translation.
Think, for example, to a blog or to a list of resources. It makes sense to have different content for different languages.
Also attachments to each node many times are dependent on the language, so you need a node for every
language or at least the option to define the language for the attachment.

I'm not sure that the db performance are better having a translation for every , or better for every node that needs it,
field of a node.
You have to send to the db the query for loading the node and a query for every field to translate.
Duplicating the nodes you send only a query for every node.
To avoid additional referencing tables and joins, the simplest solution could be add directly the language field
and the translations relations directly to the node.

Perhaps a combination of the two approaches can give the maximum flexibility.


jbjaaz’s picture

I think it depends. In some circumstances you need different nodes for different languages, not only a translation.

agreed Roberto

Localization, as a whole, is worth considering.

... Specifically, localization refers to customizing sites to reflect appropriate:

  • numeric, date and time formats,
  • currencies,
  • keyboard usages,
  • use of color, and
  • sensitivity to cultural perceptions of language, iconography, and imagery.


jpsalter’s picture

My wife's site provides science curriculum to middle school teachers.

We would like to enable volunteers to translate the pages. So far we have volunteers for Chinese, Arabic, and Spanish.

So, I would like a set of access privileges that would allow these users to see a tab for their language of choice - visible when they edit a node. They would see the English version and have a 2nd window to create the translation. These would be linked to the original node - maybe by using something similar to the revision system?

For the menu system and the taxonomy I would like to use the t() translation function. Recreating an entire taxonomy and menu system each time a language is added does not seem to apply to this use case.

Additional tools could help locate untranslated pages, partially translated pages, and missing taxonomy and menu translations. If one was to get fancy - there could also be a review process before the translated pages were published.

I've played around with adding t() to the menu and taxonomy systems - and it works like a charm.

Anyone else interested in a set of tools that allow volunteers to add translations to an existing website?

leflores’s picture

If we create some kind of multi-language node it would be easier to manage for example image nodes (we would not need to duplicate the jpg), just create a title and description for each language. This is the approach of OsCommerce, where with internationalization each product will have description and title in each language.

This is not in opposition to have separate nodes for languages, such as blogs, stories, etc. I believe that creating a content type multilingual-page, multilingual-image, etc. must be an option for nodes that must exist in EACH language. This would be better than creating a node for each language.

Luis Flores

miiimooo’s picture

I have just returned to i18n and I find it still frustrating. While the support in core of Drupal 6 is straight forward i18n is confusing and often gives unexpected results. I had to abandon a project earlier this year because the client and myself got too confused and frustrated with i18n.
I have coded the multilingual extension for the ActionApps CMS a couple of years ago and back then we decided to go for a system where - in Drupal terms - translations are done node by node (similar to content translation) and something similar to t(). In the long run it's working quite okay but if I had to do it again I'd do it differently. From a user perspective very field on a page should simply be translatable if needed. For the CMS it means having a language field for every row in the database. That way you can do partial translations, easily query what hasn't been translated etc. For the user it's nice as she can (ideally) just click "translate to French" next to let's say the title field instead of creating a new page and filling out all other fields. Same goes for attachments, have a little menu saying "add attachment in French" or "use this attachment for French/all languages" is what is most intuitive for the user.
I'm not sure about menus, and I think that's what makes things complicated. In the current i18n using menu translation is hugely confusing. It should just have a primary menu and next to each item say something like "will be displayed when in English", and a menu saying "also display in French/all languages" and then "also display in French/all languages -> add translation(s)".
I'd love to see the localizer module in action but it appears to have been abandoned.

My $0.02...

amuzulo’s picture

We're currently translating our site into 12 languages and I don't want to publish any language until a translation is complete, but yet under the current system I never know when a translation is complete. There's also no way to let translators know when pages are updated. So, currently we have a bunch of translated content, but no way to professional publish it and our translators are starting to get impatient with me and I don't have time right now to delve into the source code to get it to match our requirements. A lot of visitors are also getting upset, because with our old system we had our website in 20+ languages and now it's only in one. We use Esperanto as our base language and translate everything from that using volunteers. I would also like a system to only require the following content to be translated: all front page content and all nodes of type page.

1) a list showing translation progress across languages (categorized by status: not translated, old translation, up to date, up to date and proofread)
2) languages need to have states of active and in translation so we don't show a language that has not been completed

1) when a page is not up to date in the target language of the user, show the page with a list of languages in which that page is up to date

marc.bau’s picture

you are not alone... this is required pice... i logged a bug about this in i18n. it must be possible to translate in backround and then turn a switch - "fr" goes live *now*. This is not possible with i18n module today...

asside - until weeks nobody answered to the bugs - is there someone realy working on i18n module?

Roberto Gerola’s picture

If I understand correctly you need :

1) Add a status field to each node, besides language, where is it possible to define the status of translation of the node.
This little workflow should drived partially by human and partially by Drupal.
When you update the main node, all the translated nodes go in status old translation.
Then the person that check the translation can put it in status 'up to date' or 'up to date and proofread'.
This information must be presented in the trnaslation tab of each node, but also in a separate page, a sort of
report to verify the status of the translation of each node.
But then, also a flag for each node should be necessary, I think, : to translate, not to translate.

2) This should have only impact on the language block switcher, right ?
For each language is necessary to add a status field.


simplulo’s picture

>But then, also a flag for each node should be necessary, I think, : to translate, not to translate.

Maybe there should be a level of necessity for translation or synchronizing of translations. For example, in Wikipedia it is desirable to have each entry translated, but little or no attempt is made to keep them synched.

>When you update the main node, all the translated nodes go in status old translation.

You would want a flag for the main node, as it might not always be the same language, though one language could be the default source.

carlmcdade’s picture

Part of the reason this is hard to implement is because Drupal does not have true content staging. If it did then going the next step into controlling unfinished content by language would be possible.

But this goes more into the core architecture which at the moment is not open to i18n. i18n is being forced upon the core. What is needed is a re-write to add in a default dispatcher for the english language. Then changing to another language would be a lot easier. Right now english controls are being added in when i18n is installed.

Hiveminds Magazine
for web publishers and community builders

Gábor Hojtsy’s picture

Could you please elaborate on what you mean by this?

What is needed is a re-write to add in a default dispatcher for the english language. Then changing to another language would be a lot easier. Right now english controls are being added in when i18n is installed.

Is your problem that the assumed primary language is English? What would you expect given you have an English locale glaring on you from your screen on the Drupal pages? Or are we speaking about something different?

carlmcdade’s picture

This is the part that gets messed up when build on i18n module. The english should be explicit in the database and in the code not assumed. So if you have a language column table the default is always empty when it should not be. Also lack of "en" or whatever the default is should be there as a place holder so you don't get a code looping through "","en","sv",.....etc. When I do a i18n site I have to manually fill the empty fields which are blank and assumed to english be english. This is because the natural way of matching is for "en" = english and not "" = english, or "" = FR, or whatever the default language is at the time.

I think it was CMSMadeSimple that has this bug that when things are not right it switches to German even though the assumed default language is english.

Sorry, by dispatcher I meant "path" (too much CakePHP of late). Being redundant but right now "en" gets added to the overrided "path" when i18n is installed. It should be there already just as locale "en" is accounted for at install.

Hiveminds Magazine
for web publishers and community builders

aam’s picture

I am Using Drupal since the 4.3.0 version. And i had multilingual content before using Drupal and before the i18n module was written. So all language/translation-links were made manually and the user had to choose his language version manually too. I tryed i18n with Drupal 4.5.0: the language detection worked fine, all language/translation-links vere still hand made. The 4.6.0 version of i18n had too many errors for me, so I did not used i18n with Drupal 4.6.0. The current Drupal version 4.7.0 and the current version of i18n works now very fine for me and i use all features of i18n, including browser language detection, menu translation and content translation for most pages of my three books: , , .

I need all of the three main things for my site:
- localization of the user interface (locales module)
- menu translation for custom menu entries (i18n module)
- content translation and linking to translated/localized versions of pages/nodes (i18 module)

AAM: Building the Bridge to Real Content

marafa’s picture

i havent used i18n but i have been thinking of it for later use at the back of my mind. i just want the ppl in this group to know that some languages are RTL and not LTR. thats right to left and not left to right.
examples of rtl languages are arabic, farsi, hebrew and i think urdu.

also, most sites that i have seen that supports more than 1 language usually do it via flags of a representative country. eg. france's flag for french etc. although a few rare ones do it via drop down menu.


__________ اجدد اخبار ممثلين

brevity’s picture

When I set up a 4.6-site with multi-language support for content it did not work out as expected at all.

The site would not have all pages in two languages, but just very few (now: none! -- too difficult to maintain).
Instead the site contains some pages in the one language, other pages in the other.

Biggest problem here was with menu. Any page should be accessible via the menu, independant of current language.

Thus I fiddled with i18n and ended up adding translation/locale support for the menu items and such, with the result that the whole interface looks well translated but actual content (available in only one language) is accessible via both language interfaces.

Sure, this setup is very specific, but you should not live in seperate content worlds with seperate languages on a site.


incrn8’s picture

In my most recent project,, I was required to do English and French pages. I initially struggled a lot with i18n to figure out how things worked eg. language switching, menu translations, front pages, etc. After much trial and error, I got all that working fine. Having the two language blocks is too confusing I think, as this seems to be a problem with many people using i18n - a single block to handle all language switching is much simpler (not sure if its easier to implement though).

The menu translation was another problem area and I had to have duplicate menus. This is a relatively small bother now that the site stucture is pretty much done, but during development, having to alter two menus is a bit tricky. I had to create an Excel sheet to keep track of everything. I used Nice-menus to handle the drop-down menus, and had the English menu display only on en/* pages and French menu on fr/* pages.

Node duplication is only a problem where images/attachments are involved. The solution to this was using the Node-clone module. Definitely a feature that should be part of i18n. I haven't made up my mind whether the two node system is better than a revision-like system for handling translations - there are advantages and disadvatages to both (see previous comments). As for SEO, I haven't noticed any decrease in the site's ranking - its still #1 ;), so maybe the content duplication doesn't affect SEO that much? Anyway, I use different en & fr paths for the same content e.g. en/home = fr/accueil, so that might help a bit.

Overall, I like i18n. It has a few quirks, but once you know what they are and how to work around them, its a very usable system. Granted, the website I made doesn't use lots of languages and may not be super complicated, so there might be other issues that I never came across. However, for my needs it works well.

Recent Drupal websites: and


wonderland’s picture

I'll try to describe a use case instead of technical details. My i18n site is not ready yet, but this is what I would like to do in the future:

1.) The site will have a default language, e.g. all new content MUST be added in this language first as it is the common basis for all translators. In this case it will be english. It would be nice to have a way of forcing people to add new content in only this language. Or, even better, allow them to enter it in two languages at the time of node creation, their native language (as they might feel more comfortable to start with it) and then (possibly in second step) in the common language.

2.) Several translators for the different languages are translating new content. It would be nice to build some kind of workflow, e.g. send out notifications to translators (or a group of translators) when new content needs to be translated. Some translations might need a proofreading before the content goes live, a notification should be sent to the appropriated editor when a new translation needs to be checked.
Some nice overview site would be very useful. It should show some statistics (e.g. number of untranslated nodes per language) and a list of all untranslated nodes, sorted by language. This would help translators to find new content to translate.
Permissions should be set on a per language basis, e.g. a specific user can only create new content and translate into language x, another user can only translate into language y, an editor can only proofread ( and then publish the content) of a specific language.

3.) When a visitor accesses a site which has not been translated into his language yet, an information page should be displayed which gives a list of alternative languages in which the content is available. When the user chooses to view the content in another language this should not switch his language settings, e.g. only this page is shown in the alternative language, all links he follows after that lead him to content in his language.

4.) Different languages should be available by sub-domains, e.g.,,

5.) Content like images should be available across all translations, but with the option to change them for a specific translation (e.g. screenshots showing the program in the corresponding language).

Thats all I can think of right now. I think proper i18n support is one of the really important features that most CMS are missing right now. For me, one of the reasons to go with Drupal was that the i18n module is available and that I expect a focus on this for the next versions. i18n in core makes Drupal stand out even more. I propably can't help too much with it but I'm thinking to write up some documentation once I finished my i18n site. And I'm willing to donate some money if it helps i18n development :-)

..- Wonderland

carlmcdade’s picture

No. 1 and No. 5 I have done on this site. They are the two most important changes that I have made. They allow for complete seperation of content by language. Before I did this I was having problems with the Forum mixing nodes with an undesignated language with translated nodes. So going to the Swedish forum would show english nodes because of the blanks in the db table.

Hiveminds Magazine
for web publishers and community builders

jozef’s picture

Gabor, you should take a look at Joomla 1.0.x and Joom!fish 1.7 component.

From Joom!fish docs:
The idea of the Joom!Fish is to give you a tool that is enabling you to translate any dynamic information within your Joomla! CMS. The translation is based on a generic mapping between the database tables and the information needed for rendering your content, module or component output. It is in the responsibility of the 3rd Party developer to provide the required configuration files for the translation but generally there is no limitation in the structure or information you want to make translatable.
The integration of the automatic translation process is done by a special system bot which loads a new database transaction layer. This layer is inherited from the standard jDatabase class and transports the whole interface. The enhancements will automatically validate any query and automatically translate the content on the fly. This concept results in the fact that no 3rd Party component or any other object within the Joomla CMS framework needs to call a translation method. A call to the $database->loadResult() or $object->load() methods will return an already translated object.

JordiTR’s picture

Hi you all. That thread is starting to be long.

It's amazing to me that the core developers change whatever they want every time they want and to the extend they want and now they are shy to implement a i18n solution forever!, just in case they took the wrong approach :-? Meanwhile every time we have to afford a multilingual site it is a nightmare,... on each and every Drupal release since José Reyero and it's titanic effort is never considered and he's forced to do new and different things. I just wish that boy never gets tired of Drupal because we'll be left alone !!!!!

All in all, the present 4.7 + present.i18n.module is quite good, far better than it was on 4.6 (as wonderful as we don't have to patch and hack anything at all, just plain activate/desactivate a module). I got quite a complex site working on 4.6 with many contributed modules (included views) and i18n-ized. It was hard and having to deal with so many attempts was hard and impossible to finnish on the time-line. Well, it's opens source, isn't it?

The most lovely change on 4.7 has been the menu.module, i18n-wise, since simplyfies making menus to blocks for different sections of the site, which is a must on the corporate application of Drupal which is my field of work. Nevertheless I had to hack blocks.module to have a complete render of blocks (thru sections) adding some t().

All this IMHO :-)

wonderland’s picture

Full ACK! And a big thanks to Jose Reyero for providing us with the i18n.

..- Wonderland

JordiTR’s picture

Now we're having again a discussion to find the "Saint Grial" of Drupal i18n-zation, when the present Reyero's i18n.module produces a wonderful result, as good and as weak as Drupal itself on its present stage on many areas. Simply add i18n.module on core to the new release, touch a few things here and there to have a tight integration (with menus, blocks and taxonomies) and you're gone.

My impression is that people that don't accept the present approach and discuss the present Reyero's solution is simply because they're not making multilingual sites with Drupal, they're just discussing about the sex of angels. Of course Drupal could have and "astonishing-state-of-the-art" i18n solution but meanwhile we have nothing (except a brave coder supporting i18n by himself).

The only thing that prevents me on stop using Drupal for that lack of sense on internationalization is that there's no other open source CMS doing it better... Again IMHO (because I need i18n on every site I start as a site architect).

scb’s picture

I think everyone in appreciates Jose's huge efforts with i18n's development. We're very thankful for it. We're not talking about that.
We are discussing i18n's approach because it is just not working right. And, please, don't say we have not worked in i18n'd sites because most of us have. That's exactly why we're discussing this now.

I have used i18n for some sites (first in 4.6 then in 4.7), and it just doesn't work out of the box. Menu integration, taxonomy integration, and alias integration are poor. Duplicate content is a big problem, too. It is really hard to set up a i18n'd site flawlessly, and we're trying to change that.

JordiTR’s picture

Hi Sergio. I'm not specifically defending i18n.module, since my impression is that it is not better because it's not possible to change it without affecting the core design, something that José Reyero can't do alone and has been asking (himself) for a loooong time (seach on the forums). When I read those things a get confused.

Last i18n.module (on 4.7) works quite out-of-the-box since it doesn't require patching, but on the sites I work on, heavy corporate sites, multilingual, with complex permission assignments, variable menus systems, sections and adapted solutions for customer support that usually require new modules developement, Drupal itself is never an out-of-the-box solution but a wonderful framework. There are many ways to see such issue.

JordiTR’s picture

Have you ever set a Drupal site with 6 languages and a buch of contributed modules? Have a look to the locales_target table: it's huuuuuuuuuge !!! It's weird to see that a table which is "auxiliary" takes 30.000 registers, which takes alone 50% of a site database size (between 3 and 4 Mbs that table alone).

I don't know, it just makes me think how efficient is that approach. I'm not capable to propose an alternative. It's just weird to me.

alexmc’s picture

Not sure how useful it is but I developed as a multilingual site. The aim was that all articles would be available in Chinese and English. Of course the limiting factor is the translation time....

cghobbs’s picture

Battery Direct is the first site ImageX Media has developed using the internationalization module. The overall goal was to create a site that had a French mirror of the English site that would be easy to update. For the most part the internationalization modules were easy to use and required little custom programming. The documentation was a little weak, but other than that it is great. The same client is wanting us to build another site this time with 5 different languages (one of them is Chinese) which may prove to be challenging.

Let me know if you have any questions.

cubicray’s picture

I'm not sure yet if this is a good idea, but in some cases I think I'd prefer to add support for a second language by means of text bubbles that appear when the mouse cursor hovers over some text. Google's translation service does the same thing. I didn't know until the other day, that when you translate a page using Google's translation service, the original text appears in a bubble when you hover your cursor over the translated text. The effect works great, and I think now that we have jQuery we could do something similar. It would be nice to have this as an option to be part of the internationalization tools in the Drupal core. For example, in addition to being able to switch to another language version of the site, one could turn on the translation bubbles for that language instead. In some situations having a base language could improve the the communication and interaction between the users. It could help users communicate better about certain aspects of the website.

rondev’s picture

I use i18n (3 languages) in my corporate site Calibreuses Fachaux. That is why i choose Drupal.
I use it for pages, menus, webform, blocs.
I use no language for images, videos as it would make to much work to have the same media in different languages. For videos I put a text in three languages in the text area.
I use taxonomy menu but i18n doesn't work well when I change the parent of the vocabulary or change the title. Then I have to put a three-language title.
I added google translation for 3 other languages.

Savahn’s picture

There is also a site at still a work in progress
My biggest problem was having different content for different languages, we have menu items that only applies to one of the languages, which i did by creating 2 menu's and hardcoding a block in a module that themes the 2 menus according to what language was being shown. Very ugly hack, but the i18n didnt do it the way i wanted.

liquidcms’s picture

Currently I am working on a showcase for a Governement of Canada (bilingual) Drupal theme my company is developing. Although under contruction it can be viewed at:

I also worked on putting this bilingual Drupal site together:

and a few years ago I developed my own bilingual CMS for doing this internal web app for the Canadian National Research Council: (mock up only)

a few comments from doing these:

- need support for bilingual URLs (see post and partial fix at:

- when i did my own CMS for NRC site the FR content was sent out to a translator; from how the CMS was designed it was very easy to dump the EN content from tables into an Excel spreadsheet. This sheet was then sent to translation people who simply added FR content in cells beside EN content. This translated spreadsheet was then easily imported back into DB. Translators liked it, i liked it, clients loved it.

Perhaps later i will post work flow in doing Government of Canada (Common Look and Feel - CLF) Drupal Theme. But likely nothing to special there as far as bilingual goes - except full bilingual URLs, menus and graphic regions defined to allow bilingual graphic blocks (or disabling graphic altogether).

BTW - i think states one of Drupal biggest issues is no (out of the box) support for i18n. Getting this brought into core is a big advancement. Has everyone sent Jose a donation???

Peter Lindstrom

Ashraf Amayreh’s picture

Next week, I'm going to begin develpment of an arabic/english news site.

Arabic is an RTL language and I'm still researching modules. I believe I'll be using i18n.

I'll keep a close eye on problems as they arise and share them here. So I hope this topic stays alive for this project's development time. Hopefully all potential problems and possible solutions will spring up during development.

CEO | O-Minds
Skype. aamayreh

Connect with us on Twitter or LinkedIn.

Ashraf Amayreh’s picture

Next week, I'm going to begin develpment of an arabic/english news site.

Arabic is an RTL language and I'm still researching modules. I believe I'll be using i18n.

I'll keep a close eye on problems as they arise and share them here. So I hope this topic stays alive for this project's development time. Hopefully all potential problems and possible solutions will spring up during development.

CEO | O-Minds
Skype. aamayreh

Connect with us on Twitter or LinkedIn.

pdb’s picture

I have a partially multi-lingual Drupal setup on my personal homepage. I have many Portuguese friends from when I studied there, so I like to post some things with both English and Portuguese versions. The current implementation works reasonably well, though there are some issues, especially with add-on modules (like gsitemap) that can't deal with multiple languages without patches to other modules. I think it will be great to have i18n built into the core so that modules can handle multiple languages cleanly.

Since it is a simple personal site, my workflow is just to create a new node in English and then create another new node that translates it to Portuguese. Content categories (taxonomy) are translated to both languages, so I just assign the appropriate category to each node. Sometimes I don't translate the node and leave it to appear in English on the Portuguese version of the site.

Michael_Moor’s picture

I think it's the best option (in SEO and user terms) and i hope it will be implemented in i18n soon.

Download For All

Joe Murray’s picture

I'm currently leading an i18n content project for CiviCRM. I'll describe the use case we're primarily supporting, then mention a few others.

What I call mirrored i18n sites allow users to switch languages on any page and get the same content in a different language. A large number of organizations need this. Some major desired functionality and features:
- ability to see posting in original language when translating to new one
- ability to create first version of content in any language (i.e. there is no default language from user's perspective)
- support for multi-lingual url's (in domain name as well as other elements in url, particularly url aliases that are used to provide a friendlier face to users, and ideally to have a locale in the url)
- support for language in the text name of that language, rather than flags (this is crucial for Canada, and likely a variety of other countries)
- workflow to support identifying content which has not been translated and allow easy translation by non-technical users, with translations into different languages probably done by different users (this should handle both new content and content which is editted into a new version)
- workflow to support identifying content which has been translated into all languages for that version and which is thus ready for publishing
- support for locales rather than languages, since it is sometimes necessary to have different versions of the same language ('fix a flat' means rent an apartment in Britain, and repair a car's tire - not an auto's tyre - in Canada)

Other use cases that my clients would benefit from include:
- allowing untranslated nodes to be published, and either not showing that the content is available if it has not been translated, or allowing users to see it in original language of posting (note - this is not a default language, but just original language of posting)
- enabling community translation of content, retaining an indication of which locale was the original content
- allowing user to specify language of content to search, or to search all content
- allowing sites to have mirrored as well as unmirrored portions - e.g. forums are not mirrored, but all pages are
- support in CCK for specifying whether an image is localized or not - it is often known that an image will contain text and need to be localized
- support in CCK for doing a single update to unlocalized fields (eg dates) that will appear in all localized versions of content
- support in CCK for indicating a text field is not localizable (eg, contains the name of a publication or person), and similarly that a url is not localizable


Joe Murray


marafa’s picture

it may seem obvious
but sometimes the obvious is overlooked so i just want to say that we dont want to forget the subject/story title also needs to be internationalised.
currently when i post a story/event/etc. in arabic the title is ltr where as the arabic language is rtl.

so i get a title/subject starting from the left and the story itself is from the right.


__________ اجدد اخبار ممثلين

Roberto Gerola’s picture

Here there is a solution for Rails framework.
I think it could be of some inspiration to write a similar system
in Drupal.


mandclu’s picture

A few months back, I developed a site that needed to use five languages, and that's what brought me to Drupal. I think there are a lot of people in this community that see Drupal's multilingual features as a main selling feature, so it's entirely appropriate that it be added to core.

I'd also like to add some mad props to Jose Reyero for all his work, and his continued responsiveness.

It's been my observation that there are some people who want to essentially duplicate a single structure and set of content into multiple languages, and there are other who want to have separate sets of content that may or may not correspond between languages. Someone in this thread pointed out that some may want mirrored content for only part of the site, which could make life even more complicated.

I was creating a corporate site, so I needed mirroring, and i18n did the job quite nicely. I recall that I had to manually set environment variables in the site config file to get the languages to appear in the native translations, and I agree it would be better if this behaviour was the default, with requiring someone to tinker with the config file. I recall that I also had to do some manual hacks to the core to get the menus working the way I expected, which was obviously unfortunate. It could be that this issue has been successfully addressed since I was working on that particular site, but I am sharing my experiences, for the record.

From an end user usability standpoint, I would like the translations interface to be able to handle menu and url alias translations as well. The current method, particularly for the menus, of having to navigate to the manage translations interface, search for the string, click on the appropriate language, and finally put in the translation, seems awfully clumsy to the end user. I would much prefer if each translation had corresponding boxes for menu and url alias, but could show the original language version, and optionally allow the user to specify a substitute. Also, it would be nice if you could have separate publish states for each translation, as I recall only the publish state of the original is respected. In other words, if you were working on a Chinese version of a page, but it was still pending final approval, you could have it in the system and if someone tried to access that page on the Chinese version, the site would treat it as though that translation didn't exist (e.g. show the default language version instead).

I ultimately didn't require it for my site, but it would also be a bonus if the translations permissions could be more granular, allowing you to restrict that permission to one or more specific languages. For example, you may want to allow a translator whose expertise is French to create and edit translations in French, but not Spanish.

One other comment, to me it seems beneficial to add a language column to the main nodes tables, as this would allow for things like language-specific searching without the performance penalty of a JOIN.

trantt’s picture

Except for a few minor problems (see below), i18n has been working great for us. Here is the list of problems that I ran into:

1. it doesn't work with taxonomy_block module: i18n won't work with any module that contains the _ . I was already submited the patch sometime back but it was never made it to the core module

2. I'm not sure what I did wrong but the Language Switcher block failed to work on mine site. I've to use Translation block instead

3. i18n doesn't work on the primary and secondary menu (this is a important feature and hopefully it will be implemented on the next release)

Other than that, it is a great module

davidjava’s picture

Hello, first of all, I would like to thank both Jose A. Reyero (author of the Internationalization module) and Roberto Gerola (author of the Localizer module) for their great efforts in the localization issue. While I think that the second is much more better in terms of functionality, it evolved from the first and therefore show many similarities. Also it seems like most people are still installing the first (I wonder why?).

I want to add a new use case to the ones that have been said before:

- A user needs one only locale for the user interface. When the user is anonymous, it can be automaticaly selected either from his/her browser detection or from his/her IP origin (by using the IP_to_country facilities provided by some contributed modules). Once the user is registered, it is probably better to consider the locale which he/she chose during the registration process.

- But, that is what is new, the user wants to access the site content written in any of the languages that he/she can understand. Maybe I chose English for the user interface, but as far as I can understand Spanish as well, I would enjoy to read any post written in English or Spanish.

In my opinion, the user profile should be extended to include the multilingual concept. That way, it would be a list of locales rather than an only locale.

Regards to the Drupal community!

Bockereyer’s picture


I'm confused and maybe this is not the right place to ask.

I have to set up a multilingual site with CCK-nodes (images, text fields, url, etc...). Menu's, UI and content have to be translated. What do I need in Drupal 5.0? I started developing this web site in 4.7 but due to translation problems with the categories/menu's and difficult work-a-rounds I stalled the development.

It seams to me that other CM Systems have tackled the problem. My message to the core developers "Make this i18n issue your number one priority!". Drupal cannot grow into the future without decent flexible multi language support. I would hate seeing this great OS project disappear in the dark corners of the internet.

All that said, keep up the good work!

suit4’s picture

I recently finished a page built with Drupal 4.7, which needed to be fully translatable in at least English and German.
The page is called 'Mission Sustainability'.
During the implementation process I came across several problems regarding the localization and translation modules, which I 'solved' by workarounds and some 'adjustments' in the core code - yes, I know, that is not very wise.

The page is a German sustainability contest, where people can present their (hopefully) sustainable projects. In the last phase, there will be a voting and a jury will pick the best projects.

At first, I found it very problematic to pick the right modules for our needs. Most modules don't have information about their compatibility to i18n. That would be very helpful.

Anyway, we needed to create a system with instant login and some kind of upload form to get the projects onto the site.
With the project submission form, everyone has to accept the contest rules.
For instant login and project submission, we used Logintoboggan, a customized profile page (via Node Profile) and a new content type created with CCK.

The form description and hints needed to be translated, so we where in need of translating not just the Drupal interface, but all customized interfaces on the site. Therefor, we had to customize the t()-Function (There was an article somewhere here, not to do this,... ooops). This way, we are able to manage the translations with *.po-files.

At the end, we have all those projects as nodes. Everyone is invited to discuss the project and post some comments.
All German nodes are going to be translated to English, because the main contest language is English. The other way round, English projects do not get a German translation.

Here we came over some side effects which we did not expect. If I have, let's say, 10 projects five in German and five in English plus five translations for the German projects, that is all together 15 nodes. Simply counting the number projects gives the wrong number, if counting just nodes. For every node, we had to check the language and the presence of a translation to get pairs of nodes, which we can count.

Every project gets project number, but if the translation of a project is a new node, both original and translation do not have the same node number. Again, we had to figure out, which nodes belong together to give them some nice numbers.

One of the biggest problems was the comments issue: if we have a project with its translation, the comments posted to the translation node will not be visible underneath the original project text. First, we used CCK and Views in 'Full Node' mode to show the project details, but 'Full Node' only picks the comments for the current node. At last, we ended up with a modified 'List View', picking the comments from the database by hand.

We have some different ways to list the projects, one can choose between projects by country, by author or by tag. We missed language filters in the Views module and a nice and easy way to translated the tags very much. Filtering for languages in the Views module would have been very helpful together with some kind of rule what to show, if a node has no translation in the current language (especially in list views).

In case of this site, the idea of simply duplicating a node to translate it, is not the best way. It surely is one way, but I think, a translation and a new node is not the same. In case of Mission Sustainability, it would have been better, if the translations where related/linked to the original nodes, but not nodes them selfs.

By now, Mission Sustainability is up and running and we managed to modify everything to fit our needs, although we didn't expect those modifications.

So big thanks for i18n anyway!

drupalisme’s picture

After installed i18n.module I often receive "page not found" error but when I press F5 then the page displayed. Here is my site: , and this happen to all of my Drupal sites using i18n, there are 3 websites using i18n.module. While I remove the i18n,module then everything work fine!

Also, i18n.module ( or locale.module ? ) doesn't translate the TITLE of user define blocks.

I like Google translation feature, Google can automatic translate from English to other language, and vice versa. I really need this feature because currently I must paste to Translation Tools then copy the result back to Drupal site.

I like i18n displayed icon for each content that already has translation, i.e:
if I have a content in English then already translated to Indonesian and Germany then I like 2 flag icons displayed near the title, then users just click the German icon to see this content in German rather than click the Language Swictcher and find again the article!

WJ’s picture

I'm looking for multilingual / translation functions covering two levels, especially for database level.

1. UI level:
2. database level:
a module that is able to cut in the data rendering process from database (of a language) before presentation of the data, so after the module users are able to see/read the data in target language.

Such direct translations are suitable for certain content formats that don't require much grammar in the content presentation. For example, photo introduction. It should require some assistant target language database for such translation works, but such databases take much smaller size than making a complete database translation.

From gut feeling, I guess it should be difficult to make database/content translation at server end due to adding up some translation overhead per http request to the web server. The possibility/answer depends on how much the overhead is actually added.

*** Besides the method of translating directly from database, if there are other alternatives that can still work out content/database translation, please introduce.

*** I am appreciated if anyone can introduce such Drupal modules that can handle above two requirements.


WJ’s picture

What is multi-site installation? Is it a Drupal module?

The web sites done by Florian look very interesting and exciting. He demonstrates his websites both in English and Romanian, which are very convincing.

Due to the difference of profession, it's hard for me to understand what exactly had been done to work out web page content in both languages. The translation work looks to be done at page-to-page level not word-to-word level, which means he keeps two equal size databases for two languages. Am I correct or not?

Can anyone give some guides and help explain in more details?

david007’s picture

The issue at hand is more along the lines of "how do we want to represent different translations of content in the database? Should they each be nodes? Should they be revisions of the same node?

Insurance Center

transformative’s picture

We encountered a number of challenges when we tried to set up our client's Drupal site to work in multiple languages. In particular, we had to make some changes to the category module, to make it work as desired with the internationalization (i18n) module. We also encountered some difficulties while setting the new site up in a multi site environment. Modifying our site's existing URLs to work with the pathfilter module was an additional challenge. Since the site needed to work in Arabic (a right-to-left language), we also needed to make the site bidirectional.

The following link describes some of the process we followed, as well as a number of the challenges we faced, in moving to a multi-lingual site:

melian’s picture


I have to implement a multilingual website and the question of what module to use comes up.
I was thinking about developping a CCK fields internationalization feature based on fields duplication for each language.
The "default" fields would be the master fields and the cloned ones would be a kind of slaves. The master fields would be referenced by all the other modules but at the rendering time, the "X" language slave field would be showed. I'll test it and post my results. Any ideas are welcome.

Ciprian M.
Webdesign & Multimedia

StevenK’s picture

I have used i18n in a website for Robovision and Localizer in a website for Drop.
The Robovision site is for a small company that also works with english and german customers. I partially translated the content to english, and the company would translate the rest of them. The system works fine, and the language switching is nicely placed in the header. But the menus are cumbersome to translate, and the i18n module is difficult for training end users.
The Drop site, on the other hand, is for an export oriented agricultural equipment producer. The site is in 7 languages, and the training in how to translate content (blog, events and nodes) took about half an hour. (The most difficult part was not to forget to specify at first in what language the submitted content is).

The Localizer module is a clear winner on usability. Menus are translated quite straightforward (through the menu entry) and content is translated intuitively (through an extra tab when the node is viewed). The translation method is the same for both menu and content, so it is really easy to learn. There is no need for making blocks for international menus such as in i18n. The only drawback is that there is no central translation management where someone could visit and view content that needs to be translated. Also, the language switching is through a block, whereas the i18n has it, much more sensible, in the header.

The main problem with both is that categories are not translatable. Of course I could always insert a translated term as synonym, but it could not reference only nodes in its language.
The Drupal community is getting wider all the time. There is need for productization in Drupal, and in this case it I see it as usability first (easy translation of nodes, menus and categories, header language switching) and features (translation workflow management) later.