Currently we have two modules for this, see #1559970: Battle plan / Progress
- variable_realm_union, that eventually should become part of variable module.
- domain_i18n_variable, which defines a mixed (domain x language) realm.

There are multiple things to consider: how variables are selected, how variable overrides are done, how to build the UI, and whether we really need all these modules or the features can be added to the other modules. These are just some thoughts about that.

Two options to consider:

A. Having a single realm (domainxlanguage) with as many keys as domain x language. It would replace domain and language realms and could use the already built UI.
Pros: simple implementation, almost done.
Cons: Overcrowded UI and a lot of work for the admin since we need a value for each variable for each domain for each language.

B. Having 3 realms: domain, language, domainxlanguage and variables defined to belong to each of them.
Q: Should we allow a variable to 'belong' to more than one realm?
Pros: More flexible, less work for the site maintainer once defined.
Cons: More complex everything, from the implementation to the UI to being able to understand which variable value is used where.

Example case: Two domains (example1.com, example2.com), two languages (en, es).
- variable1 is configurable per domain
- variable2 is configurable per language
- variable3 is configurable per domain and language.

The first two are pretty simple though if they show up in the same form it may be confusing as the same form needs to have a language and a domain selector but it doesn't change all the variables in the form. They have two values each.
The third one, variable3 has 2 x 2 = 4 possible values. The configuration form for it needs selecting language and domain. It may be confusing too if mixed with other variables.

For building the variable array it should be easy on each case so the critical part seems to be the UI. How can we make it somehow usable?

CommentFileSizeAuthor
#6 variable_realm_union.png50.02 KBjose reyero

Comments

bforchhammer’s picture

bforchhammer commented

The realm union module implements the 2nd case (I think).

  • Variables only ever belong to one realm. domainxlanguage automatically contains all variables which are defined in both domain and language (and removes them from domain and language).
  • UI annotates variables in domainxlanguage realm as being "multilingual domain variables".
  • UI shows one language switcher and one domain switcher (no switcher for domainxlanguage).
  • Realm Admin shows overview of "configured variables" and "actual variables" (see "site slogan" in screenshot).
jose reyero’s picture

jose reyero commented

Yes, this makes sense.

About variable_realm_union, I think we better implement everything for now on 'domain_i18n' (can we make the name 'domain_i18n_variable' shorter?) and later we see what part of the code would be generic and reusable enough.

For selecting the variable list, then I guess we should use some hook of the ones you had for variable_realm_admin, addapted for variable_realm, which takes out the common variables from (language, domain). I'll look into adding this hook.

jose reyero’s picture

jose reyero commented

Added hook_variable_realm_variable_list_alter() in variable_realm module.

Then about switching the realms, I think we could act on hook_variable_realm_switch(), which is already working and then, if we have both a language and a domain, set the proper 'domain_language' realm.

bforchhammer’s picture

bforchhammer commented

Added hook_variable_realm_variable_list_alter() in variable_realm module.

Hmm, if we remove shared variables from the variable list using that hook they will also disappear from the settings page; i.e. to the user it will look like as if a variable is not multilingual anymore, even though it's just been moved to "multilingual + domain". That's why I only modified the low-level list of variables in my first patch... ideas?

jose reyero’s picture

jose reyero commented

Right. If you see latest changes in variable_realm API, I think we don't need this hook anymore (to be removed?)

jose reyero’s picture

jose reyero commented
StatusFileSize
new variable_realm_union.png50.02 KB

Improved variable_realm and variable_realm_union. It handles almost everything automatically.

Main changes:
- Union realms are declared now on hook_variable_realm_controller() because we may need them earlier in the bootstrap (for hook_variable_realm_switch() to work).
- Since variable and key lists are handled now with a callback function, we can build these lists dinamically. Actually variable_realm_union will handle it all (grabs variables defined by the two united realms).
- Added some more meta in hook_variable_realm_info(), like the 'form switcher' property so we don't provide switchers for union realms.

Attached screenshot, almost everything seems to be working now.
(Still this needs some testing).

Next steps:
- I think we are ok to move variable_realm_union to variable module.
- Most of domain_variable_i18n can be dropped as it is handled now by variable_realm_union.

I'll be on the drupal-i18n channel, I think we need to talk about this and future module maintanership.

bforchhammer’s picture

bforchhammer commented

One ToDo: Union module needs to make sure that realm switchers are shown for all subrealms (at the moment, there are no switchers if all variables are in the union).

jose reyero’s picture

jose reyero commented

Good point. Fixed :-)

bforchhammer’s picture

bforchhammer commented

Sometimes I get these notices (e.g. after saving); some of them multiple times:

  • Notice: Undefined variable: realm_keys in variable_realm_union_variable_realm_params_alter() (line 83 of sites\all\modules\variable\variable_realm_union\variable_realm_union.module).
  • Notice: Undefined index: default key in variable_realm_variable_settings_form_submit() (line 249 of sites\all\modules\variable\variable_realm\variable_realm.form.inc).
  • Notice: Undefined index: default key in variable_realm_form_key_current() (line 170 of sites\all\modules\variable\variable_realm\variable_realm.form.inc).

And as mentioned in a different issue: realm switcher values are lost during save, and I get redirected to a form with different values (see #1567232-6: API improvements for Variable Realm.).

Edit: added another notice

bforchhammer’s picture

bforchhammer commented

I haven't tried it out, but what happens when you turn a "language variable" into a "domain+language variable"? Are existing multilingual values kept? If not, we should probably figure out a way to copy language values to the combined realm, and clean up the variable store...

Similar issue the other way around (domain+language -> language only); in this case maybe keep the "default realm key" value?

Edit: Hm, should we move this issue (or create a new one), now that the union has been moved to the variable module?

jose reyero’s picture

jose reyero commented
Status: Active » Fixed

This is how it works (should work):
When you remove a variable from the 'realm', the value for that realm is deleted on the db.
But when you add it to a new realm, old value is kept, though overriden by the value in the new realm it it has a higher weight.

And yes, I think it's time we close this one and start opening specific issues for the right modules.

Status: Fixed » Closed (fixed)

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