Localizar modelos de tópicos de categorias

Contribuir Funcionalidade
1

Problema

A Localização de Conteúdo do Discourse (manual e automática via Discourse AI) faz um ótimo trabalho ao localizar títulos de tópicos, publicações, nomes de categorias e descrições de categorias. No entanto, os modelos de tópicos das categorias (categories.topic_template) não podem ser localizados. Em comunidades multilíngues, o preenchimento automático do editor (composer) sempre aparece no idioma padrão do site — para todos.

Comportamento atual

  • CategoryLocalization armazena name e description para cada idioma (a preocupação Localizable fornece “suporte a nome/descrição multilíngue” para Tópicos/Publicações/Categorias).
  • O editor (composer) sempre usa o topic_template não localizado, independentemente do idioma da interface do membro.

Solução proposta

  • Adicionar topic_template à CategoryLocalization (incluindo a interface de edição de localização do administrador).
  • Quando um membro abrir o editor em uma categoria, usar o modelo correspondente ao idioma da interface dele, com um retorno (fallback) para o modelo padrão da categoria caso não exista localização.
  • O mesmo problema se aplica aos mais novos modelos de formulário por categoria: eles podem diferir entre categorias, mas não há uma variante consciente de idioma dentro de uma única categoria — configurações multilíngues teriam que dividir sua comunidade em categorias separadas por idioma para contornar isso.

Caso de uso

Operamos uma comunidade bilíngue (alemão como padrão, inglês via tradução automática de IA). Algumas categorias fornecem modelos estruturados para o editor com itens de lista de verificação e um bloco [event] para o seletor de data embutido. Membros de língua inglesa atualmente recebem apenas um modelo em alemão. Nossa solução alternativa é um único modelo bilíngue (cada rótulo duplicado como “Alemão / Inglês” em uma linha), o que funciona, mas é incômodo tanto para editores quanto para membros e duplica o conteúdo do editor.

Relacionado

  • #32464 (rota de categorias localizadas) — mesma superfície de localização, categorias.
3 Curtiram
2

Seguindo meu pedido original com um esboço concreto de implementação — ficarei feliz em ajudar com um PR se a direção parecer razoável.

Problema: Os modelos de tópico das categorias (categories.topic_template) não são localizáveis. O modelo CategoryLocalization e a concern Localizable cobrem apenas name e description, e o pipeline de Localização de Conteúdo por IA ignora os modelos de acordo. O compositor sempre insere o modelo do locale base, independentemente do locale do usuário.

Caso de uso: Operamos uma comunidade bilíngue (DE/EN) no Discourse AI Content Localization com tradução automática em produção. A tradução de posts/tópicos funciona muito bem, mas os modelos de categoria para conteúdo estruturado — formulários de relatório de bugs com checklists, fluxos de RSVP via BBCode [event] — não podem ser duplicados por idioma, porque o BBCode funcional deve existir exatamente uma vez. A única solução alternativa é um único modelo com rótulos bilíngues desconfortáveis (“App-Version / App version:”), o que prejudica a legibilidade para todos.

Proposta:

  1. Adicionar uma coluna de texto topic_template anulável (nullable) em category_localizations
  2. Compositor: se existir uma localização para o locale atual do usuário, use o modelo dela; caso contrário, volte para category.topic_template
  3. Expor/persistir o campo por locale na interface administrativa de categorias (ao lado do nome/descrição localizados)
  4. Incluir topic_template no pipeline de Localização de Conteúdo por IA ao traduzir categorias (como description)

A migração é trivial (add_column :category_localizations, :topic_template, :text); o principal trabalho é a lógica de seleção do compositor e a interface administrativa.

Alternativas consideradas:

  • Modelo único bilíngue (solução alternativa atual) — falha com blocos de BBCode funcionais
  • Componente de tema injetando texto por locale — frágil, sem validação no servidor, quebra compositores de API