Multilingual Drupal: Some Dos And Don'ts

So we've done all French sites before. And we've done all English sites before. But a recent project was our first real forray in to multilingual sites and it's an e-commerce/Ubercart job! Talk about gluttons for punishment!

There are bags of tutorials, so I'll keep this short but sweet. A list of dos and don'ts from our painful, recent experience:

  1. Don't change the default language after initial set-up. Set your default language right at the start and don't mess with it. Ever.
  2. Do give each language its own weight. I'm not sure why, but this seems to fix certain situations where Drupal seems to get confused about which language it should select for an element of the UI.
  3. Do back up your database before installing someone else's PO files. Sometimes they're a pile of crap and there's no easy way (I know of) to back out.
  4. Don't add menu items using the Views module (unless they're tabs). Use the core Menu module or you'll confuse yourself to death.
  5. Don't forget your default language - it may not be English even if you normally work in English.
  6. Do enter everything in the default language first, then translate later. It's just safer that way.
  7. Don't set Taxonomy vocabularies to a language. For some reason it seems to lock them like that forever! Leave them language agnostic and translate them. Then the language switcher will do its thing.
  8. Don't forget, multilingual variables are set, as usual, in the admin UI. All you need to do is set the URL/sub-domain (depending on how you configured language switching) so you are in that language's view of the UI, then enter the variable value for that language. This is the case even if you set the language to be one specific one always in admin.
  9. Don't translate blocks. You'll confuse your client to death when you try to explain to them how to create and edit translations. Just create one block per language, as needed.
  10. Don't install BlockTheme. It's a great module, but it doesn't work at all with i18n (yet - I've been chatting to Jacob Singh about CVS access to fix that, when I have time).

I may add to this in time.

32 comments

by dereine on Sat, 30/01/2010 - 17:10

Can you write the reason?

For example: Don't add menu items using the Views module (unless they're tabs). Use the core Menu module or you'll confuse yourself to death.

by greg.harvey on Sat, 30/01/2010 - 19:00

See above. ^^

by opi on Sat, 30/01/2010 - 17:38

#3 will save my life ! (and my next multilingual-drupal-website).

by dagmar on Sat, 30/01/2010 - 17:58

Hi Greg:

I would like to know why did you post:

Don't add menu items using the Views module (unless they're tabs). Use the core Menu module or you'll confuse yourself to death.

Since Views can be disabled it would be nice that they items will disabled automatically too.

So maybe you can explain a bit better the reason of item 3. Also there is an issue to provide better internationalization support for Views 3. You can post a comment there too.

Thanks!

by greg.harvey on Sat, 30/01/2010 - 18:59

As far as we could tell (it confused the hell out of one of my developers anyway) you'll end up with the menu item twice. Once as a string in Views to be translated and once as a string in Menus. It gets confusing to track which ones you translated, which ones you need to translate, etc. If you just build your menus with Menu then you only have one set of translations.

This is the behaviour we were observing anyway. If it's not supposed to do that, let me know and I'll re-test!

by Robert Douglass on Sat, 30/01/2010 - 18:06

This is still a really underprivileged aspect of Drupal. Gabor and crew did such a great job pushing forward in D6 but it kind of fell off the map in D7.

(Took 4 tries to deciper the CAPTCHA I so hate CAPTCHAs)

by greg.harvey on Sat, 30/01/2010 - 19:01

Yeh, sorry about that. I really need to try something else. =/

by sun on Sun, 31/01/2010 - 21:59

What strange fork of Drupal 7 are you talking about?

The Drupal 7 I know has many totally awesome improvements.

- Translatable fields
- Localized date formats
- A preparation for "dynamic database translation"
- Entirely revamped language negotiation
- Message context for localized t() strings
- Revamped time zone handling, including daylight saving time adjustments
- many smaller improvements and clean-ups, such as handling of user language

...and many many more tweaks that will allow the #drupal-i18n crew to extend and improve functionality in Drupal core from contrib during the release cycle.

Truth is, CHANGELOG.txt is incomplete. File a patch!

by Pasqualle on Mon, 01/02/2010 - 07:36

alright new features, but the problems and confusion remains. I do not see it easier to create a multilingual site in D7 or create a module with multilingual support.

problems like:
dynamic string translation
content translation workflow
permissions per language

Explaining the multilingual options, wokflow and problems in D7 will take much more longer then explaining it for D6..

by sun on Mon, 01/02/2010 - 13:15

"permissions per language" doesn't really belong to internationalization features. Look into Context/Spaces/Section modules for that.

The other points are exactly what we - the #drupal-i18n crew - will be working on in contrib.

Give us some time to recover from D7 freeze, but be sure to bookmark http://drupal.org/project/translation and http://drupal.org/project/translatable

by tekket on Sat, 30/01/2010 - 18:21

Really useful post, thanks. Should be carved to a stone.

by Adrian on Sun, 31/01/2010 - 03:32

I don't quite understand point 6 "Don't set Taxonomy vocabularies to a language. For some reason it seems to lock them like that forever! Leave them language agnostic and translate them. Then the language switcher will do its thing."

So how to set taxonomY vocabularies for different languages ?

by greg.harvey on Mon, 01/02/2010 - 00:12

You create a single vocabulary and then translate it via the translations interface at admin/build/translate. This way you don't end up having to do stuff like create a Views display for each language. That's the specific case that prompts this advice -> you don't want to end up in a situation where you have two terms in two vocabularies that you want to OR. This is impossible with the current Views filter set, so you'll be stuck. You'll need to create a View for each language. Whereas if you had one vocabulary translated you wouldn't be stuck. Views would just load the translation according to the current user's language.

Hope that clarifies. =)

by Wim Mostrey on Sun, 31/01/2010 - 11:01

I'm curious about this one:

# Don't set Taxonomy vocabularies to a language. For some reason it seems to lock them like that forever! Leave them language agnostic and translate them. Then the language switcher will do its thing.

So your advice is not to use the 'taxonomy translation' module but to translate the terms using the regular interfaces?

by greg.harvey on Mon, 01/02/2010 - 00:08

We found it worked better with Views and language switcher if you don't create a vocabulary per language, but instead create a vocabulary set to "All languages" and translate it at admin/build/translate ... does that make sense?

It's just what we found worked better when you come to Views integration mainly.

by Wim Mostrey on Mon, 01/02/2010 - 07:49

It's definitely an interesting idea. I wonder what effect that solution has when it comes to performance...

by Zohar Stolar on Mon, 01/02/2010 - 07:33

Thanks for that article. I hope it will help others to jump in and build more multilingual sites with Drupal. Few remarks:

> Don't change the default language after initial set-up.

In theory, I don't see the damage. However in practice, this is probably true, as a default language of a site should not change. Plan your site in advance, and you'll not run into problems like this.

> Do enter everything in the default language first, then translate later.

I totally don't agree with this one. Once the i18n system is in place, it works fine, and in all senses. You shouldn't fear voodoo.

> Don't set Taxonomy vocabularies to a language.

Again - I think this is wrong. Taxonomy has several ways of translating itself, and these options are all useful in their case. There are four options for taxonomy translation. You're talking about the "Localized Terms" option, which is a very useful one. But you might want to use the "Per language terms" option, in case you have different sets of terms for each language (This is true for many cases where different languages are used by people of different cultures, thus different perception of things)

> Don't forget, multilingual variables are set, as usual, in the admin UI.

This is indeed confusing. Look for the notice under the input field that signifies a localised variable.

> Don't translate blocks.

Drupal 7 has some great improvement on that aspect. Do as Greg says for now :)

... and you didn't even have to confront bi-directional sites! That's where the real fun starts :-)

by greg.harvey on Mon, 01/02/2010 - 11:52

Thanks for adding your thoughts. To comment on them.

Changing default language, for us, completely broke the interface translation to French. Don't know why, don't even know if we could replicate it, but certainly won't do it again!

We had issues when stuff was entered in the NON-default language. Somehow the translations got confused about which language they were in, but only sometimes. So again, in theory it works fine but beware the dragons! Safety first, default language first.

by Anonymous on Thu, 20/05/2010 - 09:59

Yeah, that's a weird behaviour i am facing now in a site... do you know how to solve it? I mean, without breaking the whole db :)

by greg.harvey on Thu, 20/05/2010 - 12:33

Never fixed it. =(

by greg.harvey on Thu, 20/05/2010 - 13:06

Actually, I just managed to fix it. I don't really understand why, but giving the languages different weights seemed to sort it out. Give it a try. Worked for me. =)

by joachim.noreiko on Fri, 12/02/2010 - 14:18

"There are four options for taxonomy translation"

Really? Is there a list of these somewhere explaining them?

As maintainer of Image module, I've had a lot of support requests/bug reports about problems with translating the image gallery names, which are just taxonomy terms. And I have no idea what to say or whether my module needs fixing, because I've no idea how it works.

by Philipp Schaffner on Tue, 02/02/2010 - 14:21

This subject fits perfectly into our coming DUG-CH (Drupal User Group Switzerland) meeting. I've just made a link from http://groups.drupal.org/node/45908 to this essential posting here! Thank you very much for discussing this huge and quite complex issue!!!

by alwlid on Sat, 15/05/2010 - 09:37

alright new features, but the problems and confusion remains. I do not see it easier to create a multilingual site in D7 or create a module with multilingual support.

problems like:
dynamic string translation
content translation workflow
permissions per language

Explaining the multilingual options, wokflow and problems in D7 will take much more longer then explaining it for D6..

Hi Greg, how's tricks? Good article, thanks! :)

As you know we're running our website in English and Welsh, maintaining both concurrently. The reason we don't do straight automated translations is because of policy constraints, so it's all written manually for legal reasons. I know Drupal can run multiple sites, can two or more be run from the same administration pages though? Is that even the best way?

We'd be looking to run x2 of everything including nodes, menu's, tax and vocabs etc. Ideally, rather than double up on masses of content and menu's etc in our admin pages, it'd be good to switch between the languages and keep everything neatly in separate places, but to the end user, it'll be one site - they just choose which language they need.

Our only other problem is converting Drupal to flat HTML for our servers!

Many thanks
Jonathan

by greg.harvey on Wed, 30/06/2010 - 17:37

Not bad thanks, how are you? All good I trust! =)

I think one admin section for the two sites, while possible, would probably be too confusing. Better to separate them entirely, if that's the decision. You can do sharing of certain tables. If I were you I'd do single sign-on between the two sites just by sharing the user data, as detailed here:
http://drupal.org/node/291373

And leave the content separate. You could use sub-domains to host English and Welsh versions, and with the single sign-on switching between them, as normal users or admin, would be seamless.

As for flat HTML, Boost, my friend:
http://drupal.org/project/boost

by jonthomas83 on Mon, 12/07/2010 - 10:29

Cheers fella, appreciate your time and advice!

we're looking into Boost at the moment, Mike (the Boost guy!) was kind enough to lend us some advice but it all seems a little bloated as a process for us, so I'm desperately trying to convince them to put Drupal on live.

Anyway, that's off topic, sorry! Will take your advice about the separation of the two sites, seems the best way forward to me! :)

Cheers,
Jonathan

by arelem on Wed, 25/08/2010 - 12:41

We are building an English site works quite well.
We need to build a Russian site into which we cut and paste approved Russian translations of the English text.
We do not need not wish Drupal to do the translation.
The text must be in Cyrillic Times New Roman font.

I will need the menus and header to remain in English and just produce the page content and a menu in Russian

I've read the above messages but it's a bit beyond me at the moment.
I have set up pages for the Russian text but it defaults to question marks which I read are because the Cyrilic language is not on the server.

Should I start a new site using the same theme but with Russian as the Default, this is a problem because I do not speak/read Russian but rely on translation experts.
should I set up new content types for on the English site the Russian text.

Is there a step by step tutorial on how to do the above.
Thanks in advance

by swan on Sat, 29/01/2011 - 03:33

Hi Greg,

I am setting up a chinese and english site. English is default. I have followed the best guidance I can get. My only problem now is 404 for all admin links when switching to the second language, and the language switcher block links behaves strangely.

Apart from i18n, I have also reinstalled with only using drupal builtin, including without pathauto. I have also seach d.o to no luck. I found that I am not alone though.

Admin 404 problem:
Say, I have a contact page (node/1 ). When adding translation (node/2), the link goes to /zh-hans/node/add.... which is 404. So Ihave to remove the prefix (/zh-hans), then I can create the translation. Only to find out that when I go to zh-hans/node/2, it is just 404. Unless I go directly to node/2. But then no prefix.

Language switcher block link problem:
When switching to chinese, the home link prefixed with /zh-hans which is fine, but I just want a single homepage display for both. Using views frontpage with node tranlation filter all except specific languages led me to 404. Ignore this, I may have to create another view for chinese.

The critical problem with language switcher block is, when I am at /zh-hans, the link at language switcher calls for "/zh-hans/zh-hans" for chinese, and /zh-hans for the english link. Something must be wrong.

Can you shed me some light if the above two behaviors are just me?

Subscribing.
Thanks

by ThouArtJay on Tue, 23/08/2011 - 15:30

Swan, did you ever solve your problem? I am having the same issue, and I have been unable to solve it.

Pages

Post new comment

© 2010 Greg Harvey. Drupal theme by Kiwi Themes.