New mode to output all languages about multilingual_field HOT 8 CLOSED

Now that's a strange coincidence ...

I'm developing the Multilingual URL Field (see URL Field) and I just found out yesterday (Thursday) that I actually need the values for all languages from Multilingual Field to be output in the XML structure :)

There is one problem tough ...

This is the current output of the field as seen in a DS (for a Title field, English language as current):

<title mode="formatted" handle="yet-another-entry" word-count="1" handle-en="yet-another-country" handle-ro="inca-o-inregistrare" handle-es="spanish-entry">
    Yet another entry
</title>

There are 2 ways to do this:

1_ Output the values for all languages as attributes, except current language value which is the value of the node:

<title mode="formatted" handle="yet-another-entry" word-count="1" handle-en="yet-another-country" handle-ro="inca-o-inregistrare" handle-es="spanish-entry" value-ro="Inca o inregistrare" value-es="Spanish entry">
    Yet another entry
</title>

Thsi approach will be backwards compatible (no XSLT changes required) but the XML output will be REALLY clumsy and won't scale well at all.

2_a_ Rework the output of the code with dedicated XML elements for each language:

<title mode="formatted" handle="yet-another-entry" word-count="3" value="Yet another country">
    <item lang="en" handle="yet-another-country" word-count="3">Yet another country</item>
    <item lang="ro" handle="inca-o-inregistrare" word-count="3">Inca o inregistrare</item>
    <item lang="es" handle="spanish-entry" word-count="2">Spanish entry</item>
</title>

This approach will scale very well, obviously, clean output with detailed information for each language.

I added the values for current-language (English here) as attributes in title for easy access. This is debatable:

Pros: Small code snippet (yeeey, for lazy ones):

<xsl:value-of select="title/@value"/>

Cons: duplicate information. Not a good thing.

2_b_ Remove this info and keep it clean:

<title mode="formatted">
    <item lang="en" handle="yet-another-country" word-count="3">Yet another country</item>
    <item lang="ro" handle="inca-o-inregistrare" word-count="3">Inca o inregistrare</item>
    <item lang="es" handle="spanish-entry" word-count="2">Spanish entry</item>
</title>

Pros: clean structure
Cons: The value of current language must be used to identify the element, but if you're building multilingual sites I bet you have the current language stored in a variable so this won't be a con after all:

<xsl:variable name="lc" select="/data/fl-languages/current-language/@handle"/>

<xsl:value-of select="title/item[ @lang = $lc ]"/>

I suggest approach 2_b_ because it's future friendly. If we do this, we do this right from the first time.

from multilingual_field.

Maybe @vlad-ghita knows a way to add it to all multlingual fields?

This should be done in each field separately.

from multilingual_field.

I thought this to be a new, separate output mode, like fieldname: all-languages. So in the case of the ML Text Box we'd end up the output modes :formatted, :unformatted and :all-languages. This way we don't have to worry about compatibility with existing templates. So I'm suggesting (and implemented it like that) 2_b_ as well. :-)

I my use case (building a members backend) the :all-languages mode automatically builds an :unformatted item for each supported language. The code in appendFormattedElement() for this (the new) version of the multilingual text box could look like

if ($mode == 'all-languages') {
    $all = new XMLElement($this->get('element_name'), NULL, array('mode' => $mode));

    foreach (FLang::getLangs() as $lang_code) {
        $data['handle'] = $data['handle-'.$lang_code];
        $data['value'] = $data['value-'.$lang_code];
        $data['value_formatted'] = $data['value_formatted-'.$lang_code];
        $data['word_count'] = $data['word_count-'.$lang_code];

        $attributes = array(
            'language' => $lang_code
        );

        $item = new XMLElement(
            'item', null, $attributes
        );
        parent::appendFormattedElement($item, $data, true, 'unformatted');

        // Reformat generated XML
        $elem = $item->getChild(0);
        if (!is_null($elem)) {
            $attributes = $elem->getAttributes();
            $value = $elem->getValue();
            $item->setAttributeArray($attributes);
            $item->setValue($value);
            $item->removeChildAt(0);
        }

        $all->appendChild($item);
    }

    $wrapper->appendChild($all);
}

The mode could be added to the DS Editor like

public function fetchIncludableElements() {
    $includable_elements = parent::fetchIncludableElements();
    $includable_elements[] = $this->get('element_name') . ': all';
    return $includable_elements;
}

But maybe we sould support every output mode of the parent field in a :all-languages variant. Then the above snippet wouldn't work when the output is not text only (e.g. formatted) and has child nodes because of

$value = $elem->getValue();
$item->setValue($value);

from multilingual_field.

all-languages formatted
all-languages unformatted

?

from multilingual_field.

Thumbs up for 2_b implementation and all-languages formatted / all-languages unformatted

from multilingual_field.

I'll take care of it.

Thanks @klaftertief for the implementation example.

from multilingual_field.

Yep. It sounds a bit rough but I think prepending 'all-languages' to the parents modes works. Though the mode selection in the DS editor gets filled even more. Imagine ML fields in a subsection.

from multilingual_field.

I'll take care of it.

Thanks. Appreciated.

from multilingual_field.