Enabling both the content and UI language switcher blocks makes two blocks that cannot be differentiated.

Proposed resolution

A. Title the two blocks differently.
B. rely on #1833022: Only display interface language detection options to customize more granularity And only provide a choice of two blocks if the detection and selection methods are different? [this needs more discusion]

Remaining tasks

  • (novice) Create initial patch for proposed resolution A (renaming to differentiate). Contributor Task:
  • (anyone) Discuss approach B: more complicated.

User interface changes

This is a UI issue, see above.

API changes

No API changes anticipated.

Original report by Usability Testing in Budapest

Full report:
There were problems with the language switcher blocks as well. People were definitely puzzled there is a user interface and a content language switcher. Choice quotes:

  • "I need a block that switches the language **but always**, I don’t get what is the 'content' and 'user interface text' would do differently"
  • "We definitely need a block that changes both languages at once [content, interface]. So looks like I need to enable both blocks? The visitors would be interested in content, so I’d enable that for them."; "At least title the two blocks differently if we have two of them; my next step would be to rename it to Language for content and ..."

Related to #1498880: Theme language switcher for seven theme


Gábor Hojtsy’s picture

Status: Active » Patch (to be ported)

I believe this entirely depends on #1833022: Only display interface language detection options to customize more granularity, it might be solved in the same patch/issue even. If not, this issue should be good :) IMHO should be marked postponed on that, and possibly the importance of that hightened to major (if not already).

YesCT’s picture

Status: Patch (to be ported) » Postponed
YesCT’s picture

Issue tags: +budapest2012
Anonymous’s picture

Adding my 2¢ but basically supporting what Gábor suggests in #1. I would rather we have one type of block, and an option inside the configuration to set that it translates *everything* or content only.

The language between interface vs. content is very unclear. I would like to see it broken down into cases:

1. Language switcher (default) - translate everything

2. Language switcher (content only option) - if your editor wants the UI in their native language (EN, for example) but will edit content in different languages (FR content but EN editor) but want the Drupal menus to stay the same.

I really think we need the main/default option to be "translate ALL the things" because in most cases, that is all we need for a simple site.

YesCT’s picture

Ryan, that seems reasonable to me.

... there was a third table possible in detection and configuration, maybe more defined other ways in contrib. I that is mentioned in another issue somewhere.

Next steps:

  • get one more feedback to confirm support of one language switcher block (but with options on it for what the switcher controls)
  • find the issue that makes sense to implement that in (maybe this issue)
plach’s picture

Title: rename language switcher blocks (to differentiate content and UI) » Rename language switcher blocks (to differentiate content and UI)

I see this almost as a duplicate of #1833022: Only display interface language detection options to customize more granularity. As I said over there, Language defines one language switcher block for each configurable language. Two configurable language types can be configured to have completely different negotiation settings so the two blocks would behave in a completely different way. I think there is a value in having this possibility, although I'm sure this is not needed in 95% of the ML sites out there.

Currently the two blocks names are different because the language type is part of the title in fact we have:

  • Language switcher (User interface text)
  • Language switcher (Content)

I think what's confusing for users is just having to choose. We may want to skip the language type suffix if only one configurable language is defined.

This would allow us to retain the current approach which IMO scales better when there are advanced needs. Ryan's use case #2 can be mostly handled with a user interface language switcher + an admin language setting.

Gábor Hojtsy’s picture

@plach: yes, I think the negotiation method (and resulting block) should not have a specific name if it is the only one. Maybe this can be fixed altogether in #1833022: Only display interface language detection options to customize more granularity and we don't need this specific issue :)

plach’s picture

Status: Postponed » Closed (duplicate)

I agree

YesCT’s picture

good plan!