provide hungarian translation

Author: jozsefDevs

doc/hu/array/constructor.md

@@ -0,0 +1,34 @@
+## Az `Array` konstruktor
+
+Mivel az `Array` konstruktora kétértelműen bánik a paraméterekkel, melegen
+ajánlott mindig a tömb literált - `[]` jelölés - használni új tömbök létrehozásakor.
+
+    [1, 2, 3]; // Eredmény: [1, 2, 3]
+    new Array(1, 2, 3); // Eredmény: [1, 2, 3]
+
+    [3]; // Eredmény: [3]
+    new Array(3); // Eredmény: []
+    new Array('3') // Eredmény: ['3']
+
+Abban az esetben, hogyha ez a konstruktor csak egy `szám` paramétert kap, akkor
+visszatérési értékül egy olyan tömböt fog létrehozni amelynek a `length` mezője
+akkorára van beállítva, ahogy azt megadtuk az argumentumban. Megjegyzendő hogy
+**csak** a `length` tulajdonság lesz ekkor beállítva; az egyes indexek külön-külön
+nem lesznek inicializálva.
+
+    var arr = new Array(3);
+    arr[1]; // undefined
+    1 in arr; // hamis, nincs ilyen index
+
+A tömb hosszának közvetlen állítása amúgy is csak elég kevés esetben
+használható értelmesen, mint például alább, hogyha el akarjuk kerülni a 
+`for ciklus` használatát egy string ismétlésekor.
+
+    new Array(count + 1).join(ismetlendoString);
+
+### Összegzésül
+
+Az `Array` konstruktor közvetlen használata erősen kerülendő. A literálok használata
+elfogadott inkább, mivel rövidebbek, tisztább a szintaxisuk és olvashatóbb kódot
+eredményeznek.
+

doc/hu/array/general.md

@@ -0,0 +1,58 @@
+## Tömb iteráció és tulajdonságok
+
+Habár a tömbök a JavaScriptben objektumok, nincsen jó ok arra, hogy a [`for in`](#object.forinloop) ciklussal járjuk be őket. 
+Valójában sokkal több jó ok van arra, hogy **miért ne** így tegyünk.
+
+> **Megjegyzés:** A JS tömbök **nem** *asszociatív tömbök*. A JavaScriptben egyedül
+> az [objektumokkal](#object.general) lehet kulcsokat értékekhez rendelni. Ráadásul
+> amíg az asszociatív tömbök **megőrzik** a sorrendjüket, az objektumok **nem**.
+
+Mivel a `for in` ciklus a prototípus láncon levő összes tulajdonságon végigmegy,
+és mivel az egyetlen út ennek megkerülésére a [`hasOwnProperty`](#object.hasownproperty) használata, így majdnem **hússzor** 
+lassabb mint egy sima `for` ciklus.
+
+### Iteráció
+
+Annak érdekébern hogy a legjobb teljesítményt érjük el a tömbökön való iteráció során,
+a legjobb hogyha a klasszikus `for` ciklust használjuk.
+
+    var list = [1, 2, 3, 4, 5, ...... 100000000];
+    for(var i = 0, l = list.length; i < l; i++) {
+        console.log(list[i]);
+    }
+
+Még egy érdekesség van a fenti példában, ami a tömb hosszának cachelését végzi
+a `l = list.length` kifejezés használatával.
+
+Habár a `length` tulajdonság mindig magán a tömbön van definiálva, még mindig
+lehet egy kis teljesítmény kiesés amiatt hogy minden iterációban újra meg kell
+keresni ezt a tulajdonságot. Persze a legújabb JavaScript motorok **talán**
+használnak erre optimalizációt, de nem lehet biztosan megmondani hogy ahol a kódunk
+futni fog, az egy ilyen motor-e vagy sem.
+
+Valójában, a cachelés kihagyása azt eredményezheti, hogy a ciklusunk csak 
+**fele olyan gyors** lesz mintha a cachelős megoldást választottuk volna.
+
+### A `length` mező
+
+Míg a `length` mező *getter* függvénye egyszerűen csak visszaadja a tömbben
+levő elemek számát, addig a *setter* függvény használható arra (is), hogy
+**megcsonkítsuk** a tömbünket.
+
+    var foo = [1, 2, 3, 4, 5, 6];
+    foo.length = 3;
+    foo; // [1, 2, 3]
+
+    foo.length = 6;
+    foo.push(4);
+    foo; // [1, 2, 3, undefined, undefined, undefined, 4]
+
+Egy rövidebb hossz alkalmazása csonkítja a tömböt. A nagyobb hossz megadása
+értelemszerűen növeli.
+
+### Összegzésül
+
+A megfelelő teljesítmény érdekében, a `for` ciklus használata és a length cachelése
+ajánlott. A `for in` ciklus használata a tömbökön a rosszul megírt kód jele, amely
+tele lehet hibákkal, és teljesítményben sem jeleskedik.
+

doc/hu/core/delete.md

@@ -0,0 +1,91 @@
+## A `delete` Operátor
+
+Röviden, *lehetetlen* globális változókat, függvényeket és olyan dolgokat törölni
+JavaScriptben amelyeknek a `DontDelete` attribútuma be van állítva.
+
+### Globális kód és Függvény kód
+
+Amikor egy változó/függvény, globális vagy 
+[függvény hatókörben](#function.scopes) van definiálva, 
+akkor az vagy az Aktivációs (Activation) vagy a Globális (Global) objektum egyik mezőjeként
+jön létre.  Az ilyen mezőknek van egy halom attribútuma, amelyek közül az egyik 
+a `DontDelete`. A változó és függvény deklarációk a globális vagy függvény kódon
+belül mindig `DontDelete` tulajdonságú mezőket hoznak létre, így nem lehet őket
+törölni.
+
+    // globális változó
+    var a = 1; // A DontDelete be lett állítva
+    delete a; // hamis
+    a; // 1
+
+    // függvény:
+    function f() {} // A DontDelete be lett állítva
+    delete f; // hamis
+    typeof f; // "function"
+
+    // új értékadással sem megy
+    f = 1;
+    delete f; // hamis
+    f; // 1
+
+### Explicit mezők
+
+Az expliciten beállított mezőket persze normálisan lehet törölni.
+
+    // expliciten beállított mező
+    var obj = {x: 1};
+    obj.y = 2;
+    delete obj.x; // igaz
+    delete obj.y; // igaz
+    obj.x; // undefined
+    obj.y; // undefined
+	
+
+A fenti példábna az `obj.x` és `obj.y` törölhető, mivel nincs `DontDelete`
+attribútuma egyik mezőnek sem. Ezért működik az alábbi példa is.
+
+    // működik, kivéve IE-ben
+    var GLOBAL_OBJECT = this;
+    GLOBAL_OBJECT.a = 1;
+    a === GLOBAL_OBJECT.a; // igaz - egy globális változó
+    delete GLOBAL_OBJECT.a; // igaz
+    GLOBAL_OBJECT.a; // undefined
+
+Itt egy trükköt használunk az `a` törlésére. A [`this`](#function.this) itt 
+a Globális objektumra mutat, és expliciten bezetjük rajta az `a` változót, mint
+egy mezőjét, így törölni is tudjuk.
+
+Mint az szokás, a fenti kód egy kicsit bugos IE-ben (legalábbis 6-8-ig).
+
+### Függvény argumentumok és beépített dolgaik
+
+A függvény argumentumok, az [`arguments` objektum](#function.arguments)
+és a beépített mezők szintén `DontDelete` tulajdonságúak.
+
+    // függvény argumentumok és mezők
+    (function (x) {
+    
+      delete arguments; // hamis
+      typeof arguments; // "object"
+      
+      delete x; // hamis
+      x; // 1
+      
+      function f(){}
+      delete f.length; // hamis
+      typeof f.length; // "number"
+      
+    })(1);
+
+### Vendég (host) objektumok
+
+A `delete` operátor működése megjósolhatatlan a vendég objektumokra. A specifikáció
+szerint ezek az objektumok szükség szerint bármilyen viselkedést implementálhatnak.
+
+(A ford.: Vendég objektumok azok az objektumok, amelyek nincsenek konkrétan
+meghatározva az ES aktuális verziójú specifikációjában, pl. a window)
+
+### Összegzésképp
+
+A `delete` működése helyenként megjósolhatatlan, így biztonsággal csak olyan
+objektumok mezőin használhatjuk amelyeket expliciten mi állítottunk be.

doc/hu/core/eval.md

@@ -0,0 +1,49 @@
+## Miért Ne Használjuk az `eval`-t
+
+Az `eval` (evil) funkció egy stringbe ágyazott JavaScript kódot futtat a 
+lokális scopeon belül.
+
+    var foo = 1;
+    function test() {
+        var foo = 2;
+        eval('foo = 3');
+        return foo;
+    }
+    test(); // 3
+    foo; // 1
+	
+Viszont az `eval` csak akkor viselkedik így, hogyha expliciten hívjuk meg
+*és* a meghívott funkció neve valóban `eval`.
+
+    var foo = 1;
+    function test() {
+        var foo = 2;
+        var bar = eval;
+        bar('foo = 3');
+        return foo;
+    }
+    test(); // 2
+    foo; // 3
+
+Az `eval` használata kerülendő. A "felhasználása" az esetek 99.9%-ban 
+**mellőzhető**.
+    
+### Az `eval` ezer arca
+
+A `setTimeout` és `setInterval` nevű [timeout függvények](#other.timeouts) is
+tudnak úgy működni, hogy első paraméterükként egy stringbe ágyazott kódot várnak.
+Ez a string **mindig** a globális hatókörben lesz végrehajtva, mivel az `eval`t
+így nem direktben hívjuk meg.
+
+### Biztonsági problémák
+
+Az `eval` azért is veszélyes, mert **bármilyen** JS kódot végrehajt, amit odaadunk
+neki. Éppen ezért **sose** használjuk olyan kódok végrehajtására amiknek az eredete
+nem megbízható/ismeretlen.
+
+### Összegzésül
+
+Soha ne használjunk `eval`t. Bármilyen kód működése, teljesítménye, ill. biztonsága
+megkérdőjelezhető amely használja ezt a nyelvi elemet. Semmilyen megoldás
+használata **nem ajánlott** amely első sorban `eval`ra épül. Ekkor egy *jobb
+megoldás* szükségeltetik, amely nem függ az `eval`tól.

doc/hu/core/semicolon.md

@@ -0,0 +1,119 @@
+## Automatic Semicolon Insertion
+
+Bár a JavaScriptnek látszólag C-s szintaxisa van, **mégsem** kötelező benne
+kirakni a pontosvesszőket, így (helyenként) kihagyhatóak a forrásból.
+(A ford.: hiszen interpretált nyelv lévén nincsenek fordítási hibák, így 
+nyelvi elemek meglétét sem tudja erőltetni a nyelv)
+
+Itt jön a csel, hogy ennek ellenére a JavaScript csak pontosvesszőkkel
+értelmezi megfelelően a beírt kódot. Következésképp, a JS **automatikusan**
+illeszti be a pontosvesszőket (megpróbálja kitalálni a gondolataink) 
+azokra a helyekre, ahol amúgy emiatt értelmezési hibába futna.
+
+    var foo = function() {
+    } // értelmezési hiba, pontosvessző kéne
+    test()
+
+Az automatikus beillesztés megtörténik, ezután így értelmeződik a kód
+
+    var foo = function() {
+    }; // nincs hiba, mindenki örül
+    test()
+
+Az automatikus beillesztés (ASI) a JavaScript (egyik) **legnagyobb** design
+hibája, mivel igen... *meg tudja* változtatni a kód értelmezését
+
+### Hogyan Működik
+
+Az alábi kódban nincsen pontosvessző, így az értelmező (parser) feladata kitalálni,
+hogy hova is illessze be őket.
+
+    (function(window, undefined) {
+        function test(options) {
+            log('testing!')
+
+            (options.list || []).forEach(function(i) {
+
+            })
+
+            options.value.test(
+                'hosszú string az argumentumban',
+                'még még még még még hossszabbbbbbb'
+            )
+
+            return
+            {
+                foo: function() {}
+            }
+        }
+        window.test = test
+
+    })(window)
+
+    (function(window) {
+        window.someLibrary = {}
+
+    })(window)
+
+Alább mutatjuk a "kitalálós" játék eredményét.
+
+    (function(window, undefined) {
+        function test(options) {
+
+            // Nincs beillesztés, a sorok össze lettek vonva
+            log('testing!')(options.list || []).forEach(function(i) {
+
+            }); // <- beillesztés
+
+            options.value.test(
+                'hosszú string az argumentumban',
+                'még még még még még hossszabbbbbbb'
+            ); // <- beillesztés
+
+            return; // <- beillesztés, eltörik a return kifejezésünk
+            { // blokként értelemződik
+
+                // név: kifejezés formátumban értelmeződik
+                foo: function() {} 
+            }; // <- beillesztés
+        }
+        window.test = test; // <- beillesztés
+
+    // Ezeket a sorokat összeilleszti
+    })(window)(function(window) {
+        window.someLibrary = {}; // <- beillesztés
+
+    })(window); //<- beillesztés
+
+> **Megjegyzés:** A JavaScript értelmező nem tudja "korrektül" kezelni azokat
+> a return kifejezéseket, amelyek után közvetlen új sor áll. Habár ez nem biztos hogy 
+> szükségszerűen az ASI hibájából történik, azért nem egy túl kellemes mellékhatás.
+
+Az értelmező drasztikusan megváltoztatta a fenti kódot. A legtöbb esetben a 
+beillesztő **rosszul** tippel.
+
+(A ford.: Semmilyen nyelvben sem jó, hogyha hagyjuk hogy a gép találja ki mit
+szerettünk volna írni. Néma gyereknek az anyja sem érti a kódját ugye)
+
+### Kezdő Zárójelek
+
+Az értelmező **nem** rak be új pontosvesszőt, hogyha a sor eleje (nyitó) zárójellel kezdődik.
+
+    log('testing!')
+    (options.list || []).forEach(function(i) {})
+
+Ez a kód egy sorként értelmeződik
+
+    log('testing!')(options.list || []).forEach(function(i) {})
+
+Az esélyek arra **elég** magasak, hogy a `log` **nem** egy függvényt fog visszatéríteni; így a fenti kód egy `TypeError` típusú hibát fog dobni 
+`undefined is not a function` üzenettel.
+
+### Összefoglalásképp
+
+Szükségszerűen **soha** ne hagyjuk ki a pontoszvesszőket. Nem árt a kapcsos
+zárójeleket is ugyanazon a soron tartani, mint amelyiken az utasítást elkezdtük,
+így nem ajánlott az egysoros `if` / `else` kifejezések kedvéért elhagyni
+őket. Ezek a szempontok nem csak a kódot (és annak olvashatóságát) tartják
+konzisztensen, de megelőzik azt is hogy a JavaScript értelmező valamit rosszul
+"találjon ki".