Ich habe ein 11er Typo3 auf ein 13er geupdated - lief alles glatt durch, soweit auch keine Probleme. Nun tritt in der englischen Sprache aber ein seltsames Verhalten auf. Der Kunde hat einen bestehenden Datensatz, zB Galerie, in deutsch und englisch. Er hat den deutschen Datensatz nun angepasst und Bilder hinzugefügt - nun möchte er aber nicht, dass er diese Bilder auch in englisch jedes Mal warten möchte. Also dachte ich mir, ich stelle beim deutschen Datensatz unter SPRACHEN auf ALLE (-1) und blende den englischen Datensatz aus. Jedoch bleibt auf der englischen Seite dann der englische Datensatz im FRontEnd sichtbar, obwohl ich ihn ausgeblendet habe. Momentan finde ich den Wald vor lauter Bäumen nicht. Hat jmd. evtl. eine Idee oder einen Ansatz, warum dies so ist, wo ich nachschauen könnte. Das Übersetzungsverhalten im SiteManagement steht bei der englischen Sprache auf STRIKT. Vielen Dank und LG

Vorab ein paar Fragen zu deinem Anwendungsfall: 1) Haben die Inhaltselemente der deutschen und englischen Sprache eine Verbindung zueinander? → Feld `l18n_parent == 0` → "Freier Modus" im Seite-Modul ODER → Feld `l18n_parent > 0` → "Verbundener Modus" im Seite-Modul 2) Beziehst du dich mit der Aussage: > Also dachte ich mir, ich stelle beim deutschen Datensatz unter SPRACHEN auf ALLE (`-1`) und blende den englischen Datensatz aus. auf das `tt_content`-Inhaltselement selbst oder auf die darüber referenzierten Bilder-Datensätze? 3) Falls du dich auf die Bilder-Datensätze beziehst: Wie werden diese aus dem Inhaltselement heraus referenziert. → Sind es IRRE-Relation oder MM-Relationen, etc? Falls es eine öffentliche Extension ist benenne diese, damit der Fall eindeutig ist. ___ Zum nachvollziehen habe ich eben mal mit folgender Sprachen-Konfiguration in der Site Configuration gearbeitet: ```yaml - base: / enabled: true fallbackType: strict fallbacks: '' flag: de hreflang: '' languageId: 0 locale: de_DE navigationTitle: Deutsch title: German websiteTitle: 'Deutsche Website' - base: /en/ direction: ltr enabled: true flag: us hreflang: en-US iso-639`-1`: en languageId: 1 locale: en_US.UTF-8 navigationTitle: English title: English typo3Language: default websiteTitle: 'English Website' ``` DB-seitig habe ich folgenden Zustand getestet: [upl-image-preview uuid=c13ac612-ca1e-4ca0-a1e6-7623db079d72 url=https://t3forum.net/assets/files/2025-09`-1`8/1758178298-299532-bildschirmfoto-2025-09`-1`8-um-085101.png alt={TEXT?}] 1. Es wurde also in der Standard-Sprache `0` (Deutsch) ein Bild-Contentelement mit Bildreferenz angelegt. 2. Danach wurde dieses Element in die Sprache `1` (Englisch) übersetzt. 3. Anschließend wurde das Element der Standard-Sprache `0` (Deutsch) auf `-1` "Alle Sprachen" umgestellt. 4. **Unabhängig davon ob das Element der Sprache `1` (Englisch) aktiviert oder deaktiviert wurde** wird beim Aufruf der englischen Sprache im Frontend das Element der Sprache `-1` ausgegeben. Eine doppelte Ausgabe von "Alle Sprachen" `-1` und "Englisch" `1` bzw. die Anzeige der englischen Übersetzung kann ich in diesem Zustand nicht feststellen. Wenn man jedoch in den "Freien Modus" wechselt, also in der Englischen Übersetzung das Feld "Transl.Orig" `l18n_parent` auf `0` stellt, dann werden in der englischen Übersetzung - der Definition nach logischer Weise - sowohl der "Alle Sprachen" `-1` Datensatz als auch der "Englisch" `1` Datensatz ausgegeben. Wenn ich in diesem Zustand den "Englisch" `1` Datensatz deaktiviere wird nurnoch der "Alle Sprachen" `-1` Datensatz ausgegeben, also erwartbares Verhalten an dieser Stelle. Wie du siehst tue ich mich aktuell schwer deinen Anwendungsfall nachzustellen. Gebe am besten noch weitere Informationen z.B. auch zur exakten verwendeten TYPO3-Version (vielleicht ist es ein alter Bug) und zu den Details der getesteten Datensätze (insbesondere mit den relevanten TCA-Konfigurationsabschnitten). ___ Aus der Arbeit in der [TYPO3 Translation Handling Initiative](https://typo3.org/community/teams/typo3-development/initiatives/translation-handling) kann ich generell schon mal sagen, dass `-1` als Spezial-Identifikator für Sprachen künftig **abgeschafft wird**. Stattdessen streben wir an, dass Inhalte, die ehemals das Verhalten aus der Sprache `-1` hatten, automatisiert über alle Sprachen hinweg synchronisiert werden, also tatsächlich in jeder Sprache als dedizierte Datensätze vorliegen. Das erlaubt auch Klarheit hinsichtlich der Sortierung der Datensätze in der jeweiligen Sprache, was mit `-1` Datensätzen nicht zuverlässig funktionieren kann. Die Funktion "Sprache Alle" wird dann voraussichtlich über ein Bool-Flag im Datensatz der Standardsprache umgesetzt, jedoch nicht mehr über einen Spezialwert im [Sprachen-Identifikationsfeld](https://docs.typo3.org/m/typo3/reference-tca/main/en-us/Ctrl/Index.html#confval-ctrl-languagefield) (i.d.R. `sys_language_uid`).

Hallo Eric, Danke für Deine schnelle Antwort und Danke für Deine Arbeit die Du Dir da immer wieder antust. Um den Anwendungsfall ein wenig genauer zu veranschaulichen. Im 11er Typo3 hatte ich mit MASK gearbeitet, da gab es auch nie Probleme mit der Anzeige, oder der Kunde hat es nicht bemerkt, obwohl er sich selbst als perfektionistisch bezeichnet und immer wieder die Homepage kontrolliert, Standard- wie auch alle Fremdsprachen. Nach dem Update, viel dann auf einmal auf, dass in den Fremdsprachen alle COLLECTIONS die Standardsprache anzeigen, aber nur diese Elemente, alle anderen MASK Elemente waren korrekt übersetzt. Stellte ich dann auf FREIEN MODUS um, war alles soweit perfekt, ich musste nur ein paar andere Datensätze anpassen, damit diese in den Fremdsprachen korrekt angezeigt werden. Gestern meldete sich der Kunde, dass wieder was mit den Übersetzungen nicht stimmt. Da ich nun das Thema endlich mal abhaken möchte, habe ich die MASK Elemente zu CONTENT BLOCKS mittels der Extension umgewandelt - lief auch alles sauber, nun tritt aber der Fehler auf, dass -1 überhaupt nicht mehr funktioniert. 1) Laut DB haben beiden Felder Werte > 0 [upl-image-preview uuid=99497832-702e-4401-a59b-4a74587678bf url=https://t3forum.net/assets/files/2025-09-18/1758180019-978589-image.png alt={TEXT?}] 2) Ich beziehe mich hier auf tt_content Elemente - die Bilder selbst habe ich in der Dateiliste nicht umgestellt 3) Es handelt sich um - theoretisch - eine normale Galerie ```yaml name: mask/gallery typeName: mask_gallery prefixFields: false basics: - TYPO3/Appearance - TYPO3/Links fields: - type: File identifier: image useExistingField: true label: Bilder allowed: common-image-types ``` Hoffe, dass konnte ein wenig weiterhelfen. Vielen Dank

@"M4ND0"#p6960 Danke für die Infos. Noch zur Klarstellung bezüglich deiner Aussage > Stellte ich dann auf FREIEN MODUS um, war alles soweit perfekt Meinst du hier den "Freien" Modus im Sinne des konfigurierbaren Fallback Types in der Site Configuration [upl-image-preview uuid=22842237-5ee3-4dea-bc11-fb2466393865 url=https://t3forum.net/assets/files/2025-09-18/1758181161-221805-bildschirmfoto-2025-09-18-um-093054.png alt={TEXT?}] oder den "Freien" Modus im Sinne der Verknüpfung von übersetzten Inhaltselementen zueinander (sichtbar im Seite-Modul)? [upl-image-preview uuid=2fcdcbb1-5474-4546-b693-0d9933212a19 url=https://t3forum.net/assets/files/2025-09-18/1758180752-633426-bildschirmfoto-2025-09-18-um-093114.png alt={TEXT?}] Beim Fallback Type "Freier Modus" muss man dazu sagen, dass hier kein "Overlaying" stattfindet. Er nimmt also direkt die Datensätze der gewählten Sprache, ohne den Weg über die Standardsprache und die Prüfung, ob diese übersetzt ist, zu gehen. Kannst du der Vollständigkeit halber auch einmal die DB Datensätze des Übersetzungs-Elternelements (uid 389) und der Kindelemente (Standardsprache und deren Übersetzung) aus der Collection aufzeigen?

Hallo Eric, ich meine die Site Configuration - die Datensätze der Sprache sind alle im VERBUNDEN MODUS. Die Probleme mit den Collections gab es nur unter MASK - hier mal die DB-Auszüge eines kleines Bsps. Ist die Datei so OK? [upl-file uuid=f9e76d05-6f1e-4101-a263-4a15f47a6bd4 size=2kB]dbcsv.zip[/upl-file]

Oder gar noch diese Datei, es wird in der Fremdsprache immer VERFÜGBARKEIT PRÜFEN angezeigt [upl-file uuid=3aa49391-39fa-4421-b9e1-f6e87a6d41c8 size=2kB]buttonscsv.zip[/upl-file]

@"M4ND0"#p6963 Deine CSVs scheinen teilsweise verschobene Werte zu haben, es fiel mir etwas schwer die Werte den jeweils richtigen Spalten zuzuordnen. Auf die wesentlichen Felder reduziert müssten deine Datensätze so aussehen (korrekt?): ### Icons-Elemente (vereinfacht) | uid | sys\_language\_uid | l18n\_parent | l10n\_source | CType | parentid | parenttable | header | | --- | ------------------ | ------------ | ------------ | ----------- | -------- | ----------- | ------ | | 461 | 0 | 0 | 0 | mask\_icons | | | | | 467 | 1 | 461 | 461 | mask\_icons | | | | | 3 | 0 | 0 | 0 | | 461 | tt\_content | | | 8 | 0 | 0 | 0 | | 467 | tt\_content | | --- ### Buttons-Elemente (vereinfacht) | uid | sys\_language\_uid | l18n\_parent | l10n\_source | CType | parentid | parenttable | header | | --- | ------------------ | ------------ | ------------ | ------------- | -------- | ----------- | -------------------- | | 110 | 0 | 0 | 0 | mask\_buttons | | | | | 139 | 1 | 110 | 110 | mask\_buttons | | | | | 14 | 0 | 0 | 0 | | 110 | tt\_content | Verfügbarkeit prüfen | | 15 | 1 | 14 | 14 | | 139 | tt\_content | Check availability | Was hier im Vergleich direkt auffällt ist, dass das Icons-Kindelement mit `uid=8` im Gegensatz zu seinem Elternelement `uid=467` die Default-Sprache `0` nutzt statt `1` (Englisch). Bei den Button-Elementen scheint DB-seitig soweit alles korrekt zu sein. Was mich aber wundert ist, dass du dich doch eigentlich auf das Ausgabeverhalten von Sprache `-1` bezogen hattest. In deinen CSV-Beispielen kommt aber nirgendwo die Sprache `-1` vor. Kannst du klarstellen was nun konkret der verwirrende Fall ist? Bitte achte darauf den zu betrachtenden Fall möglichst exakt auszudrücken, das ist bei diesen Translation Handling Themen ohnehin schon ganzschön kompliziert nachzuvollziehen 😅

Hallo Eric, das ist leider noch nicht der "-1 - Fall" - hier ist erstmal das Problem, dass ich beim Buttons Element in der Fremdsprache nicht CHECK AVAILIBILITY angezeigt bekomme, sonder VERFÜGBARKEIT PRÜFEN - obwohl bei der Übersetzung, und auch in der DB, alles korrekt zu seien scheint. Wenn ich dann in der SITE CONFIG auf FREIEN MODUS umstelle, sehe ich die englische Sprache, im STRICT Modus aber nicht. LG

@"M4ND0"#p6969 Ok, dann gebe mir mal die zugehörige YAML-Konfiguration deines `mask_buttons` Content-Blocks einschließlich der `Collection` bzw. den `tt_content`-Kindelementen, damit ich den Fall nachstellen kann. Da es sich bei den Kindelementen ebenfalls um `tt_content`-Datensätze handelt gehe ich mal davon aus, dass du das nach der ["Nested Content Elements" Dokumentation](https://docs.typo3.org/p/friendsoftypo3/content-blocks/main/en-us/API/NestedContentElements/Index.html) gemacht hast oder?

Da es sich hier auch noch um den "alten" Fall handelt, ist hier noch MASK im Einsatz. Aber dieses Problem war hinfällig, als ich MASK auf CONTENT BLOCKs umgestellt habe. Seitdem tritt aber der Fehler mit der -1 Sprache auf. Und im Speziellen handelt es sich erstmal um ein Galerie Element, welches bei Umstellung auf -1 nicht in Englisch angezeigt wird. Hierzu meine YAML Config: > name: mask/gallery typeName: mask_gallery prefixFields: false basics: - TYPO3/Appearance - TYPO3/Links fields: - type: File identifier: image useExistingField: true label: Bilder allowed: common-image-types Diese wurde durch die Extension erstellt, daran habe ich vorerst nichts geändert. Hier noch die dazugehörigen DB Tabelle [upl-file uuid=69d3bf4a-a657-46c9-a1b2-75d7e3fe4aaf size=1kB]tt-contentcsv.zip[/upl-file]

@"M4ND0"#p6971 ich glaube ich verliere langsam den Überblick worum es dir geht. untersuchen wir jetzt also das Verhalten von Mask-Elementen ohne `-1` in TYPO3 v13? Wäre die Ausgabe mit Content-Blocks denn korrekt? In diesem Fall würde ich das abkürzen und erstmal nach Content-Blocks migrieren. Das Thema mit dem `-1` Element und der deaktvierten Übersetzung hätte ich aber auch gerne noch weiter analysiert, weil das eingangs beschriebene Verhalten schon recht ungewöhnlich ist.

Fehler bei Übersetzung von Datensätzen

M4ND0

Hallo Eric,

ich habe jetzt noch mal ein wenig getestet und probiert, wenn ich einen neuen Datensatz für eine Galerie anlege, dann zuerst die Sprache auf -1 umstelle, dann werden danach alle hinzugefügten Bilder auch auf -1 in der Tabelle sys_file_reference gestellt. Wenn ich dann aber beim Datensatz wieder auf 0 umstelle und ein Bild hinzufüge, dann bekommen nur die neuen Bilder in der sys_file_reference eine 0, die bisher referenzierten Bilder bleiben auf -1. Müssten nicht alle referenzierten Bilder beim Umstellen der Sprache im Datensatz ein "update" in der Spalte sys_language_uid erhalten? Oder sehe ich hier was falsch?

Vielen Dank

Eric Harrer

M4ND0 deine Beobachtung stimmt: bestehende Referenzen behalten ihre Spracheinstellung, wenn du die Sprache des Elternelements änderst – egal ob von -1 (alle Sprachen) auf die Standardsprache, zurück auf -1 oder auch von einer Übersetzung in eine andere. Nur neue Referenzen übernehmen die Sprache des Elternelements.

Das Verhalten ist aktuell so gewollt und wurde z. B. per Patch #80012 im Core bestätigt. Ziel des Patches war es, dass Kinder unter einem „alle Sprachen“-Elternelement ihre eigene Sprach-UID behalten, um in der aktuellen FE-Sprache lokalisiert werden zu können – die Intention dahinter: Pflegeaufwand auf Ebene des Elternelements sparen.

In unserer Initiative diskutieren wir, ob diese sprachliche Inkonsistenz hilfreich ist: Befürworter sehen weniger Pflegeaufwand, Gegner verweisen auf mehr Komplexität und mögliche Unklarheiten. Perspektivisch wollen wir das betreffend -1 durch Synchronprozesse im DataHandler lösen, wenn das „alle Sprachen“-Flag gesetzt ist. Dann wird es je einen dedizierten DB-Datensatz in jeder Sprache geben, der entweder redaktionell angelegt wurde oder das Ergebnis eines Synchronprozesses ist.

M4ND0

Das verstehe ich natürlich.

Eric, vielen Dank für Deine Hilfe!

« Vorherige Seite

Unterstütze das Forum

Hilf mit, den Community Hub für TYPO3 werbefrei zu halten und die Betriebskosten zu decken. Werde Official Community Hub Supporter für nur 5 Euro im Monat (zzgl. USt) und erhalte ein exklusives Supporter-Badge. Jeder Beitrag zählt!

Jetzt Supporter werden

Impressum - Datenschutz - Kontakt - Netiquette - RSS