Follow up for #1738374: Provide a cue to enable the language switcher when adding a language
Problem/Motivation
User testing showed no participants noticed the message saying to enable a language switcher block.
Proposed resolution
A) enable all language switcher blocks that are appropriate, and change displayed message to say it was enabled and how to disable it.
See also:
#1738374: Provide a cue to enable the language switcher when adding a language which started off automatically enabling and took out the functionality
This was shown in the past to be confusing to have a block automatically showing up when enabling a module. But I wonder with the contextual link now on blocks if it is more obvious how to turn off blocks, this might be ok.
B) Instead of only a dsm, use a message that shows on the languages configuration page until one of the switcher blocks is enabled.
Remaining tasks
- discuss, then
- create initial patch to aid testing of the idea A), get code from #1738374: Provide a cue to enable the language switcher when adding a language, or
- create initial patch for idea B), get code from... one of the et-ui issues has a message that says to enable languages if enough are not added. (find issue number)
User interface changes
TBD.
API changes
No API changes expected.
Related Issues
- #1023208: [i18n] Improve language switcher usability (D7)
- #603426: Language switcher blocks duplicated and broken
- #1874102: Rename language switcher blocks (to differentiate content and UI)
- #1833022: Only display interface language detection options to customize more granularity
- more?
Original report in Budapest Usability Testing Results
http://groups.drupal.org/node/271918
None of the participants noticed the message showing up on the top of the page guiding them to enable the language switcher block once they had 2 languages. Nobody noticed it being there.
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | language_switcher_blocks.png | 25.46 KB | Cyclodex |
Comments
Comment #1
gábor hojtsyBojhan was specifically against magically enabling a block on enabling the module. Also it depends on when you add more than 1 language. Also you might have a language block exposed by another (contrib) module if you are not happy with language module's, so we cannot just push this on user.
I think our options are (a) figure out a better way to inform the user (Bojhan hinted there may be something in the works generally for this?), (b) just live with it not being noticed (c) remove the notification altogether because it is superfluous and just more noise than use.
Comment #2
yesct commentedComment #3
yesct commentedComment #4
Anonymous (not verified) commentedI have a concern about option B, because some other modules implement this functionality in D7 but if you use an admin theme we need to also consider what is the default theme, and/or any other enabled themes (including sub-themes used by sub-sections, etc). If an admin theme is used, the "no switcher active" message will always show on the admin pages you target, even if it is enabled, and after awhile devs will start to ignore the message because it is there all the time.
Now that I've had a chance to look at how to actually enable this in D8, I'm thinking maybe it would be possible to "create" the switcher blocks and set them to "disabled" in all themes (ie, what we did in D6 & D7). That would minimize the impact on any "cowboy coders" who enable stuff on live sites, while alleviating the issue where users visit the blocks page and don't find a language switcher at all.
Another idea: this functionality is deeply related to the "Detection and Selection" page. Perhaps it would be good to put a list of existing switcher blocks on that page or as a tab beside the detection and selection page. If a dev sees this empty list, then (1) they know they need to put something into the list and (2) they know to go look at the blocks page.
Comment #5
yesct commentedOnce thing to keep in mind, is since the content language switcher block and the ui switcher block do the same thing, is that if the ui block is already enabled, we most likely dont want to automatically enable the content one. And if the content one is enabled we dont want to automatically enable the ui one.
Comment #6
yesct commentedsince #1848210: [Tests] Submitting a form in Overlay shows content + dsm() for a split second before redirecting to front-end theme is fixed we can take a look at this again
Comment #7
Cyclodex commentedI am novice and just want to try to kick in here.

I tested the output and right now it looks like this:
I am thinking of this solution:
Because this message would only appear once you add a language, lets say the user goes away and comes back, should there not still be a hint for where to configure a language switcher block? We could just extend the message like:
You can enable a language switcher block on the block administration page.just after the sentence in there ...
detection menthod settings in the Detection and Selection tab.Oh! I just found spelling error^^ should be "method" not "menthod"!
Should I create a new issue for that, or can I just fix it and make a patch in here?
To come back to this issue again: are you thinking of somehow implementing the "Tour"-thing which would inform the User? I am not yet sure how this is thought to be used.
Comment #8
klonos...yes, file a separate issue for the typo. Good catch ;)
Comment #9
klonos...and yes, I think that the second phrase in the message should stay as part of the help text once more than one languages are enabled.
Comment #23
smustgrave commentedThank you for creating this issue to improve Drupal.
We are working to decide if this task is still relevant to a currently supported version of Drupal. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or is no longer relevant. Your thoughts on this will allow a decision to be made.
Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.
Thanks!
Comment #24
smustgrave commentedSince there's been no follow up in 3 months going to close out, if still a valid task though we can always re-open.
Thanks!