Multilingual Drupal: Some Dos And Don'ts
Submitted by greg.harvey on Sat, 30/01/2010 - 14:06
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:
- 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.
- 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.
- 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.
- Don't forget your default language - it may not be English even if you normally work in English.
- Do enter everything in the default language first, then translate later. It's just safer that way.
- 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.
- 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.
- 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.
- 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.
Linked from groups.drupal.org
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!!!
My point of view
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 :-)
"There are four options for
"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.
You comments
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.
taxonomy translation
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?
Um, I think
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.
It's definitely an
It's definitely an interesting idea. I wonder what effect that solution has when it comes to performance...
I don't quite understand
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 ?
You don't
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. =)
Really useful post, thanks.
Really useful post, thanks. Should be carved to a stone.
Great list.
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)
huh?
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!
features vs problems
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..
...
"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
CAPTCHA
Yeh, sorry about that. I really need to try something else. =/
About item 3
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!
Sure
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!
Thanks a lot
#3 will save my life ! (and my next multilingual-drupal-website).
Can you write the reason?For
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.Yup
See above. ^^
Post new comment