I show the content translate programmatically like this:

$service_entities = entity_load_multiple_by_properties('node', array('type' => 'service'));

$services = [];
foreach ($service_entities as $entity) {
  $entity = \Drupal::entityManager()->getTranslationFromContext($entity);
  $services[] = [
    'title' => $entity->title->value,
    // more field...
  ];
}

When I'm logged all translations work well, but when I logout just show me the translations in the default language.

CommentFileSizeAuthor
#3 Selection_007.png18.24 KBrpayanm
#3 Selection_006.png17.07 KBrpayanm
#3 Selection_005.png16.53 KBrpayanm
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

larowlan’s picture

larowlan
Location 🇦🇺🏝.au GMT+10
CreditAttribution: larowlan commented
Issue tags: -multilanguage D8MI +multilanguage, +D8MI, +Needs tests, +Needs manual testing
Berdir’s picture

Berdir
Primary language German
Location Switzerland
CreditAttribution: Berdir commented
Category: Bug report » Support request
Priority: Critical » Normal
Status: Active » Postponed (maintainer needs more info)

- Do you have language negotation configured correctly? If you display the output of \Drupal::languageManager()->getCurrentLanguage()->getId(), is that the language that you expect?
- Is there some page or render cache involved?

Changing to a support request until we know there is a big. I have no idea how that would be possible.

rpayanm’s picture

rpayanm
he/him
Primary language Spanish
CreditAttribution: rpayanm commented
Status: Postponed (maintainer needs more info) » Active
FileSize
Selection_005.png16.53 KB
Selection_006.png17.07 KB
Selection_007.png18.24 KB

- Do you have language negotation configured correctly? If you display the output of \Drupal::languageManager()->getCurrentLanguage()->getId(), is that the language that you expect?

Yes it's the language I expect.
In my code I do:
$stuff['langcode'] = \Drupal::languageManager()->getCurrentLanguage()->getId();
and on my template.html.twig:
{{ stuff.langcode }}
For spanish, print me: es, for english: en, so it's right, no? My primary language is spanish and when I am an anonymous user only show me the text on spanish, no matter the selected language, and it have a translation for english.

- Is there some page or render cache involved?

No, actually I run drush cache-rebuild anyway, and still the problem come out.

I test my site with this:
Test 1

This:
Test2

And this:
Test 3

Still the same result.

rpayanm’s picture

rpayanm
he/him
Primary language Spanish
CreditAttribution: rpayanm commented

Something curious it's that the main menu is translated, and for both admin and anonymous user, this translates!

larowlan’s picture

larowlan
Location 🇦🇺🏝.au GMT+10
CreditAttribution: larowlan commented

Didn't plach open an issue about entity adapter issues with translations, could be related?

rpayanm’s picture

rpayanm
he/him
Primary language Spanish
CreditAttribution: rpayanm commented

@larowlan no, could you explain me better to do?

larowlan’s picture

larowlan
Location 🇦🇺🏝.au GMT+10
CreditAttribution: larowlan commented

I was referring to https://www.drupal.org/node/2414721

Berdir’s picture

Berdir
Primary language German
Location Switzerland
CreditAttribution: Berdir commented

What are you doing with $services then exactly? What happens if you just do var_dump($entity->title->value)?

rpayanm’s picture

rpayanm
he/him
Primary language Spanish
CreditAttribution: rpayanm commented

With $services I passed to twig template to print this result:

return [
      '#theme' => 'services',
      '#services' => $services
    ];

var_dump($entity->title->value) :
Logged:
es:
string 'Desarrollo Web' (length=14)
en:
string 'Web development' (length=15)

Anonymous:
es:
string 'Desarrollo Web' (length=14)
en:
string 'Desarrollo Web' (length=14)

Berdir’s picture

Berdir
Primary language German
Location Switzerland
CreditAttribution: Berdir commented
Component: language.module » content_translation.module
Assigned: Unassigned » plach
Category: Support request » Bug report
Priority: Normal » Major

Ah, now I remember. Try giving the anonymous user the translate any content permission.

Not as a real fix, just to verify that it is the problem I think it is.

On mobile, so can't look up the exact source but it is the problem I was telling @plach earlier, some language alter hook in content translation. And the entity adapter issue is not related.

Sorry for not remembering this earlier, I actually had this myself as well in a test.

Definitely a bug and atleast major.

rpayanm’s picture

rpayanm
he/him
Primary language Spanish
CreditAttribution: rpayanm commented

Try giving the anonymous user the translate any content permission.

Umm I check "Translate Service content" for anonymous and then work fine !!!

Not as a real fix, just to verify that it is the problem I think it is.

I agree with that.

Berdir’s picture

Berdir
Primary language German
Location Switzerland
CreditAttribution: Berdir commented

Ok, if you want to try and fix this before @plach finds time, have a look at content_translation_language_fallback_candidates_entity_view_alter(), something with the is published detection might not be correct.

That said, did you make sure that you translations really are published?

plach’s picture

plach
he/him
Primary language Italian
Location Venezia
CreditAttribution: plach commented

If translations are published this is probably a straight duplicate of #2414721: EntityAdapter should be instantiated per language. I found it while manually testing a very similar use case, i.e. checking whether a view of translated nodes worked correctly for anonymous users.

plach’s picture

plach
he/him
Primary language Italian
Location Venezia
CreditAttribution: plach commented
Status: Active » Postponed (maintainer needs more info)
rpayanm’s picture

rpayanm
he/him
Primary language Spanish
CreditAttribution: rpayanm commented
Status: Postponed (maintainer needs more info) » Active

My translations are unpublished, then I published these and continue the situation.

plach’s picture

plach
he/him
Primary language Italian
Location Venezia
CreditAttribution: plach commented
Status: Active » Postponed

Unpublished translations are not supposed to be viewed by users not having translation permissions, the fact that the behavior persists after publishing them makes me think this is a duplicate of #2414721: EntityAdapter should be instantiated per language. Let's wait for that one to be fixed and check whether that fixes this one too.

plach’s picture

plach
he/him
Primary language Italian
Location Venezia
CreditAttribution: plach commented
Issue tags: -multilanguage +language-content
Berdir’s picture

Berdir
Primary language German
Location Switzerland
CreditAttribution: Berdir commented

Ah, if they are unpublished then that is the expected behavior, yes :)

I had this in simplenews, in a test where I'm sending translated newsletters. That required the translate any entity workaround a few weeks ago, and I was trying to test the patch in #2414721: EntityAdapter should be instantiated per language, but I was actually not able to reproduce the problem anymore, the test works without that permission on HEAD, see #2418403: Remove translate any entity permission from SimplenewsI18nTest.

plach’s picture

plach
he/him
Primary language Italian
Location Venezia
CreditAttribution: plach commented

@Berdir++

Thanks for being so careful :)

plach’s picture

plach
he/him
Primary language Italian
Location Venezia
CreditAttribution: plach commented
Assigned: plach » Unassigned
Status: Postponed » Postponed (maintainer needs more info)

#2414721: EntityAdapter should be instantiated per language was committed. Can you still reproduce this?

rpayanm’s picture

rpayanm
he/him
Primary language Spanish
CreditAttribution: rpayanm commented

The problem was that my translated content was unpublished, but already published working as expected.

Thank you so much @plach and @Berdir.

Berdir’s picture

Berdir
Primary language German
Location Switzerland
CreditAttribution: Berdir commented
Category: Bug report » Support request
Priority: Major » Normal
Status: Postponed (maintainer needs more info) » Fixed
Issue tags: -Needs tests, -Needs manual testing

Great, then marking as fixed and changing to a support request.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.