Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Translatable blocks and context is not possible atm.
Related issue in Context issue queue: #1320864: Context not respecting block language.
Comment | File | Size | Author |
---|---|---|---|
#21 | interdiff-21-19.txt | 672 bytes | kristiaanvandeneynde |
#21 | i18n-1343044-21.patch | 1.69 KB | kristiaanvandeneynde |
Comments
Comment #1
webflo CreditAttribution: webflo commentedComment #2
gagarine CreditAttribution: gagarine commentedStill works and patch apply nicely on 7.x-1.3.
Comment #3
mordek CreditAttribution: mordek commentedi18n 7.x-1.3 working.
Comment #4
codi CreditAttribution: codi commentedConfirmed 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
Comment #5
wwhurley CreditAttribution: wwhurley commentedConfirmed working the patch to context in http://drupal.org/node/1320864#comment-5249916. Thanks.
Comment #6
setvik CreditAttribution: setvik commentedConfirmed working here as well. Would be great to get this committed.
Comment #7
webflo CreditAttribution: webflo commented#1320864: Context not respecting block language is fixed. Committed the patch from #1 to 7.x-1.x. Thanks for the reviews.
Comment #9
GoZ CreditAttribution: GoZ commentedI 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
Comment #10
dooug CreditAttribution: dooug commentedI also noticed the language specific blocks were showing always.
I applied this patch. This solved the problem.
Comment #11
Jose Reyero CreditAttribution: Jose Reyero commentedThe 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?
Comment #12
GoZ CreditAttribution: GoZ commentedIn 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.
Comment #12.0
GoZ CreditAttribution: GoZ commented...
Comment #13
kristiaanvandeneyndePatch in #9 works perfectly with #1320864-28: Context not respecting block language
Comment #14
kristiaanvandeneyndeComment 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...)
Comment #15
Jose Reyero CreditAttribution: Jose Reyero commentedOk, 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.
Comment #16
kristiaanvandeneyndeThat 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.
Setting back to RTBC and another issue for the query caching could be opened afterwards.
Comment #17
Jose Reyero CreditAttribution: Jose Reyero commentedSee i18n_block_block_list_alter().
Comment #18
kristiaanvandeneyndeYou're right, the same query is in two different places.
Comment #19
marcvangendHere'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.
Comment #20
kristiaanvandeneyndeLooks good, although there may be a need to invalidate the static 'cache' when data is inserted into i18n_block_language.
Comment #21
kristiaanvandeneyndeThis 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.