Support from Acquia helps fund testing for Drupal Acquia logo

Comments

webflo’s picture

Status: Active » Postponed
FileSize
853 bytes
gagarine’s picture

Still works and patch apply nicely on 7.x-1.3.

mordek’s picture

i18n 7.x-1.3 working.

codi’s picture

Status: Postponed » Reviewed & tested by the community

Confirmed working in i18n 7.x-1.4 (2012-Feb-05) and context 7.x-3.0-beta2 (2011-Sep-08) with the patch from this issue (comment #1) and http://drupal.org/node/1320864#comment-5249916

wwhurley’s picture

Confirmed working the patch to context in http://drupal.org/node/1320864#comment-5249916. Thanks.

setvik’s picture

Confirmed working here as well. Would be great to get this committed.

webflo’s picture

Status: Reviewed & tested by the community » Fixed

#1320864: Context not respecting block language is fixed. Committed the patch from #1 to 7.x-1.x. Thanks for the reviews.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

GoZ’s picture

Status: Closed (fixed) » Needs review
FileSize
996 bytes

I use Context 7.x-3.0-beta6 and i18n 7.x-1.7.
With i18n_block enabled, I can define 1 or more languages for a block. So if I check english to a block, it shouldn't be displayed on french, deutch or other language.

Unfortunatelly, previous patch only take care of "translatable" option, and not localization.

I join patch to make it possible. This have to be used with patch of this issue http://drupal.org/node/1320864#comment-7003150 on comment #21

dooug’s picture

I also noticed the language specific blocks were showing always.
I applied this patch. This solved the problem.

Jose Reyero’s picture

Status: Needs review » Needs work

The patch may work but really, I don't think it is a good idea to mix features of both modules in that way
(As I see the context side of the patch filters out the blocks using the language added in by i18n_block, right?)

Really, context defines block visibility depending on multiple conditions and i18n does the same only for language. Because this and because of the specific implementation on both sides, these modules are just not compatible.

What I don't understand: Can't you add language conditions using context on top of all the other conditions? If so, why would you need i18n_block for that?

And then if you want a nice UI improvement, just disable i18n_block language visibility when context is enabled.

Would that work?

GoZ’s picture

What I don't understand: Can't you add language conditions using context on top of all the other conditions? If so, why would you need i18n_block for that?

In this way, we should have as many differents contexts by language. If we have 10 differents contexts in default language which take care of other conditions than language to display some localized blocks, we have to duplicate context for each language. So we have Context number * Language number. It can be quickly very heavy.

GoZ’s picture

Issue summary: View changes

...

kristiaanvandeneynde’s picture

Issue summary: View changes
kristiaanvandeneynde’s picture

Status: Needs work » Reviewed & tested by the community

Comment in #12 also makes perfect sense, you don't want to recreate your entire context for every available language. (12 contexts in 5 languages = 60 contexts...)

Jose Reyero’s picture

Status: Reviewed & tested by the community » Needs work

Ok, I got we cannot do it with context but, can we do it without duplicating queries?
This one is invoked twice in some cases: 'SELECT module, delta, language FROM {i18n_block_language}'

Some static caching for the results will do.

kristiaanvandeneynde’s picture

Status: Needs work » Reviewed & tested by the community

That seems to be out of the scope of this issue.

The only reason that query would be run twice is if i18n_block_context_block_info_alter() is run twice. Seeing as the code from #9 isn't being added inside a loop, the double query is not the fault of that patch.

/**
 * Implements hook_context_block_info_alter().
 */
function i18n_block_context_block_info_alter(&$block_info) {
  $theme_key = variable_get('theme_default', 'garland');
  $result = db_select('block')
    ->fields('block', array('module', 'delta', 'i18n_mode'))
    ->condition('theme', $theme_key)
    ->execute();
  foreach ($result as $row) {
    if (isset($block_info["{$row->module}-{$row->delta}"])) {
      $block_info["{$row->module}-{$row->delta}"]->i18n_mode = $row->i18n_mode;
    }
  }

  // CODE FROM PATCH GOES HERE.
}

Setting back to RTBC and another issue for the query caching could be opened afterwards.

Jose Reyero’s picture

Status: Reviewed & tested by the community » Needs work

See i18n_block_block_list_alter().

kristiaanvandeneynde’s picture

You're right, the same query is in two different places.

marcvangend’s picture

Here's a new patch which takes out the SQL query and caches the result. I'm not a big fan of caching the raw database result, but I didn't see a good alternative since both functions process the result differently.

kristiaanvandeneynde’s picture

Looks good, although there may be a need to invalidate the static 'cache' when data is inserted into i18n_block_language.

kristiaanvandeneynde’s picture

FileSize
1.69 KB
672 bytes

This patch broke any website which uses Multiblock because it does not delete entries from {i18n_block_language}. Attached is a patch which protects your site from lingering records.