Anknüpfend an meine ursprüngliche Anfrage hier ein konkreter Implementierungsentwurf — ich helfe gerne bei einem PR, falls die Richtung sinnvoll erscheint.
Problem: Kategorie-Thema-Vorlagen (categories.topic_template) sind nicht lokalisiert. Das CategoryLocalization-Modell und die Localizable-Concern decken nur name und description ab, und die KI-Content-Lokalisierungspipeline überspringt Vorlagen entsprechend. Der Composer fügt immer die Vorlage der Basis-Sprache ein, unabhängig von der Sprache des Nutzers.
Anwendungsfall: Wir betreiben eine zweisprachige (DE/EN) Community auf Discourse mit KI-Content-Lokalisierung und automatischer Übersetzung im Produktivbetrieb. Das Übersetzen von Beiträgen/Themen funktioniert hervorragend, aber Kategorie-Vorlagen für strukturierte Inhalte – Bug-Report-Formulare mit Checklisten, RSVP-Flows über [event]-BBCode – können nicht pro Sprache dupliziert werden, da funktionaler BBCode genau einmal vorhanden sein muss. Der einzige Workaround ist eine einzelne Vorlage mit unhandlichen zweisprachigen Beschriftungen („App-Version / App version:“), was die Lesbarkeit für alle beeinträchtigt.
Vorschlag:
- Eine nullable
topic_template-Textspalte zucategory_localizationshinzufügen - Composer: Wenn eine Lokalisierung für die aktuelle Sprache des Nutzers existiert, deren Vorlage verwenden; andernfalls auf
category.topic_templatezurückgreifen - Das Feld pro Sprache in der Kategorie-Admin-Oberfläche ausgeben/persistieren (neben lokalisiertem Name/Beschreibung)
topic_templatein die KI-Content-Lokalisierungspipeline einbeziehen, wenn Kategorien übersetzt werden (wiedescription)
Die Migration ist trivial (add_column :category_localizations, :topic_template, :text); die Hauptarbeit liegt in der Auswahllogik des Composers und der Admin-Oberfläche.
Betrachtete Alternativen:
- Zweisprachige Einzelvorlage (aktueller Workaround) – funktioniert nicht mit funktionalen BBCode-Blöcken
- Theme-Komponente, die pro Sprache Text injiziert – fragil, keine serverseitige Validierung, bricht API-Composers