S2.5: Multilingual values of associated entries don't get translated properly anymore about multilingual_field HOT 16 OPEN

Would you mind indicating which you think is desired (or expected) behaviour? Not that much into multi-lang websites, so I don't really know what you'd find intuitive.

edit: Oh wait. I guess that's what the red vs green is for. No idea how I missed that.

from multilingual_field.

Exactly. It's red vs green :) Should have written a note about that though as I didn't mark everything consequently. But for a better understanding I try to break down the expected behaviour in words as well:

1) Datasource Output:

Items that are associated to an entry via "Select Box Link" or the new "Association Field" and that pull their values directly from a multilingual field should get translated to the current frontend language when beeing included in a datasource by their parent entry.

2) Publish Area:

Values that derive from a multilingual field should be shown in a consistent language in the publish area - no matter in what context. Amongst others this includes:

• The "system title" (used for the entry header and the first value of the entries table) of an entry that uses a multilingual field as first (or only) field (Image 8)
• The values listed in an associative field (SBL, etc.) or listed in the entries table by an associative field (Image 9)

This brings up the following question:
Which Setting should define the language of multilingual field values displayed outside of the field?

2.1) The "System Language" set by Symphony itself.
2.2) The "Main Language" set by the Frontend Localisation extension.

• 2.1 always was the behaviour of the mulitlingual extensions as far as I can remember.
• I personally wouldn't have a problem with 2.2, especially when the backend isn't translated.
• It would be good to know what others think about this, especially @vlad-ghita and @nitriques.

The Problem:

In Symphony 2.5 the associated multilingual stuff doesn't work as expected. Both the Datasource Output and the Publish Area don't seem to dynamically fetch the properly translated values of associated entries anymore - instead they show a kind a "static" value that ignores any current language-context and seems to solely depend on the "Main Language" defined by the "Frontend Localisation"-extension at the moment the respective entry was saved for the last time.

from multilingual_field.

@twiro I've been usign this setup across 2.3.x, 2.4 and 2.5 and never experienced the problems described... but

1. For the backend, please see http://symphonyextensions.com/extensions/backend_language_switcher/ This will allow your user to see the content in the right language, according to their author settings. I've been usign it for years with great success. In case I am wrong, I think what you experienced is you've always seen the data in your author language (can you confirm that in both setups, your author has the same language setting please?) -- Releated, this feature was added way before Vlad's effort this centralize multilingual things with Languages. Now that I maintain the project, I am open to new ideas 😄
2. As for the frontend, I remembered patching SBL with regards to multilingual fields, so maybe the patch got wacked (?). Aslo (and this may be the clue), there are breaking changes between 2.4 and 2.5 with regards to associations. Both Nils and I worked on seperated projects on that topic and I've refactored the way fields now provides values to core features like displaying the title in backend pages. I think we need to dig deeper on each of the issues separatly. (BTW, this should affect all multilingual fields.)

BTW, this is an extremely well documented issue, I really apreciate the effort your put in. I am in a deep rush right now at work but will try to find the time ASAP.

from multilingual_field.

I've been usign this setup across 2.3.x, 2.4 and 2.5 and never experienced the problems described... but

Been using this setup for years too and never had the troubles I'm experiencing now.

For the backend, please see http://symphonyextensions.com/extensions/backend_language_switcher/ This will allow your user to see the content in the right language, according to their author settings. I've been usign it for years with great success. In case I am wrong, I think what you experienced is you've always seen the data in your author language (can you confirm that in both setups, your author has the same language setting please?).

I did never use "backend language switcher" - just tried to install it and noticed it does not seem to work with the current 2.5RC1. But in my test case both authors used the same language. I didn't install any additional backend translation and used the default english in both settings.

As for the frontend, I remembered patching SBL with regards to multilingual fields, so maybe the patch got wacked (?). Aslo (and this may be the clue), there are breaking changes between 2.4 and 2.5 with regards to associations. Both Nils and I worked on seperated projects on that topic and I've refactored the way fields now provides values to core features like displaying the title in backend pages. I think we need to dig deeper on each of the issues separatly. (BTW, this should affect all multilingual fields.)

I started tracking down what's happening in the backend concerning the population of the SBL and will post my results in a moment... looks like the weird behaviour derives from changes both to SBL and the Text Box Field.

BTW, this is an extremely well documented issue, I really apreciate the effort your put in. I am in a deep rush right now at work but will try to find the time ASAP.

You're welcome! Good error documentation is all I can do right now as my programming skills are way to small for fixing this. But I am glad if I can help somehow as all of this multilingual stuff is pretty important to me.
And I for sure appreciate all the effort you put in extension-development in general - awesome work!

from multilingual_field.

I did a little more research on this and traced back the problem of the SBL-fields getting populated with wrong language data.
It looks to me like the wrong datasource-ouput in the frontend is directly related to what's happening here, though I haven't had the time to take a closer look at that too by now.

This is what I found out:

Test Setups

Both test setups...

• use the default english language for the author and the system. No backend translation is installed.
• use "english" and "german" as "site languages" of "frontend localisation"
• first use "german" as "main language" of "frontend localisation" (to create the 3 country-entries)
• then switch to "english" as "main language" of "frontend localisation" (to resave the first country-entry "austria")

Setup A

• Symphony 2.3.6
• SBL 1.2.9
• Text Box 2.3.3

This Setup uses the following function in findRelatedValues to fetch the actual entry data that is used to populate a SBL-Field that uses data from a multilingual field:

// Handle fields that are not exportable:
else {
    $value = $field->getParameterPoolValue(
        $field_data, $entry->get('id')
    );print($value);
}

• This returns data in a consistent language - in this case either "german" or "english".
• The language depends on system/author-settings, not on the "main language" set in the "frontend localisation"-extension. Which is fine, because this is happening in the backend, not the frontend.

Setup B

• Symphony 2.5
• SBL 1.3.1
• Text Box 2.4

This Setup uses the following function in findRelatedValues to fetch the actual entry data that is used to populate a SBL-Field that uses data from a multilingual field:

// Get unformatted content:
if (
    $field instanceof ExportableField
    && in_array(ExportableField::UNFORMATTED, $field->getExportModes())
) {
    $value = $field->prepareExportValue(
        $field_data, ExportableField::UNFORMATTED, $entry->get('id')
    );
}

• This does not return data in a consistent language in every use case.
• The language returned does not depend on system/athor-settings, but on the "main language" of the "frontend localisation"-extension.

The Main Problem

Setup B uses data from the basic handle, value, and value-formatted-fields of "Multilingual Field". This data has the following drawbacks:

• In the Backend: The language used in this fields solely relies on the "main language" of the "frontend localisation"-extension at the moment of entry saving. If that "main language" gets changed inbetween entry creation the language in these fields won't be consistent any more.
• In the Frontend: Through associated items in the SBL-field this data also finds its way into the frontend. Which is even worse, because the values of these fields do never actually depend on the current frontend language. If they`re outputted in the correct language it's just by chance.

Where does this new bahaviour come from?

I did some research and found out these two commits to SBL and Text Box introduced the new behaviour:

1. This else-statement in the findeRelatedValues-function introduced to Select Box Link in version 1.3: symphonycms/selectbox_link_field@51db364

2. The new export mode getFormatted => ExportableField::VALUEintroduced to Text Box in version 2.4: symphonists/textboxfield@7fbe24b#diff-f39c595f28f0c9a99925ce4889b77717R654

So it looks like it was just by chance that it worked as expected by now, because "getParameterPoolValue" was still used to find the (right) value although "ExportableField:UNFORMATTED" already had returned a (wrong) value. Now that the else-statement was fixed and text box got a new "ExportableField::VALUE"-mode the "findRelatedValues"-function never gets through to fetching the (right) values with "getParameterPoolValue".

On the database-level both setups are always doing exactly the same things.

What should be changed?

Thinking about this I actually don't see a sense in using the basic handle, valueand value-formatted-fields of "Multilingual Field" at all.
They currently suffer from the drawbacks described above and therefore are completely useless for frontend-usage and mostly useless for backend-usage.

Instead of this the "single language versions" (handle-xy, value-xy and value-formatted-xy) of these 3 fields should be used in every context - be it frontend or backend.

So let's try to summarise what's going wrong right now:

Current multilingual field behaviour in different situations in Symphony 2.5

(This overview refers to what's happening in Setup B)

Behaviours:

• Expected Behaviour (A) : Uses handle-xy, value-xy and value-formatted-xy
• Wrong Behaviour (B) : Uses handle, value and value-formatted

Backend Cases:

• multilingual field values used as entry-heading (entry breadcrumb, entries table) (B)
• multilingual field values used as options of an associative field (sbl, association field) (B)

Frontend Cases (Datasource Output):

• multilingual field values that directly belong to an entry (A)
• multilingual field values that are associated to an entry (B)
• multilingual field values that are used as page-params for datasource-filtering (?) (haven't checked this yet)

A supporting screenshot-collage:

from multilingual_field.

So, in summary this has nothing to do with SBL, but there seems to be a problem between Multilingual Field and Text Box Field in the latest versions. The export-modes of Text Box Field don't consider any kind of language-setting and when used for fetching data of a multilingual field always return non language-specific "default data" (the red "1" in the image above). Which results in different problems in both backend and frontend.

I'll try to dig a little deeper concerning datasource-output and datasource-filtering too as soon as I find the time...

from multilingual_field.

This is great. I am sick right now and will check this ASAP.

from multilingual_field.

I did some more testing concerning datasource-filtering of multilingual text box fields via url-params and ds-params and everything seems to work as expected in S2.5RC1 - if I set up a page named countries with a page-param $handle and use that handle to directly filter for values of a multilingual field all language-variations get recognized correctly and return the desired results:

• /en/countries/germany/
• /de/laender/deutschland/
• /fr/pays/allemagne/

I also can get all entries from other sections that are associated to the multilingual field value I filtered for.

So the bug described above doesn't have too critical side effects ;)

It's really just the translation of associated multilingual values in the datasources that's not working anymore - this can be provisionally dealt with by including additional datasources and performing translations of associated values in the frontend, but a proper fix that would avoid this rather cumbersome method would be awesome :)

from multilingual_field.

It's really just the translation of associated multilingual values in the datasources that's not working anymore -

If I remeber correctly, tI never did truly worked.

this can be provisionally dealt with by including additional datasources and performing translations of associated values in the frontend,

I had this discussion many times before. This is still a real problem affecting all mutilingual fields. I hope that the 2.5 release will allow better interoperability on that mather with the work I've made on the prepareReadableValue API.

but a proper fix that would avoid this rather cumbersome method would be awesome :)

Yeah for sure.

from multilingual_field.

BTW the problem always have been that the core backend support translations but not the frontend. So mixup is always possible.

from multilingual_field.

It's really just the translation of associated multilingual values in the datasources that's not working anymore -

If I remeber correctly, tI never did truly worked.

The translation of associated multilingual values in the datasources worked in every multilingual project I had built with 2.2.X and 2.3.X. It just stopped working since 2.4.X due to the two changes mentioned above.

Regarding translation of associated values in the backend you may be right... that probably never worked as expected...

from multilingual_field.

The translation of associated multilingual values in the datasources worked in every multilingual project I had built with 2.2.X and 2.3.X. It just stopped working since 2.4.X due to the two changes mentioned above.

Yeah me too!

I had a major server crash (both disk on the raid failed at the same time) and it took years to extract the backups and fix everything. I am starting to breath again and will have the time to take a longer look at this soon (will be on vacations)

from multilingual_field.

@twiro This is still an issue right ?

I feel like you've worked on this to much to let it rot....

There has been some work made on SBL since then, maybe the issue does not exists any more ?

from multilingual_field.

And still, the language you see in the backend is the language configured for the author.

SBL still has issues tho.

from multilingual_field.

I guess it's still an issue, but I didn't have the time to test it with the latest releases.
I'm off into holidays for a month now, but I will gladly help testing (and documenting) this issue as soon as I'm back again as it would be awesome to have this functionality back in a solid working way.

So it would be great if you could leave this issue open - thank you!

from multilingual_field.

So it would be great if you could leave this issue open - thank you!

I'll leave it open for sure! I have not seen any problem with it (except with SBL) so far with the latest releases.

from multilingual_field.