I'm about to embark on a journey to build a multilingual Drupal site, where I will most likely have to use Views, Panels and Taxonomy pretty heaily. I am a bit worried about the new-node-for-every-language approach, especially using Panels.
So far I've gotten it to work similarly to what I want by not having multilingual support for the Panels content-type, and fetching content that is from Current language and language neutral . This seem to work as expected, but I'm seeing some problems with it. There might be the occasion that I will have to have a language specific Panel (not published in English for example). If I need to have all my Panels multilingual, there seems to be alot of work to place the nodes for every column in every page in every language. I'm thinking I could possibly solve this by fetching the content with some kind of view with arguments, but this will most likely also lead to alot of work.
Is there some proper way of doing what I'm attempting to describe, or do I have alot of seemingly unnecessary work to expect?
I assume you have i18n module (http://drupal.org/project/i18n) and Views module installed. Then you can create a view for each language - one can choose language in "Filter" section of the view definition.
Once you have views, then you can link them to menus or blocks. The problem is you must have a separate version of block or menu for every language, with a proper view associated - Drupal is choosing proper language version itself according to the configuration (typically content type set in a browser). I haven't found any easier way of doing that.
Fortunately preparing multilingual content is not that hard thanks to the "transalte" functionality for nodes after enabling i18n module, so new node for every page is something one can live with.
BTW you are right that the way Drupal is doing i18n is not the best solution one can think of. I am having hard time with it sometimes.
Well there are some serious issues with views over translating taxonomy terms or vocabs names. This could be resolved with some extra modules or / and custom PHP code inside views fields. Usually 70% of modules does not support translation, then you need to patch them to support it. While others does have translation possibility, but it could be two possible ways: uses variables table to hold different translations UI dependent (need to switch to other language to find a string) or uses translation field tables to utilize "translation interface" from admin menu.
So far that's it :)
I wish you luck!
