Provide a cue to enable the language switcher when adding a language

Tag for D8MI and sprint.

I 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.

i just tested the patch, works for me.

@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?

Could 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.

Yeah, sounds like that is what we have and should do then.

So 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.

@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.

tested the patch, the message shows up one time after adding a new language.

Looking 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.)

Can 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.

Looking good, I dont think we ever link directly to urls, we always use a title?

Yeah something along the lines of Enable it on the <a href="@block-admin">blocks administration page</a>.

Let'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 :)

I 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.

Currently the link is to /admin/config/regional/admin/structure/block (should be /admin/structure/block)

Yeah 'admin/structure/block' should be url('admin/structure/block').

It works now.

Looks good. :-) (still waiting for test result to mark this RTBC)

Testing green and looks good. Marking RTBC. :-)

A screenshot of the current state:

Thanks 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?

- 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).

OK, 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?

Works for me.

Updated with that wording.

Ok, 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.

NOTE: THE RTBC is for #38! Uploading again to make sure its clear.

Just as a follow-up, here is a screenshot of the current state of this path's output:

Went through this and it looks fine. Committed/pushed to 8.x.

Removing from sprint. I don't think this should get a changelog entry or change notice, it is such a tiny improvement.

follow-up #1891450: message to enable the language switcher block when adding a language is not noticed (Automatically enable?)

UPdate summary