Problem/Motivation

Since #3247275 (related #3272202) the 403 and 404 defaults ship with canonical_url and shortlink set to <none>, and a post update sets the same values on existing sites.

The tag values use schema type text, so they’re translatable, and <none> ends up on localize.drupal.org as a regular string, which in Dutch has been translated as -geen- for a long time in many projects as a UI label. So this translation gets used instead of <none> in versions 2.2.2 and 2.2.3.

Metatag only treats the literal <none> as "don't output this tag", so the translated value is output as is. On a 404 page that uses the defaults (so not a node as error page) this ends up in the head:

<link rel="shortlink" href="-geen-" />
<link rel="canonical" href="-geen-" />

Steps to reproduce

  1. Use a site with a non-English default language (Dutch for example) and the locale module, with interface translations imported.
  2. Update to Metatag 2.2.3 and run drush updb.
  3. Import translations (drush locale:check && drush locale:update).
  4. Run drush config:get metatag.metatag_defaults.404 tags.

Expected: <none>. Actual: -geen-.

Tested on Drupal 11.4.11 with Metatag 2.2.3.

Proposed resolution

Workaround for now: translate <none> as <none> and import the config again.

AI disclosure

AI was used to help trace the cause and help test the output. I reproduced the config change myself.

Issue fork metatag-3633586

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:

About issue forks

Comments

joshuaramaekers created an issue. See original summary.

d.steindl made their first commit to this issue’s fork.

d.steindl opened merge request !312

d.steindl’s picture

d.steindl commented

Confirmed on 2.2.x (2.2.6) with German: <none> becomes - keine -, the same as -geen- in Dutch.

Cause: the URL tags' values are schema type text without a translation context. locale looks up a translatable config string by source + context, so the shipped <none> ("do not output the tag") is found under the interface string <none> and replaced with its translation.

The MR gives canonical_url and shortlink their own translation context, 'Metatag URL', the same approach core uses for date formats (translation context: 'PHP date format'). The values stay translatable, so a real canonical URL can still differ per language, but they never pick up an interface translation. I'd rather not use the workaround from the summary (translating <none> as <none>): it changes the interface string everywhere <none> is shown, and every site and language has to apply it.

For sites that already have the translated value, metatag_post_update_v2_07_error_page_defaults_untranslated_none() puts <none> back, but only where the value is exactly the locale translation of <none> in that language, in the active configuration and in language overrides. Values set on purpose are left alone, and it does not run a general locale update that could overwrite edited defaults.

MetatagNoneTranslationTest (kernel) reproduces both cases on a Dutch site with <none> → -geen-: translating the shipped defaults keeps <none>, and the update restores it without touching a deliberately set URL. Both tests fail without the change, and the full kernel suite passes.

damienmckenna’s picture

damienmckenna
Location TN, USA
commented
Status: Active » Needs review

Thank you for putting that MR together, I'll review it shortly.

damienmckenna’s picture

damienmckenna
Location TN, USA
commented
Status: Needs review » Reviewed & tested by the community
Parent issue: » #3635565: Plan for Metatag 2.2.7

I tested the changes and confirmed that it resolved the problem - thank you.

damienmckenna’s picture

damienmckenna
Location TN, USA
commented
Status: Reviewed & tested by the community » Fixed

Committed.

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.