I wrote about some Drupal multilingual SEO issues a while ago and while multilingual support has greatly improved in Drupal 6, there are still some caveats. For more information check out Gábor Hojtsy’s great slideshare on the current state of Multilingual Drupal.
Path prefix issues
For example, the language prefix in the url does not always work the way you expect. For example, let’s say you have a site with two languages, Dutch and English (default Dutch), and would like a structure like this:
www.site.com/en/example-node
www.site.com/nl/voorbeeld-node
“example-node” is an English translation of the Dutch node “voorbeeld-node”.
You also want to use the i18n translation block to allow users to switch languages. Now let’s say a visitor is on /en/example-node and uses the translation link provided by this block to view the Dutch version. In my case, with the setting ‘path prefix only’ this resulted in a link to www.site.com/voorbeeld-node. Without the /nl prefix.
This is obviously an undesired situation which could result in loads of duplicate content (bad for SEO). I believe this issue is also addressed here, so hopefully it will be fixed in Drupal 7. Until then, you should use the option ‘path prefix with language fallback’.
Translatibility of Multilingual Views
Another problem is when you start using Views. Nodes are perfectly translatable (like in above example), but look at this very common example with 2 views:
www.site.com/en/news
www.site.com/nl/nieuws
Both are page views which would show a teaser list of news nodes in their own language. This is easily done in Views 2, but you will need a separate view for each language.
The problem is these 2 views don’t know about each other. /news does not know it’s an English version of /nieuws. If you switch from English to Dutch at /en/news, the link leads to /nl/news and you would still be at the English version.
As far as I know, there is no way to tell Drupal about this translation, and the only way would be to insert views into nodes, as described here. You could use the insert_view module or the CCK field viewfield to insert Views into nodes.
These workarounds/solutions get the job done, but I don’t think they are very elegant solutions. It would be much cleaner if you could provide a translation for each view. Also, this is only an issue if you use a language switcher on each page. It get’s much simpler if you redirect the user to the frontpage if they switch languages.
Translatable menu items
Another pitfall is this: i18n enables you to create language-dependable menu items. So you can have a menu-item for a view which only shows up in a certain language. However the menu will only be rendered the way you expect when you display it through a block. (See also this issue)
If you embed the menu directly in page.tpl.php using $primary_links, these items will show up in all languages…
Overriding the language switcher block
By the way, if you are looking for a custom language switcher, look for the code in the core locale.module and write your own hook_block. This is useful if you want to filter out the current language for example.
8 comments »
Updates via RSS
Updates via Twitter 
Updates via Email
This week, I re-installed my old computer at home which also means installing all programs. Among those is Firefox, and all the add-ons I use with Firefox. Here are mine:
