Estruturando uma comunidade multilíngue

:bookmark: Este guia explica diferentes abordagens para organizar um fórum Discourse para uma comunidade multilíngue, incluindo prós e contras de cada método.

:person_raising_hand: Nível de usuário necessário: Administrador

O Discourse oferece várias maneiras de estruturar seu site para uma comunidade multilíngue. Este guia explorará as abordagens mais comuns e suas vantagens e desvantagens.

:spiral_notepad: Este tópico não é mais a fonte de abordagens recomendadas para estruturar uma comunidade multilíngue, pois agora recomendamos o uso dos recursos integrados de Localização de Conteúdo no núcleo do Discourse, com traduções automáticas opcionais via IA através do plugin Discourse AI. Para mais detalhes, consulte Content Localization - Manual and Automatic with Discourse AI.

Usando categorias para separação por idioma

Categoria “Outros idiomas” com subcategorias

Uma abordagem é criar uma categoria principal chamada “Outros idiomas” com subcategorias para idiomas específicos.

Como implementar:

  1. Crie uma nova categoria chamada “Outros idiomas”
  2. Adicione subcategorias para cada idioma que deseja suportar
  3. Incentive os usuários a postar na subcategoria do idioma apropriado

Prós:

  • Separação limpa entre idiomas
  • Possibilidade de usar tags restritas por categoria para organização adicional dentro de cada idioma

Contras:

  • Usuários multilíngues precisam acompanhar várias categorias com conteúdo semelhante
  • Pode levar a silos de conteúdo baseados no idioma

Categorias de nível superior separadas para cada idioma

Outra abordagem é criar categorias de nível superior separadas para cada idioma suportado.

Como implementar:

  1. Crie uma nova categoria para cada idioma que deseja suportar
  2. Use um componente de tema como Custom Header Links para adicionar links de troca de idioma no cabeçalho

Prós:

  • Distinção clara entre seções de idioma
  • Navegação fácil para usuários que falam apenas um idioma

Contras:

  • Pode criar uma experiência de comunidade fragmentada
  • Difícil para usuários multilíngues acompanhar discussões entre idiomas
  • Pode levar a silos de conteúdo baseados no idioma

Usando tags para identificação de idioma

Tags de idioma em todo o fórum

Esta abordagem envolve criar tags para cada idioma suportado e incentivar os usuários a marcar suas postagens de acordo.

Como implementar:

  1. Crie tags para cada idioma que deseja suportar (por exemplo, #english, #french, #spanish)
  2. Incentive os usuários a adicionar a tag de idioma apropriada ao criar tópicos
  3. Opcionalmente, use emojis nos nomes das tags para distinção visual

Prós:

  • Não é necessário criar categorias separadas
  • Usuários multilíngues podem acompanhar facilmente todo o conteúdo
  • Flexível para tópicos que podem envolver vários idiomas

Contras:

  • Depende da conformidade do usuário para marcação precisa
  • Pode ser menos intuitivo para usuários acostumados com navegação baseada em categorias

Usando instâncias separadas do Discourse

Para comunidades com grupos de idiomas distintos, pode-se considerar o uso de instâncias separadas do Discourse para cada idioma.

Como implementar:

  1. Configure uma instância separada do Discourse para cada idioma
  2. Use subdomínios ou domínios separados para cada instância (por exemplo, en.example.com, fr.example.com)
  3. Crie links entre as instâncias no cabeçalho ou rodapé usando um componente de tema como Custom Header Links

Prós:

  • Separação completa de conteúdo e usuários por idioma
  • Possibilidade de personalizar cada instância para sua comunidade de idioma específica

Contras:

  • Mais complexo gerenciar múltiplas instâncias
  • Difícil para usuários multilíngues participar em comunidades de diferentes idiomas
  • Risco de discussões duplicadas e comunidade fragmentada

Considerações adicionais

Localização de categorias e tags

O Discourse agora suporta a localização de nomes de categorias, descrições de categorias e nomes de tags por meio do recurso integrado de Localização de Conteúdo. Ative content localization enabled e configure content localization supported locales nas configurações do seu site. Grupos autorizados podem fornecer traduções manuais, ou traduções automáticas podem ser configuradas via o plugin Discourse AI.

Preferências de idioma do usuário

O Discourse possui configurações de localidade integradas, incluindo allow user locale, set locale from accept language header, set locale from cookie e set locale from param. Essas opções permitem que os usuários definam seu idioma preferido para a interface. Quando a Localização de Conteúdo está ativada, os usuários verão automaticamente conteúdo localizado com base em sua preferência de localidade.

Seletor de idiomas

A configuração content localization language switcher pode exibir um seletor de idiomas no cabeçalho, permitindo que visitantes (incluindo usuários anônimos) alternem entre os idiomas suportados.

Funcionalidade de pesquisa

Certifique-se de que os usuários possam pesquisar em todos os idiomas ou filtrar resultados por idiomas específicos.

Recursos adicionais

20 curtidas

I think https://community.wd.com have quite an elegant version of the “other languages” category. They use several such categories for different languages and added a language bar above the header (via css I suppose, but they forgot to add it to the mobile css).

They even managed to somehow exclude the language categories from the “all categories” page (also via CSS?) And also the “latest” page seems free of non-english topics, but that may be because there are non at the moment.

However, another downside of this solution is clearly that the illusion of beeing on, for example, a German WD forum is shattered when you click on “latest” because what you get are not the latest German posts.

8 curtidas

Is there anybody who uses completely separate instances of Discourse for multi-lingual communities? This seemed like the most obvious way to do it (especially since you can set each language-subcommunity to default to use the same language in the Discourse UI).

2 curtidas

I’m setting them up, but I do:

https://en.ancap.ch
https://br.ancap.ch
https://jp.ancap.ch
https://th.ancap.ch

and so on… they are in a multisite configuration

I prefer that each one has a link to each others in the Header (the https://br.ancap.ch one has)

6 curtidas

I like your approach. How you did it?

1 curtida

There’s nothing special to @swfsql’s approach.

  1. Set up a dedicated Discourse forum for each language. No need for a multisite configuration.
  2. Use a theme component like Custom Header Links or Brand header theme component to create the menu you need.
6 curtidas

I would like to share some ideas about how to turn Discourse in a truly and multilingual space, equitable to speakers of dozens of languages, some of them multilingual, some of them not, some fluent in English some of them not, or not at all. In our organization we might be able to invest in the development of these features, after a good technical and community review.

The idea would be to use language tags with some customization. Posters would be able to tag their post with the relevant language so as to keep topics searchable by language.

Goal

The goal is to offer a discussion space that speakers of any language (and language combinations) can feel as theirs, as opposed to an English forum with a multilingual corner or a forum split in many languages becoming effectively many separate forums.

Language tags

For this, the main building block would be a tag specific to languages. This tag would be required for all topics, and it would default to English. Topics in non-English languages would be tagged accordingly.

Languages displayed

By default, the topic would display topics in all languages. Admins could configure as default just one language, a combination of languages, keep all languages…

Through a language bar that pulls from the tag titles, users could see the topics available in a specific language.

Language user preferences

Through browser detection, language chosen by the user during registration, user preferences, and other means to be determined, the system would decide which language(s) are displayed to a user.

Again, the default would be English and admins could define other combinations. The user could always go to their user preferences and set the language(s) they want to see / ignore. It would be of further use if the users could set the default language of posting, to save them from selecting a language tag each time.

Localization of categories and tags

Tags, categories and their descriptions could be localized.

Search filter

Users could search in all languages or filter for their languages defined in their profiles.

Progressive implementation

Not all these features would be deployed at once, and maybe not all these features need to be in just one plugin. It would be preferred to test and build incrementally, and start with a minimum viable product that a multilingual community could start testing.

Does this approach sound like the right one? Are there other ideas for how we could more effectively build the multilingual element of this discussion space?

9 curtidas

O que faz uma comunidade parecer uma comunidade? Em um meio predominantemente baseado em texto, conseguir entender a comunicação textual dos outros membros parece ser fundamental. Ou seja, me pergunto se é possível superar completamente as duas armadilhas que você menciona (‘silosização’ ou ‘tokenismo’) em um meio predominantemente baseado em texto (sem tradução automática perfeita).

Uma comunidade que me vem à mente aqui é https://discourse.mozilla.org

Atualmente, temos a opção de exigir um certo número de tags em uma postagem em uma categoria, veja The option to enforce tagging (Configuração de categoria “Número mínimo de tags exigidas em um tópico”).

No entanto, esse caso de uso se beneficiaria de uma configuração ligeiramente diferente: “Exigir tag de um grupo de tags”. A forma como você usaria isso seria:

  • Criar um tag_group com uma lista fixa de idiomas
  • Exigir que cada novo tópico tenha uma tag adicionada desse grupo antes de ser publicado.

@HAWK Estou curioso se alguns dos outros casos de uso para esse tipo de configuração que você mencionou no tópico vinculado se beneficiariam de algo semelhante (ou se eles são totalmente cobertos pela configuração existente “Número mínimo de tags exigidas em um tópico”)?

Isso poderia ser feito de uma forma que seria geralmente útil: um componente de navegação por tags que exibe tags de um grupo específico.

O Discourse atualmente permite que o usuário defina seu local (alternado pela configuração do site allow user locale) e realiza detecção automática de local, alternada pela configuração do site set locale from accept language header. Existem três contextos de detecção automática:

  • Visitantes (navegador e cabeçalhos)
  • Cadastros (idem)
  • Convites (idem) - talvez haja um problema com isso? (veja) (@schungx?)

Talvez as duas melhorias que poderiam ser feitas aqui sejam:

  • adicionar uma configuração para permitir que um usuário defina manualmente seu local no formulário de cadastro
  • adicionar um ‘alternador de local’ para visitantes, semelhante ao do Facebook (veja a barra inferior da página de cadastro). Eu realmente fiz isso para um projeto diferente, mas ainda não o transformei em um plugin.

Acho essa parte realmente interessante e acredito que seria definitivamente interessante tentar. As tags, categorias e descrições de categorias são o que um usuário geralmente lê primeiro antes de ler um tópico real. Elas frequentemente contribuem para a sensação do usuário sobre a comunidade. Se eles veem palavras e descrições com as quais se identificam, é mais provável que se relacionem com a própria comunidade. Então, mesmo que haja um idioma diferente assim que o usuário entrar no tópico, seu interesse e senso de comunidade já estão preparados.

Também é mais fácil localizar descrições de categorias e tags do que localizar tópicos inteiros. Tecnicamente falando, isso é viável, mas ainda não foi testado. Veja mais. @erlend_sh Você conhece algum trabalho adicional ou exemplos sobre isso?

Se as tags de idioma estiverem todas em um único tag_group, a mudança aqui seria adicionar um filtro de tag específico para grupo de tags na página de pesquisa avançada.

Para resumir as mudanças que mencionei acima:

  • Uma configuração de site ou categoria “Exigir tag de um grupo de tags”
  • Um componente de navegação por tags que exibe tags de um grupo específico
  • Uma configuração para permitir que um usuário defina manualmente seu local no formulário de cadastro
  • Um ‘alternador de local’ para visitantes
  • Localização de tags, nomes de categorias e descrições de categorias
  • Adicionar um filtro de tag específico para grupo de tags na página de pesquisa avançada
10 curtidas

Convites (ibid) - talvez haja um problema com isso? (veja 1) (@schungx?)

Pelo que pude perceber, os e-mails de convite serão enviados no idioma padrão do site, mas o usuário receberá seu próprio idioma ao fazer login.

Atualmente, não há como especificar o idioma dos convites…

2 curtidas

Nada me vem à mente, mas estamos vendo cada vez mais comunidades multilíngues. Se isso for simplificar esse caso de uso específico, acho que é um pedido legítimo.

8 curtidas

@HAWK Também apoio esse recurso. Consigo ver muitos usos para isso, além da exigência de tags de idioma. Por exemplo, atualmente temos um grupo de tags chamado “gerenciamento de projetos” com as tags #ideia, #escopo, #pronto, #em-andamento, #celebrando, #avaliando, #concluído. Seria incrível exigir que as pessoas etiquetem corretamente cada postagem que fizerem com a etapa apropriada de gerenciamento de projetos dentro de certas categorias.

3 curtidas

@neil, o que você acha? Quanto trabalho envolveria impor uma única tag de um grupo específico de tags?

Note que ainda não atingimos a regra de três, mas ainda estou interessado nas respostas acima.

7 curtidas

Isso soaria interessante também para o meu fórum. Temos principalmente membros de língua inglesa, mas também membros de língua espanhola. Estamos sempre traduzindo de um lado para o outro. A ideia de dois fóruns separados (em idiomas diferentes) não é o caminho para nós. Mas um site bilíngue com tradução automática — com idioma padrão especificado pelo usuário — seria ótimo!

4 curtidas

Seria fácil adicionar uma maneira de impor a presença de um tag de um grupo de tags. Acredito que, neste caso (escolher um idioma), queremos impor exatamente um tag, mas imagino que algumas pessoas possam querer pelo menos um tag (semelhante à configuração “Número mínimo de tags exigidas em um tópico”). Preferiria implementar “pelo menos um tag de um grupo específico de tags”, pois já podemos ver algo assim em ação no Car Talk, onde é possível que as pessoas marquem seus tópicos com todas as tags de marca e modelo de carros, mas isso não acontece. Além disso, em uma comunidade multilíngue, mais de um idioma pode fazer sentido às vezes.

13 curtidas

É, isso parece inteligente para mim.

6 curtidas

Talvez a melhor forma de fazer isso seja adicioná-la como um mínimo numérico, em vez de booleano, para oferecer um controle mais granular e também deixar a porta aberta para adicionar um máximo.

4 curtidas

Construí isso hoje. É uma configuração por categoria na aba Tags:

Uma coisa que pode ser melhorada é como as pessoas sabem quais tags têm para escolher. No momento, está mostrando o nome do grupo de tags, mas provavelmente deveria listar as tags, ou as tags mais populares do grupo, caso haja muitas para listar.

@debryc @angus O que vocês acham?

11 curtidas

Isso é tão emocionante, Neil!

  1. Acredito que a exibição das configurações está perfeita.
  2. Concordo que é necessário alguma indicação sobre quais tags eles têm para escolher.

Talvez no menu suspenso de tags do compositor, exibamos primeiro o grupo de tags e suas opções de tag, antes de mostrar outras tags populares.

Ou, talvez a mensagem de erro inclua um aviso como “escolha uma das seguintes tags antes de publicar”. Os usuários poderiam clicar no nome da tag para adicioná-la!

5 curtidas

Adotei essa abordagem. As tags obrigatórias serão sugeridas pela entrada de tags caso nenhuma ainda tenha sido escolhida.

6 curtidas

Outra reflexão:
Para ser equitativo com múltiplos idiomas, um usuário deve ser capaz de produzir/expressar (texto fonte) no idioma mais confortável para ele/ela. E o leitor deve ser capaz de consumir/ler no idioma mais confortável para ele/ela (texto traduzido). Para minimizar problemas de “perda na tradução”, seria benéfico mostrar lado a lado tanto o texto fonte quanto o texto traduzido. A versão base do texto traduzido poderia ser uma versão traduzida automaticamente. E versões subsequentes do texto traduzido poderiam ser melhorias contribuídas por usuários. Assim como em uma wiki, os leitores poderiam optar por ver versões anteriores do texto traduzido se suspeitarem de problemas de “perda na tradução”.

O usuário deve ter uma maneira rápida de escolher o idioma consumido (para substituir qualquer decisão tomada pelo sistema ou administrador) — por exemplo, a partir de um menu suspenso de idiomas no canto superior direito da tela. Por exemplo, um usuário convidado que fala inglês (não logado) viajando para a China pode querer ver o texto em inglês, embora a detecção do navegador possa indicar chinês como idioma local.

Adoro essa ideia de traduzir tags e categorias. No entanto, alguns termos técnicos/científicos podem não ter traduções e podem precisar permanecer no idioma original.

3 curtidas