javascript-tutorial · javascript-translate-bot · May 31, 2019 · May 31, 2019 · Jun 21, 2019 · Jun 22, 2019
diff --git a/1-js/01-getting-started/1-intro/article.md b/1-js/01-getting-started/1-intro/article.md
@@ -106,7 +106,11 @@ Bundan dolayı yakın zamanda bir sürü yeni *transpiled* yani çevirilmiş dil
 
 Bu dillere örnek vermek gerekirse:
 
+<<<<<<< HEAD
 - [CofeeScript](http://coffeescript.org) JavaScript için "şeker yazım" denebilecek bir dildir. Yazılımı daha kısadır ve daha temiz kod yazmaya yardımcı olur. Genellikle [Ruby](https://www.ruby-lang.org/tr/) geliştiriciler bunu sever.
+=======
+Examples of such languages:
+>>>>>>> 6bbe0b4313a7845303be835d632ef8e5bc7715cd
 
 - [Typescript](http://www.typescriptlang.org/) durağan veri yapıları ile JavaScript yazılmasını sağlar. Karmaşık programlar geliştirmeyi kolaylaştırır. Microsoft tarafından geliştirilmiştir.
 

diff --git a/1-js/02-first-steps/01-hello-world/hello-world-render.png b/1-js/02-first-steps/01-hello-world/hello-world-render.png
diff --git a/1-js/02-first-steps/01-hello-world/hello-world-render@2x.png b/1-js/02-first-steps/01-hello-world/hello-world-render@2x.png
diff --git a/1-js/02-first-steps/05-types/article.md b/1-js/02-first-steps/05-types/article.md
@@ -213,9 +213,15 @@ typeof alert // "function"  (3)
 
 Son üç satır diğerlerinden farklıdır. Şu şekilde;
 
+<<<<<<< HEAD
 1. `Math` matematiksal operasyonlar için kullanılacak JavaScript dilinde var olan bir objedir. <info:number> konusunda buna değinilecektir.  Burada sadece objenin örneklenmesi için kullanılmıştır.
 2. `typeof null` sonucu `"object"` dir. Aslında yanlış. Bu `typeof` fonksiyonunun bilinen bir hatasıdır. Eski versiyonlara uygunluk açısından bu şekliyle bırakılmıştır. Yoksa `null` bir obje değildir. Kendine has bir tiptir. Tekrar söylemek gerekirse bu JavaScript dilinin bir hatasıdır.
 3. `typeof alert` fonksiyondur. Çünkü `alert` dilde doğrudan var olan bir fonksiyondur. `Math` ile farklı gördüğünüz gibi. Bir sonraki bölümde fonksiyonlar anlatılacaktır. Fonksiyonlar obje tipine dahildir. Fakat `typeof` bunları farklı yorumlar. Resmi olarak yanlış olsa da pratikte çokça kullanılan bir özelliktir.
+=======
+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
 
 
 ## Özet

diff --git a/1-js/02-first-steps/07-operators/article.md b/1-js/02-first-steps/07-operators/article.md
@@ -124,11 +124,19 @@ Neden önce "unary" işlemi gerçekleşiyor da "binary" işlemi gerçekleşmiyor
 
 Eğer bir ifade birden fazla operatör içeriyorsa. Bu ifade çalıştırılırken tanımlı *önceliklere* göre çalıştırılır, bir başka ifade ile öncelik sırasına göre çalıştırılır.
 
+<<<<<<< HEAD
 Okuldan hepinizin hatırlayacağı gibi çarpma işlemi toplamadan önce yapılır `1 + 2 * 2`. Aslında *öncelik* tam olarakta budur. Çarpma işlemi toplama işleminden daha *yüksek önceliğe* sahiptir.
+=======
+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
 
 Parantez, bu öncelikleri çiğner ve eğer bu *önceliklerden* memnun değilseniz bunları tekrar tanımlamanıza olanak verir. Örneğin `(1 + 2 ) * 2`
 
+<<<<<<< HEAD
 JavaScript' dilinde birçok operatör vardır. Her operatörün de bir önceliği. Yüksek öncelik sayısına sahip operatör mnce çalışır. Eğer öncelik değerleri eşit ise soldan sağa doğru çalışır.
+=======
+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
 
 [öncelik tablosu](https://developer.mozilla.org/en/JavaScript/Reference/operators/operator_precedence) ( Ezberlemenize gerek yok sadece unary operatörlerin binary olanlara göre daha üstün olduğunu hatırlayın yeter). Yani `+elma + +portakal` işleminde önce unary ile `elma`'nın değerini sayı yapar sonra `portakal`'ın değerini sayı yapar ve en sonunda toplar.
 
@@ -193,9 +201,16 @@ alert( a ); // 3
 alert( c ); // 0
 ```
 
+<<<<<<< HEAD
 Yukarıdaki örnekte, `(a = b+1)` in sonucu `a` ya atandıktan sonra(3) 3'den çıkarmak için kullanılıyor.
 
 Komik bi kod değil mi? Nasıl çalıştığını anlamanız lazım, bazen başka kütüphaneler kullandığınızda böyle şeyleri sizin yazmanız beklenmez. Böyle olaylar aslında kodun okunaklılığını azaltır.
+=======
+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
 
 ````
 
@@ -419,10 +434,10 @@ Here, the first expression `1 + 2` is evaluated and its result is thrown away. T
 ```smart header="Comma has a very low precedence"
 Please note that the comma operator has very low precedence, lower than `=`, so parentheses are important in the example above.
 
-Without them: `a = 1 + 2, 3 + 4` evaluates `+` first, summing the numbers into `a = 3, 7`, then the assignment operator `=` assigns    `a = 3`, and finally the number after the comma, `7`, is not processed so it's ignored.
+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 part?
+Why do we need an operator that throws away everything except the last expression?
 
 Sometimes, people use it in more complex constructs to put several actions in one line.
 
@@ -435,4 +450,4 @@ for (*!*a = 1, b = 3, c = a * b*/!*; a < 10; 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.
+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.
diff --git a/1-js/03-code-quality/01-debugging-chrome/chrome-open-sources.png b/1-js/03-code-quality/01-debugging-chrome/chrome-open-sources.png
diff --git a/1-js/03-code-quality/01-debugging-chrome/chrome-open-sources@2x.png b/1-js/03-code-quality/01-debugging-chrome/chrome-open-sources@2x.png
diff --git a/1-js/03-code-quality/01-debugging-chrome/chrome-sources-breakpoint.png b/1-js/03-code-quality/01-debugging-chrome/chrome-sources-breakpoint.png
diff --git a/1-js/03-code-quality/01-debugging-chrome/chrome-sources-breakpoint@2x.png b/1-js/03-code-quality/01-debugging-chrome/chrome-sources-breakpoint@2x.png
diff --git a/1-js/03-code-quality/01-debugging-chrome/chrome-sources-debugger-trace-1.png b/1-js/03-code-quality/01-debugging-chrome/chrome-sources-debugger-trace-1.png
diff --git a/1-js/03-code-quality/01-debugging-chrome/chrome-sources-debugger-trace-1@2x.png b/1-js/03-code-quality/01-debugging-chrome/chrome-sources-debugger-trace-1@2x.png
diff --git a/1-js/03-code-quality/02-coding-style/article.md b/1-js/03-code-quality/02-coding-style/article.md
@@ -2,14 +2,22 @@
 
 Kodunuz olabildiğince okunaklı ve temiz olmalıdır.
 
+<<<<<<< HEAD
 Aslında bu programlama sanatıdır -- karmaşık bir görevi alın ve bunu olabildiğince doğru ve okunaklı bir şekile getirin.
+=======
+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
 
 Buna yardımcı olan bir şey de iyi kodlama stilidir.
 
+<<<<<<< HEAD
 
 ## Yazım
 
 Kodlar için yazımış bir kopya kağıdı(detayları aşağıda):
+=======
+Here is a cheat sheet with some suggested rules (see below for more details):
+>>>>>>> 6bbe0b4313a7845303be835d632ef8e5bc7715cd
 
 ![](code-style.png)
 <!--
@@ -40,7 +48,13 @@ if (n < 0) {
 
 Buradaki hiç bir şey kanun değildir. Hepsi sizin zevgine kalmıştır ve değişebilir. Buradaki kodlama kuralları dogmalara dayanmaz.
 
+<<<<<<< HEAD
 ### Süslü Parantez
+=======
+```warn header="There are no \"you must\" rules"
+Nothing is set in stone here. These are style preferences, not religious dogmas.
+```
+>>>>>>> 6bbe0b4313a7845303be835d632ef8e5bc7715cd
 
 Çoğu JavaScript projesinde süslü parantezler yeni satırda değil de kod ile aynı satırda yazılırlar. Buna "mısırlı" stili denir. Ayrıca süslü parantezin başında aşağıdaki gibi boşluk bırakılır.
 
@@ -54,7 +68,13 @@ if (kosul) {
 ```
 Tek satırlı `if` cümlelerinde süslü parantez kullanmalı mı ? Kullanılacaksa nasıl yazılmalı?
 
+<<<<<<< HEAD
 Burada not düşülerek `if` örnekleri verilmiş. Siz de bu kodların okunabilirliğini yargılayabilirsiniz.
+=======
+A single-line construct, such as `if (condition) doSomething()`, is an important edge case. Should we use braces at all?
+
+Here are the annotated variants so you can judge their readability for yourself:
+>>>>>>> 6bbe0b4313a7845303be835d632ef8e5bc7715cd
 
 <!--
 ```js no-beautify
@@ -76,11 +96,39 @@ if (n < 0) {
 3. Süslü parantez olmadan tek satırda işi bitirebilirseniz kabul edilebilir. Ama kısa olması şartıyla.
 4. Bunların içerisindeki en iyisi.
 
+<<<<<<< HEAD
 Özetle:
 - Çok kısa kodlar için, şu şekilde kullanım kabul edilebilir: `if(koşul) return null`.
 - Eğer ayrı satırlara yazmanız gerekiyorsa kesin süslü parantez kullanın.
 
 ### Satır uzunluğu
+=======
+### 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
 
 En uzun satır boyunun bir sınırı olmalı. Kimse yatayda kodu takip etmek istemez. Eğer o kadar uzun ise yeni bir satıra geçmeniz önerilir.
 
@@ -131,15 +179,25 @@ Satır uzunluğu limitine takım seviyesinde karar verilir. Genelde 80-120 karak
 
 Her cümlenin sonuna noktalı virgül konulmalıdır. Tercihli olsa bile tercih her zaman noktalı virgül tarafında olmalıdır.
 
+<<<<<<< HEAD
 Bazı dillerde noktalı virgül tamamen tercihe bağlıdır. O dilde nadiren kullanılır. Fakat JavaScript için bazı durumlarda yeni satır noktalı virgül olarak algılanmayabilir. Bu da programlama hatasına neden olur.
 
 Eğer sonuçlarını ve nasıl kullanılacağına inancınız tamsa bu durumda noktalı virgül kullanmayabilirsiniz. Fakat başlangıçta kesinlikle kullanmalısınız.
+=======
+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
 
 ### İç içelik seviyesi
 
 Çok fazla iç içe kod yazmamalısınız.
 
+<<<<<<< HEAD
 Bazı durumlarda döngü içinde ["continue"](info:while-for#continue) kullanmak iyi bir fikir olabilir.
+=======
+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
 
 Aşağıdaki kullanım yerine:
 
@@ -202,13 +260,21 @@ function ust(x, n) {
 }
 ```
 
+<<<<<<< HEAD
 ... fakat ikincisi daha okunaklıdır, çünkü `n<0` koşulu ilk önce kontrol edildi ve buna göre aksiyon alındı sonrsında ana kod akışına devam edildi, ayrıca bir `else` yazmaya gerek kalmadı.
+=======
+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
 
 ## Kodun altında fonksiyonlar
 
 Eğer bir kaç tane "helper"(yardımcı) fonksiyon yazıyorsanız bunları yerleştirmenin üç farklı yolu var.
 
+<<<<<<< HEAD
 1. Kullanan kodun üstünde fonksiyonları tanımlamak:
+=======
+1. Declare the functions *above* the code that uses them:
+>>>>>>> 6bbe0b4313a7845303be835d632ef8e5bc7715cd
 
     ```js
     // *!*function declarations*/!*
@@ -254,15 +320,23 @@ Eğer bir kaç tane "helper"(yardımcı) fonksiyon yazıyorsanız bunları yerle
 
 3. Karışık: Fonksiyonu kullanıldığı yerde tanımlama.
 
+<<<<<<< HEAD
 Çoğu zaman ikinci yöntem tercih edilmektedir.Çünkü kodu okumaya başladığınızda, öncelik bu kodun "ne yaptığı" olur. Eğer önce kod yazılırsa bu bazı bilgiler verir. Sonrasında belki de fonksiyonları okumamıza hiç gerek kalmayabilir. Özellikle isimlendirme iyi ise buna gerek yoktur.
+=======
+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
 
 ## Stil Klavuzu
 
 Stil klavuzları genel olarak "nasıl yazılmalı" sorusunun cevabını verir: Kaç satır bırakılmalıdırı, nerede yeni satıra geçilmelidir vs. çok küçük küçük şeyler.
 
 Genel olarak tüm takım üyeleri bu kurallara uyduğunda kod tek bir elden çıkmış gibi görünür. Kimin yazdığı önemini yitirir.
 
+<<<<<<< HEAD
 Tabi takımın kendine ait bir stil klavuzu da olabilir. Fakat çoğu daha önce denendiğinden dolayı yenisini oluşturmaya gerek yoktur. Örneğin:
+=======
+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
 
 
 - [Google JavaScript Style Guide](https://google.github.io/styleguide/javascriptguide.xml)
@@ -271,15 +345,27 @@ Tabi takımın kendine ait bir stil klavuzu da olabilir. Fakat çoğu daha önce
 - [StandardJS](https://standardjs.com/)
 - (ve birçoğu)
 
+<<<<<<< HEAD
 Eğer kodlamaya yeni başladıysanız, şimdilik yukarıda bahsettiğimiz kopya kağıdından faydalanabilirsiniz. Daha sonra stil klavuzlarına bakarak istediğinizi örnek alabilir ve bir tanesini seçebilirsiniz.
+=======
+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
 
 ## Otomatik Düzenleyiciler
 
+<<<<<<< HEAD
 Kod stilinizi otomatik olarak denetleyen araçlar bulunmaktadır. Bunlara "düzenleyici" - linter denebilir.
 
 Bunların en önemli özelliği stili kontrol etmesinin yanında yazımdaki hataları, fonksiyon isimlerindeki problemleri bulur.
 
 Bundan dolayı bir tanesini kullanmanız öneririli. Sadece kelime hatalarını düzeltmeniz için bile olsa kullanmanız iyidir.
+=======
+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
 
 En çok bilinen araçlar:
 
@@ -329,8 +415,14 @@ Ayrıca bazı IDEler bu otomatik düzenleyicileri kendileri doğrudan entegre ed
 
 ## Özet
 
+<<<<<<< HEAD
 Bu bölümdeki tüm yazım kurallar ve stil klavuzlarının amacı okunabilrliği artırmaktır. Bundan dolayı tamamı tartışılabilir.
 
 "Nasıl daha iyi yazarız?" sorusu hakkında düşündüğümüzde, kriter "Nasıl daha iyi okunur kod yazabilir, nasıl yazarken hatalardan kaçabiliriz?" sorularını aklımızda tutmamız gereklidir. Buna göre stil seçip hangisinin daha iyi olduğuna karar verebiliriz.
+=======
+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
 
 Stil klavuzlarını okuyun ve son gelişmeler hakkında daha iyi bilgi sahibi olun, buna göre en iyiyi seçebilirsiniz.
diff --git a/1-js/03-code-quality/02-coding-style/code-style.png b/1-js/03-code-quality/02-coding-style/code-style.png
diff --git a/1-js/03-code-quality/02-coding-style/code-style@2x.png b/1-js/03-code-quality/02-coding-style/code-style@2x.png
diff --git a/1-js/03-code-quality/03-comments/article.md b/1-js/03-code-quality/03-comments/article.md
@@ -5,7 +5,11 @@ Genelde  yorum satırları kodun nasıl ve niçin çalıştığını anlatmak i
 
 İlk görüşte yorum yapmanın gereklilik olduğu aşikardır. Fakat programlama yeni başlayanlayanlar bunu ilk önce genelde yanlış anlamaktadırlar.
 
+<<<<<<< HEAD
 ## Kötü Yorum
+=======
+At first sight, commenting might be obvious, but novices in programming usually get it wrong.
+>>>>>>> 6bbe0b4313a7845303be835d632ef8e5bc7715cd
 
 Programlamaya yeni başlayanlar yorumları genelde "kodda ne oluyor"'u anlatmak için kullanırlar. Örneğin:
 
@@ -17,9 +21,13 @@ karmaşık;
 kod;
 ```
 
+<<<<<<< HEAD
 Fakat iyi kod aslında kendi kendini açıklayan koddur. Yorum satırlarının olabildiğince az olması beklenir. Gerçekten, kod yorum satırı olmadan da kolayca anlaşılabilir olmalı.
 
 Bunun için harika bir kural var: "Eğer bir kod yorum yapmayı gerektirecek kadar karmaşıksa, kodu tekrar yazmanızda yarar var"
+=======
+But in good code, the amount of such "explanatory" comments should be minimal. Seriously, the code should be easy to understand without them.
+>>>>>>> 6bbe0b4313a7845303be835d632ef8e5bc7715cd
 
 ### Çözüm: Fonksiyonları dışarıya atın.
 

diff --git a/1-js/03-code-quality/05-testing-mocha/3-pow-test-wrong/solution.md b/1-js/03-code-quality/05-testing-mocha/3-pow-test-wrong/solution.md
@@ -4,7 +4,11 @@ Burada aslında 3 tane test var, fakat bunların hepsi bir fonksiyon içine tık
 
 Bazen böyle yazmak kolay olsa da bir hata olursa bu gizli saklı kalır ve nerede hata olduğu anlaşılamaz.
 
+<<<<<<< HEAD
 Eğer karmaşık bir akış içinde bir hata olursa ve bunun nedenini testler vasıtasıyla çözmeye çalışırsanız, testleri **ayıklamanız** gerekir.
+=======
+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
 
 Bunun yerine testi birden çok `it` bloğuna ayırırsanız bu problemden kurtulursunuz.