Posted by gterez on September 3, 2010 at 10:32am
Does anyone have recent experience with webforms in a fully internationalised Drupal website?
I saw that the webform module does not fully support the i18n system but there have been patches that successfully address some issues (see: http://drupal.org/node/245424).
Do you think it's worth trying to make it work? or shall I go for a CCK-based solution? I won't be needing anything very complex, just a few beefed-up contact forms. Webforms work really well for that because of the email integration and csv export functionality.
Any opinions will be greatly appreciated!
Cheers,
George
Comments
Interesting
Actually after a year of running a multi-lingual website without the locale or the i18n modules I'm finally looking at using these modules (as much as I'd love to avoid them), and one of my main reasons is that I need to have multi-lingual support for webform verification (such as email address formats, madatory fields etc).
I'm interested to hear that it may cause problems. I'll be experimenting soon and I'll give you an update if I bump into any problems.
How do you do it without locale & i18n?
Thanks Richard, I'd like to hear about your experience! Out of curiosity, how do you manage this without locale & i18n? A different theme for each language (and therefore different blocks etc) and hand-crafted urls?
...
You're pretty close. I have just one theme but I've hand-crafted the URLs in that all the Japanese pages have a 'jp' prefix. Because I've defined this prefix myself it is recognised by the block configuration system (the prefix added by the Locale module isn't recognised, which is one of the module's key failings in my opinion).
I essentially have a bunch of blocks which are configured for jp and jp/* and the rest are configured for the inverse.
I have two menus - the primary menu and a Japanese menu. These are implemented via two nice menus blocks which are are configured to be displayed in the same way as the other blocks.
Other than that I have a j-page content type in addition to a standard page which provides me with a bit more flexibility where necessary.
With respect to pages created by views I've also defined the page paths to have a 'jp' prefix where required. Naturally my j_page comes in handy here when building queries in the correct language.
Essentially it was very simple to set up when compared to the Locale / i18n combo. Plus it doesn't have the associated drawbacks of these modules such as duplicate content, poor views integration, and path prefixes which aren't visible to the block configuration system.
However...I currently can't work with the t() function, and this is becoming more of an issue.
Long-term I'd like to write my own alternative module to use in place of these modules which is still able to leverage the power of the t() function (or something like it). Unfortunately however my experience is in writing c++ and .net development, and much of Drupal still remains a mystery to me.
Clever!
Quite a clever solution :-) I've found the basic local + i18n to work well, but those issues you highlight are pretty big and they're indeed not handled elegantly. Menus & blocks handling, as well as searching by hand for strings to translate are things that are nowhere near Drupal's usual standards. There exist other cases though that are handled very smoothly with locale + i18n and would a hack otherwise. E.g. you can turn the site logo in your theme to a multilingual variable and have the image switching along with the language.
I haven't had any issues with Views, I find they're working pretty well with different languages (and there are ways to translate the "no results" or header/footer texts).
Views
I've just been messing around with views and while it works to a degree I have one major issue with the way in which the path prefix is defined:
http://drupal.org/node/903622