Problem
When you add a language there is no way to figure out how to make users switch between them. The language switcher block is not enabled and there is no cue as to how can that happen. So people wonder around cluelessly.
Proposal
We wanted to enable the block and make it pop up automatically once you have 2 or more languages. Bojhan pointed out similar behavior with Search module was tested and did not work well. So we settled on just outputting a message to the user pointing to the blocks UI to expose a language switcher from there.
Comment | File | Size | Author |
---|---|---|---|
#43 | language_switcher_block_message-39.png | 74.38 KB | LoMo |
#42 | 1738374-38.patch | 3.49 KB | Gábor Hojtsy |
#39 | using_new_lang_object_1738374-39.patch | 3.65 KB | sxnc |
#38 | 1738374-38.patch | 3.49 KB | Gábor Hojtsy |
#33 | language_switcher_message.png | 54.49 KB | LoMo |
Comments
Comment #1
sxnc CreditAttribution: sxnc commentedAttached patch enables this functionality and extends the "Language list configuration" test to check for the newly added block as well.
Comment #2
Gábor HojtsyTag for D8MI and sprint.
Comment #3
Bojhan CreditAttribution: Bojhan commentedI don't think we should be doing this, in one of the earliest tests we did it showed that people where confused by the fact that a block suddenly appears when enabling a module. In the usability test its case the search module, in Drupal 6.
Placing a block is almost always a explicit action, when its not people get confused. A good way to inform people about a new block, is adding it to the install success message.
Comment #4
k4v CreditAttribution: k4v commentedi just tested the patch, works for me.
Comment #5
Gábor Hojtsy@Bojhan: thanks for the feedback! In this case, it is not really the install success that should trigger this. The block gets interesting when you have more than one language. The current UX is that you add your second language and then nothing changes, and you could have a hard time figuring out how to actually make use of the language. We already fixed it earlier in the cycle that the path prefixes are preconfigured properly, so the languages work if you manually switch around the paths, but we don't have any UI apparent to start using your multiple languages.
So we'd need some call to action when you add your second custom language I guess then?
Comment #6
Bojhan CreditAttribution: Bojhan commentedCould we do something like adding a message when you add a second custom language? I know its not ideal, but we don't really have a better pattern yet for showing new blocks.
Comment #7
Gábor HojtsyYeah, sounds like that is what we have and should do then.
Comment #8
Gábor HojtsyComment #9
Gábor HojtsyComment #10
Gábor HojtsySo the problematic UI is this. Note it explains users have ways to choose language, but not explained how or where or that you need to enable a block. I'm not sure this should be explained in the help text though that is also a possibility. A message is probably more visible.
Comment #11
sxnc CreditAttribution: sxnc commentedAlright, i modified the patch to display 2 messages.
Comment #12
Gábor Hojtsy@sxnc: according to my understanding of Bojhan's suggestion, you'd NOT enable the block at all automatically. You'd just tell the user they need to enable the block and (a) tell them the block title and (b) link them off to the blocks list admin page in the message. So Bojhan just said he sees this showing up automatically (even with the message) would confuse people and we should just tell them where to enable the block.
Comment #13
k4v CreditAttribution: k4v commentedtested the patch, the message shows up one time after adding a new language.
Comment #14
LoMo CreditAttribution: LoMo commentedLooking good.
Reviewed and tested and feature seems to work "as advertised". :-)
(Oh, I see the block should not have been activated automatically, but I thought that was nice, anyway. For most people, it saves a step, I guess.)
Comment #15
sxnc CreditAttribution: sxnc commented@Gábor Hojtsy olright, changed the patch to only show a message and link to the block configuration page~
Comment #17
sxnc CreditAttribution: sxnc commentedre-applying patch
Comment #18
Gábor HojtsyCan you provide a screenshot of this? There are I think one or two configurable language types and therefore blocks in core by default (depending on whether you have entity_translation module enabled or not). So maybe we just want to say something more general referring to the language switcher blocks without concrete titles of the blocks.
Comment #19
sxnc CreditAttribution: sxnc commented@Gábor Hojtsy here's a screenshot of how it looks right now, so i guess i would refer to it as "Language switcher" only then?
Comment #20
Bojhan CreditAttribution: Bojhan commentedLooking good, I dont think we ever link directly to urls, we always use a title?
Comment #21
Gábor HojtsyYeah something along the lines of
Enable it on the <a href="@block-admin">blocks administration page</a>
.Comment #22
sxnc CreditAttribution: sxnc commentedOkay, here it goes again :)
Comment #23
Gábor HojtsyLet's integrate the link text in the message, like in #22, that is better for translators. Eg. "the" translates differently based on the text going after in German or Hungarian :)
Comment #24
sxnc CreditAttribution: sxnc commented@Gábor Hojtsy the more you know! added the patch with the changes~
Comment #25
Gábor HojtsyI realized this will only work for predefined languages, so we'd need to add this to the custom language submission too (where you provide language details). Then I realized that would be too much code duplication in an area where it already has quite some. So I decided to merge these together. Untested :) Also I did some text adjustment, so it does not refer to a concrete block by the name that we don't have for a concrete block, just making it general.
Comment #26
LoMo CreditAttribution: LoMo commentedCurrently the link is to /admin/config/regional/admin/structure/block (should be /admin/structure/block)
Comment #27
Gábor HojtsyYeah 'admin/structure/block' should be url('admin/structure/block').
Comment #28
sxnc CreditAttribution: sxnc commented@LoMo fixed the link to "/admin/structure/block"
Comment #29
sxnc CreditAttribution: sxnc commented@Gábor Hojtsy added another patch, now with the url('admin/structure/block') as it should have been :(
Comment #30
LoMo CreditAttribution: LoMo commentedIt works now.
Looks good. :-) (still waiting for test result to mark this RTBC)
Comment #31
LoMo CreditAttribution: LoMo commentedTesting green and looks good. Marking RTBC. :-)
Comment #32
Gábor HojtsyComment #33
LoMo CreditAttribution: LoMo commentedA screenshot of the current state:
Comment #34
webchickThanks for the screenshots! That's really helpful.
I personally think we should just automatically enable the block, though I can see both sides. I know of the testing results Bojhan's talking about, but OTOH we've also seen plenty of testing results that 99% of people ignore what's in those green messages (it might help slightly that there are two of them and this is somewhat unusual), so I worry we won't actually have fixed any UX issues here. :\ I guess we can go with it for now and try and do some crowdsourced usability testing of multilingual features later and do a follow-up based on that.
Question, is there a reason we're casting $language to an object, rather than just making it an object directly? That's a bit weird.
Also, one small grammar tweak; it should be "Enable it" rather than "Enable them;" you're only talking about one block, no? And could we emphasize the block title or so, so that the name of the block is set apart from its surrounding text to help people know what they need to do there?
Comment #35
Gábor Hojtsy- The casting was there before, we can update it to new Language() and then pass on the arguments there. The Language class came later :)
- There are in fact multiple language switcher blocks possibly, one for each configurable language type. Eg. if you have content and interface language setup separately, then you have one block for each. We can make two messages one with singular and one with plural wording, but we cannot really tell the exact block name if there are multiple, because it depends on what you want (YES, I know people don't know what they want, but the blocks not being easily explained is a separate usability concern I think).
Comment #36
webchickOK, how about this wording then?
Use one of the language switcher blocks to allow site visitors to switch between languages. You can enable these blocks on the <a href="">block administration page</a>
Does that work?
Comment #37
Gábor HojtsyWorks for me.
Comment #38
Gábor HojtsyUpdated with that wording.
Comment #39
sxnc CreditAttribution: sxnc commentedUpdated patch to use the new Language Object, thanks Gábor Hojtsy!
Comment #40
Gábor HojtsyOk, I stumbled on this use of name => NULL in the predefined language case. @sxnc tells me it defaults to English otherwise. Yeah, because Language has those property defaults, so if you do not provide a complete set of properties it makes assumptions like the name is English or the direction is LTR. It does not make this "predefined language fallback" logic that is in language_save().
Ideally, we'd either modify Language() to do that logic in its constructor, or provide an init function which sets from a predefined language and includes the logic form language_save(). However, instead of duplicating the code, we'd move it to the Language class from language_save(), then we need to ensure we always use the class, and all this becomes a lot bigger and pretty much unrelated issue. Submitted #1739994: Use the Language class universally instead of stdObj instances for this. So we should be back to considering #38 for commit.
Comment #41
sxnc CreditAttribution: sxnc commentedComment #42
Gábor HojtsyNOTE: THE RTBC is for #38! Uploading again to make sure its clear.
Comment #43
LoMo CreditAttribution: LoMo commentedJust as a follow-up, here is a screenshot of the current state of this path's output:
Comment #44
catchWent through this and it looks fine. Committed/pushed to 8.x.
Comment #45
Gábor HojtsyRemoving from sprint. I don't think this should get a changelog entry or change notice, it is such a tiny improvement.
Comment #47
YesCT CreditAttribution: YesCT commentedfollow-up #1891450: message to enable the language switcher block when adding a language is not noticed (Automatically enable?)
Comment #47.0
YesCT CreditAttribution: YesCT commentedUPdate summary