Ability to set language negotiation to "domain only" in the future as a feature?

Let's assume I have domain access enabled with two sites each with two subdomains:

Master site based on drupal install is example.com es.example.com and
the second site made is example.org fr.example.org

I'm currently using the locale language switcher, and the desired scenario is to make my links work correctly.

Right now, example.org has within its language switcher block, a link for 'English' and 'French', but instead of the hyperlink for French pointing to fr.example.org, it points to fr.example.com, which is obviously incorrect when the "domain only" setting (language negotiation section from Drupal + i18n and the edits done within the list) has been selected. So it is using the master site setting for the secondary site.

If the domain locale module could ensure the integrity of the settings to the domain access module when "domain only" was chosen, that would be the desired result. I figured this module would be the best place for this type of feature.

By the way, what is the recommended subdomain creation process using domain access for languages using "domain only"? Do you happen to know? One method is to create an alias, and the other is to create another domain entry, but a new domain entry could mess up language settings? I'll do some research.

After thinking this over, there's three solutions that I know of which will more or less take care of domain name path issues:

1st one is to make a subdomain module for the domain access module, which gives the ability to clone some settings from the tld site and making it support cookies would be a bonus

2nd one is to make a feature based on the above where the path based on domain is respected.

3rd solution is to create a new domain instead of using an alias (which can cause confusion at the master install drupal site, since that site would show correct UI language), and deal with any link issues as necessary.

Right now, since the drupal.org/project/subdomain module (not domain access) doesn't do anything in regards to localization based on domain path, the 3rd solution is the only one feasible.

To clarify comment #2, I was talking about the domain IDs in relation to the Domain Locale module. When I say subdomain, I refer to anything to the left of the TLD (so in es.example.com, I'm referring to an es subdomain creation). I was referring to the DA setup where domain ID 0 (example.com, the master site, called for the initial drupal install site) was setup to be "domain only", and if a subdomain (es.example.com) was setup by Domain Access (DA) to be an alias, then most i18n use cases are working with i18n and related modules.

DA was used to create a second domain ID, domain ID 1 (example.org), and if an alias is setup (fr.example.org), sometimes those settings get corrupted, which results in the language switcher block not pointing to the right domain, which is the problem that I keep having to avoid or solve, as noted in comment #2.

I'm not sure what corrupts that setting, but adding another domain ID, just for a subdomain (like domain ID 1 for example.org and domain ID 2 for fr.example.org), adds affiliate management duties on top of localization tasks. i18n can be separated into User Interface and Node content, but using the creation of a domain ID for a subdomain is where I see aliasing problems.

So to sum it up, using an alias for the subdomain of a domain ID results in certain language behaviors that can not be reset to default behaviors, and you can't change logos or anything else for that matter, while the creation of a domain ID/subdomain results in additional tasks and path aliasing problems.

Thanks for the update. I'll take a look and return with a patch for #745540 if I'm able to.

Under http://www.example.com/admin/settings/language/overview ..the domain ID 0 site has a list of enabled languages where the default language English is left blank for the path prefix and language domain. For the included second language, for example es for spanish, when set to domain only, most people would put the subdomain name of their choice, so let's pick es, for http://es.example.com. That path is only for the user interface, not the content nodes.

That would be done if using the i18n module. Your question states that the i18n module is enabled. What happens is domain ID 0 sites work with the variable stored under http://www.example.com/admin/settings/language/configure. If it was stored under http://www.example.org/admin/settings/language/configure, it is the same as saving at the domain ID 0 site. If es.example.org was stored instead of es.example.com, domain ID 0 will not be set with the language user interface to spanish when a user goes to es.example.com, nor will it set path aliases to es.example.com (such as when using the language switcher block), but instead, path aliases within content will be set up to es.example.org and it will be in English. If domain ID 1 was setup to be es.example.org, the user interface and path aliases within content will be as intended.

To explain the original question, for domain ID 0 (example.com), if a third language, fr for french was installed, and it was set to fr.example.com ("domain only" configuration under i18n module), then the user interface is setup correctly for domain ID 0 (along with the path aliases), but any other domain IDs (like, example.net, example.org) will not path alias correctly, nor will it set the user interface correctly, and it will be in English.

So path aliasing, user interface, and node content are the most important dependent variables which rely on the domain ID and i18n settings.

1) Also, some of the nodes indexed by apache solr show up in search results for the wrong domains, EDIT: apache multilingual module and http://drupal.org/node/556426 was used to fix this one.
2) and url escaped characters for some other languages will prevent normal processing (values being too long, etc.) with the path urls if they are not saved in English, such as Korean, etc. This makes path aliasing pointless for other languages when used in conjunction with other services (twitter) and methods:

This is url escaped for drupal comments, but not so as originally shown in google.co.kr/news http://news.google.co.kr/news/url?sa=t&ct2=kr%2F0_0_s_3_0_t&ct3=MAA4AEgD...

Wouldn't a domain specific box for http://www.example.com/admin/settings/language/overview do the trick?

Or is the code too integrated or something...?

I found that multisite + domain access avoids the need for a patch. However, if the domain module wants to broaden it's scope of capabilities/features and save admins time, a patch for the request mentioned above would need to be implemented. Since a batch configuration page for domains is available, the domain module is already partly in the category of a provisioning module. Whichever the future direction, this module make internationalization more feasible, especially using the domain only feature.

I saw that the new i18n 7.x version updated a lot of stuff. Hopefully, everything holds up, but I'm starting to think that domain access needs to be installed after i18n modules at this point (perhaps true for other node access using modules), due to how it manages the cache.

Just to clear things up on what I'm doing for users, if including more than one domain, such as example.net, multi-site also lets me add two of the same subdomain names, such as es.example.net and es.example.com without url or i18n ui issues occuring.