fr doc XML updates.

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1865847 13f79535-47bb-0310-9956-ffa450edef68

2 files changed, 44 insertions, 44 deletions

diff --git a/docs/manual/mod/mod_authn_socache.xml.fr b/docs/manual/mod/mod_authn_socache.xml.fr
index a730b176b3..4286c31044 100644
--- a/docs/manual/mod/mod_authn_socache.xml.fr
+++ b/docs/manual/mod/mod_authn_socache.xml.fr
@@ -1,7 +1,7 @@
 <?xml version="1.0" encoding="UTF-8"?>
 <!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
 <?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
-<!-- English Revision: 1793933:1865402 (outdated) -->
+<!-- English Revision: 1865402 -->
 <!-- French translation : Lucien GENTIS -->
 <!-- Reviewed by : Vincent Deffontaines -->
 
@@ -47,28 +47,28 @@ la charge des serveurs d'arrière-plan</description>
     etc...), et où une requête pour cette page génère des centaines de
     sous-requêtes à effet immédiat pour des contenus supplémentaires
     authentifiés.</p>
-    <p>Pour résoudre ce problème, mod_authn_socache fournit une solution
-    qui permet de maintenir un cache des données d'authentification.</p>
+    <p>Pour résoudre ce problème, <module>mod_authn_socache</module> fournit une
+    solution qui permet de maintenir un cache des données
+    d'authentification.</p>
 </section>
 
 <section id="usage"><title>Utilisation</title>
-    <p>Le cache d'authentification doit être utilisé lorsque les
-    requêtes d'authentification induisent une charge significative sur le
-    serveur, le serveur d'arrière-plan ou le réseau. Cette mise en cache
-    n'apportera probablement aucune amélioration dans le cas d'une
-    authentification à base de fichier (<module>mod_authn_file</module>)
-    ou de base de données dbm (<module>mod_authn_dbm</module>) car ces
-    méthodes sont de par leur conception rapides et légères (la mise en
-    cache peut cependant s'avérer utile dans le cas où le fichier est
-    situé sur un montage réseau). Les fournisseurs d'authentification
-    basés sur SQL ou LDAP ont plus de chances de tirer parti de cette
-    mise en cache, en particulier lorsqu'un problème de performances est
-    détecté. <module>mod_authnz_ldap</module> gérant son propre cache,
-    seul <module>mod_authn_dbd</module> est concerné par notre sujet.</p>
+    <p>Le cache d'authentification doit être utilisé lorsque les requêtes
+    d'authentification induisent une charge significative sur le serveur, le
+    serveur d'arrière-plan ou le réseau. Cette mise en cache n'apportera
+    probablement aucune amélioration dans le cas d'une authentification à base
+    de fichier (<module>mod_authn_file</module>) ou de base de données dbm
+    (<module>mod_authn_dbm</module>) car ces méthodes sont de par leur
+    conception rapides et légères (la mise en cache peut cependant s'avérer
+    utile dans le cas où le fichier est situé sur un montage réseau). Les
+    fournisseurs d'authentification basés sur SQL ou LDAP ont plus de chances de
+    tirer parti de cette mise en cache, en particulier lorsqu'un problème de
+    performances est détecté. <module>mod_authnz_ldap</module> gérant son propre
+    cache, seul <module>mod_authn_dbd</module> est concerné par notre sujet.</p>
     <p>Les principales règles à appliquer pour la mise en cache sont :</p>
-    <ol><li>Inclure le fournisseur pour lequel vous voulez effectuer une
-    mise en cache dans une directive
-    <directive>AuthnCacheProvideFor</directive>.</li>
+    <ol><li>Inclure le fournisseur pour lequel vous voulez effectuer une mise en
+    cache dans une directive <directive
+    module="mod_authn_socache">AuthnCacheProvideFor</directive> .</li>
         <li>Mettre <var>socache</var> avant le fournisseur pour lequel
 	vous voulez effectuer une mise en cache dans votre directive
 	<directive module="mod_auth_basic">AuthBasicProvider</directive>
@@ -96,12 +96,11 @@ AuthnCacheSOCache dbm
 </section>
 
 <section id="dev"><title>La mise en cache avec les modules tiers</title>
-    <p>Les développeurs de modules doivent savoir que la mise en cache
-    avec mod_authn_socache doit être activée dans leurs modules. La
-    fonction de l'API <var>ap_authn_cache_store</var> permet de
-    mettre en cache les données d'authentification qu'un fournisseur
-    vient de rechercher ou de générer. Vous trouverez des exemples
-    d'utilisation à <a
+    <p>Les développeurs de modules doivent savoir que la mise en cache avec
+    <module>mod_authn_socache</module> doit être activée dans leurs modules. La
+    fonction de l'API <var>ap_authn_cache_store</var> permet de mettre en cache
+    les données d'authentification qu'un fournisseur vient de rechercher ou de
+    générer. Vous trouverez des exemples d'utilisation à <a
     href="http://svn.eu.apache.org/viewvc?view=revision&amp;revision=957072"
     >r957072</a>, où trois fournisseurs authn sont activés pour la mise
     en cache.</p>
@@ -157,10 +156,11 @@ mise en cache</description>
 <override>AuthConfig</override>
 
 <usage>
-    <p>Cette directive permet de spécifier un ou plusieurs fournisseurs
-    pour le(s)quel(s) on veut effectuer une mise en cache. Les données
+    <p>Cette directive permet de spécifier un ou plusieurs fournisseurs pour
+    le(s)quel(s) on veut effectuer une mise en cache. Les données
     d'authentification trouvées par un fournisseur non spécifié dans une
-    directive AuthnCacheProvideFor ne seront pas mises en cache.</p>
+    directive <directive>AuthnCacheProvideFor</directive> ne seront pas mises en
+    cache.</p>
 
     <p>Par exemple, pour mettre en cache les données d'authentification
     trouvées par <module>mod_authn_dbd</module> ou par un fournisseur
@@ -176,7 +176,7 @@ AuthnCacheProvideFor dbd mon-fournisseur
 <name>AuthnCacheTimeout</name>
 <description>Définit une durée de vie pour les entrées du cache</description>
 <syntax>AuthnCacheTimeout <var>durée-de-vie</var> (secondes)</syntax>
-<default>300 (5 minutes)</default>
+<default>AuthnCacheTimeout 300 (5 minutes)</default>
 <contextlist><context>directory</context><context>.htaccess</context></contextlist>
 <override>AuthConfig</override>
 
@@ -204,8 +204,8 @@ AuthnCacheProvideFor dbd mon-fournisseur
 <name>AuthnCacheContext</name>
 <description>Spécifie une chaîne de contexte à utiliser dans la clé du
 cache</description>
-<syntax>AuthnCacheContext <var>directory|server|chaîne-personnalisée</var></syntax>
-<default>directory</default>
+<syntax>AuthnCacheContext directory|server|<var>custom-string</var></syntax>
+<default>AuthnCacheContext directory</default>
 <contextlist><context>directory</context></contextlist>
 
 <usage>
@@ -215,12 +215,12 @@ cache</description>
     construction d'une clé de cache. Ceci permet de lever l'ambiguïté
     entre plusieurs noms d'utilisateurs identiques servant différentes
     zones d'authentification sur le serveur.</p>
-    <p>Il y a deux valeurs spéciales pour le paramètre : <var>directory</var>,
+    <p>Il y a deux valeurs spéciales pour le paramètre : <code>directory</code>,
     qui utilise le contexte de répertoire de la requête comme chaîne, et
-    <var>server</var>, qui utilise le nom du serveur virtuel.</p>
-    <p>La valeur par défaut est <var>directory</var>, qui est aussi la
-    définition la plus courante. Ceci est cependant loin d'être optimal,
-    car par exemple, <var>$app-base</var>, <var>$app-base/images</var>,
+    <code>server</code>, qui utilise le nom du serveur virtuel.</p> <p>La valeur
+    par défaut est <code>directory</code>, qui est aussi la définition la plus
+    courante. Ceci est cependant loin d'être optimal, car par exemple,
+    <var>$app-base</var>, <var>$app-base/images</var>,
     <var>$app-base/scripts</var> et <var>$app-base/media</var>
     possèderont chacun leur propre clé de cache. Il est préférable
     d'utiliser le fournisseur de mot de passe : par exemple un fichier
diff --git a/docs/manual/mod/mod_deflate.xml.fr b/docs/manual/mod/mod_deflate.xml.fr
index c27776a8e1..2e99abad78 100644
--- a/docs/manual/mod/mod_deflate.xml.fr
+++ b/docs/manual/mod/mod_deflate.xml.fr
@@ -1,7 +1,7 @@
 <?xml version="1.0" encoding="UTF-8" ?>
 <!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
 <?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
-<!-- English Revision: 1853637:1865363 (outdated) -->
+<!-- English Revision: 1865363 -->
 <!-- French translation : Lucien GENTIS -->
 <!-- Reviewed by : Vincent Deffontaines -->
 
@@ -42,8 +42,8 @@ client</description>
   <p>Le seul codage supporté est <code>gzip</code> afin d'assurer une complète
   compatibilité avec les anciens navigateurs. Le codage <code>deflate</code>
   n'est donc pas supporté ; voir à ce sujet la <a
-  href="http://www.gzip.org/zlib/zlib_faq.html#faq38">documentation de zlib</a>
-  pour une explication détaillée.
+  href="https://zlib.net/zlib_faq.html#faq39">documentation de zlib</a> pour une
+  explication détaillée.
   </p>
 </section>
 
@@ -205,17 +205,17 @@ SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ no-gzip
 <section id="precompressed"><title>Servir du contenu précompressé</title>
 
     <p>Comme <module>mod_deflate</module> recompresse le contenu demandé à
-    chaque requête, il est possible de gagner en performances en
-    précompressant ce contenu, et en forçant mod_deflate à servir ce
-    contenu précompressé sans avoir à le recompresser à chaque requête.
-    Pour ce faire, utilisez une configuration du style :</p>
+    chaque requête, il est possible de gagner en performances en précompressant
+    ce contenu, et en forçant <module>mod_deflate</module> à servir ce contenu
+    précompressé sans avoir à le recompresser à chaque requête.  Pour ce faire,
+    utilisez une configuration du style :</p>
 
     <highlight language="config">
 &lt;IfModule mod_headers.c&gt;
     # Servir des fichiers JS et CSS compressés avec gzip, s'ils existent, et
     # si le client accepte gzip.
     RewriteCond "%{HTTP:Accept-encoding}" "gzip"
-    RewriteCond "%{REQUEST_FILENAME}\.gz" "-s"
+     RewriteCond "%{REQUEST_FILENAME}\.gz" -s
     RewriteRule "^(.*)\.(css|js)"              "$1\.$2\.gz" [QSA]
 
     # Servir des types de contenus corrects, et empêcher mod_deflate