Kategorie-Themenvorlagen lokalisieren

Beitragen Merkmal
1

Problem

Die Inhaltslokalisierung von Discourse (manuell und automatisch über Discourse AI) erledigt einen hervorragenden Job bei der Lokalisierung von Themen-Titeln, Beiträgen, Kategoriennamen und Kategoriebeschreibungen. Allerdings können Thementemplates von Kategorien (categories.topic_template) nicht lokalisiert werden. In mehrsprachigen Communities erscheint die Composer-Vorbelegung immer in der Standardsprache der Website – für alle.

Aktuelles Verhalten

  • CategoryLocalization speichert name und description pro Locale (die Localizable-Concern bietet “Mehrsprachige Name/Beschreibung-Unterstützung” für Topic/Post/Category).
  • Der Composer verwendet immer das nicht lokalisierte topic_template, unabhängig vom Interface-Locale des Mitglieds.

Vorschlag

  • topic_template zu CategoryLocalization hinzufügen (einschließlich der Admin-Lokalisierung-Editor-UI).
  • Wenn ein Mitglied den Composer in einer Kategorie öffnet, das Template verwenden, das seinem Interface-Locale entspricht, mit einem Fallback auf das Standard-Template der Kategorie, falls keine Lokalisierung existiert.
  • Dasselbe Problem betrifft die neueren Formulare pro Kategorie: Sie können zwischen Kategorien variieren, aber es gibt keine Locale-bewusste Variante innerhalb einer Kategorie – mehrsprachige Setups müssten ihre Community in separate, sprachspezifische Kategorien aufteilen, um dieses Problem zu umgehen.

Anwendungsfall

Wir betreiben eine zweisprachige Community (Deutsch als Standardsprache, Englisch über automatische KI-Übersetzung). Einige Kategorien bieten strukturierte Composer-Templates mit Checklisten-Punkten und einem [event]-Block für den integrierten Datumsauswahl-Dialog an. Englischsprachige Mitglieder erhalten derzeit nur ein deutschsprachiges Template. Unser Workaround ist ein einzelnes zweisprachiges Template (jedes Label auf einer Zeile als “Deutsch / Englisch” dupliziert), was funktioniert, aber für beide Redakteure und Mitglieder umständlich ist und den Composer-Inhalt verdoppelt.

Verwandt

  • #32464 (lokalisierter Kategorien-Route) – gleiche Lokalisierungsfläche, Kategorien.
3 „Gefällt mir“
2

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:

  1. Eine nullable topic_template-Textspalte zu category_localizations hinzufügen
  2. Composer: Wenn eine Lokalisierung für die aktuelle Sprache des Nutzers existiert, deren Vorlage verwenden; andernfalls auf category.topic_template zurückgreifen
  3. Das Feld pro Sprache in der Kategorie-Admin-Oberfläche ausgeben/persistieren (neben lokalisiertem Name/Beschreibung)
  4. topic_template in die KI-Content-Lokalisierungspipeline einbeziehen, wenn Kategorien übersetzt werden (wie description)

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