Issues when selecting English; changing to African and then back to English makes it work again

We run into the same issue. Can anyone please help?

This issue was happening on D7 as well, here the links:
https://www.drupal.org/project/gtranslate/issues/2822393
https://www.drupal.org/project/gtranslate/issues/1982656#comment-10261903 (Has a partial solution)

Based on the solution in the second link I implemented a similar script in my custom theme.

Drupal.behaviors.gtranslate = {
    attach: function (context) {
      if (Cookies.get('googtrans') === undefined || Cookies.get('googtrans') === 'none') {
        $('#block-gtranslate :input option[value="en|en"]').attr('disabled', 'disabled');
      }
      $('#block-gtranslate :input').change(function (e) {
        $('#block-gtranslate :input option[value="en|en"]').removeAttr('disabled');
      });
    }
  };

Note: gtranslate module uses a cookie (googtrans) to know the selected language. I'm using https://github.com/js-cookie/js-cookie to get the cookie value.

I have found the the same. When clicking on English, the page language is translated to Afrikaans.

In my case however hiding "English" is not an option. This is because the site has no concept of languages, and people all around the world can post to it. This means that some pages are in English, some in Spanish, and some even in Chinese. When English users arrive at a Spanish page, they may want to translate it to English... we even have some cases where part of the pages are in English, and part in Spanish (feeds etc).

Therefore in my case, I want no default language to be set. I want Google to automatically work out the language, and translate it to the best of its ability. For mixed pages this will mean it will translate some paragraphs, and not others.

My fix involves adding the ability to select no default language. This results in the Google translate Javascript having no default language set. I am not sure of the bigger picture consequences of this, so please use my fix understanding that there may be consequences I am un-sure of. It is also worth noting that in my case, the site is a closed community, and therefore is not indexed by search engines. I can't imaging this to have any SEO impact as the language is just related to the translate javascript and not any other meta information (as far as I am aware). But please do check this won't affect your SEO. Happy to discuss if this fix has repercussions I am unaware of.

It appears to me that Google does a remarkable job of working out the language and translating the content even with no default language set. This may be to my untrained eye, so again do your own testing... if anything comes back from our testing, I'll post an update here.

Forgot to add the new language to the block class.

Hey

I applied patch #6 and found I ended up with the flags mismatched against their language.

Dutch has the Finnish flag against it.

Think this needs work.

Thanks

Bugs are fixed in the development snapshots (the releases created from branches).

I took a look at all of the issues I could find here in the issue queue related to this (#1982656, #2820025, and #3127553). Thanks to everyone who submitted code suggestions. I've consolidated all of that into a patch that appears to be working for Drupal 8 here.

The IS needs to be updated; reading it, it's not clear what the issue is, and what the patch is trying to resolve.

Adding an updated patch to work with version 1.14 of the module.

Removes unnecessary console.log.

+1 for #13 x 1.14

I think #13 puts the JS folder in the wrong location. It doesn't seem to add it to the JS folder of the module but instead creates a new folder. Am I applying the patch incorrectly?

+1 for #13 x 1.14

+1 for #13 x 1.14

Re-rolled #13 just to clean it up a little bit and remove the commented out console log

The previous patches didn't seem to mark the current language as disabled when moving to a new page. This patch addresses that problem by taking the value from the cookie and disabling the appropriate option.

#21 Patches are working fine for me.
Thanks

Patch #21 working fine.

My case:
When I select English with nothing else selected, it turns to another language (perhaps Afrikaans).

When I re-select English, it turns back to English.

I am still having this issue, patches above does not seem to work, using 8.x - 1.14

I applied patch#21 and it worked on D9.5.2.

@pr1859. I had to refresh the cache in order for it to take effect. To confirm that it's working, your "Main language" should be greyed out in the dropdown.

Good luck!

Hello,

Turns out Ipads/tablets do not work correctly. When you select another language, your "Main" language remains greyed out and unselectable.

Please test: https://www.drupal.org/project/gtranslate/releases/8.x-2.x-dev

Hi edo888,

Tested dev and now I'm getting WSOD. I reverted back to stable and reapplied the patch for now.

Here's the dblog:
Undefined array key 1 in Drupal\gtranslate\Plugin\Block\GTranslateBlock->build()(line 385 of /var/www/sseto.ca/web/modules/contrib/gtranslate/src/Plugin/Block/GTranslateBlock.php)
#0 /var/www/sseto.ca/web/modules/contrib/gtranslate/src/Plugin/Block/GTranslateBlock.php(385): array_values()
#1 /var/www/sseto.ca/web/core/modules/block/src/BlockViewBuilder.php(171): Drupal\gtranslate\Plugin\Block\GTranslateBlock->build()
#2 [internal function]: Drupal\block\BlockViewBuilder::preRender()
#3 /var/www/sseto.ca/web/core/lib/Drupal/Core/Security/DoTrustedCallbackTrait.php(101): call_user_func_array()
#4 /var/www/sseto.ca/web/core/lib/Drupal/Core/Render/Renderer.php(788): Drupal\Core\Render\Renderer->doTrustedCallback()
#5 /var/www/sseto.ca/web/core/lib/Drupal/Core/Render/Renderer.php(374): Drupal\Core\Render\Renderer->doCallback()
#6 /var/www/sseto.ca/web/core/lib/Drupal/Core/Render/Renderer.php(446): Drupal\Core\Render\Renderer->doRender()
#7 /var/www/sseto.ca/web/core/lib/Drupal/Core/Render/Renderer.php(204): Drupal\Core\Render\Renderer->doRender()

Added a variation of the patch which attempt to support D9/D10. May be used in tandem with #3297355-8: Automated Drupal 10 compatibility fixes

The last patch does not apply for me.
However, if I understand the issue correctly, it's similar or equal to the issue I'm having.

Our default language is English, sometimes (I don't know what the trigger is) when changing to a different language, you can't change back to English.
You have to click on the current language again, and then you can click English again and it'll work.
When this happens, English is the selected language in the language selector, but the page is still in the translated language.

No console errors or other measures to know what's going on.

If what I described matches/corresponds to what the original poster experiences, maybe we can update the issue as such if it's clear enough.

Bumping again...

Can the maintainer please take a look at this??
Is there even still an active maintainer?