Merge pull request #137 from bogdanbacosca/sync-29216730

update

Author: bogdanbacosca

1-js/04-object-basics/04-object-methods/7-calculator/task.md

@@ -6,7 +6,7 @@ importance: 5
 
 Creați un obiect `calculator` cu trei metode:
 
-- `read()` solicită două valori și le salvează ca proprietăți ale obiectului.
+- `read()` solicită două valori și le salvează ca proprietăți ale obiectului cu numele `a` respectiv `b`.
 - `sum()` returnează suma valorilor salvate.
 - `mul()` multiplică valorile salvate și returnează rezultatul.
 

1-js/04-object-basics/04-object-methods/8-chain-calls/solution.md

@@ -23,10 +23,10 @@ let ladder = {
   }
 };
 
-ladder.up().up().down().showStep().down().showStep(); // shows 1 then 0
+ladder.up().up().down().showStep().down().showStep(); // arată 1 apoi 0
 ```
 
-De asemenea, putem scrie câte o apelare pe linie. Pentru înlănțuirile lungi este mai lizibil:
+De asemenea putem scrie câte o singură apelare pe linie. Pentru înlănțuirile lungi este mai lizibil:
 
 ```js
 ladder

1-js/04-object-basics/04-object-methods/article.md

@@ -70,7 +70,7 @@ OOP este un lucru mare, o știință interesantă în sine. Cum să alegi entit
 Există o sintaxă mai scurtă pentru metode într-un obiect literal:
 
 ```js
-// aceste obiecte realizează același lucru
+// aceste obiecte fac același lucru
 
 user = {
   sayHi: function() {
@@ -90,7 +90,7 @@ user = {
 
 După cum s-a demonstrat, putem omite `"function"` și scriem doar `sayHi()`.
 
-În realitate, notațiile nu sunt complet identice. Există diferențe subtile legate de moștenirea obiectelor (care vor fi acoperite ulterior), dar deocamdată nu contează. În aproape toate cazurile, se preferă sintaxa mai scurtă.
+Să spunem adevărul, notațiile nu sunt complet identice. Există diferențe subtile legate de moștenirea obiectelor (care vor fi acoperite ulterior), dar deocamdată nu contează. În aproape toate cazurile, se preferă sintaxa mai scurtă.
 
 ## "this" în metode
 

1-js/04-object-basics/08-symbol/article.md

@@ -70,6 +70,7 @@ alert(id.toString()); // Symbol(id), acum funcționează
 ```
 
 Sau să obținem proprietatea `symbol.description` pentru a afișa numai descrierea:
+
 ```js run
 let id = Symbol("id");
 *!*
@@ -172,7 +173,7 @@ alert( "Direct: " + user[id] ); // Direct: 123
 
 [Object.keys(user)](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/keys) le ignoră, de asemenea. Aceasta este o parte a principiului general "ascunderea proprietăților simbolice". Dacă un alt script sau librărie iterează asupra obiectului nostru, nu va accesa neașteptat o proprietate simbol.
 
-În contrast, metoda [Object.assign](mdn:js/Object/assign) copiază proprietățile de ambele tipuri, șir și simbol:
+În contrast, metoda [Object.assign](mdn:js/Object/assign) copiază atât proprietățile string cât și symbol:
 
 ```js run
 let id = Symbol("id");
@@ -185,7 +186,7 @@ let clone = Object.assign({}, user);
 alert( clone[id] ); // 123
 ```
 
-Nu este niciun paradox aici. Așa este construit. Ideea este că, atunci când clonăm un obiect sau contopim obiecte, în mod normal vrem ca *toate* proprietățile să fie copiate (incluzând simboluri precum `id`).
+Nu este niciun paradox aici. Așa este construit. Ideea este că, atunci când clonăm un obiect sau contopim obiecte, de obicei vrem ca *toate* proprietățile să fie copiate (incluzând simboluri precum `id`).
 
 ## Simboluri globale
 
@@ -284,4 +285,4 @@ Simbolurile au două cazuri principale de folosire:
 
 2. Există multe simboluri sistem folosite de JavaScript care sunt accesibile prin `Symbol.*`. Le putem folosi pentru a altera câteva comportamente incluse în limbaj. De exemplu, mai târziu în tutorial vom folosi `Symbol.iterator` pentru [iterabile](info:iterable), `Symbol.toPrimitive` pentru a configura [conversia object-to-primitive](info:object-toprimitive) ș.a.m.d.
 
-Tehnic, simbolurile nu sunt 100% ascunse. Există metode ale limbajului JavaScript [Object.getOwnPropertySymbols(obj)](mdn:js/Object/getOwnPropertySymbols) care ne permit sa accesăm toate simbolurile. Mai există o metodă numită [Reflect.ownKeys(obj)](mdn:js/Reflect/ownKeys) care returnează  *toate* cheile unui obiect incluzându-le și pe cele simbolice. Dar cele mai multe librării, funcții built-in și construcții de sintaxă nu folosesc aceste metode.
+Tehnic, simbolurile nu sunt 100% ascunse. Există o metodă built-in [Object.getOwnPropertySymbols(obj)](mdn:js/Object/getOwnPropertySymbols) care ne permit sa accesăm toate simbolurile. Mai există o metodă numită [Reflect.ownKeys(obj)](mdn:js/Reflect/ownKeys) care returnează  *toate* cheile unui obiect incluzându-le și pe cele simbolice. Dar cele mai multe librării, funcții built-in și construcții de sintaxă nu folosesc aceste metode.

1-js/06-advanced-functions/03-closure/article.md

@@ -7,7 +7,7 @@ We already know that a function can access variables outside of it ("outer" vari
 
 But what happens if outer variables change since a function is created? Will the function get newer values or the old ones?
 
-And what if a function is passed along as a parameter and called from another place of code, will it get access to outer variables at the new place?
+And what if a function is passed along as an argument and called from another place of code, will it get access to outer variables at the new place?
 
 Let's expand our knowledge to understand these scenarios and more complex ones.
 
@@ -173,17 +173,7 @@ In this simple code without functions, there is only one Lexical Environment:
 
 ![lexical environment](lexical-environment-global.svg)
 
-<<<<<<< HEAD
-<<<<<<< HEAD
-5. When the `counter()` is called, an "empty" Lexical Environment is created for it. It has no local variables by itself. But the `[[Environment]]` of `counter` is used as the outer reference for it, so it has access to the variables of the former `makeCounter()` call where it was created:
-
-    ![](lexenv-nested-makecounter-5.svg)
-=======
-5. When `counter()` is called, a new Lexical Environment is created for the call. It's empty, as `counter` has no local variables by itself. But the `[[Environment]]` of `counter` is used as the `outer` reference for it, that provides access to the variables of the former `makeCounter()` call where it was created:
->>>>>>> 852ee189170d9022f67ab6d387aeae76810b5923
-=======
 This is the so-called *global* Lexical Environment, associated with the whole script.
->>>>>>> 29216730a877be28d0a75a459676db6e7f5c4834
 
 On the picture above, the rectangle means Environment Record (variable store) and the arrow means the outer reference. The global Lexical Environment has no outer reference, that's why the arrow points to `null`.
 
@@ -195,20 +185,11 @@ Here's a little bit longer code:
 
 Rectangles on the right-hand side demonstrate how the global Lexical Environment changes during the execution:
 
-<<<<<<< HEAD
-    ![](lexenv-nested-makecounter-6.svg)
-<<<<<<< HEAD
-
-    So we return to the previous step with the only change -- the new value of `count`. The following calls all do the same.
-=======
->>>>>>> 852ee189170d9022f67ab6d387aeae76810b5923
-=======
 1. When the script starts, the Lexical Environment is pre-populated with all declared variables.
     - Initially, they are in the "Uninitialized" state. That's a special internal state, it means that the engine knows about the variable, but it cannot be referenced until it has been declared with `let`. It's almost the same as if the variable didn't exist.
 2. Then `let phrase` definition appears. There's no assignment yet, so its value is `undefined`. We can use the variable from this point forward.
 3. `phrase` is assigned a value.
 4. `phrase` changes the value.
->>>>>>> 29216730a877be28d0a75a459676db6e7f5c4834
 
 Everything looks simple for now, right?
 

1-js/11-async/02-promise-basics/article.md

@@ -33,18 +33,10 @@ When the executor obtains the result, be it soon or late, doesn't matter, it sho
 
 So to summarize: the executor runs automatically and attempts to perform a job. When it is finished with the attempt, it calls `resolve` if it was successful or `reject` if there was an error.
 
-<<<<<<< HEAD
-<<<<<<< HEAD
-![](promise-resolve-reject.svg)
-=======
-The `promise` object returned by `new Promise` constructor has internal properties:
->>>>>>> 852ee189170d9022f67ab6d387aeae76810b5923
-=======
 The `promise` object returned by the `new Promise` constructor has these internal properties:
->>>>>>> 29216730a877be28d0a75a459676db6e7f5c4834
 
 - `state` — initially `"pending"`, then changes to either `"fulfilled"` when `resolve` is called or `"rejected"` when `reject` is called.
-- `result` — initially `undefined`, then changes to `value` when `resolve(value)` called or `error` when `reject(error)` is called.
+- `result` — initially `undefined`, then changes to `value` when `resolve(value)` is called or `error` when `reject(error)` is called.
 
 So the executor eventually moves `promise` to one of these states:
 
@@ -68,7 +60,7 @@ We can see two things by running the code above:
 1. The executor is called automatically and immediately (by `new Promise`).
 2. The executor receives two arguments: `resolve` and `reject`. These functions are pre-defined by the JavaScript engine, so we don't need to create them. We should only call one of them when ready.
 
-    After one second of "processing" the executor calls `resolve("done")` to produce the result. This changes the state of the `promise` object:
+    After one second of "processing", the executor calls `resolve("done")` to produce the result. This changes the state of the `promise` object:
 
     ![](promise-resolve-1.svg)
 
@@ -135,9 +127,9 @@ That's fine. We immediately have a resolved promise.
 The properties `state` and `result` of the Promise object are internal. We can't directly access them. We can use the methods `.then`/`.catch`/`.finally` for that. They are described below.
 ```
 
-## Consumers: then, catch, finally
+## Consumers: then, catch
 
-A Promise object serves as a link between the executor (the "producing code" or "singer") and the consuming functions (the "fans"), which will receive the result or error. Consuming functions can be registered (subscribed) using methods `.then`, `.catch` and `.finally`.
+A Promise object serves as a link between the executor (the "producing code" or "singer") and the consuming functions (the "fans"), which will receive the result or error. Consuming functions can be registered (subscribed) using the methods `.then` and `.catch`.
 
 ### then
 
@@ -152,9 +144,9 @@ promise.then(
 );
 ```
 
-The first argument of `.then` is a function that runs when the promise is resolved, and receives the result.
+The first argument of `.then` is a function that runs when the promise is resolved and receives the result.
 
-The second argument of `.then` is a function that runs when the promise is rejected, and receives the error.
+The second argument of `.then` is a function that runs when the promise is rejected and receives the error.
 
 For instance, here's a reaction to a successfully resolved promise:
 
@@ -220,59 +212,83 @@ promise.catch(alert); // shows "Error: Whoops!" after 1 second
 
 The call `.catch(f)` is a complete analog of `.then(null, f)`, it's just a shorthand.
 
-### finally
+## Cleanup: finally
 
 Just like there's a `finally` clause in a regular `try {...} catch {...}`, there's `finally` in promises.
 
-The call `.finally(f)` is similar to `.then(f, f)` in the sense that `f` always runs when the promise is settled: be it resolve or reject.
+The call `.finally(f)` is similar to `.then(f, f)` in the sense that `f` runs always, when the promise is settled: be it resolve or reject.
+
+The idea of `finally` is to set up a handler for performing cleanup/finalizing after the previous operations are complete.
 
-`finally` is a good handler for performing cleanup, e.g. stopping our loading indicators, as they are not needed anymore, no matter what the outcome is.
+E.g. stopping loading indicators, closing no longer needed connections, etc.
 
-Like this:
+Think of it as a party finisher. No matter was a party good or bad, how many friends were in it, we still need (or at least should) do a cleanup after it.
+
+The code may look like this:
 
 ```js
 new Promise((resolve, reject) => {
-  /* do something that takes time, and then call resolve/reject */
+  /* do something that takes time, and then call resolve or maybe reject */
 })
 *!*
   // runs when the promise is settled, doesn't matter successfully or not
   .finally(() => stop loading indicator)
-  // so the loading indicator is always stopped before we process the result/error
+  // so the loading indicator is always stopped before we go on
 */!*
   .then(result => show result, err => show error)
 ```
 
-That said, `finally(f)` isn't exactly an alias of `then(f,f)` though. There are few subtle differences:
+Please note that `finally(f)` isn't exactly an alias of `then(f,f)` though.
+
+There are important differences:
 
 1. A `finally` handler has no arguments. In `finally` we don't know whether the promise is successful or not. That's all right, as our task is usually to perform "general" finalizing procedures.
-2. A `finally` handler passes through results and errors to the next handler.
+
+    Please take a look at the example above: as you can see, the `finally` handler has no arguments, and the promise outcome is handled by the next handler.
+2. A `finally` handler "passes through" the result or error to the next suitable handler.
 
     For instance, here the result is passed through `finally` to `then`:
+
     ```js run
     new Promise((resolve, reject) => {
-      setTimeout(() => resolve("result"), 2000)
+      setTimeout(() => resolve("value"), 2000);
     })
-      .finally(() => alert("Promise ready"))
-      .then(result => alert(result)); // <-- .then handles the result
+      .finally(() => alert("Promise ready")) // triggers first
+      .then(result => alert(result)); // <-- .then shows "value"
     ```
 
-    And here there's an error in the promise, passed through `finally` to `catch`:
+    As you can see, the `value` returned by the first promise is passed through `finally` to the next `then`.
+
+    That's very convenient, because `finally` is not meant to process a promise result. As said, it's a place to do generic cleanup, no matter what the outcome was.
+
+    And here's an example of an error, for us to see how it's passed through `finally` to `catch`:
 
     ```js run
     new Promise((resolve, reject) => {
       throw new Error("error");
     })
-      .finally(() => alert("Promise ready"))
-      .catch(err => alert(err));  // <-- .catch handles the error object
+      .finally(() => alert("Promise ready")) // triggers first
+      .catch(err => alert(err));  // <-- .catch shows the error
     ```
 
-That's very convenient, because `finally` is not meant to process a promise result. So it passes it through.
+3. A `finally` handler also shouldn't return anything. If it does, the returned value is silently ignored.
 
-We'll talk more about promise chaining and result-passing between handlers in the next chapter.
+    The only exception to this rule is when a `finally` handler throws an error. Then this error goes to the next handler, instead of any previous outcome.
 
+To summarize:
+
+- A `finally` handler doesn't get the outcome of the previous handler (it has no arguments). This outcome is passed through instead, to the next suitable handler.
+- If a `finally` handler returns something, it's ignored.
+- When `finally` throws an error, then the execution goes to the nearest error handler.
+
+These features are helpful and make things work just the right way if we use `finally` how it's supposed to be used: for generic cleanup procedures.
 
 ````smart header="We can attach handlers to settled promises"
-If a promise is pending, `.then/catch/finally` handlers wait for it. Otherwise, if a promise has already settled, they just run:
+If a promise is pending, `.then/catch/finally` handlers wait for its outcome.
+
+Sometimes, it might be that a promise is already settled when we add a handler to it.
+
+In such case, these handlers just run immediately:
 
 ```js run
 // the promise becomes resolved immediately upon creation
@@ -286,10 +302,10 @@ Note that this makes promises more powerful than the real life "subscription lis
 Promises are more flexible. We can add handlers any time: if the result is already there, they just execute.
 ````
 
-Next, let's see more practical examples of how promises can help us write asynchronous code.
-
 ## Example: loadScript [#loadscript]
 
+Next, let's see more practical examples of how promises can help us write asynchronous code.
+
 We've got the `loadScript` function for loading a script from the previous chapter.
 
 Here's the callback-based variant, just to remind us of it:

1-js/99-js-misc/01-proxy/article.md

@@ -730,11 +730,7 @@ The problem is actually in the proxy, in the line `(*)`.
 2. The prototype is `userProxy`.
 3. When reading `name` property from the proxy, its `get` trap triggers and returns it from the original object as `target[prop]` in the line `(*)`.
 
-<<<<<<< HEAD
-![](proxy-inherit.svg)
-=======
     A call to `target[prop]`, when `prop` is a getter, runs its code in the context `this=target`. So the result is `this._name` from the original object `target`, that is: from `user`.
->>>>>>> 852ee189170d9022f67ab6d387aeae76810b5923
 
 To fix such situations, we need `receiver`, the third argument of `get` trap. It keeps the correct `this` to be passed to a getter. In our case that's `admin`.
 

1-js/99-js-misc/04-reference-type/2-check-syntax/solution.md

@@ -11,11 +11,7 @@ let user = {
 (user.go)() // eroare!
 ```
 
-<<<<<<< HEAD:1-js/04-object-basics/04-object-methods/2-check-syntax/solution.md
-Din mesajul de eroare furnizat de majoritatea browserelor nu reiese ce a mers prost.
-=======
-The error message in most browsers does not give us much of a clue about what went wrong.
->>>>>>> 29216730a877be28d0a75a459676db6e7f5c4834:1-js/99-js-misc/04-reference-type/2-check-syntax/solution.md
+Mesajul de eroare din majoritatea browserelor nu ne oferă prea multe indicii despre ce a mers greșit.
 
 **Eroarea apare deoarece simbolul ";" lipsește după `user = {...}`.**
 
@@ -38,8 +34,5 @@ let user = {
 (user.go)() // John
 ```
 
-<<<<<<< HEAD:1-js/04-object-basics/04-object-methods/2-check-syntax/solution.md
-Rețineți că parantezele din jurul `(user.go)` nu fac nimic aici. De obicei setează ordinea operațiilor, dar aici punctul `.` are oricum precedență, deci nu are niciun efect. Singurul lucru care contează este simbolul ";".
-=======
-Please note that parentheses around `(user.go)` do nothing here. Usually they setup the order of operations, but here the dot `.` works first anyway, so there's no effect. Only the semicolon thing matters.
->>>>>>> 29216730a877be28d0a75a459676db6e7f5c4834:1-js/99-js-misc/04-reference-type/2-check-syntax/solution.md
+Vă rugăm să rețineți că parantezele din jurul `(user.go)` nu fac nimic aici. De obicei ele stabilesc ordinea operațiilor, dar aici punctul `.` funcționează primul oricum, deci nu au niciun efect. Doar chestia cu punctul și virgula contează.
+

1-js/99-js-misc/04-reference-type/2-check-syntax/task.md

@@ -4,7 +4,7 @@ importance: 2
 
 # Verificare de sintaxă
 
-Care este rezultatul următorului cod?
+Care este rezultatul acestui cod?
 
 
 ```js no-beautify