Comments

Steven Jones created an issue. See original summary.

steven jones’s picture

Status: Active » Needs review
StatusFileSize
new3 KB

Here's a patch!

james.williams’s picture

Unfortunately, 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...

james.williams’s picture

Here'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).

james.williams’s picture

StatusFileSize
new3.91 KB

Sorry, I missed a file.

james.williams’s picture

Status: Needs review » Needs work

Oh 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...

james.williams’s picture

Status: Needs work » Needs review
StatusFileSize
new4.5 KB

Right, 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.

steven jones’s picture

Assigned: Unassigned » steven jones
Status: Needs review » Needs work

Sadly this isn't enough, because in various places, such as i18n_variable_get the 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.

steven jones’s picture

Status: Needs work » Needs review
StatusFileSize
new6.19 KB

Right, 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.

james.williams’s picture

And another attempt... this one allows for values from different stores to be accessed within the same page request.

steven jones’s picture

Issue tags: +Needs tests, +Badly needs tests
steven jones’s picture

Status: Needs review » Needs work

Clearly we need some tests here :)

steven jones’s picture

Issue tags: +ComputerMinds

Adding a tag so someone at ComputerMinds can pick this up.

james.williams’s picture

Here'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.

steven jones’s picture

Assigned: steven jones » Unassigned
Status: Needs work » Needs review
Issue tags: -Needs tests, -Badly needs tests

Marking as needs review for the testbot.

steven jones’s picture

Status: Needs review » Reviewed & tested by the community

Looks good to me!

james.williams’s picture

Status: Reviewed & tested by the community » Fixed

Committed!

Status: Fixed » Needs work

The last submitted patch, 14: language-hierarchy-2577439-14-i18n_variable.patch, failed testing.

james.williams’s picture

Status: Needs work » Fixed

Sorry, I misunderstood how testbot would interact with issue status. The test failed because the patch had already been committed! (The test had passed beforehand)

Status: Fixed » Closed (fixed)

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