Language support for Page Manager

Whoa! Didn't use the access function, but the language context is great (and the view integration will save tons of time).

Some comments:

1. I get some whitespace errors: (page-manager-language-support.patch:6: new blank line at EOF., page-manager-language-support.patch:67: new blank line at EOF.)
2. The list of contexts in page manager when adding a new context is destroyed after applying the patch. You only see the group, not the context itself (i.e. User, User, User, User, User, Node, Node, Node, Node, etc.)
3. There's already a language detection function in Drupal. Would it be possible to hook into that? Or is that already included in the Current Language selection?

I think this is an important patch to commit, as it solves Page Views in different languages. I'm not even sure what the current solution is: add multiple translation sets with a view for each language? This is the One Page, One View solution.

Re #2 above: Don't have the Context list bug anymore... Don't know why I was getting a strange list.

So, the patch looks nice, and the context itself works great, but for my use-case, the double context requires me to create a variant for each language. Maybe this is intentional, but all I want is a single pane replaced in the site-template depending on the language, so I would like a version that only required one context, "current language".

Then I add four panes, one with each language settings comparing against the context.

I changed the patch to require only one context, not sure if it's possible to make both options possible within the the same plugin, or if it has to be two separate.

Having to create 2 languages to compare the contexts is awkward.

Ideally you want a rule that accepts one language and then compares that to [is one of this list]. Which is basicaly what the site_language access plugin does right now, but it doesn't actually accept a context.

The question I have is: What do we really buy with a language context?

Things that support language (i.e, entities) can have an access plugin for that thing to test what language it's in. Besides the site and an entity, what else even supports language? That reduces the UX burden by making it much more straightforward. I ask "Is node in the user's language" or something like that, with a single access rule that takes the node.

Are there any circumstances where we want to compare the language between two different entities? That's about the only use-case I can think of for this system, but we already have 'context compare' where we can compare the equality of two contexts. So that particular access rule is redundant.

Has anything regarding language handling changed since? I'm wondering if the following scenario can already be accomplished using just Panels + Beans, or if it needs support added to Panels (the patch above?), or support provided by a separate access plugin:

A panels page for node/% with some entity-translation-enabled Bean blocks (e.g. English and Dutch) placed as panes.
On en/node/1, only English bean blocks are shown;
On nl/node/2 only Beans in Dutch are shown.

I'm adding an argument plugin to this patch.

This is my use-case, if it helps:
I'm building custom administrative pages that need to take a language argument from the URL. Having this context allows me to pass the language code into multiple views on the page, as well as use the tokens provided by the context convert list. I need to have arguments passed into my views (as opposed to using exposed filters) so that my user-facing views can match the same arguments that are used in my draggable-views on the admin pages.

As for the access plugin, I agree that it could use some refining. Actually, I modified the existing site_language plugin to accept a single optional language context, as I think this is a more acceptable approach.

I read in different issues that we always consider the usage of Views. But what if this it not the case?

Let me explain with an example:

I created a page called Video, translated it in three languages so:

node/1 <-- English
node/52 <-- Spanish
node/53 <-- French

And inserted in Panels directly, like "Node".

Then the point is that you have to set a "Context By Node" but it just let you insert a unique entity ID, so if I insert: 1, then is just appearing the English node whatever language is currently. If I set 52 then is just appearing Spanish node whatever language is currently and so on. Should be nice to being able to put 1+52+53 without using Views.

I think it is related "problem" so that's why I exposed here.

Thank you.

This would greatly help Metatag: #1998236: metatags won't show in <head> in panel content types with multi language

This should be tested with both the core Locale module (different node per language) and EntityTranslation (same node, different language).

After trying out #6 I got the following.

Fatal error: Cannot use object of type EntityType as array in sites/all/modules/contrib/ctools/includes/export.inc on line 1058

I rebuilt the registry and cleared the cache and tried again and same differences. It shows up on cache clear.
Removing the patch and clearing the registry removes this error.

Ignore me in #10, I've re-applied the patch, so far so good... will report back if anything horrible happens:)

Combined these two patches to get drush make build working.

My usecase is to have one panelized frontpage with lots of different panel panes. With language context I can now manage the visibility of each pane.

Did small play during latest project and couln't get the site language comparison working at all. Finally we managed to check panel visibility by changing access check:

/**
 * Check for access.
 */
function ctools_site_language_ctools_access_check($conf, $context) {
  global $language_content;

  if (is_array($conf) && array_key_exists('language', $conf)) {
    // Check against current language if configuration exist and the language is the same as current language
    if ($language_content->language === array_search($language_content->language, $conf['language'])) {

      return TRUE;
    }
    else {
      return FALSE;
    }
  }

  return true;
}

Hi, this patch does not work since ctools update to 7.x-1.7 (March,19 2015).

Or is it about the core update 7.35?

Can you upgrade this patch please? I really need it, all my contexts based on this patch are broken.

Ty.

@TD44 It seemed to apply for me on the 1.7 dev branch.

What's the difference between using

• User: Language
• Node: Language
• (hypothetical) Interface: Language,

for example in a pane visibility rules?

Would that be more performant? When User: language does not work?

@kopeboy user language would be the language the user chose in their profile, node language would be the language of a particular node is in (not all pages are nodes).
Interface language is the language the current page is on.

I believe that is correct and mostly go with interface: Language

Usecase: current language context for view panes.
#13 worked nicely. Thanks for the patch.

site_language access plugin does not work when no language context is provided, although it pledges to fallback to request language when that be the case.

This patch fixes this issue.

Thanks lucas, patch in #22 works much better for me.

Ran into an issue when adding a Language context, ajax error due to no language key in the $conf array. This patch resolves that issue.

The 3 year old patch in #22 and the 2 year old patch in #24 do not apply to the latest ctools 7.x-1.x-dev.