Portuguese (Brazil) version

Portuguese (Brazil) version

Author: angellicacardozo

doc/language.json

@@ -1,5 +1,5 @@
 {
     "default": "en",
-    "listed": ["en", "fi", "ru", "zhtw", "zh", "tr", "pl", "ko", "ja", "es", "it", "hu"]
+    "listed": ["en", "fi", "ru", "zhtw", "zh", "tr", "pl", "ko", "ja", "es", "it", "hu","pt"]
 }
 

doc/pt/array/constructor.md

@@ -0,0 +1,29 @@
+## O construtor `Array`
+
+Uma vez que o construtor `Array` é ambíguo na forma como ele lida com seus parâmetros,
+o uso da notação `[]` é fortemente recomendado ao criar novo arrays.
+
+    [1, 2, 3]; // Resultado: [1, 2, 3]
+    new Array(1, 2, 3); // Resultado: [1, 2, 3]
+
+    [3]; // Resultado: [3]
+    new Array(3); // Resultado: []
+    new Array('3') // Resultado: ['3']
+
+Nos casos onde somente um argumento é passado para o construtor `Array` e quando o argumento é
+um `Number`, o construtor retornará um novo array *sem elementos* com a propriedade `length` configurada de acordo com o valor do argumento.
+É importante perceber que **somente** a propriedade `length` do novo array será configurada desta maneira; os índices do array não serão inicializados.
+
+    var arr = new Array(3);
+    arr[1]; // undefined
+    1 in arr; // false, o índice não foi definida
+
+Ser capaz de definir o comprimento de um array antecipadamente é útil em poucos casos,
+como ao replicar uma string, em que se evita o uso de um loop.
+
+    new Array(count + 1).join(stringToRepeat);
+
+### Conclusão
+
+O uso de literais é preferencial na inicialição de Arrays. São curtos, possuem uma sintaxe limpa, e contribuem para a legibilidade do código.
+

doc/pt/array/general.md

@@ -0,0 +1,59 @@
+## Iteração com Arrays e propriedades
+
+Embora arrays em JavaScript sejam objetos, não existem boas razões para utilizar
+o [`for in`](#object.forinloop) loop. De fato, existem muitas boas razões para 
+**evitar** o uso de `for in` com arrays.
+
+> **Nota:** JavaScript arrays **não** são *arrays associativos*. JavaScript utiliza 
+> [objects](#object.general) apenas para mapear chaves com valores. Enquanto arrays associativos 
+> **preservam** a ordem, objetos **não preservam**.
+
+Uma vez que o `for in` loop enumera todas as propriedades que estão na cadeia
+prototype e visto que o único modo de excluir tais propriedades é por meio do uso
+do [`hasOwnProperty`](#object.hasownproperty), ele chega a ser **vinte vezes**
+mais custoso que o uso normal do `for` loop.
+
+### Iteração
+
+A fim de atingir a melhor performance ao interagir sobre arrays, 
+a melhor opção é utilizar o clássico `for` loop.
+
+    var list = [1, 2, 3, 4, 5, ...... 100000000];
+    for(var i = 0, l = list.length; i < l; i++) {
+        console.log(list[i]);
+    }
+
+Existe um detalhe importante no exemplo acima , que é o caching
+do comprimento do array via `l = list.length`.
+
+Embora a propriedade `length` esteja definida no próprio array, ainda existe
+um trabalho extra ao executar a busca em cada iteração do array.
+Enquanto que recentes engines JavaScript **talvez** implementem um otimização
+para este caso, não existe uma maneira de saber quando o código será executado em uma
+dessas novas engines. 
+
+De fato, deixando de lado o armazenamento em caching pode resultar em um loop **duas vezes mais rápido** 
+do que com o armazenamento em caching.
+
+### A propriedade `length`
+
+Enquanto que o *getter* da propriedade `length` retorna o total de elementos
+que estão contidos no array, o *setter* pode ser usado para **truncar** o array. 
+
+    var foo = [1, 2, 3, 4, 5, 6];
+    foo.length = 3;
+    foo; // [1, 2, 3]
+
+    foo.length = 6;
+    foo.push(4);
+    foo; // [1, 2, 3, undefined, undefined, undefined, 4]
+
+Atribuir um valor de menor para length trunca o array. Por outro lado, incrementando
+o valor de length cria um array esparso.
+
+### Conclusão
+
+Para melhor performance, é recomendado o uso do `for` loop e o cache da propriedade
+`length`. O uso do `for in` loop na iteração com array é um sinal de código mal escrito 
+e tendencioso a apresentar defeitos, além de ter performance ruim.
+

doc/pt/core/delete.md

@@ -0,0 +1,85 @@
+## O operador `delete`
+
+Em resumo, é *impossível* remover variáveis globais, funções e outras coisas em JavaScript
+que tenham o atributo `DontDelete` definido.
+
+### Código global e código de função
+
+Quando uma variável ou função é definida no escopo global ou em 
+um [escopo de função](#function.scopes) ela passa a ser uma propriedade de ambos
+objeto Activation e do objeto Global. Tais propriedades possuem um conjunto de atributos, um dos quais é o `DontDelete`.
+Declarações de funções e variáveis em código global e em código de função
+sempre criam propriedades com `DontDelete`, e portanto não podem ser removidas.
+
+    // variável global:
+    var a = 1; // DontDelete está definido
+    delete a; // false
+    a; // 1
+
+    // função comum:
+    function f() {} // DontDelete está definido
+    delete f; // false
+    typeof f; // "function"
+
+    // mudar o valor do atributo não ajuda:
+    f = 1;
+    delete f; // false
+    f; // 1
+
+### Propriedades explícitas
+
+Propriedades definidas explicitamente podem ser apagadas normalmente.
+
+    // definição explícita de propriedade:
+    var obj = {x: 1};
+    obj.y = 2;
+    delete obj.x; // true
+    delete obj.y; // true
+    obj.x; // undefined
+    obj.y; // undefined
+
+No exemplo acima, `obj.x` e `obj.y` podem ser removidos por que eles não possuem o
+atributo `DontDelete`. Este é o motivo pelo qual o exemplo abaixo também funciona.
+
+    // Desconsiderando o IE, isto funciona bem:
+    var GLOBAL_OBJECT = this;
+    GLOBAL_OBJECT.a = 1;
+    a === GLOBAL_OBJECT.a; // true - apenas uma variável global
+    delete GLOBAL_OBJECT.a; // true
+    GLOBAL_OBJECT.a; // undefined
+
+Aqui nós utilizamos um truque para remover `a`. Aqui o [`this`](#function.this)
+faz referência ao objeto Global e declara explicitamente a variável `a` como
+sua propriedade a qual nos permite removê-la.
+
+O IE (pelo menos 6-8) possui defeitos, então o código acima não funciona.
+
+### Argumentos de função e propriedades nativas
+
+Argumentos de função, [objetos `arguments`](#function.arguments) e 
+propriedades nativas tambêm possuem o `DontDelete` definido.
+
+    // argumentos de funções e propriedades:
+    (function (x) {
+    
+      delete arguments; // false
+      typeof arguments; // "object"
+      
+      delete x; // false
+      x; // 1
+      
+      function f(){}
+      delete f.length; // false
+      typeof f.length; // "number"
+      
+    })(1);
+
+### Objetos hosts
+    
+O comportamento do operador `delete` pode ser imprevisível para objetos hosts.
+Devido a especificação, objetos hosts têm permissão para implementar qualquer tipo de comportamento.
+
+### Conclusão
+
+O operador `delete` freqüentemente apresenta um comportamento inesperado e só
+pode ser usado com segurança para remover propriedades definidas explicitamente em objetos normais.

doc/pt/core/eval.md

@@ -0,0 +1,45 @@
+## Por que não utilizar `eval`
+
+A função `eval` executará uma string de código JavaScript no escopo local.
+
+    var foo = 1;
+    function test() {
+        var foo = 2;
+        eval('foo = 3');
+        return foo;
+    }
+    test(); // 3
+    foo; // 1
+
+Entreranto, `eval` somente é executado no escopo local quando é chamado diretamente
+*e* quanto o nome da função chamada é `eval`. 
+
+    var foo = 1;
+    function test() {
+        var foo = 2;
+        var bar = eval;
+        bar('foo = 3');
+        return foo;
+    }
+    test(); // 2
+    foo; // 3
+
+O uso de `eval` deve ser evitado. 99.9% de seu "uso" pode ser alcançado **sem** ele.
+    
+### `eval` dissimulado
+
+As [funções timeout](#other.timeouts) `setTimeout` e `setInterval` podem ambas receberem uma string
+como primeiro argumento. Tais strings **sempre** serão executadas no escopo global uma vez que 
+`eval` não é chamado diretamente, naquele caso.
+
+### Problemas de segurança
+
+`eval` também é considerado um problema de segurança, por que executa **qualquer** código dado.
+Ele **nunca** deve ser utilizado com strings de origens duvidosas ou desconhecidas.
+
+### Conclusão
+
+`eval` nunca deve ser utilizado. Qualquer código que faça uso de `eval` seve ser questionado
+em sua utilizade, performance e segurança. Se algo necessita de `eval` para funcionar, então **não** deve ser utilizado.
+Um *design melhor* deve ser utilizado, um que não faça uso de `eval`.
+

doc/pt/core/semicolon.md

@@ -0,0 +1,106 @@
+## Inserção automática do ponto e vírgula 
+
+Apesar do JavaScript possuir uma sintaxe no estilo C, o uso do ponto e vírgula **não** é obrigatório. 
+
+JavaScript não é uma linguagem 'semicolon-less'. De fato, o ponto e vírgula é necessário para o interpretação do código. Entretanto, o parser do JavaScript insere o **automaticamente** ponto e vírgula sempre que ocorrer um error de parser, decorrente da falta do ponto e vírgula. 
+
+    var foo = function() {
+    } // parse error, semicolon expected
+    test()
+
+A inserção acontece e o parser realiza uma nova tentativa. 
+
+    var foo = function() {
+    }; // no error, parser continues
+    test()
+
+A inseção automática de ponto e vírgula é considerada um dos **maiores** equívocos no design da linguagem pois pode influenciar no comportamento do código.
+
+### Como funciona
+
+O código abaixo não possui ponto e vírgula, então fica à cargo do parser inserir o ponto e vírgula onde julgar necessário.
+
+    (function(window, undefined) {
+        function test(options) {
+            log('testing!')
+
+            (options.list || []).forEach(function(i) {
+
+            })
+
+            options.value.test(
+                'long string to pass here',
+                'and another long string to pass'
+            )
+
+            return
+            {
+                foo: function() {}
+            }
+        }
+        window.test = test
+
+    })(window)
+
+    (function(window) {
+        window.someLibrary = {}
+
+    })(window)
+
+Abaixo está o resultado do processamento do parser.
+
+    (function(window, undefined) {
+        function test(options) {
+
+            // Not inserted, lines got merged
+            log('testing!')(options.list || []).forEach(function(i) {
+
+            }); // <- inserted
+
+            options.value.test(
+                'long string to pass here',
+                'and another long string to pass'
+            ); // <- inserted
+
+            return; // <- inserted, breaks the return statement
+            { // treated as a block
+
+                // a label and a single expression statement
+                foo: function() {} 
+            }; // <- inserted
+        }
+        window.test = test; // <- inserted
+
+    // The lines got merged again
+    })(window)(function(window) {
+        window.someLibrary = {}; // <- inserted
+
+    })(window); //<- inserted
+
+> **Nota:** O parser do JavaScript não manipula corretamente 'return statements' que são seguidos de uma nova linha. Apesar de não ser necessariamente uma > > > falha da inserção automática do ponto e vírgula, ainda pode gerar efeitos colaterais não-esperados. 
+
+O parser mudou o comportamento do código acima drásticamente. Em determinados casos, o parser **não procede** como o esperado. 
+
+### Parênteses 
+
+No caso de parênteses, o parser **não** insere o ponto  e vírgula. 
+
+    log('testing!')
+    (options.list || []).forEach(function(i) {})
+
+Este código é interpretado em uma só linha. 
+
+    log('testing!')(options.list || []).forEach(function(i) {})
+
+As chances de `log` não retornar uma função são **muito** altas; portanto, o código acima irá produzir um `TypeError` informando que `undefined is not a function`.
+
+### Conclusão
+
+It is highly recommended to **never** omit semicolons. It is also recommended
+that braces be kept on the same line as their corresponding statements and to
+never omit them for single-line `if` / `else` statements. These measures will
+not only improve the consistency of the code, but they will also prevent the
+JavaScript parser from changing code behavior.
+
+É **fortemente** recomendado que nunca se omita o ponto e vírgula. Também é recomendado que chaves sejam mantidas na mesma linha que seus statements e que nunca sejam omitadas em declações de uma só linha como `if` / `else` statements. Tais medidas não somente melhorarão a consistência do código, como também irão previnir alteração no comportamento do código por má interpretação do parser do JavaScript.
+