Scenario 1:

  1. Activate 2 languages: De(default), En
  2. Create a node in German
  3. Add translation in English, change title.
  4. Install administration_language_negotiation
  5. Visit "/admin/config/regional/language/detection"
  6. Activate "Administration language", "URL"
  7. Make sure "Administration language" is above "URL"
  8. Visit the created node, try to translate it.
  9. See that node form content is always in German.

Scenario 2:

  1. After all the steps in Scenario 1
  2. Create a new node in German
  3. Add translation in English, change title
  4. Visit the new node page in English.
  5. See "Symfony\Component\Routing\Exception\ResourceNotFoundException"
CommentFileSizeAuthor
#7 translation_is_broken_3013406_7.patch698 bytesOscaner

Comments

a.milkovsky created an issue. See original summary.

a.milkovsky’s picture

a.milkovsky
he/him
Location UTC +2
commented
Priority: Normal » Major

Major, as the module breaks core functionality (if not critical).

anybody’s picture

anybody
Primary language German
Location Porta Westfalica
commented

I can confirm this problem. Even when visiting the translated node form, the language select is always overridden with the selected administration language and the content is shown in that language in the form.

Other admin language modules like https://www.drupal.org/project/admin_language_negotiation and admin_language have exactly the same problem.

nielsaers’s picture

nielsaers commented

Any news on this bug?

fox mulder’s picture

fox mulder commented

I can confirm the problem too.

fox mulder’s picture

fox mulder commented
Related issues: +#2801397: Account administration pages option break multilingual

likely core problem:
https://www.drupal.org/project/drupal/issues/2801397

Oscaner’s picture

Oscaner commented
Status: Active » Needs review
StatusFileSize
new translation_is_broken_3013406_7.patch698 bytes

So interesting.
This issue from here, at src/Plugin/LanguageNegotiation/LanguageNegotiationAdministrationLanguage.php

...
    return $this->currentUser->getPreferredAdminLangcode();
...

The getPreferredAdminLangcode have one param called fallback_to_default, default is TRUE.
So if not have preferred admin langcode, this function always return default langcode for us.
This is why the Scenario 1 was happened.

Change this code to

...
    return $this->currentUser->getPreferredAdminLangcode(FALSE);
...
mastap’s picture

mastap commented

We're also encountering this problem.
Was this fixed?
In fact without this fix the module is unusable!

PS: Will this patch #7 work with Paragraph?

  • Pol committed 6e5b209 on 8.x-1.x authored by Oscaner 
    Issue #3013406 by Oscaner: Translation is broken
pol’s picture

pol
Location Brussels
commented
Status: Needs review » Fixed
anybody’s picture

anybody
Primary language German
Location Porta Westfalica
commented

Thank you very much @Pol for fixing this! :)

mastap’s picture

mastap commented

I did apply the patch: translation_is_broken_3013406_7.patch

This was committed to Branch 1.x or 1.10 !? confused

How come I still see the problem on the Scenario 1

Status: Fixed » Closed (fixed)

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

gaurav_manerkar’s picture

gaurav_manerkar commented
Related issues: +#3228726: Argument 1 passed to Drupal\language\LanguageNegotiationMethodBase::setCurrentUser() must implement interface

Facing another issue after updating module to v1.11