Fixed
Project:
Drupal core
Version:
11.x-dev
Component:
language.module
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
20 Feb 2026 at 04:31 UTC
Updated:
28 Apr 2026 at 08:04 UTC
Jump to comment: Most recent
Problem/Motivation
- language_process_language_select
- language_configuration_element_submit
- language_get_default_langcode
- language_negotiation_url_prefixes_update
- language_get_browser_drupal_langcode_mappings
Steps to reproduce
Proposed resolution
Move language_process_language_select to Language hook class
The remaining functions are used in a few places each, need to review and decide if one service or separate locations.
Remaining tasks
User interface changes
Introduced terminology
API changes
Data model changes
Release notes snippet
Issue fork drupal-3574727
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:
- 3574727-deprecate-remaining-language.module
changes, plain diff MR !14947
Comments
Comment #2
nicxvan commentedComment #5
claudiu.cristeaComment #6
claudiu.cristeaComment #7
claudiu.cristeaThis is ready for review. There's still an unanswered question from @Berdir which deserves an answer but I'm not sure I have an opinion
Comment #8
claudiu.cristeaReady for review
Comment #9
nicxvan commentedI think this is almost ready, just need a confirmation from @berdir.
That test is some clever cleanup too!
Comment #10
berdirResolved that, but added some new comments. I think we should consistently deprecate this for D13. Also might be good to get a +1 from our new language.module maintainer here.
Comment #11
penyaskitoA couple of (new) methods names are confusing or we might want to inline them, but IMHO we want to keep diffs here at a minimum. As a middle ground suggesting we make them private before anyone depends on them.
Otherwise no big concerns.
Comment #12
penyaskitoI didn't explicitly comment on it, but AFAIK deprecating for drupal:12.0.0 train has passed, so all should be drupal:13.0.0.
Comment #13
nicxvan commentedHad a discussion in slack about this with @penyaskito about the private bit and the deprecations.
The deprecation versions are consistent with current policies, the functions are all deprecated in 11.4 and removed in 13, the new constructor parameters are deprecated in 11.4 and removed in 12.
As for the private vs protected, I don't think this is the place for private since the goal is specifically to not have them marked as api.
These items are already not api, they are protected, and they are on plugins. for plugins only the name is api and protected methods are not api.
https://www.drupal.org/about/core/policies/core-change-policies/bc-polic...
https://www.drupal.org/about/core/policies/core-change-policies/bc-polic...
I applied the version deprecation suggested in 10, but since it was just a version bump I think I'm still eligible. I don't think we really need that submit handler to be a 13 removal, but I don't think it harms anything to stick around either.
To add a bit more from slack, the reason why @penyaskito wanted private was to add more leeway in refactoring before the next (13) major.
Personally I think private should strongly be restricted to just experimental features, not just for convenience here. If others feel otherwise I think we can discuss it more if necessary.
Link to slack thread: https://drupal.slack.com/archives/C079NQPQUEN/p1775613336644339 (search for this string in the slack app to find it)
Edit, I just remembered I did the initial commit, but that was just one function which had updates and other reviews so I think it's still fine to RTBC here.
Comment #14
penyaskito+1 to the above. Even if we don't agree on the
privatepolicy, this is not the issue for changing that.And the benefits of getting this in outweigh the drawbacks.
Comment #17
alexpottCommitted a0dcfd3 and pushed to main. Thanks!
Committed a204e12 and pushed to 11.x. Thanks!
Resolved conflicts on merge to 11.x as they were simple.