Explain why the language switcher would not show under some configurations

I don't think this is an issue anymore. Please, re-check.

I see now that if you have session enabled, then you also see the block.

Updating issue description.

First patch attempt.

Removing JavaScript tag, as this only touches PHP.

Adding usability review tag because the wording could probably use some work.

"You do not have any language detection method enabled that provide URL based detection. The language switcher module will not be shown."

Not a native speaker, but I'm fairly certain it should to be "provides".

Can someone provide a better wording?

Add session detection to summary.

Patch no longer applies.

+++ b/core/modules/language/src/Plugin/Block/LanguageBlock.php
@@ -95,4 +97,20 @@ public function build() {
+      drupal_set_message($this->t('You do not have any language detection method enabled that provide URL based detection. The language switcher module will not be shown.'), 'warning');

As per #6, this should be provides.

Is there anywhere in the system we could link to in this text to ease the enabling of language detection?

fixed :)

I think we should link language detection method to the configuration page at admin/config/regional/language/detection so people can see exactly where they need to go to make the change.

Needs tests. Additionally to that:

+++ b/core/modules/language/src/Plugin/Block/LanguageBlock.php
@@ -95,4 +97,20 @@ public function build() {
+      drupal_set_message($this->t('You do not have any language detection method enabled that provides URL based detection. The language switcher module will not be shown.'), 'warning');

"No language detection method is enabled that would provide URL based detection. Therefore the language switcher block will not be shown."

Ie. module to block and instead of talking to the person, explaining the site config.

This looks similar to #1082902: Improve language switcher usability?

As per https://www.drupal.org/contribute/core/beta-changes usability is prioritized. This is usability.

@develCuy: are you working on this one? The tag is supposed to be on issues someone is working/worked on.

Removed tag by mistake.

Removed tag by mistake.

Thanks for the patch in #11.

I have confirmed that it does show up when configuring the block once placed in the region.

Should it also show up as soon as you click the block on the right side of the block layout page (e.g. /admin/structure/block/list/bartik) and before it is placed anywhere? It currently does not. I think this would be useful to see before it is placed so the user will know what to expect before placing it.

Also, I realize the text is not correct. Needs to be updated per #14.

Based on the issue:

#1082902: Improve language switcher usability

I think the patch for this issue should differentiate between:

1) switch links aren't showing up because there is only one language

2) switch links aren't showing up because language negotiation settings

and then we can close:

#1082902: Improve language switcher usability

See comments here: https://www.drupal.org/node/1082902#comment-9524351

Shorter description.

I'll work in this issue

I add a new patch rerolling the previous one (#11) because it didn't apply.

@jlbellido: thanks, the concerns raised from #14 onwards still apply, so needs work for those :)

Updated summary, made much shorter.

I've updated #28 with the following:

* Updated message with #14 in case of no language method detection are enabled.
* As sugested in #25, I've introduced a different message when links are not showed because only 1 language is enabled and when no language method detection is enabled.

Tests still needed.

Hi @jlbellido!
Just a minor change in a comment.

$languages = $this->languageManager->getLanguages();
    // Warn the user that if only one language is enabled the block won't appear
    if (count($languages) == 1) {
      drupal_set_message($this->t('Only one language is enabled. Therefore the language switcher block will not be shown.'), 'warning');
    }

The one line comments should end with "."

I have tested the UI and it's working and the code is good for me.

Thanks @fran for review it. I add a new patch fixing it.

For me is RTBC.

This is a block that uses a deriver - see Drupal\language\Plugin\Derivative\LanguageBlock. I think we can put this logic there and just not display the block in the list of available blocks if this is the case.

@alexpott Then you have to explain why is not listed since people are going to look for the block and a message on the blocks page is too much.

Thinking in the user, I believe we should show that something is happening with that block but if we set the block not available the user will not know the reason, the user needs a feedback from UI.

I propose the following possibilities:

1. When user goes to the block layout and add the block, a warning message is showed in the modal window.
   That way will warning the user before add the block
2. When user goes to the block layout and add a block, after submitting the configuration modal page, a warning message will be showed in the top of block layout page.
   That way will warning the user after add it.
3. When the user goes to block layout, the block will not be able to be added. Could be showed with a tooltip or we could show a warning in the page or we could update the page description explaining this behavior.
   That way warning the user from the beginning.

Working on it :)

Implementing tests in #DrupalCampsEs2015

Attach the test for the issue.
I'm implementing the changes that @YesCT proposed.
Also add the needs reroll tag and remove the Needs tests tag

attach reroll.

Applied this patch in #54 to a local branch, applied and auto-merged successfully. Removing Needs re-roll tag from the issue, also changed the name of patch to a standard name.

changed to RTBC

Hi!
The issue is not fixed, we need to apply the changes that @yesCT proposed.
Change the status to needs work

I'm looking where I should implement the changes @YesCT proposed in #49 and I see that:

1. The user goes to block layout
1.1 Show a tooltip in the language Switcher: Reviewing the code I saw that the link and its attributes are added in BlockListBuilder::buildForm and I don't see the way to add it from LanguageBlock class. I think we should not change the BlockListBuilder:buildForm code, isn't it?

1.2 Change the page description:
This change have to be done in language.module in language_help, checking the route_name, block.admin_display and block.admin_display_theme, but my question is, Should this text be rendered just when language Switcher will not be able to be added? I think the text should be always present explaining how the language switcher should be configured to be added.

2. After add the block: Currently, the system is showing a message depending the user has just one language or URL detection is not enable. I think could be good show this messages (as you commented in #50) instead show a single message. I'm not sure if the message @YesCT refers in #49 are the same that #50.

@YesCT,
I suggest we can leave the warning messages as is and give a link to where user can add a new language to the site, in the warning message itself.

Changed issue status

@gauravjeet could you add an interdiff between your pach and the the #56?
If you need more info about it you can get it in [1]

[1] https://www.drupal.org/documentation/git/interdiff

@fran seva,
I made these changes only :

--- a/core/modules/language/src/Plugin/Block/LanguageBlock.php
+++ b/core/modules/language/src/Plugin/Block/LanguageBlock.php
     if (count($languages) == 1) {
-      drupal_set_message($this->t('Only one language is enabled. Therefore the language switcher block will not be shown.'), 'warning');
+      drupal_set_message($this->t('Only one language is enabled. Therefore the language switcher block will not be shown. To add a new language on the site, go to @language-link.', array('@language-link' => \Drupal::l(t('Language list'), Url::fromRoute('entity.configurable_language.collection')))), 'warning');
     }

@gauravjeet, checking your last patch It seems that there are more changes and seems to be related to other issue (I think).
For example, I see the patch add this change

   /**
-   * {@inheritdoc}
-   */
-  public function register($id, $class = null) {
-    if (strtolower($id) !== $id) {
-      throw new \InvalidArgumentException("Service ID names must be lowercase: $id");
-    }
-    return parent::register($id, $class);
-  }
-
-  /**
-   * {@inheritdoc}
-   */
-  public function setParameter($name, $value) {
-    if (strtolower($name) !== $name) {
-      throw new \InvalidArgumentException("Parameter names must be lowercase: $name");
-    }
-    parent::setParameter($name, $value);
-  }
-

why?

In other hand, every time a patch is post it, have to be posted an interdiff file. In [1] you can get how create the file
The reason for it, is that the reviewer could check just the last changes and not all the changes in a patch.

[1]https://www.drupal.org/documentation/git/interdiff

Removing sprint weekend tag and other irrelevant tags!!
As suggested by @YesCT

Sorry, these issues were actually worked on during the 2015 Global Sprint
Weekend https://groups.drupal.org/node/447258

@gauravjeet I have cleaned your patch because there was changes not related to the issue (the clean patch with your proposal is explain_why_the-2019511-72.patch. I also attach the interdiff with the last patch (interdiff-54-72).

Reviewing the interdiff I see your proposal is not what @YesCT describe in the issue and its what is supposed to do but I think could be a good idea show the link to configure it.

I also see that the patch is not including the tests and should be. As conclusion the pending task are:

- Improve tests
- implement @YesCT proposal
- add test to main patch.

I have hidden the wrong patches and I have added the clean version.

ups...the status

Attach patch with tests and interdiff.
The patch should be red

1. --- /dev/null
   +++ b/.idea/misc.xml
   

   This file should be removed from the patch.

2. +++ b/core/modules/language/src/Plugin/Block/LanguageBlock.php
   @@ -118,4 +130,23 @@ public function getCacheMaxAge() {
   +      drupal_set_message($this->t('Only one language is enabled. Therefore the language switcher block will not be shown. To add a new language on the site, go to @language-link.', array('@language-link' => \Drupal::l(t('Language list'), Url::fromRoute('entity.configurable_language.collection')))), 'warning');
   

   The call to the t('Language list') function should be replaced by $this->t().

3. +++ b/core/modules/language/src/Tests/LanguageSwitchingTest.php
   @@ -283,6 +283,37 @@ function testLanguageBodyClass() {
   +      $warning_bool = ($warning->__toString() == 'The block Language Switcher cannot be added.')? true : false;
   

   Small nit: there needs to be a space between ) and ?, and true and false should be upper cased.

   Also, instead of manually calling the __toString() magic method, casting to a string might be more clear: (string) $warning === '...'

@jhedstrom thanks for review.
Attach the patch with the fixes.

I'm working in @YesCT proposal.

@YesCT I'm having some problems to show the message in the modal form.

Currently the code is using drupal_set_message in LanguageBlock::blockForm to render the message but this happens after submit the form and that is not what we want.

I'm not sure how do it because I see problems in all solutions I think:

1. in LanguageBlock::blockForm add an form item to show the message. This is not good because we are not using the drupal way to show messages. AFAIK we wanna show the drupal_set_message style but we could show the message just as a text without the drupal_set_message.

2. I think the message should be "done" from language module, which is the module that generate the block. But if we wanna show the message with drupal_set_message we should do before generate the modal form. make that sense?

3. Another option could be add the message using JS. The JS file could be in language module and when the form where loaded will check the number of languages and the language-url configuration. Is this the way to do it?

Are there in D8 a way to show messages in modal forms? I'm looking in code a similar use case.

No more work on that? This kind of features provide a lot of value for users.

There is another condition that must be correct to show the block that took me ages to find!
"Interface text language selected for page" must be set on /admin/config/regional/content-language
I would also recommend this be the default as I think it would be the normal setup.

@fran seva's patch in #79 no longer applied to 8.9.x. A reroll with no further modifications is attached.