Now we have language for nodes -Just committed to Drupal core!!! Also, on a different thread we are exploring possibilities for a Drupal/CiviCRM multilingual soluction. So lots of things are going on, pieces are fitting together, but also it's maybe a good time to think a bit more about the 'overall strategy' of this Drupal multilingual enhancement!
Right now, we are busy preparing some other patch that will allow translating virtually everything. That's very good. But that possibility has also the danger of using a generic mechanism like this to efectively translate everything forgetting about other better options for specific items. So in this post I want to make some case for 'per language menu items' and 'per language taxonomy terms'.
The difference between (A) 'per language items/terms' and (B) 'translatable items/terms' and is basically that in the first case we'd have different items for each language, while in the second one we'd have the very same menu items that would show up translated in one language or another.
For some sites it may make sense to have all the content translated to all languages and all the translations tightly tied so the content is not published until all the translations are finished. These are mainly these official EU sites, or similar, where they have a huge team of translators, and they need the content in all languages at the same time. But for most of 'real life' sites, while you want to have content in different languages, you cannot expect, nor have the resources to have all content translated to all languages. This is specially true for community sites or for sites that are built with user submitted content in general. -Hmm, does it sound like the kind of sites Drupal is so often used for.. ?
So, following with this second case, while some of the content may be translated and available in all languages, the thing is more similar to multiple sites with single log on, on which each language version has its own life. Thus, for some languages you'll have some different menu items linking to content that may or may not have translation. If the content has a translation, nice, you can link to that translation -that will lead the user to a different 'translated' menu item. But if it doesn't, it's also nice because menu items that dont have associated content in the current language won't show up.
A similar thing happens with taxonomy terms. Think of a site with lots of multilingual content, a few thousand users and free tagging. Users will be tagging content for different languages with language-specific tags. Whether you can work out translation relationships between these tags later or not is a different question. But as users are tagging the content we'll want to be collecting the tags for these different languages without them mixing and showing up for the wrong language.
First questions, I'll ask them to myself
- OK, but where do you want to get?
Simple -and simple to implement too-. I'd like to have a language field for menu items and taxonomy terms too, like the one we have for nodes now. Whether you use it or not for a given web site is a different question. It can be hidden or not, we can add some setting for it. But if you have it you can decide wether to use it or not and these details with core objects, like menu items and taxonomy terms, are usually more difficult to fix if we need to provide it with a contrib module.
Not that I don't want 'translatable menu items/terms'. But I also want per language menu items and terms.
- So you want it all?
Yes!
- Then, what are you waiting for?
Nothing, really, I'm writing the patch, but I just want some support for this features when I finally post it :-)
Thanks for reading!