Steps to repeat:
1. Enable two translations for a content
2. Enable this module
3. create a new entity (A), and add the two additional translations, say, (B) amd (C)

At /admin/content, the table renders A, C, and C - which should be indeed A, B, C.

The v1.3 is fine. There must be some regressions.

Comments

adamschan created an issue. See original summary.

papagrande’s picture

Priority: Major » Critical
Status: Active » Needs review
StatusFileSize
new685 bytes

I found that the cache ID (CID) was getting reused for all translations and wasn't specific enough so I appended the original language code.

This bug is critical for our site because it changed content shown in views.

radelson’s picture

Status: Needs review » Reviewed & tested by the community

Here is an alternative description for this bug, not sure if I understand the initial bug report

The service can be reused multiple times during the same request for different langcodes. Our case was indexing using search_api (not using the datasource or process plugin provided by this module, but the field "Entity language (with fallback)" provided recently by search_api).
When the candidates are requested (multiple times during each step of the batch process), the same candidates are returned for each entity type bundle, no matter the language requested.

The problem is indeed fixed when adding the langcode in the CID.
I couldn't detect any side effect after applying the patch.

I'm marking this as RTBC.

vuil’s picture

Very quick fix and job done. Congratulations!
I confirm that patch of #2 works perfectly for us.

You saved my life, guys. :)

bbu23’s picture

Patch #2 works great!

simonbaese’s picture

Encountered the same problem. Filed another bug #3383157: Static cache in FallbackController service does not consider langcode which I closed after finding this. As we came to the exact same solution, I also add my RTBC here. Please consider this for the next release as it is really hard to track down.

davidiio’s picture

Applying patch #2 made all operations links/bulk operation checkboxes in our views appear "broken/missing handler".
Removing the patch made it work again we can't use it like this but we don't have time to improve the patch now or investigate more on this.

simonbaese’s picture

The patch #2 is completely unrelated to views. The change is very atomic and does not influence other modules. There is probably another problem in your specific setup.

ressa’s picture

I am not using this module, but indexing multilingual nodes in Search API Solr, with default language English (under /en), and Danish as second language, set as fallback language, without language prefix (under /), for Rendered HTML in Search API Solr.

I tried many things like clearing cache, rebuilding Solr index, etc., but this is what seems to work:

I open the edit form for a node under Danish (/node/259/edit), and see English translated field names. If I then clear caches, Drupal "wakes up" and realizes there is a default language (/en), but the fallback language in the current page is Danish. The fields are now rendered in Danish, and now, when I index in Solr, the correct translated field labels are used in the rendered HTML fields.

I have some more comments about the subject in the referred issue, the patch enables indexing of rendered HTML.