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¶
- Install Drupal CMS with the Haven site template in German (or English, then add German).
- Import a German translation for the string "Webform" (e.g. via interface translation).
- 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>