- sync up to r15558

git-svn-id: http://framework.zend.com/svn/framework/standard/trunk@15806 44c647ce-9c0f-0410-b52a-842ac1e357ba

documentation/manual/pl/module_specs/Zend_Acl-Advanced.xml

@@ -1,3 +1,5 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- Reviewed: no -->
 <sect1 id="zend.acl.advanced">
 
     <title>Zaawansowane użycie</title>
@@ -7,24 +9,25 @@
         <title>Trwałe przechowywanie danych ACL</title>
 
         <para>
-        Klasa Zend_Acl została zaprojektowana w taki sposób, aby nie wymagała
-        żadnej szczególnej technologii backendu do przechowywania danych ACL
-        takiej jak np. baza danych czy serwer buforujący. Kompletna
-        implementacja w PHP pozwala na podstawie Zend_Acl budować dostosowane
-        narzędzia administracyjne, które są relatywnie łatwe oraz elastyczne.
-        Wiele sytuacji wymaga pewnej formy interaktywnego zarządzania ACL, a
-        Zend_Acl zapewnia metody do ustawiania oraz odpytywania kontroli
-        dostępu aplikacji.
+            Klasa <classname>Zend_Acl</classname> została zaprojektowana w taki 
+            sposób, aby nie wymagała żadnej szczególnej technologii backendu do 
+            przechowywania danych <acronym>ACL</acronym> takiej jak np. baza 
+            danych czy serwer buforujący. Kompletna implementacja w 
+            <acronym>PHP</acronym> pozwala na podstawie <acronym>Zend_Acl</acronym> 
+            budować dostosowane narzędzia administracyjne, które są relatywnie łatwe 
+            oraz elastyczne. Wiele sytuacji wymaga pewnej formy interaktywnego 
+            zarządzania <acronym>ACL</acronym>, a <classname>Zend_Acl</classname> 
+            zapewnia metody do ustawiania oraz odpytywania kontroli dostępu aplikacji.
         </para>
 
         <para>
-        Przechowywanie danych ACL jest zadaniem pozostawionym dla programisty,
-        dlatego, że przykłady użycia mogą się bardzo różnić w rozmaitych
-        sytuacjach. Ponieważ możliwe jest serializowanie Zend_Acl, obiekty ACL
-        mogą być serializowane za pomocą funkcji PHP
-        <ulink url="http://php.net/serialize"><code>serialize()</code></ulink>,
-        a wyniki mogą być przechowane tam gdzie określi to programista, na
-        przykład w pliku, w bazie danych lub w mechanizmie buforowania.
+            Przechowywanie danych <acronym>ACL</acronym> jest zadaniem pozostawionym 
+            dla programisty, dlatego, że przykłady użycia mogą się bardzo różnić w rozmaitych
+            sytuacjach. Ponieważ możliwe jest serializowanie <classname>Zend_Acl</classname>, 
+            obiekty <acronym>ACL</acronym> mogą być serializowane za pomocą funkcji 
+            <acronym>PHP</acronym> <ulink url="http://php.net/serialize"><methodname>serialize()</methodname></ulink>,
+            a wyniki mogą być przechowane tam gdzie określi to programista, na
+            przykład w pliku, w bazie danych lub w mechanizmie buforowania.
         </para>
 
     </sect2>
@@ -34,23 +37,23 @@
         <title>Tworzenie warunkowych reguł ACL z zapewnieniami</title>
 
         <para>
-        Czasem reguła przyznawania lub zabraniania dostępu roli do zasobu nie
-        powinna być absolutna, ale powinna być oparta na różnych kryteriach.
-        Na przykład załóżmy, że pewien dostęp powinien być przyznany, ale
-        jedynie między godziną 8:00 a 17:00. Innym przykładem może być zabranie
-        dostępu adresom IP, które zostały oznaczone jako źródło nadużyć.
-        Zend_Acl ma wbudowaną obsługę implementowania reguł opartych na
-        dowolnych warunkach, wedle potrzeb programisty.
+            Czasem reguła przyznawania lub zabraniania dostępu roli do zasobu nie
+            powinna być absolutna, ale powinna być oparta na różnych kryteriach.
+            Na przykład załóżmy, że pewien dostęp powinien być przyznany, ale
+            jedynie między godziną 8:00 a 17:00. Innym przykładem może być zabranie
+            dostępu adresom IP, które zostały oznaczone jako źródło nadużyć.
+            <classname>Zend_Acl</classname> ma wbudowaną obsługę implementowania 
+            reguł opartych na dowolnych warunkach, wedle potrzeb programisty.
         </para>
 
         <para>
-        Zend_Acl zapewnia obsługę warunkowych reguł za pomocą interfejsu
-        <code>Zend_Acl_Assert_Interface</code>. W celu użycia interfejsu
-        zapewnień reguł, programista pisze klasę, ktora implementuje metodę
-        <code>assert()</code> interfejsu:
+            <classname>Zend_Acl</classname> zapewnia obsługę warunkowych reguł za 
+            pomocą interfejsu <classname>Zend_Acl_Assert_Interface</classname>. 
+            W celu użycia interfejsu zapewnień reguł, programista pisze klasę, 
+            ktora implementuje metodę <methodname>assert()</methodname> interfejsu:
         </para>
 
-        <programlisting role="php"><![CDATA[
+        <programlisting language="php"><![CDATA[
 class CleanIPAssertion implements Zend_Acl_Assert_Interface
 {
     public function assert(Zend_Acl $acl,
@@ -66,43 +69,41 @@ class CleanIPAssertion implements Zend_Acl_Assert_Interface
         // ...
     }
 }
-]]>
-        </programlisting>
+]]></programlisting>
 
         <para>
-        Kiedy klasa zapewnień jest już dostępna, programista musi przekazać
-        klasę zapewnień kiedy przypisuje regułę warunkową. Reguła, która jest
-        utworzona z klasą zapewnienia będzie jedynie stosowana wtedy, gdy metoda
-        zapewnienia zwróci logiczną wartośc true.
+            Kiedy klasa zapewnień jest już dostępna, programista musi przekazać
+            klasę zapewnień kiedy przypisuje regułę warunkową. Reguła, która jest
+            utworzona z klasą zapewnienia będzie jedynie stosowana wtedy, gdy metoda
+            zapewnienia zwróci logiczną wartośc <constant>TRUE</constant>.
         </para>
 
-        <programlisting role="php"><![CDATA[
+        <programlisting language="php"><![CDATA[
 $acl = new Zend_Acl();
 $acl->allow(null, null, null, new CleanIPAssertion());
-]]>
-        </programlisting>
+]]></programlisting>
 
         <para>
-        Powyższy kod tworzy warunkową regułę dostępu, ktora pozwala na dostęp
-        do wszystkich przywilejów do wszystkich zasobów dla wszystkich ról, z
-        wyjątkiem adresów IP, będących na czarnej liście. Jeśli żądanie pochodzi
-        z adresu IP, który nie jest uznany jako "czysty", wtedy reguła nie ma
-        zastosowania. Z tego względu, że reguła ma zastosowanie do wszystkich
-        ról, zasobów oraz przywilejów, zablokowany adres IP będzie miał
-        zabroniony cały dostęp. Jest to specjalny przypadek i powinien być
-        zrozumiany tak, że we  wszystkich innych przypadkach (np., tam gdzie
-        specyficzna rola, zasób lub przywilej są określone w regule), nieudane
-        zapewnienie spowoduje, że reguła nie zostanie zastosowana i inne reguły
-        powinny być zastosowane aby określić czy dostęp jest dozwolony czy
-        zabroniony.
+            Powyższy kod tworzy warunkową regułę dostępu, ktora pozwala na dostęp
+            do wszystkich przywilejów do wszystkich zasobów dla wszystkich ról, z
+            wyjątkiem adresów IP, będących na czarnej liście. Jeśli żądanie pochodzi
+            z adresu IP, który nie jest uznany jako "czysty", wtedy reguła nie ma
+            zastosowania. Z tego względu, że reguła ma zastosowanie do wszystkich
+            ról, zasobów oraz przywilejów, zablokowany adres IP będzie miał
+            zabroniony cały dostęp. Jest to specjalny przypadek i powinien być
+            zrozumiany tak, że we  wszystkich innych przypadkach (np., tam gdzie
+            specyficzna rola, zasób lub przywilej są określone w regule), nieudane
+            zapewnienie spowoduje, że reguła nie zostanie zastosowana i inne reguły
+            powinny być zastosowane aby określić czy dostęp jest dozwolony czy
+            zabroniony.
         </para>
 
         <para>
-        Metoda <code>assert()</code> obiektu zapewnienia jest przekazywana do
-        ACL, roli, zasobu, oraz przywileju do których stosuje się zapytanie
-        autoryzacyjne (np., <code>isAllowed()</code>), w celu dostarczenia
-        kontekstu dla klasy zapewnienia aby określić warunki zapewnienia tam
-        gdzie są one potrzebne.
+            Metoda <methodname>assert()</methodname> obiektu zapewnienia jest przekazywana do
+            ACL, roli, zasobu, oraz przywileju do których stosuje się zapytanie
+            autoryzacyjne (np., <methodname>isAllowed()</methodname>), w celu dostarczenia
+            kontekstu dla klasy zapewnienia aby określić warunki zapewnienia tam
+            gdzie są one potrzebne.
         </para>
 
     </sect2>

documentation/manual/pl/module_specs/Zend_Acl-Refining.xml

@@ -1,3 +1,5 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- Reviewed: no -->
 <sect1 id="zend.acl.refining">
 
     <title>Analiza kontroli dostępu</title>
@@ -7,50 +9,50 @@
         <title>Precyzyjna kontrola dostępu</title>
 
         <para>
-        Podstawowe ACL zdefiniowane w
-        <link linkend="zend.acl.introduction">poprzedniej sekcji</link> pokazują
-        jakie rozmaite uprawnienia mogą być dozwolone dla ACL (dla wszystkich
-        zasobów). W praktyce, kontrola dostępu ma skłonność do posiadania
-        wyjątków od reguł oraz różnych stopni skomplikowania. Zend_Acl pozwoli
-        ci przeprowadzić te analizy w przystępny i elastyczny sposób.
+            Podstawowe <acronym>ACL</acronym> zdefiniowane w
+            <link linkend="zend.acl.introduction">poprzedniej sekcji</link> pokazują
+            jakie rozmaite uprawnienia mogą być dozwolone dla <acronym>ACL</acronym> 
+            (dla wszystkich zasobów). W praktyce, kontrola dostępu ma skłonność do 
+            posiadania wyjątków od reguł oraz różnych stopni skomplikowania. 
+            <classname>Zend_Acl</classname> pozwoli ci przeprowadzić te analizy 
+            w przystępny i elastyczny sposób.
         </para>
 
         <para>
-        W przykładowej aplikacji CMS, zostało zdecydowane, że podczas gdy
-        grupa 'staff' pokryje potrzeby większości użytkowników, potrzebna jest
-        jeszcze jedna nowa grupa 'marketing', która wymaga dostępu do
-        newslettera oraz ostatnich nowości w CMS. Ta grupa jest naprawdę
-        samowystarczalna i będzie dawała możliwość publikowania oraz
-        archiwizowania zarówno newsletterów jak i ostatnich nowości.
+            W przykładowej aplikacji <acronym>CMS</acronym>, zostało zdecydowane, 
+            że podczas gdy grupa 'staff' pokryje potrzeby większości użytkowników, 
+            potrzebna jest jeszcze jedna nowa grupa 'marketing', która wymaga dostępu 
+            do newslettera oraz ostatnich nowości w <acronym>CMS</acronym>. Ta grupa 
+            jest naprawdę samowystarczalna i będzie dawała możliwość publikowania oraz
+            archiwizowania zarówno newsletterów jak i ostatnich nowości.
         </para>
 
         <para>
-        Dodatkowo, zażądano także aby grupa 'staff' miała pozwolenie do
-        przeglądania nowości, ale żeby nie mogła przeglądać ostatnich nowości.
-        Dodatkowo, archiwizowanie 'zapowiedzi' nie powinno być w ogóle możliwe
-        (nawet przez administratora), ponieważ ich okres ważności to 1-2 dni.
+            Dodatkowo, zażądano także aby grupa 'staff' miała pozwolenie do
+            przeglądania nowości, ale żeby nie mogła przeglądać ostatnich nowości.
+            Dodatkowo, archiwizowanie 'zapowiedzi' nie powinno być w ogóle możliwe
+            (nawet przez administratora), ponieważ ich okres ważności to 1-2 dni.
         </para>
 
         <para>
-        Wpierw przejrzymy rejestr ról, aby rozważyć te zmiany. Określiliśmy, że
-        grupa 'marketing' ma te same podstawowe uprawnienia co grupa 'staff',
-        więc zdefiniujemy grupę 'marketing' w taki sposób, aby dziedziczyła
-        uprawnienia od grupy 'staff':
+            Wpierw przejrzymy rejestr ról, aby rozważyć te zmiany. Określiliśmy, że
+            grupa 'marketing' ma te same podstawowe uprawnienia co grupa 'staff',
+            więc zdefiniujemy grupę 'marketing' w taki sposób, aby dziedziczyła
+            uprawnienia od grupy 'staff':
         </para>
 
-        <programlisting role="php"><![CDATA[
+        <programlisting language="php"><![CDATA[
 // Nowa grupa marketing dziedziczy uprawnienia od grupy staff
 $acl->addRole(new Zend_Acl_Role('marketing'), 'staff');
-]]>
-        </programlisting>
+]]></programlisting>
 
         <para>
-        Zauważ, że powyższa kontrola dostępu odnosi się do określonych zasobów
-        (np., "newsletter", "ostatnie nowości", "zapowiedzi"). Teraz dodamy te
-        zasoby:
+            Zauważ, że powyższa kontrola dostępu odnosi się do określonych zasobów
+            (np., "newsletter", "ostatnie nowości", "zapowiedzi"). Teraz dodamy te
+            zasoby:
         </para>
 
-        <programlisting role="php"><![CDATA[
+        <programlisting language="php"><![CDATA[
 // Utwórz zasoby dla reguł
 
 // newsletter
@@ -64,15 +66,14 @@ $acl->add(new Zend_Acl_Resource('latest'), 'news');
 
 // zapowiedzi
 $acl->add(new Zend_Acl_Resource('announcement'), 'news');
-]]>
-        </programlisting>
+]]></programlisting>
 
         <para>
-        Teraz prostą sprawą jest zdefiniowanie bardziej specyficznych reguł
-        na docelowych obszarach ACL:
+            Teraz prostą sprawą jest zdefiniowanie bardziej specyficznych reguł
+            na docelowych obszarach <acronym>ACL</acronym>:
         </para>
 
-        <programlisting role="php"><![CDATA[
+        <programlisting language="php"><![CDATA[
 // Grupa marketing musi mieć możliwość publikowania i archiwizowania
 // newsletterów oraz ostatnich nowości
 $acl->allow('marketing',
@@ -85,14 +86,15 @@ $acl->deny('staff', 'latest', 'revise');
 
 // Każdy (włączając w to administratorów) ma zabroniony dostęp do
 // archiwizowania zapowiedzi
-$acl->deny(null, 'announcement', 'archive');]]>
-        </programlisting>
+$acl->deny(null, 'announcement', 'archive');
+]]></programlisting>
 
         <para>
-        Teraz możemy przeprowadzić zapytanie do ACL z uwzględnieniem ostatnich zmian:
+            Teraz możemy przeprowadzić zapytanie do <acronym>ACL</acronym> z 
+            uwzględnieniem ostatnich zmian:
         </para>
 
-        <programlisting role="php"><![CDATA[
+        <programlisting language="php"><![CDATA[
 echo $acl->isAllowed('staff', 'newsletter', 'publish') ?
      "allowed" : "denied";
 // zabronione
@@ -124,8 +126,7 @@ echo $acl->isAllowed('editor', 'announcement', 'archive') ?
 echo $acl->isAllowed('administrator', 'announcement', 'archive') ?
      "allowed" : "denied";
 // zabronione
-]]>
-        </programlisting>
+]]></programlisting>
 
     </sect2>
 
@@ -134,14 +135,15 @@ echo $acl->isAllowed('administrator', 'announcement', 'archive') ?
         <title>Usuwanie kontroli dostępu</title>
 
         <para>
-        Aby usunąć jedną lub więcej reguł z ACL, po prostu użyj dostępnych metod
-        <code>removeAllow()</code> lub <code>removeDeny()</code>. Podobnie jak
-        w  metodach <code>allow()</code> oraz <code>deny()</code>, możesz podać
-        wartość <code>null</code> aby oznaczyć wszystkie role, wszystkie zasoby
-        i/lub wszystkie przywileje:
+            Aby usunąć jedną lub więcej reguł z <acronym>ACL</acronym>, po prostu użyj 
+            dostępnych metod <methodname>removeAllow()</methodname> lub 
+            <methodname>removeDeny()</methodname>. Podobnie jak w  metodach 
+            <methodname>allow()</methodname> oraz <methodname>deny()</methodname>, 
+            możesz podać wartość <constant>NULL</constant> aby oznaczyć wszystkie 
+            role, wszystkie zasoby i/lub wszystkie przywileje:
         </para>
 
-        <programlisting role="php"><![CDATA[
+        <programlisting language="php"><![CDATA[
 // Usunięcie zabronienia możliwości przeglądania ostatnich nowości
 // przez grupę staff (oraz marketing, przez dziedziczenie)
 $acl->removeDeny('staff', 'latest', 'revise');
@@ -161,16 +163,15 @@ echo $acl->isAllowed('marketing', 'newsletter', 'publish') ?
 echo $acl->isAllowed('marketing', 'newsletter', 'archive') ?
      "allowed" : "denied";
 // zabronione
-]]>
-        </programlisting>
+]]></programlisting>
 
         <para>
-        Przywileje mogą być modyfikowane inkrementalnie jak pokazano wyżej, ale
-        wartość <code>null</code> dla przywilejów nadpisuje te inkrementalne
+            Przywileje mogą być modyfikowane inkrementalnie jak pokazano wyżej, ale
+            wartość <constant>NULL</constant> dla przywilejów nadpisuje te inkrementalne
         zmiany:
         </para>
 
-        <programlisting role="php"><![CDATA[
+        <programlisting language="php"><![CDATA[
 // Nadanie grupie marketing wszystkich uprawnień związanych z ostatnimi nowościami
 $acl->allow('marketing', 'latest');
 
@@ -185,8 +186,7 @@ echo $acl->isAllowed('marketing', 'latest', 'archive') ?
 echo $acl->isAllowed('marketing', 'latest', 'anything') ?
      "allowed" : "denied";
 // dozwolone
-]]>
-        </programlisting>
+]]></programlisting>
 
     </sect2>
 

documentation/manual/pl/module_specs/Zend_Acl.xml

@@ -1,60 +1,65 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- Reviewed: no -->
 <sect1 id="zend.acl.introduction">
     <title>Wprowadzenie</title>
 
     <para>
-        Zend_Acl zapewnia lekką i elastyczną obsługę implementacji list
-        kontroli dostępu (ACL) do zarządzania uprawnieniami. Ogólnie rzecz
-        biorąc, aplikacja może używać list ACL do kontrolowania
-        dostępu do określonych chronionych obiektów przez inne obiekty.
+        <classname>Zend_Acl</classname> zapewnia lekką i elastyczną obsługę 
+        implementacji list kontroli dostępu (<acronym>ACL</acronym>) do zarządzania 
+        uprawnieniami. Ogólnie rzecz biorąc, aplikacja może używać list 
+        <acronym>ACL</acronym> do kontrolowania dostępu do określonych chronionych 
+        obiektów przez inne obiekty.
     </para>
 
     <para>
-        Dla celów tej dokumentacji,
-
-        <itemizedlist>
-            <listitem>
-                <para>
-                    <emphasis role="strong">zasób</emphasis> jest obiektem do
-                    którego dostęp jest kontrolowany.
-                </para>
-            </listitem>
-            <listitem>
-                <para>
-                    <emphasis role="strong">rola</emphasis> jest obiektem, który
-                    może zażądać dostępu do zasobu.
-                </para>
-            </listitem>
-        </itemizedlist>
-
-        Przystępnie mówiąc, <emphasis role="strong">role żądają dostępu do zasobów</emphasis>.
+        Dla celów tej dokumentacji:
+    </para>
+
+    <itemizedlist>
+        <listitem>
+            <para>
+                <emphasis>zasób</emphasis> jest obiektem do
+                którego dostęp jest kontrolowany.
+            </para>
+        </listitem>
+        <listitem>
+            <para>
+                <emphasis>rola</emphasis> jest obiektem, który
+                może zażądać dostępu do zasobu.
+            </para>
+        </listitem>
+    </itemizedlist>
+
+    <para>
+        Przystępnie mówiąc, <emphasis>role żądają dostępu do zasobów</emphasis>.
         Na przykład, jeśli obsługujący parking samochodow zażąda dostępu do
         samochodu, to ta osoba jest rolą, a samochód jest zasobem, więc dostęp
         do samochodu nie musi zostać przyznany każdemu.
     </para>
 
     <para>
-        Dzięki określeniu i użyciu list kontroli dostępu (ACL), aplikacja może
-        kontrolować to, w jaki sposób żądające obiekty (role) mają przydzielany
-        dostęp do chronionych obiektów (zasobów).
+        Dzięki określeniu i użyciu list kontroli dostępu (<acronym>ACL</acronym>), 
+        aplikacja może kontrolować to, w jaki sposób żądające obiekty (role) mają 
+        przydzielany dostęp do chronionych obiektów (zasobów).
     </para>
 
     <sect2 id="zend.acl.introduction.resources">
         <title>O zasobach</title>
         <para>
-            Tworzenie zasobu w Zend_Acl jest bardzo proste. Zend_Acl zapewnia
-            interfejs <code>Zend_Acl_Resource_Interface</code> aby ułatwić
+            Tworzenie zasobu w Zend_Acl jest bardzo proste. <classname>Zend_Acl</classname> zapewnia
+            interfejs <classname>Zend_Acl_Resource_Interface</classname> aby ułatwić
             programistom tworzenie zasobów w aplikacji. Klasa jedynie implementuje ten
-            interfejs, który składa się z jednej metody, <code>getResourceId()</code>,
-            dzięki ktorej Zend_Acl wie, że obiekt jest zasobem. Dodatkowo w
-            Zend_Acl dołączona jest klasa <code>Zend_Acl_Resource</code>,
+            interfejs, który składa się z jednej metody, <methodname>getResourceId()</methodname>,
+            dzięki ktorej <classname>Zend_Acl</classname> wie, że obiekt jest zasobem. Dodatkowo w
+            <classname>Zend_Acl</classname> dołączona jest klasa <classname>Zend_Acl_Resource</classname>,
             która jest podstawową implementacją zasobu do użycia przez
             programistów gdy jest to potrzebne.
         </para>
         <para>
-            Zend_Acl zapewnia drzewiastą strukturę, w której mogą być dodawane
-            zasoby (lub inaczej "obszary będące pod kontrolą"). Dzięki temu, że
-            zasoby są przechowywane w strukturze drzewiastej, mogą być one
-            organizowane od ogólnych (od korzeni) do szczegółowych (do gałęzi).
+            <classname>Zend_Acl</classname> zapewnia drzewiastą strukturę, w której 
+            mogą być dodawane zasoby (lub inaczej "obszary będące pod kontrolą"). 
+            Dzięki temu, że zasoby są przechowywane w strukturze drzewiastej, mogą 
+            być one organizowane od ogólnych (od korzeni) do szczegółowych (do gałęzi).
             Zapytanie do konkretnego zasobu automatycznie przeszuka całą
             hierarchię zasobów, dla reguł przypisanych do przodka zasobów,
             pozwalając na proste dziedziczenie reguł. Na przykład, jeśli
@@ -62,15 +67,15 @@
             wystarczy przypisać regułę do miasta, zamiast przypisywać regułę to
             każdego z budynków z osobna. Niektóre z budynków mogą wymagać
             wyjątków od tej reguły i może być to osiągnięte w łatwy sposób w
-            Zend_Acl poprzez przypisanie takiej wyjątkowej reguły dla każdego z
+            <classname>Zend_Acl</classname> poprzez przypisanie takiej wyjątkowej reguły dla każdego z
             budynków wymagających wyjątku. Zasób może dziedziczyć tylko od
             jednego zasobu rodzica, a ten rodzic może także dziedziczyć tylko od
             jednego zasobu itd.
         </para>
         <para>
-            Zend_Acl także obsługuje przywileje dla zasobów (np., "create",
-            "read", "update", "delete") i programista może przypisać reguły,
-            które mają zastosowanie do wszystkich przywilejów, lub dla
+            <classname>Zend_Acl</classname> także obsługuje przywileje dla zasobów 
+            (np., "create", "read", "update", "delete") i programista może przypisać 
+            reguły, które mają zastosowanie do wszystkich przywilejów, lub dla
             konkretnych przywilejów dla jednego lub więcej zasobów.
         </para>
     </sect2>
@@ -79,15 +84,15 @@
         <title>O rolach</title>
         <para>
             Tak jak tworzenie zasobów, tworzenie ról także jest bardzo proste.
-            Wszystkie role muszą implementować interfejs <code>Zend_Acl_Role_Interface</code>
-            Ten interfejs składa się z jednej metody, <code>getRoleId()</code>,
+            Wszystkie role muszą implementować interfejs <classname>Zend_Acl_Role_Interface</classname>
+            Ten interfejs składa się z jednej metody, <methodname>getRoleId()</methodname>,
             dzięki ktorej Zend_Acl wie, że obiekt jest rolą. Dodatkowo w
-            Zend_Acl dołączona jest klasa <code>Zend_Acl_Role</code>,
+            Zend_Acl dołączona jest klasa <classname>Zend_Acl_Role</classname>,
             która jest podstawową implementacją roli do użycia przez
             programistów gdy jest to potrzebne.
         </para>
         <para>
-            W Zend_Acl rola może dziedziczyć z jednej lub więcej ról. Jest to po
+            W <classname>Zend_Acl</classname> rola może dziedziczyć z jednej lub więcej ról. Jest to po
             to, aby możliwe było dziedziczenie zasad dla ról. Na przykład rola,
             użytkownik "sally", może dziedziczyć z jednej lub więcej ról
             rodziców, takich jak na przykład "editor" oraz "administrator".
@@ -100,23 +105,23 @@
             Chociaż możliwość dziedziczenia po wielu rolach jest bardzo
             użyteczna, to takie dziedziczenie wprowadza pewien stopień
             złożoności. Poniższy przykład ilustruje niejasny przypadek
-            dziedziczenia i pokazuje w jaki sposób Zend_Acl go rozwiązuje.
+            dziedziczenia i pokazuje w jaki sposób <classname>Zend_Acl</classname> go rozwiązuje.
         </para>
         <example id="zend.acl.introduction.roles.example.multiple_inheritance">
             <title>Dziedziczenie po wielu rolach</title>
             <para>
                 Poniższy kod definiuje trzy podstawowe role, po których inne role
-                mogą dziedziczyć - "<code>guest</code>", "<code>member</code>",
-                oraz "<code>admin</code>". Następnie definiowana jest rola o
-                nazwie "<code>someUser</code>", ktora dziedziczy po zdefiniowanych
+                mogą dziedziczyć - "guest", "member",
+                oraz "admin". Następnie definiowana jest rola o
+                nazwie "someUser", ktora dziedziczy po zdefiniowanych
                 wcześniej trzech rolach. Ważna jest kolejność zdefiniowania tych
-                trzech ról w tablicy <code>$parents</code>. Gdy sprawdzamy
-                reguły dostępu, Zend_Acl szuka reguł zdefiniowanych nie tylko dla
-                danej roli (w tym przypadku "<code>someUser</code>"), ale także
+                trzech ról w tablicy <varname>$parents</varname>. Gdy sprawdzamy
+                reguły dostępu, <classname>Zend_Acl</classname> szuka reguł zdefiniowanych nie tylko dla
+                danej roli (w tym przypadku someUser"), ale także
                 dla ról, po których ta rola dziedziczy (w tym przypadku
-                "<code>guest</code>", "<code>member</code>" oraz "<code>admin</code>"):
+                "guest", "member" oraz "admin"):
             </para>
-            <programlisting role="php"><![CDATA[
+            <programlisting language="php"><![CDATA[
 $acl = new Zend_Acl();
 
 $acl->addRole(new Zend_Acl_Role('guest'))
@@ -132,35 +137,34 @@ $acl->deny('guest', 'someResource');
 $acl->allow('member', 'someResource');
 
 echo $acl->isAllowed('someUser', 'someResource') ? 'allowed' : 'denied';
-]]>
-            </programlisting>
+]]></programlisting>
             <para>
                 Z tego względu, że nie ma zdefiniowanych reguł konkretnie dla
-                roli "<code>someUser</code>" oraz dla zasobu "<code>someResource</code>",
-                Zend_Acl musi szukać zasad, ktore mogą być zdefiniowane dla ról,
-                po których dziedziczy rola "<code>someUser</code>". Wpierw
-                sprawdzana jest rola "<code>admin</code>", a dla niej nie ma
+                roli "someUser" oraz dla zasobu "someResource",
+                <classname>Zend_Acl</classname> musi szukać zasad, ktore mogą być zdefiniowane dla ról,
+                po których dziedziczy rola "someUser>". Wpierw
+                sprawdzana jest rola "admin", a dla niej nie ma
                 zdefiniowanej żadnej reguły dostępu. Następnie sprawdzana jest
-                rola "<code>member</code>" i Zend_Acl znajduje zdefiniowaną
-                regułę zezwalająca roli "<code>member</code>" na dostęp do zasobu
-                "<code>someResource</code>".
+                rola "member" i <classname>Zend_Acl</classname> znajduje zdefiniowaną
+                regułę zezwalająca roli "member" na dostęp do zasobu
+                "someResource".
             </para>
             <para>
-                Jeśli Zend_Acl kontynuowałby sprawdzanie reguł zdefiniowanych dla
+                Jeśli <classname>Zend_Acl</classname> kontynuowałby sprawdzanie reguł zdefiniowanych dla
                 innych ról rodziców, znalazłby regułę zabraniającą roli
-                "<code>guest</code>" dostępu do zasobu "<code>someResource</code>".
+                "guest" dostępu do zasobu "someResource".
                 Ten fakt wprowadza niejaność, ponieważ teraz rola
-                "<code>someUser</code>" ma zarówno dozwolony jak i zabroniony
-                dostęp do zasobu "<code>someResource</code>", z tego powodu, że
+                "someUser" ma zarówno dozwolony jak i zabroniony
+                dostęp do zasobu "someResource", z tego powodu, że
                 posiada odziedziczone po dwóch rolach reguły, które są ze sobą
                 sprzeczne.
             </para>
             <para>
-                Zend_Acl rozwiązuje tę niejaśność kończąc zapytanie wtedy, gdy
-                znajdzie pierwszą regułę, wprost pasującą do zapytania. W tym
-                przypadku, z tego względu, że rola "<code>member</code>" jest
-                sprawdzana przed rolą "<code>guest</code>", przykładowy kod
-                wyświetliłby "<code>allowed</code>".
+                <classname>Zend_Acl</classname> rozwiązuje tę niejaśność kończąc 
+                zapytanie wtedy, gdy znajdzie pierwszą regułę, wprost pasującą do 
+                zapytania. W tym przypadku, z tego względu, że rola "member" jest
+                sprawdzana przed rolą "guest", przykładowy kod
+                wyświetliłby "allowed".
             </para>
         </example>
         <note>
@@ -173,24 +177,23 @@ echo $acl->isAllowed('someUser', 'someResource') ? 'allowed' : 'denied';
     </sect2>
 
     <sect2 id="zend.acl.introduction.creating">
-        <title>Tworzenie list kontroli dostępu (ACL)</title>
+        <title>Tworzenie list kontroli dostępu</title>
 
         <para>
-            ACL może reprezentować dowolny zestaw fizycznych lub wirtualnych
-            obiektów których potrzebujesz. Dla celów prezentacji utworzymy ACL
+            <acronym>ACL<acronym> może reprezentować dowolny zestaw fizycznych lub wirtualnych
+            obiektów których potrzebujesz. Dla celów prezentacji utworzymy <acronym>ACL</acronym>
             dla prostego Systemu Zarządzania Treścią (Content Management System
-            - CMS), w którym różnymi obszarami zarządza kilka poziomów grup.
-            Aby utworzyć nowy obiekt ACL, utwórzmy instancję ACL bez parametrów:
+            - <acronym>CMS</acronym>), w którym różnymi obszarami zarządza kilka poziomów grup.
+            Aby utworzyć nowy obiekt <acronym>ACL</acronym>, utwórzmy instancję <acronym>ACL</acronym> bez parametrów:
         </para>
 
-        <programlisting role="php"><![CDATA[
+        <programlisting language="php"><![CDATA[
 $acl = new Zend_Acl();
-]]>
-        </programlisting>
+]]></programlisting>
 
         <note>
             <para>
-                Dopóki programista nie określi reguły "allow", Zend_Acl zabroni
+                Dopóki programista nie określi reguły "allow", <classname>Zend_Acl</classname> zabroni
                 dostępu wszystkim rolom do wszystkich przywilejów dla wszystkich
                 zasobów.
             </para>
@@ -205,7 +208,7 @@ $acl = new Zend_Acl();
             uprawnień aby określić możliwości jego użytkowników.
             Może być tu grupa 'Guest' aby pozwolić na limitowany dostęp
             dla celów demonstracyjnych, grupa 'Staff' dla większości
-            użytkowników aplikacji CMS, którzy przeprowadzają najczęstsze
+            użytkowników aplikacji <acronym>CMS</acronym>, którzy przeprowadzają najczęstsze
             codzienne operacje, grupa 'Editor' dla tych odpowiedzialnych za
             publikowanie, przeglądanie, archiwizowanie i usuwanie zawartości i
             ostatecznie grupa 'Administrator', której zadania obejmują zarówno
@@ -254,13 +257,13 @@ $acl = new Zend_Acl();
         </table>
 
         <para>
-            W tym przykładzie użyty jest obiekt <code>Zend_Acl_Role</code>, ale
+            W tym przykładzie użyty jest obiekt <classname>Zend_Acl_Role</classname>, ale
             dozwolony jest dowolny obiekt, który implementuje interfejs
-            <code>Zend_Acl_Role_Interface</code>. Te grupy mogą być dodane
+            <classname>Zend_Acl_Role_Interface</classname>. Te grupy mogą być dodane
             do rejestru ról w taki sposób:
         </para>
 
-        <programlisting role="php"><![CDATA[
+        <programlisting language="php"><![CDATA[
 $acl = new Zend_Acl();
 
 // Dodajemy grupy do rejestru ról używając obiektu Zend_Acl_Role
@@ -281,8 +284,7 @@ $acl->addRole(new Zend_Acl_Role('editor'), 'staff');
 
 // Administrator nie dziedziczy kontroli dostępu
 $acl->addRole(new Zend_Acl_Role('administrator'));
-]]>
-        </programlisting>
+]]></programlisting>
 
     </sect2>
 
@@ -290,11 +292,11 @@ $acl->addRole(new Zend_Acl_Role('administrator'));
         <title>Definiowanie kontroli dostępu</title>
 
         <para>
-            Teraz gdy ACL zawiera stosowne role, możemy ustalić reguły, które
+            Teraz gdy <acronym>ACL</acronym> zawiera stosowne role, możemy ustalić reguły, które
             definiują w jaki sposób role mają uzyskiwać dostęp do zasobów.
             Mogłeś zauważyć, że nie zdefiniowaliśmy w tym przykładzie żadnych
             konkretnych zasobów, co jest uproszczone w celu zilustrowania, że
-            reguły mają zastosowanie do wszystkich zasobów. Zend_Acl zapewnia
+            reguły mają zastosowanie do wszystkich zasobów. <classname>Zend_Acl</classname> zapewnia
             implementację dzięki której reguły mogą być przypisane od ogólnych
             do szczegółowych, minimalizując ilość potrzebnych reguł, ponieważ
             zasoby oraz role dziedziczą reguły, które są definiowane dla ich
@@ -303,7 +305,7 @@ $acl->addRole(new Zend_Acl_Role('administrator'));
 
         <note>
             <para>
-                W zasadzie Zend_Acl przestrzega danej reguły tylko wtedy, gdy
+                W zasadzie <classname>Zend_Acl</classname> przestrzega danej reguły tylko wtedy, gdy
                 nie ma zastosowania bardziej szczegółowa reguła.
             </para>
         </note>
@@ -314,7 +316,7 @@ $acl->addRole(new Zend_Acl_Role('administrator'));
             zdefiniowane wyżej zrób tak:
         </para>
 
-        <programlisting role="php"><![CDATA[
+        <programlisting language="php"><![CDATA[
 $acl = new Zend_Acl();
 
 $roleGuest = new Zend_Acl_Role('guest');
@@ -341,12 +343,11 @@ $acl->allow('editor', null, array('publish', 'archive', 'delete'));
 
 // Administrator nie dziedziczy niczego, ale ma dostęp do wszystkich zasobów
 $acl->allow('administrator');
-]]>
-        </programlisting>
+]]></programlisting>
 
         <para>
-            Wartości <code>null</code> w powyższych wywołaniach metod
-            <code>allow()</code> oznaczają, że reguły dotyczą wszystkich zasobów.
+            Wartości <constant>NULL</constant> w powyższych wywołaniach metod
+            <methodname>allow()</methodname> oznaczają, że reguły dotyczą wszystkich zasobów.
         </para>
 
     </sect2>
@@ -355,13 +356,13 @@ $acl->allow('administrator');
         <title>Zapytania ACL</title>
 
         <para>
-            Posiadamy teraz elastyczne ACL, ktore mogą być użyte do określenia,
+            Posiadamy teraz elastyczne <acronym>ACL</acronym>, ktore mogą być użyte do określenia,
             czy żądająca osoba posiada uprawnienia do przeprowadzenia określonej
             akcji w aplikacji web. Przeprowadzenie zapytań jest bardzo proste
-            poprzez użycie metody <code>isAllowed()</code>:
+            poprzez użycie metody <methodname>isAllowed()</methodname>:
         </para>
 
-        <programlisting role="php"><![CDATA[
+        <programlisting language="php"><![CDATA[
 echo $acl->isAllowed('guest', null, 'view') ?
      "allowed" : "denied";
 // dozwolone
@@ -392,8 +393,8 @@ echo $acl->isAllowed('administrator') ?
 
 echo $acl->isAllowed('administrator', null, 'update') ?
      "allowed" : "denied";
-// dozwolone ponieważ administrator ma wszystkie uprawnienia]]>
-        </programlisting>
+// dozwolone ponieważ administrator ma wszystkie uprawnienia
+]]></programlisting>
 
     </sect2>
 </sect1>