Clarify the task and decision
This guide turns typo3 implementation guide into a reviewable operating workflow. It connects domain decisions, ownership, evidence, and acceptance so the result continues to work in production.
Model accessible-language versions as governed records connected to their source content and workspace approval.
Practical workflow
- 1
Inventory source types, identifiers, fields, locales, owners, and publication states.
- 2
Choose the delivery pattern from volume, latency, editorial control, and failure tolerance.
- 3
Map the source record to a separate language-version record with durable linkage.
- 4
Add authentication, idempotency, retry, cache invalidation, logging, and access controls.
- 5
Test publication, source changes, unavailable results, rollback, keyboard operation, and monitoring before release.
Worked example or tool
A TYPO3 workspace example covers field mapping, translation relations, deployment, and invalidation. In the tool, also record the baseline, owner, decision, evidence, open issue, and approval date. Use a real page or transaction so the team sees dependencies, exceptions, and the maintenance work that follows release.
| Decision point | Record | Acceptance criterion |
|---|---|---|
| Baseline | Observed current state | Source and date recorded |
| Decision | Selected option and rationale | Risk and audience considered |
| Evidence | Test, document, or measure | Reviewable and version-specific |
| Approval | Name, role, and date | All mandatory criteria met |
Model language versions as governed records
Use a dedicated content record or page type for an accessible-language version and connect it to the source with an immutable relation. Store source UID, source workspace revision or content hash, target locale, language mode, transformation result ID, review state, glossary version, approvers, and last verified date. Keep this relationship separate from TYPO3’s ordinary locale translation relation when the version changes structure or information density rather than only language.
Map structured source fields deliberately. Preserve headings, paragraphs, lists, links, tables, notices, downloads, and contact blocks as semantic elements. Define a safe fallback for each unsupported content element: retain it with a reviewer warning, replace it with an approved summary component, or block generation. Never drop an unknown element silently. File references and links keep their identifiers so validation can detect changed or deleted dependencies.
| Record field | Purpose | Required behaviour |
|---|---|---|
| source_uid | Connects version and source | Immutable relation with permission check |
| source_revision | Detects source changes | Marks approved version for review when different |
| review_state | Controls workflow | Transition restricted by backend role |
| result_id | Supports traceability | Stored with settings and request time |
Use workspaces for generation, review, and approval
Create the generated result in a controlled workspace, never directly in the live workspace. A generation role may request and update drafts. A subject reviewer confirms conditions, figures, dates, responsibilities, and links. A language reviewer checks the selected mode and rendered journey. A publisher verifies resolved findings and moves the approved revision through the established workspace stage. Enforce these capabilities in backend permissions and server-side transition logic.
Configure stage notifications with record URL, source revision, risk level, required role, and due date. Reviewers need a meaningful diff that distinguishes content changes from TYPO3 metadata noise. If the source is edited while review is open, mark the version stale and require the team to choose between rebasing the draft or completing an explicitly recorded exception. The system must prevent a stale approval from reaching live.
- 1
Create or identify the source record and capture its workspace revision.
- 2
Generate the structured version into the assigned workspace.
- 3
Complete subject, language, and link validation on the rendered preview.
- 4
Resolve findings and confirm that the source revision is still current.
- 5
Publish the approved record and retain the complete workspace history.
Deploy and invalidate without losing approved content
Create route enhancers and page metadata that give every version a stable, readable URL. Publish reciprocal language links and canonical relationships in server-rendered markup. Include the version in site search and XML sitemaps only after approval. Configure access restrictions explicitly and verify that a public language page does not inherit an unintended source-page restriction or expose protected source content.
Invalidate the correct frontend caches when the approved version, source, referenced file, shared content element, rendering template, or glossary changes. Use cache tags that include both source and version identifiers. During generation or review, continue to serve the last approved record. A failed request creates a visible backend task and operational event, but it does not purge a valid public page or replace it with a draft.
Every public version has a stable route and reciprocal source link.
Search and sitemap include approved records only.
Cache tags cover source, version, shared elements, files, and renderer.
Protected sources cannot leak through generated public records.
The last approved record remains available during failures and review.
Operate the extension through TYPO3 upgrades
Test the extension against the supported TYPO3 long-term-support versions, PHP versions, database, multilingual configuration, workspaces, scheduler, search extension, and caching layer. Automated integration tests should cover backend permission checks, DataHandler hooks, relation persistence, workspace transitions, cache invalidation, API failure, and stale-source detection. Browser tests cover backend keyboard operation and frontend navigation at representative widths.
Before release, document scheduler jobs, queue monitoring, credential rotation, log retention, backup and restore, schema migration, and safe extension disablement. Perform upgrades first on a production-like staging copy and verify old approved records before creating new ones. Acceptance includes a successful rollback of both extension code and database migration, with published content still available and its audit history intact.
Roles, evidence, and approval
Keep generation separate from publication. A successful response is a draft, not an approval. Store the source identifier and version, transformation settings, result identifier, review state, approver, and publication time. When the source changes, mark the language version for review instead of silently replacing approved content. This makes rollback and audit possible across platforms.
Operations and maintenance
The work does not end at publication. Link the language version or configuration to its source, monitor quality and service measures, and define concrete review triggers. Triggers include source changes, legal changes, new audience needs, recurring support questions, technical changes, and incidents. A named owner evaluates the trigger, opens a new revision when needed, and records renewed approval.
Release checklist
The integration uses durable source identifiers.
Credentials are stored server-side and rotated.
Timeout, retry, and rate-limit behavior are defined.
Repeated requests are idempotent.
Generated content enters a review state.
Source changes invalidate or reopen the version.
Language navigation works by keyboard and assistive technology.
Monitoring covers failures, queues, latency, and stale content.