Language switcher blocks duplicated and broken [#603426]

Arising from #282191: TF #1: Allow different interface language for the same path, the language switcher blocks appear broken.

There are two language switcher blocks, one each for interface language and content language. The bug is, the two blocks look and behave exactly the same.

Steps to reproduce issue:
* Enable locale, install two languages, and enable all language negotiation options.
* Enable both interface language and content language switcher blocks.

Result: The two blocks are identical (except on translated node pages). Both are called "Language" and feature the same language options. The language links lead to the same paths (the current page with a language code prefix). It appears that the interface language is switched for both, while neither switches to the content language.

Expected result: There is some difference in the block title, indicating to the user the type of language switching. (Or, possibly, only one switcher may be enabled at a time.) And they actually work, switching language for interface and content respectively.

Comments

Comment #1

alexanderpas commented 13 October 2009 at 17:40

hmm... if i think about it, the amount of blocks seems wrong too... (from a purely coding view.)

we actually should have three blocks:
- one for the old-style node language
- one for the session parameter.
- one for the URL-prefix language at the node-level. (en/node/6 and de/node/6)
- one for the URL-prefix language at the alias-level. (en/alias and de/alias (can be different nodes))

okay, that was a purely coding view. (read: naturally, that won't work.)

now from an UX view:
Two blocks seem correct, yet the functionality seems to be not working correctly for now:
- "view this site in a specific language" (interface-language)
- "view translated version of this post." or "this post is also availble in specific language" (content-language)

naturally, even better, would be just one block, that always changes the correct parameter.

okay, now, how do we determine parameter to change, and which block to show, as there is no need to show a certain block if we can determine that another language is always taking over (e.g. no need to show interface language block, for logged-in users, when user language has a higher priority over both url and session language.) or this post has not been translated.

also, if it has been determined that both blocks use the same parameter, there is no need to show them both. (i would say, show only show site language block.)

now, how to determine which language swither to use... that's the next question ;)

Comment #2

plach

he/him

Italian

Venezia

commented 14 October 2009 at 12:30

Issue tags:

-translatable fields

I won't have time for this for a couple of days. Just a few considerations: language blocks are now tied to language types, if a module defines a new language type there will be three language switcher blocks available. Although it probably doesn't make sense to enable more than one, IMO we should not limit this possibilty; I don't see a great harm in allowing this.
From my pov the (default) block titles should be kept the same ("Language") as the language type is a concept I wouldn't expose to users.

The language switch links change their form based on the language negotiation configured for the related language type. If you configure interface and content negotiation the same way, obviously the two language switcher will behave the same.
About the broken behavior I will have a look ASAP.

@alexanderpas:

also, if it has been determined that both blocks use the same parameter, there is no need to show them both. (i would say, show only show site language block.)

This might be a good idea, but I don't know if it's easy to implement because the language negotiation processes are independent and it couldn't be easy to compare them.