Closed (fixed)
Project:
Language Hierarchy
Version:
7.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
30 Sep 2015 at 09:24 UTC
Updated:
12 Nov 2015 at 11:14 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
steven jones commentedHere's a patch!
Comment #3
james.williamsUnfortunately, whilst the patch may give fallback to variables, the mere presence of the i18n_variable+variable_realm modules breaks the interface string fallbacks that Language Hierarchy provides! Patch to follow in the next week...
Comment #4
james.williamsHere's an updated patch that improves the above issue. The only way to do it within Language Hierarchy itself is to have a low enough module weight so that it acts before i18n_variable on hook_language_init(). However, there are still rogue calls to t() during bootstrap / language initialization that cause problems though, which I'll raise issues against variable module to resolve, since there are cases that cannot be solved within Language Hierarchy (e.g. getting translations for languages other than the current interface language).
Comment #5
james.williamsSorry, I missed a file.
Comment #6
james.williamsOh dear, it gets worse... unfortunately language hierarchy needs to act before i18n_variable for hook_language_init(), but after it for hook_variable_realm_info(), so the changing the module weight isn't sufficient. New approach on the way...
Comment #7
james.williamsRight, here we go, hopefully the last attempt! Good job we have a client that is / will be testing this :-)
I've added a new submodule for integration with i18n_variable, since there are submodules in use for interacting with other i18n/translation modules. The bonus of this is that the base Language Hierarchy module, which needs to act before i18n_variable, can be set to a low enough weight, whilst the submodule can keep a higher weight so it can act after i18n_variable.
Comment #8
steven jones commentedSadly this isn't enough, because in various places, such as
i18n_variable_getthe variable store is retrieved and queried directly.I think we will need to make a clever variable store that can do the hierarchy and use that rather than a custom controller.
Comment #9
steven jones commentedRight, try this.
It's an extension of #7 but I've pushed the cascade down into the realm store, so when it's accessed directly, it can do the lookup.
Comment #10
james.williamsAnd another attempt... this one allows for values from different stores to be accessed within the same page request.
Comment #11
steven jones commentedComment #12
steven jones commentedClearly we need some tests here :)
Comment #13
steven jones commentedAdding a tag so someone at ComputerMinds can pick this up.
Comment #14
james.williamsHere's a version with tests ... however it depends on the test module added in #2596321-9: Empty node titles in content overview (which is why it's guaranteed to fail!).
I don't have time right now to produce a patch with just the tests either, sorry.
Comment #15
steven jones commentedMarking as needs review for the testbot.
Comment #16
steven jones commentedLooks good to me!
Comment #17
james.williamsCommitted!
Comment #20
james.williamsSorry, I misunderstood how testbot would interact with issue status. The test failed because the patch had already been committed! (The test had passed beforehand)