I know you're working on the UI. This is more to let you know I'm ready to test and am following.
Trying the sandbox project domain_variable with the latest variable module (7.x-1.1+19-dev). The scenario is multiple languages per domain. We limit it to the slogan for now, set at admin/config/regional/i18n/variable.
Steps followed:
On the default domain (ID 1).
- At admin/config/system/site-information it says at the top THERE ARE MULTILINGUAL VARIABLES IN THIS FORM. The slogan field is indicated as multilingual variable. A language can be selected.
- Going back to admin/config/system/site-information we set a slogan for the default language. Save.
- We select another language from the top of the form and fill in the translated slogan. Save.
- A message at the top says:
- The configuration options have been saved.
- Primary domain settings updated.The configuration options have been saved.
- The actual slogan field turned back to display the default language slogan. No translated slogan appears in the other languages.
At admin/structure/domain/view/[domain ID]/config no slogan field shows.
admin/config/system/variable/edit/domain_variable_conf and admin/config/system/variable/edit/domain_variable_list are both empty.
No slogan can be set per domain and they are not translatable.
Thanks for your efforts.
Comments
Comment #1
bforchhammer commentedStill very much a work in progress, but the "7-x.1-x.-generalized" branch now contains code which successfully turns the page slogan into a "multilingual domain variable"... See #1559970-6: Battle plan / Progress.
Comment #2
bforchhammer commentedThis is now possible with the latest versions of variable 7.x-2.x and i18n:
admin/config/regional/i18n/variableadmin/structure/domain/variablesTesting and feedback appreciated :)
Note that some variables (e.g. language_default, site_name; see issue queue) don't work yet, and there is also no migration path from the domain_conf module yet (see #1593548: Migration path from domain_conf).
Comment #3
lolandese commentedIn sites/all/modules/i18n/i18n_variable/i18n_variable.info I had to remove the version behind the dependencies of variable_realm and variable_store. That solved the issue below.
update.php -> Requirements problem
Unresolved dependency Variable store (Version 7.x-2.x required)
Variable translation requires this module and version. Currently using Variable store version 2.x-dev
Unresolved dependency Variable realm (Version 7.x-2.x required)
Variable translation requires this module and version. Currently using Variable realm version 2.x-dev
I will report other issues as I find them.
Thanks.
Comment #4
lolandese commentedOn a new Drupal install it all went smooth. You can ignore my previous post that resulted from an existing install.
It worked as expected. The UI is clear having only the usual admin/config/system/site-information and not also a coexisting admin/structure/domain/view/[domain-ID]/config with partially the same data.
Adding the slogan of a domain, after saving it says:
Primary domain settings updated.
That made me think it changed the settings on the default domain. Maybe better Domain settings updated or second.domain.com settings updated.
It's great to see that three mainstream modules got an improvement. Domain Access, Variable and Internationalization (i18n). Contrib modules should declare their variables to have them translatable. With the improved UI it is mature now.
Thanks a lot. I follow the progress and will post any issues I find. Closing this one. Slogan can now be set per domain and they are translatable.
Comment #5
bforchhammer commentedThanks for testing :-)
I think this message only shows up when you use a git checkout, because then the respective module
.infofiles will not contain a "version" string which is required for the dependency check. As long as you work with tarballs downloaded from project pages, that message should not show up...We actually don't show a message at all, so this must still come from the domain module... Not sure where from exactly, possibly the code which is responsible for updading the site-name; that would be resolved with #1593558: Support site_name variable and #1550762: Separate domain name and site name. If not we'll have to investigate further at some point.
Comment #6
lolandese commentedCross-posted an extraction in the module's documentation at http://drupal.org/node/1856952
Comment #7
knalstaaf commented@lolandese:
I've added an extra step: #2757871: Undefined index: site_name in domain_form_sitename_submit