Localizza i modelli di topic delle categorie

Contribuisci Funzionalità
1

Problema

La localizzazione dei contenuti di Discourse (manuale e automatica tramite Discourse AI) fa un ottimo lavoro nel localizzare i titoli degli argomenti, i post, i nomi delle categorie e le descrizioni delle categorie. Tuttavia, i modelli di argomento delle categorie (categories.topic_template) non possono essere localizzati. Nelle comunità multilingue, il prefill del compositore appare sempre nella lingua predefinita del sito — per tutti.

Comportamento attuale

  • CategoryLocalization memorizza name e description per ogni locale (il concern Localizable fornisce il “supporto a nome/descrizione multi-locale” per Topic/Post/Category).
  • Il compositore utilizza sempre il topic_template non localizzato, indipendentemente dal locale dell’interfaccia del membro.

Soluzione proposta

  • Aggiungere topic_template a CategoryLocalization (inclusa l’interfaccia di localizzazione per gli amministratori).
  • Quando un membro apre il compositore in una categoria, utilizzare il modello corrispondente al locale della sua interfaccia, con un fallback al modello predefinito della categoria se non esiste una localizzazione.
  • Lo stesso problema si applica ai più recenti modelli di modulo per categoria: possono differire tra le categorie, ma non esiste una variante sensibile al locale all’interno di una singola categoria — le configurazioni multilingue dovrebbero essere costrette a suddividere la propria comunità in categorie separate per lingua per ovviare al problema.

Caso d’uso

Gestiamo una comunità bilingue (tedesco come lingua predefinita, inglese tramite traduzione automatica con IA). Alcune categorie forniscono modelli di compositore strutturati con voci di elenco di controllo e un blocco [event] per il selettore di date integrato. I membri di lingua inglese attualmente ricevono un modello solo in tedesco. Il nostro workaround è un modello bilingue unico (ogni etichetta duplicata come “Tedesco / Inglese” su una riga), che funziona, ma è ingombrante sia per gli editor che per i membri e raddoppia il contenuto del compositore.

Correlati

  • #32464 (route delle categorie localizzate) — stessa superficie di localizzazione, categorie.
3 Mi Piace
2

Seguo la mia richiesta originale con una bozza di implementazione concreta — sono felice di contribuire con una PR se la direzione sembra ragionevole.

Problema: I modelli di argomento delle categorie (categories.topic_template) non sono localizzabili. Il modello CategoryLocalization e la concern Localizable coprono solo name e description, e la pipeline di Localizzazione Contenuti AI salta di conseguenza i modelli. Il compositore inserisce sempre il modello della lingua di base, indipendentemente dalla lingua dell’utente.

Caso d’uso: Gestiamo una comunità bilingue (DE/EN) su Discourse con Localizzazione Contenuti AI e traduzione automatica in produzione. La traduzione di post/argomenti funziona bene, ma i modelli di categoria per contenuti strutturati — moduli di segnalazione bug con elenchi di controllo, flussi RSVP tramite BBCode [event] — non possono essere duplicati per lingua, perché il BBCode funzionale deve esistere esattamente una volta. L’unico workaround è un modello unico con etichette bilingui goffe (“Versione app / App version:”), che danneggia la leggibilità per tutti.

Proposta:

  1. Aggiungere una colonna di testo nullable topic_template a category_localizations
  2. Compositore: se esiste una localizzazione per la lingua corrente dell’utente, utilizzare il suo modello; in caso contrario, fare riferimento a category.topic_template
  3. Esporre/persistere il campo per lingua nell’interfaccia di amministrazione delle categorie (accanto a nome/descrizione localizzati)
  4. Includere topic_template nella pipeline di Localizzazione Contenuti AI quando si traducono le categorie (come description)

La migrazione è banale (add_column :category_localizations, :topic_template, :text); il lavoro principale riguarda la logica di selezione del compositore e l’interfaccia di amministrazione.

Alternative considerate:

  • Modello unico bilingue (workaround attuale) — non funziona con blocchi BBCode funzionali
  • Componente di tema che inietta testo per lingua — fragile, nessuna validazione lato server, rompe i compositori API