Canvas Translate supports page variants and requires Canvas 1.11

Summary

Canvas 1.11 replaces theme-wide page regions with page variants. Its update converts the default theme's enabled regions into one theme_<theme> page variant and makes it the default. Canvas Translate now translates page variants, shown as "Page template" in the dashboard, and moves translation work that was still on the page regions to that variant.

Canvas Translate now requires Canvas 1.11 or later (canvas:canvas (>=1.11.0), drupal/canvas: ^1.11.0).

What changes for sites

• Page variants can be translated in the translation workspace, like content templates.
• Page regions no longer appear in the dashboard once Canvas has set a default page variant (canvas.settings:default_page_variant), because they no longer render.
• When Canvas creates the theme_<theme> variant, Canvas Translate moves the regions' translation state to it, matched by component UUID:
  • Unpublished translation drafts move to the variant. A draft the variant already has wins.
  • Approvals move only if every moved draft was approved and the variant had no draft of its own. Approvals of drafts that change during the move are cleared.
  • Published region translations the variant's override lacks are added. The variant's own translations win.
• The region translations themselves are left in place. Canvas owns region cleanup.

Upgrade path

The move runs from two places:

• hook_page_variant_insert(), when Canvas creates a theme_<theme> variant while this version is installed (Canvas's update, or enabling Canvas for a theme later).
• canvas_translate_post_update_0002_move_page_region_translations(), for sites that updated Canvas first and kept translating regions with an older Canvas Translate.

Both are safe to run more than once.

canvas_translate_post_update_0001_align_page_variant_uuids() gives each theme_<theme> variant the UUID it has in the config sync directory. Each site's Canvas update creates that variant with its own UUID, so without this a config import would delete and recreate the variant, and core would delete its published translations with it.

Deploying with configuration management

Run database updates before importing configuration, as drush deploy does:

1. On a development site, update Canvas and Canvas Translate, run drush updb, then export configuration with drush cex.
2. Deploy the code and that export, then run drush deploy.

Re-export configuration after drush updb. A config import does not move region translations to the variant: an export taken before the update still carries the regions' translations, and importing it puts them back on the regions only. A variant created by a config import keeps exactly the translations in the export.