Make Webform multilingual (i18n) aware

Oh, also. In the menu section there is no language selection while using i18n menus. But in the primary links section there appears a language selection. FYI.

It will be good to use the same output table for different languages as an option and default would be separate tables, or vice versa.

I'd like to get i18n support into Webform. That said, I have no experience with i18n or any sites that require it. The inclusion of this support will probably need to come from a patch contributor or sponsor.

As it stands, there could be two ways to go about translating a webform node:

1) using i18n, whereby you'd recreate a whole new node and change all the labels to the new language (one node per language).
2) using locale, whereby you'd only ever have one node per webform, and would use locale to translate all the labels.

With the first option, if you translate a webform into three languages, you'd have responses to the webform on three different nodes. Perhaps this would be good, since you may need three different people anyway to sift through the results (unless the admin contact for the webform is tri-lingual). The poll module in D6 will tally responses to the same question across all languages, summing responses for showing results. W/ this first option, you could have a links on each webform to corresponding webforms in other languages.

With the second option, since you have just once node, all the results will be submitted to just one node. In this case, if you wanted a different person to be emailed per-language, as responses are submitted, the first option would work better, w/o the need for custom processing. A down-side w/ the second option is that if you change a label in the English version (assuming English is the default language for your site) this will invalidate the translation of that label on the other webforms. Not a huge deal if you are not changing the labels on a 'contact us' webform (unless you have it in 9 different languages == 8 other labels to re-translate).

There are advantages and disadvantages to both of these options. If you switch webform to use CCK for fields, then both options would depend on CCK's use of t() on field labels (instead of webform's). I'm not sure what the latest is w/ this, but in some v. 5 versions, there were a few missing t's.

I'm trying to remember - webforms can reuse components of other webforms? If not, the i18n approach seems like a lot of extra work (recreating all new components for each webform). Then again, w/ some extra flexibility.

A webform, using cck fields, + w/ a cck field that lets you dynamically assign who to email based on what site-language the user filled out the webform, would be pretty nice. I'd think if you're about to move to cck field support, it would be good to look at all this under those circumstances, and maybe patch for missing t()'s in the meantime.

I hope this helps outline some (and maybe there are more) scenarios/solutions.

Components are still not duplicated on translation.
Is this a missing feature/bug? Components where duplicated in D5 versions.

Thanks,

Kees

I have changed this thread category to a "bug report" because of the way Webform breaks the language navigation on a multilingual site. I consider it "critical" but because of the workaround (see below) I will leave it at "normal".

The Multilingual system provides site navigation with the different options depending on whether or not content should be visible in all languages ("language neutral") or only visible according to language-based rules.

Due to the lack of language support in Webform, all web forms are essentially "language neutral". That means that, even if you clone a web form and translate the content into the target language,

1. the original form is visible to all visitors, regardless of their prefered language.
2. the translated form is visible to all visitors, regardless of their prefered language.
3. the language navigation links (along side the date/author info at the foot of the message and and in the Language Selector Block) are self-referential. That is, they follow the rules of the multi-language URL construction but ultimately lead you back to the same node content.

There is no way to disable or hide language links. As a workaround, however, it should be possible to use URL redirects to get a visitor to the correct language of web form (I am about to test this right now) but I can't expect clients to do this on their own sites every time they want a new web form. In other content types URL aliasing rules are automatically taken care of by the i18n module so the client need not do anything special when creating content in multiple languages.

--

I have tested URL redirects as a workaround. Success was limited but not satisfactory. I am elevating this thread to "critical".

First some assumptions for my test:

• The i18n URL rewrite rules use a language suffix:
  • English: mydomain.com/page (default language)
  • Japanese: mydomain.com/ja/page (aliases and redirects are controlled by i18n)
• No URL alias is defined on the Node Edit page
• No URL aliases are defined in Administer » Site building » URL aliases

The test was to use the URL Redirect module to select the correct language of web form. Node/54 is the English version of the form and node/55 is in Japanese. The following redirects were created:

• ja/node/54 -> node/55
• node/55 -> node/54

This worked! The first entry appears incongruous, but the ja is inserted by the i18n module, so all is well. The resulting page is indeed maydomain.com/ja/node/55.

However, i18n seems to handle URL aliases differently, because although I could get it to work to redirect back to English, the Japanese alias just returned a 404 error.

It seems that i18n does not create a .../ja/.. version of the node alias. Perhaps it is related to the node being "language neutral" as far as i18n is concerned. I just don't know.

It's not a bug, as Webform never claimed to support multiple languages. I have made absolutely no effort to make webforms multilingual and despite the large number of modules that do support multiple languages, it usually requires a specific implementation and extra effort to add that functionality. Webform does work fine in any single language though, problems with that can be filed as a bug.

As far as I can see Webform nodes ARE language aware, and so do the strings that are in the forms as labels etc..
A module does not require special code to implement multilingual support, as long as strings are t() parsed, all stuff is properly generated by standard Drupal API's and node information is stored in core default tables (!). If node information is stored in other (module specific) tables, this information is by default probably not duplicated when a node is duplicated using i18n or node copy (cck?) for example.

The latter could be the case for webforms, if so, this is not specifically related to multilingual support, but related to node duplication in general.

Greetings,

Kees

kees, Yes you're right that Webform is "locale" aware, in that you can make a Webform in any language (as I said in #7). It is NOT "multilingual" aware, meaning you can't create a single Webform that is translated in several languages and have them associated with each other.

Whell as a node I can translate webforms in a multilingual environment just as any node type.

The problem I encounter, is the fact that the form elements are not copied to the new translation of a webform node.

So, this makes me think that it's more a node copy problem than a multilingual problem.

(Just try to make clear my previous post, I do not mean to argue ;).)

In response of #3, components are able to be cloned between forms but only using a custom patch http://drupal.org/node/298268 I hope Quicksketch consider including this on the core.

In the near future I will have to do webforms (and a whole site) in 2 or 3 languages. I hope I can help then.

I have been creating a multilingual site making use of webforms.
There are 7 translations, but as one poster noted above, each must be e-mailed to a separate person anyway, so I cloned the first node 7 time and changed the labels which worked fine. My problem is, even when changing my site language, The select and date dropdowns in webform are not translated. i.e. 'Select...', date day and month names.

Is this possible to do in D6?

Ok, sorry being a bit thick there. I got the translation system working in D6, which successfully translates the 'select' box, but not the date components.

Now I know this is dependant on the status of the translation .po files, but I tried with Dutch (nl) and the translations for 'select', 'day', 'month' and the month names appear to be in the file under the translations folder of the webform module. However, still only the translation for 'select...' appears when the language is changed...

I searched some old posts which says after you enabled the i18n module, webform is supporting multilingual. However, that's for Drupal 4.7. So the upgrades have break the i18n support which was available a long time ago? I'm not sure if it is a webform issue or i18 issue.

I'm currently using Drupal 6, i18n module, and webform 6.x-2.3. As I understand, D6 has built-in multilingual support which shows a 'translate' table after the editing. All the content types created in the normal way has that feature, but not avaialbe for webform nodes. My question is, as a webform node is essentially a node, why the translation function is not there? I would like to see somebody explain that as it is basically a core feature now... And if I want to support the translation of the generated forms, where should I look to in the code? Maybe I can roll a patch if someone know more about this module can give me some hints.

yang_yi_cn: basically, in Drupal 6 when you translate a node you make a copy of it. However, what this means for Webform is that you need to recreate or edit every single component in the language you are translating it into. Webforms are much more complicated that any other node type, hence why the challenge is greater. Beyond that, when working with the "translated" copies of the original node, you'd probably want all the results to be aggregated together. But since each translated copy is a different node entirely, we'd need to improve upon the logic that builds the result sets. Right now they're all kept separately as if the nodes weren't related at all.

Yes, in Drupal 6 when there are translations, they are different nodes and share a 'tnid', which is the source node.

To my understanding, it makes sense that the title and description of the two nodes in different languages having different copies, but normally we would like to share the same form, while get every single pieces of text translated.

I think, firstly, we need to enable the duplication of node, i.e., enable the 'translation' tab.

Secondly, we need to have the url alias for different languages.
I've enabled the pathauto module. So, for now if I create a webform which is http://en.mydomain/node/1234, it will have the path http://en.mydomain/content/title, but I cannot access http://fr.mydomain/content/title, I have to access http://fr.mydomain/node/1234 to get the same form in the French language. But I think this problem will be automatically solved once we implemented the first step, to have a translated node for the other language, say, French.

Third, the translation of the components, both labels and values.
Once the previous two steps are implemented, labels should be translatable already, I tried to visit the http://fr.mydomain/node/1234 and that refreshes the translation database and I then can search through the translation interface in Drupal and translate it.
The values are a little bit tricky. There can be different ways to do it. Let's see how i18n_taxonomy deal with it, there are four options:

• None. No multilingual options for this vocabulary
• Localize terms. Terms are common for all languages but their name and description may be localized.
• Per language terms. Different terms will be allowed for each language and they can be translated.
• Set language to vocabulary. The vocabulary will have a global language and it will only show up for pages in that language.

As mentioned in the beginning, I don't think the webform components should be different for each language, so the solution here should be:
"Localize form values. Values are common for all languages but may be localized."
How to implement that? Although I didn't look into the code, I assume there will be some CRUD functions for the components. So, when LOAD, we should pre-fill the translated values to the default values and selection options. It's possible, just make sure we get the source string from webform_component table, which should be correct because we only have one copy for each 'tnid'. Then 'foreach...t()..' after loaded from the database and the values can be translated from the translate interface. When SAVE, if current language is the source language, update the webform_component table. We can disable the component update for other languages than source, show a page with links to the source components and the translation interface, or make a translation page showing all strings used in this form, for editing, but not editing the form elements.

Finally, for the analysis, we can keep the current data structure, but JOIN with node.nid, node.tnid, node.language and alter the db_query to show different language results separately and/or together.

Well, I got a simpler solution, which might not be perfect, but works for me.

Basically, I still just create one webform and keep it 'language neutral', then, instead of make different copies of webform, I change the text displaying by adding t() to the hook_view() and _webform_filter_values()

Thanks for sharing your approach yang_yi_cn. This won't be usable as a permanent solution in Webform however. The use of t() on dynamic variables is a very bad practice, since there's no way to cleanup or change those values after they get out of date. Even a single webform is likely to add dozens or hundreds of new strings.

Not sure if I'm missing the point here, but I've able to get at least the field titles of the webform translated with no hacks.
I have a multilingual site, using Locale and I8n. Most pages are language specific using language prefix in the url.
I set up the Webform to be language neutral. Its path is /calendar-and-booking
I am using 3 separate menus for the 3 site languages. The 2 non-English menus have a custom menu link I added which points directly to the webform (node/50). The menu items are set to be language specific (ie the German menu item is set to be German language etc).

When the current user is, say, German, he sees the German menu. The link for the webform is automatically shown with the language prefix (/de/calendar-and-booking) and when he clicks it, he gets the Language Neutral webform, but the field titles in the form are translated (after I translate them using locale).

If you want to have a look, the site is www.gallaghersequestriancentre.com. You can change language by clicking on the flags.

I can't get the node title or any descriptive text translated using this method but it's a good start.

I too got this to work without hacks. The strings are translatable and the translations can be linked just like any other form of content.

Could a be that this has recently been fixed?

Edit: I remember though that I had to switch "multilingual support" to "Enabled, with translation" in the Edit Contenttype screen.

So, you have 2 webform id and you will have 2 webform results, dude!

This is a temporary solution. Is there anyway to hook these two functions using a new module. Then, we can update the webform later?

I have just built a module to integrate the Webform module with the I18n module. Check this out.
The module is webform_multilang . I don't know how to add this module to the community, so I add to this page.
***_ THIS MODULE IS OLD, CHECK NEXT COMMENT _***

Attachment	Size
webform_multilang.zip	1.31 KB

Module: Webfom Multilanguage
Description: Integrate the Webform module with I18n module

Attachment	Size
webform_multilang.zip	1.3 KB

oliverhuynh, it'd be much appreciated if you could provide these in patch form: http://drupal.org/patch/create. Otherwise it won't be reviewed for inclusion into Webform directly.

Is there anybody that can transform this code to a patch so it can be included en webform? please, It would be much appreciated!
Thanks for this great module!

I'm not so sure we want the approach mentioned in #24 in webform itself... it uses the t() function for the body and teaser, which can be problematic perhaps.

However, I'm very glad that there is work being done in this direction.

I'd like to summarize the current state of webform when it comes to multilanguage support:

There are two ways to do this at the moment:

1. Translate strings with locale module: You have only one webform, but title etc are not translated.
2. Translate the node using i18n: You have to recreate the form for each translation, you have a separate webform for each language, but it is fully translated. (example)

The first one is quicker, and allows you to see all results for all languages, but it's not fully translatable. The second is far more time consuming, separates results but it gets you there fully.

So, the issue of translating webforms is a very special one, it won't do with just the normal node translation approach in my opinion. We should brainstorm a bit about this, here is my take on it:

We could have these situations:

1. Different fields for different languages, or the same?
   • If the same fields are used, then just use the translate strings from locale
   • If using different fields, then let the user edit the existing ones.
2. Different emails for different languages or the same?
3. Keep results separate or use the same table for all languages?

In each case, the existing fields in the webform should be passed when creating the translated node.

In my opinion, these different situations call for a different approach to making webform multilingual, than the rest of modules out there.
However, ideally this would cover all possibilities and let the user configure it properly.

As how to go about doing this, perhaps have the user specify options under a "Multilingual" section when you create the webform, if i18n is present.

Thoughts?

IMO, fields should be transfered in all cases. A language field in the DB table would suffice, stating the language of the form. Because even though the results may differ, some fields may be excluded or included, I assume 90% of the fields will be needed for each translation. Let's say you have a title field which is Mr. or Ms. in spanish you get Sr. and Sra., you can set their values in Spanish as Mr. and Ms., respectively. Or webform can handle this so everything will be in the same form. When querying you can select language=spanish.. etc.

+1

Subscribing to this. We've done some work in this area, to link up different language versions of the same webform so that a webform administrator can clone the webform for different languages and customise as necessary, then view the results in the same screen. I think we need to refactor it a bit, but hopefully we can release it soon.

Also created #426108: Webform submission notifications are sent in language of submitter not creator to do with submission emails being sent in the wrong language.

The bits that geodaniel mentioned are actually at http://drupal.org/node/403692 and waiting for my spare time to get stripped out of the webform_add_ons module (6.x-2.3) which has a bunch of other additional functionalities. For immediate needs you can try it.

I have created one webform for 3 languages English, French and Dutch
Does anybody have a solution to translate the title?

Looking forward to it geodaniel! Will you release an early beta version?

Any news about this?

I just need the title and the select list items translated for now.

To make the select list items translatable, put this code after the line 153 in components/select.inc

akalyptos,

Thanks, thanks, thanks!!! that code did all the work!!! I'm going to sleep happy!

I hope this can be added to webform's next version so we don't have to make this change everytime.

I really appreciate your help!

Thanks again.
Maira.

thank you! This works great!
How can I translate the title?

I'm almost there to launch the site and i need the webform title translated. At this point it doesn't matter if the solution is something strange, but I would love any way to solve this.

Sinceresly thanks.

+1 critical imho

The 3.x branch has been created for new features such as this one. Due to the amount of work involved in this, I'm not planning on implementing this feature. This feature will need to come from the community if it will ever be added.

I can understand that quicksketch... I'm thinking this would be a good candidate for a sprint! any takers?

This one of the issues that keeps me from using the module. I know in the US this probably isn't such a big deal, but for the rest of the world, it is. Perhaps a local group somewhere will take challenge and organize a sprint =)

Manuel, today I read your message and the one sent by quicksketch and as I see there will be no official help and I need my title translate I made some simple changes... I'll explain them, maybe they can be helpfull for someone.

In my webform which node id is 24 the following were left untranslated:
1) Node title
2) Page title (the title tag in page head)
3) The title in the breadcrumb, if you have added your current node title without a link at the end of the breadcrumb as is explained in http://www.internetunlimited.nl/en/blog/breadcrumbs-drupal-6

Here are the solutions for each one of this problems:

1) NODE TITLE: Create a page-node-24.tpl.php in your theme folder, where 24 has to be replaced by your node number. Note: Copy your page.tpl.php and then rename it. Find:

And add before that, this lines:

You are passing the $title variable through t() function. Then you go to the admin/build/translate/search and search for the node's original title and translate it. If the string doesn't appear, go to the node page in the untranslated language, and then search again and it will appear.

2) PAGE TITLE:In the same page-node-24.tpl file I replaced:

With:

You have to repeat the same as in step one to translate the string.

3) BREADCRUMB TITLE: To translate a custom breadcrumb made with the tutorial explained in http://www.internetunlimited.nl/en/blog/breadcrumbs-drupal-6 you have to go again to your template.php file and search for the phptemplate_preprocess(&$variables, $hook) and replace all the function with:

Remember to change in $variables['nid'] == 24 the "24" with your node number.
I can't explain why this have to be done like this, cause I'm not a programmer, and this part was not made by me. My fiance doesn't know how does drupal work, but he could make it work. I only know this works!

If you alredy translated the string in step one, then, the breadcrumb title appears translated after this change.

As you can see, the third step is only to those who made the customization of the breadcrumbs.

The first and second steps are the important ones, and can be applied without modifying anything in webform module. We only have to create a tpl for the node and pass both titles through the t() function. It's great for one or two contact forms. If you have lots of forms, it's not the greatest solution, but is the one I can provide :D

I hope this can help anyone with the same problem!!

And thanks for webform! I hope this translation problems can be solved soon.

mairav, a simpler solution (if you're just using t() on the title) is to wrap your page title in t() in hook_preprocess_page().

In your theme's template.php file:

Then you don't need to make a separate page.tpl.php file and it'll work on all Webforms automatically. Just clear your Drupal caches at admin/settings/performance (the button at the bottom) after adding the new function to template.php. However I'd like to re-iterate (yet again) that wrapping dynamic strings in t() is improper use of the function, but until this problem is fixed properly, I can't prevent people from doing whatever they'll do to get the title translated.

Thanks a lot! This works!

quicksketch, thanks for this solution, I haven't try it yet, but I will. I'm pretty new with drupal and I'm not a programmer, so I looked for a solution, even when I knew this one was not a proper one.

One of my forms needs another changes so, I can't avoid using a diferent tpl.php, but other ones just modify:

<?php if ($title): print '<h2'. ($tabs ? ' class="with-tabs"' : '') .'>'. $title .'</h2>'; endif; ?>

This would be solved with your solution. And

<?php $head_title ?>

How can I fix this one?

Sinceresly thanks for your help. I hope this can be solved soon, so we don't have to make extrange changes :D

Referring to post #27, I'd like to translate strings in the webform with Locale module, but in the Edit page of my webform I can't see the "Language" select option, so I can't make the webform "Language neutral" and, as a result, users with language different from the default language can't see the webform.
Am I missing something?
Thanks

@ #27

I think we should try to look bigger picture and final state of this module. It should have possibilty like with different node for every language. As you would maybe add different descriptions to them and different emails as if u have 6 languages then u will have more ppl to read emails and then they should be send to those who can actually read them :-)

Biggest problem for me, from number 2 solution now is. If i have 8 languages and 6 forms with 10 fields each, i have to recreate all of them and wait for hundred of page reloads ufff :-(
So i think duplicating form component when translating should at least be an option. then i could just rename all the fields for each form, fild names/labels are on the same page, so i just quickly do it and thats it. Think this would be best solution.

Now i will do this manually, duplicate node with node clone and then add them to languages so i dont have to wait for each component creation as its very time consuming.

What do u think?

Hi all,
I am so lucky because i found this issue and helped me with translation select list items, everything is working fine. Thanks all!!!

But i am freaking out a litle, did anyone notice that if you make a change into any field in any language all the form will set that language as default and translation will stop working??
I dont know if it is a bug or how to called but it happened to me twice today.

gonna go a bit deeper, i made a form (webform.module) in english then translated to spanish with the translation interface, i was checking and everything was going good, as i had a long input field i change the size in spanish and then this form was in spanish all the time, not english anymore.... :( had to rename all the fields again.

Is it a bug, did anyone notice it?

If you translate a webform into multiple languages you can use the visibility settings in Panels 3 to choose which language to display.

'-- Add new visibility rule' then depending on your particular setup either choose 'Node: language' or 'User: language'.

The values of the select list are translated on the screen by applying the solution of #35, but these values are not translated in the sent e-mails. How can I fix this?

The labels of the fields are translated correctly.