Problem with localised Data Source output

[nilshoerrmann]

This is a strange problem with Brendan's Meta Keys extension: Multilingual returns the correct translation for all fields in the XML output expect for Meta Keys fields. It always defaults to the first language available.

Example:

<params>
    <multilingual>yes</multilingual>
    <languages>
        <item handle="de">de</item>
        <item handle="en">en</item>
    </languages>
    <language>en</language>
</params>

…

<entry>
    <datenblatt-de mode="normal">
        <key handle="gewicht" name="Gewicht">
            <value handle="250g">250g</value>
        </key>
        <key handle="materialien" name="Materialien">
            <value handle="nylon-leder">Nylon, Leder</value>
        </key>
        <key handle="preis" name="Preis">
            <value handle="2900">29,00</value>
        </key>
    </datenblatt-de>
    <datenblatt-en mode="normal">
        <key handle="weight" name="Weight">
            <value handle="250g">250g</value>
        </key>
        <key handle="materials" name="Materials">
            <value handle="nylon-leather">Nylon, Leather</value>
        </key>
        <key handle="price" name="Price">
            <value handle="2900">29,00</value>
        </key>
    </datenblatt-en>
    <datenblatt mode="normal">
        <key handle="gewicht" name="Gewicht">
            <value handle="250g">250g</value>
        </key>
        <key handle="materialien" name="Materialien">
            <value handle="nylon-leder">Nylon, Leder</value>
        </key>
        <key handle="preis" name="Preis">
            <value handle="2900">29,00</value>
        </key>
    </datenblatt>
</entry>

datenblatt should represent datenblatt-en in this case while it shows the content of datenblatt-de.

[jensscherbl]

Multilingual checks if a field (in another language) has content or not, and if not, it defaults to the first language.

The problem here (I guess) is that more complex fields like Meta Keys have a very different structure and $element->getValue() doesn't return a value, therefore Multilingual thinks the field is empty.

Not sure if it's even possible to provide a general solution to this without adding support for fields like Meta Keys specifically.

Edit:

I have an idea...

[jensscherbl]

@nilshoerrmann Can you think of other common fields with a more complex structure you need this tested with?

[nilshoerrmann]

Date and Time maybe?

[jensscherbl]

If you want to help with this issue, maybe you can tinker around a bit and try to find a good solution.

The value checking is in Line 356. Elements are the XML elements of the fields at this state.

Edit:

Other idea would be, we just have multiple elemements with the same name and a language attribute (title with lang=de instead of title-de), as suggested here.

This solution wouldn't care about falling back to the default language (in case the translated field is empty) and leave the checking and falling back to your XSLT.

Would be more flexible, but also massively bloat the XSLT (you would have to do the checks and fallback everywhere you want to access a translated field).

[nilshoerrmann]

The value checking is in Line 356. Elements are the XML elements of the fields at this state.

If I have two fields, say title-de and title-en, Symphony will only return an element in the XML, if those fields have content. So if my entry has a German title but no English one, there should only be <title-de /> in the source but no <title-en />, right?

In this case, wouldn't it be easier to just check for the existence of those elements without taking care of their content? So you could just clone the element you need, change its name to title and attach it to the XML output. Not messing with the nested content.

Other idea would be, we just have multiple elemements with the same name and a language attribute (title with lang=de instead of title-de), as suggested here.

I like the idea of having language attributes.

This solution wouldn't care about falling back to the default language (in case the translated field is empty) and leave the checking and falling back to your XSLT.

It would be possible to have both (lang="current").

[jensscherbl]

If I have two fields, say title-de and title-en, Symphony will only return an element in the XML, if those fields have content. So if my entry has a German title but no English one, there should only be <title-de /> in the source but no <title-en />, right?

Unfortunately not, Symphony also returns empty fields, that's why I have to check the content (empty textareas even have content since Symphony outputs an empty CDATA-string).

So you could just clone the element you need, change its name to title and attach it to the XML output. Not messing with the nested content.

That's already how I do it, but as mentioned above, still needs checking if empty or not.

It would be possible to have both (lang="current").

Right, good idea. Doesn't solve our issue, though.

[nilshoerrmann]

Is there something like a toString() function that can be applied to the element so you could do better checks for emptyness?

[jensscherbl]

Is there something like a toString() function that can be applied to the element so you could do better checks for emptyness?

There's the generate() function which returns the XML output as string. Not sure if this is really better for checking or even more complicated. Will do some testing.

[nilshoerrmann]

I just noticed that this issue also occurs on the core select field.