There's some inconsistency in multilanguage handling between views and drupal concerning me.
IN DRUPAL:
If you're on platform language A and a node has alias only in language B the alias won't get applied.
IN VIEWS:
if you're in language A and a node has (due to node language B) some alias in language B the alias gets applied in language context B
thus: clicking a regular node link in drupal doesn't switch platform language ever natively, while views switches language selection -- just because of presence of a node row of different language.
At least it is not consistent. Our accessibility "experts" deny switching platform language without user action (independent of chosen language content)
We should do this with clear statement.. if by design..
is it?
| Comment | File | Size | Author |
|---|---|---|---|
| #15 | workaround link to node .png | 55.18 KB | slip |
| #3 | views_handler_field_node_nolang.patch | 367 bytes | miro_dietiker |
Comments
Comment #1
dawehnerFor sounds for me exactly like http://drupal.org/node/713210
Could you specify the difference?
Comment #2
gábor hojtsyWell, only aliases for the current language or language neutral ones should be looked up. Unrelated aliases (aliases for the same path but for different language) should only be used when the specific language is asked for (eg. in a language switcher block). That's the idea of how Drupal core works.
Comment #3
miro_dietikerTo make views behave like drupal core does you need to unset language information in total.
This is a quick fix (resulting in the situation that we could remove the lines before completely...)
The question is whether this should be some configurable feature to allow language domain transitions...
Comment #4
esmerel commentedComment #5
dawehnerI don't understand the patch
It just unsets the value always. Why?
At least the code is wrong, because it would be possible to just not set the language.
Comment #6
dawehnerWhat i wanted to express is that this code could be cleanup if we never should set the language prefix.
Comment #7
miro_dietikerRight dereine -- i didn't want to delete the lines... We could remove then the whole language decision thing.
As i told: Removing it would be drupal core compliant. But since some people want foreign language aliases enabled this might be a great sample for some locale configuration option. We might check here for some internal variable for those replacements?
Comment #8
esmerel commentedSetting back to active: miro's question looks like it needs an answer before work could progress on the patch.
Comment #9
Letharion commentedComment #10
merlinofchaos commentedI'm having trouble understanding how what we're doing is wrong.
To be fair, it is in part because the translation system is really opaque to me.
The way the code currently works:
If the node being linked to is in a language, render the link in that language.
Are you saying that if node A is in language FOO and we render the l() specifying language foo, and node A has no alias, but node B, which is a translation of node A has an alias, and is in language BAR, we get node B's alias somehow?
Comment #11
merlinofchaos commentedComment #12
miro_dietikermiro_dietiker @ 11:07
drupal core has something like an interface language consistency
if you build a platform on that rule, you can have primary menu and user interface text on the CURRENT chosen language.
whatever language a document has, no one should do a language switch on its own.
merlinofchaos @ 11:09
I wonder how many people are relying on the current behavior.
miro_dietiker @ 11:11
to explain the maximum confusion: i can administer a node in any language (i probably don't know) with ma ui language in english.
so a language switch sometimes makes a platform unmaintainable for a cross-language maintainer.
merlinofchaos @ 11:11
I see. The language specific alias actually causes a language switch.
Though. That doesn't explain to me why it's even an option at that point.
We should probably go back and look and see if we can figure out where this feature got in.
miro_dietiker @ 11:12
is it an option?
i suggested making it an option for views
merlinofchaos @ 11:12
It's not an option. It could be added.
For maximum BC it'd have to default to the wrong behavior. :/
miro_dietiker @ 11:13
to me there's two different platform usecases, so a general option might make sense
merlinofchaos @ 11:14
Sure.
Anybody here care to undertake the patch for that?
miro_dietiker @ 11:16
adding it in the views tools options?
merlinofchaos @ 11:16
Would it be in the tools option or an option on the field?
Seems like you could easily have the need view specific.
miro_dietiker @ 11:17
okay.. where to add then? like the "link this field to its node"?
this seems much added complexity to the ui
Comment #13
iamjon commentedsubcribing so I can help out.
Comment #14
darksniperx commentedHi,
I am having the same issue, here is my initial post!
I have set up 2 identical views. One if for french language and another is for english.
I filter them by:
For French:
Taxonomy: Term = Dojos
Node translation: Language = French
For English:
Taxonomy: Term = Dojos
Node translation: Language = English
Both taxonomy terms have same page name.
When I preview data on english page, I get none which is what it should be.
When I preview data on french page, I get the content, which is correct.
So far so good.
When I go directly by the url I have specified in the view, I get french content on both links.
I dont have any issues with my other views, just this one is for some reason is giving me troubles.
The links are:
For english: http://nintai.ca/en/dojos
For french: http://nintai.ca/dojos
Any idea on what can be the cause of the problem.
Thx.
Comment #15
slip commentedA quick workaround is use to "Output this field as a link" as in the attached image.
Comment #16
mustanggb commented