Beta phase evaluation
Issue priority | Major because contributed project blocker. |
---|---|
Disruption | Zero disruption. Docs, cleanup, no API change. (Could theoretically be viewed as an API addition.) |
Problem/Motivation
To e.g. implement an alternative page cache that supports language negotiation, you need to know some things without instantiating the config system and other services:
- the default language (already a container parameter in core:
language.default_values
) - whether the site is multilingual
- the supported (interface) languages
- the langcode mappings
Proposed resolution
- Also turn 2, 3 and 4 in container parameters, similar to
language.default_values
. - Document
langcode.default_values
.
Remaining tasks
Review.
User interface changes
None.
API changes
None, only container parameters added.
Comment | File | Size | Author |
---|---|---|---|
#1 | 2424309-1.patch | 6.91 KB | Wim Leers |
Comments
Comment #1
Wim LeersComment #2
Wim LeersComment #3
Wim Leersd.o--
Comment #4
Gábor HojtsyHow does language mappings for example help with an alternate cache backend?
Comment #5
Wim LeersComment #6
Wim Leers#4: note that the usefulness of these container parameter is not limited to alternative page cache implementations — these are useful to any module/service doing anything language-related.
And how the langcode mappings in specific can be useful: because they indicate the list of available interface translation languages, and hence the list of interface languages that can be negotiated to.
Comment #7
Gábor HojtsyI am not sure you use the term language mappings the same way Drupal core uses them (which is a mapping an arbitrary list of browser language codes to an arbitrary list of possible configured languages that may or may not be configured on the site).
Comment #8
Wim LeersOh, sorry, I mixed up "supported langcodes" and "langcode mappings" in #6. You're right.
The langcode mappings are necessary for alternative response caching services that need to determine a CID and support
Accept-Language
-based language negotiation. The only other way to get at this information, is to initialize the config system, even though these mappings change very rarely.Comment #9
BerdirWe're not actually using this yet, right?
We've tried quite hard to limit the need to have a container rebuild only when you make the switch from 1 to N languages. This would mean that we would need to do this any time we enable or remove a language and possibly even more configuration changes.
We definitely don't do that yet, and I guess the only reason you don't have any fails is that you're not actually using those values yet.
Comment #10
Wim LeersWe do! We rebuild the container in several cases for i18n purposeses:
\Drupal\language\EventSubscriber\ConfigSubscriber::onConfigSave()
— this is where we set the one container parameter that already is being set in HEAD.\Drupal\language\Entity\ConfigurableLanguage::postSave()
(when going from single language to multiple languages)\Drupal\language\Entity\ConfigurableLanguage::postDelete()
(vice versa)Otherwise I'd never propose this in the first place.
Comment #11
BerdirRight, so it is one more case than I meant (changing the default language), but you said yourself that we only rebuild when switching into/away from multilingual.
Storing the list of languages, means we also need to invalidate on the third, fourth, .. language that we add. And *that* we don't do yet, that's what I meant.
Comment #12
Wim LeersRight.
Comment #15
Wim LeersThis is basically choosing between:
That's the trade-off we must make.
I face a similar choice over at #2708771-8: Port SEO (duplicate content prevention) to 8.x-3.x.
Comment #16
Wim Leers