Adding terms to Glossary

[halian-vilela]

Hey guys, adding some terms to the glossary. Sorry for the mess with the other format.

I'll try keep to keep it updated in the other repo just in case we find out later that with a lot of terms, that's better to read.

For now on, let's keep it simple then!

---

I want to raise a discussion on translating the following terms, what do you think?

• Bubbling (for bubbling events)
• Wrap (verb - action performed by a wrapper around something)
• Wrapper (e.g. a Wrapper Component or a Wrapper Tag)

[tibuurcio]

Wrap as a verb is a hard one since embrulhar and empacotar are not good meanings. At #47 there's the following phrase:

we also recommend wrapping it in parentheses

Some variations of what was used and suggested in this case:

também recomendamos cercá-lo com parênteses
também recomendamos colocar dentro de parênteses

Also, maybe we should have a label for Glossary specific PR's? I believe it will be a recurring topic.

[halian-vilela]

Wrap as a verb is a hard one since embrulhar and empacotar are not good meanings.

Yes, very crappy meanings hahaha.

também recomendamos cercá-lo com parênteses

"Cercar" is good. Could be also "envolver" in this particular context.

Also, maybe we should have a label for Glossary specific PR's? I believe it will be a recurring topic.

Totally agree.

[tibuurcio]

How about to assert? Should we use afirmar or determinar? 🤔. Although to assert means afirmar, I believe when used to talk about test stuff the proper meaning would be to determine something, that's why I prefer determinar.

[fjoshuajr]

TO DO: https://github.com/reactjs/reactjs.org-translation/blob/master/style-guide.md

[glaucia86]

LGTM 👍

[tibuurcio]

Just thought about it and bubbling events can be translated as propagando eventos, outros exemplos:

• evento propagou
• evento foi propagado

What do you think @halian-vilela ?

[glaucia86]

@tibuurcio add also these words pls

• timestamps - timestamps
• server - servidor
• server-side - lado do servidor
• client - cliente
• client-server - lado do cliente
• script - script
• single-page apps - single-page apps
• widgets - widgets
• watcher - watcher

cc: @cezaraugusto @fjoshuajr

[glaucia86]

Just thought about it and bubbling events can be translated as propagando eventos, outros exemplos:

• evento propagou
• evento foi propagado

What do you think @halian-vilela ?

• evento propagado

[fjoshuajr]

@tibuurcio add also these words pls

• timestamps - timestamps
• server - servidor
• server-side - lado do servidor
• client - cliente
• client-server - lado do cliente
• script - script
• single-page apps - single-page apps
• widgets - widgets
• watcher - watcher

cc: @cezaraugusto @fjoshuajr

👌

[eduardomoroni]

Em https://github.com/reactjs/pt-BR.reactjs.org/pull/47/files as duas menções a wrap foram traduzidar como colocar dentro de e envolver com o que parece bom para mim no contexto.
Será que a gente precisa convencionar para o caso de Wrapper components? ou podemos deixar este termo livre para ser traduzido de acordo com o contexto?

[fjoshuajr]

Check the comments, please.

[halian-vilela]

Just thought about it and bubbling events can be translated as propagando eventos, outros exemplos:

• evento propagou
• evento foi propagado

What do you think @halian-vilela ?

Então, à primeira vista eu achei que usar "propagação" como equivalente direto de "bubbling" fosse a melhor opção, mas eu fiquei em dúvida depois de pensar mais um pouco pq o "bubbling" é somente uma das formas de propagação de eventos em JS, né? Também tem o "capturing".

No caso, eu precisaria da opinião de um dev mais experiente pra saber qual a relevância do "capturing" na prática, pois se for relativamente irrelevante, podemos considerar a "propagação" como "bubbling" por default e aí especificar sempre que o contexto estive falando do capturing. Talvez fique mais simples.

Alguém pode opinar sobre isso? "Capturing" costuma aparecer em muitos casos?

---

Fora isso, concordo com o restante. Vou esperar a resposta sobre essa dúvida acima e faço a modificação no arquivo para fazermos o merge dessa etapa.

[tibuurcio]

@halian-vilela Muito bem observado.
Esse post no SO explica um pouco da diferença dos dois termos. Confesso que sempre que precisei usar foi pensando no tipo bubble, não conhecia o outro.

Pelo post fica claro que bubbling e capturing são tipos diferentes para controlar a mesma coisa, que é a propagação de eventos.

Lendo um pouco a documentação do MDN e do W3C me parece que o padrão é o tipo bubble e o capture só é utilizado caso especificado.

Por causa disso, acho que deveríamos traduzir como propagação na falta de um termo melhor, já que bubbling é o tipo padrão.

Uma exceção a isso seria no caso da página que documenta os eventos sintéticos do React, talvez seja interessante especificar o tipo quando estiver traduzindo, visto que a página tem referências pra ambas as fases de propagação.

Mais uma referência do uso do termo bubbling na documentação oficial do React pra que possamos ter mais exemplos:

• Event Bubbling Through Portals

O que acham das considerações?

EDIT: Marcando aqui @cezaraugusto que é quem fez a tradução da página que eu citei. Acho que é interessante ouvir seu feedback por ter traduzido a página sobre SyntheticEvents.

[halian-vilela]

@tibuurcio

Por causa disso, acho que deveríamos traduzir como propagação na falta de um termo melhor, já que bubbling é o tipo padrão.

Eu voto por "propagação" salvo em um contexto onde o capturing seja relevante. Nesse caso, façamos como nos outros, detalhando o termo com o original em parênteses ou trocando por uma frase que dê mais contexto.

Se todos concordarem eu já faço a iteração nessa PR adicionando bubbling tb.

[tibuurcio]

@halian-vilela Concordo com você, voto do mesmo jeito 👍

[halian-vilela]

Galera, como padronizamos:

• high-order components - componente de alta-ordem?
• stateful logic - lógica com estado?
• event listeners - ?

[fjoshuajr]

Deixei alguns os comentários

[fjoshuajr]

Galera, como padronizamos:

• high-order components - componente de alta-ordem?
• stateful logic - lógica com estado?

Por mim, ok.

[tibuurcio]

Galera, como padronizamos:

• high-order components - componente de alta-ordem?
• stateful logic - lógica com estado?
• event listeners - ?

Tenho certas ressalvas em traduzir termos que representam padrões específicos do React, como por exemplo high-order components e/ou render-props. Acho que alguém que acabou de ler a documentação em pt-BR deve ser capaz de entrar em um artigo em inglês logo em seguida e reconhecer os mesmos termos, pelo menos pra conceitos tão utilizados na comunidade como esses.

Talvez quando for traduzir termos assim a gente possa colocar a representação original entre parênteses? Como estamos fazendo com estado (state) em alguns casos.

O que acham sobre isso? Gostaria de ouvir a opinião de todos, pois talvez eu não esteja enxergando a visão de alguém que tem muita dificuldade com inglês...

[halian-vilela]

Galera, como padronizamos:

• high-order components - componente de alta-ordem?
• stateful logic - lógica com estado?
• event listeners - ?

Tenho certas ressalvas em traduzir termos que representam padrões específicos do React, como por exemplo high-order components e/ou render-props. Acho que alguém que acabou de ler a documentação em pt-BR deve ser capaz de entrar em um artigo em inglês em seguida e ver os mesmos termos, pelo menos pra conceitos tão utilizados na comunidade como esses.

Talvez quando for traduzir termos assim a gente colocar a representação original entre parênteses? Como estamos fazendo com estado (state) em alguns casos.

O que acham sobre isso? Gostaria de ouvir a opinião de todos, pois talvez eu não esteja enxergando a visão de alguém que tem muita dificuldade com inglês...

Eu também tenho as ressalvas, por isso tenho me preocupado principalmente com searchability, o problema é que para alguns termos compostos, quando ele tem algum termo no meio que se aparecer "sozinho" é traduzido, fica estranho...

Tipo na descrição: "o componente X tem tal e tal propriedade."

E aí no mesmo texto, falando de outro componente: "por ser um um high-order component, o componente Y tem tal e tal".

---

Não sei se fui claro, de qualquer maneira, creio que o melhor jeito é a estratégia do original em parênteses mesmo.

---

Aproveitando, me deparei com mais um termo que pode ter várias formas:

fetch -> captura/capturar ?

[tibuurcio]

Não sei se fui claro, de qualquer maneira, creio que o melhor jeito é a estratégia do original em parênteses mesmo.

Concordo..

Muito bem lembrado sobre searchability! Pensando nisso, não consigo imaginar alguém indo na docs e pesquisando por "componente de alta ordem" 😆

Fetch pode ser também "requisitar" / "obter", quando se referir a uma requisição por dados.

data fetching -> requisição por dados / requisitando dados

Certeza que vai aparecer outros contextos, tipo nessa página por exemplo tá sendo usado com sentido de baixar e instalar dependências do yarn, tipo uma junção de "buscar" + "trazer" 🤔

[eduardomoroni]

GLOSSARY.md já está outdated, o que voces acham de mergearmos as coisas em que concordamos e deixar as outras partes como outro PR?
As traduções estão movendo rapido, se a discussão ficar bloqueando as coisas que nós já concordamos pode ser se alguém traduza com o glossario desatualizado.

[WendellAdriel]

Por isso eu tinha criado o Glossário como issue, que era muito mais rápido de se atualizar

[halian-vilela]

Por isso eu tinha criado o Glossário como issue, que era muito mais rápido de se atualizar

@WendellAdriel

O problema era que no caso da Issue só os moderadores podiam inserir os termos, o resto ficava nas discussões, que já estavam muito longas enquanto o glossário ainda estava relativamente pequeno.

De qqr maneira, acho que essa PR aqui já está mais longa do que devia também. Do que precisamos para mergear logo e fazermos PRs de termos mais curtas e pontuais?

Já vi muita coisa que está aqui (meio que decidida) que acabou não indo pro glossário e por isso estão sendo traduzidas de maneiras diversas nas outras PRs.

Vamos bater o martelo, pessoal?

@glaucia86 @eduardomoroni @tibuurcio @fjoshuajr

[fjoshuajr]

Wrap vai para as palavras que não se traduzem.

Suggested change

| wrapper | ? |

[halian-vilela]

@fjoshuajr
"Wrap" ou "Wrapper"?

Wrapper eu até tendo a concordar, mas "wrap" eu acho que tem muitos contextos que tornaria o fluxo do texto estranho.

[fjoshuajr]

@halian-vilela wrap nos exemplos que encontrei funciona como verbo entao podemos usar a palavra encapsular. Agora wrapper a gente nao traduz

[tibuurcio]

Vi issues pra discutir glossário sendo criadas nos repositórios de outras linguagens mas acaba realmente ficando sempre uma discussão grande..

@halian-vilela Acho que podemos fechar esse PR com as definições que chegamos até agora :)

[fjoshuajr]

@halian-vilela wrap nos exemplos que encontrei funciona como verbo entao podemos usar a palavra encapsular. Agora wrapper a gente nao traduz

[fjoshuajr]

Concordo com @tibuurcio. Vamos fechar esse PR.

O review foi resolvido