ZF-5568: Zend_Form_Element_Multi does not handle translations on key's


While typically do would not want the key's to be modified, I believe there has been a major design flaw in terms of handling OptGroups for select statements that causes the label to not be very flexible and unable to handle corresponding translations. Consider the following array which would be optimal for handling the situation of OptGroups in a select element and reflects relational data points that you might have from a database:

    [1] => Array
            [label] => translatable label
            [options] => Array
                    [1] => data element 1
                    [2] => data element 2
                    [3] => data element 3

Essentially there would be a label field for the label of the opt group where as the internal options would be defined by the key of the array. This gives additional flexibility in terms of being able to maintain a sustainable approach to select elements and handling translations in the current design without a massive rework or overhaul of the existing logic.

Given this the option that is set into the design would be more flexible and would allow the OptGroup label to display correctly while being able to maintain a hierarchy for a list. In terms of backwards compatibility the label field could be automatically filled in by the key value.

Otherwise, you are left with doing a hack or generating a different value for translations when you retrieve the elements.... A quick and dirty hack for the Select.php file would be something as the following which has additional impact to handle the opt group translations which is far from a good idea!

    public function getMultiOptions()
        foreach ($this->options as $option => $value) {
            $option = $this->_translateValue($option);
            $this->_translateOption($option, $value);
        return $this->options;


Fixed in trunk and 1.8 release branch