Remove Core hreflang tags

Interesting, I've not seen that - the hreflang tags are identical and thus one overwrites the other.

Any chance you could write a failing test to catch this bug or provide steps to reproduce?

ok this is caused by the fact that we explicitly set the URL to <front> if we're on the front page: $route = \Drupal::service('path.matcher')->isFrontPage() ? '<front>' : '<current>';

We could remove this line, although this would instruct search engines to index e.g. https://www.domain.com/de/Node-URL rather than https://www.domain.com/de

At the moment what you could do is use hook_page_attachments_alter() to remove the hreflang tags added by core translation module

Arguably the $entity->toUrl('canonical') which is called by content_translation_page_attachments() should be front-page aware, and generate the correct URL when generating the canonical URL for an entity which is the front page? I guess it's a philosophical question, what is the canonical URL anyways? :)

Found a related core issue: #1255092: Return "/" instead of the internal path when asked for the URL of the frontpage

Well this won't work because module weight is apparently non-deterministic in drupal 8 - based on install time rather than alphabetic. So the content translation hreflang tags may not have been set yet.

I've just applied the patch and it generates the following errors:

Notice: Undefined index: html_head_link in hreflang_page_attachments() (line 35 of modules/contrib/hreflang/hreflang.module).

Warning: Invalid argument supplied for foreach() in hreflang_page_attachments() (line 35 of modules/contrib/hreflang/hreflang.module).

Will use the hook instead.

It's because content_translation is set with a weight of 10 on the install, so your hook_page_attachments() will always be run before. You should maybe use something like that to be serene:

function hreflang_module_implements_alter(&$implementations, $hook) {
  if ($hook == 'page_attachments' && isset($implementations['content_translation']))) {
    unset($implementations['content_translation']);
  }
}

Else move your code in a hook_page_attachments_alter() and remove the alternate hreflang generated by content_translation before to proceed with your own module code.

By the way, i guess there is no reason to use html_head_link, you should only use html_head. It's recommended to use only 1 method for the alternate hreflang (among the 3 methods: meta html, http header, sitemap xml / see the global SEO recommendations) and html_head_link generate meta html + http header.

And be aware of these issues:

#2945033: HtmlHeadLink processing does not allow for duplicated alternate hreflang links
>> so the key if you change for html_head, should be "your-module-name:rel:hreflang:href"

#2873648: With many languages, content_translation_page_attachments adds too many alternate links to the response headers crashing varnish (503)
>> one more reason, to only use html_head for the alternate hreflang...

By the way 2, there is no access checking on the alternate links you are generating (let said that for a page where FR is published but not the EN version, both alternate links (FR + EN (unpublished/403)) will be generated whatever the access rights).
For more info, see #2521782: HTML head has alternate hreflang links to unpublished translations

I will point these problematic later in the core issues too.

@raphaeltbm Thanks for the sleuthing :)

For info #2994800: Improve the alternate hreflang implementation. Cheers.

This solution, which is in the latest release did not work for me, for anyone else struggling, this solution worked to remove the duplicates https://www.drupal.org/project/metatag/issues/2993991

@sanskrit I actually added a test for this issue, so if you can write a failing test or provide steps to reproduce that would be helpful.