Skip to content

02 · Locale translations of component defaults change the component version, pages fail with "The requested version … is not available"

Project Canvas
Component Config management / translation
Category Bug report
Priority Major
Status Reported upstream as #3592151

Problem/Motivation

Canvas derives a component's version from a hash of its versioned_properties.*.settings, which include example values/defaults of props. Pages store the version they were built with.

Locale translates a string wherever it occurs as translatable configuration – including these versioned settings. When a site imports a translation for a string that is also the default of a component (e.g. "Webform", the default label of the Webform block component), the settings change, a new version hash is computed, and existing pages point to a version that no longer exists. The page then fails with a 500 error: "The requested version … is not available".

This makes it impossible to safely import community translations (localize.drupal.org) on a site built with Canvas.

Steps to reproduce

  1. Install Drupal CMS with the Haven site template in German (or English, then add German).
  2. Import a German translation for the string "Webform" (e.g. via interface translation).
  3. Visit the front page: 500 error "The requested version … is not available".

Proposed resolution

Translations must not change the component version. Options: - compute the version hash from the source-language (untranslated) settings, or - mark versioned_properties settings as not translatable in the config schema.

Remaining tasks

  • Decide the approach, patch, add a test that imports a translation for a component default and asserts the version is unchanged.

Additional information

Workaround in dcle: all strings occurring in versioned settings of used components are kept out of locale; where the same strings appear as page content, they are translated directly ("content-only" translations).

Copy to drupal.org

Issue title:

Locale translations of component defaults change the component version, pages fail with "The requested version … is not available"

Issue summary (paste it into the "Issue summary" field; project, component, category and priority are in the table above):

<h3 id="summary-problem-motivation">Problem/Motivation</h3>
<p>Canvas derives a component's version from a hash of its <code>versioned_properties.*.settings</code>, which include example values/defaults of props. Pages store the version they were built with.</p>
<p>Locale translates a string wherever it occurs as translatable configuration – including these versioned settings. When a site imports a translation for a string that is also the default of a component (e.g. "Webform", the default label of the Webform block component), the settings change, a new version hash is computed, and existing pages point to a version that no longer exists. The page then fails with a 500 error: "The requested version … is not available".</p>
<p>This makes it impossible to safely import community translations (localize.drupal.org) on a site built with Canvas.</p>
<h3 id="summary-steps-reproduce">Steps to reproduce</h3>
<ol>
<li>Install Drupal CMS with the Haven site template in German (or English, then add German).</li>
<li>Import a German translation for the string "Webform" (e.g. via interface translation).</li>
<li>Visit the front page: 500 error "The requested version … is not available".</li>
</ol>
<h3 id="summary-proposed-resolution">Proposed resolution</h3>
<p>Translations must not change the component version. Options:
- compute the version hash from the source-language (untranslated) settings, or
- mark <code>versioned_properties</code> settings as not translatable in the config schema.</p>
<h3 id="summary-remaining-tasks">Remaining tasks</h3>
<ul>
<li>Decide the approach, patch, add a test that imports a translation for a component default and asserts the version is unchanged.</li>
</ul>
<h3>Additional information</h3>
<p>Workaround in <code>dcle</code>: all strings occurring in versioned settings of used components are kept out of locale; where the same strings appear as page content, they are translated directly ("content-only" translations).</p>