I turn on Language negotiation to "Domain name only", and display the "Language" block. And set up "Language domain" for diffirent languages.
But URL's in "Language" block displays wrong!
I try to setup "Language domain" for languages with protocol and without, nothing helps.
When I try "ru.mydomain.com", URL in block becomes "http://mydomain.com/ru.mydomain.com/".
When I try "http://ru.mydomain.com", URL in block becomes "http://mydomain.com/http:/%2Fru.mydomain.com/".
I look to the module, this block displays with function theme_links(). This function generate "domain" parameter for the $link array correctly:
[ru] => Array
(
[href] => node
[title] => Русский
[language] => stdClass Object
(
[language] => ru
[name] => Russian
[native] => Русский
[direction] => 0
[enabled] => 1
[plurals] => 0
[formula] =>
[domain] => ru.mydomain.com // or http://ru.mydomain.com
[prefix] => ru
[weight] => 0
[javascript] =>
)
[attributes] => Array
(
[class] => language-link
)
)
But when it's converting to HTML code, something goes wrong.
Comment | File | Size | Author |
---|---|---|---|
#11 | language-domains-fix-3.patch | 2.78 KB | Gábor Hojtsy |
#9 | language-domains-fix-2.patch | 1.67 KB | Gábor Hojtsy |
#5 | language-domains-fix.patch | 618 bytes | Gábor Hojtsy |
Comments
Comment #1
MurzFor temporary solution I patched file includes/common.inc, function url().
Before string 1310 ("$path = drupal_urlencode($path);") I add following code:
This works only with $clean_url is on and http domains.
Comment #2
Gábor HojtsyAn
'external' => TRUE
key should be passed on to theme_links() if using the domain negotiation. Can you try this out?Comment #3
MurzYes, I try but it isn't help :(
I think that problem is in function language_url_rewrite(&$path, &$options) [/includes/language.inc], because when turned on LANGUAGE_NEGOTIATION_DOMAIN language mode, it's allways add domain and $options['absolute'] vaule to $path. But after that function url($path = NULL, $options = array()) [/includes/common.inc] translates $path to url_encoded.
Comment #4
Gábor HojtsyMurz: Can you try modifying the 'absolute' you noted to 'external' in language_url_rewrite()? To me it seems like we use the wrong flag there. This really should designate that we *already built* an external link, not that an absolute links *should be assembled*. As far as I see, this causes the error you encounter. If this works for you, I can fix it in Drupal.
Comment #5
Gábor HojtsyI went ahead and tested this while I was at it for testing RTL CSS files and locale help texts in other patches anyway. I validated that we need to use 'external' as intended there, so the attached simple fix was the result. Committed to Drupal 6-dev. Thanks for the report. Please reopen this issue if this does not fix domain URLs for you.
Comment #6
Gábor HojtsyAlso remember to use
http://ru.example.com
(ie. add the protocol) as the description on the domain field suggests.Comment #7
MurzWith this patch "Url aliases" does not work! When you do your patch, I try to create my version. It's work with aliases correctly:
And I replace main selection to "if ($options['language'])" because when URL have same language that current site, there are no needs to add domain prefix to URL.
Comment #8
Gábor HojtsyAh, indeed, by returning with an external link from url() too soon, we loose support for path aliases, additional query strings and so on. However, not returning and letting the flow go on would mean our built up full URL would be target to alias lookups and so on, which is not right.
As far as I see, a possibility here would be to invoke url() again and let it do the path mangling with all query string and hash building and glue that to the end of the domain name. That would require all domains to have Drupal in the same directory (path) for example, but that might not be a problem as they point to the same code base anyway. The only problem with calling back url() is that it goes into the language negotiation rewrite again, so we end up with an infinite loop. We need a way to tell url() that it should not go into the language rewrites when called back from the language rewrite.
Comment #9
Gábor HojtsyThere is actually a much easier way. We only need to make the base_url modifiable in url(), so we can pass on our base_url (from the language domain setting) and get absolute URLs with that base. This fixes path aliases and other URL functions in my testing. Please review, so I can get this important fix into Drupal 6 as soon as possible.
The attached fix is against the latest Drupal 6-dev code, which has the fix in #5 from above already applied.
Comment #10
MurzI try your last patch, it works good, load aliases for same language that in page, but it isn't load aliases for links with languages other that in page.
And I think there are no needs to add domain prefix and option 'absolute' for links to pages in same language, because it must be local links.
You must try to load two aliases for each url: with url language and without languages:
Comment #11
Gábor HojtsyDepending on your base_url setting on the site, the current language domain might or might not be the same as the base_url, so you would end up with broken links, if you do not use the domain.
Looking at the language aliasing this is indeed an issue. url() did not take the language into account, and the path negotiation did some workaround to kind of solve this issue. As with the base_url resetting, aliases are also better handled by url() centrally (there are quite some checks which would be pointless to repeat in the negotiation check), so handing off the path alias retrieval in both cases with our language code works better. This also makes the custom aliasing receive the language code, so it can act on that too. This was quite an oversight there, that passing on this info was missing.
Try this please, this should fix all the issues you encountered. Thanks.
Comment #12
MurzWith language-domains-fix-3.patch all works good! Thanks.
Comment #13
Gábor HojtsyThanks for testing, now committed.
Comment #14
MurzGábor Hojtsy says:
I don't think so.
For example, site have 3 languages (English, Russian, German), base_url is "http://mydomain.com".
English domain: http://mydomain.com
German domain: http://de.mydomain.com
Russian domain: http://ru.mydomain.com
And I open a page in German language: http://de.mydomain.com/node/23
Current language is German, current domain is de.mydomain.com.
When I place an internal url without language affiliation (/node/64), it leads to http://de.mydomain.com/node/23 (correct url).
And all other internal links without language affiliation leads to correct domain.
But in page I have a Language selector block, that have links to other languages. This links have option that obviously points to language. I agree, in all links like this you must add domain prefix. But links with clear "language" option, I think, needs to stay internal.
Comment #15
Gábor HojtsyWell, you use Drupal's automoted ability to find the base_url under ideal software circumstances. It is possible that the user set a base url in the config file, and as the language switching is implemented on the site, that base_url is the same for all languages, and should not be used when being on any of the language versions.
Comment #16
(not verified) CreditAttribution: commentedAutomatically closed -- issue fixed for two weeks with no activity.
Comment #17
MurzI found an inconvenience with external links to native language links. When I move site from one domain to another, I can't use site interface in new domain, all links leads to old site. And I need to type an address /admin/settings/language/edit/en manually to change language domain.
And when I do a mistake and type wrong domain, I have this problem too.
This isn't difficult for me but this can mislead the newcomers.
About base_url: when I don't use multilanguage system, I have all links as local. And when I use wrong base_url in this mode, all links leads to wrong base_url address too. Therefore, I think that leaving site links to native language as local will be better that converting they to external. Maybe try to add an option for selecting types of native language links?
Comment #18
Gábor HojtsyWell, please open a new issue for new problems. This is not related to how url() features were not supported in domain negotiation.