Problem/Motivation

When CSS/JS aggregation enabled, views screen can't be switched to another language after upgrading from 9.5.11 to 10.1.7.
Could you take a look at this?

Steps to reproduce

1.Go to Configuration > Development, turn on "Aggregate CSS files" or "Aggregate JavaScript files".
2.Create an English content and views, create another language (e.g. Japanese) content and views.
3.Show views screen for English contents.
4.In address bar of web browser, replace "en" of language code with other language code (e.g. "ja").
5.The views screen for English contents remains unchanged. (The views screen means the views table and other blocks (e.g. menu bar of superfish).)

Go to Configuration > Development, turn off both of "Aggregate CSS files" and "Aggregate JavaScript files", views screen can be switched to another language successfully.

Comments

kubokura created an issue. See original summary.

sandeepsingh199’s picture

Hi @kubokura, I have tried in my local with Drupal 10.1 but not able to replicate. Can you add some screenshots or short video.

lendude’s picture

Status: Active » Postponed (maintainer needs more info)
Issue tags: +Needs steps to reproduce

And if possible some steps to reproduce this on a clean Drupal install. Just tried this on a clean Umami install and switching from /en to /es and that seems to work fine

kubokura’s picture

StatusFileSize
new2.16 KB
new2.26 KB

Thank you for your response. The previous reproduce steps are too rough, sorry for that. Here are detail reproduce steps. (I can't prepare clean install environment of Drupal 10.1 at this moment.)

Steps to reproduce
1.Login as an administrator, go to Configuration > Development, turn on "Aggregate CSS files" or "Aggregate JavaScript files".

2.Go to Content, click Add content, click Basic page, and create two contents.
- English content
Title: 2023/12/15 (en)
Language: English

- Another language (e.g. Japanese) content
Title: 2023/12/15 (ja)
Language: Japanese

3.Go to Structure > Views, click Add view, and create a view.
- View name: Basic page list
- Views settings: Show "Content" of type: "Basic page" sorted by: "Newest first"
- Page settings:
-- Create a page: checked
-- Page title: Basic page list
-- Path: basic-page-list
-- Page display settings - Display format: Table
Save the view.

4."Basic page list (Content)" page appears, specify Fields and Filter criteria;
- at Fields, add "Original language" of "Content".
- at Filter criteria, add "Original language" of "Content", select "Is one of" for Operator, select "Interface text language selected for page" for Language.
Save "Basic page list (Content)".

5.Click Translate view tab, add another language (e.g. Japanese).
"Edit Japanese translation for Basic page list view" appears, specify as follows;
- Displays > Default Display settings > Basic page list Default display options > Fields
-- at Title Views entity field handler, enter "TAITORU" in "Create a label" field.
-- at Original language Views entity field handler, enter "GENGO" in "Create a label" field.

6.Go to /en/basic-page-list, "2023/12/15 (en)" appears in the table, and "Title" and "Original language" appears at the table header.
(See basic-page-list.png.)

7.In address bar of web browser, replace "en" of language code with other language code (e.g. "ja").

8."2023/12/15 (en)", "Title" and "Original language" remain unchanged.

Expected behavior
"2023/12/15 (ja)" appears in the table, and "TAITORU" and "GENGO" appears at the table header.
(See basic-page-list(expected).png.)

best regards,

kubokura’s picture

StatusFileSize
new13.92 KB
new13.06 KB

Hi, I have noticed the symptom also occurred on user profile screen. I'm sorry for noticing it late. Here are the reproduce steps.
Steps to reproduce
1.Login as an administrator, go to Configuration > Development, turn on "Aggregate CSS files" or "Aggregate JavaScript files", and logout.
2.Login as a user, go to user profile screen (go to /en/user/nnn). (See user_profile.png.)
3.In address bar of web browser, replace "en" of language code with other language code (e.g. "ja").
4.The English screen remains unchanged.

Expected behavior
The other language (e.g. Japanese) screen appears. (See user_profile(expected).png.)

best regards,

joseph.olstad’s picture

this might have been caused by a bad release of facets_pretty_paths
I published a new release of facets_pretty_paths that fixes a similar type of problem that is described. There was a regression that was fixed.

kubokura’s picture

Hi, @joseph.olstad, thank you for your comment. In my case, the website is not using facets_pretty_paths module.
Hi, @SandeepSingh199, it seems if CSS/JS cache is existing, the symptom may not occur.

Steps to reproduce
1.Start web browser (e.g. Chrome, Firefox), login as an administrator, go to Configuration > Development > Performance, turn off "Aggregate CSS files" and "Aggregate JavaScript files", and save configuration in order to clear CSS/JS cache under private/drupal-sites-default/files.

2.Turn on "Aggregate CSS files" or "Aggregate JavaScript files", save configuration, and logout.

3.End web browser, restart web browser, login as a user, go to user profile screen (go to /en/user/nnn). (See user_profile.png.)

4.In address bar of web browser, replace "en" of language code with other language code (e.g. "ja").

5.The English screen remains unchanged. [reproduced]

6.End web browser, restart web browser, login as a user, go to user profile screen (go to /en/user/nnn).

7.In address bar of web browser, replace "en" of language code with other language code (e.g. "ja").

8.The other language (e.g. Japanese) screen appears. [not reproduced]

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

acbramley’s picture

Issue tags: +Bug Smash Initiative

I tried reproducing #4 using the Umami profile and was able to reproduce what is described, however changing aggregation settings did not "fix" it at all.

I have never used these Translate view settings, but it seems likely there's a bug in there?

I noticed if I changed the Filter to use "Content language for selected page" instead of "Interface text language selected for page" it correctly displayed the english or spanish nodes depending on the path prefix, but the field labels never changed.

Even overriding the view label in the translation doesn't seem to work.

catch’s picture

Title: Views screen can't be switched to another language in multilingual site due to CSS/JS aggregation of Drupal 10.1 » Views screen can't be switched to another language in multilingual site
smustgrave’s picture

Wanted to bump 1 more time if still experiencing this in D11?

kubokura’s picture

Hi, I still can reproduce the issue on my website of Drupal 10.5.4. However, I can't reproduce it using the simplytest of Drupal 10.5.4.
The cause might be contributed modules my website using.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.

mohit_aghera’s picture

StatusFileSize
new164.05 KB

I came across this issue while doing a bugsmash traige.

I feel this looks like a configuration issue in the language negotiator plugins.
I don't any weightage screenshot/info about language negotiation plugins in steps to reproduce.

By default in umami it is as per following screenshot.
language negotiation plugin settings umami

Here if we see, User - Follow the user's language preference. is taking precedance.

I checked the plugin code and it we haven't defined any language, it takes default language (en)
https://git.drupalcode.org/project/drupal/-/blob/main/core/modules/user/..., and getPreferredLanguage method in AccountProxy is like

  public function getPreferredLangcode($fallback_to_default = TRUE) {
    return $this->getAccount()->getPreferredLangcode($fallback_to_default);
  }

Hence, it always returns 'en', which is default language.

Now, if we want to fix it, we should either change following things:
1. Update "Interface text language detection" plugins and ensure "URL" plugin is before anything. So it considers the lang-code from URL.
OR
2. Update view and in filter, change the language negotiation plugin to "Content language selected for page"
Things to note for second option - it will just update the content language only. Interface will remain as it is.

If we want truly flexible, we can spin up a new negotiation plugin for interface language and content language that considers both the scenarios.

@kubokura please let me know if this helps!

Happy to help you further.

kubokura’s picture

Hi, mohit_aghera, your advice #1 works for me. Now I can turn on "Aggregate CSS files" and "Aggregate JavaScript files" on my website (Drupal 11.3.3). Thank you so much for your information.

>1. Update "Interface text language detection" plugins and ensure "URL" plugin is before anything. So it considers the lang-code from URL.

Go to /admin/config/regional/language/detection, rearrange methods as below;
--Before--
Session
URL
Browser
--After--
URL
Session
Browser

lendude’s picture

Based on #14 this issue summary needs a bit of a rewrite and a new title!

smustgrave’s picture

Status: Postponed (maintainer needs more info) » Needs work
Issue tags: +Needs title update

Seems like this is still a bug but don't feel comfortable closing it at least.