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:
- Aggiungere una colonna di testo nullable
topic_templateacategory_localizations - Compositore: se esiste una localizzazione per la lingua corrente dell’utente, utilizzare il suo modello; in caso contrario, fare riferimento a
category.topic_template - Esporre/persistere il campo per lingua nell’interfaccia di amministrazione delle categorie (accanto a nome/descrizione localizzati)
- Includere
topic_templatenella pipeline di Localizzazione Contenuti AI quando si traducono le categorie (comedescription)
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