[DISCUSSÃO] Tradução dos nomes dos métodos, funções e buzzwords

[larien]

E aí, galera, beleza?

Boa parte de vocês veio me perguntar sobre traduzir ou não os nomes dos métodos dentro do código. Exemplo:

// Save saves an report to database.
func (r *Report) Save() error {
    // smt
    return nil
}

Eu respondi a alguns de vocês levantando os seguintes pontos:

• A ideia é diminuir a barreira de linguagem e na minha opinião, mesmo com as palavras reservadas estando em inglês, manter os nomes dos métodos em inglês iria dificultar o aprendizado
• Não é necessário traduzir as coisas de forma literal e podemos adaptar para o contexto utilizado (ex.: traduzir router para roteador, data para dados, utilizar termos comuns para a gente no geral)

Dessa forma, a tradução do exemplo acima ficaria:

// Salva armazena um relatório na base de dados.
func (r *Relatorio) Salva() error {
    // smt
    return nil
}

Ao invés de manter:

// Save armazena uma informação na base de dados.
func (r *Report) Save() error {
    // smt
    return nil
}

No entanto, gostaria de abrir essa discussão com vocês para a gente chegar em um consenso e aplicar esse estilo no decorrer do código. Quais são seus pontos em relação a não traduzir os métodos/funções/buzzwords nesse livro? Bora bater um papo? :)

[larien]

Marcando geral, porque o GitHub só deixa dar assign em até 10 pessoas: @edmilton, @ehriq, @devdrops, @haruanm, @ramonsilvanet, @milhomem, @diegonvs, @rafa-acioly, @zevet, @giovana-morais, @julioshinoda, @Caaddss, @wps13, @malaquiasdev, @jessicapaz, @Ronald-TR, @mbrosowicz, @Dimenicius

[wps13]

@larien Eu estava traduzindo os nomes e variavéis dos métodos, tenho achando mais fácil de entender o contéudo assim.

[julioshinoda]

Para fins didáticos creio que seja uma boa ideia

[ehriq]

Eu gosto da ideia também. O único ponto é a padronização de certos nomes na tradução. Ex: para Save usamos Gravar ou Salvar?

[larien]

Tem uma issue aberta para a criação de glossário para casos comuns de tradução. Fico devendo isso pra vocês. Por enquanto cada um pode seguir o seu jeito e a gente vai ajustando isso no decorrer da tradução :)

[mbrosowicz]

Eu estava em dúvida entre traduzir os nomes de métodos ou não, porque hoje em dia é quase que um padrão usar nomes de métodos em inglês, mas pensando em fins didáticos realmente faz sentido.

[Ronald-TR]

Inicialmente fui contra por alguns motivos:

1- Aprender o código em inglês pode ser uma barreira a mais, mas é uma barreira necessária. Termos, nomes de padrões e a maioria dos materiais futuros de apoio estarão em inglês. O quanto antes nos familiarizarmos com os jargões, melhor será para nossos futuros estudos.

2- Você pode acabar se vendo confuso ao ler um código fonte "padrão-inglês" não por não conhecer a teoria por trás dos termos, mas por tê-los associado a outras palavras (portuguesas), gerando um esforço e período de re-aprendizado mais ou menos duro ou não (a depender de pessoa para pessoa).

Tirando os contras do âmbito profissional (que não é o foco), para a didática, acho estes dois motivos acima um desafio um tanto grande.

Mas fica ao criterio da maioria, aprender os termos na sua lingua mãe é mais facil para absorver a teoria, eu concordo. Mas haverão estas barreiras que hora ou outra, como estudantes vamos ter que encarar... rsrs

[giovana-morais]

talvez seja legal traduzir e depois fazer uma seção mostrando um código em inglês, fazendo o paralelo entre o que foi traduzido e os jargões em si. não sei se faz sentido, massssssss

enfim, eu concordo com a tradução dos códigos pq acho que facilita o entendimento e a absorção da teoria, porque fica mais fluído.

[larien]

Acham válido criar um capítulo no livro que comente as principais buzzwords em inglês utilizadas no livro e suas definições, como a Gi comentou? Eu curti a ideia

[Ronald-TR]

Acho bacana! No final anexar um glossário com os termos utilizados

[milhomem]

Eu sou contra, primeiro porque nunca fica em português é sempre um mix: func (r *Relatorio) Salva() error return nil No exemplo, o que é func e o que é error? O que é return? Esses é um exemplo básico mas todas as keywords não podem ser traduzidas.

Segundo, se a pessoa está aprendendo e temos exemplos que não devem ser seguidos, como explicamos para ela que estamos fazendo “errado” para fins didáticos? Se decidirmos seguir traduzindo, acho válido uma sessão com buzzwords e também um esclarecimento do porque se traduziu e que quando a pessoa for escrever código que não se deve usar português.

Por último, acho que dificulta a tradução porque tem que alinhar todas as classes que se repetem ao longo dos capítulos e também os testes, mas isso é só questão de ter mais trabalho.

[larien]

Keywords não podem ser traduzidas, mas são só 25 na linguagem e boa parte delas é usada em contextos bem específicos. Elas estão sempre lá e não vão mudar. Diferentemente dos nomes de métodos/funções/variáveis, em que cada contexto tem seu próprio. Não vejo problema em manter o mix, desde que os conceitos fiquem claros para quem tá lendo e aprendendo com o livro hihihi O que também dá pra fazer é a gente explicar no primeiro momento que a keyword aparece para que ela serve. Assim, a pessoa já coloca na cabeça o significado daquela keyword. Essa opção de explicar cada termo também pode ser feita se mantivermos as assinaturas e nomenclaturas em inglês, mas aí é questão de ter mais trabalho xD Eu vou padronizando os termos ou aviso na revisão enquanto não conseguir criar o glossário. Tá na minha lista com prioridade máxima aqui KADJFHLSAJGAHSKFJG

[erikacarvalho]

tô mais acompanhando do que traduzindo mas vim deixar meus 2 centavos:

a premissa dessa tradução é: a língua inglesa é uma barreira ao aprendizado pra várias pessoas.

se todas as pessoas lusófonas compreendessem inglês, não haveria nenhuma necessidade de traduzir o Learn Go with Tests.

partindo dessa premissa, usar palavras em inglês além das estritamente necessárias (como keywords) coloca uma barreira a mais no caminho pro aprendizado da pessoa. não tem motivo fazê-lo.

além disso, não acredito que seja papel das pessoas envolvidas com a tradução julgar se código escrito em português é errado ou não. entendo que o papel seja viabilizar o acesso a um material que anteriormente não estava acessível. se a pessoa eventualmente vai aprender inglês em algum momento e vai codar em inglês, não cabe a nós.

uma outra vantagem de deixar o código em português, nesse caso, é que fica nítido pra pessoa que está aprendendo o que são nomes específicos da linguagem e o que são nomes que a própria pessoa atribui quando está programando.

@larien posso ajudar com esse glossário hein 🤓

[larien]

Maravilhosa :blue_heart: quer pegar a issue do glossário e começar com algumas definições?

[erikacarvalho]

@larien bora! vou ver se no fim de semana consigo começar

[larien]

Beleza, vou te colocar como colaboradora Tenha pressa não, a gente faz cada um no seu tempo aqui :)

[brunagil]

Cheguei tarde na discussão, mas sou do time que concorda com a tradução total do conteúdo, incluindo os métodos dentro do código. Que o inglês seja apenas das palavras reservadas (porque aí não tem o que fazer mesmo)

Um glossário vai ser ótimo! Quem já traduziu poderia abrir uma issue pra colocar suas sugestões. Que tal?

[larien]

É uma boa ideia a galera que já traduziu contribuir para essas sugestões Acho legal concentrar em um só lugar numa issue que já tá aberta aqui pra facilitar o trabalho da @erikacarvalho que tá nela :D

[milhomem]

Mudamos um pouco do ponto da discussão . Não estamos discutindo sobre traduzir ou não o conteúdo. Eu concordo com a premissa, e sim vamos traduzir o que for necessário.

O ponto é, traduzir o que não se pode ser traduzido: o código.

Eu adoraria poder usar português pra codar, mas essa não é a realidade.

Keywords foram só exemplos, mas mensagens de erros, referências, classes e métodos de bibliotecas, operadores, constantes e etc vão aparecer pra confundir quem não sabe inglês básico.

O ponto é até aonde vai nosso dever como profissionais do ramo em prestar uma didática que facilite a vida do estudante independentemente das limitações individuais.

Qual a diferença entre jogar esse conteúdo no Google tradutor e ter um grupo de pessoas pensando na melhor tradução?

Eu queria voltar pro ponto e dizer que acho ótimo a ideia do glossário, mas gostaria de ir além e colocar um esforço em ensinar também o inglês básico, introduzido pelos códigos de exemplo. O quanto antes o estudante se familiarizar com o inglês e principalmente com a forma que se escreve código melhor para ele.

Talvez, como foi sugerido, colocar lado a lado linguagem de programação e linguagem natural. Deixando claro a intenção do código.

Ou colocar uma opção de código traduzido, na qual podemos traduzir tudo para a linguagem natural tentando explicar a intenção do código.

Já que estamos falando de traduzir tudo, adicionar também as traduções das mensagens de erros.

Na minha perspectiva da profissão e me colocando de volta no início dela quando comecei sem saber inglês, eu gostaria de uma opção que não tocasse no código. Uma opção que me ensinasse a programar.

[giovana-morais]

@milhomem não há realmente como traduzir o código todo, como já discutido, mas traduzir as variáveis ajuda a deixar a explicação do texto mais fluída quando passada pra linguagem natural porque é mais fácil de entender o propósito do método/variável/etc.

o que vocês acham de mantermos os códigos em inglês comentados com explicações em português junto com os códigos traduzidos (arquivos diferentes no mesmo diretório, talvez?) caso alguém queira consultar? isso poderia servir pra gente ressaltar que é importante saber o inglês básico porque, infelizmente, os compiladores/interpretadores/qualquer coisa que jogar um erro na sua cara vai fazer isso em inglês;

[larien]

No meu mundo ideal essa buzzword pode ser mantida em inglês desde que haja um link dela para sua devida explicação no glossário que tá para ser criado, o que acham? Mas eu não concordo com manter os nomes das variáveis/estruturas de dados em inglês e colocar a explicação em português pelos motivos que já foram citados aqui.

Eu adoraria poder usar português pra codar, mas essa não é a realidade.

Tocar no ponto da realidade faz muito sentido, mas essa não é a realidade: os conceitos ensinados sobre esse livro são sobre Go e testes, não sobre padrões de projetos, arquiteturas e não têm foco em ensinar a pessoa a arquitetar um software (sei nem se essa palavra existe, desculpa aí o vacilo, gente)

Eu queria voltar pro ponto e dizer que acho ótimo a ideia do glossário, mas gostaria de ir além e colocar um esforço em ensinar também o inglês básico, introduzido pelos códigos de exemplo.

Não é nossa responsabilidade ensinar inglês básico. Isso vai ser uma barreira para quem tem como foco aprender o objetivo do livro, que é Go/testes. Se a pessoa preferir saber como o termo tá em inglês ela pode abrir o livro original que também tá linkado no repositório.

Talvez, como foi sugerido, colocar lado a lado linguagem de programação e linguagem natural. Deixando claro a intenção do código.

o que vocês acham de mantermos os códigos em inglês comentados com explicações em português junto com os códigos traduzidos (arquivos diferentes no mesmo diretório, talvez?) caso alguém queira consultar?

A minha preocupação sobre ter explicações para cada código em inglês é que o código/as explicações fiquem poluídas para quem tá lendo. Mas acho uma boa ideia manter algumas buzzwords, desde que haja uma explicação do que ela faz no mesmo texto (mas volta a ideia da buzzword tho)

Já que estamos falando de traduzir tudo, adicionar também as traduções das mensagens de erros.

E sim, as traduções das mensagens de erro devem ser traduzidas (pelo menos a parte que o compilador deixa traduzir; nos termos que o compilador definir e não pudermos mexer deve sim ter uma explicação do que foi falado, mas fica poluído)

Talvez, como foi sugerido, colocar lado a lado linguagem de programação e linguagem natural. Deixando claro a intenção do código.

Cê pode me dar um exemplo mais claro sobre como você tá pensando em fazer isso?

Na minha perspectiva da profissão e me colocando de volta no início dela quando comecei sem saber inglês, eu gostaria de uma opção que não tocasse no código. Uma opção que me ensinasse a programar.

A pessoa vai aprender a programar em Go e criar testes mesmo traduzindo as coisas para português. Na minha perspectiva da profissão, eu senti falta de tutoriais claros e termos de compreensão simples no começo da carreira. Até hoje eu tenho problema com buzzwords tho

[erikacarvalho]

eu queria reforçar novamente sobre essa parte de ensinar inglês pras pessoas. a meu ver não cabe a quem está traduzindo decidir que a pessoa usuária aprendiz deve aprender inglês, ou induzir isso pelo viés do material. inclusive, se for a vontade da pessoa entender como seria aquilo em inglês, ter todos os nomes (os possíveis) traduzidos pro português auxilia nesse processo uma vez que basta colocar lado a lado o material original e o material traduzido e a pessoa pode comparar e aprender por assimilação.

No meu mundo ideal essa buzzword pode ser mantida em inglês desde que haja um link dela para sua devida explicação no glossário que tá para ser criado, o que acham?

sobre isso que @larien falou, eu discordo de sempre fazer a pessoa checar um material adicional. entendo que se fizermos dessa forma estaremos atrapalhando a experiência da pessoa usuária (no caso, pessoa usuária = quem está estudando com o material). vejo o glossário principalmente como uma ferramenta dos próprios tradutores pra unificar os termos da tradução, e secundariamente como um material a ser checado pela pessoa usuária aprendiz. da forma que eu entendo, precisamos desenhar o material de uma forma que a pessoa usuária tenha uma experiência linear, seguindo apenas o fio principal do material principal, sem a necessidade de checar materiais adicionais (SE a pessoa quiser checar, como adicional, ela checa). assim como SE ela quiser checar como é em inglês, ela checa o original.

Já que estamos falando de traduzir tudo, adicionar também as traduções das mensagens de erros.

isso que @milhomem falou e depois @larien comentou acho bem importante. nas partes do material em que os erros são esperados ou mencionados, entendo como crucial traduzir a msg de erro do exemplo. nos codelabs de go que estamos fazendo aqui em cwb uma das principais dificuldades de quem está começando é ler e entender a mensagem de erro (que às vezes está dizendo exatamente como consertar). entendo que o que pudermos derrubar de barreira linguística devemos derrubar.

[larien]

Eu entendo seu ponto em relação a checar o material adicional e concordo, @erikacarvalho. É bem chato ter que parar a leitura para procurar o significado do termo no final do livro. A gente pode manter o glossário da forma como tu falou, como um conteúdo adicional, e manter a leitura de forma linear explicando as buzzwords que não tiverem sido traduzidas no próprio texto ao invés de mandar para outro lugar.

[edmilton]

Cheguei bem tarde na conversa - desculpem se eu estiver chovendo no molhado aqui - mas ainda assim, gosto muito da ideia de traduzirmos os métodos/classes/variáveis/etc. Mantendo em inglês basicamente só o que o compilador não permite traduzir. Reforço o que a @larien pontuou muito bem sobre o objetivo do livro e da tradução e, com isso, traduzir métodos/classes/variáveis ajuda a diminuir a barreira para alcançarmos esse objetivo. Mantendo a leitura fluída e o foco do leitor em Go e testes.

Sobre a realidade, não é incomum encontrarmos métodos/classes/variáveis em PT-BR. Até algum tempo atrás era muito associado com empresa de baixa qualidade, mas nem sempre, como exemplificado nesta thread do @akamud.

[ehriq]

Eu penso que existem coisas mais difíceis de traduzir, ou que talvez não faça sentido traduzir porque virou jargão adotado na comunidade pt-br (ex: mock que é comum ouvir gente falar _mockar o retorno). O que eu tenho feito, na parte que estou traduzindo, é manter o termo em inglês quando parece difícil ou estranho traduzir, e colocando uma explicação embaixo. Com o glossário, vai ficar consistente. Na minha visão, tem que entender que é pra gente que está começando, mas ao mesmo tempo temos que tomar cuidado pra não alienar a pessoa que está seguindo com traduções estranhas e termos que não são usados, como ficou famoso em algumas traduções de livros de alguns anos atrás.

[larien]

Bom, galera, últimas duas semanas foram uma loucura e vou voltar à tradução/revisão no fds :D Levando em conta todos os comentários aqui, creio que a maioria concorda em traduzir todos os termos possíveis, com exceção de termos específicos (como mock, benchmark, como bem pontuado pelo @ehriq) e coisas que o compilador nos retorna. Nesses casos mais específicos, vamos colocar uma explicação breve no próprio texto e quando o glossário entrar a gente linka esses termos nele. Como não há um glossário bem definido atualmente, vou priorizar o desenvolvimento dele e por enquanto dar foco nesses pontos durante as revisões. Não tem problema as traduções serem feitas sem um padrão muito bem definido por enquanto - o livro passará por revisões constantes e eventualmente será uniforme. É só a versão alpha-0.0.0, galera AKODJFHKASDLJFGLASJFH Muito obrigada pela discussão! Vocês são foda <3