Merge pull request #357 from javascript-tutorial/sync-3c934b5a

Sync with upstream @ 3c934b5

Author: longo-andrea

1-js/02-first-steps/16-function-expressions/article.md

@@ -43,8 +43,12 @@ In more advanced situations, that we'll come across later, a function may be cre
 
 ## Function is a value
 
+<<<<<<< HEAD
 Let's reiterate: no matter how the function is created, a function is a value. Both examples above store a function is `sayHi` variable.
 >>>>>>> 8d04d0d2db97276dbb2b451c30a7bd3e05d65831
+=======
+Let's reiterate: no matter how the function is created, a function is a value. Both examples above store a function in the `sayHi` variable.
+>>>>>>> 3c934b5a46a76861255e3a4f29da6fd54ab05c8c
 
 Possiamo anche mostrarne il valore usando `alert`:
 

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

@@ -159,11 +159,15 @@ for (let key in user) alert(key); // name, age (nessun symbol)
 alert( "Direct: " + user[id] );
 ```
 
+<<<<<<< HEAD
 <<<<<<< HEAD
 Anche `Object.keys(user)` li ignora. Questo fa parte del principio generale di occultazione delle proprietà symbol. Se uno script esterno o una libreria eseguisse un ciclo sul nostro oggetto, non avrebbe inaspettatamente accesso a una proprietà di tipo symbol.
 =======
 [Object.keys(user)](mdn:js/Object/keys) also ignores them. That's a part of the general "hiding symbolic properties" principle. If another script or a library loops over our object, it won't unexpectedly access a symbolic property.
 >>>>>>> 8d04d0d2db97276dbb2b451c30a7bd3e05d65831
+=======
+[Object.keys(user)](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/keys) also ignores them. That's a part of the general "hiding symbolic properties" principle. If another script or a library loops over our object, it won't unexpectedly access a symbolic property.
+>>>>>>> 3c934b5a46a76861255e3a4f29da6fd54ab05c8c
 
 Invece [Object.assign](mdn:js/Object/assign) esegue la copia sia delle proprietà di tipo stringa sia di quelle symbol:
 

1-js/05-data-types/12-json/article.md

@@ -27,7 +27,11 @@ Fortunatamente, non c'è bisogno di scrivere del codice per gestire questa situa
 
 ## JSON.stringify
 
+<<<<<<< HEAD
 [JSON](http://en.wikipedia.org/wiki/JSON) (JavaScript Object Notation) è un formato per rappresentare valori e oggetti. Viene descritto nello standard [RFC 4627](http://tools.ietf.org/html/rfc4627). Inizialmente fu creato per lavorare con JavaScript, ma molti altri linguaggi possiedono delle librerie per la sua gestione. Quindi JSON risulta semplice da usare per lo scambio di dati quando il client utilizza JavaScript e il server codifica in Ruby/PHP/Java/Altro.
+=======
+The [JSON](http://en.wikipedia.org/wiki/JSON) (JavaScript Object Notation) is a general format to represent values and objects. It is described as in [RFC 4627](https://tools.ietf.org/html/rfc4627) standard. Initially it was made for JavaScript, but many other languages have libraries to handle it as well.  So it's easy to use JSON for data exchange when the client uses JavaScript and the server is written on Ruby/PHP/Java/Whatever.
+>>>>>>> 3c934b5a46a76861255e3a4f29da6fd54ab05c8c
 
 JavaScript fornisce i metodi:
 

1-js/08-prototypes/01-prototype-inheritance/article.md

@@ -54,7 +54,11 @@ alert( rabbit.eats ); // true (**)
 alert( rabbit.jumps ); // true
 ```
 
+<<<<<<< HEAD
 Nell'esempio la linea `(*)` imposta `animal` come prototype di `rabbit`.
+=======
+Here the line `(*)` sets `animal` to be the prototype of `rabbit`.
+>>>>>>> 3c934b5a46a76861255e3a4f29da6fd54ab05c8c
 
 Successivamente, quando `alert` proverà a leggere la proprietà `rabbit.eats` `(**)`, non la troverà in rabbit, quindi JavaScript seguirà il riferimento in `[[Prototype]]` e la troverà in  `animal` (ricerca dal basso verso l'alto):
 
@@ -287,7 +291,11 @@ for(let prop in rabbit) alert(prop); // jumps, then eats
 */!*
 ```
 
+<<<<<<< HEAD
 Se questo non è ciò che ci aspettiamo, e vogliamo escludere le proprietà ereditate, esiste un metodo integrato [obj.hasOwnProperty(key)](mdn:js/Object/hasOwnProperty): ritorna `true` se `obj` possiede la propria proprietà `key` (non ereditata).
+=======
+If that's not what we want, and we'd like to exclude inherited properties, there's a built-in method [obj.hasOwnProperty(key)](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/hasOwnProperty): it returns `true` if `obj` has its own (not inherited) property named `key`.
+>>>>>>> 3c934b5a46a76861255e3a4f29da6fd54ab05c8c
 
 Quindi possiamo filtrare le proprietà ereditate (o farci qualcos'altro):
 

1-js/09-classes/01-class/article.md

@@ -118,7 +118,11 @@ alert(Object.getOwnPropertyNames(User.prototype)); // constructor, sayHi
 
 ## Non solo una semplificazione (syntax sugar)
 
+<<<<<<< HEAD
 Talvolta si pensa che `class` in JavaScript sia solo "syntax sugar" (una sintassi creata per semplificare la lettura, ma che non apporta nulla di nuovo), dato che potremmo potremmo dichiarare la stessa cosa senza utilizzare la parola chiave `class`:
+=======
+Sometimes people say that `class` is a "syntactic sugar" (syntax that is designed to make things easier to read, but doesn't introduce anything new), because we could actually declare the same thing without using the `class` keyword at all:
+>>>>>>> 3c934b5a46a76861255e3a4f29da6fd54ab05c8c
 
 ```js run
 // la classe User usando solo funzioni

5-network/05-fetch-crossorigin/article.md

@@ -207,10 +207,18 @@ Fino a qualche tempo fa nessuno avrebbe potuto supporre che una pagina web fosse
 
 Così, per evitare fraintendimenti, per ogni "unsafe" request -- che tempo fa non sarebbero stata possibile, il browser non esegue direttamente queste request. Prima invia una richiesta, chiamata "preflight", per richiedere il permesso.
 
+<<<<<<< HEAD
 Una preflight request usa il method `OPTIONS`, nessun body e due headers:
 
 - `Access-Control-Request-Method` che indica il method della unsafe request.
 - `Access-Control-Request-Headers` che contiene una lista, separata da virgole, degli unsafe HTTP-headers della request.
+=======
+A preflight request uses the method `OPTIONS`, no body and three headers:
+
+- `Access-Control-Request-Method` header has the method of the unsafe request.
+- `Access-Control-Request-Headers` header provides a comma-separated list of its unsafe HTTP-headers.
+- `Origin` header tells from where the request came. (such as `https://javascript.info`)
+>>>>>>> 3c934b5a46a76861255e3a4f29da6fd54ab05c8c
 
 Se il server accetta di servire la request, invia una risposta con un body vuoto, uno status 200 e le headers:
 

6-data-storage/01-cookie/article.md

@@ -105,6 +105,7 @@ Solitamente, dovremmo impostare `path` nella cartella principale: `path=/` affin
 
 Un dominio definisce dove il cookie è accessibile. In realtà, ci sono delle limitazioni. Non possiamo impostare nessun dominio.
 
+<<<<<<< HEAD
 Di default, un cookie è accessibile solo nel dominio in cui è stato impostato. Cosi se il cookie è stato impostato da `site.com`, non lo otterremo su `other.com`
 
 ...Inoltre, non otterremo il cookie nel sotto dominio `forum.site.com`!
@@ -127,17 +128,51 @@ Questa è una restrizione per motivi di sicurezza, per consentirci di immagazzin
 // su site.com
 // rende il cookie accessibile su ogni sotto dominio *.site.com:
 document.cookie = "user=John; domain=site.com"
+=======
+**There's no way to let a cookie be accessible from another 2nd-level domain, so `other.com` will never receive a cookie set at `site.com`.**
+
+It's a safety restriction, to allow us to store sensitive data in cookies that should be available only on one site.
+
+By default, a cookie is accessible only at the domain that set it.
+
+Please note, by default a cookie is also not shared to a subdomain as well, such as `forum.site.com`.
+
+```js
+// if we set a cookie at site.com website...
+document.cookie = "user=John"
+
+// ...we won't see it at forum.site.com
+alert(document.cookie); // no user
+```
+
+...But this can be changed. If we'd like to allow subdomains like `forum.site.com` to get a cookie set at `site.com`, that's possible.
+
+For that to happen, when setting a cookie at `site.com`, we should explicitly set the `domain` option to the root domain: `domain=site.com`. Then all subdomains will see such cookie.
+
+For example:
+
+```js
+// at site.com
+// make the cookie accessible on any subdomain *.site.com:
+document.cookie = "user=John; *!*domain=site.com*/!*"
+>>>>>>> 3c934b5a46a76861255e3a4f29da6fd54ab05c8c
 
 // dopo
 
 // su forum.site.com
 alert(document.cookie); // possiede un cookie user=John
 ```
 
+<<<<<<< HEAD
 Per ragioni storiche, `domain=.site.com` (un punto prima di `site.com`) funziona nello stesso modo, garantendo accesso al cookie dal sotto dominio. Questa è una vecchia notazione, dovrebbe essere utilizzata se dobbiamo supportare vecchi browsers.
 
 
 Ricapitolando, l'opzione `domain` ci consente di rendere un cookie accessibile ai sotto domini.
+=======
+For historical reasons, `domain=.site.com` (with a dot before `site.com`) also works the same way, allowing access to the cookie from subdomains. That's an old notation and should be used if we need to support very old browsers.
+
+To summarize, the `domain` option allows to make a cookie accessible at subdomains.
+>>>>>>> 3c934b5a46a76861255e3a4f29da6fd54ab05c8c
 
 ## expires, max-age
 
@@ -190,7 +225,7 @@ Con questa opzione, se un cookie è impostato su `https://site.com`, non apparir
 //assumendo sia on https:// now
 // imposta il cookie sicuro (Solo accessibile se si utilizza HTTPS)
 document.cookie = "user=John; secure";
-```  
+```
 
 ## samesite
 
@@ -257,7 +292,11 @@ Quindi, ciò che `samesite=lax` fa è semplicemente garantire alla più comune o
 
 Se questo ti è sufficiente, aggiungere `samesite=lax` probabilmente non intaccherà l'esperienza utente e, allo stesso tempo, aggiungerà protezione.
 
+<<<<<<< HEAD
 Generalmente, `samesite` è un'ottima scelta.
+=======
+Overall, `samesite` is a great option.
+>>>>>>> 3c934b5a46a76861255e3a4f29da6fd54ab05c8c
 
 Ma c'è uno svantaggio: