Domain names and Internationalization

I do not understand that feature request, and closed it because it was never fully explained.

What exactly do you need that is not currently provided?

Do you know what is missing from the code to allow you to do what you want?

I suspect we would have to write something specific for this use. Is there an i18n function we can tie into?

Domain Conf does that already. Just enable it and read the instructions.

I ran into the same problem... Domain Conf didn't quite work in my case, because it overwrote any localized i18n-variables I had defined.

I ended up disabling Domain Conf, prefixing the i18n_variables table in the database and defining all site variables as multilinugal ones (by adding them to $conf['i18n_variables'], as described here). Now I have to swap the domain to set my site settings for each domain and I don't have that nice bulk update feature, but I can set them in multiple languages for all domains.

Well, what no one has been able to explain is "what feature do you actually need?"

In particular, are the string values the same on all domains, or sensitive to the current domain? For example, you have an English (en), German (de), and Spanish (es) site running on the domains:

- en.example.com -- English
- de.example.com -- Deutche
- es.example.com -- Español

Do the domain strings shown on each site match the language of that site? Or are they always in the native language of the domain? In the example above, do we need to store three name strings for each domain? If so, in which case do we use which string?

Sorry for the late follow up...

So what we actually need are variables/strings that are both sensitive to the current language as well as the current domain... so that we can for example store a german and an english value of the site_footer variable for one domain entry. How the language is determined doesn't really matter - it can just be determined by a pathprefix, which the Domain Access module wouldn't (need to) care about.

The Internationalization module allows to specify multilingual variables by adding them to the array $conf['i18n_variable'] in settings.php as described on this page. The values for every variable name in that array are stored separately in the {i18n_variable} table. During i18n_init() the localized values are retrieved and replace the non-localized values in the global $conf variable.

I'm not sure how this can be solved but if there are any suggestions I'd be willing to try and implement a solution...

I see that problem now, and it is complex. Domain Conf does something similar, except that it stores its values in the database and loads them dynamically when the domain is initiated.

What we could do is add an 'i18n' or 'language' column to the {domain_conf} table, with a default of NULL. Then we would make the menu item for Domain Conf language sensitive.

I don't think that is too big of a challenge, actually, but it doesn't fit into the current release.

I am also uncertain if it solves the original problem -- localized names -- since we do not currently allow this value to be set in Domain Conf. So that part would need to be reworked.

OK. Here's a patch that provides dynamic i18n support by language-enabling Domain Conf.

This needs significant testing, as it touches many parts of the module.

If you apply the patch, you must enable Domain Conf and run update.php.

Note that this has been tested against core Locale module. It requires that you do not alter $conf inside settings.php, but do so instead through the Domain Conf UI.

subscribe

Hello,

With this patch, we can set a defaut language for each sub-domains?

I'm using DOmain Acess 1.2. Is this patch is include to the 2.0 dev. version?

Thanks

This patch is in _testing_.

If it does not apply to 6.x.2, then it needs to be updated.

My understanding is that the assignment of domains to languages is done through the language settings screen -- you map 'en' to domain en.example.com and 'de' to de.example.com.

So I don't believe you need to do anything else -- unless you are not using core internationalization features.

Hello,

@agentrickard

"My understanding is that the assignment of domains to languages is done through the language settings screen"

Sure but you can assigne only one domain per language...

SO, if you have a sub-domaine France et Belgique, you can't have French language for both of them.

Same exemple with Espana and Argentina...

I understand now.

Please test the current patch and report what you are missing in order to accomplish your goal.

I've a question with a bit different angle: is multilingual content per domain supported?

Sure, this is what i18n does.

http://drupal.org/node/133977

@ agentrickard

I will try the patch this weekend :)

hello,

@ agentrickard

I can't apply the patch.

See the screenshot ^^

I'm using Cygwin.

Patch is out of date.

Here the solution,

http://drupal.org/node/360775#comment-1262578

No. That is a bad solution that is only appropriate for traditional multi-site. You do not want multiple settings files. We need to make Domain Conf load the data dynamically.

ok, sure it will be better if we could set a defaut language to sub-domains in the domains settings instead of using one settings.php file per sub-domains.

Updated patch against HEAD. I am tempted to commit this for more testing.

Hm. As far as I can tell, we will not be able to store this data in the {domain_conf} table for the obvious reason that we need to query that table by _language_, but we need to know the language_default value in order to do so.

I have committed some changes that now allow the per-domain configuration of default languages.

Note: this only works with path-based language negotiation.

ok, I'm going to test that patch really soon.

Thanks :)

The patch will not work as designed, so no need to test it. You have to checkout CVS HEAD to test the changes.

The problem with the patch is that we need to store the language information separately from the Domain Conf data. That is because we need to know which language we are using if we want to load a language-sensitive {domain_conf} table.

The current code (in HEAD), just lets you set a default language for each domain. The advanced patch will allow per-language settings overrides using Domain Conf.

Hi,

Patch is working great, but could I suggest one feature please? The multilingual options only seem to work for additional domains, not the main domain itself - and supporting the main domain would be excellent.

Are there plans to include this patch in the main module?

Yes. It will go in the main module.

As with all Domain Conf variables, the main domain itself inherits the default site settings. There is not a simple way to change that behavior, because Domain Conf cannot handle complex variables.

Great news that it will go into the main module, and for now if you set the main domain as a list domain, you can still configure multilingual variables - as it seems i18n variables from the i18n project doesn't play well with even the normal domain module sit configuration changes.

I've noticed for me that the domain conf admin page doesn't seem to save the settings in the database properly, and also seems to append a language after the full URI before you can specify the home page - will see if I can debug and patch or spot the issue.

I've noticed for me that the domain conf admin page doesn't seem to save the settings in the database properly, and also seems to append a language after the full URI before you can specify the home page - will see if I can debug and patch or spot the issue.

I don't understand this report. Domain Conf cannot save a complex variable array, and so it has to store just the two-digit language id string. Then it expands that to an object in its bootstrap function.

Lanuage-specific settings are not supported by the code in core.

@jamesfk

As I understand, i18n variables requires adding $conf array to setings.php. http://drupal.org/node/134002

If you do this, the $conf array _must_ be loaded _after_ the Domain Access include function.

If you don't, then Domain Conf may overwrite the variables set by i18n.

But that still may not be enough.

Sorry that was very badly worded! What I mean was having applied the patch, the per language settings weren't being correctly saved by doamin_conf into it's table - only one language row was being added / updated.

I've tried HEAD now instead, and this seems to have removed the ability to set per language settings now, but allows me to choose a default language instead - is this correct?

Am happy to help debug and test this, as I have a few sites for one client they want in at least two languages and using domain module - so getting the 2 modules to work together would be great :)

I've tried HEAD now instead, and this seems to have removed the ability to set per language settings now, but allows me to choose a default language instead - is this correct?

Yes, this is now correct and committed for the next release.

The per-language _and_ per-domain variable loading logic needs work, and it may be best to use i18n for that. We need more testing, but the original patch for that needs to be rewritten.

I agree that the functionality probably best belongs in the i18n module, but I wonder what the best way is to get the two to play together well? At the moment Drupal only seems to allow for one module to alter the variables definitively.

If there's anyway to assist I'm more than happy as this would be very useful for a few projects now :)

If you can identify where the conflicts take place and even poll users to see which solution they prefer -- I assume i18n.

It may be a simple case of making sure that Domain Conf loads first and then lets i18n modify the variables. That can be done with $conf variables now.

I just don't know where (or how) i18n makes its changes. Domain Conf does them right after drupal_bootstap loads the settings.php file, so any module that loads normally can modify $conf in hook_boot() or hook_init() to override that changes.

Personally I think i18n is the best place, and happy to see where the conflicts lie (presumably in the loading of the site variables).

The problem as I see it, is that i18n will need to know about the different domains to allow settings per language, per domain?

Yes. That data is easily available, but we probably need a separate 'bridge' module.

domain_i18n.module.

I am going to close this issue, since the 'default language per domain' has been corrected. I would like to see someone take up the i18n project separately.

Let me take that last bit back. This is a good overview of the issue.

From what I read in #8, this works now, with the caveat that you only get one set of localizations. If you want localization _per_ domain, then we need a domain_i18n module.

Looks like the domain_i18n module is what we need then, what do you think is the best way to get this started?

It would need a definitive location to enter per domain, per language site variables, and I wonder where the best place is to offer that - probably in the domain settings form as the original patch did?

Just my 2 cents - there's two issues here. Having different sets of languages available for domains and having site variables available in the languages defined per domain/for all domains. So I'd go with domain_locale to define language sets and domain_i18n to define everything that needs to be customizable based on the values of domain_locale or if this is not enabled based on the set of languages defined for the default domain.

@nonsie-

You want to take a crack at documenting what those modules might look like? Just a skeleton of functions?

I've been playing around with what's in Domain Conf at the moment for default language support and ran into these two bugs.

More updated to follow;)

The patch from #43 has been committed to HEAD.

Another note - the code in HEAD atm allows to set default language for each subdomain assuming default domain and subdomains all use the same set of languages. However the new default language never gets used - it should be stored in $language which is not part of $conf.

Committed #45.

Here's my first stab at domain_locale eg. having different language set per domain.
Things to keep in mind:
1. if you want a language enabled on a subdomain, it must be enabled for the default domain (eg. sitewide settings). The reason lies in language_list() in bootstrap.inc
2. set language negotiation to "Path prefix only". We are overriding $language in bootstrap hence overwriting any changes that might of been user's preferred language specific. Also user's preferred language might not exist all domains. You can leave the setting to "Path prefix with language fallback" but the language fallback will be overwritten.

Optional:
1. make sure all languages have a prefix (by default English does not). This gives unique URLS for all languages on all domains.

Domain Locale:
1. when installed enables all enabled languages for all domains setting either site default language as default for each domain or uses language_default variable set by Domain Conf if it is set
2. adds another link on admin/build/domain/view to administer domain specific languages. You can choose one or more from the enabled languages, change the weight they appear in for that domain and set default language for the domain. Updating this form will also keep language_default variable in Domain Conf in sync
3. alters the list of available languages on domain settings screen (admin/build/domain/conf/*) to only show the languages available on the domain
4. if an enabled language is deleted for the default domain removes it from all domains that have it enabled; if the deleted language was the default language on one or more subdomains sets the new default language using the next highest language weight for that subdomain (also updates language_default variable in Domain Conf)

I wonder if this commit messes up the code any?

http://drupal.org/node/405148#comment-1400402

Hm, this messes up some of the code I've written, especially the "Use primary domain settings" option that's now available (which is a great thing to have imho). No big deal to overcome that though.
It would be helpful if we had domain_conf_variable_get($domain_id, $variable) that I could call.

Easy enough to write.

#413950: Make domain_conf_variable_get()

I'm going to rip out language_default from domain_locale, no reason to keep it in two different places and sync it.

Here's the modified version that relies on domain_conf storing the default language for each subdomain

i'm getting this error after i install domain_locale_take2.zip
Fatal error: Call to undefined function domain_conf_variable_get() in /home/clafike/public_html/cf610/modules/domain_locale/domain_locale.admin.inc on line 38

i'm using Drupal 6.10 and Domain Access 6.x-2.0-rc6

i get this error everr time i create new domain or when i go to the language configuration in any domain

This is because Domain Locale uses the latest DA code eg. HEAD. domain_conf_variable_get() is not available in 6.x-2.0-rc6

where can i download manually the latest DA code, HEAD

See http://drupal.org/node/99990/cvs-instructions and click the 'show' button.

Here's a bit updated version of Domain Locale and Domain Internationalization module to enable customizing variables based on site and language. Install.txt contains instructions on module setup - if you've set up i18n module before then this should be a piece of cake.
Domain Internationalization only requires DA and Locale modules to be enabled (i18n is not required) but works well combined with Domain Locale and Domain Conf as well as i18n.
The reason why I decided not to make i18n a requirement was actually very simple - I wanted to have some variables domain specific while others would remain global. Overriding i18n at this point was not so easy since i18n_exit() saves everything that has been modified in $conf even when it doesn't apply to the domain, sets it as the default value in current language and doesn't provide a way around it.

does this 2 modules work with Drupal 6.10 and Domain Access 6.x-2.0-rc6 ?

For what it's worth, I think we should support core practices, and then find a way to collaborate with contrib.

Does DA itself provide enough support for these modules now?

If so, we have to decide how to release and maintain them. I think we should probably create a separate project. Though I could see including Domain Locale in the core module.

Let's release Domain Locale and Domain i18n as separate projects once the first stable version of DA is out (they both depend on the Domain Conf changes in HEAD atm).

So we can close this, because all the support code you need is in HEAD?

Agreed. If someone wants to follow up on these/test them out and/or have suggestions/bugs to report before I create the projects should use my contact form. The urls for these projects will most likely be drupal.org/project/domain_locale and drupal.org/project/domain_i18n.

Hi,

Could you release a DEV version in order to allow many people to test it please ?

Thanks

Just a test report.

I use the HEAD version and create some domains
domain1 with 2 languages
domain2 with 1 language

1. I upgrade to HEAD version (need to upgrade database)
2. Use http://example.com/admin/build/domain/language/* to configure the language
3. Modify settings.php and add the following code

$conf['domain_i18n_variables'] = array(
  // Primary and secondary links
  'menu_primary_links_source',);
}

4. Connect to http://example.com/admin/build/domain/i18n and you will see the variable in step 3.
5. Enable the variable you want to use and save.
6. Click "edit domain variables" and setup your variable now.
7. It works... great!!!

btw, just a suggestion, after I enable 'menu_primary_links_source' but I still can setup it in http://example.com/admin/build/domain/conf/*. Maybe it will confuse users.

Hi,

Is this patch will be on a dev. version of Domain Access?

or Will be a new module? (as nonsie propose)

What could we expect? :)

Hi,

Any news about the patch(s) applied in a new DEV or rc7 version ?

Thank you

The supporting code is in HEAD (and will be part of either rc7 or release 2.0, depending on which comes first). The other two items from #57 will be released separately after we have stable release code (again, either rc7 or 2.0).

any news about the rc7 or 2.0 release?

Please see #443296: Tasks for stable release

Why is this open?

To get a copy of HEAD, follow these instructions.

The next rc will be out when it is ready.

/me wastes five minutes.

Hello, I tried to use Head copy without succes, update.php don't upgrade database.

Is there a specific method to use Head copy?

All these changes are in rc7.

Yes, already update to rc7.

All works perfectly! Great job! Thanks :)