Provide link tags to alternate languages (hreflang) in HTML head

Tagged, moved to a task and updated issue summary with template

+++ b/core/modules/content_translation/content_translation.module
@@ -872,3 +872,77 @@ function content_translation_save_settings($settings) {
+function content_translation_get_langcodes($entity) {

This logic is VERY convoluted. Instead IMHO you should use getTranslationLanguages() which gets you all the right languages :)

This looks as good as it can be as far as I see for the code (if it works :D). As for tests, NodeTranslationUITest has nodes translated in various languages and already tests for read more, comment, etc. links. You could test the node pages there for the alternate links as well, should only be a few lines added there.

As for the fails, looks like getOption() on the route may return null if there was no such option. So blindly foreach()ing on it would not work.

We usually couple patch updates on drupal.org with interdiffs, so it is easier to review what changed. It may look too much for such small patches, but it would still help a lot. See https://www.drupal.org/documentation/git/interdiff I think you changed this:

+  foreach ($route_match->getRouteObject()->getOption('parameters') as $name => $options) {

to this:

+  if (!empty($route) && !empty($parameters = $route->getOption('parameters'))) {
+    foreach ($parameters as $name => $options) {

That makes sense. :) Using an interdiff, it is much easier to tell.

Looking forward to test results.

From http://php.net/manual/en/function.empty.php

Prior to PHP 5.5, empty() only supports variables; anything else will result in a parse error. In other words, the following will not work: empty(trim($name)).

Drupal requires PHP 5.4.x, 5.5 is not required, so this should work with 5.4.x.

Putting on sprint board, since you are working on this :)

This looks very good except this small bit:

+++ b/core/modules/node/src/Tests/NodeTranslationUITest.php
@@ -315,6 +318,26 @@ protected function doTestTranslations($path, array $values) {
+        $link = '<link rel="alternate" hreflang="' . $altlangcode .'" href="' . $url . '" />';
+        $this->assertRaw($link, format_string('The %langcode node translation has the correct alternate hreflang link for %altlangcode: %link.', array('%langcode' => $langcode, '%altlangcode' => $altlangcode, '%link' => $link)));

There is a bit too much concrete markup assumption about how Drupal formats these tags exactly, down to the number of whitespace... If you use an xpath expression, you can test essentially the same thing but with more room for Drupal to adjust markup without needing to fix every detail in tests. Eg. something like

    $links = $this->xpath('//link[@rel = 'alternate' and @href = :href and @hreflang = :hreflang]', array(':href' => $url, ':hreflang' => $altlangcode));
    $this->assert(isset($links[0]), format_string(....)));

Good job! :)

Looks good to me now. Thanks!

Glad to see you were able to locate the right bracket after which to break: ;-)

+                );
+              }
+            }
+          }
+          break;
+        }
+      }
+    }
+  }
+}

You can avoid excessive nesting by using (1) negated conditions (+ continue; if applicable) and/or (2) early-returns.

Something like this?

EDIT: @paulmckibben Ahhh! I crossposted with you, and I didn't notice you were assigned. Sorry :(

+++ b/core/modules/system/src/Plugin/Block/SystemPoweredByBlock.php
@@ -25,6 +26,9 @@ class SystemPoweredByBlock extends BlockBase {
   public function build() {
+    $entity = Node::load(1);
+    $language = 'asdf';
+    $foo = $entity->urlInfo()->setOption('language', $language)->setAbsolute()->toString();

Whoops. My test code snuck in there.

Thanks for reformatting the code for even better readability :) Yay for machine parseable output.

Testbot ate that run.

What about a view that is translated?

+++ b/core/modules/content_translation/content_translation.module
@@ -833,3 +833,43 @@ function content_translation_save_settings($settings) {
+    // Only add links for the first content entity found.
+    return;

How come we do this? When do we find more than one content entity? Perhaps the comment needs updating to say don't check anymore parameters after we've found the one we're looking for :)

When rewriting the code, the break called out in #22 from the patch in #17 became a return.
I added the comment because that's what it does, I'm not sure if it was intended.

I was confused by @alexpott's reference to views - which shouldn't apply here; except if the view itself would be translated (disregarding translatable entities within).

The quoted condition, however,

+    // Only add links for the first content entity found.
+    return;

…seemingly tries to address a different problem space: If the current route contains multiple upcasted entity parameters, then we don't know what the "actual" (primary) entity of the current page is; e.g.:

/node/{node}/revisions/{node_revision}

So we "blindly" choose the first, in the hope that it's the actual/primary. (which isn't necessarily the case, as e.g. in aforementioned node revision route example)

@alexpott: a view that is translated in itself does not really guarantee that that page will have language alternate content. That would be assuming quite a bit about how that view is built. Eg. that it is dependent on the page's language. That a view has some of its config translated does not guarantee it actually is displaying language dependent data.

@sun: do you know a way to tell the "primary" entity on the route from the "non-primary" one(s)?

@paulmckibben: well, looks like we need the comment updated as per #32.

I think we cleared out above that config entities are not really suitable for this. Also that there is no way to tell which part of the route should be the primary entity, so we don't have a better way but to pick the first. The requested comment update was done, so moving back to RTBC.

Committed 2e7b455 and pushed to 8.0.x. Thanks!

@Gábor Hojtsy and I discussed whether or not there should be an alternate link to the same language as currently being viewed.

14:30 GaborHojtsy
alexpott: according to http://www.w3.org/TR/2014/PR-html5-20140916/links.html#rel-alternate
14:30 GaborHojtsy
"If the alternate keyword is used with the hreflang attribute, and that attribute's value differs from the root element's language, it indicates that the referenced document is a translation."

diff --git a/core/modules/node/src/Tests/NodeTranslationUITest.php b/core/modules/node/src/Tests/NodeTranslationUITest.php
index fa2e8fc..9c0ffac 100644
--- a/core/modules/node/src/Tests/NodeTranslationUITest.php
+++ b/core/modules/node/src/Tests/NodeTranslationUITest.php
@@ -339,11 +339,11 @@ protected function doTestAlternateHreflangLinks($path) {
     }
     foreach ($this->langcodes as $langcode) {
       $this->drupalGet($path, array('language' => $languages[$langcode]));
-      foreach ($urls as $altlangcode => $url) {
+      foreach ($urls as $alternate_langcode => $url) {
         // Retrieve desired link elements from the HTML head.
         $links = $this->xpath('head/link[@rel = "alternate" and @href = :href and @hreflang = :hreflang]',
-          array(':href' => $url, ':hreflang' => $altlangcode));
-        $this->assert(isset($links[0]), format_string('The %langcode node translation has the correct alternate hreflang link for %altlangcode: %link.', array('%langcode' => $langcode, '%altlangcode' => $altlangcode, '%link' => $url)));
+          array(':href' => $url, ':hreflang' => $alternate_langcode));
+        $this->assert(isset($links[0]), format_string('The %langcode node translation has the correct alternate hreflang link for %alternate_langcode: %link.', array('%langcode' => $langcode, '%alternate_langcode' => $alternate_langcode, '%link' => $url)));
       }
     }
   }

I updated the variable name on commit since $altlangcode should be snaked.

Superb, thanks for sticking around on this @paulmckibben, this should be a great move to Drupal 8 multilingual SEO!

It's not clear to me why the hreflang link tags should only be generated for translated entities. Other pages, such as views, and untranslated content with a translated user interface, need them too.

For another solution, this module adds hreflang link tags to all pages on the site: https://www.drupal.org/project/hreflang

@mfb please file new feature request for 8.1.x branch!

Should this not be in the head of the html page? The language switcher is not in the of the page, that is what the description on the google page requires.