Updated: Comment #0
Problem/Motivation
In #1862202: Objectify the language system the following arguments were raised:
- I wonder whether we really need to repeat the term "Language" in 90% of all methods on classes that are named
LanguageManager
already?- "default locked languages" requires one to understand what Drupal understands under that term. Wasn't there a formal expression for these linguistic/language codes à la "universal languages" or "non-linguistic languages" or similar?
UserAgent::getLangcode()
does not really encompass what this method is doing. It's rather aUserAgent::getBestMatchingLangcode()
or similar.- It's not clear to me what a "selected language" is. Given the implementation, this rather seems to be a "negotiation fallback to a statically configured language"?
- [The parent issue] introduced some major inconsistencies between
LanguageNegotiation
vs.LanguageNegotiator
namespaces and class names, both within plugins but also outside of plugins... The change to "negotiator" for plugins makes sense to me, but let's make sure that the whole shebang makes sense (in that follow-up) :-)- All of the constants in the language classes/interfaces (including
STATE_…
) are poorly named, because they (1) require one to understand deep internals and (2) do not map at all to their intended purpose/meaning.
Proposed resolution
Rename classes, methods and constants to something more appropriate.
Remaining tasks
- Evaluate whether it would make more sense to split this into smaller issues.
- Agree on a solution.
User interface changes
None
API changes
TBD
Comment | File | Size | Author |
---|---|---|---|
#4 | lang.name_.4.patch | 49.8 KB | sun |
Comments
Comment #1
plachCopying my answer to bullet #2 from #1862202-353: Objectify the language system:
Comment #2
plachComment #3
tim.plunkettComment #4
sunAttached patch performs the following clean-ups and adjustments:
Comment #6
plachIt would really be better to have this sorted out before beta (actually this sounds beta deadline-ish to me). I will try to review this ASAP.
Comment #7
xjmThis issue was marked as a beta target for the 8.0.x beta, but is not applicable as an 8.1.x beta target, so untagging.
I've moved the issue to 8.2.x since it could be possible to implement this with BC in a minor.
Comment #18
andypost