Update guide\pl

Author: tomekbyd

docs/guide/pl/caching.data.txt

@@ -55,7 +55,7 @@ służy wykorzystaniu tej właściwości. W przypadku kiedy używany system bufo
 wspiera tej funkcjonalności metoda [mget()|CCache::mget] zasymuluje ją.
 
 Aby usunąć zbuforowaną wartość z bufora wywołujemy metodę [delete()|CCache::delete];
-aby usunąć całą wartość z bufora wołamy [flush()|CCache::flush]. Bądź bardzo ostrożny
+aby usunąć całą zawartość bufora wywołujemy metodę [flush()|CCache::flush]. Bądź bardzo ostrożny
 podczas wywoływania [flush()|CCache::flush] ponieważ usuwa ono dane, które zostały 
 zbuforowane dla innych aplikacji.
 
@@ -133,7 +133,7 @@ odpowiedniego komponentu buforowania aplikacji (domyślnie `cache`).
 
 ### Używanie buforowania zapytań w DAO
 
-Aby używać buforowania zapytań wołamy metodę [CDbConnection::cache()] podczas wykonywania zapytania 
+Aby używać buforowania zapytań wywołujemy metodę [CDbConnection::cache()] podczas wykonywania zapytania 
 bazodanowego. Poniżej znajduje się przykład:
 
 ~~~
@@ -144,7 +144,7 @@ $rows = Yii::app()->db->cache(1000, $dependency)->createCommand($sql)->queryAll(
 ~~~
 
 Podczas wykonywania powyższej instrukcji, Yii sprawdzi najpierw czy bufor zawiera odpowiedni
-rezultat instrukcji SQL, która ma zostać wykonana. Dzieje się to poprzez sprawdzenia następujących trzech warunków:
+rezultat instrukcji SQL, która ma zostać wykonana. Dzieje się to poprzez sprawdzenie następujących trzech warunków:
 
 - czy bufor zawiera wpis zindeksowany za pomocą instrukcji SQL.
 - czy ważność tego wpisu nie upłynęła (mniej niż 1000 sekund od momentu kiedy został on zapisany w buforze).

docs/guide/pl/caching.fragment.txt

@@ -25,7 +25,7 @@ potrzebujemy ID do zidentyfikowania fragmentu, który będzie buforowany.
 Powyżej, jeśli metoda [beginCache()|CBaseController::beginCache()] zwróci wartość
 false, zbuforowana zawartość będzie automatycznie wstawiona w tym miejscu;
 w przeciwnym przypadku, zawartość zawarta w wyrażeniu `if` będzie wykonana 
-i zbuforowana kiedy metoda [endCache()|CBaseController::endCache()] jest wywołana.
+i zbuforowana do miejsca wywołania metody [endCache()|CBaseController::endCache()].
 
 Opcje buforowania
 ---------------
@@ -40,7 +40,7 @@ każdej z właściwości [COutputCache].
 
 ### Czas trwania
 
-Prawdopodobni najbardziej znaną opcją jest czas trwania [duration|COutputCache::duration],
+Prawdopodobnie najbardziej znaną opcją jest czas trwania [duration|COutputCache::duration],
 która określa jak długo zawartość może pozostać poprawna dla bufora. Jest ona podobna 
 do parametru wygasania metody [CCache::set()]. Następujący kod buforuje część 
 zawartości na maksymalnie godzinę czasu:
@@ -91,10 +91,10 @@ Następujący kod deklaruje część zawartości, zależną od zmian wartości w
 Zawartość, która będzie buforowana, może zostać zmieniona odpowiednio do pewnych
 parametrów. Na przykład, profil osobisty, może wyglądać różnie dla różnych użytkowników.
 Buforując zawartość profilu, będziemy chcieli uzmiennić zbuforowaną kopię, odpowiednio
-do ID użytkowników. To essentially znaczy, że będziemy chcieli używać różnych
+do ID użytkowników. To w istocie oznacza, że będziemy chcieli używać różnych
 ID podczas wołania metody [beginCache()|CBaseController::beginCache()].
 
-Zamiast prosić dewelopera do uzmiennienie ID odpowiednio do pewnego wzorca, 
+Zamiast prosić dewelopera o uzmiennienie ID odpowiednio do pewnego wzorca, 
 [COutputCache] posiada takie wbudowane funkcjonalności. Poniżej ich podsumowanie.
 
    - [varyByRoute|COutputCache::varyByRoute]: ustawiając tą opcję na true, buforowana
@@ -112,7 +112,7 @@ Zamiast prosić dewelopera do uzmiennienie ID odpowiednio do pewnego wzorca,
    GET. Na przykład, jeśli strona wyświetla zawartość posta, odpowiednio do parametru 
    GET o nazwie `id`, możemy określić jako [varyByParam|COutputCache::varyByParam] 
    tablicę `array('id')`, tak, że możemy zbuforować zawartość dla każdego posta.
-   Bez takiej parametryzacji, będziemy mogli buforować pojedyncze posty.
+   Bez takiej parametryzacji, będziemy mogli buforować tylko pojedynczy post.
 
    - [varyByExpression|COutputCache::varyByExpression]: ustawiając tą opcję jako wyrażenie PHP, możemy zbuforowaną
    zawartość uzmiennić w zależności od wyniku wyrażenia PHP.

docs/guide/pl/database.dao.txt

@@ -26,9 +26,9 @@ Ustanawianie połączenia z bazą danych
 -------------------------------------
 
 Aby ustanowić połączenie z bazą danych należy utworzyć instancję [CDbConnection] 
-a następnie aktywować ją. Aby połączyć się z bazą danych potrzebny jest adres DNS. 
+a następnie aktywować ją. Aby połączyć się z bazą danych potrzebny jest adres DSN. 
 Użytkownik oraz hasło mogą być również potrzebne aby ustanowić połączenie. W przypadku 
-gdy podczas łączenia nastąpi błąd (np. podano zły adres DNS lub złe hasło/nazwę użytkownika) 
+gdy podczas łączenia nastąpi błąd (np. podano zły adres DSN lub złe hasło/nazwę użytkownika) 
 zostanie rzucony odpowiedni wyjątek.
 
 ~~~
@@ -40,10 +40,10 @@ $connection->active=true;
 $connection->active=false;  // zamknij połączenie
 ~~~
 
-Format adresu DNS zależy od używanego, dla danej bazy danych, sterownika PDO. Uogólniając, 
-DNS składa się z nazwy sterownika PDO, po którym następuje dwukropek a następnie 
+Format adresu DSN zależy od używanego, dla danej bazy danych, sterownika PDO. Uogólniając, 
+DSN składa się z nazwy sterownika PDO, po którym następuje dwukropek a następnie 
 zależna od sterownika składnia połączenia. Zobacz [dokumentację PDO](http://www.php.net/manual/en/pdo.construct.php) 
-aby uzyskać więcej informacji. Poniżej znajduje się lista najczęściej używanych formatów DNS:
+aby uzyskać więcej informacji. Poniżej znajduje się lista najczęściej używanych formatów DSN:
 
    - SQLite: `sqlite:/scieżka/do/pliku/bazy`,
    - MySQL: `mysql:host=localhost;dbname=testdb`,
@@ -252,4 +252,4 @@ $sql='SELECT * FROM {{user}}';
 $users=$connection->createCommand($sql)->queryAll();
 ~~~
 
-<div class="revision">$Id: database.dao.txt 2890 2011-01-18 15:58:34Z qiang.xue $</div>
+<div class="revision">$Id: database.dao.txt 2890 2011-01-18 15:58:34Z qiang.xue $</div>

docs/guide/pl/database.migration.txt

@@ -140,7 +140,7 @@ class m101129_185401_create_news_table extends CDbMigration
 }
 ~~~
 
-Jednakże łatwiejszym sposobem uzyskania wparcia dla transakcyjności jest zaimplementowanie metody `safeUp()` zamiast `up()` oraz `safeDown()` zamiast`down()`. Na przykład:
+Jednakże łatwiejszym sposobem uzyskania wparcia dla transakcyjności jest zaimplementowanie metody `safeUp()` zamiast `up()` oraz `safeDown()` zamiast `down()`. Na przykład:
 
 ~~~
 [php]
@@ -211,7 +211,7 @@ yiic migrate down [step]
 
 gdzie opcjonalny parametr `step` określa jak wiele migracji zostanie odwróconych. Domyślnie przyjmuje wartość 1 co oznacza odwracanie ostatnio zaaplikowanej migracji.
 
-Tak jak wspominaliśmy wcześniej nie wszystkie migracje można odwracać. Próbując odwrócać nieodwracalną migrację otrzymamy wyjątek i proces odwracania zostanie przerwany. 
+Tak jak wspominaliśmy wcześniej nie wszystkie migracje można odwracać. Próbując odwrócić nieodwracalną migrację otrzymamy wyjątek i proces odwracania zostanie przerwany. 
 
 
 Poprawianie migracji
@@ -270,9 +270,9 @@ Polecenia migracji dostarczane są wraz z czterema opcjami, które mogą być ok
 
 * `connectionID`: łańcuch znaków, określający identyfikator komponentu bazy danych aplikacji. Domyślnie 'db'.
 
-* `templateFile`: łańcuch znaków, określający ścieżkę do pliku, który posłuży jako szablon kodu używany do generowania klas migracji. Należy go określić przy użyciu aliasu ścieżki (np. `application.migrations.template`). Jeśli nie został podany, wewnętrzny szablon zostanie użyty, W szablonie token `{ClassName}` zostanie zastąpiony aktualną nazwą klasy migrującej.
+* `templateFile`: łańcuch znaków, określający ścieżkę do pliku, który posłuży jako szablon kodu używany do generowania klas migracji. Należy go określić przy użyciu aliasu ścieżki (np. `application.migrations.template`). Jeśli nie został podany, wewnętrzny szablon zostanie użyty. W szablonie token `{ClassName}` zostanie zastąpiony aktualną nazwą klasy migrującej.
 
-W celu zdefiniowania tych opcji wykonaj polecenia migracji używając formatu
+W celu zdefiniowania tych opcji wykonaj polecenia migracji używając formatu:
 
 ~~~
 yiic migrate up --opcja1=wartość1 --opcja2=wartość2 ...

docs/guide/pl/extension.create.txt

@@ -19,7 +19,7 @@ twoje rozszerzenie dostępne zarówno dla projektów open-source jak i o kodzie
 powinieneś rozważyć używanie licencji takich jak BSD, MIT, itp. ale nie GPL, gdyż ta wymaga
 aby kod wywodził się od innego kodu open-source.
 
-Następnie, opiszemy jak utworzyć nowe rozszerzenie, odpowiednio do katergori
+Następnie, opiszemy jak utworzyć nowe rozszerzenie, odpowiednio do katergorii
 opisanych w [przeglądzie](/doc/guide/extension.overview). Opis ten również ma zastosowanie
 kiedy tworzysz komponenty do użytku we własnych projektach.
 
@@ -35,9 +35,9 @@ aplikacji](/doc/guide/basics.application#application-configuration))
 zostały nadane.
 
 Domyślnie, komponent aplikacji jest tworzony i inicalizowany tylko wtedy, gdy
-żądamy dostępu do nie go po raz pierwszy podczas obsługiwania żądania. Jeśli komponent
+żądamy dostępu do niego po raz pierwszy podczas obsługiwania żądania. Jeśli komponent
 aplikacji musi być utworzony zaraz po tym jak instancja aplikacji została utworzona, 
-powinien jedo ID zostać dodane do listy we właściwości [CApplication::preload].
+jego ID powino zostać dodane do listy we właściwości [CApplication::preload].
 
 
 Zachowanie (ang. Behavior)
@@ -176,7 +176,7 @@ class MyFilter extends CFilter
 ~~~
 
 Parametr `$filterChain` jest typu [CFilterChain] i zawiera informacje dotyczące 
-akcji, któa jest aktualnie filtrowana.
+akcji, która jest aktualnie filtrowana.
 
 Kontroler
 ----------
@@ -232,15 +232,15 @@ Moduł
 Zerknij do sekcji dotyczącej [modułów](/doc/guide/basics.module#creating-module) 
 aby zobaczyć jak utworzyć moduł.
 
-Ogólną wytyczną dla tworzenia moduły jest to, iż powinien on być samowystarczalny. 
+Ogólną wytyczną dla tworzenia modułu jest to, iż powinien on być samowystarczalny. 
 Pliki zasobów (takie jak CSS, JavaScript, obrazki), które są używane w module,
-powinny być dystrybuowane razem z modułem, a moduł powinien opublikować jest, tak
+powinny być dystrybuowane razem z modułem, a moduł powinien opublikować je, tak
 żeby były one dostępne dla internauty.
 
 
 Generyczne komponenty
 -----------------
-Tworzenie rozszerzeń generycznych komponentów to jak pianie klasy. Również tutaj, 
+Tworzenie rozszerzeń generycznych komponentów to jak pisanie klasy. Również tutaj, 
 komponent powinien być samowystarczalny, tak że może ony być w łatwy sposób
 wykorzystany przez innych deweloperów.
 

docs/guide/pl/extension.overview.txt

@@ -2,7 +2,7 @@ Rozszerzanie Yii
 ================
 
 Rozszerzanie Yii jest powszednią czynnością podczas dewelopmentu. Na przykład, gdy
-piszesz nowy kontroler, rozszerzasz Yii poprzez dziedziczenie po klasie jego 
+piszesz nowy kontroler, rozszerzasz Yii poprzez dziedziczenie po jego klasie 
 [CController]; gdy piszesz nowy widżet, dziedziczysz po [CWidget] lub istniejącej
 klasie widżetu. Jeśli rozszerzony kod jest przeznaczony do ponownego użycia przez
 innych deweloperów, nazywamy go *rozszerzeniem* (ang. extension).

docs/guide/pl/extension.use.txt

@@ -22,8 +22,8 @@ rozszerzeń, zgodnie z kategoriami opisanymi w [przeglądzie](/doc/guide/extensi
 Rozszerzenie Zii
 --------------
 
-Zanim rozpoczniemy opisuywanie jak używać rozszerzenia firm trzecich, chcielibyśmy przedstawić
-bibliotekę rozszerzeń Zii, która jest zestawem rozszerzeń oprogranowanych przez zespół  
+Zanim rozpoczniemy opisywanie jak używać rozszerzenia firm trzecich, chcielibyśmy przedstawić
+bibliotekę rozszerzeń Zii, która jest zestawem rozszerzeń oprogranowanych przez zespół 
 programistów Yii. Jest ona dołączana do każdego wydania.
 
 Podczas używanie rozszerzenia Zii, należy odnosić się do odpowiednich klas używając aliasu ścieżki
@@ -300,7 +300,7 @@ aby zobaczyć jak używać modułów.
 Komponenty generyczne
 -----------------
 Aby używać generycznych [komponentów](/doc/guide/basics.component), najpierw musimy 
-dołączyć ich plik klasy używając
+dołączyć ich plik klasy używając:
 
 ~~~
 Yii::import('ext.xyz.XyzClass');

docs/guide/pl/quickstart.first-app-yiic.txt

@@ -72,7 +72,7 @@ powinniśmy zobaczyć nowo dodanego użytkownika w liście.
 Powtarzaj powyższe kroki aby dodać więcej użytkowników. Zauważ, że strona z listą użytkowników
 będzie automatycznie podzielona na strony jeśli użytkowników jest zbyt wiele, by wyświetlić ich na jednej stronie.
 
-Jeśli zalogujemy się jako adminsitrator przy użyciu `admin/admsin`, możemy zobaczyć stronę zarządzania użytkownikami
+Jeśli zalogujemy się jako adminsitrator przy użyciu `admin/admin`, możemy zobaczyć stronę zarządzania użytkownikami
 za pomocą następującego adresu URL:
 
 ~~~

docs/guide/pl/test.fixture.txt

@@ -3,7 +3,7 @@ Konfiguracja testu
 
 Zautomatyzowane testy wykonywanie są wielokrotnie. Aby upewnić się, że proces testowania jest powtarzalny, chcielibyśmy uruchamiać testy w pewnym znanym stanie zwanym *fixture* (konfiguracją testu). Na przykład, aby przetestować funkcjonalność tworzenia postu w aplikacji blogowej, za każdym razem kiedy uruchamiamy testy, tabele zawierające odpowiednie dane o postach (np. tabela postu - `Post`, komentarzy - `Comment`) powinna zostać przywrócona do pewnego stałego stanu. [Dokumentacja PHPUnit](http://www.phpunit.de/manual/current/en/fixtures.html) dobrze opisuje tworzenie ogólnej konfiguracji testu. W tym rozdziale, opiszemy przede wszystkim jak utworzyć konfigurację testu bazodanowego, tak jak w opisanym powyżej przykładzie.
 
-Ustawianie konfiguracji testu bazodanowego jest najprawdopodobniej jedną z najbardziej czasochłonnych czynności w testowaniu aplikacji internegowej korzystającej z bazy danych. Yii dostarcza komponent aplikacji [CDbFixtureManager] aby złagodzić ten problem. Wykonuje on następujące czynności podczas uruchamiana zestawów testów:
+Ustawianie konfiguracji testu bazodanowego jest najprawdopodobniej jedną z najbardziej czasochłonnych czynności w testowaniu aplikacji internetowej korzystającej z bazy danych. Yii dostarcza komponent aplikacji [CDbFixtureManager] aby złagodzić ten problem. Wykonuje on następujące czynności podczas uruchamiana zestawów testów:
 
  * Przed uruchomieniem wszystkich testów, resetuje wszystkie tabele biorące udział w testach do znanych stanów.
  * Przed uruchomieniem pojedynczej metody testu, resetuje określone tabele biorące udział w teście do znanego stanu.
@@ -22,7 +22,7 @@ return array(
 );
 ~~~
 
-Następnie dostarczamy dane konfiguracji testu w katalogu `protected/tests/fixtures`. Katalog ten można zmienić poprzez skonfigurowanie właściwości [CDbFixtureManager::basePath] w konfiguracji aplikacji. Dane konfiguracji testu są zorganizowane jako kolekcja plików nazywanych plikami konfiguracji testów (ang. fixture files). Każdy plik konfiguracji testy zwraca tablicę reprezentującą inicjalne dane danych dla poszczególnych tabel. Nazwa pliku jest zgodna z nazwą tabeli. Poniżej znajduje się przykład pliku z danymi dla tabeli `Post` zachowanej w pliku `Post.php`:
+Następnie dostarczamy dane konfiguracji testu w katalogu `protected/tests/fixtures`. Katalog ten można zmienić poprzez skonfigurowanie właściwości [CDbFixtureManager::basePath] w konfiguracji aplikacji. Dane konfiguracji testu są zorganizowane jako kolekcja plików nazywanych plikami konfiguracji testów (ang. fixture files). Każdy plik konfiguracji testu zwraca tablicę reprezentującą inicjalne dane danych dla poszczególnych tabel. Nazwa pliku jest zgodna z nazwą tabeli. Poniżej znajduje się przykład pliku z danymi dla tabeli `Post` zachowanej w pliku `Post.php`:
 
 ~~~
 [php]
@@ -43,7 +43,7 @@ return array(
 );
 ~~~
 
-Jak możemy zauwazyc, dwa wiersze danych sa zwracane w powyższym kodzie. Każdu wiersz jest reprezentowany jako asocjacyjna tablica, której klucze są nazwami kolumn i których wartości są odpowiadającymi im wartościami kolumn. Dodatkowo, każdy wiersz jest indeksowany poprzez łańcuch znaków (np. `sample1`, `sample2`) nazywany  *aliasem wiersza* (ang. row alias). Później, podczas pisania skryptów testów, możemy wygodnie odwołać się do wiersza przez jego alias. Opiszemy to szczegółowo w następnym rozdziale.
+Jak możemy zauważyć, dwa wiersze danych są zwracane w powyższym kodzie. Każdu wiersz jest reprezentowany jako asocjacyjna tablica, której klucze są nazwami kolumn i których wartości są odpowiadającymi im wartościami kolumn. Dodatkowo, każdy wiersz jest indeksowany poprzez łańcuch znaków (np. `sample1`, `sample2`) nazywany  *aliasem wiersza* (ang. row alias). Później, podczas pisania skryptów testów, możemy wygodnie odwołać się do wiersza przez jego alias. Opiszemy to szczegółowo w następnym rozdziale.
 
 Z pewnością zauważyłeś, że nie określamy wartości kolumny `id` w powyższej konfiguracji testu. Dzieje się tak, ze względu na to, że kolumna `id` określona jest jako samoprzyrastający (ang. auto-incremental) klucz główny, którego wartość będzie wypełniona, jeśli wstawimy nowy wiersz.
 
@@ -53,7 +53,7 @@ Czasami, nie chcemy zresetować każdej tabeli, która posiada konfigurację tes
 
 Możliwe też, że nie chcemy domyślnego sposobu resetowania tabeli, np. obcinania i wstawiania do niej danych konfiuracji testu. Jeśli jest tak w naszym przypadku, możemy napisać inicjalizacyjny skrypt, dla określonego pliku konfiguracji testu. Skrypt musi posiadać nazwę zgodną z tabelą zakończoną łańcuchem `.init.php`. Na przykład, inicjalizacyjnym skryptem dla tabeli `Post` będzie `Post.init.php`. Gdy menedżer [CDbFixtureManager] widzi ten skrypt, wykona go zamiast używania domyślnego sposobu resetowania tabeli.
 
-> Tip|Wskazówka: Posiadanie wieli plików konfiguracji testu może zwiększyć drastycznie czas testowania. Z tych powodów, powinieneś jedynie tworzyć pliki konfiguracji testu dla tych tabel, których zawartość może ulec zmianie podczas testu. Tabele, które służy wyłącznie do przeglądania, nie zmieniają się i dlatego nie potrzebują pliku konfiguracji testu.
+> Tip|Wskazówka: Posiadanie wieli plików konfiguracji testu może zwiększyć drastycznie czas testowania. Z tych powodów, powinieneś jedynie tworzyć pliki konfiguracji testu dla tych tabel, których zawartość może ulec zmianie podczas testu. Tabele, które służą wyłącznie do przeglądania, nie zmieniają się i dlatego nie potrzebują pliku konfiguracji testu.
 
 Następnie dwa rozdziały opiszą jak używać konfiguracji testu zarządzanej przez [CDbFixtureManager] w testach jednostkowych i funkcjonalnych.