Canonical meta tag on config entity pages (e.g. Views) no longer refers to current language

It is likely a result of this change: #3077442

In order to change this further we'd need to have test coverage.

Is this a standalone Views page or is it connected to an entity?

Is the path for the Views page "it/articoli" or "articoli"? What is the default language of the site?

Do these give different results?

Test 1:
* Clear the caches.
* Load /articles.
* Load /it/articoli.

Test 2:
* Clear the caches.
* Load /it/articoli.

Thanks for testing it, that helps us narrow down what's going.

I think we next need to create a test scenario.

I have managed to fix this issue by enabling Use replacement tokens from the first row checkbox.

1. Go to settings of a view
2. Open Meta tags settings
3. Enable checkbox Use replacement tokens from the first row

So maybe we need some hints in the UI to enable that option?

Alternatively, maybe this should be automatic? Or maybe the option should be enabled by default, with a hint to disable it for performance reasons if it isn't needed?

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 and could break other stuff that I'm not aware of, 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

FWIW

When I enter [view:url] in the Canonical-URL field under Metatag settings in the view I managed to get a correct url for both languagaes in a multilanguage domain based setup.

Metatag 2.1.0
Drupal 10.4.4

The current patch from #19 didn't fix it for us. In issue #3077442 the generateRawElements function is also updated.

I rerolled it with the same fix in this function as well to cover both cases. This solves the problem in our case where rawElements are used. Review needed.

We discussed this issue as part of [Drupal Contribution Day Japan 2025](https://www.drupal.org/community/events/drupal-japan-contribution-day-ju...)

Patch #21 worked. Attaching before/after screenshots.
Also worked on creating the merge-request for 2.1 branch using the same patch.

Drupal.org usernames:
- yukihyogo
- gengo_k
- bassline

Back to this needing work to add test coverage.

It worked for us. Should the MR be rebased against 2.2.x?

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.

This was an excellent point, so I updated the MR to check for ConfigEntityInterface instead of ViewEntityInterface, hopefully the tests still pass.

Committed. Thank you all!