The description field of webform components is not translated, and the description strings don't show up in the string management interface of localization.

CommentFileSizeAuthor
#3 select.inc_.patch696 bytesBodo Maass

Comments

quicksketch’s picture

quicksketch
he/him
commented

They should be translatable, they're all properly wrapped in t() functions such as this from date.inc:

/**
 * Module specific instance of hook_help().
 */
function _webform_help_date($section) {
  switch ($section) {
    case 'admin/settings/webform#date_description':
      $output = t("Presents month, day, and year fields.");
      break;
  }
  return $output;
}
quicksketch’s picture

quicksketch
he/him
commented
Status: Active » Closed (fixed)

Please re-open if more information become available about what the problem is or what needs to be solved.

Bodo Maass’s picture

Bodo Maass commented
Status: Closed (fixed) » Needs review
StatusFileSize
new select.inc_.patch696 bytes

I think the problem was not the static description of the available fields, but the user-supplied description for those fields. There was another issue related to translating webforms where you suggested that people should use the internationalization or localizer module to create translations of the form. This is a possible approach, but it has the large disadvantage that there will be a separate form for each language, with separate result lists.

In drupal5, the locale module offers to translate strings that go through the t() function. Although this is primarily intended for static strings, user supplied content can in fact be piped through that function, and many modules make use of this. While drupal6 has a cleaner solution for that, my production site is using drupal 5 and I noticed that a fully translated webform is almost possible with the default codebase. So I changed the code a little to route every remaining item through t(), including every string that can be entered by the user. This allows me to have a single result set of the form submissions, independent of the language that the user had while submitting the form, which is easier for me than to manage several submission sets for the different languages (which also creates problems if you want to limit users to a single submission, independent of the interface language they chose).

To solve the particular translation problem here, I added a call to t() to the #description field in _webform_render_select in select.inc (see attached patch).

morbus iff’s picture

morbus iff
they/them
commented
Status: Needs review » Closed (works as designed)

The fact that Drupal 5 doesn't translate user strings, and encourages you to use something like locale or i18n is by design. No module should attempt to go against this design for the Drupal 5 branch. Modules that do pipe user data through t() in Drupal 5 are wrong, plain and simple.