Merge pull request BonsaiDen#86 from ciembor/master

Correction of Polish translation.

Author: BonsaiDen

doc/pl/array/constructor.md

@@ -2,7 +2,7 @@
 
 Zaleca się zawsze korzystać z literału tablicy - notacja `[]` - podczas tworzenia 
 nowych tablic, ponieważ konstruktor `Array` niejednoznacznie interpretuje 
-parametry do niego przekazane.
+przekazane do niego parametry.
 
     [1, 2, 3]; // Rezultat: [1, 2, 3]
     new Array(1, 2, 3); // Rezultat: [1, 2, 3]
@@ -14,15 +14,15 @@ parametry do niego przekazane.
 W przypadku gdy tylko jeden argument zostanie przekazany do kostruktora `Array` i 
 ten argument jest typu `Number`, konstruktor zwróci nową *dziwną* tablicę 
 z ustawioną właściwością `length` na wartość przekazaną jako argument. Należy 
-zauważyć, że **tylko** właściwość `length` zostanie ustawiona w ten sposób,
-rzeczywiste indeksy w tej tablicy nie zostaną zainicjalizowane.
+zauważyć, że **tylko** właściwość `length` zostanie ustawiona w ten sposób.
+Rzeczywiste indeksy w tej tablicy nie zostaną zainicjalizowane.
 
     var arr = new Array(3);
     arr[1]; // undefined
     1 in arr; // zwraca false, indeks nie został ustawiony
 
-Możliwość ustanienia z góry długości tablicy jest użyteczna tylko w kilku 
-przypadkach, jak powtarzanie ciągu znaków, w którym unika się stosowania 
+Możliwość ustalenia z góry długości tablicy jest użyteczna tylko w kilku 
+przypadkach, jak np. powtarzanie ciągu znaków, w którym unika się stosowania 
 pętli `for`.
 
     // count - ilosc powtorzen
@@ -31,7 +31,7 @@ pętli `for`.
 
 ### Wnioski
 
-W miare możliwości należy unikać używania konstruktora `Array`. Literały są 
-zdecydowanie lepszym rozwiązaniem, są krótsze i mają bardziej precyzyjną składnię.
+W miarę możliwości należy unikać używania konstruktora `Array`. Literały są 
+zdecydowanie lepszym rozwiązaniem. Są krótsze i mają bardziej precyzyjną składnię.
 Zwiększają również czytelność kodu.
 

doc/pl/array/general.md

@@ -1,15 +1,15 @@
-## Iterowanie po tablicach oraz właściwości tablic
+## Iterowanie po tablicach oraz właściwościach tablic
 
-Mimo, że tablice w JavaScript są obiektami, nie ma dobrych powodów do używania 
-[`pętli for in`](#object.forinloop) do iteracji po nich. W rzeczywiści istnieje 
-wiele dobrych powodów **przeciwko** wykorzystania `for in` na tablicach.
+Mimo że tablice w JavaScript są obiektami, nie ma dobrych powodów aby używać 
+[`pętli for in`](#object.forinloop) do iteracji po nich. W rzeczywstości istnieje 
+wiele dobrych powodów **przeciwko** wykorzystaniu `for in` na tablicach.
 
 > **Uwaga:** Tablice JavaScriptowe **nie** są *tablicami asocjacyjnymi*. JavaScript
 > posiada tylko [obiekty](#object.general) do mapowania kluczy do wartości. Jednakże 
 > tablice asocjacyjne **zachowują** porządek, natomiast obiekty **nie zachowują**.
 
 Ponieważ pętla `for in` wylicza wszystkie właściwości, które są wewnątrz 
-łańcucha prototypów i jedynym sposobem aby wykluczyć te właściwości to użycie 
+łańcucha prototypów i jedynym sposobem aby wykluczyć te właściwości jest użycie 
 [`hasOwnProperty`](#object.hasownproperty), ale wówczas pętla staje się 
 **dwadzieście razy** wolniejsza od normalnej pętli `for`.
 
@@ -23,22 +23,22 @@ użyć klasycznej pętli `for`.
         console.log(list[i]);
     }
 
-Jest tam jeszcze jeden dodatkowy haczyk w przykładzie powyżej. Jest to zbuforowanie 
+W powyższym przykładzie jest jeszcze jeden dodatkowy haczyk. Jest to zbuforowanie 
 długości tablicy poprzez `l = list.length`.
 
-Mimo, że właściwość `length` jest zdefiniowana w wewnątrz tablicy, istnieje nadal 
+Mimo że właściwość `length` jest zdefiniowana wewnątrz tablicy, istnieje nadal 
 dodatkowy koszt na wyszukiwanie tej właściwości przy każdej iteracji w pętli. 
-Chociaż najnowsze silniki JavaScript **mogą** zastosować optymalizację w tym 
-przypadku. Nie ma jednak możliwość ustalenia czy kod będzie wykonywany w jednym 
-z tych nowych silników czy też nie.
+Chociaż najnowsze silniki JavaScript **mogą** zastosować w tym 
+przypadku optymalizację. Nie ma jednak możliwość ustalenia czy kod będzie wykonywany w jednym 
+z tych nowych silników, czy też nie.
 
-W rzeczywistości pomijając buforowanie długości tablicy może spowodować, że pętla 
+W rzeczywistości pominięcie buforowania długości tablicy może spowodować, że pętla 
 będzie tylko **w połowie tak szybka** jak ta z buforowaniem długości.
 
 ### Właściwość `length`
 
-Mimo, że *getter* właściwości `length` po prostu zwraca liczbę elementów, które są 
-zawarte w tablicy, to *setter* może być użyta do **skracania** tablicy.
+Mimo, że *getter* właściwości `length` zwraca po prostu liczbę elementów, które są 
+zawarte w tablicy, to *setter* może być użyty do **skracania** tablicy.
 
     var foo = [1, 2, 3, 4, 5, 6];
     foo.length = 3;
@@ -54,5 +54,5 @@ Przypisanie mniejszej długości spowoduje skrócenie tablicy, ale zwiększenie
 
 Aby uzyskać najlepszą wydajność zaleca się, aby zawsze używać zwykłej pętli `for`
 i zbuforowanie właściwości `length`. Korzystanie z pętli `for in` na tablicy jest 
-znakiem źle napisanego kodu, który jest podatny na błędy i ma słabą wydajność.
+oznaką źle napisanego kodu, który jest podatny na błędy i ma słabą wydajność.
 

doc/pl/core/eval.md

@@ -1,4 +1,4 @@
-## Dlaczego nie należy używać `eval`
+## Dlaczego nie należy używać `eval`?
 
 Funkcja `eval` uruchomi podany string jako kod JavaScript w lokalnym zasięgu (scopie).
 
@@ -11,8 +11,8 @@ Funkcja `eval` uruchomi podany string jako kod JavaScript w lokalnym zasięgu (s
     test(); // 3
     foo; // 1
 
-Niestaty `eval` zostanie wykonana w lokalnym zasięgu tylko jeżeli została wywołana 
-**bezpośrednio** *i* nazwa wołanej funkcji równa sie `eval`.  
+Niestaty, `eval` zostanie wykonana w lokalnym zasięgu tylko wtedy, gdy zostanie wywołana 
+**bezpośrednio** *i* nazwa wywoływanej funkcji równa sie `eval`.  
 
     var foo = 1;
     function test() {
@@ -30,20 +30,19 @@ osiągnąć ten sam efekt **nie** używając `eval`.
 ### `eval` w przebraniu
 
 [Funkcje wykonywane po upływie czasu](#other.timeouts) `setTimeout` i `setInterval` 
-mogą przyjąć string jako pierwszy argument. String ten zostanie **zawsze** wykonany 
-w globalnym zasięgu, ponieważ funkcja `eval` zostanie wywołana niebezpośrednio w tym 
-przypadku.
+mogą przyjąć string jako pierwszy argument. String ten **zawsze** będzie wykonywany 
+w globalnym zasięgu, ponieważ funkcja `eval` jest w tym wypadku wywoływana pośrednio.
 
 ### Problemy z bezpieczeństwem
 
 Funkcja `eval` jest również problematyczna od strony bezpieczeństwa, ponieważ 
-wykonuje **każdy** kod, który zostanie do niej przekazany i nie należy **nigdy** 
-używać jej na stringach nieznanego lub niezaufanego pochodzenia.
+wykonuje **każdy** kod, który zostanie do niej przekazany i **nigdy** nie należy
+jej używać na stringach nieznanego lub niezaufanego pochodzenia.
 
 ### Wnioski
 
-Funkcja `eval` nie powinna być w ogole używana, każdy kod, który ją wykorzystuje 
+Funkcja `eval` nie powinna być w ogóle używana. Każdy kod, który jej używa
 powinien zostać sprawdzony pod względem działania, wydajności i bezpieczeństwa. 
 W przypadku gdy użycie `eval` jest niezbędne do działania, wówczas taki kod 
-należy przemyśleć raz jeszcze i *ulepszyć* kod aby nie wymagał użycia `eval`. 
+należy ponownie przemyśleć i *ulepszyć* aby nie wymagał użycia `eval`. 
 

doc/pl/core/semicolon.md

@@ -1,9 +1,9 @@
 ## Automatyczne wstawianie średnika
 
-Mimo, że JavaScript ma składnię podobną do języka C, to **nie** wymusza stosowania 
+Mimo że JavaScript ma składnię podobną do języka C, to **nie** wymusza stosowania 
 średników w kodzie źródłowym. Istnieje możliwość ich pominięcia.  
 
-Lecz JavaScript nie jest językiem bez średników, tak na prawdę potrzebuje 
+JavaScript nie jest językiem bez średników, tak na prawdę potrzebuje 
 średników aby zinterpretować kod źródłowy. Jednakże parser JavaScript 
 **automatycznie** wstawia średniki o ile napotka błąd parsowania związany z 
 brakiem średnika.
@@ -19,7 +19,7 @@ Parser dodaje średnik, i próbuje jeszcze raz sparsować skrypt.
     test()
 
 Automatyczne wstawianie średników jest uważane za jeden z **największych** błędów 
-konstrukcji języka, ponieważ *może* ono zachowanie kodu.
+konstrukcji języka, ponieważ *może* ono zmienić zachowanie kodu.
 
 ### Jak działa wstawianie
 
@@ -84,11 +84,11 @@ Poniżej znajduje się rezultat "zgadywania" parsera.
     })(window); //<- wstawiony
 
 > **Uwaga:** Parser JavaScript nie potrafił "odpowiednio" zinterpretować 
-> deklaracji return, po którje został dodany znak nowej linii. Mimo, że 
+> deklaracji return, po której został dodany znak nowej linii. Mimo że 
 > niekoniecznie jest to błąd automatycznego wstawiania średników, to może to 
 > jednak powodować niechciane efekty uboczne 
 
-Parser drastycznie zmienił działanie powyższego kodu, w niektórych przypadkach 
+Parser drastycznie zmienił działanie powyższego kodu. W niektórych przypadkach 
 **zmienił go źle**.
 
 ### Nawiasy
@@ -99,19 +99,19 @@ W przypadku, gdy w następnej linii znajduje się nawias, parser **nie** wstawi
     log('testing!')
     (options.list || []).forEach(function(i) {})
 
-Ten kod zostanie zmieniony w poniższą jedną linię.
+Kod ten zostanie zmieniony w poniższą linię.
 
     log('testing!')(options.list || []).forEach(function(i) {})
 
-Jest **bardzo** prawdopodobne, że `log` **nie** zwróci fukcji, co za tym idzie 
+Jest **bardzo** prawdopodobne, że `log` **nie** zwróci fukcji. Co za tym idzie 
 powyższy kod wyrzuci błąd `TypeError` oznajmując, że `undefined is not a 
 function` - `undefined` nie jest funkcją.
 
 ### Wnioski
 
-Zaleca się aby **nigdy** nie pomijać średników, pozostawiać nawias otwierający 
+Zaleca się, aby **nigdy** nie pomijać średników, pozostawiać nawias otwierający 
 w tej samej linii co odpowiadająca mu definicja i nigdy nie pozostawiać deklaracji 
-`if` / `else` bez nawiasów nawet jeżeli są jednolinijkowe. Wszystkie te uwagi nie 
-tylko pomagają poprawić spójność kodu, ale również zapobiegają parser JavaScript 
-przed zmianą działania kod.
+`if` / `else` bez nawiasów - nawet, jeżeli są jednolinijkowe. Wszystkie te uwagi nie 
+tylko pomagają poprawić spójność kodu, ale też zapobiegają zmianie działania 
+kodu przez parser JavaScript.
 

doc/pl/core/undefined.md

@@ -7,45 +7,44 @@ z tych dwóch jest `undefined`.
 
 `undefined` jest typem z dokładnie jedną wartością: `undefined`.
 
-Język również definiuje globalną zmienną, która ma wartość `undefined`, zmienna 
-ta jest nazwana `undefined`. Jednakże jest to zmienna a **nie** stała czy słowo 
-kluczowe w języku. Oznacza to że możliwe jest nadpisanie *wartości* tej zmiennej.
+Język również definiuje globalną zmienną, która ma wartość `undefined` - zmienna 
+ta jest nazwana `undefined`. Jednakże jest to zmienna a **nie** stała, czy słowo 
+kluczowe. Oznacza to, że możliwe jest nadpisanie *wartości* tej zmiennej.
 
 > Uwaga ES55: `undefined` w ECMAScript 5 **nie będzie już** *nadpisywalna* w trybie
-> strict mode, ale jej nazwa może zostać przysłonona przez na przykład funkcję o 
+> strict mode, ale jej nazwa może zostać przesłoniona przez na przykład funkcję o 
 > nazwie `undefined`.
 
 Kilka przykładów kiedy wartość `undefined` jest zwracana:
 
- - Dostęp do (niemodyfikowalnej) zmiennej globalnej `undefined`.
- - Wyjście z funkcji, która nie ma deklaracji `return`.
- - Deklaracja `return`, która nic jawnie nie zwraca.
- - Poszukiwanie nieistniejącej właściwości.
- - Parametr funkcji, który nie został jawnie przekazany podczas wywołania funkcji
- - Wszystko co zostało ustawione na wartość `undefined`
+ - dostęp do (niemodyfikowalnej) zmiennej globalnej `undefined`,
+ - wyjście z funkcji, która nie ma deklaracji `return`,
+ - deklaracja `return`, która nic jawnie nie zwraca,
+ - poszukiwanie nieistniejącej właściwości,
+ - parametr funkcji, który nie został jawnie przekazany podczas wywołania funkcji,
+ - wszystko czemu została przypisana wartość `undefined`.
 
 ### Obsługa przypadku zmiany wartości `undefined`
 
-Ponieważ globalna zmienna `undeined` tylko zawiera kopię prawdziwej *wartości* typu 
+Ponieważ globalna zmienna `undefined` zawiera tylko kopię prawdziwej *wartości* typu 
 `undefined`, przypisanie nowej wartości do tej zmiennej **nie** zmienia wartości 
 *typu* `undefined`.
 
-Jednak, aby porównać coś do wartości `undefined` potrzebne jest odczytanie wartości 
-`undefined`.
+Jednak aby porównać coś z wartością `undefined`, trzeba odczytać wartość `undefined`.
 
-Aby uchronić swój kod przeciwko możliwemu nadpisaniu zmiennej `undefined`, korzysta 
+Aby uchronić swój kod przed możliwym nadpisaniem zmiennej `undefined`, korzysta 
 się z powszechnej techniki dodania dodatkowego parametru do 
 [anonimowego wrappera](#function.scopes), do którego nie zostanie przekazany 
 argument.
 
     var undefined = 123;
     (function(something, foo, undefined) {
-        // undefined lokalnym zasięgu znowu 
+        // undefined o lokalnym zasięgu znowu 
         // odnosi się do poprawnej wartości
 
     })('Hello World', 42);
 
-Kolejnym sposobem aby osiągnąć ten sam efekt jest użycie deklaracji zmiennej 
+Kolejnym sposobem na osiągnięcie tego samego efektu jest użycie deklaracji zmiennej 
 wewnątrz wrappera.
 
     var undefined = 123;
@@ -55,13 +54,13 @@ wewnątrz wrappera.
 
     })('Hello World', 42);
 
-Jedyną różnicą pomięcy tymi sposobami są dodatkowe 4 bajty przeznaczone na słowo 
+Jedyną różnicą pomiędzy tymi sposobami są dodatkowe 4 bajty przeznaczone na słowo 
 kluczowe `var` i spację po nim.
 
 ### Zastosowanie `null`
 
 Podczas gdy `undefined` w kontekście języka jest używany jak *null* w sensie 
-tradycyjnych języków, to `null` w JavaScript (jako literał i jako typ) jest po 
+tradycyjnych języków, `null` w JavaScript (jako literał i jako typ) jest po 
 prostu kolejnym typem danych.
 
 Jest wykorzystywany we wnętrzu JavaScript (np. deklaracji końca łańcucha prototypów 

doc/pl/function/arguments.md

@@ -1,18 +1,18 @@
 ## Obiekt `arguments`
 
-Każda zasięg funkcyjny w języku JavaScript ma dostęp do specjalnej zmiennej `arguments`. 
+Każdy zasięg funkcyjny w języku JavaScript ma dostęp do specjalnej zmiennej `arguments`. 
 Ta zmienna trzyma listę wszystkich argumentów przekazanych do funkcji.
 
-> **Uwaga:** W przypadku gdy `arguments` zostanie zadeklarowana wewnatrz funkcji
+> **Uwaga:** W przypadku gdy `arguments` zostanie zadeklarowana wewnątrz funkcji
 > poprzez `var` lub jako nazwa jednego z formalnych parametrów, obiekt `arguments` 
 > nie zostanie utworzony.
 
-Obiekt `arguments` **nie** jest typu `Array`. Mimo, że posiada pewne cechy 
-semantyki tablic - właściwość `length` - to nie dziedziczy on z `Array.prototype`,
-ale w rzeczywistości z `Object`.
+Obiekt `arguments` **nie** jest typu `Array`. Mimo że posiada pewne cechy 
+semantyki tablic - właściwość `length` - to w rzeczywistości nie dziedziczy 
+on z `Array.prototype`, tylko z `Object`.
 
-Ze względu na to **nie** można używać standardowych dla tablic metod takich jak
-`push`, `pop` czy `slice` na obiekcie `arguments`. Mimo, że iteracja przy pomocy 
+Ze względu na to, na obiekcie `arguments` **nie** można używać standardowych dla tablic metod, 
+takich jak `push`, `pop` czy `slice`. Mimo że iteracja przy pomocy 
 pętli `for` działa dobrze, to aby skorzystać ze standardowych metod tablicowych 
 należy skonwertować `arguments` do prawdziwego obiekt `Array`.
 
@@ -29,7 +29,7 @@ które mają duży wpływ na wydajność.
 ### Przekazywanie argumentów
 
 Zalecany sposób przekazywania argumentów z jednej funkcji do następnej 
-wyglada następująco.
+wyglada następująco:
 
     function foo() {
         bar.apply(null, arguments);
@@ -58,11 +58,11 @@ szybkich i nieograniczonych wrapperów.
 
 ### Parametry formalne i indeksy argumentów
 
-Obiekt `arguments` tworzy funckje *getter* i *setter* nie tylko dla swoich 
+Obiekt `arguments` tworzy funkcje *getter* i *setter* nie tylko dla swoich 
 właściwości, ale również dla parametrów formalnych funkcji.
 
 W rezultacie zmiana wartości parametru formalnego zmieni również wartość 
-odpowiadającemu mu wpisowi w obiekcie `arguments`, zachodzi to również w drugą stronę.
+odpowiadającemu mu wpisowi w obiekcie `arguments`. Zachodzi to również w drugą stronę.
 
     function foo(a, b, c) {
         arguments[0] = 2;
@@ -79,7 +79,7 @@ odpowiadającemu mu wpisowi w obiekcie `arguments`, zachodzi to również w drug
 
 ### Mity i prawdy o wydajności
 
-Obiekt `arguments` jest zawsze tworzony z wyjątkiem dwóch przypadków, gdy
+Obiekt `arguments` jest tworzony zawsze, z wyjątkiem dwóch przypadków, gdy
 zmienna o takiej nazwie jest zdefiniowana wewnątrz funkcji lub jeden z parametrów 
 formalnych funkcji ma taką nazwę. Nie ma znaczenia czy obiekt `arguments` jest 
 używany czy nie.
@@ -108,9 +108,8 @@ nowoczesnych silnikach JavaScript. Ten przypadek to wykorzystanie
 W powyższym przykładzie `foo` nie może zostać wykorzystana metoda [inline][1] 
 ponieważ potrzebne są nie tylko informacje na własny temat ale również 
 na temat funkcji wywołującej. Takie użycie nie tylko uniemożliwia 
-inlining i korzyści z niej wynikające, ale również stanowi złamanie 
-zasad enkapsulacji ponieważ ta funkcja jest zależna od kontekstu 
-w jakim została wywołana.
+inlining i korzyści z niego wynikające, ale też łamie zasady enkapsulacji, 
+ponieważ ta funkcja jest zależna od kontekstu w jakim została wywołana.
 
 **Mocno zalecane** jest aby **nigdy** nie korzystać z `arguments.callee` 
 i żadnej jej własności.