[PL] Some typos corrections and synchro with English version.

4 files changed, 11 insertions, 11 deletions

diff --git a/demos/quickstart/protected/pages/Fundamentals/pl/Controls.page b/demos/quickstart/protected/pages/Fundamentals/pl/Controls.page
index 3b1cff2b..94974de4 100644
--- a/demos/quickstart/protected/pages/Fundamentals/pl/Controls.page
+++ b/demos/quickstart/protected/pages/Fundamentals/pl/Controls.page
@@ -19,12 +19,12 @@ gdzie właściwość <tt>Controls</tt> wskazuje na kolekcję kontrolek bedących
 

 <h2 id="803">Identyfikacja kontrolki</h2>

 <p id="120131" class="block-content">

-Każda kontrolka ma właściwość <tt>ID</tt>, która jednoznacznie identyfikuje ją samą spośród jej rodzeństwa. W dodatku każda kontrolka posiada właściwość <tt>UniqueID</tt> oraz <tt>ClientID</tt>, która może zostać użyta do identyfikacji "globalnej" kontrolki w drzewku gdzie znajduje się ta kontrolka. Właściwości <tt>UniqueID</tt> oraz <tt>ClientID</tt> są bardzo podobne. Pierwsza jest używana przez framework do określenia położenia odpowiedniej (!#corresponding) kontrolki w drzewku, druga jest głównie używana po stronie klienta jako ID w tagach HTML. Ogólnie rzecz ujmując nie powinno się polegać na zewnętrznym (!#explicit) formacie <tt>UniqueID</tt> lub <tt>ClientID</tt>.

+Każda kontrolka ma właściwość <tt>ID</tt>, która jednoznacznie identyfikuje ją samą spośród jej rodzeństwa. W dodatku każda kontrolka posiada właściwość <tt>UniqueID</tt> oraz <tt>ClientID</tt>, która może zostać użyta do identyfikacji "globalnej" kontrolki w drzewku gdzie znajduje się ta kontrolka. Właściwości <tt>UniqueID</tt> oraz <tt>ClientID</tt> są bardzo podobne. Pierwsza jest używana przez framework do określenia położenia odpowiedniej kontrolki w drzewku, druga jest głównie używana po stronie klienta jako ID w tagach HTML. Ogólnie rzecz ujmując nie powinno się polegać na tak sprecyzowanym formacie <tt>UniqueID</tt> lub <tt>ClientID</tt>.

 </p>

 

 <h2 id="804">Kontenery nazw (ang. naming containers)</h2>

 <p id="120132" class="block-content">

-Każda kontrolka posiada kontener nazw, który jest kontrolką tworzącą unikalną przestrzeń nazw dla rozróżnienie pomiędzy kontrolkami o tych samych <tt>ID</tt>. Na przykład kontrolka <tt>TRepeater</tt> tworzy wiele (!#?items), które posiadają kontrolki-dzieci o tych samych <tt>ID</tt>. Aby rozróżnić te kontrolki-dzieci, każdy (!#?item) służy jako kontener nazw serves. Dzięki temu, kontrolka-dziecko może zostać jednoznacznie zidentyfikowana używając <tt>ID</tt> swojego kontenera nazw razem z swoim własnym <tt>ID</tt>. Powinieneś teraz zrozumieć, że właściwości <tt>UniqueID</tt> i <tt>ClientID</tt> bazują (wynikają?) na kontenerze nazw.

+Każda kontrolka posiada kontener nazw, który jest kontrolką tworzącą unikalną przestrzeń nazw dla rozróżnienie pomiędzy kontrolkami o tych samych <tt>ID</tt>. Na przykład kontrolka <tt>TRepeater</tt> tworzy wiele pozycji, które posiadają kontrolki-dzieci o tych samych <tt>ID</tt>. Aby rozróżnić te kontrolki-dzieci, każda pozycja służy jako kontener nazw. Dzięki temu, kontrolka-dziecko może zostać jednoznacznie zidentyfikowana używając <tt>ID</tt> swojego kontenera nazw razem z swoim własnym <tt>ID</tt>. Powinieneś teraz zrozumieć, że właściwości <tt>UniqueID</tt> i <tt>ClientID</tt> bazują (wynikają?) na kontenerze nazw.

 </p>

 <p id="120133" class="block-content">

 Kontrolka może służyć jako kontener naz jeśli implementuje interfejs <tt>INamingContainer</tt>.

@@ -35,7 +35,7 @@ Kontrolka może służyć jako kontener naz jeśli implementuje interfejs <tt>IN
 HTTP jest protokołem bezstanowym, co oznacza, że nie dostarcza on funkjonalności wspierającej kontynuowanie interakcji pomiędzy użytkownikiem a serwerem. Każde żądanie (ang. request) jest rozpatrywane jako pojedyńcze i niezależne w stosunku do innego żądania. Jednakże, aplikacja webowa często potrzebuje wiedzieć co użytkownik zrobił w poprzednich żądaniach. Dlatego wprowadzono sesje by pomóc zapamiętać te informacje o stanie.

 </p>

 <p id="120135" class="block-content">

-PRADO zapożycza koncept stanu widoku oraz stanu kontrolki z ASP.NET Microsoftu by dostarczać dodatkowego mechanizmu ??? programowania (!#? stateful programming mechanism). Wartość zachowana w stanie widoku lub stanie kontrolki może być dostepna w następnym żądaniu jeśli nowe żądanie pochodzi od (!#?form submissions) (nazywanej postback'iem) do tej samej strony przez tego samego użytkownika. Różnica pomiędzy stanem widoku a stanem kontrolki wynika z tego iż pierwsza może zostać wyłączona a druga nie.

+PRADO zapożycza koncept stanu widoku oraz stanu kontrolki z ASP.NET Microsoftu by dostarczać dodatkowego stanowego mechanizmu programowania (ang. stateful programming mechanism). Wartość zachowana w stanie widoku lub stanie kontrolki może być dostępna w następnym żądaniu jeśli nowe żądanie pochodzi od wysłania formularza (ang. form submissions) (nazywanej postback'iem) do tej samej strony przez tego samego użytkownika. Różnica pomiędzy stanem widoku a stanem kontrolki wynika z tego iż pierwsza może zostać wyłączona a druga nie.

 </p>

 <p id="120136" class="block-content">

 Stan widoku i stan kontrolki są zaimplementowane w <tt>TControl</tt>. Są one zazwyczaj używane do zdefiniowania różnych właściwościu kontrolki. By zapisać i przywrócić wartości ze stanu widoku lub stanu kontrolki, należy użyć następujących sposobów:

diff --git a/demos/quickstart/protected/pages/Fundamentals/pl/Modules.page b/demos/quickstart/protected/pages/Fundamentals/pl/Modules.page
index 747f865d..f92b0eb3 100644
--- a/demos/quickstart/protected/pages/Fundamentals/pl/Modules.page
+++ b/demos/quickstart/protected/pages/Fundamentals/pl/Modules.page
@@ -2,7 +2,7 @@
 

 <h1 id="1001">Moduły (ang. modules)</h1>

 <p id="140141" class="block-content">

-Moduł jest instancją klasy implementującej interfejs <tt>IModule</tt>. Moduł jest (~#?commonly) zaprojektowany by dostarczać określonej funkcjonalności, która może być podłączona do aplikacji PRADO i dzielona wśród wszystkich komponentów aplikacji.

+Moduł jest instancją klasy implementującej interfejs <tt>IModule</tt>. Moduł jest zazwyczaj zaprojektowany by dostarczać określonej funkcjonalności, która może być podłączona do aplikacji PRADO i dzielona wśród wszystkich komponentów aplikacji.

 </p>

 <p id="140142" class="block-content">

 PRADO używa konfiguracji aby określić kiedy załadować moduł, jaki rodzaj modułu i jak zainicjalizować załadowane moduły. Deweloper może zastąpić zródłowe (ang. core) moduły własnymi implementacjami poprzez konfigurację aplikacji lub może napisać nowe moduły by dostarczać dodatkowe funkcjonalności. Na przykład można stworzyć moduł, który będzie dostarczał wspólną logikę baz danych dla jednej lub więcej stron. Aby dowiedzieć się więcej zobacz sekcję <a href="?page=Configurations.Overview">konfiguracja</a>.

@@ -32,7 +32,7 @@ Moduł sesji enkapsuluje funkcjonalność związaną z zarządzaniem sesji użyt
 <a name="error"></a>

 <h2 id="1005">moduł zarządzania błędami (ang. error handler module)</h2>

 <p id="140147" class="block-content">

-Moduł zarządzzania błędami jest użuwany by przechwycić i obsłużyć wszystkie przypadki/warunki (!#ang. condition) błędów w aplikacji. PRADO używa <tt>TErrorHandler</tt> jako moduł zarządzania błędami. Przechwytuje on wszystkie ostrzeżenia PHP (ang. warnings), wiadomości (ang. notices) oraz wyjątki (ang. exceptions) i wyświetla w odpowiedniej formie użytkownikowi końcowemu. Moduł zarządzania błędami jest dostępny poprzez właściwość <tt>ErrorHandler</tt> instancji aplikacji.

+Moduł zarządzzania błędami jest użuwany by przechwycić i obsłużyć wszystkie przypadki błędów w aplikacji. PRADO używa <tt>TErrorHandler</tt> jako moduł zarządzania błędami. Przechwytuje on wszystkie ostrzeżenia PHP (ang. warnings), wiadomości (ang. notices) oraz wyjątki (ang. exceptions) i wyświetla w odpowiedniej formie użytkownikowi końcowemu. Moduł zarządzania błędami jest dostępny poprzez właściwość <tt>ErrorHandler</tt> instancji aplikacji.

 </p>

 

 <a name="custom"></a>

@@ -41,7 +41,7 @@ Moduł zarządzzania błędami jest użuwany by przechwycić i obsłużyć wszys
 PRADO zostało wydane z większą ilością modułów niż wymienione moduły źródłowe. PRADO zawiera moduły keszujące (<tt>TSqliteCache</tt> oraz <tt>TMemCache</tt>), moduły zarządzające użytkownikami (<tt>TUserManager</tt>), moduły autentykacji i autoryzacji (<tt>TAuthManager</tt>), itd.

 </p>

 <p id="140149" class="block-content">

-Kiedy wystąpi żądanie <tt>TPageService</tt> ładowane są także określone moduły dla serwisu stron, włączając menedżer (!#? assets manager) (<tt>TAssetManager</tt>), menedżer szablonów (<tt>TTemplateManager</tt>), menedżer tematów/skórek (ang. theme/skin manager) (<tt>TThemeManager</tt>).

+Kiedy wystąpi żądanie <tt>TPageService</tt> ładowane są także określone moduły dla serwisu stron, włączając menedżer elementów aktywnych (ang. assets manager) (<tt>TAssetManager</tt>), menedżer szablonów (<tt>TTemplateManager</tt>), menedżer tematów/skórek (ang. theme/skin manager) (<tt>TThemeManager</tt>).

 </p>

 <p id="140150" class="block-content">

 Dodatkowe moduły oraz moduły źródłowe są konfigurowalne poprzez <a href="?page=Configurations.Overview">konfigurację</a>.

diff --git a/demos/quickstart/protected/pages/Fundamentals/pl/Pages.page b/demos/quickstart/protected/pages/Fundamentals/pl/Pages.page
index e55509c2..e50df71f 100644
--- a/demos/quickstart/protected/pages/Fundamentals/pl/Pages.page
+++ b/demos/quickstart/protected/pages/Fundamentals/pl/Pages.page
@@ -3,7 +3,7 @@
 <h1 id="901">Strony (ang. pages)</h1>

 <p id="130137" class="block-content">

 Strony są najwyżej umiejscowionymi w hierarchi kontrolkamki, które nie posiadają rodzica.

-Prezentacja strony jest bezpośrednio wyświetlana użytkownikowi końcowemu. Użytkownicy posiadają dostęp do strony poprzez wysłanie żądanie do serwisu strony (!#Users access pages by sending  page service requests).

+Prezentacja strony jest bezpośrednio wyświetlana użytkownikowi końcowemu. Użytkownicy posiadają dostęp do strony poprzez wysłanie żądanie do serwisu strony (ang. sending page service requests).

 </p>

 <p id="130138" class="block-content">

 Każda strona musi posiadać plik <a href="?page=Configurations.Templates1">szablonu</a>. Musi posiadać on rozszerzenie <tt>.page</tt>. Nazwa pliku (bez rozszerzenia) jest nazwą strony. PRADO będzie próbować znaleźć plik klasy strony w  katalogu zawierającym szablon strony. Taki plik klasy strony musi posiadać tą samą nazwę (z rozszerzeniem <tt>.php</tt>) jak plik szablonu. Jeśli klasa nie zostanie znaleziona, strona skorzysta z klasy <tt>TPage</tt>.

@@ -11,14 +11,14 @@ Każda strona musi posiadać plik <a href="?page=Configurations.Templates1">szab
 

 <h2 id="902">PostBack</h2>

 <p id="130139" class="block-content">

-Wysłanie formularza jest nazywane <i>postback</i> jeśli wysłanie następuje do strony zawierającej formularz. Postback może być postrzegany jako zdarzenie po stronie klienta, wywoływane przez użytkownika. PRADO będzie próbowało zidentyfikować, która kontrolka po stronie serwera jest odpowiedzialna za zdarzenie postblack. Jeśli znajdzie taką, np. przykład <tt>TButton</tt>, nazywać ją będziemy senderem zdarzenia postback, który przetłumaczy (przetworzy?) zdarzenie postback na pewne specyficzne zdarzenia po stronie serwera (np. zdarzenia <tt>OnClick</tt> i <tt>OnCommand</tt> dla <tt>TButton</tt>).

+Wysłanie formularza jest nazywane <i>postback</i> jeśli wysłanie następuje do strony zawierającej formularz. Postback może być postrzegany jako zdarzenie po stronie klienta, wywoływane przez użytkownika. PRADO będzie próbowało zidentyfikować, która kontrolka po stronie serwera jest odpowiedzialna za zdarzenie postblack. Jeśli znajdzie taką, np. przykład <tt>TButton</tt>, nazywać ją będziemy senderem zdarzenia postback, który przetłumaczy zdarzenie postback na pewne specyficzne zdarzenia po stronie serwera (np. zdarzenia <tt>OnClick</tt> i <tt>OnCommand</tt> dla <tt>TButton</tt>).

 

 </p>

 

 <h2 id="903">Cykl życia strony (ang. page lifecycles)</h2>

 <p id="130140" class="block-content">

-Zrozumienie cyklu życia strony jest niezbędne by zrozumieć(!#?grasp) programowanie w PRADO.

-Cykl życia strony odwołuje się do stanów (!#? transitions) strony, kiedy jest ona dostarczana użytkownikowi końcowemu. Może on (cykl) być przedstawiony za pomocą następującej ... stanów (!#? statechart):

+Zrozumienie cyklu życia strony jest kluczowe by zrozumieć istotę programowania w PRADO.

+Cykl życia strony odwołuje się do stanów przejściowych strony, gdy jest ona dostarczana użytkownikowi końcowemu. Może on (cykl) być przedstawiony za pomocą następującej tablicy stanów:

 <img src="<%~lifecycles.gif %>" />

 </p>

 

diff --git a/demos/quickstart/protected/pages/Fundamentals/pl/Services.page b/demos/quickstart/protected/pages/Fundamentals/pl/Services.page
index 31144916..9c23e459 100644
--- a/demos/quickstart/protected/pages/Fundamentals/pl/Services.page
+++ b/demos/quickstart/protected/pages/Fundamentals/pl/Services.page
@@ -5,7 +5,7 @@
 Serwis jest instancją klasy implementującej interfejs <tt>IService</tt>. Każdy rodzaj serwisu przetwarza specyficzny typ żądania użytkownika. Na przykład serwis strony (ang. page service) odpowiada na żądania użytkownika dla stron PRADO.

 </p>

 <p id="150152" class="block-content">

-Serwis jest jednoznacznie identyfikowany poprzez swoją właściwość <tt>ID</tt>. Domyślnie kiedy <tt>THttpRequest</tt> jest używany jako <a href="?page=Fundamentals.Modules#request">moduł żądania</a> (ang. request module), nazwy zmiennych GET są używane by zidentyfikować serwis żadany przez użytkownika. Jeśli nazwa zmiennej GET zgadza się z jakimś <tt>ID</tt> serwisu, żądanie jest (!#? considered) dla tego serwisu oraz wartość parametru GET jest przekazywana jako parametr serwisu. Dla serwisu strony nazwą zmiennej GET musi być <tt>page</tt>. Na przykład następujący adres URL żadą strony <tt>Fundamentals.Services</tt>,

+Serwis jest jednoznacznie identyfikowany poprzez swoją właściwość <tt>ID</tt>. Domyślnie kiedy <tt>THttpRequest</tt> jest używany jako <a href="?page=Fundamentals.Modules#request">moduł żądania</a> (ang. request module), nazwy zmiennych GET są używane by zidentyfikować serwis żadany przez użytkownika. Jeśli nazwa zmiennej GET zgadza się z jakimś <tt>ID</tt> serwisu, żądanie jest przetwarzane przez ten serwis oraz wartość parametru GET jest przekazywana jako parametr serwisu. Dla serwisu strony nazwą zmiennej GET musi być <tt>page</tt>. Na przykład następujący adres URL żadą strony <tt>Fundamentals.Services</tt>,

 <com:TTextHighlighter Language="none" CssClass="source block-content" id="code_150069">

 http://hostname/index.php?page=Fundamentals.Services

 </com:TTextHighlighter>