Thanks for the module! I found that x-default was missing and wanted to add it

Issue fork hreflang-3126993

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

vdsh created an issue. See original summary.

vdsh’s picture

Status: Active » Needs review
StatusFileSize
new836 bytes

This is quite straightforward, so I don't expect much issues, but feel free to let me know if I missed something

mfb’s picture

My take on x-default is that it was intended for language-neutral URLs, e.g. international landing pages where users choose their language, or pages that dynamically alter their content to match the user's language. It wasn't intended for pages that use the site's default language. I'm happy to hear other opinions on this though. See also discussion at #2376417: Add x-default.

vdsh’s picture

Thanks for your comment. From my understanding, it's recommended to always put a x-default in my case (which may not be everyone's case) where my interface / taxonomy is translated, but not everything (eg: description is never translated and could be in any language as user-generated)

From
https://support.google.com/webmasters/answer/189077?hl=en
it states an example of when it should be used (which is my case):

If you keep the main content in a single language and translate only the template, such as the navigation and footer. Pages that feature user-generated content, like forums, typically do this.
...
Use the x-default tag for unmatched languages
The reserved value hreflang="x-default" is used when no other language/region matches the user's browser setting. This value is optional, but recommended, as a way for you to control the page when no languages match.

Let's say we have 3 tags: hreflang="en", hreflang="fr", hreflang="de". How does google know which should be the 'best' page for italian speakers? (Well I guess google would propose the "en" one as more international, but would not hurt to put x-default anyway)

I don't think adding it could hurt, so we might as well always add it - but again, feel free to disagree :)

mfb’s picture

Status: Needs review » Needs work

This usage of x-default might work fine for your case, but it won't work for everyone. Other sites could setup a language-neutral page with a language switcher, a page that dynamically alters its content based on the user's location, or a page that redirects to a specific language based on the user's location.

For example, a site might might have "en" as the default language, and want to use these hreflang tags:

<link rel="alternate" hreflang="en" href="https://www.example.com/en" />
<link rel="alternate" hreflang="fr" href="https://www.example.com/fr" />
<link rel="alternate" hreflang="x-default" href="https://www.example.com/" />

You could instead make this optional: Add a setting that, if enabled, adds an x-default tag pointing at the default language.

In addition, the metatag you're creating is incorrect, it should be hreflang="x-default"

vdsh’s picture

StatusFileSize
new838 bytes

Thanks for the catch! It was supposed to be simply but I managed to mess it up. I recreated a proper patch.

I think your suggestion to add an option makes sense. I'll see to implement it when I'll get some more time.

Edit: There seems to be an issue with that latest patch but now my "en" hreflang gets removed somewhere for some reason. Not sure why exactly, I'll investigate

mfb’s picture

vdsh’s picture

Status: Needs work » Needs review
StatusFileSize
new3.19 KB

Thanks mfb for finding the right issue. Indeed, after applying patch in #2945033: HtmlHeadLink processing does not allow for duplicated alternate hreflang links, it solved the issue. I have added a new version of the page which adds a setting to the admin config page (not activated by default)

I tested it and it seems to work as expected: when checked, it adds x-default with the same url as the default language, and when unchecked, it doesn't add it.

mfb’s picture

@vdsh maybe you or someone else interested in this feature could review that core patch.. in hopes that it will be committed some day soon? :) Drupal 7 had the same problem IIRC

vdsh’s picture

StatusFileSize
new3.24 KB

Rerolled the patch #8 for latest release

alexverb made their first commit to this issue’s fork.

alexverb’s picture

Version: 8.x-1.3 » 8.x-1.x-dev

Created merge request. Same patch but also added a link under "Regional and language" at admin/config/regional/hreflang.

Needs review again. Also confirmed that the patch works properly with https://www.drupal.org/project/drupal/issues/2945033

mfb’s picture

Issue tags: +Needs tests

This will need a test

Hmm, hreflang settings could also go under "search and metadata" (it overlaps the two sections pretty perfectly :)

mfb’s picture

Status: Needs review » Needs work

Looks like the core issue is finally committed \o/ so this issue is ready once we have a test

mfb’s picture

Assigned: vdsh » Unassigned
Status: Needs work » Needs review

Rebased, made various tweaks and added tests

mfb’s picture

Issue tags: -Needs tests
mfb’s picture

Category: Task » Feature request

This MR is passing tests on core 9.3 and 9.2, and failing tests on 9.1 and 8.9, but that's to be expected based on which branches have #2945033: HtmlHeadLink processing does not allow for duplicated alternate hreflang links. Seems RTBC to me..

mfb’s picture

Ok, added a skip test statement for the new functionality on older versions of core. So we can verify that if someone running an unsupported version of core upgrades hreflang, this new functionality won't work but hreflang otherwise shouldn't be broken.

  • mfb committed 252cca9 on 8.x-1.x authored by alexverb
    Issue #3126993 by vdsh, alexverb, mfb: Add hreflang x-default
    
mfb’s picture

Status: Needs review » Fixed

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.