[DOCUMENTATION] French:

 - sync with English

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

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

@@ -1,5 +1,5 @@
 <?xml version="1.0" encoding="utf-8"?>
-<!-- EN-Revision: 15101 -->
+<!-- EN-Revision: 15814 -->
 <!-- Reviewed: no -->
 <sect1 id="zend.acl.advanced">
     <title>Utilisation avancée</title>
@@ -10,20 +10,21 @@
         <para>
             <classname>Zend_Acl</classname> a été conçu pour ne pas nécessiter de technologie
             spécifique comme une base de données ou un serveur de cache pour conserver les données
-            ACL. Son implémentation PHP permet de créer des outils d'administration assez
-            facilement. De nombreuses situations nécessitent une certaine forme de maintenance ou
-            de gestion des ACL, et <classname>Zend_Acl</classname> fournit les méthodes pour
+            <acronym>ACL</acronym>. Son implémentation <acronym>PHP</acronym> permet de créer des
+            outils d'administration basés sur <classname>Zend_Acl</classname> assez facilement. De
+            nombreuses situations nécessitent une certaine forme de maintenance ou de gestion des
+            <acronym>ACL</acronym>, et <classname>Zend_Acl</classname> fournit les méthodes pour
             définir et interroger les règles d'accès d'une application.
         </para>
 
         <para>
-            Le stockage des données ACL est dès lors laissé aux bons soins du développeur,
-            dans la mesure où les cas d'utilisation peuvent grandement varier d'un cas à l'autre.
-            Puisque <classname>Zend_Acl</classname> est sérialisable, les objets ACL peuvent être
-            sérialisés avec la fonction
-            <ulink url="http://fr.php.net/serialize"><code>serialize()</code></ulink>, et le
-            résultat peut être stocké n'importe où le développeur le désire : fichier, base de
-            donnée, cache.
+            Le stockage des données <acronym>ACL</acronym> est dès lors laissé aux bons soins du
+            développeur, dans la mesure où les cas d'utilisation peuvent grandement varier d'un cas
+            à l'autre. Puisque <classname>Zend_Acl</classname> est sérialisable, les objets
+            <acronym>ACL</acronym> peuvent être sérialisés avec la fonction
+            <ulink url="http://fr.php.net/serialize"><methodname>serialize()</methodname></ulink> de
+            <acronym>PHP</acronym>, et le résultat peut être stocké n'importe où le développeur le
+            désire&#160;: fichier, base de donnée, cache.
         </para>
     </sect2>
 
@@ -43,7 +44,7 @@
         <para>
             <classname>Zend_Acl</classname> fourni le support pour les règles conditionnelles
             via <classname>Zend_Acl_Assert_Interface</classname>. Pour mettre en oeuvre cette
-            interface, il suffit d'implémenter la méthode <code>assert()</code> :
+            interface, il suffit d'implémenter la méthode <methodname>assert()</methodname>&#160;:
         </para>
 
         <programlisting language="php"><![CDATA[
@@ -68,7 +69,7 @@ class CleanIPAssertion implements Zend_Acl_Assert_Interface
             Lorsqu'une classe d'assertion est disponible, le développeur doit fournir une
             instance de cette classe lorsqu'il assigne une règle conditionnelle. Une règle qui est
             créée avec une assertion s'applique uniquement dans les cas où l'assertion retourne une
-            valeur <code>true</code>.
+            valeur <constant>TRUE</constant>.
         </para>
 
         <programlisting language="php"><![CDATA[
@@ -90,10 +91,11 @@ $acl->allow(null, null, null, new CleanIPAssertion());
         </para>
 
         <para>
-            La méthode <code>assert()</code> d'un objet d'assertion reçoit l'ACL, le rôle, la
-            ressource et le privilège auquel une requête d'autorisation (c.a.d.,
-            <code>isAllowed()</code>) s'applique, afin de fournir un contexte à la classe
-            d'assertion pour déterminer ses conditions lorsque cela est nécessaire.
+            La méthode <methodname>assert()</methodname> d'un objet d'assertion reçoit
+            l'<acronym>ACL</acronym>, le rôle, la ressource et le privilège auquel une requête
+            d'autorisation (c.-à-d., <methodname>isAllowed()</methodname>) s'applique, afin de
+            fournir un contexte à la classe d'assertion pour déterminer ses conditions lorsque cela
+            est nécessaire.
         </para>
     </sect2>
 </sect1>

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

@@ -1,5 +1,5 @@
 <?xml version="1.0" encoding="utf-8"?>
-<!-- EN-Revision: 15101 -->
+<!-- EN-Revision: 15783 -->
 <!-- Reviewed: no -->
 <sect1 id="zend.acl.refining">
     <title>Affiner les Contrôles d'Accès</title>
@@ -10,18 +10,18 @@
         <para>
             La liste basique définie dans le
             <link linkend="zend.acl.introduction">chapitre précédent</link>montre comment plusieurs
-            privilèges peuvent être alloués pour l'ensemble de la liste (toutes les ressources). En
-            pratique, toutefois, les contrôles d'accès ont souvent des exceptions et des degrés de
-            complexité variables. <classname>Zend_Acl</classname> permet d'atteindre ce degré de
-            finesse d'une manière directe et flexible.
+            privilèges peuvent être alloués pour l'ensemble de l'<acronym>ACL</acronym> (toutes les
+            ressources). En pratique, toutefois, les contrôles d'accès ont souvent des exceptions et
+            des degrés de complexité variables. <classname>Zend_Acl</classname> permet d'atteindre
+            ce degré de finesse d'une manière directe et flexible.
         </para>
 
         <para>
-            Pour l'exemple du CMS, nous avons déterminé que bien que le groupe "Staff" couvre
-            les besoins de la plupart des utilisateurs, un groupe "Marketing" est nécessaire. Ce
-            groupe doit avoir accès à la newsletter et aux dernières news dans le CMS. Le groupe va
-            recevoir la possibilité de publier et d'archiver à la fois des newsletters et des
-            news.
+            Pour l'exemple du <acronym>CMS</acronym>, nous avons déterminé que bien que le groupe
+            "Staff" couvre les besoins de la plupart des utilisateurs, un groupe "Marketing" est
+            nécessaire. Ce groupe doit avoir accès à la newsletter et aux dernières news dans le
+            <acronym>CMS</acronym>. Le groupe va recevoir la possibilité de publier et d'archiver à
+            la fois des newsletters et des news.
         </para>
 
         <para>
@@ -67,7 +67,7 @@ $acl->add(new Zend_Acl_Resource('announcement'), 'news');
 
         <para>
             Ensuite c'est simplement une manière de définir ces règles spécifiques sur les
-            parties cibles de l'ACL&#160;:
+            parties cibles de l'<acronym>ACL</acronym>&#160;:
         </para>
 
         <programlisting language="php"><![CDATA[
@@ -87,7 +87,8 @@ $acl->deny(null, 'annonce', 'archive');
 ]]></programlisting>
 
         <para>
-            On peut maintenant interroger les ACL sur base des dernières modifications&#160;:
+            On peut maintenant interroger les <acronym>ACL</acronym> sur base des dernières
+            modifications&#160;:
         </para>
 
         <programlisting language="php"><![CDATA[
@@ -121,11 +122,11 @@ echo $acl->isAllowed('administrator', 'announcement', 'archive') ?
         <title>Retirer les Contrôles d'Accès</title>
 
         <para>
-            Pour retirer une ou plusieurs règles des ACL, utilisez simplement la méthode
-            <code>removeAllow()</code> ou <code>removeDeny()</code>. Comme pour
-            <code>allow()</code> et <code>deny()</code>, vous pouvez utiliser une valeur
-            <code>null</code> pour indiquer que la méthode s'applique à tous les rôles, ressources
-            et/ou privilèges.
+            Pour retirer une ou plusieurs règles des <acronym>ACL</acronym>, utilisez simplement la
+            méthode <methodname>removeAllow()</methodname> ou <methodname>removeDeny()</methodname>.
+            Comme pour <methodname>allow()</methodname> et <methodname>deny()</methodname>, vous
+            pouvez utiliser une valeur <constant>NULL</constant> pour indiquer que la méthode
+            s'applique à tous les rôles, ressources et&#160;/&#160;ou privilèges.
         </para>
 
         <programlisting language="php"><![CDATA[
@@ -151,8 +152,8 @@ echo $acl->isAllowed('marketing', 'newsletter', 'archive') ?
 
         <para>
             Les privilèges peuvent être modifiés de manière incrémentielle comme indiqué au
-            dessus, mais une valeur <code>null</code> pour les privilèges écrase ces modifications
-            incrémentielles.
+            dessus, mais une valeur <constant>NULL</constant> pour les privilèges écrase ces
+            modifications incrémentielles.
         </para>
 
         <programlisting language="php"><![CDATA[

documentation/manual/fr/module_specs/Zend_Acl.xml

@@ -1,39 +1,42 @@
 <?xml version="1.0" encoding="utf-8"?>
-<!-- EN-Revision: 15346 -->
+<!-- EN-Revision: 15783 -->
 <!-- Reviewed: no -->
 <sect1 id="zend.acl.introduction">
     <title>Introduction</title>
 
     <para>
         <classname>Zend_Acl</classname> fournit une implémentation légère et flexible de
-        listes de contrôle d'accès (ACL : Access Control List) pour la gestion de privilèges. En
-        général, une application peut utiliser une telle fonctionnalité pour contrôler l'accès à
+        listes de contrôle d'accès (<acronym>ACL</acronym>) pour la gestion de privilèges. En
+        général, une application peut utiliser ces <acronym>ACL</acronym> pour contrôler l'accès à
         certains objets par d'autres objets demandeurs.
     </para>
 
     <para>
-        Dans le cadre de cette documentation,
-        <itemizedlist>
-            <listitem>
-                <para>
-                    une <emphasis>ressource</emphasis> est un objet dont l'accès
-                    est contrôlé,
-                </para>
-            </listitem>
-            <listitem>
-                <para>
-                    un <emphasis>rôle</emphasis> est un objet qui peut demander
-                    l'accès à une ressource.
-                </para>
-            </listitem>
-        </itemizedlist>Dit simplement, <emphasis> les rôles demandent l'accès à des
+        Dans le cadre de cette documentation&#160;:
+    </para>
+
+    <itemizedlist>
+        <listitem>
+            <para>
+                une <emphasis>ressource</emphasis> est un objet dont l'accès est contrôlé,
+            </para>
+        </listitem>
+        <listitem>
+            <para>
+                un <emphasis>rôle</emphasis> est un objet qui peut demander l'accès à une ressource.
+            </para>
+        </listitem>
+    </itemizedlist>
+
+    <para>
+        Dit simplement, <emphasis> les rôles demandent l'accès à des
         ressources</emphasis>. Par exemple, si une personne demande l'accès à une voiture, alors la
         personne est le rôle demandeur et la voiture est la ressource, puisque l'accès à la voiture
         est soumis à un contrôle.
     </para>
 
     <para>
-        Grâce à la définition et à la mise en oeuvre d'une liste de contrôle d'accès (ACL),
+        Grâce à la définition et à la mise en oeuvre d'une <acronym>ACL</acronym>,
         une application peut contrôler comment les objets demandeurs (rôles) reçoivent l'accès (ou
         non) à des objets protégés (ressources).
     </para>
@@ -46,7 +49,7 @@
             <classname>Zend_Acl</classname> fournit
             <classname>Zend_Acl_Resource_Interface</classname> pour faciliter la tâche aux
             développeurs. Une classe a simplement besoin d'implémenter cette interface, qui
-            consiste en une seule méthode, <code>getResourceId()</code>, pour que
+            consiste en une seule méthode, <methodname>getResourceId()</methodname>, pour que
             <classname>Zend_Acl</classname> reconnaît l'objet comme étant une ressource. Par
             ailleurs, <classname>Zend_Acl_Resource</classname> est fourni par
             <classname>Zend_Acl</classname> comme une implémentation basique de ressource que les
@@ -81,14 +84,11 @@
         <title>A propos des rôles</title>
 
         <para>
-            Comme pour les ressources, créer un rôle est très simple.
-            <classname>Zend_Acl</classname> propose <classname>Zend_Acl_Role_Interface</classname>
-            pour faciliter le travail des développeurs. Une classe doit uniquement implémenter
-            cette interface qui consiste en une seule méthode <code>getRoleId()</code>, pour que
-            <classname>Zend_Acl</classname> considère l'objet comme un rôle. De plus,
-            <classname>Zend_Acl_Role</classname> est inclus dans <classname>Zend_Acl</classname>
-            comme une implémentation basique de rôle que les développeurs peuvent étendre si
-            besoin.
+            Comme pour les ressources, créer un rôle est très simple. Tout rôle doit implémenter
+            <classname>Zend_Acl_Role_Interface</classname> qui consiste en une seule méthode
+            <methodname>getRoleId()</methodname>. De plus, <classname>Zend_Acl_Role</classname> est
+            inclus dans <classname>Zend_Acl</classname> comme une implémentation basique de rôle que
+            les développeurs peuvent étendre si besoin.
         </para>
 
         <para>
@@ -103,22 +103,20 @@
         <para>
             Bien que la possibilité d'hériter de plusieurs rôles soit très utile, l'héritage
             multiple introduit aussi un certain degré de complexité. L'exemple ci-dessous illustre
-            l'ambiguïté et la manière de la résoudre.
+            l'ambiguïté et la manière dont <classname>Zend_Acl</classname> la résout.
         </para>
 
         <example id="zend.acl.introduction.roles.example.multiple_inheritance">
             <title>Héritages multiples entre rôles</title>
 
             <para>
-                Le code ci-dessous définit trois rôles de base - "<code>guest</code>",
-                "<code>member</code>", et "<code>admin</code>" - desquels d'autres rôles peuvent
-                hériter. Ensuite, un rôle identifié par "<code>someUser</code>" est créé et hérite
-                des trois autres rôles. L'ordre selon lequel ces rôles apparaissent dans le tableau
-                <code>$parents</code> est important. Lorsque cela est nécessaire
-                <classname>Zend_Acl</classname> recherche les règles d'accès définies non seulement
-                pour le rôle demandé (ici "<code>someUser</code>"), mais aussi pour les autres rôles
-                desquels le rôle recherché hérite (ici "<code>guest</code>",
-                "<code>member</code>", et "<code>admin</code>")&#160;:
+                Le code ci-dessous définit trois rôles de base - "guest", "member", et "admin" -
+                desquels d'autres rôles peuvent hériter. Ensuite, un rôle identifié par "someUser"
+                est créé et hérite des trois autres rôles. L'ordre selon lequel ces rôles
+                apparaissent dans le tableau <varname>$parents</varname> est important. Lorsque cela
+                est nécessaire <classname>Zend_Acl</classname> recherche les règles d'accès définies
+                non seulement pour le rôle demandé (ici "someUser"), mais aussi pour les autres
+                rôles desquels le rôle recherché hérite (ici "guest", "member", et "admin")&#160;:
             </para>
 
             <programlisting language="php"><![CDATA[
@@ -161,7 +159,7 @@ echo $acl->isAllowed('unUtilisateur', 'someResource') ? 'autorisé' : 'refusé';
                 <classname>Zend_Acl</classname> résout cette ambiguïté en arrêtant la
                 recherche de règles d'accès dès qu'une première règle est découverte. Dans notre
                 exemple, puisque le rôle "member" est examiné avant le rôle "invite", le résultat
-                devrait afficher "<code>autorisé</code>".
+                devrait afficher "autorisé".
             </para>
         </example>
 
@@ -178,11 +176,12 @@ echo $acl->isAllowed('unUtilisateur', 'someResource') ? 'autorisé' : 'refusé';
         <title>Créer la Liste de Contrôle d'Accès</title>
 
         <para>
-            Une ACL peut représenter n'importe quel ensemble d'objets physiques ou virtuels
-            que vous souhaitez. Pour les besoins de la démonstration, nous allons créer un système
-            basique d'ACL pour une Gestion de Contenus (CMS) qui comporte plusieurs niveaux de
-            groupes au sein d'une grande variété de zones. Pour créer un nouvel objet ACL, nous
-            créons une nouvelle instance d'ACL sans paramètres&#160;:
+            Une <acronym>ACL</acronym> peut représenter n'importe quel ensemble d'objets physiques
+            ou virtuels que vous souhaitez. Pour les besoins de la démonstration, nous allons créer
+            un système basique d'<acronym>ACL</acronym> pour une Gestion de Contenus
+            (<acronym>CMS</acronym>) qui comporte plusieurs niveaux de groupes au sein d'une grande
+            variété de zones. Pour créer un nouvel objet <acronym>ACL</acronym>, nous créons une
+            nouvelle instance d'<acronym>ACL</acronym> sans paramètres&#160;:
         </para>
 
         <programlisting language="php"><![CDATA[
@@ -202,17 +201,18 @@ $acl = new Zend_Acl();
         <title>Registre des rôles</title>
 
         <para>
-            Les systèmes de gestion de contenu vont pratiquement toujours nécessiter une
-            hiérarchie de permissions afin de déterminer les droits de rédaction de ses
-            utilisateurs. Il pourrait y avoir un groupe "Invités" qui donne accès aux
-            démonstrations, un groupe "Staff" pour la majorité des utilisateurs du CMS qui
-            réalisent la plupart du travail quotidien, un groupe "Éditeur" pour ceux qui sont
-            responsables de la publication, l'archivage, la relecture et la suppression, et enfin
-            un groupe "Administrateur" dont les tâches incluent toutes les tâches des autres
-            groupes plus des tâches de maintenance, de gestion des utilisateurs, configuration et
-            backup/export. Cet ensemble de permissions peut être représenté dans un registre de
-            rôles, permettant à chaque groupe d'hériter des privilèges des groupes "parents". Les
-            permissions peuvent être rendues de la manière suivante&#160;:
+            Les systèmes de gestion de contenu (ou <acronym>CMS</acronym>) vont pratiquement
+            toujours nécessiter une hiérarchie de permissions afin de déterminer les droits de
+            rédaction de ses utilisateurs. Il pourrait y avoir un groupe "Invités" qui donne accès
+            aux démonstrations, un groupe "Staff" pour la majorité des utilisateurs du
+            <acronym>CMS</acronym> qui réalisent la plupart du travail quotidien, un groupe
+            "Éditeur" pour ceux qui sont responsables de la publication, l'archivage, la relecture
+            et la suppression, et enfin un groupe "Administrateur" dont les tâches incluent toutes
+            les tâches des autres groupes plus des tâches de maintenance, de gestion des
+            utilisateurs, configuration et backup ou export. Cet ensemble de permissions peut être
+            représenté dans un registre de rôles, permettant à chaque groupe d'hériter des
+            privilèges des groupes "parents". Les permissions peuvent être rendues de la manière
+            suivante&#160;:
         </para>
 
         <table id="zend.acl.introduction.role_registry.table.example_cms_access_controls">
@@ -284,13 +284,13 @@ $acl->addRole(new Zend_Acl_Role('administrateur'));
         <title>Définir les Contrôles d'Accès</title>
 
         <para>
-            Maintenant que l'ACL contient les rôles nécessaires, on peut établir des règles
-            qui définissent comment les ressources accèdent aux rôles. Vous avez sans doute noté
-            que nous n'avons défini aucune ressource particulière pour cet exemple, ce qui est plus
-            simple pour illustrer comment les règles s'appliquent à toutes les ressources.
-            <classname>Zend_Acl</classname> fournit une implémentation dans laquelle les règles
-            doivent simplement être assignées du général au particulier, ce qui réduit le nombre de
-            règles spécifiques à ajouter. Ceci grâce à l'héritage.
+            Maintenant que l'<acronym>ACL</acronym> contient les rôles nécessaires, on peut établir
+            des règles qui définissent comment les ressources accèdent aux rôles. Vous avez sans
+            doute noté que nous n'avons défini aucune ressource particulière pour cet exemple, ce
+            qui est plus simple pour illustrer comment les règles s'appliquent à toutes les
+            ressources. <classname>Zend_Acl</classname> fournit une implémentation dans laquelle les
+            règles doivent simplement être assignées du général au particulier, ce qui réduit le
+            nombre de règles spécifiques à ajouter. Ceci grâce à l'héritage.
         </para>
 
         <note>
@@ -335,8 +335,9 @@ $acl->allow('administrateur');
 ]]></programlisting>
 
         <para>
-            Les valeurs <code>null</code> dans les appels <code>allow()</code> ci-dessus sont
-            utilisées pour indiquer que les règles s'appliquent à toutes les ressources.
+            Les valeurs <constant>NULL</constant> dans les appels <methodname>allow()</methodname>
+            ci-dessus sont utilisées pour indiquer que les règles s'appliquent à toutes les
+            ressources.
         </para>
     </sect2>
 
@@ -344,10 +345,10 @@ $acl->allow('administrateur');
         <title>Interroger les ACL</title>
 
         <para>
-            Nous avons maintenant une ACL flexible, qui peut être utilisée pour déterminer si
-            l'objet appelant a les permissions pour réaliser les fonctions au sein de l'application
-            web. Interroger l'ACL est assez simple en utilisant la méthode
-            <code>isAllowed()</code>&#160;:
+            Nous avons maintenant une <acronym>ACL</acronym> flexible, qui peut être utilisée pour
+            déterminer si l'objet appelant a les permissions pour réaliser les fonctions au sein de
+            l'application web. Interroger cette liste est assez simple en utilisant la méthode
+            <methodname>isAllowed()</methodname>&#160;:
         </para>
 
         <programlisting language="php"><![CDATA[

documentation/manual/fr/module_specs/Zend_Amf.xml

@@ -7,11 +7,11 @@
     <para>
         <classname>Zend_Amf</classname> fournit le support pour l'
         <ulink url="http://en.wikipedia.org/wiki/Action_Message_Format">Action Message
-        Format</ulink>(AMF) d'Adobe, permettant la communication entre le
+        Format</ulink>(<acronym>AMF</acronym>) d'Adobe, permettant la communication entre le
         <ulink url="http://en.wikipedia.org/wiki/Adobe_Flash_Player">Flash Player</ulink>d'Adobe et
-        PHP. De manière spécifique, il fournit une implémentation serveur pour gérer les requêtes
-        envoyées par le Flash Player au serveur et fait correspondre ces requêtes à des objets, à
-        des méthodes de classe et à des callbacks arbitraires.
+        <acronym>PHP</acronym>. De manière spécifique, il fournit une implémentation serveur pour
+        gérer les requêtes envoyées par le Flash Player au serveur et fait correspondre ces requêtes
+        à des objets, à des méthodes de classe et à des callbacks arbitraires.
     </para>
 
     <para>