# Translation Handling Initiative<br>Team Meeting Minutes [← Back to the overview](https://notes.typo3.org/s/f3ae8fZSD) - **Date:** 2026-10-23<br> - **Where:** [Slack Huddle](https://app.slack.com/huddle/T024TUMLZ/C05D7UF1L8M) - **Participants:** - André Buchmann - Eric Harrer - Martin Clewing ## Topic 1: Structure-Layer Proof of Concept and Migration Safety André demonstrated the [structure-layer proof of concept](https://github.com/t3thi/structure-layer), developed with Claude using the initiative's documentation. It hides language `0` from normal editorial work and treats it as a structural reference, while actual content resides in equally ranked language variants from `1` onwards. Existing Default Language content would need to move into a real language layer. The prototype deliberately leaves wider changes such as `BCP 47` identification outside its immediate scope. André described a lifecycle rule requiring pages to have at least one real-language translation, with cleanup for pages existing only in the hidden `0` layer. The DDEV demo command resets the existing database and creates test data and site configuration. André reported that a migration command also existed but had not yet been tested. Eric distinguished it from an Upgrade Wizard suitable for existing installations. André warned against production use and questioned whether migration back would be feasible. The demonstration did not establish a production-ready migration path. ## Topic 2: Editing Language and Comparison-View Navigation The prototype lets editors switch the Page Tree into their Editing Language. When a page is unavailable in that language, it displays another available language with an indication of its origin. André explained that this backend display fallback follows site-configuration order. Eric suggested a configurable preference, for example preferring US English over German when British English is unavailable. They left that refinement outside the immediate scope. In Language Comparison, changing the Editing Language changes the leading column, and content can be created in each language without exposing a Connected Mode control. The participants also observed gaps: selecting a language without a page translation could leave an empty view, and comparison-language selections were lost when switching between Layout and Language Comparison. They wanted the previous selection retained rather than requiring editors to select all or reconstruct a custom selection repeatedly. Eric proposed reporting that reset behavior as a separate Core issue and considered a fix for v15 and potentially v14 appropriate, subject to investigation. They agreed that the Editing Language should always appear in Language Comparison, including a warning and a page-translation action when its translation is missing. On that condition, it should no longer be selectable or deselectable in the comparison-language multi-select. Otherwise, deselecting it could unexpectedly switch the Editing Language. The missing-page translation action should be as visible in comparison columns as in the single-language Layout view. ## Topic 3: Editing Context, Language Selection, and Multisite Behavior The prototype changes the Editing Language when an editor changes the language in Layout. André favored retaining that familiar behavior, with the Page Tree and editing view moving together. Eric argued for remembering the working source independently: an editor translating English into Chinese might temporarily inspect Chinese-only content in Layout but still expect English to remain the leading language when returning to Language Comparison. The participants considered the trade-off between familiar interaction and an independently remembered editing context. André did not see implementation complexity as a blocker but wanted stronger editorial evidence. Eric suggested interviewing an experienced multilingual editor, such as Daniel Held. André preferred keeping the proof of concept simple and presenting independent context persistence as a possible later feature or choice for Core discussion rather than implementing it immediately. They also considered moving the language control into the top toolbar and removing the duplicate Layout selector. This would distinguish the overall editing context from the multi-select used to choose comparison columns. André clarified that the prototype remembers a separate Editing Language for each site. Its menu groups languages by site rather than treating matching numeric IDs or labels as globally identical. This avoids choosing a language unavailable in another site. The demonstration still needed clearer site headings and usable names instead of configuration keys; menu size with many sites remained a concern. The discussion also noted that manually edited site configuration can undermine the consistency encouraged by the existing language-ID interface. ## Topic 4: Structure-Layer Inspection and Structural Permissions A development-only “Show Structure Layer” control exposed the hidden `0` layer for debugging and migration inspection. André did not want that control included in an initial Core integration. They considered administrator-only access; Eric considered a later inspection feature useful only if the layer were reliably read-only: no editable fields, creation controls, or other route through which editors could manipulate machine-maintained structure. Interface changes alone would not be sufficient protection. They explored creating structural blueprints before language content exists, but questioned whether that would require direct access to the structural layer at all; disabled content in a real language might already serve that purpose. The idea remained speculative, with no v15 or v16 commitment. Eric separately proposed distinguishing permission to translate from permission to change structure, for both human editors and automated translation. Workspaces were discussed but did not remove his interest in an explicit permission boundary. They retained this as a later feature idea, not a prerequisite for the initial prototype. ## Topic 5: All-Language Visibility Actions Without an Additional Field André demonstrated a convenience action that enables or disables related language variants by writing their existing `hidden` values. He related this to the earlier proposal to replace the Strict/Free output distinction through explicit editorial updates. Eric pointed out that toggling all variants overwrites their individual visibility choices; toggling back does not restore a previously mixed selection. Eric considered a separate all-language hidden field that would override individual visibility without replacing it. André opposed adding another field and corresponding Core and extension query handling for a convenience operation. Eric accepted that argument, and the participants explicitly chose not to introduce the additional field. They agreed to move the all-language operation into the context menu rather than display a second prominent toggle, reducing accidental changes while retaining a deliberate bulk action. They also favored removing the redundant all-languages-hidden label: the existing visibility control and visual state already show whether each language variant is active. The operation would continue to change individual records rather than retain a separate overriding state. ## Topic 6: Language Zero and Site-Configuration Validation André presented [Gerrit change 97053, “Use language 0 as default language of a site”](https://review.typo3.org/c/Packages/TYPO3.CMS/+/97053), supplied by Benni. The discussed revision prefers language `0` regardless of configuration order but otherwise takes the first configured language. André wanted an error when `0` is absent rather than that fallback and reported that Benni had invited him to update the patch. Eric supported retaining a dependable `0` reference and avoiding additional migration complexity. André contrasted this with his older attempt to make the Default Language ID configurable, which he no longer intended to pursue. He considered removing the deeply embedded `0` assumption unrealistic. The structural-layer prototype instead retains that internal reference while removing its role as an editor-maintained content language. André planned to add the validation and share the updated change; this was not presented as already merged behavior. ## Topic 7: Missing-Translation Placeholders and Contextual Translation Actions The prototype displays an existing language's title and flag where a target-language content variant is missing. Eric noted that showing only one source can suggest that no other source translation exists. They considered making that display depend on the Editing Language, while recognizing that content may be missing there too. A neutral “available in other languages” indication with a translation action was another option. They proposed a per-record Translate button that opens the existing translation wizard with the content record already selected. Only source-language selection would remain where multiple sources are available; the record-selection step could be skipped. They also discussed the visibility of page-translation and deletion actions in Layout. During testing, previously translated and deleted content appeared to affect which wizard steps were shown. They treated this as something to investigate rather than an explained prototype feature. ## Topic 8: Source-Language Restrictions and Deleted Sources During the demonstration, the participants described as existing Core behavior a restriction whereby an initial content translation can fix the source language for later translations on that page. They observed that this could prevent translating a remaining element existing only in another language. They weighed consistent source-language workflows against flexibility and discussed the risk of source drift when editors translate through successively changed language variants. A practical counterexample concerned adding US English after German and British English: choosing German for the first US-English translation can prevent later use of the more suitable British-English source. Possible permission or TSconfig controls were discussed, but no configuration contract was selected. Eric favored preserving existing restrictions in the initial scope and treating flexibility as a separate feature. André noted that per-record Translate buttons would make the limitation particularly visible and argued for allowing the corresponding source choice. They did not resolve that wider product trade-off. They also tested deleting the original source translation and questioned references and source restrictions that remained afterwards. Eric proposed reporting a separate issue and clearing references to source records that no longer exist, rather than preserving meaningless IDs. Cleanup of the prototype's structural records also required attention. The discussion did not establish the full cause or a verified Core fix. ## Topic 9: Removing Site Languages and Deferred Data Cleanup The participants distinguished deleting a page translation from removing a language in site configuration. Eric initially described cascading deletion of page-translation content, then clarified that changing site YAML does not itself run a corresponding database cleanup through `DataHandler`. Records can therefore remain after a configured language is removed. They considered a separate consistency check or cleanup job rather than an expensive deletion process on every site-configuration save. Eric questioned offering language removal without a corresponding Core cleanup route; André mentioned `EXT:dbdoctor` and project-specific commands or Upgrade Wizards. Integrating this into Database Compare was also discussed, then distinguished from its existing schema-level responsibility. André emphasized that safe cleanup must resolve each record's site through its page and rootline, because the same language ID may still be valid elsewhere. Custom relations and project-specific data further complicate a universal solution. They deferred this longstanding cleanup problem and kept the hidden structural layer and editorial workflow as the immediate priority.