Problem/Motivation

When the language detection is configured to follow the order of

  1. User's selected language
  2. Language from URL

and the site default language matches the language configured by the user, the detection will ignore the first negotiation step.

This is because LanguageNegotiationUser::getLangcode() will return NULL due to the conditional statement in the method:

if (!empty($preferred_langcode) && $preferred_langcode != $default_langcode && isset($languages[$preferred_langcode])) {

(see $preferred_langcode != $default_langcode).

Which prevents the site builder from using a different language to be detected for authenticated vs anonymous users.

Proposed resolution

Remove the check against preferred and default langcodes from the plugin.

CommentFileSizeAuthor
#14 user_language-2726505-14.patch1.11 KBMatt_five
#12 user_language-2726505-12.patch1.11 KBMatt_five
#9 user_language-2726505-9.patch1.11 KBMatt_five
#8 user_language-2726505-4.patch1.11 KBMatt_five
#3 user_language-2726505-3.patch1.03 KBsnufkin
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

snufkin created an issue. See original summary.

snufkin’s picture

snufkin CreditAttribution: snufkin at Acquia commented
Issue summary: View changes
snufkin’s picture

snufkin CreditAttribution: snufkin at Acquia commented
Status: Active » Needs review
FileSize
user_language-2726505-3.patch1.03 KB

Status: Needs review » Needs work

The last submitted patch, 3: user_language-2726505-3.patch, failed testing.

yoruvo’s picture

yoruvo CreditAttribution: yoruvo commented
Priority: Normal » Major
Status: Needs work » Reviewed & tested by the community

I have just applied the above patch and it fixed the following problem for me:

  • Default Language: English
  • Enabled language negotiators: User, Selected language (German)
  • Users with English language selected would still receive German translations

I consider this a fairly critical bugfix, so I've bumped up the priority and changed the status to "reviewed".

catch’s picture

catch
he/him
Primary language English
CreditAttribution: catch at Third and Grove commented
Status: Reviewed & tested by the community » Needs work
Issue tags: +Needs tests

Patch looks fine, but we should have test coverage for this.

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.

Matt_five’s picture

Matt_five CreditAttribution: Matt_five commented
FileSize
user_language-2726505-4.patch1.11 KB

I get the same problem. The patch of @snufkin at #3 work for me.

I support to remove $preferred_langcode != $default_langcode because it destroy the order of language detection. It is very odd to return NULL when user prefer language (valid value e.g. en, fr) is equal to default language (e.g. en, fr).

Then, I study the test coverage.

LanguageUILanguageNegotiationTest fail at followings:
---------------------------------------------------------------------------------------------
1. "Set preferred langcode for user to NULL." at line #230-243
2. "Set preferred langcode for user to unknown language." at line #245-258

The above test case enable the "User's selected language", and expected LanguageNegotiationUser::getLangcode() return Null.

Here is the code of the patch#3.

     // User preference (only for authenticated users).
     if ($this->languageManager && $this->currentUser->isAuthenticated()) {
       $preferred_langcode = $this->currentUser->getPreferredLangcode();
-      $default_langcode = $this->languageManager->getDefaultLanguage()->getId();
       $languages = $this->languageManager->getLanguages();
-      if (!empty($preferred_langcode) && $preferred_langcode != $default_langcode && isset($languages[$preferred_langcode])) {
+      if (!empty($preferred_langcode) && isset($languages[$preferred_langcode])) {
         $langcode = $preferred_langcode;
       }
     }

The function getPreferredLangcode() do have a fall back option. Please check the manual.

8.2.x User.php User::getPreferredLangcode($fallback_to_default = TRUE)

After applying the patch #3, LanguageNegotiationUser::getLangcode() return default value (e.g. en) other than it's own value (null or unknow-value).

I would like to stop the fallback action by 

$preferred_langcode = $this->currentUser->getPreferredLangcode(FALSE);

With this supplement, the return of the Language detection of "User's prefer language" would be totally independent to other detection method. It can ensure "User's prefer language" return valid value OR language Negotiation go into next detection method if user's prefer language is invalid.

Please check the updated patch.

Matt_five’s picture

Matt_five CreditAttribution: Matt_five commented
FileSize
user_language-2726505-9.patch1.11 KB

Please find the updated patch.

Matt_five’s picture

Matt_five CreditAttribution: Matt_five commented
Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch, 9: user_language-2726505-9.patch, failed testing.

Matt_five’s picture

Matt_five CreditAttribution: Matt_five commented
Status: Needs work » Needs review
FileSize
user_language-2726505-12.patch1.11 KB

Please find the updated patch.

Status: Needs review » Needs work

The last submitted patch, 12: user_language-2726505-12.patch, failed testing.

Matt_five’s picture

Matt_five CreditAttribution: Matt_five commented
Status: Needs work » Needs review
FileSize
user_language-2726505-14.patch1.11 KB

Please find the updated patch.

Matt_five’s picture

Matt_five CreditAttribution: Matt_five commented
Issue tags: -Needs tests +Needs Review

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.

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

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

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

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

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

yoruvo’s picture

yoruvo CreditAttribution: yoruvo commented
Status: Needs review » Reviewed & tested by the community
Issue tags: -Needs Review

Patch #14 continues to work like a charm on several production sites.

alexpott’s picture

alexpott
he/they
Primary language English
Location 🇪🇺🌍
CreditAttribution: alexpott at Acro Commerce, Thunder commented
Status: Reviewed & tested by the community » Needs work
Issue tags: +Needs tests

We still need an automated test for this bugfix, as @catch said in #6

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

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

axroth’s picture

axroth CreditAttribution: axroth commented

I propose to close this as the patch seems -somehow- to be contained in 8.6.3 already?!

achton’s picture

achton
Location Denmark
CreditAttribution: achton at Reload commented
Related issues: +#2907546: User's language preference is not applied!

The problem described in this issue was solved independently in another issue: #2907546: User's language preference is not applied! and commited on 2018-09-11 so that it was included in 8.6.2.

The fix was the exact same as in this issue, except that it included tests as well.

So yes, this issue can be closed (presumably as a duplicate of the other).

Version: 8.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

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

Version: 8.9.x-dev » 9.2.x-dev

Drupal 8 is end-of-life as of November 17, 2021. There will not be further changes made to Drupal 8. Bugfixes are now made to the 9.3.x and higher branches only. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

smustgrave’s picture

smustgrave CreditAttribution: smustgrave at Mobomo commented
Status: Needs work » Closed (duplicate)
Issue tags: +Bug Smash Initiative

This came up as a daily target for the bugsmash initiative

As pointed out in #23 this is a duplicate as the fix was committed in another issue. I will move over credit to that issue for
Matt_five
snufkin

For the patches they submitted.