#D8MI

Hello,
Tested and verified patch applied successfully.
but its not working as expected
attaching screenshots

Upgrade path for schema and deprecations bumped to 11.2.x

Removed the needs test tag, and used a more appropriate title.

This still applies, however, core has been merged recently and I did that too instead of a rebase, with almost 60 commits, a rebase would be a ton of work. One option would be to squash it together into a single commit and force push that, I did that in a different issue.

Rebased for 11.x, adding support for the 📌 [ignore] Convert everything everywhere all at once Active work.

Version of the patch still using the procedural approach is available here for reference purposes.

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. 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.

Seems issue summary is good. Update the code against latest head.

nicoschi → changed the visibility of the branch 2546212-entity-viewform-mode-10.3.x to active.

Believe upgrade path is still needed.

Also deprecations probably have to be bumped to 11.2.x

Merged and moved the new hooks to the new Hook class. Would be good if someone could double check that.

Updated and created a merge request.

I recently discussed thie with catch.

Using the header and vary on that is very dangerous for cache purposes. It will make very very many variations, which results in bad caching and performance. Not to mention possible memroy issues in caches or high cache trashing.

We did think about how we could possible work around that.

What if;

We normalize the prermutation of the language into the resulting language, and cache that normalization and the resulting language.

So perhaps a site with en_EN and fr_FR. A browser comes along and tells the site "Hi i'm en-GB,en-US;q=0.9,en;q=0.8". The site would find out what this will end up as so

en-GB,en-US;q=0.9,en;q=0.8 magic => en_EN, we cache this and threat serve cache asif en_EN. This would mean (at least on the drupal side) only the records for inLang => outLang exist, which are pretty small and we dont end up with loads of difference permutations.

Not entirely sure how we would implement that, but feels like a way to have drupal cache be happy.

The little devil on my shoulder also has a voice though. Which does tell me this is kinda a. can of worms as this could also easily break caching on the caches in front of Drupal, be it varnisch or maybe smoething like cloudflare. That is kinda the scary part. Perhaps contrib is better to have this live, instead of trying to get this into core.

gitlab shows that there is a conflict in .module file, please rebase and fix

Added context and language manager whereever needed. Tests are now green