braziljs / eloquente-javascript

Tradução do livro Eloquent JavaScript - 2ª edição.

JavaScript Eloquente - 2ª edição

Uma moderna introdução ao JavaScript, programação e maravilhas digitais.

Conteúdo do Livro

Introdução

1. Valores, Tipos e Operadores - (Parte 1: Linguagem)
2. Estrutura do Programa
3. Funções
4. Estrutura de Dados: Objeto e Array
5. Funções de Ordem Superior
6. A Vida Secreta dos Objetos
7. Prática: Vida Eletrônica
8. Erros e Manipulação de Erros
9. Expressões Regulares
10. Módulos
11. Prática: A Linguagem de Programação
12. JavaScript e o Navegador - (Parte 2: Navegador)
13. O Document Object Model
14. Manipulando Eventos
15. Projeto: Plataforma de Jogo
16. Desenhando no Canvas
17. HTTP
18. Formulários e Campos de Formulários
19. Projeto: Um Programa de Pintura
20. Node.js - (Parte 3: Node.js)
21. Projeto: Website de Compartilhamento de Habilidades

Status Geral do Projeto

As informações sobre o status e log de cada capítulo estão organizadas nessa issue.

Atualmente, estamos melhorando o que já está traduzido, focando na qualidade e precisão da tradução e entendimento do texto como um todo, além de tentar aplicar a gramática mais correta possível. Vários contribuidores ajudaram em diferentes partes do livro e, por isso, existem diversas oportunidades de melhorias.

Como Contribuir?

Se você tiver interesse em ajudar, criamos um guia para ajudá-lo e, se tiver qualquer dúvida, basta abrir uma issue.

Informações Importantes

• Autor: Marijn Haverbeke
• Versão original deste livro.

Licenciado sob a licença Creative Commons attribution-noncommercial.

Todo código neste livro também pode ser considerado sob a licença MIT.

eloquente-javascript's Issues

Cap.02 - Estrutura do Programa

Tradução do arquivo 02-estrutura-do-programa.md

Original: link

Cap.04 - Estrutura de Dados: Objeto e Array

Tradução do arquivo 04-estrutura-de-dados.md

Original: link

Tradução do Capítulo 20

Pessoal, pintou um projeto grande aqui na empresa e ta tomando o tempo que eu havia reservado para a tradução. Deve acabar ainda essa semana, espero que até quarta. Sei que já devo estar a mais de 15 dias sem fazer um PR da tradução, e isso pode estar atrasando o andamento do projeto.

Peço desculpas, e, espero na quinta retomar a tradução. Caso vocês queiram passar a tradução para alguém, tudo bem. Mas se puderem aguardar até quinta (7/5), eu pretendo voltar a traduzir.

Obrigado e grande abraço!

acompanhar atualização no repositório do autor

Como iremos acompanhar as atualizações que estão sendo feitas no repo do autor do livro?

Cap.06 - A Vida Secreta dos Objetos

Tradução do arquivo 06-a-vida-secreta-dos-objetos.md

Original: link

Cap.09 - Expressões Regulares

Tradução do arquivo 09-expressoes-regulares.md

Original: link

• Expressões Regulares
• Notação
• Testando por correspondências
• Encontrando um conjunto de caracteres
• Partes repetidas em um pattern
• Agrupando sub-expressões
• Resultados e grupos
• O tipo data
• Limites de palavra e string
• Alternativas
• O mecanismo de procura #29
• Backtracking #31
• The replace method #30
• Greed #32
• Dynamically creating RegExp objects #33
• The search method #34
• The lastIndex property #35
• Parsing an ini file #37
• International characters #38
• Summary #38
• Exercises #39
• Regex golf #40
• Quoting style #41
• Numbers again #42

Introdução

Tradução do arquivo 00-introducao.md

Original: link

Cap.07 - Prática: Vida Eletrônica

Tradução do arquivo 07-pratica-vida-eletronica.md

Original: link

Como vocês estão traduzindo o termo "callback"?

• Função de retorno?
• Função de volta?
• ???

Cap. 21 - Projeto: Website de Compartilhamento de Habilidades

Cap.11 - Prática: A Linguagem de Programação

Tradução do arquivo 11-pratica-linguagem-de-programacao.md

Original: link

Definições para termos em gerais

A minha idéia é construir um padrão a ser seguido durante todos os processos.

Termos a definir:

• delimitação para títulos de obras
• citações
• sentido figurado
• estrangeirismo
• marcação para código

Iniciamos uma discussão neste PR sobre os termos de sentido figurado, gostaria de dar continuidade para saber a opinião de todos.
Caso alguém tenha algum outro termo para adicionar fique a vontade.

Aqui está minhas considerações sobre cada item.

• delimitação para títulos de obras: aspas duplas no nomes da obra e o nome do autor entre parênteses. Ex: "The Book of Programming"(Master Yuan-Ma)
• citações: utilizar aspas duplas.
• sentido figurado: utilizar itálico em todas ocorrências.
• estrangeirismo: utilizar itálico em todas ocorrências.
• marcação para código: inserir o pedaço de código entre apostrofe. Ex: console.log

Depois da definição de todos seria bem válido registrarmos essas decisões em algum lugar, pensei em coloca-las no CONTRIBUTING, o que acham?

Presente de Natal

Galera, estou querendo finalizar este projeto antes do Natal para ficar de presente para a comunidade.

Para ajudar nisso, pensei em algumas coisas:

1. Tentarmos dedicar 10min ~ 15min todo dia ao projeto e
2. Trabalharmos todos no mesmo capítulo

Creio que se formos finalizando todas as etapas de um capítulo antes de ir para o próximo, vamos ter mais sucesso. Dessa forma, uma pessoa incentiva a outra.

O que acham? Quem topa participar?

Se entrarmos nessa forma de trabalho, não existirão mais "donos" dos capítulos, assim que terminarmos um, já começaremos outro, e caso tenham mais pessoas querendo ajudar, repartimos as tarefas novamente e vamos prosseguindo. 😄

Aguardo a opinião/voto de vocês.

@braziljs/eloquent-javascript

Como traduzir a palavra "writable(s)"?

A única sugestão que vem na minha cabeça é gravável / graváveis. Até pq, quando leio em inglês é assim que minha mente traduz, existindo essa palavra em português ou não. hahaha.

Tempo para envio de PR

Pessoal, acho que devemos adicionar no README um termo dizendo que após X dias que a pessoa se manifestou para realizar alguma tarefa, se ela não enviar nenhum PR, nós adm's temos a permissão para alterar a label do capítulo sem precisar confirmar com a pessoa.

Estamos com a situação de vários capítulos parados, e se alguém chegar e olhar rapidamente vai pensar que não tem mais nada disponível para traduzir.

Penso no período de 15 dias para cada interação.

Ex:

• Pessoa se manifestou dia 01 ~> tem até o dia 16 para enviar algo
• Enviou algo no dia 03 ~> tem até o dia 18 para enviar algo novamente

cc @joaostein @randsonjs @SauloSilva @gabrielfgularte

Sugestão para workflow das traduções/revisões

Acredito que podemos ser um pouco mais rigorosos nesse sentido. Se formos analisar um sistema tradicional de taquigrafia por exemplo, temos os seguinte workflow:

1. Existe um setor chamado "apanhamento". Esse setor é responsável por "apanhar" o conteúdo inicial de uma fonte externa (no caso discursos, palestras etc), e criar a primeira versão do documento tentando ao máximo produzir um documento próximo de um trabalho final e aceitável (aqui inclui pesquisas, erros básicos de português, convenções, etc). Entretanto sabemos que sempre passam detalhes.
2. Por isso, existe um outro setor chamado "revisão". O dever da “revisão” é receber o trabalho do “apanhamento” e entregar um trabalho final aceitável (muitas vezes o apanhamento já entrega um trabalho perfeito havendo pouca ou nenhuma necessidade de alteração, mas as vezes acaba passando erros, falta de pesquisa etc…). Nesse ponto, teoricamente temos o documento final. Sempre é bom haver uma verificação final a cargo de ter ao menos uma segunda opinião sobre o documento final.
3. Por isso, existe um último setor chamado "supervisão". Esse setor é responsável por receber o trabalho teoricamente pronto da "revisão" e fazer pequenos ajustes que possam ter passado despercebidos (como detalhes de convenção, formas de escrita, etc). Esse setor recebe praticamente o trabalho pronto da "revisão" e só tem que dar um “check” para dizer que o trabalho está 100%.

O nosso workflow hoje contempla apenas os dois primeiros setores. Acredito que poderia ser uma boa ideia termos um outro passo após a revisão e abrirmos a oportunidade de termos uma segunda revisão (supervisão), a fim de termos uma segunda opinião sobre a revisão e ao mesmo tempo achar eventuais erros que passarem da revisão. Vai dar um pouco mais de trabalho, porém acredito que assim podemos ter a oportunidade de produzir um material de maior qualidade. O que acham?

Display Hints

Galera, como a gente vai fazer (ou vem fazendo) pra traduzir essas partes dos exercícios? Eu vi pelo menos umas quatro formas diferentes. Exemplos:

• https://github.com/braziljs/eloquente-javascript/blob/master/chapters/19-projeto-um-programa-de-pintura.md

• eloquente-javascript/chapters/16-desenhando-no-canvas.md

  Line 682 in b94c2ec

  **Dicas**

• eloquente-javascript/chapters/13-document-object-model.md

  Line 559 in b94c2ec

  #### Dicas

• eloquente-javascript/chapters/09-expressoes-regulares.md

  Line 698 in a016975

  Dicas

Quando eu traduzi, eu olhei um desses e segui, achando que havia um padrão. Mas aparentemente não. No site ele só mostra a dica quando o usuário clica em mostrar. Vamos repetir esse padrão?

Cap.08 - Erros e Manipulação de Erros

Tradução do arquivo 08-erros-e-manipulacao-de-erros.md

Original: link

Cap.01 - Valores, Tipos e Operadores

Tradução do arquivo 01-valores-tipos-operadores.md

Cap. 19 - Projeto: Um Programa de Pintura

Como vocês traduziriam o termo: "Let’s get coding"?

Me deparei com esse termo revisando o #9 e não sei ao certo qual seria a melhor forma de traduzir.

O termo que usamos hoje é: "Vamos codar".

Eu tenho a impressão de que o termo "codar" não é um termo válido na língua portuguesa, porém descreve perfeitamente o termo em inglês e ouço bastante pessoas falando dessa forma. No português, o termo "codificar" representa bem a tradução, porém soa um pouco estranho: "Vamos codificar".

codificar 
co.di.fi.car 
(lat codice+ficar2) vtd 1 Reduzir a código; reunir em código. 2 Coligir.

O que acham sobre isso, e qual maneira que faz mais sentido para vocês? Claro que outras alternativas são totalmente bem-vindas :)

Guia para o Website

Pessoas, esse é um guia vivo do que tem no website e na branch master onde está acontecendo as traduções/revisões. Se estiver faltando alguma coisa espero que deixem no comentário.

• Introdução
• Valores, Tipos e Operadores
• Estrutura do Programa
• Funções
• Estrutura de Dados: Objeto e Array
• Funções de Ordem Superior
• A Vida Secreta dos Objetos
• Prática: Vida Eletrônica
• Erros e Manipulação de Erros
• Expressões Regulares
• Módulos
• Prática: A Linguagem de Programação
• JavaScript e o Navegador
• O Document Object Model
• Manipulando Eventos
• Projeto: Plataforma de Jogo
• Desenhando no Canvas
• HTTP
• Formulários e Campos de Formulários
• Projeto: Um Programa de Pintura
• Node.js
• Projeto: Website de Compartilhamento de Habilidades

Vou começar a atualizar o site assim que possivel e irei alterando aqui.

Cap.12 - JavaScript e o Navegador

Tradução do arquivo 12-javascript-e-o-navegador.md

Original: link

O problema do capítulo 3 (Funções)

Então galera, traduzindo o capítulo 3, encontrei 2 problemas, e preciso da ajudar de vocês. Primeiro problema:

Primeiro problema: tradução.

Tive dificuldade em traduzir o seguinte trecho:

Trecho original:

If a function is pure, a call to it can be seen as a thing in itself. When you are not sure that it is working correctly, you can test it by calling it directly from the console, which is simple because it does not depend on any context. It is easy to make these tests automatic ― to write a program that tests a specific function. Non-pure functions might return different values based on all kinds of factors, and have side effects that might be hard to test and think about.

Minha tradução:

Se uma função é pura, uma chamada a ela pode ser vista como uma coisa a ela mesma. Quando você não está certo se ela está funcionando corretamente, você pode testar ela chamando ela diretamente do console, que é simples, pois não depende de nenhum contexto. É facil fazer esses testes automaticamente - para escrever um programa que testa uma função específica. Funções não-puras podem retornar diferentes valores baseados em diferentes fatores, e possuem efeitos colaterais que podem ser difíceis de testar e pensar sobre eles.

Não entendi a parte do "uma coisa a ela mesma" e sobre a parte dos testes, nem mesmo em inglês consegui entender direito.

Segundo problema: Erro do livro.

Trecho original:

People who have experience with other programming languages might expect that a block of code (between braces) also produces a new local environment. Not in JavaScript. Functions are the only things that create a new scope. You are allowed to use free-standing blocks like this...

var something = 1;
{
  var something = 2;
  print("Inside: " + something);
}
print("Outside: " + something);

... but the something inside the block refers to the same variable as the one outside the block. In fact, although blocks like this are allowed, they are utterly pointless. Most people agree that this is a bit of a design blunder by the designers of JavaScript, and ECMAScript Harmony will add some way to define variables that stay inside blocks (the let keyword).

---

O texto diz que variaveis criadas dentro de um bloco não são "válidas". Acredito que deva ter havido alguma mudança no javascript, porque agora elas são válidas, e como a variavel dentro do bloco foi declarada depois da primeira, ela sobrepõe a outra. Ou seja, o resultado dos dois "print" deveria ser 1, mas é 2. Acho que a solução é mudar totalmente esse paragrafo ou até mesmo tirar ele, mas precisamos avaliar se realmente mudou ou o código que está errado.

Melhorias no capítulo 02

Linha 271:

atual:

Muitos programadores JavaScript envolvem os if e os loops com chaves. [...]

para:

Muitos programadores JavaScript envolvem cada if e loop com chaves. [...]

---

atual:

[...] quando houver alterações no número de declarações. [...]

para:

[...] quando houver alterações posteriores no número de declarações

Atualizar conteúdo do site

@randsonjs, você consegue atualizar o site com o conteúdo que nós temos até agora e deixar em sincronia a medida que novas alterações forem ocorrendo?

Website

Pessoal,

eu crie um repositório do livro e registrei um dominio para o mesmo. Vocês pode acessar por aqui: http://eloquentjavascript.com.br

Se vocês gostarem e quiserem colaborar com revisões ou tradução. Estou inteiramente a disposição para qualquer dúvidas :)

Ainda falta fazer muita coisa, então qualquer colaboração é bem-vinda :)

Obrigado

Convenções para a realização das traduções

Acredito que seria interessante fazer uma espécie de glossário com os termos em inglês mais importantes encontrados no livro e suas respectivas traduções. Deste modo fica mais fácil uniformizar as traduções e revisões deste repo. O que acha @ericdouglas ?

Como vocês estão traduzindo "threads"?

Essa eu nem faço ideia de sugestões. Alguém sugere algo?

Cap.10 - Módulos

Tradução do arquivo 10-modulos.md

Original: link

• Texto Original & estrutura, @letanure, #28
• Modules #43
• Organization #44
• Namespaces
• Reuse
• Decoupling
• Functions as namespaces
• Objects as namespaces
• Detaching from the global scope
• Evaluating data as code
• Require
• Slow-loading modules
• Interface design
• Predictability
• Composability
• Layered interfaces
• Summary
• Exercises
• Month names
• Circular dependencies
• A return to electronic life

Alterar nome do repositório

Seria interessante alterar o nome do repositório para eloquent-javascript ao invés de eloquente-javascript. Ficando assim com o nome original!

O que acham?

Cap. 17 - HTTP

Transferir website

Estou pensando em mudar o website aqui nesse repositório.

Como ele é feito em jekyll, no caso é só criar uma branch orfã. Dessa forma centralizamos tudo nesse repositório.

O que acham?

Guia nos formatos PDF e Epub

Tem alguma possibilidade de empacotar nos formatos PDF e Epub?

LICENSE

Atualmente estamos linkando uma licença, não seria interessante termos uma dentro do repositório?
Talvez daria até pra usar alguma que o Github sugere, que tal?

Canal de Comunicação

O @ewertonorg sugeriu usar uma ferramenta para comunicação. Tipo Gitter ou Slack. O que acham galera?

Seria interessante para colocar as ideias lá e interagimos melhor entre todos.

Por mim seria uma boa, e usaria Slack pela integração com o GitHub!

O que acham?

Cap. 20 - Node.js

Cap. 18 - Formulários e Campos de Formulários

Cap.13 - O Document Object Model

Tradução do arquivo 13-document-object-model.md

Original: link

Cap. 16 - Desenhando no Canvas

Cap.03 - Funções

Tradução do arquivo 03-funcoes.md

Original: link

Cap.05 - Funções de Ordem Superior

Tradução do arquivo 05-funcoes-de-ordem-superior.md

Original: link

Link para Download

Converti para ePub

1. Para Converter
   http://johnmacfarlane.net/pandoc/

2. Para Editar
   https://github.com/user-none/Sigil/releases

Link pra baixar
http://minhateca.com.br/movibe/eloquente-javascript,411419992.epub

Cap. 15 - Projeto: Plataforma de Jogo

Estrutura e Organização

Fala pessoal, tudo bem?

Sugiro que seja colocado uma tabela de conteúdo com os seus respectivos links no README.md. Além disso, podemos utilizar a mesma mecânica da tradução da documentação do Grunt. Ou seja, para cada arquivo será aberta uma issue, com labels para revisão, tradução e um milestone para o progresso da tradução.

Assim, deixamos mais organizado. O que acham?

Espero que ajude. Abraço!

Criar arquivo CONTRIBUTING.md

[LOG] Capítulo 04 — Estrutura de Dados: Objetos e Arrays

Essa issue tem o propósito de manter um log de todas as alterações referentes ao capítulo, não sendo um espaço para discussões, dúvidas e sugestões. Caso queira contribuir, abra uma issue/pull-request individual com sua contribuição.

Atenção: Quando abrir uma issue ou pull request referente a esse capítulo, faça referência usando:
ref "#215".

Arquivo: 04-estrutura-de-dados.md

Original: link

Cap. 14 - Manipulando Eventos

Criar página de Glossário na wiki

Como foi conversado em #67 e tendo como base as modificações em #78

• Criar página na wiki (https://github.com/braziljs/eloquente-javascript/wiki/Gloss%C3%A1rio)
• Remover arquivo glossario.md

Como vocês traduziriam o termo: "Debug"?

Me deparei com essa palavra na supervisão do capítulo 8 (#14 ). Estamos usando hoje "depuração" para traduzir esse termo, o que é uma tradução válida. Eu achei interessante levantar essa issue para discutir esse termo pois o verbo "Depurar" acaba se tornando muito formal, e muitas vezes acabamos falando algo na linha: "Debugar", "Debugando" etc...

O que vocês acham? Mantemos essa linha formal (já que é uma tradução de texto), ou seguimos uma direção mais informal?

Seguem algumas referências:

• http://www.dicionarioinformal.com.br/depurar/
• http://michaelis.uol.com.br/moderno/portugues/index.php?lingua=portugues-portugues&palavra=depurar
• http://www.dicionarioinformal.com.br/debugar/
• http://michaelis.uol.com.br/moderno/portugues/index.php?lingua=portugues-portugues&palavra=debugar

@braziljs/eloquent-javascript