merging all conflicts

Author: iliakan

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

@@ -34,7 +34,11 @@ let sayHi = function() {
 
 ## تابع یک مقدار است
 
+<<<<<<< HEAD
 بیایید تکرار کنیم: مهم نیست که تابع چگونه ساخته شده است، یک تابع همیشه یک مقدار است. هر دو مثال بالا تابعی را درون متغیر `sayHi` ذخیره می‌کنند.
+=======
+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
 
 ما حتی می‌توانیم آن مقدار را با استفاده از `alert` چاپ کنیم:
 

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

@@ -161,7 +161,11 @@ for (let key in user) alert(key); // name, age (بدون سمبل)
 alert( "به طور مستقیم: " + user[id] );
 ```
 
+<<<<<<< HEAD
 همچنین `Object.keys(user)` هم آنها را نادیده می‌گیرد. این بخشی از اصل کلی «مخفی‌سازی ویژگی‌های سمبلی» است. اگر یک اسکریپت یا کتابخانه دیگر در شیء ما حلقه بزند، به تصادفی به ویژگی سمبلی ما دسترسی نخواهد داشت.
+=======
+[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
 
 در مقابل، [Object.assign](mdn:js/Object/assign) هم ویژگی‌های رشته و هم سمبل را کپی می‌کند:
 

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

@@ -27,7 +27,11 @@ alert(user); // {name: "John", age: 30}
 
 ## متد JSON.stringify
 
+<<<<<<< HEAD
 [JSON](http://fa.wikipedia.org/wiki/جی%E2%80%8Cسان) (نشانه‌گذاری شیء جاوااسکریپت، جِی‌سان) یک فرمت کلی برای نمایش مقدارها و شیءها است. جِی‌سان در استاندارد [RFC 4627](http://tools.ietf.org/html/rfc4627) شرح داده شده است. در ابتدا برای جاوااسکریپت ساخته شد اما بسیاری از زبان‌های دیگر هم کتابخانه‌هایی برای بکاربردن آن دارند. پس هنگامی که سمت کاربر سایت از جاوااسکریپت و سمت سرور با زبان‌های Ruby/PHP/Java/یا هر چیز دیگر نوشته شده باشد، استفاده از جی‌سان برای رد و بدل کردن داده آسان است.
+=======
+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
 
 جاوااسکریپت متدهای زیر را دارد:
 

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

@@ -54,7 +54,11 @@ alert( rabbit.eats ); // true (**)
 alert( rabbit.jumps ); // true
 ```
 
+<<<<<<< HEAD
 اینجا خط `(*)` شیء `animal` را به عنوان پروتوتایپ `rabbit` تنظیم می‌کند.
+=======
+Here the line `(*)` sets `animal` to be the prototype of `rabbit`.
+>>>>>>> 3c934b5a46a76861255e3a4f29da6fd54ab05c8c
 
 سپس زمانی که `alert` سعی می‌کند تا ویژگی `rabbit.eats` `(**)` را بخواند، درون `rabbit` نیست پس جاوااسکریپت مرجع `[[Prototype]]` را دنبال می‌کند و ویژگی را درون `animal` پیدا می‌کند (از پایین به بالا نگاه کنید):
 
@@ -287,7 +291,11 @@ for(let prop in rabbit) alert(prop); // eats سپس ،jumps
 */!*
 ```
 
+<<<<<<< HEAD
 اگر این چیزی نیست که ما می‌خواهیم و دوست داریم که شامل ویژگی‌های به ارث‌برده‌شده نشود، یک متد درون‌ساخت [obj.hasOwnProperty(key)](mdn:js/Object/hasOwnProperty) وجود دارد: این متد اگر `obj` ویژگی خودش (نه به ارث‌برده‌شده) به نام `key` را داشته باشد `true` برمی‌گرداند.
+=======
+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
 
 پس می‌تواند ویژگی‌های به ارث‌برده‌شده را جداسازی کنیم (یا کاری دیگر با آن‌ها کنیم):
 

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

@@ -118,7 +118,11 @@ alert(Object.getOwnPropertyNames(User.prototype)); // sayHi ،سازنده
 
 ## فقط یک سینتکس برای زیباکردن(syntactic sugar) نیست
 
+<<<<<<< HEAD
 گاهی اوقات مردم می‌گویند که `class` یک «سینتکس برای زیباکردن(syntactic sugar)» است (سینتکسی که برای خواندن ساده‌تر طراحی شده است، اما چیز جدیدی معرفی نمی‌کند)، زیرا در واقع می‌توانیم همان را بدون کلمه کلیدی `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
 // بازنویسی کلاس کاربر در توابع خالص

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

@@ -207,10 +207,11 @@ Some time ago no one could even imagine that a webpage could make such requests.
 
 So, to avoid misunderstandings, any "unsafe" request -- that couldn't be done in the old times, the browser does not make such requests right away. First, it sends a preliminary, so-called "preflight" request, to ask for permission.
 
-A preflight request uses the method `OPTIONS`, no body and two headers:
+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`)
 
 If the server agrees to serve the requests, then it should respond with empty body, status 200 and headers:
 

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

@@ -96,38 +96,42 @@ Usually, we should set `path` to the root: `path=/` to make the cookie accessibl
 
 A domain defines where the cookie is accessible. In practice though, there are limitations. We can't set any domain.
 
-By default, a cookie is accessible only at the domain that set it. So, if the cookie was set by `site.com`, we won't get it at `other.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.
 
-...But what's more tricky, we also won't get the cookie at a subdomain `forum.site.com`!
+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
-// at site.com
+// if we set a cookie at site.com website...
 document.cookie = "user=John"
 
-// at forum.site.com
+// ...we won't see it at forum.site.com
 alert(document.cookie); // no user
 ```
 
-**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`.**
+...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.
 
-It's a safety restriction, to allow us to store sensitive data in cookies, that should be available only on one site.
+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.
 
-...But if we'd like to allow subdomains like `forum.site.com` to get a cookie, that's possible. When setting a cookie at `site.com`, we should explicitly set the `domain` option to the root domain: `domain=site.com`:
+For example:
 
 ```js
 // at site.com
 // make the cookie accessible on any subdomain *.site.com:
-document.cookie = "user=John; domain=site.com"
+document.cookie = "user=John; *!*domain=site.com*/!*"
 
 // later
 
 // at forum.site.com
 alert(document.cookie); // has cookie user=John
 ```
 
-For historical reasons, `domain=.site.com` (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.
+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.
 
-So, the `domain` option allows to make a cookie accessible at subdomains.
+To summarize, the `domain` option allows to make a cookie accessible at subdomains.
 
 ## expires, max-age
 
@@ -180,7 +184,7 @@ With this option, if a cookie is set by `https://site.com`, then it doesn't appe
 // assuming we're on https:// now
 // set the cookie to be secure (only accessible over HTTPS)
 document.cookie = "user=John; secure";
-```  
+```
 
 ## samesite
 
@@ -247,7 +251,7 @@ But anything more complicated, like a network request from another site or a for
 
 If that's fine for you, then adding `samesite=lax` will probably not break the user experience and add protection.
 
-Overall, `samesite` is a great option. 
+Overall, `samesite` is a great option.
 
 There's a drawback: