If language is detected from the URL, this language will apply to user interface translations as well as the $language_url global which is used when generating URLs.
If, however, language is detected via some other means, such as from the browser language setting, this language will apply to user interface translations, but will not be applied to the global $language_url variable. This results in a page that is translated to the browser's language, for example to Spanish. But all links in the page point to the default language, for example French: /fr/node/1.
Shouldn't $language_url be set regardless of the language detection method?
Comment | File | Size | Author |
---|---|---|---|
#24 | language-956256-24.patch | 9.31 KB | plach |
#23 | language-956256-23.patch | 8.66 KB | plach |
#22 | language-956256-22.patch | 8.69 KB | plach |
#19 | language-956256-19.patch | 8.23 KB | plach |
#16 | language-956256-16.patch | 8.23 KB | plach |
Comments
Comment #1
mfbI looked into this and found a few things:
$language_url is set in drupal_language_initialize() and language_initialize(). A module could presumably implement hook language_init() to set $language_url = $language during bootstrap.
In any case, I don't really understand the logic behind the user interface language detecting browser language while URL language ignores it.
Comment #2
Frank Ralf CreditAttribution: Frank Ralf commentedOnly cross-linking to g.d.o.: URL language vs. user interface language: D7 $language_url global
Comment #3
plach@mfb:
No, otherwise there would be no point in having two distinct variables: the reason is that they may actually be different.
See http://drupal.org/update/modules/6/7#language_negotiation for a detailed explanation. You may also want to give a look to this (closed) related issue, that may help to shed some light on this one: #855380: $language_url should be used to lookup the current path alias.
Anyway the behavior you are reporting in the OP is wrong and we must fix it, I suspect your system is configured so that all languages have a non-empy language prefix, right?
If the default language had an empty prefix you would get a page with URLs with an empty prefix, and every page would behave as the viewed one, e.g.: you get a Spanish interface and URLs are unprefixed. If I understood the bug report well, here we are viewing a page with an unprefixed URL, say
/node
, but all the enabled languages have a prefix defined. In this case (and only in this case) I agree that if we don't find a language prefix we must fall back to the page language.Comment #4
mfbYes, on this site we configured each language to have a prefix -- we did not want to appear to favor one language over another by using an empty prefix for the "default" language. so far I'm not up to speed enough on the language subsystem to try to patch this, but I'll read thru the links you provided.
Comment #5
plachI'll provide a patch myself. I have an idea on how to quick fix this.
Comment #6
plachHere is a patch for the bot. We still needs tests.
Comment #7
mfbThis seems to resolve the issue, after I cleared and re-configured language variables and cleared caches. Thanks! Noticed a few typos:
Should say interface language?
should be "detected".
Comment #8
mfb[Deleted - posted a comment in the wrong tab :p]
Comment #9
plachThe attached patch fixes the typos, provides an update function that refreshes the language negotiation settings and adds test coverage. We should be ready to go now.
Comment #11
plachTests pass on my box
#9: language-956256-9.patch queued for re-testing.
Comment #13
plachLet's try this.
Comment #14
plachThere was the usual problem with clean urls. This one should pass.
Comment #16
plachThere was also an issue with the base path. Hopefullly this one should be ok, provided that the patch is in a correct format (I had to manually edit the previous one, since I cannot login into cvs.drupal.org atm).
Comment #17
plachComment #19
plachRerolled #16 now that cvs.drupal.org is back online.
Comment #20
plachwhew
Comment #21
sunHad to read this twice to understand what it tries to tell. Can we move the if clause to the beginning?
The summary states that a language is assigned *to* a URL, but the actual function name states that a language is determined *from* a URL. Which of both?
1) "we" should not be contained here.
2) Without reading the rest of this patch, it's not clear to me,
a) from where locale_language_from_url_fallback() is invoked
b) whether a special configuration is required to make the language system invoke this function
c) how and where the assumption that other languages have been already detected is accounted for.
1) "Optional." should be "(optional)" (lowercase, parenthesis). See http://drupal.org/node/1354 for details.
2) $language doesn't seem to be used in this function. It's not clear to me what happens if I pass a certain $language, or what the default/special value of NULL means.
1) Ideally, there should be parenthesis around the entire comparison for $prefix; i.e.:
$prefix = (variable_get() == LANGUAGE);
2) The return line is too condensed and should be written with a proper if/else construct (which additionally allows to write inline comments above the if/else conditions to explain why a certain check means foobar.
return can be removed.
1) $language_types_info is $language_types elsewhere, I think.
2) $info is very generic, why not $url_language ?
I guess that other descriptions start with "Use", which makes more sense from a UX perspective than a technical "Return", so we should re-phrase this description to also start with "Use".
"Fallback" should be lowercase, I think.
This initial static reset is either superfluous or needs an inline comment for why it is required. (I bet it's superfluous.)
These separated code lines look a bit weird. Can we write this like we do elsewhere?
Powered by Dreditor.
Comment #22
plachThanks sun! Everything should be fixed except:
language_types_info()
return an indexed array whose keys are language types, but values are again indexed arrays of data. The only other piece of core code invoking it uses$language_types_info
.Because
$info
holds the language negotiation info for URL language not a language value.Comment #23
plachWe always have a valid language code.
Powered by Dreditor.
Comment #24
plachDiscussed with sun a far better PHP doc for
locale_language_url_fallback()
.Comment #25
sunThanks! We can with this patch and documentation for now. Ideally, we'll revisit the entire high-level and low-level language system documentation in a separate (non-major) issue.
Comment #26
plachThis needs to be committed before rc-1, since we are introducing a couple of new strings (although in core they are never displayed).
Comment #27
Dries CreditAttribution: Dries commentedCommitted to CVS HEAD. Thanks.
Comment #28
plachThanks Dries!
Comment #29
plachQuick followup: #965130: locale_update_7002() assumes that multiple languages are enabled..
Comment #32
xjm