Problem/Motivation
Entities with language set to 'Not specified' or 'Not applicable' are linked, when done through a StringFormatter, to the default language. Following such a link can change the UI language, which is not expected by the end user.
Steps to reproduce
- Install a clean Drupal site and make sure that "Language" module is enabled.
- Add a second language at
/admin/config/regional/language. - Configure URL negotiation at
/admin/config/regional/language/detection, make sure "URL" is enabled. - Configure a URL prefix for the second language at
/admin/config/regional/language/detection/url - Go to the "Frontpage" view and edit the filter criterion
Content: Translation language (= Content language selected for page)enabling the options "Not specified" and "Not applicable". Save the view. - Add a simple text field to the article content type and configure its "teaser" view mode to show it as a link it to the entity.
- Create a new article with the language set as "Not specified" and fill a value in the new textfield.
- Navigate to to the front page in the second language (for example, navigate to
/esif your second language was Spanish) - Check that the link in the simple field value of the new article points to the article in the default site language (English) instead of the current language (your second language).
Proposed solution/idea
Links to entities with language 'Not specified' or 'Not applicable' should default to the current UI language.
Remaining tasks
Fix. DoneTests. Done
User interface changes
Now the links pointing to entities with language "Not specified" or "Not applicable", and printed through a StringFormatter, point to the entity in the current UI language instead of the default site language.
Introduced terminology
None
API changes
None
Data model changes
None
Release notes snippet
None
Original report by @aleksip
Entities with language set to 'Not specified' or 'Not applicable' are linked to the default language. Following such a link can change the UI language, which is not expected by the end user.
| Comment | File | Size | Author |
|---|---|---|---|
| #33 | 2991440-nr-bot.txt | 1.84 KB | needs-review-queue-bot |
Issue fork drupal-2991440
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
aleksipHere is a patch with a proposed fix.
Comment #3
aleksipOuch. Well, let's just use
\Drupal::languageManager()and make all the required changes if this is considered a good idea in the first place.Comment #4
aleksipComment #6
markdatter commentedAny chance that this will be fixed and implemented in Drupal 8.8?
Comment #9
marksmith commentedThis is still an issue in Drupal 9.
Comment #10
anushrikumari commentedRerolled #3
Comment #11
vdsh commentedrerolled for Drupal v9.x
Comment #15
ranjith_kumar_k_u commentedRerolled #11 for 9.5
Comment #17
smustgrave commentedThis issue is being reviewed by the kind folks in Slack, #needs-review-queue-initiative. We are working to keep the size of Needs Review queue [2700+ issues] to around 400 (1 month or less), following Review a patch or merge request as a guide.
As a bug this will need a test case
Did not review or test.
Comment #19
kimlop commentedPatch #15 fails when applied to core 10.4.0
Comment #22
oily commentedI came across this closed issue which looks similar. We need to reproduce on Drupal 11.x to see if it has already been fixed.
Comment #24
vidorado commentedFixed a couple of things and added a unit test covering the case :)
Comment #25
oily commentedRemoved 'Needs tests' tag as a unit test is in place.
The 'test-only' job fails as it should. A failing test is in place. Pipeline all green.
Comment #27
smustgrave commentedFeedback in MR seems legit.
Wonder if we have to worry about backwards compatibility and add a trigger_error
Comment #28
vidorado commented@smustgrave, could you explain better what do you mean by backwards compatibility and in which case should we trigger an error?
Comment #29
vidorado commentedTrying to get feedback
Comment #30
oily commentedRE: #28 @vidorado Your changes to the code comments definitely makes their meaning clearer. RE: #27, the question could be raised in the Slack #core-development channel.
Comment #31
smustgrave commentedFeedback for this one appears to be addressed.
Comment #32
oily commentedThe comments seem clearer now in line with recommendations.
Comment #33
needs-review-queue-bot commentedThe Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".
This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.
Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.