This is a major release introducing significant architectural changes, new features, and a complete UI redesign. Upgrading from 2.x requires reviewing the breaking changes listed below.

🚀 New Features

Webhook System

A fully integrated webhook system has been introduced, enabling real-time event notifications to external services whenever content changes occur within a space.

• Webhook Management UI – Create, update, enable/disable, and delete webhooks directly from the Space Settings panel.

• Supported Events – Webhooks can be subscribed to the following content lifecycle events:

  • content.published – fired when a content document is published.

  • content.unpublished – fired when a content document is unpublished.

  • content.deleted – fired when a content document is deleted.

  • content.updated – fired when a content document is updated.

• Configurable Headers & HMAC Signature – Each webhook supports custom HTTP headers and an optional secret for payload signature verification, allowing consumers to authenticate incoming payloads.

• Webhook Delivery Logs – Every webhook delivery is recorded with the HTTP status code, response time, and any error message, providing full observability into delivery history.

Token Permissions (V2 Tokens)

The token system has been redesigned to support granular, role-based access control.

• Token V2 – A new token version (version: 2) introduces an explicit permissions array, replacing the previous all-or-nothing token model.

• Permission Scopes – Five distinct permissions are now available:

  • TRANSLATION_PUBLIC – Access to published translations.

  • TRANSLATION_DRAFT – Access to draft translations.

  • CONTENT_PUBLIC – Access to published content.

  • CONTENT_DRAFT – Access to draft/preview content.

  • DEV_TOOLS – Access to developer tooling endpoints (space metadata, OpenAPI schema, translation management).

• Backward Compatibility – Existing V1 tokens (without a version field) are automatically treated as having TRANSLATION_PUBLIC, TRANSLATION_DRAFT, CONTENT_PUBLIC, and CONTENT_DRAFT permissions, ensuring zero downtime for existing integrations.

Translation Draft Version

Translations now support a distinct draft version, enabling a safer publication workflow.

• Draft API Access – The V1 CDN API supports a version query parameter; when set to draft, the TRANSLATION_DRAFT token permission is required.

• Version-Aware Cache Paths – The translation service now resolves locale-specific cache paths dynamically based on the requested version, consolidating cache management logic.

AI-Powered Locale Translation

New locale translation capabilities allow entire locale sets to be translated automatically using AI or Google Cloud Translation.

• Translation Locale Translate – A new background Cloud Function translates all translations in a source locale to a target locale for a given space, leveraging Google Cloud Translation API.

• Content Locale Translate – A corresponding function translates the locale-specific content of a single content document from a source locale to a target locale.

• AI Translation for Markdown Fields – Markdown-type schema fields are now eligible for AI translation, extending auto-translate coverage beyond plain text strings.

Translation Filter & Status

The Translations view has been enhanced with a rich filtering system.

• Filter by Translation Status – Translations can now be filtered by status: Translated, Partially Translated, and Untranslated.

• Filter by Locale Status – An additional Locale Translated / Locale Untranslated filter allows viewing per-locale completion state.

Content Unpublish

Content documents can now be explicitly unpublished through the Content Action Menu.

Space Danger Zone

A new destructive action has been added to the Space Settings Danger Zone panel, allowing administrators to permanently delete all translations within a space.

UI Version Check & Auto-Reload

The application now periodically checks whether a new deployment has been released. When a new version is detected, a non-intrusive notification is shown, prompting the user to reload the application to pick up the latest changes.

Localess CLI

Allow to interact with Localess API via CLI. Used to automate your project tasks, like :

• Translations: Sync, Pull and Push

• Schema type generation

🔄 Changes

Angular Upgrade to v21

The entire application has been upgraded to Angular v21, including all first-party packages. The upgrade brings improved performance, enhanced signal support, and updated compilation pipeline.

Complete UI Redesign with Spartan/Helm Component Library

The application UI has been comprehensively redesigned using the Spartan headless component library (@spartan-ng/brain) combined with Tailwind CSS, replacing the previous Angular Material-only approach for layout and structural components.

Content Model Enhancements

• Reference Resolution – The V1 CDN content endpoint now resolves references to full content objects and includes them inline in the API response.

• Link Resolution – The V1 CDN API populates links as a resolved map, enabling consumers to resolve internal links without additional API calls.

Schema Model Changes

• SchemaFieldAsset / SchemaFieldAssets – Both asset field types now support a single fileType filter in addition to the existing multi-type fileTypes array, simplifying schema definitions for fields that accept only one file type category.

• SchemaFieldOption / SchemaFieldOptions – Removed the deprecated source: 'self' option and the associated inline SchemaFieldOptionSelectable model. Option fields must now reference an external schema source, enforcing a cleaner separation between schema definitions and option data.

Cloud Build & Deployment Pipeline

The cloudbuild.yaml The deployment pipeline has been significantly improved:

• Automatic API Enablement – A new build step enables all required Google Cloud APIs (Cloud Functions, Cloud Run, Artifact Registry, Eventarc, Cloud Translation, etc.) at the start of every deployment, eliminating manual pre-configuration.

• Automatic Firebase App SDK Config – The Firebase Web App SDK configuration is now fetched dynamically from Firebase during the build using firebase apps:sdkconfig, replacing the previous approach of supplying seven individual Cloud Build substitution variables.

• Simplified Environment – The build:prod step no longer requires Firebase-specific substitution variables (_LOCALESS_FIREBASE_*), reducing configuration overhead for new deployments.

• CORS Configuration Removed – The manual gsutil cors set step has been removed; CORS is now managed entirely within Firebase configuration.