Problem

When setting language detection method, the checkbox Customize Content language detection to differ from User interface text language detection settings is not applied, only the interface configuration.

This leads to two critical issues with translating content:

  1. It is not possible to edit translated version of a node. All "Edit" urls on node's "Translate" tab are the same and lead to main editing form. See edit.png.
  2. Translated content is never shown to the user. Default language is always displayed.

Steps to reproduce

On a fresh D8 install:

  1. Enable content translation and language modules
  2. Add another language
  3. Set Detection and selection method to session and browser (tested both, both are broken)
  4. Configure content type "Article" to be translatable (Administration >> Configuration >> Regional and language)
  5. Add a node and set it's language to default one (I used article with image. All fields were filled including image)
  6. Translate node to a second language and save.
  7. Go to "Translate" tab and investigate "Edit" links. Both lead to the same page.
  8. Go to the newly create node and try switching language using "session" parameter. You will still see the node in default language.
  9. Do the same with a browser running second language (or just spoof the browser string to change language). You will still see the node in default language.

Remaining tasks

  1. Investigate why the checkbox Customize Content language detection to differ from User interface text language detection settings is ignored. The source of the issue lies probably inside Drupal\language\Form\NegotiationConfigureForm::submitForm() function. - the configuration is correctly saved
  2. Create patch - Patch is provided

User interface changes

No changes to the UI are required for the fix.

API changes

The protected variable type which indicates whether a given type of language usage (language_content, language_interface, language_url) changes to an array to allow different types to initialize during the initialization of another.

Comments

SiliconMind’s picture

Issue summary: View changes

Added steps to reproduce.

SiliconMind’s picture

Irrelevant.

SiliconMind’s picture

Project: Content translation » Drupal core
Version: » 8.x-dev
Component: Code » content_translation.module

OK, this is embarrassing - I posted this to the wrong project :)

SiliconMind’s picture

Priority: Major » Critical
Issue summary: View changes

I'm changing this to critical. The site is unusable with this bug if you want to use more than one language.
The issue might be related to this: #2214697: Invalid argument supplied for foreach() in Drupal\content_translation\ContentTranslationController->entityFormAlter()

Also updated "steps to reproduce" as it missed one important step.

SiliconMind’s picture

My investigation led me to the Drupal\language\Entity\Language::preSave method that explicitly sets "en" langcode for EVERY language that is being saved. So no matter what language is chosen on "Add language" form (admin/config/regional/language/add), the langcode is always set to "en".

  public function preSave(EntityStorageControllerInterface $storage_controller) {
    parent::preSave($storage_controller);
    // Languages are picked from a predefined list which is given in English.
    // For the uncommon case of custom languages the label should be given in
    // English.
    $this->langcode = 'en';
  }

No wonder that each language.entity.*.yml file has "langcode" set to "en".
Why this is hardcoded?

SiliconMind’s picture

Argh, Ignore my last comment. It seems that language.entity.*.yml is a dead end. The langcode in these files are for label purpose only. It looks like this is langcode of the language entity, not the language itself. This is very misleading.

SiliconMind’s picture

Upon more digging I've found that despite setting language detection for interface to browser and session AND un-checking Customize Content language detection to differ from User interface text language detection settings, language negotiation for content was always set to default, which is 'URL'.

As soon as I've checked Customize Content language detection to differ from User interface text language detection settings and set detection method for content to browser and session explicitly, I was able to see translated content properly.

So it seems that option Customize Content language detection to differ from User interface text language detection settings is ignored.

SiliconMind’s picture

Title: Content translation not working » Content language detection must be set explicitly to work correctly
Component: content_translation.module » language system
Issue summary: View changes

Updated issue to reflect recent findings.
It seems that Drupal\language\Form\NegotiationConfigureForm::submitForm() needs fixing.

It would be nice to be able to delete comments that are now irrelevant (#2, #5, #6).

catch’s picture

Priority: Critical » Major
Issue tags: +D8MI

Tagging with D8MI. This looks like just the configuration form itself is broken rather than negotiation, so moving to major.

meyertox’s picture

Same problem in D 8.0.0-beta; even if Customize Content language detection to differ from User interface text language detection settings-checkbox is on or off, the links in the admin-interface for editing and translating a page/content are resulting in same links

Bearbeiten

Bearbeiten

matsbla’s picture

I also see same issue no matter if the "Customize Content language detection to differ from User interface text language detection settings"-checkbox is on or off.

Maybe this is related?
#2476563: Entity operations links tied to original entity language, ignore everything else

snufkin’s picture

This can be reproduced on the latest dev as well. I've looked into the previously mentioned submitForm() method, but it seems that negotiations are saved just fine as they appear in the config object:

all:
  - language_interface
  - language_content
  - language_url
configurable:
  - language_interface
  - language_content
negotiation:
  language_content:
    enabled:
      language-url: -8
      language-selected: 12
    method_weights:
      language-content-entity: -9
      language-url: -8
      language-session: -6
      language-user: -4
      language-browser: -2
      language-interface: 9
      language-selected: 12
  language_url:
    enabled:
      language-url: 0
      language-url-fallback: 1
  language_interface:
    enabled:
      language-user-admin: -10
      language-url: -8
      language-selected: 12
    method_weights:
      language-user-admin: -10
      language-url: -8
      language-session: -6
      language-user: -4
      language-browser: -2
      language-selected: 12
_core:
  default_config_hash: dqouFqVseNJNvEjsoYKxbinFOITuCxYhi4y2OTNQP_8

Regardless of what language detection I set for content language detection it always defaults to the source node (in this case english).

In comparison here is the config when i disable the Content language customization:

all:
  - language_interface
  - language_content
  - language_url
configurable:
  - language_interface
negotiation:
  language_content:
    enabled:
      language-url: -8
    method_weights:
      language-content-entity: -9
      language-url: -8
      language-session: -6
      language-user: -4
      language-browser: -2
      language-interface: 9
      language-selected: 12
  language_url:
    enabled:
      language-url: 0
      language-url-fallback: 1
  language_interface:
    enabled:
      language-user-admin: -10
      language-selected: 12
    method_weights:
      language-user-admin: -10
      language-url: -8
      language-session: -6
      language-user: -4
      language-browser: -2
      language-selected: 12
_core:
  default_config_hash: dqouFqVseNJNvEjsoYKxbinFOITuCxYhi4y2OTNQP_8
snufkin’s picture

Status: Active » Needs review
FileSize
1.29 KB

So it seems that \Drupal\language\ConfigurableLanguageManager::getCurrentLanguage somehow gets called while it is initialising, and due to the check on $this->initializing it will not process the next query.

If I change this to an array where the key is the type, then the content translation picks up from the URL fine and I see a translated content with english interface.

snufkin’s picture

Oops, random whitespace change crept in.

snufkin’s picture

Updating the type of the protected variable as well.

The last submitted patch, 13: content_language-2189267-13.patch, failed testing.

The last submitted patch, 14: content_language-2189267-13.patch, failed testing.

Status: Needs review » Needs work

The last submitted patch, 15: content_language-2189267-13.patch, failed testing.

snufkin’s picture

Let's see if we initialise the $initializing array with all possible types to FALSE solves the notice errors.

edit: due to a form error I have duplicate patches uploaded, ignore one please.

The last submitted patch, 19: content_language-2189267-13.patch, failed testing.

Status: Needs review » Needs work

The last submitted patch, 19: content_language-2189267-13.patch, failed testing.

snufkin’s picture

Status: Needs work » Needs review
FileSize
1.57 KB

Initializing the array on the first request to avoid the undefined index notices.

Gábor Hojtsy’s picture

Yay, thanks! Issue title and summary needs to be updated to current state. Also needs tests for the bug. Finally:

+++ b/core/modules/language/src/ConfigurableLanguageManager.php
@@ -99,7 +99,7 @@ class ConfigurableLanguageManager extends LanguageManager implements Configurabl
    * @var bool
    */
-  protected $initializing = FALSE;
+  protected $initializing = [];

Type phpdoc should be updated too.

Also, this is protected, so any classes inheriting from this language manager would now get a new type for this variable. Is that a BC change or not? :) How do we consider that now. https://www.drupal.org/core/d8-allowed-changes does not spell out protected members.

snufkin’s picture

Title: Content language detection must be set explicitly to work correctly » When content language detection is different from interface language detection, the detected language is not applied to the rendered content
Issue summary: View changes
FileSize
1.66 KB
  • Fixing the phpdoc annotation for the variable type.
  • Updating issue summary and issue title
timmillwood’s picture

Version: 8.0.x-dev » 8.1.x-dev
Gábor Hojtsy’s picture

Status: Needs review » Needs work
Issue tags: -Needs issue summary update +Needs tests

As I wrote in #27, this needs test coverage for the bug to prove its fixed. Sorry forgot to add the tag.

fran seva’s picture

Assigned: Unassigned » fran seva
pbonnefoi’s picture

Applying the patch fixed the problem for me. Thanks for the good work !

The last submitted patch, 29: content_language-2189267-29-test-only.patch, failed testing.

Status: Needs review » Needs work

The last submitted patch, 29: content_language-2189267-29.patch, failed testing.

jjcarrion’s picture

Patch #24 works fine for me.

@maxocub, you said that didn't work for you, could it be that you have another order in the 'Content language detection'? I have used something like this:

Language detection

Great work all!

maxocub’s picture

Hi @jjcarrion, the settings you show on your screen capture work well even without the patch. What I tried and what I reproduced in the test is what is mentioned in the step to reproduce of the issue summary:

3. Set Detection and selection method to session and browser (tested both, both are broken)

Maybe the issue summary or title should be updated, they are not perfectly clear to me.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

spoit’s picture

Patch #24 fixed it for me too (on 8.2.x)

Without the patch combining Account administration pages language setting (in Interface text) with Content language (in Content language detection ) just does not work.

Gábor Hojtsy’s picture

I think #24 is clearly fixing a bug, since if you call getCurrentLanguage() for the content language, it depends on the interface language, so if the later is not yet negotiated, that is called again, which then is not initialized properly because another language type is already being initialized. So to avoid a recursion, that is not negotiated. But its a different type, so it should be negotiated to be used for the content language. Does that help outline the purpose of #24 @maxocub? Your test does not test that scenario because it disabled the interface language detection on the content language, so the "recursion" of negotiation does not even happen. Not surprising that the patch does not make a difference for your scenario.

dubcanada’s picture

Patch #24 fixes my translation issues as well.

Mojtaba Reyhani’s picture

I added a RTL Language translation File (Like: Persian, Farsi) to my drupal 8 site and What I simply want is to All "Administration Pages language" (or backend Language) in english only and all admin menu Always in left side and frontend pages of the site(Site Language) in another language (Like: persian, Farsi)
I do below setting:

1- I enabled the Language module, and set-up one additional language. Install was done in En (english), and I added Fa (Persian) language.
Language Module Configuration
Language Module Configuration

2- I configure the administration language separate to the content language by below setting:

/admin/config/regional/language/detection:
Account administration pages: enabled

Interface text language Configuration
Interface text language Configuration

3-Admin -> Edit Profile -> Edit(Tab)
Configuration of Administration Language
Configuration of Administration Language

This work properly for all administration page and those are English and in left side (LTR) except the "home page" and "user/1/" and admin/structure/block/demo/'Theme Name' of the site that the administration menu is in Persian Language and in right side (RTL) yet.

Administration Pages
Administration Pages

Home Page
Home Page

Gábor Hojtsy’s picture

@Mojtaba Reyhani: looks like your problem is not related to which language is selected for the page, but how the admin menu is rendered? We have #2313309: Admin toolbar should always be rendered in the admin language (if set) for that, which did not see to have much interest from users so far unfortunately :/

mirsoft’s picture

I was going to write tests for this to proceed further, however during getting through whole story I wasn't able to reproduce the issue anymore (Drupal 8.2.1).

The setting from screenshot #32 provides already correct language translation query parameter "language_content_entity" that determines the correct translation paths to each node's translation:

correct behavior

The issue I found was in case we only select browser and/or session in either settings:

invalid settings

In that case, the "translate" page does not differentiate with any URL:

no link

That actually corresponds with the original ticket description, however does not correspond with the patch in #24 (it actually does not fix this issue).

In a summary, could please somebody explain and/or summarize and update the ticket description and provide clear testing path with exact previous state, exact working patch and exact state that the patch fixes?

yurii_2016’s picture

FileSize
89.99 KB

yes. I do have this issue too! This is hilarious!
asd

it is critical bug, we cannot edit translated content at all! Only language switch helps

blazey’s picture

FileSize
100.52 KB

@yurii_2016 Have you tried checking the box at the bottom of the form and enabling Content Language detection method?

@mirsoft I have also been trying to write a test and my results are similar.

When content language detection is enabled and Content language detection method is chosen everything works fine. Translation forms can be reached via edit links on both /node/{nid}/translations and /admin/content.

The problem starts when all detection methods other than Browser and Session are disabled. This is the case described in #40 but also the one pictured below, when content language detection is disabled completely.

Only Browser and Session detection methods enabled

In this setup translations' Edit buttons are pointing to /node/{nid}/edit and show the node in wrong (default) language. Patch from #24 doesn't help.

I think what we need here is something like Content language detection method enabled all the time under the hood for edit links. There is no way to determine language of edited entity based on Accept-language header sent by editor's browser.

yurii_2016’s picture

FileSize
137.21 KB
113.78 KB

blazey,

same stuff. maybe it is bug of autopath module.. we're on 8.2.0, maybe it was fixed? I don't know.

sa

Another stuff. Tried to change manually language of alias to 'none' - then it shows page in currently selected language for any alias.. other way one of alias'ed page is 'not' found'.

what

regards!

p.s.
I was switched to another project, so I'm not able to dig to D8 for now, but this stuff is critical

Gábor Hojtsy’s picture

@yurii_2016: let's not use this issue as a general support forum, what does the language of path aliases has to do with what language does Drupal pick for editing a node?

yurii_2016’s picture

Gábor Hojtsy,

so far only bug reports are active on useful response (at least for me), drupal answers has no use too. but ok, i'll try to be quiet

about path alias - i think this is related issue, because path alias has this 'language' distinction which MUST be used to load appropriate content, and not be overlapped by user language selection. Or not?! This is what happens in admin panel too (i think).

*e-em, or should try to change order of language negotiation options somehow?

spoit’s picture

While using the patch in #24 is working well for editing entities, it seems to mess up ajax file uploads in an evil way:

Normal ajax callback url:
/nl/node/370/edit?element_parents=gt_main_photo/widget/0&ajax_form=1&_wrapper_format=drupal_ajax

When using the language_content_entity parameter:

/nl/node/370/edit?language_content_entity=nl?element_parents=gt_main_photo/widget/0&language_content_entity=nl&ajax_form=1&_wrapper_format=drupal_ajax

Mind the double"?" which make the ajaxCallback function fail. On the UI side this makes the full widget disappear (since the ajax callback fails to deliver a new one)

danquah’s picture

Seems https://www.drupal.org/node/2772891 is a duplicate of this issue, can anyone confirm, and does it make sense to incorporate any of the work from that issue in to this, or should it just be closed?

mogio_hh’s picture

I also have the problem that twig templates t() function and other elements like yml forms pick up the UI language rather than the content defined or url defined language.

Its so funny that nobody fixes this problem. Seems to me like the whole backend / content language feature makes no sense like this.

Also I recognized that the lang attribute of the html tag shows the default admin language instead of the language that is defined through the url prefix.

Crazy stuff.

mogio_hh’s picture

Can smb confirm issue #46?

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

wannesderoy’s picture

Issue summary: View changes
FileSize
416.33 KB

@mogio_hh I can't confirm the file upload issue. Any image uploading works fine with me.

I can also confirm patch #24 solves the issue as described. When detection & selection settings is set as shown in the attached screenshot and content is added, adding translations doesn't work as it should. With the patch it does.
Wat needs to be done to get this committed in core? Should any tests be updated/written?
screenshot