Dear lazyweb,
I'm currently setting up a drupal-based site. While it's working pretty well and has allowed me to get most things done that I needed doing, there's one remaining issue that would need resolving. I tried asking for suggestions on the drupal support mailniglist and on the #drupal-support channel on freenode, but I haven't received a solution thus far. Hopefully someone reading one of the planets I'm on knows the answer.
The site would need to be multilingual. That is to say, not just the interface, but also all static content and some of the nonstatic content would need to be translated in two (at first) languages (perhaps more will follow in the future).
Using the i18n drupal module, I have been able to create alternate-language versions of some nodes, and enable a language chooser, allowing a visitor to choose a different content language for the site and seeing the site translated. However, there is one issue that needs to be resolved: the menu.
The i18n.module does not create an alternate version of a translated node; rather, it creates a new node. This node then is linked to the original node by way of some extra table that the i18n.module installs. As such, both versions of the same content will have a different node number. To give a concrete example, the Dutch version of the "about" page on the site I'm creating is node/2, whereas the English version is node/10. Since you might want to review the English version of a node even if you request the site in Dutch, you do not unexpectedly get the Dutch version anyway if you request node/10.
Since the node number is part of the URL of the node, this makes it impossible to create a link to "the about node, in whatever language is appropriate".
The i18n module also comes with a "i18nmenu" module, which allows one to translate a menu item's description using gettext. This works, but it has one fatal flaw: it does not allow to change the target of the link. As a result, and given the above, it's impossible to create a menu item for "the about node in the current language, whatever that means".
In an effort trying to work around that issue, I've come up with a number of things. Unfortunately, none of them seem to work to satisfaction.
- Create a URL alias, including the language prefix that gets added by the i18n module, and then link to the version without that language prefix from the menu: suggested by the i18n module's documentation, this does work, but has the problem that the menu system then doesn't detect that you're viewing the content which the menu has linked to. As a result, child menu entries don't get expanded, which I would need (my menu would get too convoluted if everything would be visible from the onset).
- Create a
custom_url_rewrite
function to change the target of the URL alias depending on the value of the$locale
variable (which contains the current interface language). Turns out that this breaks the language prefix (i18n.module installs its owncustom_url_rewrite
function). Efforts to change my function or the i18n version of that function to change in such a way that both translations are done have failed; they seem to confuse drupal in some way. This is possibly due to the fact that the custom_url_rewrite function in i18n.module only performs one end of the translation, while my needs require both ends; I don't know enough about drupal to figure out how i18n's other side is implemented. - Create something which will actually search for articles, in such a way that it is guaranteed that it will only return one article (e.g., by using a special taxonomy term or some such), and link to that search from the menu. This works, but only returns the teaser version of the page, requiring users to click a "read more"-type of link, which is not what you'd expect from a menu system. Ensuring that nodes to which we'll link from the menu are created so that they don't have a teaser isn't desirable, either.
At this point, I'm effectively out of ideas. If anyone has a solution (or can tell me why it isn't possible), I'll gladly hear it, either as a comment on my blog or by mail on w@uter.be.
Drupal 6 will (hopefully) ship with many i18n improvements. We're moving a lot of the i18n stuff from the contributed modules repository to core -- and we're fixing things up as we do exactly that.
Of course, that doesn't help you fix your current problems so I've asked Gabor/Goba, a resident Drupal i18n expert, and the driving force behind the i18n additions for Drupal 6 to comment on your post.
Hope that helps, Wouter.
Dries has been fast answering this one, but I was going to point at the same thing, giving less details. Following Drupal6 news from the drupal.org community I see Drupal 6 is what I have been waiting for, and will have i18n "done right".
I guess your site will be in production and you can't rely on pre-beta stage code, so it's really bad timing
i18n is a real pain. The only thing I'd do is create 2 menus. One for each language. Sounds stupid ? I know.
Another idea is to write a module that'd detect the current locale, load the correct node and overwrite $node->body; ugly ? I know.
Whether different translations should share a single node ID, or whether each translation should have its own node ID is a tricky problem. There is no right or wrong as each of these techniques has its advantages and drawbacks.
For example, if each translation has its own node ID, each of them will be indexed by Google. Also, it allows you to configure each node differently, and to assign different workflow scenarios to different languages (i.e. you might want to have your French translation proof-read, but your English translations not).
I haven't much experience with the i18n module but I've heard good stories about it, but also bad stories about it. It's one of the reasons why we're moving it to core so we can make it work better.
If I get it correctly you'd like to add a link in pages/menu's to a page in the 'current language'. Instead of a link to a page 'of a specific language'.
This is possible with i18n. Have a look at http://happyhomekenya.org/. The menu items 'happyhome', 'howtohelp' are redirecting to the right page in the language the user is browsing.
I implemented this some time ago from a post on the drupal site.
I did some reverse-engineering and here is what I see from the config: * Go to the page you want and create an alias for that page. (en/howtohelp, nl/howtohelp) * In admin > menu, create an item with as 'path' the alias without the language flag (howtohelp) * In the i18n module settings the 'content selection mode' is set to ' Only current language and no language'. This is working on drupal 4.x. Feel free to ping me if you need help to configure this.
Hi,
Maybe I'm missing something obvious (which is quite possible, I haven't actually used the i18n module myself), but I was thinking maybe you could create two menus and use block visibility to display the correct one?
Cheers,
Dave.
I don't endorse this, but I got into menu.inc around 1080 and did something like this:
if (function_exists('i18n_get_lang') ) { $lang = i18n_get_lang(); $i18n_alias = "$lang/{$item->path}"; //now we look for en/myalias or es/myalias... if ($item->i18n_path = drupal_get_normal_path($i18n_alias) ) { //We found an alias! Return that as the path $item->path = $item->i18n_path; } else { //oh well, return the normal path. Obviously, this is broken for pages not using an alias system. $item->path = $item->real_path; }
Yeah, it's not ideal, but works if you get all static links set up and IMHO is better than having 4 menus (the current recommended solution pre-D6).