Page variant by current language

That should be enough

Works fine here - RTBC for me.

+++ b/src/EventSubscriber/CurrentLanguageContext.php
@@ -0,0 +1,63 @@
+    $event->getPageExecutable()->addContext('language', $context);

Unfortunately we just changed PageManagerContextEvent, delete the "Executable" part.

Also please add tests

fixed patch, but looking at \Drupal\Tests\page_manager\Unit\CurrentUserContextTest no idea how to write test properly

We have no mechanism to reuse core context providers yet, but why duplicate their code anyway? We could just do this.
Or make this a more generic issue to reuse all core context providers instead of waiting for #2511568: Create "context stack" service where available contexts can be registered

It would be great to have all core contexts available but please keep scope of language, cos this is a blocker for multilingual sites

+++ b/src/EventSubscriber/CurrentLanguageContext.php
@@ -0,0 +1,61 @@
+    $contexts = $this->currentLanguageContextProvider->getRuntimeContexts([]);
+    foreach ($contexts as $key => $context) {
+      $event->getPage()->addContext($key, $context);
+    }

nice idea, but there's no cache dependencies set...

Taking my suggestions to #2511596: Switch from EventSubscribers to core-style ContextProviders.
Can you explain the differences between the core CurrentLanguageContext and this one?

+++ b/src/EventSubscriber/CurrentLanguageContext.php
@@ -0,0 +1,61 @@
+ * Sets the current language as a context.

Current interface language? Content language? URL language?

i.e. \Drupal\Core\Language\LanguageInterface::TYPE_INTERFACE vs \Drupal\Core\Language\LanguageInterface::TYPE_CONTENT vs \Drupal\Core\Language\LanguageInterface::TYPE_URL

See \Drupal\Core\Cache\Context\LanguagesCacheContext which also needs to make this distinction.

not trying to hyjak the issue, but trying to solve the issue of language and path. please let me know if i should open another issue.

using as is, the path is given for the entire page entity. if 2 variants are created based on language, and a variant is selected based on role/url/content, the path is still fixed to one the one entered for the page. could the variant set the path? it will still be an issue for menus only having 1 path regardless if there is a translation or not, but that is less wok to solve.

still new to d8 so maybe i'm missing something.

Continued from issue#2770653 to get this change request moving.

My patch holds the context class LanguageInterfaceContext event subscriber and loads the language_interface context from the LazyContextRepository.
The patch also contains a unit test for the LanguageInterfaceContext class.

@fluxline. We set the panels page path to a node id (eg: /node/503) and the node is translatable, and the page variant condition based on language (not path). The alias of the node gets requested and the variant gets loaded based on the node. We compose a single wegpage with node content with page variant content this way.

Proper patch file now. Other patch holds wrong paths.

Patch in #18 works for me. Thanks!

And covered with tests

hmm I'm having trouble getting this patch to show up. Applies cleanly, but is not showing up in the selection criteria. Has this been tested on recent head?

This applied and worked for me correctly ^_^.

Additionally recent head is currently the stable tag 1.0-alpha4.

Possible to check again?

patch applies cleanly and works

Clean-up code to follow code styles
Btw this issue should wait for #2511596: Switch from EventSubscribers to core-style ContextProviders

I've been using this in production for a while and it works well. Because #2511596: Switch from EventSubscribers to core-style ContextProviders is fairly stalled, gonna commit this now.

linking