Merge pull request #30 from javascript-tutorial/sync-6bbe0b43

Sync with upstream @ 6bbe0b4

Author: HachemiH

1-js/01-getting-started/1-intro/article.md

@@ -109,7 +109,11 @@ Donc, récemment, une pléthore de nouveaux langages sont apparus, qui sont *tra
 
 Les outils modernes rendent la [transpilation](https://fr.wiktionary.org/wiki/transpilation) très rapide et transparente, permettant aux développeurs de coder dans une autre langue et de la convertir automatiquement "sous le capot".
 
+<<<<<<< HEAD
 Les exemples les plus courants de ce genre de langages :
+=======
+Examples of such languages:
+>>>>>>> 6bbe0b4313a7845303be835d632ef8e5bc7715cd
 
 - [CoffeeScript](http://coffeescript.org/) est un "sucre syntaxique" pour JavaScript, il introduit une syntaxe plus courte, permettant d’écrire du code plus précis et plus clair. Habituellement, les développeurs Ruby l'aiment bien.
 - [TypeScript](http://www.typescriptlang.org/) se concentre sur l'ajout de "typage strict des données" pour simplifier le développement et la prise en charge de systèmes complexes. Il est développé par Microsoft.

1-js/02-first-steps/01-hello-world/hello-world-render.png

@@ -219,9 +219,15 @@ typeof alert // "function"  (3)
 
 Les trois dernières lignes peuvent nécessiter des explications supplémentaires :
 
+<<<<<<< HEAD
 1. `Math` est un objet interne au langage qui fournit des opérations mathématiques. Nous allons l'apprendre dans le chapitre <info:number>. Ici, il sert uniquement comme exemple d'un objet.
 2. Le résultat de `typeof null` est "object". C'est faux. C'est une erreur officiellement reconnue dans `typeof`, conservée pour compatibilité. Bien sûr, `null` n'est pas un objet. C'est une valeur spéciale avec un type distinct qui lui est propre. Donc, encore une fois, c’est une erreur dans le langage.
 3. Le résultat de `typeof alert` est "function", car `alert` est une fonction du langage. Nous étudierons les fonctions dans les chapitres suivants, et nous verrons qu’il n’ya pas de type "fonction" dans le langage. Les fonctions appartiennent au type `object`. Mais `typeof` les traite différemment. Formellement, c'est incorrect, mais très pratique.
+=======
+1. `Math` is a built-in object that provides mathematical operations. We will learn it in the chapter <info:number>. Here, it serves just as an example of an object.
+2. The result of `typeof null` is `"object"`. That's wrong. It is an officially recognized error in `typeof`, kept for compatibility. Of course, `null` is not an object. It is a special value with a separate type of its own. So, again, this is an error in the language.
+3. The result of `typeof alert` is `"function"`, because `alert` is a function. We'll study functions in the next chapters where we'll also see that there's no special "function" type in JavaScript. Functions belong to the object type. But `typeof` treats them differently, returning `"function"`. That's not quite correct, but very convenient in practice.
+>>>>>>> 6bbe0b4313a7845303be835d632ef8e5bc7715cd
 
 
 ## Résumé

1-js/02-first-steps/01-hello-world/[email protected]

@@ -127,11 +127,19 @@ Pourquoi les plus unaires sont-ils appliqués aux valeurs avant les binaires ? C
 
 ## Précédence des opérateurs
 
+<<<<<<< HEAD
 Si une expression a plusieurs opérateurs, l’ordre d’exécution est défini par leur priorité ou, en d’autres termes, il existe un ordre de priorité implicite entre les opérateurs.
+=======
+If an expression has more than one operator, the execution order is defined by their *precedence*, or, in other words, the default priority order of operators.
+>>>>>>> 6bbe0b4313a7845303be835d632ef8e5bc7715cd
 
 De l'école, nous savons tous que la multiplication dans l'expression `1 + 2 * 2` devrait être calculée avant l'addition. C’est exactement cela la précédence. La multiplication est dite avoir une *précédence supérieure* à l'addition.
 
+<<<<<<< HEAD
 Les parenthèses outrepassent toute précédence, donc si nous ne sommes pas satisfaits de l'ordre de traitement, nous pouvons les utiliser, comme: `(1 + 2) * 2`.
+=======
+Parentheses override any precedence, so if we're not satisfied with the default order, we can use them to change it. For example, write `(1 + 2) * 2`.
+>>>>>>> 6bbe0b4313a7845303be835d632ef8e5bc7715cd
 
 Il y a beaucoup d'opérateurs en JavaScript. Chaque opérateur a un numéro correspondant à sa priorité de précédence. Celui qui est plus haut sur le tableau s'exécute en premier. Si la priorité est la même, l'ordre d'exécution est de gauche à droite.
 
@@ -199,9 +207,15 @@ alert( a ); // 3
 alert( c ); // 0
 ```
 
+<<<<<<< HEAD
 Dans l'exemple ci-dessus, le résultat de `(a = b + 1)` est la valeur attribuée à `a` (c'est-à-dire `3`). Il est ensuite utilisé pour soustraire de `3`.
 
 Code drôle, n'est-ce pas ? Nous devrions comprendre comment cela fonctionne, car parfois nous pouvons le voir dans des bibliothèques tierces, mais nous ne devrions pas écrire quoi que ce soit de similaire nous-mêmes. De telles astuces ne permettent pas de rendre le code plus clair et lisible.
+=======
+In the example above, the result of expression `(a = b + 1)` is the value which was assigned to `a` (that is `3`). It is then used for further evaluations.
+
+Funny code, isn't it? We should understand how it works, because sometimes we see it in JavaScript libraries, but shouldn't write anything like that ourselves. Such tricks definitely don't make code clearer or readable.
+>>>>>>> 6bbe0b4313a7845303be835d632ef8e5bc7715cd
 ````
 
 ## Reste % (Modulo)
@@ -427,10 +441,17 @@ Ici, la première expression `1 + 2` est évaluée mais son résultat n'est pas
 ```smart header="La virgule a une très faible précédence"
 Veuillez noter que l'opérateur virgule a une précédence très basse, inférieure à `=`, donc les parenthèses sont importantes dans l'exemple ci-dessus.
 
+<<<<<<< HEAD
 Sans eux : `a = 1 + 2, 3 + 4` évalue d'abord `+`, additionnant les nombres dans `a = 3, 7`, ensuite l'opérateur d'affectation `=` assigne `a = 3`, puis le nombre après la virgule `7` n'est pas traité c'est ignoré.
 ```
 
 Pourquoi avons-nous besoin d'un tel opérateur qui jette tout sauf la dernière partie ?
+=======
+Without them: `a = 1 + 2, 3 + 4` evaluates `+` first, summing the numbers into `a = 3, 7`, then the assignment operator `=` assigns `a = 3`, and the rest is ignored. It's like `(a = 1 + 2), 3 + 4`.
+```
+
+Why do we need an operator that throws away everything except the last expression?
+>>>>>>> 6bbe0b4313a7845303be835d632ef8e5bc7715cd
 
 Parfois, les gens l'utilisent dans des constructions plus complexes pour placer plusieurs actions sur une seule ligne.
 
@@ -443,4 +464,8 @@ for (*!*a = 1, b = 3, c = a * b*/!*; a < 10; a++) {
 }
 ```
 
+<<<<<<< HEAD
 Ces astuces sont utilisées dans de nombreux frameworks JavaScript, c’est pourquoi nous les mentionnons. Mais généralement, ils n'améliorent pas la lisibilité du code, nous devrions donc bien réfléchir avant d'écrire comme ça.
+=======
+Such tricks are used in many JavaScript frameworks. That's why we're mentioning them. But usually they don't improve code readability so we should think well before using them.
+>>>>>>> 6bbe0b4313a7845303be835d632ef8e5bc7715cd

1-js/02-first-steps/05-types/article.md

@@ -2,13 +2,21 @@
 
 Notre code doit être aussi propre et lisible que possible.
 
+<<<<<<< HEAD
 C’est en fait un art de la programmation -- prendre une tâche complexe et la coder de manière correcte et lisible par l’homme.
+=======
+That is actually the art of programming -- to take a complex task and code it in a way that is both correct and human-readable. A good code style greatly assists in that.  
+>>>>>>> 6bbe0b4313a7845303be835d632ef8e5bc7715cd
 
 Une chose à aider est le bon style de code.
 
+<<<<<<< HEAD
 ## Syntaxe
 
 Un cheatsheet avec les règles (plus de détails ci-dessous) :
+=======
+Here is a cheat sheet with some suggested rules (see below for more details):
+>>>>>>> 6bbe0b4313a7845303be835d632ef8e5bc7715cd
 
 ![](code-style.png)
 <!--
@@ -38,7 +46,13 @@ if (n < 0) {
 
 Discutons maintenant des règles et de leurs raisons en détail.
 
+<<<<<<< HEAD
 Rien n'est "gravé dans le marbre" ici. Tout est optionnel et peut être modifié: ce sont des règles de codage, pas des dogmes religieux.
+=======
+```warn header="There are no \"you must\" rules"
+Nothing is set in stone here. These are style preferences, not religious dogmas.
+```
+>>>>>>> 6bbe0b4313a7845303be835d632ef8e5bc7715cd
 
 ### Accolades
 
@@ -54,7 +68,11 @@ if (condition) {
 }
 ```
 
+<<<<<<< HEAD
 Une construction sur une seule ligne est un cas important. Devrions-nous utiliser des crochets ? Si oui, alors où ?
+=======
+A single-line construct, such as `if (condition) doSomething()`, is an important edge case. Should we use braces at all?
+>>>>>>> 6bbe0b4313a7845303be835d632ef8e5bc7715cd
 
 Voici les variantes annotées pour que vous puissiez juger de leur lisibilité :
 
@@ -74,13 +92,41 @@ if (n < 0) {
 -->
 ![](figure-bracket-style.png)
 
+<<<<<<< HEAD
 En résumé :
 - Pour un code vraiment court, une ligne est acceptable: comme `if (cond) return null`.
 - Mais une ligne distincte pour chaque affirmation entre parenthèses est généralement préférable.
 
 ### Longueur de la ligne
 
 La longueur maximale de la ligne doit être limitée. Personne n'aime suivre les yeux sur une longue ligne horizontale. C’est mieux de la scinder.
+=======
+### Line Length
+
+No one likes to read a long horizontal line of code. It's best practice to split them.
+
+For example:
+```js
+// backtick quotes ` allow to split the string into multiple lines
+let str = `
+  Ecma International's TC39 is a group of JavaScript developers,
+  implementers, academics, and more, collaborating with the community
+  to maintain and evolve the definition of JavaScript.
+`;
+```
+
+And, for `if` statements:
+
+```js
+if (
+  id === 123 &&
+  moonPhase === 'Waning Gibbous' &&
+  zodiacSign === 'Libra'
+) {
+  letTheSorceryBegin();
+}
+```
+>>>>>>> 6bbe0b4313a7845303be835d632ef8e5bc7715cd
 
 La longueur de ligne maximale est convenue au niveau de l'équipe. C’est généralement 80 ou 120 caractères.
 
@@ -129,15 +175,25 @@ Il existe deux types d'indentations :
 
 Un point-virgule doit être présent après chaque déclaration. Même si cela pourrait éventuellement être ignoré.
 
+<<<<<<< HEAD
 Il y a des langages où le point-virgule est vraiment optionnel. Il est donc rarement utilisé. Mais dans JavaScript, il y a peu de cas où un saut de ligne n'est parfois pas interprété comme un point-virgule. Cela laisse place à des erreurs de programmation.
 
 À mesure que vous devenez plus mature en tant que programmeur, vous pouvez choisir un style sans point-virgule, comme [StandardJS](https://standardjs.com/), mais c’est seulement lorsque vous connaissez bien JavaScript et que vous comprenez les pièges possibles.
+=======
+There are languages where a semicolon is truly optional and it is rarely used. In JavaScript, though, there are cases where a line break is not interpreted as a semicolon, leaving the code vulnerable to errors. See more about that in the chapter <info:structure#semicolon>.
+
+If you're an experienced JavaScript programmer, you may choose a no-semicolon code style like [StandardJS](https://standardjs.com/). Otherwise, it's best to use semicolons to avoid possible pitfalls. The majority of developers put semicolons.
+>>>>>>> 6bbe0b4313a7845303be835d632ef8e5bc7715cd
 
 ### Niveaux d'imbrications
 
 Il ne devrait pas y avoir trop de niveaux d'imbrication.
 
+<<<<<<< HEAD
 C’est parfois une bonne idée d’utiliser la directive ["continue"](info:while-for#continue) dans la boucle pour éviter l'imbrication supplémentaire `if(..) { ... }` :
+=======
+For example, in the loop, it's sometimes a good idea to use the ["continue"](info:while-for#continue) directive to avoid extra nesting.
+>>>>>>> 6bbe0b4313a7845303be835d632ef8e5bc7715cd
 
 Au lieu de :
 
@@ -199,13 +255,21 @@ function pow(x, n) {
 }
 ```
 
+<<<<<<< HEAD
 … Mais le second est plus lisible, car le "cas marginal" de `n < 0` est traité tôt, et nous avons ensuite le flux de code "principal", sans imbrication supplémentaire.
+=======
+The second one is more readable because the "special case" of `n < 0` is handled early on. Once the check is done we can move on to the "main" code flow without the need for additional nesting.
+>>>>>>> 6bbe0b4313a7845303be835d632ef8e5bc7715cd
 
 ## Placement de Fonction
 
 Si vous écrivez plusieurs fonctions "helper" (auxiliaires) et le code pour les utiliser, il existe trois façons de les placer.
 
+<<<<<<< HEAD
 1. Fonctions au dessus du code qui les utilise :
+=======
+1. Declare the functions *above* the code that uses them:
+>>>>>>> 6bbe0b4313a7845303be835d632ef8e5bc7715cd
 
     ```js
     // *!*fonctions declarations*/!*
@@ -252,15 +316,23 @@ Si vous écrivez plusieurs fonctions "helper" (auxiliaires) et le code pour les
 
 La plupart du temps, la deuxième variante est préférée.
 
+<<<<<<< HEAD
 C’est parce qu’en lisant un code, nous voulons d’abord savoir "ce qu’il fait". Si le code commence en premier, alors il fournit cette information. Et puis peut-être n’aurons-nous pas besoin de lire les fonctions du tout, surtout si leur nom correspond à ce qu’elles font.
+=======
+That's because when reading code, we first want to know *what it does*. If the code goes first, then it becomes clear from the start. Then, maybe we won't need to read the functions at all, especially if their names are descriptive of what they actually do.
+>>>>>>> 6bbe0b4313a7845303be835d632ef8e5bc7715cd
 
 ## Guides de style
 
 Un guide de style contient des règles générales sur "comment écrire": les quotes à utiliser, le nombre d'espaces à mettre en retrait, l'emplacement des sauts de ligne, etc. Beaucoup de petites choses.
 
 Au total, lorsque tous les membres d'une équipe utilisent le même guide de style, le code est uniforme. Peu importe qui l’a écrit, c’est toujours le même style.
 
+<<<<<<< HEAD
 Certes, une équipe peut réfléchir à un guide de style. Mais dorénavant, il n’est plus nécessaire de le faire. Il existe de nombreux guides de style éprouvés et faciles à adopter.
+=======
+Of course, a team can always write their own style guide, but usually there's no need to. There are many existing guides to choose from.
+>>>>>>> 6bbe0b4313a7845303be835d632ef8e5bc7715cd
 
 Par exemple :
 
@@ -270,15 +342,27 @@ Par exemple :
 - [StandardJS](https://standardjs.com/)
 - (il y en a plus)
 
+<<<<<<< HEAD
 Si vous êtes un développeur novice, vous pouvez commencer par le cheatsheet ci-dessus dans le chapitre, puis consulter les guides de style pour découvrir les principes communs et éventuellement en choisir un.
+=======
+If you're a novice developer, start with the cheat sheet at the beginning of this chapter. Then you can browse other style guides to pick up more ideas and decide which one you like best.
+>>>>>>> 6bbe0b4313a7845303be835d632ef8e5bc7715cd
 
 ## Linters automatisés
 
+<<<<<<< HEAD
 Il existe des outils permettant de vérifier le style de code automatiquement. Ils s'appellent des "linters".
 
 Ce qui est génial avec eux, c'est que la vérification du style trouve également des bugs, comme une faute de frappe dans une variable ou un nom de fonction.
 
 Il est donc recommandé d’en installer un, même si vous ne voulez pas vous en tenir à un «style de code». Ils aident à trouver des fautes de frappe - et cela suffit déjà.
+=======
+Linters are tools that can automatically check the style of your code and make improving suggestions.
+
+The great thing about them is that style-checking can also find some bugs, like typos in variable or function names. Because of this feature, using a linter is recommended even if you don't want to stick to one particular "code style".
+
+Here are some well-known linting tools:
+>>>>>>> 6bbe0b4313a7845303be835d632ef8e5bc7715cd
 
 Les outils les plus connus sont :
 
@@ -326,8 +410,14 @@ De plus, certains IDE prennent en charge le linting nativement, ce qui peut éga
 
 ## Résumé
 
+<<<<<<< HEAD
 Toutes les règles de syntaxe de ce chapitre et les guides de style visent à améliorer la lisibilité, elles sont donc toutes discutables.
 
 Lorsque nous réfléchissons à "comment écrire mieux ?", Le seul critère est "qu'est-ce qui rend le code plus lisible et plus facile à comprendre ? qu'est-ce qui aide à éviter les erreurs ?". C’est l’essentiel à garder à l’esprit lors du choix du style ou de la question de savoir lequel est le meilleur.
+=======
+All syntax rules described in this chapter (and in the style guides referenced) aim to increase the readability of your code. All of them are debatable.
+
+When we think about writing "better" code, the questions we should ask ourselves are: "What makes the code more readable and easier to understand?" and "What can help us avoid errors?" These are the main things to keep in mind when choosing and debating code styles.
+>>>>>>> 6bbe0b4313a7845303be835d632ef8e5bc7715cd
 
 Lisez les guides de style pour connaître les dernières idées à ce sujet et suivez celles que vous trouvez les meilleures.

1-js/02-first-steps/07-operators/article.md

@@ -4,7 +4,11 @@ Comme nous le savons du chapitre <info:structure>, les commentaires peuvent êtr
 
 Nous les utilisons normalement pour décrire comment et pourquoi le code fonctionne.
 
+<<<<<<< HEAD
 De prime abord, les commentaires peuvent sembler évidents, mais les novices en programmation se trompent généralement.
+=======
+At first sight, commenting might be obvious, but novices in programming usually get it wrong.
+>>>>>>> 6bbe0b4313a7845303be835d632ef8e5bc7715cd
 
 ## Mauvais commentaires
 
@@ -18,7 +22,11 @@ complex;
 code;
 ```
 
+<<<<<<< HEAD
 Mais en bon code, le nombre de ces commentaires "explicatifs" devrait être minime. Sérieusement, le code devrait être facile à comprendre sans eux.
+=======
+But in good code, the amount of such "explanatory" comments should be minimal. Seriously, the code should be easy to understand without them.
+>>>>>>> 6bbe0b4313a7845303be835d632ef8e5bc7715cd
 
 Il existe une excellente règle à ce sujet: "Si le code est si peu clair qu’il nécessite un commentaire, il devrait peut-être être réécrit".
 

1-js/03-code-quality/01-debugging-chrome/chrome-open-sources.png

@@ -4,7 +4,11 @@ Ce que nous avons ici est en fait 3 tests, mais présentés comme une seule fonc
 
 Parfois, il est plus facile d’écrire de cette façon, mais si une erreur se produit, ce qui a mal tourné est beaucoup moins évident.
 
+<<<<<<< HEAD
 Si une erreur survient dans un flux d’exécution complexe, nous devrons bien comprendre les données à ce stade. Nous devrons en fait *déboguer le test*.
+=======
+If an error happens in the middle of a complex execution flow, then we'll have to figure out the data at that point. We'll actually have to *debug the test*.
+>>>>>>> 6bbe0b4313a7845303be835d632ef8e5bc7715cd
 
 Il serait bien préférable de diviser le test en plusieurs blocs `it` avec des entrées et des sorties clairement écrites.