Canonical metatag on Views pages no longer refers to current, language page

I've just encountered this issue on some views pages on a multilingual site. I arrived at line 591 in web/modules/contrib/metatag/src/MetatagManager.php file:

    // Use the entity's language code, if one is defined.
    $langcode = NULL;
    if ($entity) {
      $langcode = $entity->language()->getId();
    }

The language code that is later used in all token replacement calls seems to be declared here, and the $entity variable contains the Views configuration object. This object always returns the default language, at least for my case.

I added a patch that might not be the best fix/approach, but I think it's good to start somewhere. I'm omitting to set the current language if the $entity is a view (probably it applies to all config entities, but idk about that) so that later on in the execution the language is set with the current detected language. We don't want to have the language of the config object, but the interface language (especially for views pages).

I tried the option from comment #10, but that didn't work for me.

I had the same issue and the current patch fixed it. Thanks.

Setting the status to "needs review" now that there's a merge request to review.

The issue is relevant to webform pages as well. I think it make sense to not extract language from any config entity, not only Views.

I think it'd be worth improving the test coverage to catch this problem.

A patch for 2.1.0 version