Posted by Leela on March 8, 2012 at 3:56pm
3 followers
| Project: | Webform |
| Version: | 7.x-3.11 |
| Component: | User interface |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
Hello,
It's just a little problem, but I can't explain it quickly (sorry !).
When you're editing a webform's components, you've got a list of existing components and a line to add a new component :
- to choose the type of a new component, each option of the select list is the translated label of corresponding type ;
- for existing components, the displayed type is the translated type, instead of the translated label of the current type.
It's not a problem for users who know HTML tags, but it could be confusing if the final user is a neophyte (maybe only in some languages ?).
What do you think of this suggestion, in webform.components.inc, function _webform_components_form_rows(...) :
<?php
// Add each component to a table row.
$row_data = array(
$indents . filter_xss($component['name']),
// Current version :
// t($component['type']),
// Suggestion to replace the current version :
(!empty($form['add']['type']['#options'][ $component['type'] ]) ? $form['add']['type']['#options'][ $component['type'] ] : t($component['type'])),
//
($component['value'] == '') ? '-' : $component['value'],
drupal_render($form['components'][$cid]['mandatory']),
drupal_render($form['components'][$cid]['cid']) . drupal_render($form['components'][$cid]['pid']) . drupal_render($form['components'][$cid]['weight']),
l(t('Edit'), 'node/' . $node->nid . '/webform/components/' . $cid, array('query' => drupal_get_destination())),
l(t('Clone'), 'node/' . $node->nid . '/webform/components/' . $cid . '/clone', array('query' => drupal_get_destination())),
l(t('Delete'), 'node/' . $node->nid . '/webform/components/' . $cid . '/delete', array('query' => drupal_get_destination())),
);
?>?
This way, we are sure to use the same name at the 2 locations.
Could this be added to the module ? Or does someone have a better solution ?
Thanks for your help !
Comments
#1
From looking at your code, I can't easily tell what you've changed. Could you either make a patch to show the differences or screenshot before and after your changes?
#2
Ok sorry, here are a patch (I hope the patch is ok ?) and screenshots before and after changes.
#3
Thanks, haha I meant a screenshot of the interface, but in any case I think it's quite clear now. :)
We actually translate these components already in hook_component_info(), it shouldn't be too hard to pull that information out from there instead of trying to reuse the value from the #options array. Really our use to t() is incorrect here (you shouldn't ever use t() on a variable like this), so I'm moving this to a bug report.
#4
Pfff, sorry for the screenshots, what was I thinking ?!
Thanks to you !
#5
Committed this patch to both branches to fix this problem. We don't have an easy API function for getting a components label based on its type, but we conveniently already have a key => value list on this page (the "Add" dropdown) so we can use it to pull out the translated labels.
#6
Automatically closed -- issue fixed for 2 weeks with no activity.