Substituição eficiente de textos do site?

Eu li que a única maneira de conseguir todos os textos para substituir é usando as configurações de textos do site e substituindo cada um deles. Estou tentando alterar a redação:

Tópicos → Threads
Categorias → Fóruns
Subcategorias → Subfóruns

Porque isso faz muito mais sentido para mim com fóruns de mensagens. Consegui alterar muitos deles com os textos do site, mas é uma maneira ineficiente de fazer isso. Existe alguma outra forma?

(Também, porque ele só retornará os primeiros 50 resultados, eu não consigo realmente alterar todos com os textos do site de qualquer forma.)

Se essa é a colina em que você quer morrer (e quando você faz perguntas aqui, vai usar a sua língua ou a nossa?), você pode olhar em discourse/config/locales/client.en.yml at main · discourse/discourse · GitHub e ver todas elas.

3 curtidas

Dependendo se você pode usar plugins de terceiros, isso pode ser útil?

Haha, vou usar seu idioma para manter as coisas sob controle! Sobre este arquivo, posso apenas alterar seu conteúdo para minha instalação local e as mudanças irão refletir em todo o site?

Oh, obrigado por compartilhar. Me preocupo com a possibilidade de danificar os elementos da interface de usuário, de acordo com os comentários…

1 curtida

Isso é principalmente para você ver o que todos eles são.

Você pode editar esse arquivo e depois tentar fazer com que sua versão seja copiada para o dentro do container.

Outra coisa que você pode fazer é editar e tentar atualizar as informações no banco de dados através da API. Ou você pode fazer isso em Rails. Na verdade, não deve ser muito difícil fazer alguma IA escrever um script para fazer as atualizações.

Realmente não recomendo, mas pode ser uma coisa divertida.

Então você quer dizer que, este arquivo é o que o aplicativo interpreta para popular o banco de dados com os valores reais? Ou seja, este é o “padrão” que o sistema lê?

Não, acho que não.

Isso não acessa o banco de dados (acho que seria muito lento).

Acredito que a maior parte das informações de localidade é processada na memória para velocidade, usando o Redis como cache (fico feliz em ser corrigido sobre isso).

A única coisa que é armazenada no banco de dados são suas modificações (na tabela translation_overrides), que serão lidas quando você inicializar o aplicativo ou gradualmente quando você fizer uma única modificação enquanto estiver online.

Apenas gostaria de apontar algumas coisas:

  • aumentar significativamente o número de modificações pode estender o tempo de inicialização do seu aplicativo (não tenho certeza se alguém já fez um benchmark disso).
  • estas podem se tornar uma dor administrativa para manter à medida que o Discourse evolui, mas mantém sua própria nomenclatura. Você está inventando trabalho para si mesmo aqui.
  • dado que agora é, sem dúvida, a plataforma de fóruns mais popular, muitas pessoas já usam pelo menos um site Discourse e estão muito acostumadas com a nomenclatura, então talvez considere não confundir seus usuários mudando o que eles já se acostumaram de volta às normas anteriores?

Veja também:

Isso implica que cada Categoria tem seus próprios administradores, URL, configurações, propósito … por exemplo, Meta é um fórum. Não é composto por vários fóruns … realmente não tenho certeza de como você argumentaria isso? Mas divago.

Não.

Sim.

Então, se você quiser alterá-los todos, o que é uma péssima ideia, você poderia editar esse arquivo, colocá-lo em /var/discourse/shared/standalone/whatever

E então adicionar um exec ao app.yml que o copiasse de /shared/whatever para /var/www/discourse/config/locales/

Mas você também precisará acompanhar os commits para ver se ele foi alterado para poder adicionar o que quer que tenha sido alterado.

Portanto, a maneira da API ou do rails, que colocou os valores no banco de dados, pode ser melhor.

Respeitosamente, vocês não conhecem meu caso de uso. Dizer que é uma “ideia terrível” ou que eu posso estar prejudicando a experiência do usuário sem saber por quê estou fazendo o que estou fazendo assume que estou agindo por ignorância. Não estou interessado em entrar em um debate sobre taxonomia ou experiência do usuário. Para meu caso de uso e público, a terminologia que o Discourse usa para descrever seus tipos de conteúdo não faz sentido.

Então, para recapitular:

  • O Discourse lê este arquivo para popular seus rótulos por padrão; quaisquer alterações que eu fizer na tradução sobrescrevem isso e acabam sendo salvas no banco de dados. Portanto, a maneira mais eficiente de alterar esses termos em todo o site é apenas modificar este arquivo e colocá-lo na pasta /locales/
  • Parece que as únicas preocupações aqui são se esse arquivo é atualizado pelo núcleo. Assumo, então, que quaisquer novos textos seriam lidos da versão /standalone/ do arquivo em vez da minha, então eu precisaria atualizar a minha para acomodar isso. Não tenho certeza de como o desempenho seria um problema nesse caso, já que o banco de dados não está envolvido e ele está apenas lendo de um arquivo?

Obrigado.

1 curtida

Essa é uma maneira de fazer isso. Você precisaria editar seu app.yml para que ele faça isso toda vez que você construir um novo contêiner.

Se você fizer o que descrevi acima, sua versão substituirá a versão que é fornecida com a versão atual. A versão no diretório locales é o que eu acho que você quer dizer com “versão standalone”. Então, se você fizer dessa forma, o arquivo eventualmente ficará sem coisas, a menos que você observe quando ele muda. No pior dos casos, você apenas verá o nome da coisa que está faltando, então talvez você não se importe. Não vai travar, apenas parecer confuso.

Estou dizendo que é uma má ideia porque essas são coisas que podem causar problemas se você não entender, então quando acabar sendo um desastre, eu estarei registrado dizendo que não recomendei as próprias alterações que eu te disse como fazer.

1 curtida

Você poderia emitir uma série de comandos sed no app.yml para automatizar as atualizações.

Dessa forma, você pode ser um pouco mais “tolerante às mudanças”.

Se descobrir que está alterando cerca de 20 entradas, talvez seja melhor fazer isso online pelo Admin!

Desafio interessante!

1 curtida

Obrigado pela dica!

Parece que consegui a maior parte (senão todas) das referências de contato com o público através dos textos do site. Mas vou ter isso em mente se desenvolver um método mais abrangente.

2 curtidas

Boa! Isso é definitivamente melhor do que sobrescrever tudo como eu sugeri. . . . desde que essas operações sed não alterem os nomes dos textos!

1 curtida

Sim, seria preciso ter cuidado e olhar as diferenças! :sweat_smile:

1 curtida