[Trad] [svn:pgfr] r1118 - traduc/trunk/slony

Ven 8 Aou 09:47:39 CEST 2008

Author: daamien
Date: 2008-08-08 09:47:39 +0200 (Fri, 08 Aug 2008)
New Revision: 1118

Modified:
   traduc/trunk/slony/ddlchanges.xml
   traduc/trunk/slony/faq.xml
   traduc/trunk/slony/intro.xml
   traduc/trunk/slony/logshipping.xml
   traduc/trunk/slony/slon.xml
   traduc/trunk/slony/slonik_ref.xml
Log:
Slony : corrections de qq coquilles


Modified: traduc/trunk/slony/ddlchanges.xml
===================================================================

--- traduc/trunk/slony/ddlchanges.xml	2008-08-08 07:46:52 UTC (rev 1117)
+++ traduc/trunk/slony/ddlchanges.xml	2008-08-08 07:47:39 UTC (rev 1118)
@@ -204,16 +204,16 @@
 &slony1; <emphasis>ne</emphasis> peut rÃ©pliquer, tels que les fonctions
 stockÃ©es. Et il est assez probable que cela vous posera problÃ¨me de propager ces mises Ã  jour
 en association avec un jeu de rÃ©plication oÃ¹ <command>EXECUTE SCRIPT</command> 
-va vÃ©rouiller tout un jeu de tables qui n'ont pas rÃ©ellement besoin de l'Ãªtre.
+va vÃ©rouiller tout un jeu de tables qui n'ont pas rÃ©ellement besoin de l'Ãªtre.</para>
 
 <para> Si vous propagez une procÃ©dure stockÃ©e qui n'est pas utilisÃ©e tout le temps
 (de telle sorte que vous acceptiez une petite desynchronisation entre les noeuds), alors vous pouvez
 simplement la soumettre Ã  chaque noeud par l'intermÃ©diare d'une commande <application>psql</application>,
-ne faisant pas d'utilisation particuliÃ¨re de &slony1;
+ne faisant pas d'utilisation particuliÃ¨re de &slony1;</para>
 
 <para>Si vous <emphasis>avez</emphasis> besoin d'une parfaite synchronisation sur l'ensemble des noeuds,
 a ce moment lÃ , vous devez utiliser <command>EXECUTE SCRIPT</command>
- pour verouiller vos travaux.</para></listitem>
+ pour verrouiller vos travaux.</para></listitem>
 
 <listitem><para> Vous pouvez avoir besoin d'index suplÃ©mentaires sur quelques
 noeuds rÃ©pliquÃ©s pour accroÃ®tre les performances.</para>
@@ -289,24 +289,10 @@
 de remettre ces machines a niveau, de facon a ce que le script
  <emphasis> s'exÃ©cute</emphasis>  sans erreur.
 
-Attention <para> Si le script contient un  <command> COMMIT;
+<warning>Attention <para> Si le script contient un  <command> COMMIT;
 </command> n'importe ou avant le <command> ROLLBACK; </command>, cela va 
 effectuer des changements auxquels vous ne vous attendiez pas.  </para>
 </warning></para>
 </sect2>
 </sect1>
-<!-- Keep this comment at the end of the file
-Local variables:
-mode:sgml
-sgml-omittag:nil
-sgml-shorttag:t
-sgml-minimize-attributes:nil
-sgml-always-quote-attributes:t
-sgml-indent-step:1
-sgml-indent-data:t
-sgml-parent-document:"slony.sgml"
-sgml-exposed-tags:nil
-sgml-local-catalogs:("/usr/lib/sgml/catalog")
-sgml-local-ecat-files:nil
-End:
--->
+

Modified: traduc/trunk/slony/faq.xml
===================================================================
--- traduc/trunk/slony/faq.xml	2008-08-08 07:46:52 UTC (rev 1117)
+++ traduc/trunk/slony/faq.xml	2008-08-08 07:47:39 UTC (rev 1118)
@@ -1,75 +1,74 @@
 <?xml version="1.0" encoding="UTF-8"?>
-<!-- Dernière modifications
+<!-- DerniÃ¨re modifications
      le       $Date$
      par      $Author$
-     révision $Revision$ -->
+     rÃ©vision $Revision$ -->
 
 <qandaset>
-<indexterm><primary>Questions Fréquemment Posées à  propos de &slony1;</primary></indexterm>
+<indexterm><primary>Foire Aux Questions de &slony1;</primary></indexterm>
 
 <qandadiv id="faqcompiling"><title> &slony1; FAQ: Monter et Installer &slony1; </title>
 
 <qandaentry>
 
 <question><para> J'utilise <productname> Frotznik Freenix
-4.5</productname>, avec son <acronym>FFPM</acronym> (Frotznik Freenix
-Package Manager) gestionnaire des paquetage système.  L'arrivée de
-<acronym>FFPM</acronym> c'est l'introduction des paquetages pour &postgres; 7.4.7, lequel je suis actuellement
-entrain d'utiliser pour ma base de données, mais qui n'inclut pas encore les paquetages &slony1.
-Comment puis-je rajouter &slony1; à cette configuration?  </para>
+4.5</productname>, avec son systÃ¨me de gestion de paquetages <acronym>FFPM</acronym> (Frotznik Freenix Package Manager).  Il existe des paquets
+<acronym>FFPM</acronym> pour &postgres; 7.4.7, que j'utilise actuellement
+comme base de donnÃ©es, mais il n'y a pas encore de paquetages &slony1;.
+Comment puis-je rajouter &slony1; Ã  cette distribution ?  </para>
 </question>
 
 
 <answer><para> <productname>Frotznik Freenix</productname> c'est nouveau pour moi,
-alors il est un peu dangereux, pour donner des réponses définitives vraiment concise et rapides.  </para>
+alors il est un peu dangereux, de donner une rÃ©ponse dÃ©finitive, concise et rapide.  </para>
 
-<para> Les réponses différent légèrement t entre les diverses combinaisons de versions entre
-&postgres; et &slony1; Il est légérement plus faciles, dans les versions récentes, de faire face à ce genre de question 
-que dans les versions plus anciennes. En général, vous devez presque certainement recompiler &slony1; depuis les sources; selon les versions
+<para> Les rÃ©ponses diffÃ©rent lÃ©gÃ¨rement selon les diverses combinaisons de versions entre
+&postgres; et &slony1; Il est lÃ©gÃ©rement plus facile, avec les versions rÃ©centes, de faire face Ã  ce genre de questions qu'avec les versions plus anciennes. En gÃ©nÃ©ral, vous devez presque certainement recompiler &slony1; depuis les sources; selon les versions
 des deux composants &slony1; et &postgres;, vous
-<emphasis>devez</emphasis> également recompiler &postgres; à partir de zéro.
-(Si vous devez d' <emphasis> utilisez </emphasis> le &postgres; compiler
-est un autre problème; vous n'avez probablement pas besoin...) </para>
+<emphasis>devez</emphasis> Ã©galement recompiler &postgres; Ã  partir de zÃ©ro.
+(Savoir si vous devez <emphasis> utilisez </emphasis> la version compilÃ©e de &postgres; 
+est un autre problÃ¨me; en gÃ©nÃ©ral ce n'est pas le cas...) </para>
 
 <itemizedlist>
 
-<listitem><para> &slony1; la version 1.0.5 et ultérieur nécessite avoir complètement
-configuré &postgres; ayant les sources installées, afin de recompiler
+<listitem><para> &slony1; la version 1.0.5 et ultÃ©rieur nÃ©cessite d'avoir une version  complÃ¨tement configurÃ©es des sources de &postgres;, afin de recompiler
 &slony1;.</para>
 
+TODO
+
 <para> <emphasis>Si tout va bien </emphasis> vous pouvez refaire la configuration,  
-ceci contre la configuration utilisée nativement par la paquetage d'origine, en utilisant la 
+ceci contre la configuration utilisÃ©e nativement par la paquetage d'origine, en utilisant la 
 version de &postgres; en utilisant la commande
 <command> pg_config --configure</command>. </para> </listitem>
 
-<listitem> <para> &slony1; La version 1.1 simplifie considérablement les choses;
-dans la mesure où vous êtes dispensé d'avoir la version totale de &postgres; en sources, mais qui,
-au lieu de cela, se réfère à l'endroit où &postgres; ses librairies,
-les binaires, la configuration, ainsi que <command> les fichiers #include </command> sont déjà installés.
+<listitem> <para> &slony1; La version 1.1 simplifie considÃ©rablement les choses;
+dans la mesure oÃ¹ vous Ãªtes dispensÃ© d'avoir la version totale de &postgres; en sources, mais qui,
+au lieu de cela, se rÃ©fÃ¨re Ã  l'endroit oÃ¹ &postgres; ses librairies,
+les binaires, la configuration, ainsi que <command> les fichiers #include </command> sont dÃ©jÃ  installÃ©s.
 </para> </listitem>
 
-<listitem><para> &postgres; 8.0 et supérieur est généralement plus facile voire idéal
-car comprenant déjà une <quote>installation par défaut</quote> incluant la totalité des fichiers d'inclusion
+<listitem><para> &postgres; 8.0 et supÃ©rieur est gÃ©nÃ©ralement plus facile voire idÃ©al
+car comprenant dÃ©jÃ  une <quote>installation par dÃ©faut</quote> incluant la totalitÃ© des fichiers d'inclusion
 <command> #include </command>.  </para>
 
-<para> Si vous utilisez les versions antérieur de&postgres;, vous êtes sensé avoir trouvé
+<para> Si vous utilisez les versions antÃ©rieur de&postgres;, vous Ãªtes sensÃ© avoir trouvÃ©
 toutes les sources et de les installer, si le paquetage d'installation ne l'a pas fait pour vous <quote> sur le serveur,
-les fichiers d'inclusions<command>#include</command></quote>, peuvent être réinstaller via la commande
+les fichiers d'inclusions<command>#include</command></quote>, peuvent Ãªtre rÃ©installer via la commande
 <command> make install-all-headers </command>.</para>
 </listitem>
 
 </itemizedlist>
 
-<para> En effet, le <quote>cas dérangeant </quote> est un scénario où 
-vous utilisez une version de &slony1; antérieur à 1.1 avec une
+<para> En effet, le <quote>cas dÃ©rangeant </quote> est un scÃ©nario oÃ¹ 
+vous utilisez une version de &slony1; antÃ©rieur Ã  1.1 avec une
 <quote>vieille</quote> version de &postgres;, dans ce cas vous pouvez comptez devoir compiler &postgres;
-à partir de zéro afin d'avoir tout les pré requis de &slony1; Recompile sera un passage obligé même si  
-vous utilisez un version<quote>paquetée</quote> de &postgres;.</para>
+Ã  partir de zÃ©ro afin d'avoir tout les prÃ© requis de &slony1; Recompile sera un passage obligÃ© mÃªme si  
+vous utilisez un version<quote>paquetÃ©e</quote> de &postgres;.</para>
 
-<para> Si vous employez une version récente de &postgres; et une version récente de &slony1;,
-alors les dependences peuvent être assez petits, et vous ne pouvez pas avoir besoin 
-complémentaire des sources &postgres;.  Ces dispositions devraient soulager la mise en production de
-paquetage de &slony1;  de sorte que vous pourriez même pouvoir espérer éviter la compilations
+<para> Si vous employez une version rÃ©cente de &postgres; et une version rÃ©cente de &slony1;,
+alors les dependences peuvent Ãªtre assez petits, et vous ne pouvez pas avoir besoin 
+complÃ©mentaire des sources &postgres;.  Ces dispositions devraient soulager la mise en production de
+paquetage de &slony1;  de sorte que vous pourriez mÃªme pouvoir espÃ©rer Ã©viter la compilations
 de &slony1;.</para>
 
 </answer>
@@ -87,20 +86,20 @@
 </screen>
 </para></question>
 
-<answer><para> Vous exécutez certainement une version &postgres; 7.4
-ou ultérieur, où les en-têtes de serveur ne sont pas installé par défaut, 
+<answer><para> Vous exÃ©cutez certainement une version &postgres; 7.4
+ou ultÃ©rieur, oÃ¹ les en-tÃªtes de serveur ne sont pas installÃ© par dÃ©faut, 
 il vous suffi dans ce cas de lancer juste 
 une commande <command>make install</command> de &postgres;.</para>
 
-<para> Vous avez besoin d'installer les en-têtes de serveur lors d'installation de &postgres;
+<para> Vous avez besoin d'installer les en-tÃªtes de serveur lors d'installation de &postgres;
 via la commande <command>make install-all-headers</command>.
 
 </para> </answer> </qandaentry>
 
 <qandaentry id="threadsafety">
 
-<question><para> &slony1; semble se compiler correctement; maintenant, lorsque j'exécute un
-&lslon;, certain évènement démarrent autour, mais la réplication ne se met pas 
+<question><para> &slony1; semble se compiler correctement; maintenant, lorsque j'exÃ©cute un
+&lslon;, certain Ã©vÃ¨nement dÃ©marrent autour, mais la rÃ©plication ne se met pas 
 route.</para>
 
 <para> Slony logs might look like the following:
@@ -118,7 +117,7 @@
 </screen>
 </para>
 
-<para> Parfois il peut se manifester de manières suivante ...
+<para> Parfois il peut se manifester de maniÃ¨res suivante ...
 
 <screen>
 ERROR  remoteListenThread_2: "select ev_origin, ev_seqno, ev_timestamp,
@@ -132,32 +131,32 @@
 </question>
 
 <answer><para>Sur AIX et Solaris (et probablement sur d'autre OS), les deux
-&slony1; <emphasis>et &postgres;</emphasis> doivent être compilés avec l'
+&slony1; <emphasis>et &postgres;</emphasis> doivent Ãªtre compilÃ©s avec l'
 <option>--enable-thread-safety</option> option.  Le message ci-dessus arrive lorsque la compilation
-de &postgres; n'a pas fait appel à cette option.</para>
+de &postgres; n'a pas fait appel Ã  cette option.</para>
 
 <para>Le disfonctionnement ici vient du fait que le libc (threadsafe) et libpq
-(non-threadsafe) utilisent des emplacement de mémoire différente pour le code erreur, ainsi en 
-laissant la requête échouer.</para>
+(non-threadsafe) utilisent des emplacement de mÃ©moire diffÃ©rente pour le code erreur, ainsi en 
+laissant la requÃªte Ã©chouer.</para>
 
-<para>Des problèmes de ce genre sur AIX et sur Solaris, surviennent avec des régularités surprenantes.
-; l'erreur devrais prendre quelque choses ressemblant à un code <quote>objet ou à un code d'audit</quote> qui sont compilé
+<para>Des problÃ¨mes de ce genre sur AIX et sur Solaris, surviennent avec des rÃ©gularitÃ©s surprenantes.
+; l'erreur devrais prendre quelque choses ressemblant Ã  un code <quote>objet ou Ã  un code d'audit</quote> qui sont compilÃ©
 make sure that <emphasis>ALL</emphasis> of the necessary components have been
-et linké avec l'option <option>--enable-thread-safety</option>.</para>
+et linkÃ© avec l'option <option>--enable-thread-safety</option>.</para>
 
-<para>Pour le moment, je me concentre sur le problème de
-<envar>LD_LIBRARY_PATH</envar> si c'est défini, sur Solaris, pour pointer sur les
-librairies depuis une version ancienne de &postgres; afin de recompiler. Cela signifie que même si
-la base <emphasis>a été</emphasis> compilée avec l'
+<para>Pour le moment, je me concentre sur le problÃ¨me de
+<envar>LD_LIBRARY_PATH</envar> si c'est dÃ©fini, sur Solaris, pour pointer sur les
+librairies depuis une version ancienne de &postgres; afin de recompiler. Cela signifie que mÃªme si
+la base <emphasis>a Ã©tÃ©</emphasis> compilÃ©e avec l'
 <option>--enable-thread-safety</option>, et que
-<application>slon</application> a été recompilé à nouveau, avec l'édition de lien dynamique de
+<application>slon</application> a Ã©tÃ© recompilÃ© Ã  nouveau, avec l'Ã©dition de lien dynamique de
 <application>slon</application> pointant sur un 
-<quote>ancienne mauvaise version de thread-unsafe,</quote> et alors slon n'a pas fonctionné.  Ceci n'était pas clair
-que c'était le cas, jusqu'à ce que je rexécute <command>ldd</command>
-à nouveau <application>slon</application>.</para> </answer>
+<quote>ancienne mauvaise version de thread-unsafe,</quote> et alors slon n'a pas fonctionnÃ©.  Ceci n'Ã©tait pas clair
+que c'Ã©tait le cas, jusqu'Ã  ce que je rexÃ©cute <command>ldd</command>
+Ã  nouveau <application>slon</application>.</para> </answer>
 
 <answer><para> A noter que la version   7.4.2 de libpq, sur Solaris exige, un nouveau patch
-de <link linkend="threadpatch">  </link> ; Le requis est également demandé pour &postgres; version 8.0.
+de <link linkend="threadpatch">  </link> ; Le requis est Ã©galement demandÃ© pour &postgres; version 8.0.
 </para>
 </answer>
 </qandaentry>
@@ -165,77 +164,77 @@
 <qandaentry id="pg81funs">
 
 <question> <para> Je suis en train de migrer sur une nouvelle version de &slony1;
-et je me débat avec un problème de<xref
-linkend="stmtupdatefunctions"/>.  Lors d'exécution de<xref
+et je me dÃ©bat avec un problÃ¨me de<xref
+linkend="stmtupdatefunctions"/>.  Lors d'exÃ©cution de<xref
 linkend="stmtupdatefunctions"/>, mon
 <application>postmaster</application> plante dessus avec un Signal 11.
-Le fichier log ne contient aucune erreur, relatives à
+Le fichier log ne contient aucune erreur, relatives Ã 
 &postgres; les logs indiquent que, yes indeed, the postmaster fell
 over.</para>
 
-<para> En scrutant le fichier core avec un débuguer, on constate que
+<para> En scrutant le fichier core avec un dÃ©buguer, on constate que
 l'incident survient lors de la validation d'une transaction. </para>
 
 <para> Pour infos je suis sur &postgres; 8.1.[0-3]. </para>
 </question>
 
-<answer> <para> Désagréablement l'ancienne versions de &postgres; 8.1 avait un problème
-où lorsque vous  aviez besoin de redéfinir une fonction (comme , say,
-<function>upgradeSchema(text)</function>), et que après, dans la même session de transaction
-, vous exécutiez la même fonction, le
+<answer> <para> DÃ©sagrÃ©ablement l'ancienne versions de &postgres; 8.1 avait un problÃ¨me
+oÃ¹ lorsque vous  aviez besoin de redÃ©finir une fonction (comme , say,
+<function>upgradeSchema(text)</function>), et que aprÃ¨s, dans la mÃªme session de transaction
+, vous exÃ©cutiez la mÃªme fonction, le
 <application>postmaster</application> tombait en erreur, et que la
 transaction ne pouvait se valider.  </para>
 
 <para> La commande &lslonik; <xref linkend="stmtupdatefunctions"/>
-fonctionne de cette manière; dans la même transaction, essayez ceci:
+fonctionne de cette maniÃ¨re; dans la mÃªme transaction, essayez ceci:
 
 <itemizedlist>
 <listitem><para> Charger les nouvelles fonctions (depuis <filename>slony1_funcs.sql</filename>), notamment comprenant <function>upgradeSchema(text)</function>.
 </para> </listitem>
-<listitem><para> Lancer <function>upgradeSchema(text)</function> pour effectuer la migration nécessaire des schémas de la base. </para> </listitem>
+<listitem><para> Lancer <function>upgradeSchema(text)</function> pour effectuer la migration nÃ©cessaire des schÃ©mas de la base. </para> </listitem>
 <listitem><para> Notifier au pro cesses &lslon; le fait de changement de la configuration.</para> </listitem>
 </itemizedlist>
 </para>
 
 <para> Malheureusement, en &postgres; 8.1.0, 8.1.1, 8.1.2, et 8.1.3,
-ceci est conflictuel avec un bug où l'utilisation et la modification d'une fonction plpgsql au sein de la même transaction
-lié à un plantage. </para>
+ceci est conflictuel avec un bug oÃ¹ l'utilisation et la modification d'une fonction plpgsql au sein de la mÃªme transaction
+liÃ© Ã  un plantage. </para>
 
-<para> Plusieurs contournements sont à envisager. </para>
+<para> Plusieurs contournements sont Ã  envisager. </para>
 
 </answer>
 
-<answer> <para> La réponse privilégiée serais de dire migrer &postgres; en 
-version 8.1.4 ou supérieur. Les changements mineurs du noyau n'entraîne pas de
+<answer> <para> La rÃ©ponse privilÃ©giÃ©e serais de dire migrer &postgres; en 
+version 8.1.4 ou supÃ©rieur. Les changements mineurs du noyau n'entraÃ®ne pas de
 reconstruction de la base; ceci devrait simplement exiger d'installer un noyau 8.1.x 
-en redémarrant les <application>postmaster</application> avec cette nouvelle version.  </para>
+en redÃ©marrant les <application>postmaster</application> avec cette nouvelle version.  </para>
 </answer>
 
-<answer><para> Si cette solution ne convient pas, il est possible d'effectuer une série de transaction  <quote>à la main</quote>, 
-l'équivalent de ce que &lslonik; aurait fait pour cette migration. </para>
+<answer><para> Si cette solution ne convient pas, il est possible d'effectuer une sÃ©rie de transaction  <quote>Ã  la main</quote>, 
+l'Ã©quivalent de ce que &lslonik; aurait fait pour cette migration. </para>
 
 <itemizedlist>
 <listitem><para> Prendre <filename>slony1_funcs.sql</filename> et faire trois remplacement dans ce fichier: </para> 
 
 <itemizedlist>
 <listitem><para> Remplacer <quote>@CLUSTERNAME@</quote>avec le nom du cluster</para> </listitem>
-<listitem><para> Remplacer <quote>@MODULEVERSION@</quote> avec la version littérale de &slony1; comme <quote>1.2.10</quote> </para> </listitem>
+<listitem><para> Remplacer <quote>@MODULEVERSION@</quote> avec la version littÃ©rale de &slony1; comme <quote>1.2.10</quote> </para> </listitem>
 <listitem><para> Remplacer <quote>@NAMESPACE@</quote> avec <quote>double-quoted</quote> nom du cluster, comme "_MyCluster" </para> </listitem>
 </itemizedlist>
 </listitem>
-<listitem><para> Recharger cet<quote>remis à niveau</quote> de jeux de fonctions dans la base.</para> </listitem>
-<listitem><para> Exécuter la fonction stockée via <command>select <function>upgradeSchema('1.2.7')</function>; </command>, 
-en supposant que la précédente version de &slony1; en cours était celle de 1.2.7. </para> </listitem>
-<listitem><para> Rechargement total des processes &lslon; sera probablement une sage  décision après ce genre de <quote>chirurgie.</quote> </para> </listitem>
+<listitem><para> Recharger cet<quote>remis Ã  niveau</quote> de jeux de fonctions dans la base.</para> </listitem>
+<listitem><para> ExÃ©cuter la fonction stockÃ©e via <command>select <function>upgradeSchema('1.2.7')</function>; </command>, 
+en supposant que la prÃ©cÃ©dente version de &slony1; en cours Ã©tait celle de 1.2.7. </para> </listitem>
+<listitem><para> Rechargement total des processes &lslon; sera probablement une sage  dÃ©cision aprÃ¨s ce genre de <quote>chirurgie.</quote> </para> </listitem>
 </itemizedlist>
 </answer>
 </qandaentry>
 
 <qandaentry>
-<question> <para> Problème d'installation sur Fedora/x86-64 </para>
+<question> <para> ProblÃ¨me d'installation sur Fedora/x86-64 </para>
 
-<para> Lorsqu'on essaie de configurer &slony1; sur système Fedora x86-64,
-où <application>yum</application> a été utilisé pour une installation du paquetage
+<para> Lorsqu'on essaie de configurer &slony1; sur systÃ¨me Fedora x86-64,
+oÃ¹ <application>yum</application> a Ã©tÃ© utilisÃ© pour une installation du paquetage
 <filename>postgresql-libs.x86_64</filename>, le message suivant se manifeste :
 
 <screen>
@@ -244,69 +243,69 @@
  and thus not supported by Slony-I.
 </screen></para>
 
-<para> Ceci arrive avec &postgres; 8.2.5, ce qui est certainement un peu plus récent que
+<para> Ceci arrive avec &postgres; 8.2.5, ce qui est certainement un peu plus rÃ©cent que
 7.3. </para>
 </question>
 
-<answer> <para> <application>configure</application> est à la recherche de ce directif 
-en compilant un petit programme requis, pour lequel il est appelé, et 
-vérifie la compilation se passe bien. Avec la ligne de commande <command>gcc</command>
+<answer> <para> <application>configure</application> est Ã  la recherche de ce directif 
+en compilant un petit programme requis, pour lequel il est appelÃ©, et 
+vÃ©rifie la compilation se passe bien. Avec la ligne de commande <command>gcc</command>
 il utilise <command>-lpq</command> pour chercher la librairie. </para>
 
 
-<para> Malheureusement, ce paquetage fait défaut depuis le lien symbolique, de
-<filename>/usr/lib64/libpq.so</filename> à
+<para> Malheureusement, ce paquetage fait dÃ©faut depuis le lien symbolique, de
+<filename>/usr/lib64/libpq.so</filename> Ã 
 <filename>libpq.so.5.0</filename>; c'est pourquoi il plante sur libpq.  
-Le <emphasis>vrai</emphasis> problème c'est que le compilateur n'arrive pas à trouver une
-librairie pour l'édition de lien, et non pas que libpq est absent et qui a manqué à l'appel.
+Le <emphasis>vrai</emphasis> problÃ¨me c'est que le compilateur n'arrive pas Ã  trouver une
+librairie pour l'Ã©dition de lien, et non pas que libpq est absent et qui a manquÃ© Ã  l'appel.
 </para>
 
-<para> Eventuellement il faudra remonter ces informations vers ceux qui gèrent le paquetage
+<para> Eventuellement il faudra remonter ces informations vers ceux qui gÃ¨rent le paquetage
 <filename>postgresql-libs.x86_64</filename>. </para>
 </answer>
 
-<answer> <para> Notez que ce même symptôme peut être révélateur des problèmes semblables de ce genre 
-de configuration système. Les mauvais liens symboliques, les mauvaises permissions, le mauvais comportement
-de la part de votre compilateur C, tout peuvent potentiellement mener à ce même message d'erreur. </para> 
+<answer> <para> Notez que ce mÃªme symptÃ´me peut Ãªtre rÃ©vÃ©lateur des problÃ¨mes semblables de ce genre 
+de configuration systÃ¨me. Les mauvais liens symboliques, les mauvaises permissions, le mauvais comportement
+de la part de votre compilateur C, tout peuvent potentiellement mener Ã  ce mÃªme message d'erreur. </para> 
 
-<para> Ainsi si vous rencontrez cette erreur, vous aurez besoin de regarder le fichier log généré,
- <filename>config.log</filename>.  Cherchez par la bas, et regarder quel est le souci <emphasis>récemment</emphasis> rencontré.
-Ceci sera bénéfique, pour trouver la racine de l'épineux problème.</para>
+<para> Ainsi si vous rencontrez cette erreur, vous aurez besoin de regarder le fichier log gÃ©nÃ©rÃ©,
+ <filename>config.log</filename>.  Cherchez par la bas, et regarder quel est le souci <emphasis>rÃ©cemment</emphasis> rencontrÃ©.
+Ceci sera bÃ©nÃ©fique, pour trouver la racine de l'Ã©pineux problÃ¨me.</para>
 </answer>
 
 </qandaentry>
 
 </qandadiv>
 
-<qandadiv id="faqconnections"> <title> &slony1; FAQ: Problèmes relatifs aux connections</title>
+<qandadiv id="faqconnections"> <title> &slony1; FAQ: ProblÃ¨mes relatifs aux connections</title>
 <qandaentry>
 
 <question><para>Je cherche le nom de<envar>_clustername</envar>, et 
 il est introuvable.</para></question>
 
-<answer><para> Si le DNS sont erronés, alors l'instance &lslon;
+<answer><para> Si le DNS sont erronÃ©s, alors l'instance &lslon;
 ne pourra pas se connecter aux noeuds.</para>
 
-<para>Ceci mène aux fait que les noeuds seront introuvables.</para>
+<para>Ceci mÃ¨ne aux fait que les noeuds seront introuvables.</para>
 
-<para>Revérifier la configuration des connexions. D'ailleurs depuis <xref
-linkend="slon"/> le linkage avec libpq, vous devrez avoir le mot de passe généré 
- dans <filename> $HOME/.pgpass</filename>, partiellement reporté dans bonne/mauvais authentification ici.</para>
+<para>RevÃ©rifier la configuration des connexions. D'ailleurs depuis <xref
+linkend="slon"/> le linkage avec libpq, vous devrez avoir le mot de passe gÃ©nÃ©rÃ© 
+ dans <filename> $HOME/.pgpass</filename>, partiellement reportÃ© dans bonne/mauvais authentification ici.</para>
 </answer>
 </qandaentry>
 
 <qandaentry id="morethansuper">
-<question> <para> J'ai crée un compte <quote>super utilisateur</quote>,
-<command>slony</command>, pour exécuter les activités de réplications. Comme suggéré,
-je l'ai configuré comme super user, avec l'interrogation suivante : 
+<question> <para> J'ai crÃ©e un compte <quote>super utilisateur</quote>,
+<command>slony</command>, pour exÃ©cuter les activitÃ©s de rÃ©plications. Comme suggÃ©rÃ©,
+je l'ai configurÃ© comme super user, avec l'interrogation suivante : 
 <command>
 update pg_shadow set usesuper = 't' where usename in ('slony',
 'molly', 'dumpy');
 </command>
-(Cette même commande permet d'autoriser autres utilisateurs d'exécuter vacuums et
+(Cette mÃªme commande permet d'autoriser autres utilisateurs d'exÃ©cuter vacuums et
 sauvegarde).</para>
 
-<para> Malheureusement, je suis tombé en erreur, à chaque fois où je voulais souscrire à un nouveau ensemble.</para>
+<para> Malheureusement, je suis tombÃ© en erreur, Ã  chaque fois oÃ¹ je voulais souscrire Ã  un nouveau ensemble.</para>
 
 <programlisting>
 DEBUG1 copy_set 28661
@@ -319,12 +318,12 @@
 WARN   remoteWorkerThread_1: data copy for set 28661 failed - sleep 60 seconds
 </programlisting>
 
-<para> Celà a continué de se planter, à plusieurs reprise, juqsqu'à ce que 
+<para> CelÃ  a continuÃ© de se planter, Ã  plusieurs reprise, juqsqu'Ã  ce que 
 <application>slon</application> se connecte comme 
 <command>postgres</command> le faisait.</para>
 </question>
 
-<answer><para> Le problème est assez évident en soi; la permission sur la table de système est ignorée, <envar>pg_class</envar>.</para></answer>
+<answer><para> Le problÃ¨me est assez Ã©vident en soi; la permission sur la table de systÃ¨me est ignorÃ©e, <envar>pg_class</envar>.</para></answer>
 
 <answer><para> La <quote>solution</quote> est la suivante:</para>
 <programlisting>
@@ -332,7 +331,7 @@
 </programlisting>
 </answer>
 
-<answer><para> En version 8.1 et supérieur, vous avez aussi besoin de:</para>
+<answer><para> En version 8.1 et supÃ©rieur, vous avez aussi besoin de:</para>
 <programlisting>
 update pg_authid set rolcatupdate = 't', rolsuper='t' where rolname = 'slony';
 </programlisting>
@@ -350,9 +349,9 @@
 WARN	remoteWorkerThread_1: data copy for set 1 failed - sleep 60 seconds
 </screen></para></question>
 
-<answer> <para> Il y a évidemment un certain nombre de vieilles transactions bloquantes,
+<answer> <para> Il y a Ã©videmment un certain nombre de vieilles transactions bloquantes,
 de &slony1; restant depuis le traitement des synchros. Vous devriez jeter un coup d'oeil
-à pg_locks to see what's up:</para>
+Ã  pg_locks to see what's up:</para>
 
 <screen>
 sampledb=# select * from pg_locks where transaction is not null order by transaction;
@@ -363,32 +362,32 @@
 (2 rows)
 </screen>
 
-<para>See?  127314921 est en effet plus vieux que 127314958, et il est toujours en cours d'exécution.</para>
+<para>See?  127314921 est en effet plus vieux que 127314958, et il est toujours en cours d'exÃ©cution.</para>
 
 <para> Un long traitement G/LA,  s'emballe durant une interrogation
 <application>RT3</application>, avec
-<application>pg_dump</application>, toute les transaction semblent s'exécuter pour une période interminable.
-Jusqu'à ce que elles soient complétées ou bien interrompu, on verra alors le message d'erreur suivant:
+<application>pg_dump</application>, toute les transaction semblent s'exÃ©cuter pour une pÃ©riode interminable.
+Jusqu'Ã  ce que elles soient complÃ©tÃ©es ou bien interrompu, on verra alors le message d'erreur suivant:
 <quote> data copy
 for set 1 failed - sleep 60 seconds </quote>.</para>
 
  
-<para>D'ailleurs, s'il y a plus d'une base de données sur le cluster du &postgres;
-, et que la charge se déporte sur une autre base, ce qui mène à procéder aux<quote>transactions plus tôt que XID
-quoi que</quote> s'avérant encore en marche.  Le fait est que la base de donnée dissociée 
+<para>D'ailleurs, s'il y a plus d'une base de donnÃ©es sur le cluster du &postgres;
+, et que la charge se dÃ©porte sur une autre base, ce qui mÃ¨ne Ã  procÃ©der aux<quote>transactions plus tÃ´t que XID
+quoi que</quote> s'avÃ©rant encore en marche.  Le fait est que la base de donnÃ©e dissociÃ©e 
 sur le cluster n'est pas pertinente; &slony1; attendra
-jusqu'à ce que ces vieilles transactions se terminent.</para>
+jusqu'Ã  ce que ces vieilles transactions se terminent.</para>
 </answer>
 </qandaentry>
 
 
 <qandaentry>
-<question><para>Même chose que ce qui précède.  Ce que j'ai oublié de mentionner, aussi bien, 
-était que j'essayais d'ajouter 
-<emphasis>DEUX</emphasis> abonnés, concurremment.</para></question>
+<question><para>MÃªme chose que ce qui prÃ©cÃ¨de.  Ce que j'ai oubliÃ© de mentionner, aussi bien, 
+Ã©tait que j'essayais d'ajouter 
+<emphasis>DEUX</emphasis> abonnÃ©s, concurremment.</para></question>
 
 <answer><para> Cela ne peut marcher: &slony1; ne peut employer la commande
-<command>COPY</command> de manière concurrente.  voir 
+<command>COPY</command> de maniÃ¨re concurrente.  voir 
 <filename>src/slon/remote_worker.c</filename>, la fonction
 <function>copy_set()</function></para>
 
@@ -397,30 +396,30 @@
 postgres 2605100  205018	0 18:53:43  pts/3  3:13 postgres: postgres sampledb localhost COPY 
 </screen>
  
-<para>Ceci s'avère justement être une transaction de <command>COPY</command> 
-impliqué en installant l'abonnement pour un des noeuds. Tout a l'air bien; 
-le système s'occupe de configurer le premier abonné; il ne veut pas démarrer sur le second 
+<para>Ceci s'avÃ¨re justement Ãªtre une transaction de <command>COPY</command> 
+impliquÃ© en installant l'abonnement pour un des noeuds. Tout a l'air bien; 
+le systÃ¨me s'occupe de configurer le premier abonnÃ©; il ne veut pas dÃ©marrer sur le second 
 tant que le premier n'a pas fini son enregistrement.
-Cela représente une cause possible.</para>
+Cela reprÃ©sente une cause possible.</para>
 
-<para>Ceci a (peut-être malheureusement)comme conséquence que vous ne pouvez pas peupler
-deux esclaves concurremment pour un simple fournisseur. Vous devez souscrire un et un seul abonné à la fois,
-une fois qu'il a accompli l'abonnement,(copyant le contenu des table et autre) peut s'occuper de débuter l'enregistrement
-du deuxième.</para></answer>
+<para>Ceci a (peut-Ãªtre malheureusement)comme consÃ©quence que vous ne pouvez pas peupler
+deux esclaves concurremment pour un simple fournisseur. Vous devez souscrire un et un seul abonnÃ© Ã  la fois,
+une fois qu'il a accompli l'abonnement,(copyant le contenu des table et autre) peut s'occuper de dÃ©buter l'enregistrement
+du deuxiÃ¨me.</para></answer>
 </qandaentry>
 
-<qandaentry id="missingoids"> <question> <para> Nous somme souciés par quelques choses 
-car ne pouvant envisager de désinstaller entièrement une réplication du cluster slony 
-entre un maître et un esclave.</para>
+<qandaentry id="missingoids"> <question> <para> Nous somme souciÃ©s par quelques choses 
+car ne pouvant envisager de dÃ©sinstaller entiÃ¨rement une rÃ©plication du cluster slony 
+entre un maÃ®tre et un esclave.</para>
 
-<warning> <para><emphasis>ASSUREZ-VOUS QUE VOUS ARRÊTEZ L'EXECUTION DE VOS APPLICATIONS
+<warning> <para><emphasis>ASSUREZ-VOUS QUE VOUS ARRÃŠTEZ L'EXECUTION DE VOS APPLICATIONS
 SUR VOTRE BASE DE DONNEES MAITRE, LORS DE L'ELIMINATION D'UN MEMBRE DU
 CLUSTER</emphasis>, or at least re-cycle all your open connections
 after the event!  </para></warning>
 
-<para> Les connexions <quote>se renouvellent</quote> ou se rapportent à OIDs qui sont 
-tuées lors du lancement du script de désinstallation. Et vous obtiendrez 
-un bon nombre d'erreurs en conséquence…
+<para> Les connexions <quote>se renouvellent</quote> ou se rapportent Ã  OIDs qui sont 
+tuÃ©es lors du lancement du script de dÃ©sinstallation. Et vous obtiendrez 
+un bon nombre d'erreurs en consÃ©quenceÂ…
 </para>
 
 </question>
@@ -428,92 +427,92 @@
 <answer><para> Il y a deux sections notables de 
 &postgres; qui sont la mise en cache des plans d'interrogation et les OIDs:</para>
 <itemizedlist>
-<listitem><para> Préparer la requête</para></listitem>
+<listitem><para> PrÃ©parer la requÃªte</para></listitem>
 <listitem><para> Les fonctions pl/pgSQL </para></listitem>
 </itemizedlist>
 
-<para> En particulier le problème n'est pas que sous &slony1; en un; 
-se produirait quand de telles modifications importantes sont apportées aux fondements de base 
-de données. Il n'est pas imaginable que cela mène à perdre des données, mais de se voir confronté
-à une vague d'erreur relatives à OID.
+<para> En particulier le problÃ¨me n'est pas que sous &slony1; en un; 
+se produirait quand de telles modifications importantes sont apportÃ©es aux fondements de base 
+de donnÃ©es. Il n'est pas imaginable que cela mÃ¨ne Ã  perdre des donnÃ©es, mais de se voir confrontÃ©
+Ã  une vague d'erreur relatives Ã  OID.
 </para></answer>
 
-<answer><para> Le problème arrive lorsque vous utilisez une sorte de 
-<quote>pool de connexion</quote> qui essaie de les reconnecter à la fin.
-Si vous remettez l'application en route après ceci, des nouvelles connexions
-sont générées avec un <emphasis>nouveau</emphasis>plan d'interrogation, et qui 
-font disparaître les erreurs. Si votre pool de connexion tue les sessions, et en recrée de nouvelle,
-alors ces nouvelles session auront de <emphasis>nouveau</emphasis> plan d'exécution, et
-que les erreurs vont disparaître. </para></answer>
+<answer><para> Le problÃ¨me arrive lorsque vous utilisez une sorte de 
+<quote>pool de connexion</quote> qui essaie de les reconnecter Ã  la fin.
+Si vous remettez l'application en route aprÃ¨s ceci, des nouvelles connexions
+sont gÃ©nÃ©rÃ©es avec un <emphasis>nouveau</emphasis>plan d'interrogation, et qui 
+font disparaÃ®tre les erreurs. Si votre pool de connexion tue les sessions, et en recrÃ©e de nouvelle,
+alors ces nouvelles session auront de <emphasis>nouveau</emphasis> plan d'exÃ©cution, et
+que les erreurs vont disparaÃ®tre. </para></answer>
 
 En notre code nous laissons tomber le raccordement sur n'importe quelle 
-erreur nous ne peut pas tracer à un état prévu. Ceci réutiliserait par la 
-suite tous les raccordements sur de tels problèmes inattendus après juste une 
-erreur par raccordement. Naturellement si l'erreur apprête car une violation de 
-contrainte qui est un état identifié, ce won' ; l'aide de t l'un ou l'autre, et 
-si le problème est persistant, les raccordements maintiendra réutiliser qui
+erreur nous ne peut pas tracer Ã  un Ã©tat prÃ©vu. Ceci rÃ©utiliserait par la 
+suite tous les raccordements sur de tels problÃ¨mes inattendus aprÃ¨s juste une 
+erreur par raccordement. Naturellement si l'erreur apprÃªte car une violation de 
+contrainte qui est un Ã©tat identifiÃ©, ce won' ; l'aide de t l'un ou l'autre, et 
+si le problÃ¨me est persistant, les raccordements maintiendra rÃ©utiliser qui
  laisseront tomber l'effet de la mise en commun, dans le dernier cas que 
- le code de mise en commun pourrait également annoncer un Admin. pour jeter 
- un coup d'oeil…
+ le code de mise en commun pourrait Ã©galement annoncer un Admin. pour jeter 
+ un coup d'oeilÂ…
  
-<answer> <para> Dans notre code nous éliminons toutes connexions ayant des erreurs inattendues dans
-le contexte. Ceci dit, les convexions devront être rétablis à la fin de chaque telle erreur
-inattendues, à raison d'une erreur par connexion. Naturellement si l'erreur remonte une violation de contrainte,
-qui est une condition reconnue, ne peut aider la situation,  et si le problème persiste, les connexions sont restaurées,
-qui aura pour effet de casser l'effet de pool, dans ce dernier cas, l'administrateur aura à jeter  
+<answer> <para> Dans notre code nous Ã©liminons toutes connexions ayant des erreurs inattendues dans
+le contexte. Ceci dit, les convexions devront Ãªtre rÃ©tablis Ã  la fin de chaque telle erreur
+inattendues, Ã  raison d'une erreur par connexion. Naturellement si l'erreur remonte une violation de contrainte,
+qui est une condition reconnue, ne peut aider la situation,  et si le problÃ¨me persiste, les connexions sont restaurÃ©es,
+qui aura pour effet de casser l'effet de pool, dans ce dernier cas, l'administrateur aura Ã  jeter  
 un coup d'oeil sur le code. </para> </answer>
 
 </qandaentry>
 
-<qandaentry><question><para> J'ai migré mon  &slony1; en version
+<qandaentry><question><para> J'ai migrÃ© mon  &slony1; en version
 1.2.  J'ai maintenant cet avertissement dans les logs:</para>
 
 <screen>NOTICE:  Slony-I: log switch to sl_log_2 still in progress - sl_log_1 not truncated</screen>
 
 <para> Les deux <envar>sl_log_1</envar> et <envar>sl_log_2</envar> continue de prendre du volume, 
-et <envar>sl_log_1</envar> n'est jamais remis à zéro.
+et <envar>sl_log_1</envar> n'est jamais remis Ã  zÃ©ro.
 Quel est le souci?
 </para> </question>
 
-<answer><para> Ceci est un cas symptomatique et similaire au précèdent,
-relatif à la suppression de réplication : s'il y a des connexions établies, s'attardant à utiliser des plan d'exécutions
-basés sur des vieilles fonctions stockées, donne par conséquence une écriture dans 
+<answer><para> Ceci est un cas symptomatique et similaire au prÃ©cÃ¨dent,
+relatif Ã  la suppression de rÃ©plication : s'il y a des connexions Ã©tablies, s'attardant Ã  utiliser des plan d'exÃ©cutions
+basÃ©s sur des vieilles fonctions stockÃ©es, donne par consÃ©quence une Ã©criture dans 
  <envar>sl_log_1</envar> </para>
 
-<para> La fermeture des vieilles et l'ouverture des nouvelles connexions, résous ce problème.</para> </answer> 
+<para> La fermeture des vieilles et l'ouverture des nouvelles connexions, rÃ©sous ce problÃ¨me.</para> </answer> 
 
-<answer> <para> En d'autre terme, la présence d'un ordre dans la liste d'attente de &postgres;
-pour implémenter des dépendances, aura pour effet de descendre les plans d'exécution, lorsque cette dépendance 
+<answer> <para> En d'autre terme, la prÃ©sence d'un ordre dans la liste d'attente de &postgres;
+pour implÃ©menter des dÃ©pendances, aura pour effet de descendre les plans d'exÃ©cution, lorsque cette dÃ©pendance 
 joue sur l'objet qui change.  </para> </answer>
 </qandaentry>
 
 <qandaentry>
-<question><para>J'ai pointé un noeud de souscription à un fournisseur différent, et il a cessé 
-la réplication.</para></question>
+<question><para>J'ai pointÃ© un noeud de souscription Ã  un fournisseur diffÃ©rent, et il a cessÃ© 
+la rÃ©plication.</para></question>
 
 <answer><para>
-Nous rappelons que ceci arrive lorsque nous souhaitons initialiser un noeud où
+Nous rappelons que ceci arrive lorsque nous souhaitons initialiser un noeud oÃ¹
 nous avons la configuration suivante: 
 
 <itemizedlist>
 <listitem><para> Node 1 - fournisseur</para></listitem>
-<listitem><para> Node 2 - s'enregistrer au noeud 1 - le noeud que nous avons réinitialisé</para></listitem>
-<listitem><para> Node 3 - s'enregistrer au noeud 3 - le noeud qui doit répliquer</para></listitem>
+<listitem><para> Node 2 - s'enregistrer au noeud 1 - le noeud que nous avons rÃ©initialisÃ©</para></listitem>
+<listitem><para> Node 3 - s'enregistrer au noeud 3 - le noeud qui doit rÃ©pliquer</para></listitem>
 </itemizedlist></para>
 
-<para>L'abonnement pour le noeud 3 a changé dans le sens d'avoir 
+<para>L'abonnement pour le noeud 3 a changÃ© dans le sens d'avoir 
 le noeud 3 comme fournisseur, et on a fait<xref linkend="stmtdropset"/> /<xref
-linkend="stmtsubscribeset"/> pour le noeud 2 pour qu'il soit rechargé.</para>
+linkend="stmtsubscribeset"/> pour le noeud 2 pour qu'il soit rechargÃ©.</para>
 
-<para>Malencontreusement, la réplication a été arrêtée soudainement sur le noeud 3.</para>
+<para>Malencontreusement, la rÃ©plication a Ã©tÃ© arrÃªtÃ©e soudainement sur le noeud 3.</para>
 
-<para>Le problème était qu'il n'y avait pas un ensemble approprié de
-<quote>ports d'écoute</quote> dans <xref linkend="table.sl-listen"/> pour permettre aux évènements 
-depuis le noeud 1 de se propager sur le 3. Les événements vont se reporter aux noeuds 2 et bloquent ainsi 
-derrière l'évènement <xref linkend="stmtsubscribeset"/> que le noeud 2 est en train de traiter.</para>
+<para>Le problÃ¨me Ã©tait qu'il n'y avait pas un ensemble appropriÃ© de
+<quote>ports d'Ã©coute</quote> dans <xref linkend="table.sl-listen"/> pour permettre aux Ã©vÃ¨nements 
+depuis le noeud 1 de se propager sur le 3. Les Ã©vÃ©nements vont se reporter aux noeuds 2 et bloquent ainsi 
+derriÃ¨re l'Ã©vÃ¨nement <xref linkend="stmtsubscribeset"/> que le noeud 2 est en train de traiter.</para>
 
-<para>Le port d'écoute a lâché le script suivant de slonik où le noeud 3 aurait dû, en passant par le noeud 2
-de l'ajouter directement en ports d'écoute entre  les deux noeuds 1 et 3.
+<para>Le port d'Ã©coute a lÃ¢chÃ© le script suivant de slonik oÃ¹ le noeud 3 aurait dÃ», en passant par le noeud 2
+de l'ajouter directement en ports d'Ã©coute entre  les deux noeuds 1 et 3.
 
 <programlisting>
 cluster name = oxrslive;
@@ -529,29 +528,29 @@
 }
 </programlisting></para>
 
-<para>Juste après que ce script a été terminé, les événements de  <command>SYNC</command> ont commencé à 
+<para>Juste aprÃ¨s que ce script a Ã©tÃ© terminÃ©, les Ã©vÃ©nements de  <command>SYNC</command> ont commencÃ© Ã  
 propager encore sur le noeud 3.
 
-Ceci précise deux principes:
+Ceci prÃ©cise deux principes:
 <itemizedlist>
-
-Si vous avez des noeuds multiples, et des abonnés en cascade,
-vous devez faire attention en repeuplant les entrés <xref
+<listitem><para>
+Si vous avez des noeuds multiples, et des abonnÃ©s en cascade,
+vous devez faire attention en repeuplant les entrÃ©s <xref
 linkend="stmtstorelisten"/>, et en modifiant leur structures de l'<quote>arbre</quote>de changement 
-de réplication.</para></listitem>
+de rÃ©plication.</para></listitem>
 
-<listitem><para> La version 1.1 fourni des meilleurs outils pour gérer ce cas.</para>
+<listitem><para> La version 1.1 fourni des meilleurs outils pour gÃ©rer ce cas.</para>
 </listitem>
 
 </itemizedlist></para>
 
-<para>Les problèmes relatifs aux <quote>chemins d'écoute</quote> sont discutés
+<para>Les problÃ¨mes relatifs aux <quote>chemins d'Ã©coute</quote> sont discutÃ©s
 plus bas au <xref linkend="listenpaths"/> </para></answer>
 </qandaentry>
 
 <qandaentry id="multipleslonconnections">
 
-<question><para> En redémarrant  &lslon;, j'obtiens
+<question><para> En redÃ©marrant  &lslon;, j'obtiens
 le message suivant <quote>FATAL</quote> dans le log. Que se passe-t-il??? </para>
 <screen>
 2006-03-29 16:01:34 UTC CONFIG main: slon version 1.2.0 starting up
@@ -575,113 +574,113 @@
 
 </question>
 
-<answer><para> La table <envar>sl_nodelock</envar> est utilisée comme un 
-<quote>enclencheur</quote>pour prévenir que les deux process &lslon; essaient de prendre 
-la gestion du même noeud en même temps. Le &lslon; essais d'insérer 
-un enregistrement dans la table; seulement il peut le faire avec succès que 
-si il est le seul à gérer le noeud. </para></answer>
+<answer><para> La table <envar>sl_nodelock</envar> est utilisÃ©e comme un 
+<quote>enclencheur</quote>pour prÃ©venir que les deux process &lslon; essaient de prendre 
+la gestion du mÃªme noeud en mÃªme temps. Le &lslon; essais d'insÃ©rer 
+un enregistrement dans la table; seulement il peut le faire avec succÃ¨s que 
+si il est le seul Ã  gÃ©rer le noeud. </para></answer>
 
-<answer><para> Ce message d'erreur est typiquement un signe que vous avez démarrez 
-un second process  &lslon;  pour un noeud donné.  Le &lslon;pose la question évidente qui est :
- <quote>Avez vous déjà un a slon démarré pour gérer ce noeud?</quote> </para></answer>
+<answer><para> Ce message d'erreur est typiquement un signe que vous avez dÃ©marrez 
+un second process  &lslon;  pour un noeud donnÃ©.  Le &lslon;pose la question Ã©vidente qui est :
+ <quote>Avez vous dÃ©jÃ  un a slon dÃ©marrÃ© pour gÃ©rer ce noeud?</quote> </para></answer>
 
-Vous supposant éprouver une certaine sorte de panne de réseau, le raccordement 
-entre le & ; lslon ; et la base de données peut échouer, et le & ; lslon ; peut 
-figurer ceci dehors longtemps avant le & ; postgres ; exemple il était relié fait. 
-Le résultat est qu'il y aura un certain nombre de les raccordements à vide sont partis sur 
-le serveur de base de données, qui won' ; t soit fermé jusqu'aux temps morts de TCP/IP complets, 
-qui semble prendre normalement environ deux heures. Pour cette période de deux heures, le & ; lslon ; 
-essayera de se relier, à plusieurs reprises, et recevra le message mortel ci-dessus, plus d'et au-dessus de.
+Vous supposant Ã©prouver une certaine sorte de panne de rÃ©seau, le raccordement 
+entre le &lslon; et la base de donnÃ©es peut Ã©chouer, et le &lslon; peut 
+figurer ceci dehors longtemps avant le &postgres; exemple il Ã©tait reliÃ© fait. 
+Le rÃ©sultat est qu'il y aura un certain nombre de les raccordements Ã  vide sont partis sur 
+le serveur de base de donnÃ©es, qui won' ; t soit fermÃ© jusqu'aux temps morts de TCP/IP complets, 
+qui semble prendre normalement environ deux heures. Pour cette pÃ©riode de deux heures, le &lslon; 
+essayera de se relier, Ã  plusieurs reprises, et recevra le message mortel ci-dessus, plus d'et au-dessus de.
 
-<answer><para> Vous supposant éprouver une certaine sorte de panne de réseau,
-les connections entre &lslon; et la base de données peuvent échouer, et  &lslon;
-peut avertir cela bien avant l'instance de &postgres;  il était connecté pour ce faire.
-La conséquence en est qu'un certain nombre de connexion pré-établie vont s'ouvrir su la base de données
-et qui ne vont pas se terminer jusqu'à ce que le timeout de TCP/IP arrive à échéance, chose qui n'arrive que 
-tous les deux heures. Durant cette période de deux heures, le &lslon; va essayer de se reconnecter,
-encore et encore, et obtient le message d'erreur ci-dessous réputé Fatl. </para>
+<answer><para> Vous supposant Ã©prouver une certaine sorte de panne de rÃ©seau,
+les connections entre &lslon; et la base de donnÃ©es peuvent Ã©chouer, et  &lslon;
+peut avertir cela bien avant l'instance de &postgres;  il Ã©tait connectÃ© pour ce faire.
+La consÃ©quence en est qu'un certain nombre de connexion prÃ©-Ã©tablie vont s'ouvrir su la base de donnÃ©es
+et qui ne vont pas se terminer jusqu'Ã  ce que le timeout de TCP/IP arrive Ã  Ã©chÃ©ance, chose qui n'arrive que 
+tous les deux heures. Durant cette pÃ©riode de deux heures, le &lslon; va essayer de se reconnecter,
+encore et encore, et obtient le message d'erreur ci-dessous rÃ©putÃ© Fatl. </para>
 
-<para> Un administrateur peut mettre fin à cette situation en se connectant sur
-le serveur et en lançant <command>kill -2</command> pour terminer les connexions mourantes.
-Malheureusement , puisque le problème a eu lieu dans couche de gestion de réseau,ni &postgres; ni &slony1; 
-a le moyen direct de détecter ceci. </para> 
+<para> Un administrateur peut mettre fin Ã  cette situation en se connectant sur
+le serveur et en lanÃ§ant <command>kill -2</command> pour terminer les connexions mourantes.
+Malheureusement , puisque le problÃ¨me a eu lieu dans couche de gestion de rÃ©seau,ni &postgres; ni &slony1; 
+a le moyen direct de dÃ©tecter ceci. </para> 
 
-<para> Vous pouvez <emphasis>la plupart</emphasis> des cas éviter ceci en s'assurant
-que le process &lslon; est hébergé quelque part près des serveurs qu'il gère. Si le &lslon;
-est hébergé sur le même serveur que la base de donnée qu'il gère, alors
-toute <quote>panne de réseau</quote> qui peut interrompre les connexions
-seraient susceptibles d'être assez sérieux pour menacer le serveur entier. </para></answer>
+<para> Vous pouvez <emphasis>la plupart</emphasis> des cas Ã©viter ceci en s'assurant
+que le process &lslon; est hÃ©bergÃ© quelque part prÃ¨s des serveurs qu'il gÃ¨re. Si le &lslon;
+est hÃ©bergÃ© sur le mÃªme serveur que la base de donnÃ©e qu'il gÃ¨re, alors
+toute <quote>panne de rÃ©seau</quote> qui peut interrompre les connexions
+seraient susceptibles d'Ãªtre assez sÃ©rieux pour menacer le serveur entier. </para></answer>
 </qandaentry>
 
 
 <qandaentry>
-<question><para> Quand est-ce que je peux arrêter les process &lslon;?</para></question>
+<question><para> Quand est-ce que je peux arrÃªter les process &lslon;?</para></question>
 
-<answer><para> Généralement ce n'est pas un grand compromis pour arrêter les processes &lslon;
+<answer><para> GÃ©nÃ©ralement ce n'est pas un grand compromis pour arrÃªter les processes &lslon;
 Chacun d'eux est un <quote>simplement</quote> un client de &postgres;,
-gérant chacun un noeud, qui engendre des fils pour gérer et recevoir des évènements
+gÃ©rant chacun un noeud, qui engendre des fils pour gÃ©rer et recevoir des Ã©vÃ¨nements
 depuis d'autre noeud.  </para>
 
-<para>L'<quote>évènement d'écoute</quote> des serveurs n'est pas un travail sorcier; ils n'ont 
-rien à faire que de temps en temps de tester le noeud distant pour déterminer si sur  le noeud en question,
-il y a des tâches à faire. Si vous tuer le process &lslon; sa surveillance sera fermée, qui doit avoir peu
-ou pas du tout d'impact sur rien peut-être. Les éventements générés pour un &lslon; en arrêt reprendront 
-lors de son redémarrage.</para>
+<para>L'<quote>Ã©vÃ¨nement d'Ã©coute</quote> des serveurs n'est pas un travail sorcier; ils n'ont 
+rien Ã  faire que de temps en temps de tester le noeud distant pour dÃ©terminer si sur  le noeud en question,
+il y a des tÃ¢ches Ã  faire. Si vous tuer le process &lslon; sa surveillance sera fermÃ©e, qui doit avoir peu
+ou pas du tout d'impact sur rien peut-Ãªtre. Les Ã©ventements gÃ©nÃ©rÃ©s pour un &lslon; en arrÃªt reprendront 
+lors de son redÃ©marrage.</para>
 
-<para> La<quote>gestion des noeuds</quote> est un peu plus intéressant;
- la plupart du temps , vous pouvez prévoir, sur un abonné, pour son fil 
- d'exécuter l'évènement<command>SYNC</command>. Si vous arrêtez 
-le &lslon; durant un évènement, la transaction va échouer, et s'annuler, alors lorsque the &lslon; 
-redémarre, il aura de reprendre l'évènement pour l'exécuter.</para>
+<para> La<quote>gestion des noeuds</quote> est un peu plus intÃ©ressant;
+ la plupart du temps , vous pouvez prÃ©voir, sur un abonnÃ©, pour son fil 
+ d'exÃ©cuter l'Ã©vÃ¨nement<command>SYNC</command>. Si vous arrÃªtez 
+le &lslon; durant un Ã©vÃ¨nement, la transaction va Ã©chouer, et s'annuler, alors lorsque the &lslon; 
+redÃ©marre, il aura de reprendre l'Ã©vÃ¨nement pour l'exÃ©cuter.</para>
 
-<para> L'unique situation où cela peut arriver est 
- <emphasis>particulièrement</emphasis> <quote>l'arrêt de coeur</quote> si 
-l'évènement qui vient de s'achever était un traitement de longue durée comme,
-<command>COPY_SET</command> pour une large réplication.</para>
+<para> L'unique situation oÃ¹ cela peut arriver est 
+ <emphasis>particuliÃ¨rement</emphasis> <quote>l'arrÃªt de coeur</quote> si 
+l'Ã©vÃ¨nement qui vient de s'achever Ã©tait un traitement de longue durÃ©e comme,
+<command>COPY_SET</command> pour une large rÃ©plication.</para>
 
 <para>L'autre chose qui <emphasis>pourrait</emphasis> causer l'ennui est
-si &lslon; travaille sur un noeud distant auxquels il est connecté;
-vous pouvez découvrir que les sessions de la base de données sont laissées <command>disponible en transaction</command>. 
-Ceci peut normalement arriver si les  connexions réseaux  sont supprimées sans que &lslon; ni la base en ait pris connaissance 
-.Dans ce cas vous pouvez découvrir que des connexions <quote>zombies</quote> traînent encore durant deux long heures
-si vous n'y aller pas à la main pour leur mettre fin dans &postgres;
+si &lslon; travaille sur un noeud distant auxquels il est connectÃ©;
+vous pouvez dÃ©couvrir que les sessions de la base de donnÃ©es sont laissÃ©es <command>disponible en transaction</command>. 
+Ceci peut normalement arriver si les  connexions rÃ©seaux  sont supprimÃ©es sans que &lslon; ni la base en ait pris connaissance 
+.Dans ce cas vous pouvez dÃ©couvrir que des connexions <quote>zombies</quote> traÃ®nent encore durant deux long heures
+si vous n'y aller pas Ã  la main pour leur mettre fin dans &postgres;
 backends.</para>
 
- Il y a un autre cas qui pourrait causer l'ennui ; quand & ; lslon ; 
- la gestion du noeud d'origine ne fonctionne pas, événement de synchro 
- ne fonctionne pas contre ce noeud. Si & ; lslon ; les séjours vers le bas 
- pendant une période prolongée, et quelque chose aiment isn' ; fonctionnement 
- de t, vous pourriez être laissé avec une grande synchro au processus quand il 
- vient support. Mais c'est seulement un souci si ce & ; lslon ; est vers le bas 
- pendant une période prolongée ; le fermant pour uns seconde shouldn' ; cause 
- de t tout grand problème.
+ Il y a un autre cas qui pourrait causer l'ennui ; quand &lslon; 
+ la gestion du noeud d'origine ne fonctionne pas, Ã©vÃ©nement de synchro 
+ ne fonctionne pas contre ce noeud. Si &lslon; les sÃ©jours vers le bas 
+ pendant une pÃ©riode prolongÃ©e, et quelque chose aiment isn' ; fonctionnement 
+ de t, vous pourriez Ãªtre laissÃ© avec une grande synchro au processus quand il 
+ vient support. Mais c'est seulement un souci si ce &lslon; est vers le bas 
+ pendant une pÃ©riode prolongÃ©e ; le fermant pour uns seconde shouldn' ; cause 
+ de t tout grand problÃ¨me.
 
 
 <para> Il y a un autre cas qui pourrait causer l'ennui; quand
-&lslon; administrant son noeud d'attachement n'est pas en cours d'exécution
-,aucun évènement <command>SYNC</command> s'exécute sur ce même serveur. Si le &lslon; 
- arrêté pour une longue durée, et que quelques chose du genre <xref linkend="gensync"/> n'est pas encours, 
-vous pouvez vous retrouvez avec  <emphasis>un énorme<command>SYNC</command></emphasis> à effectuer
-lorsque vous vous apprêtez à réaliser une sauvegarde.  Ceci est vrai seulement si &lslon; est en arrêt pendant une période 
-assez longue; alors que un arrêt de quelques seconds ne génère pas de problème.</para> </answer>
+&lslon; administrant son noeud d'attachement n'est pas en cours d'exÃ©cution
+,aucun Ã©vÃ¨nement <command>SYNC</command> s'exÃ©cute sur ce mÃªme serveur. Si le &lslon; 
+ arrÃªtÃ© pour une longue durÃ©e, et que quelques chose du genre <xref linkend="gensync"/> n'est pas encours, 
+vous pouvez vous retrouvez avec  <emphasis>un Ã©norme<command>SYNC</command></emphasis> Ã  effectuer
+lorsque vous vous apprÃªtez Ã  rÃ©aliser une sauvegarde.  Ceci est vrai seulement si &lslon; est en arrÃªt pendant une pÃ©riode 
+assez longue; alors que un arrÃªt de quelques seconds ne gÃ©nÃ¨re pas de problÃ¨me.</para> </answer>
 </qandaentry>
 
 <qandaentry>
 <question><para> Y a-t-il des risques pour ce faire ? Quels en sont les avantages ?</para></question>
 
-<answer><para> En bref, si votre <command>COPY_SET</command> prend environ 18h pour s'exécuter
-finalement, ce n'est pas un grand sacrifice d'arrêter quelques moments un &lslon; 
-ou peut-être même durant un cycle<emphasis>all</emphasis> de &lslon;s. </para> </answer>
+<answer><para> En bref, si votre <command>COPY_SET</command> prend environ 18h pour s'exÃ©cuter
+finalement, ce n'est pas un grand sacrifice d'arrÃªter quelques moments un &lslon; 
+ou peut-Ãªtre mÃªme durant un cycle<emphasis>all</emphasis> de &lslon;s. </para> </answer>
 </qandaentry>
 
 </qandadiv>
 
-<qandadiv id="faqconfiguration"> <title> &slony1; FAQ: Problèmes de configuration </title>
+<qandadiv id="faqconfiguration"> <title> &slony1; FAQ: ProblÃ¨mes de configuration </title>
 <qandaentry>
 <question><para>Slonik tombe en erreur - ne peut pas charger les librairies &postgres;  -
 <command>PGRES_FATAL_ERROR load '$libdir/xxid';</command></para>
 
-<para> Lorsque j'exécute un simple script de configuration, j'obtiens un message similaire à
+<para> Lorsque j'exÃ©cute un simple script de configuration, j'obtiens un message similaire Ã 
 :
 
 <command>
@@ -689,43 +688,43 @@
 could not open file '$libdir/xxid': No such file or directory
 </command></para></question>
 
-<answer><para> Evidemment, vous n'avez pas accès à la librairie
-<filename>xxid.so</filename> dans le répertoire <envar>$libdir</envar>
-où l'instance &postgres; est en usage. Notez que le composant &slony1;doit être installé sur le noyau du &postgres;
+<answer><para> Evidemment, vous n'avez pas accÃ¨s Ã  la librairie
+<filename>xxid.so</filename> dans le rÃ©pertoire <envar>$libdir</envar>
+oÃ¹ l'instance &postgres; est en usage. Notez que le composant &slony1;doit Ãªtre installÃ© sur le noyau du &postgres;
 pour <emphasis>chacun des noeud</emphasis> et pas seulement sur le noeud d'origine.</para>
 
-<para>Cela peut également venir du fait d'une disparité entre les binaires
-du noyau  &postgres; et celui du noyau de  &slony1;. Si vous avez manuellement compilé &slony1;
-vous même, sur une machine où il y a plusieurs noyau de
+<para>Cela peut Ã©galement venir du fait d'une disparitÃ© entre les binaires
+du noyau  &postgres; et celui du noyau de  &slony1;. Si vous avez manuellement compilÃ© &slony1;
+vous mÃªme, sur une machine oÃ¹ il y a plusieurs noyau de
 &postgres;  <quote>se trouvant autour,</quote> il est possible
 que les binaires slon ou lslonik demande de charger une librairie qui n'est pas accessible
-actuellement dans les répertoires du noyau de &postgres; gérant le cluster.</para>
+actuellement dans les rÃ©pertoires du noyau de &postgres; gÃ©rant le cluster.</para>
 
 <para>Court et concis: Ceci indique un besoin de <quote>auditer</quote>
 quel mode d'installation de &postgres; et de &slony1; vous avez en place sur vos machines.
-Malheureusement,n'importe quelle incompatibilité peut faire remonter ce genre
+Malheureusement,n'importe quelle incompatibilitÃ© peut faire remonter ce genre
 de soucis.  Voir aussi<link linkend="threadsafety">
-sécurité des thread </link> à propos de la gestion des thread sur Solaris.
+sÃ©curitÃ© des thread </link> Ã  propos de la gestion des thread sur Solaris.
 ...</para> 
 
-<para> La situation sera plus simple si vous aviez un seul noyau de &postgres; installé par serveur
-dans ce cas il n'y aura pas d' <quote>incompatibilité
-de chemins</quote> dans lequel les composants de &slony1; sont installés.</para>
+<para> La situation sera plus simple si vous aviez un seul noyau de &postgres; installÃ© par serveur
+dans ce cas il n'y aura pas d' <quote>incompatibilitÃ©
+de chemins</quote> dans lequel les composants de &slony1; sont installÃ©s.</para>
 Si vous avez une installation multiple,
-vous devrez vous assurez de la compatibilité de la bonne 
-versions de &slony1; associé à la bonne version du noyau de 
-&postgres;. </para> </answer></qandaentry>
+vous devrez vous assurez de la compatibilitÃ© de la bonne 
+versions de &slony1; associÃ© Ã  la bonne version du noyau de 
+&postgres;. </answer></qandaentry>
 
 <qandaentry>
-<question> <para>J'essai de créer un cluster dont le nom contient un "-".
+<question> <para>J'essai de crÃ©er un cluster dont le nom contient un "-".
 Cela ne marche pas!.</para></question>
 
-<answer><para> &slony1; Utilise les même règles de nommage que &postgres;
+<answer><para> &slony1; Utilise les mÃªme rÃ¨gles de nommage que &postgres;
 alors  confirmation, il ne faudra pas utiliser un "-"
 dans le nom.</para>
 
 <para> Vous pouvez tenter de mettre des simples <quote>quotes</quote> pour l'identifiant
-,mais vous allez vous exposer à des soucis, qui pourront surgir à tout moment.</para>
+,mais vous allez vous exposer Ã  des soucis, qui pourront surgir Ã  tout moment.</para>
 </answer>
 </qandaentry>
 
@@ -733,14 +732,14 @@
 <question><para>La commande ps affiche le mot de passe en claire</para>
 
 <para> Si je lance une commande <command>ps</command>, tout le monde,
-peut voir le mot de passe qui a été fourni à la ligne de commande.</para></question>
+peut voir le mot de passe qui a Ã©tÃ© fourni Ã  la ligne de commande.</para></question>
 
 <answer> <para>Conservez vous mot de passe en dehors de la configuration Slony, en les mettant dans
 des fichiers <filename>$(HOME)/.pgpass.</filename></para>
 </answer></qandaentry>
 
 <qandaentry>
-<question><para>Sommaire de questions posées sur namespace
+<question><para>Sommaire de questions posÃ©es sur namespace
 
 <programlisting>
 set add table (set id = 1, origin = 1, id = 27, 
@@ -755,48 +754,48 @@
 </answer></qandaentry>
 
 <qandaentry>
-<question> <para> La réplication a été retardée, et il semble que les interrogations pour restituer des données
+<question> <para> La rÃ©plication a Ã©tÃ© retardÃ©e, et il semble que les interrogations pour restituer des donnÃ©es
 depuis  <xref linkend="table.sl-log-1"/>/<xref
 linkend="table.sl-log-2"/> prennent beaucoup de temps en indiquant quelques demande de 
 <command>SYNC</command>s. </para>
 </question>
 
-<answer> <para> Jusqu'à la version 1.1.1, la table <xref
-linkend="table.sl-log-1"/>/<xref linkend="table.sl-log-2"/>,possédait seulement un index, et si plusieurs jeu de réplication 
-se mettaient en route en même temps, quelques colonnes dans l'indexe n'était pas très discriminent pour la manière d'accès.
-Si l'index ne contient pas la colonne<function> log_xid</function>, il est conseillé de l'ajouter. Voir le script
-<filename>slony1_base.sql</filename> pour regarder la manière de créer un indexe.
+<answer> <para> Jusqu'Ã  la version 1.1.1, la table <xref
+linkend="table.sl-log-1"/>/<xref linkend="table.sl-log-2"/>,possÃ©dait seulement un index, et si plusieurs jeu de rÃ©plication 
+se mettaient en route en mÃªme temps, quelques colonnes dans l'indexe n'Ã©tait pas trÃ¨s discriminent pour la maniÃ¨re d'accÃ¨s.
+Si l'index ne contient pas la colonne<function> log_xid</function>, il est conseillÃ© de l'ajouter. Voir le script
+<filename>slony1_base.sql</filename> pour regarder la maniÃ¨re de crÃ©er un indexe.
 </para>
 </answer>
 </qandaentry>
 
 <qandaentry><question> <para> J'ai besoin de renommer une colonne qui figure dans la clef 
-primaire pour l'une de mes tables répliquées. L'opération s'avère un peu dangereuse, est-ce vrai ? 
-Aurai-je à la recréer en dehors de la réplication ?</para>
+primaire pour l'une de mes tables rÃ©pliquÃ©es. L'opÃ©ration s'avÃ¨re un peu dangereuse, est-ce vrai ? 
+Aurai-je Ã  la recrÃ©er en dehors de la rÃ©plication ?</para>
 </question>
 
-<answer><para> Affirmatif, c'est un scénario qui fonctionne proprement.  &slony1; fait un usage intensif de
-clef primaire, mais actuellement c'est ainsi et on espère une gestion intégrée et transparente  prochainement</para>.
+<answer><para> Affirmatif, c'est un scÃ©nario qui fonctionne proprement.  &slony1; fait un usage intensif de
+clef primaire, mais actuellement c'est ainsi et on espÃ¨re une gestion intÃ©grÃ©e et transparente  prochainement</para>.
 
 <para> Supposez que vous souhaiter renommer une colonne, comme dans uns script sql, on utiliserais la 
 commande DDL suivante<command> alter table accounts alter column aid rename to cid; </command> Ceci
-permet de renommer la colonne dans la table; elle permet de manière 
-<emphasis>transparente</emphasis> de effectuer la mise à jour dans clef primaire qui contient la colonne en question. 
-Le résultat est que ce genre de changement s'effectue simultanément sur les différents composants, du noeud.</para>
+permet de renommer la colonne dans la table; elle permet de maniÃ¨re 
+<emphasis>transparente</emphasis> de effectuer la mise Ã  jour dans clef primaire qui contient la colonne en question. 
+Le rÃ©sultat est que ce genre de changement s'effectue simultanÃ©ment sur les diffÃ©rents composants, du noeud.</para>
 
 <para> Dans l' <emphasis>ideal</emphasis> et pour bien faire les choses 
-il aurait fallu utiliser <xref linkend="stmtddlscript"/> pour déployer la modification 
-en étant sur que le bon changement s'applique aux bons noeuds.</para>
+il aurait fallu utiliser <xref linkend="stmtddlscript"/> pour dÃ©ployer la modification 
+en Ã©tant sur que le bon changement s'applique aux bons noeuds.</para>
 
-<para> Pour la clarté des choses, tant que la modification commence par la partie répliquée et bien avant les abonnés,
-il n'y aura pas de cassure irrémédiable. Se retrouver avec quelques évènements de 
-<command>SYNC</command> qui n'incluent pas la table sur laquelle il y a la modification, n'est pas un problème car ils vont se dérouler 
-sans difficulté...  Par contre si le changement est signalé d'abord par un abonné, alors 
+<para> Pour la clartÃ© des choses, tant que la modification commence par la partie rÃ©pliquÃ©e et bien avant les abonnÃ©s,
+il n'y aura pas de cassure irrÃ©mÃ©diable. Se retrouver avec quelques Ã©vÃ¨nements de 
+<command>SYNC</command> qui n'incluent pas la table sur laquelle il y a la modification, n'est pas un problÃ¨me car ils vont se dÃ©rouler 
+sans difficultÃ©...  Par contre si le changement est signalÃ© d'abord par un abonnÃ©, alors 
 point that the first update to the table is drawn in by a subscriber,
-<emphasis>ce</emphasis> sera le point de départ pour que 
+<emphasis>ce</emphasis> sera le point de dÃ©part pour que 
 <command>SYNC</command> tombe en erreur, puisque le fournisseur indiquera une 
-<quote>nouvelle</quote>  colonne alors que l'abonné connait toujours
-ses <quote>anciens</quote> formats. En appliquant la modification à postériori chez l'abonné, la commande
+<quote>nouvelle</quote>  colonne alors que l'abonnÃ© connait toujours
+ses <quote>anciens</quote> formats. En appliquant la modification Ã  postÃ©riori chez l'abonnÃ©, la commande
 <command>SYNC</command>, peut retrouver le
 <quote>nouveau</quote> nom de colonne et fonctionner sans plantage .
 </para> </answer></qandaentry>
@@ -804,81 +803,81 @@
 <qandaentry id="v72upgrade">
 <question> <para> J'ai un &postgres; version 7.2 que je souhaite 
 <emphasis>vraiment, vraiment</emphasis> employer avec &slony1; Que faut-il faire pour une migration en
-version 8.2 ? Quel est l'implication pour récupérer &slony1; afin de les exploiter ensemble?</para>
+version 8.2 ? Quel est l'implication pour rÃ©cupÃ©rer &slony1; afin de les exploiter ensemble?</para>
 </question>
 
-<answer> <para> Voici l'écrit d'un certain Rod Taylor sur le sujet ...
+<answer> <para> Voici l'Ã©crit d'un certain Rod Taylor sur le sujet ...
 </para>
 
 <para> Voici ce dont approximativement vous avez besoin:</para>
 <itemizedlist>
 <listitem><para>Prendre les formulaire 7.3 et de mes copier en 7.2 -- ou bien de 
         mettre en dur 7.3 dans vos formulaire </para></listitem>
-<listitem><para>Supprimer toute trace de schémas dans le code sql de vos formulaires. 
+<listitem><para>Supprimer toute trace de schÃ©mas dans le code sql de vos formulaires. 
         Sommairement je remplace "." par "-". </para></listitem>
-<listitem><para> Le bloc de travail relatif aux models de données XID ainsi qu’aux fonctions. 
-        Par exemple, Slony crée des  CASTs pour  the xid en  xxid et vice versa -- mais 
-        la 7.2 ne peut pas crée de nouveau casts et dans ce cas vous êtes obligé de le modifier à la main.
-        Je rappelle la création d'une classe d'opérateur ainsi que l'édition de certaines fonctions. </para></listitem>
-<listitem><para>sl_log_1 aura de grave problème de performance quelque soit le volume de données.
-        Ceci exige qu'un certain nombre d'indexe soient positionnés pour optimiser les interrogations en 7.2. 7.3
-        et supérieur. </para></listitem>
-<listitem><para> Ne pas s'  embeter à essayer de travailler en séquence. Faites les à la main
+<listitem><para> Le bloc de travail relatif aux models de donnÃ©es XID ainsi quÂ’aux fonctions. 
+        Par exemple, Slony crÃ©e des  CASTs pour  the xid en  xxid et vice versa -- mais 
+        la 7.2 ne peut pas crÃ©e de nouveau casts et dans ce cas vous Ãªtes obligÃ© de le modifier Ã  la main.
+        Je rappelle la crÃ©ation d'une classe d'opÃ©rateur ainsi que l'Ã©dition de certaines fonctions. </para></listitem>
+<listitem><para>sl_log_1 aura de grave problÃ¨me de performance quelque soit le volume de donnÃ©es.
+        Ceci exige qu'un certain nombre d'indexe soient positionnÃ©s pour optimiser les interrogations en 7.2. 7.3
+        et supÃ©rieur. </para></listitem>
+<listitem><para> Ne pas s'  embeter Ã  essayer de travailler en sÃ©quence. Faites les Ã  la main
         en utilisant pg_dump et grep. </para></listitem>
 </itemizedlist>
-<para> Bien sûr, une fois que ces pre-requis terminés, on n'est pas encore compatible avec
-le Slony standard. Ainsi ou bien, vous devez au moins implémenter la 7.2 de manière artisanale
-du moins, forcer slony à travailler sans les schémas dans la nouvelle version versions de &postgres; 
-ainsi le dialogue entre les deux peut être établi.
+<para> Bien sÃ»r, une fois que ces pre-requis terminÃ©s, on n'est pas encore compatible avec
+le Slony standard. Ainsi ou bien, vous devez au moins implÃ©menter la 7.2 de maniÃ¨re artisanale
+du moins, forcer slony Ã  travailler sans les schÃ©mas dans la nouvelle version versions de &postgres; 
+ainsi le dialogue entre les deux peut Ãªtre Ã©tabli.
 </para>
-<para> Juste après le déroulement de la procédure de migration de 7.2 vers 7.4, 
-on peut désinstaller la version bidouillée de Slony (à la main encore pour la majeur partie), et démarrer la migration
-de  7.2 à 7.4 sur les différentes machines en utilisant un Slony standard.
-Ceci permettant de s'assurer sur la fiabilité d'un catalogue système qui avait subi des changement manuels.
+<para> Juste aprÃ¨s le dÃ©roulement de la procÃ©dure de migration de 7.2 vers 7.4, 
+on peut dÃ©sinstaller la version bidouillÃ©e de Slony (Ã  la main encore pour la majeur partie), et dÃ©marrer la migration
+de  7.2 Ã  7.4 sur les diffÃ©rentes machines en utilisant un Slony standard.
+Ceci permettant de s'assurer sur la fiabilitÃ© d'un catalogue systÃ¨me qui avait subi des changement manuels.
 </para>
 
-<para> Tout cela pour dire, que nous migrons quelque centaine de GO de données,
-de  7.2 a  7.4 en espace de 30 minutes. (contre 48 heures auparavant annoncées myeneant un dump et 
-restore) sans pertes de données.
+<para> Tout cela pour dire, que nous migrons quelque centaine de GO de donnÃ©es,
+de  7.2 a  7.4 en espace de 30 minutes. (contre 48 heures auparavant annoncÃ©es myeneant un dump et 
+restore) sans pertes de donnÃ©es.
 </para>
 </answer>
 
-<answer> <para> Ceci vous dresse un éventail assez laid qualifié de
-<quote>bidouille</quote> qu'il faut admettre entrer dans le périmètre de production.
-Si quelqu'un est intéressé pour le transformer en
-<quote>tâche de production</quote>, il y aura un sens dans ce cas de s'appuyer sur
-&slony1; en version 1.0, avec un maître mot de ne 
-<emphasis>pas</emphasis> essayer de le rendre pérenne, étant donnée sa durée de vie limitée.</para>
+<answer> <para> Ceci vous dresse un Ã©ventail assez laid qualifiÃ© de
+<quote>bidouille</quote> qu'il faut admettre entrer dans le pÃ©rimÃ¨tre de production.
+Si quelqu'un est intÃ©ressÃ© pour le transformer en
+<quote>tÃ¢che de production</quote>, il y aura un sens dans ce cas de s'appuyer sur
+&slony1; en version 1.0, avec un maÃ®tre mot de ne 
+<emphasis>pas</emphasis> essayer de le rendre pÃ©renne, Ã©tant donnÃ©e sa durÃ©e de vie limitÃ©e.</para>
 
-<para> Vous devriez seulement adapter cette solution que si vous êtes à l'aise avec
+<para> Vous devriez seulement adapter cette solution que si vous Ãªtes Ã  l'aise avec
 &postgres; et &slony1; et que de mettre la main au code ne vous fait pas peur. </para> </answer>
 </qandaentry>
 
 <qandaentry>
-<question> <para> J'avais un réseau <quote>pas performant</quote> qui m'obligeais à utiliser
+<question> <para> J'avais un rÃ©seau <quote>pas performant</quote> qui m'obligeais Ã  utiliser
  <xref linkend="stmtfailover"/> un basculement sur un noeud secondaire.
-Le plantage n'était pas causé par un problème de corruption de donnée venant du disque,
-Pourquoi serais-je obligé de reconstruire depuis le début, le noeud planté ? </para></question>
+Le plantage n'Ã©tait pas causÃ© par un problÃ¨me de corruption de donnÃ©e venant du disque,
+Pourquoi serais-je obligÃ© de reconstruire depuis le dÃ©but, le noeud plantÃ© ? </para></question>
 
-<answer><para> Le rôle de <xref linkend="stmtfailover"/> est d'
-<emphasis>abandonner</emphasis> le noeud planté, et par conséquence il n'a plus de 
-charge générée par l'activité de &slony1. Plus le temps passe plus le serveur planté se désynchronise.</para></answer>
+<answer><para> Le rÃ´le de <xref linkend="stmtfailover"/> est d'
+<emphasis>abandonner</emphasis> le noeud plantÃ©, et par consÃ©quence il n'a plus de 
+charge gÃ©nÃ©rÃ©e par l'activitÃ© de &slony1;. Plus le temps passe plus le serveur plantÃ© se dÃ©synchronise.</para></answer>
 
-<answer><para> L'<emphasis>énorme</emphasis> problème afin de restaurer le serveur planté,
-est qu'il peut contenir des mises à jours qui n'ont pas eu le temps de se propager endors.
-Vous ne pouvez pas non plus les rejouer, car elles vont être conflictuelles, car à moitié en place.
-En tout cas vous avez une sorte de corruption <quote>logique</quote>de donnée, qui n'est jamais causée par une erreur disque.
+<answer><para> L'<emphasis>Ã©norme</emphasis> problÃ¨me afin de restaurer le serveur plantÃ©,
+est qu'il peut contenir des mises Ã  jours qui n'ont pas eu le temps de se propager endors.
+Vous ne pouvez pas non plus les rejouer, car elles vont Ãªtre conflictuelles, car Ã  moitiÃ© en place.
+En tout cas vous avez une sorte de corruption <quote>logique</quote>de donnÃ©e, qui n'est jamais causÃ©e par une erreur disque.
 dite <quote>physique.</quote>
 </para></answer>
 
-<answer><para> Comme cela a été abordé en <xref linkend="failover"/>, utiliser <xref
-linkend="stmtfailover"/> revient à accepter comme <emphasis>dernier
+<answer><para> Comme cela a Ã©tÃ© abordÃ© en <xref linkend="failover"/>, utiliser <xref
+linkend="stmtfailover"/> revient Ã  accepter comme <emphasis>dernier
 ressort</emphasis> tant qu'il implique d'abandonner le noeud d'origine pour cette corruption.</para></answer>
 </qandaentry>
 
 
-<qandaentry> <question><para> Après notification d'un abonnement sur un 
-<emphasis>autre</emphasis> noeud, la réplication échoue sur l'un des abonnés, avec le message d'erreur suivant:</para>
+<qandaentry> <question><para> AprÃ¨s notification d'un abonnement sur un 
+<emphasis>autre</emphasis> noeud, la rÃ©plication Ã©choue sur l'un des abonnÃ©s, avec le message d'erreur suivant:</para>
 
 <screen>
 ERROR  remoteWorkerThread_1: "begin transaction; set transaction isolation level serializable; lock table "_livesystem".sl_config_lock; select "_livesystem".enableSubscription(25506, 1, 501); notify "_livesystem_Event"; notify "_livesystem_Confirm"; insert into "_livesystem".sl_event     (ev_origin, ev_seqno, ev_timestamp,      ev_minxid, ev_maxxid, ev_xip, ev_type , ev_data1, ev_data2, ev_data3, ev_data4    ) values ('1', '4896546', '2005-01-23 16:08:55.037395', '1745281261', '1745281262', '', 'ENABLE_SUBSCRIPTION', '25506', '1', '501', 't'); insert into "_livesystem".sl_confirm      (con_origin, con_received, con_seqno, con_timestamp)    values (1, 4, '4896546', CURRENT_TIMESTAMP); commit transaction;" PGRES_FATAL_ERROR ERROR:  insert or update on table "sl_subscribe" violates foreign key constraint "sl_subscribe-sl_path-ref"
@@ -886,7 +885,7 @@
 </screen>
 
 <para> Par la suite l'erreur est suivie par un ensemble d'<xref
-linkend="slon"/> arrêt: de syncs:</para>
+linkend="slon"/> arrÃªt: de syncs:</para>
 
 <screen>
 DEBUG2 remoteListenThread_1: queue event 1,4897517 SYNC
@@ -903,42 +902,42 @@
 
 </question>
 
-<answer><para> Si vous regardez les journaux de &lslon; à l'arrêt avec des erreurs due à cet effet
-<emphasis>d'arrêt</emphasis>, vous auriez besoin de revenir en arrière en ignorant une partie de
+<answer><para> Si vous regardez les journaux de &lslon; Ã  l'arrÃªt avec des erreurs due Ã  cet effet
+<emphasis>d'arrÃªt</emphasis>, vous auriez besoin de revenir en arriÃ¨re en ignorant une partie de
 ces journalisation, 
-<emphasis>en attendant</emphasis> après le redémarrage du serveur en erreur de trouver la cause d'origine.</para></answer>
+<emphasis>en attendant</emphasis> aprÃ¨s le redÃ©marrage du serveur en erreur de trouver la cause d'origine.</para></answer>
 
-<answer><para> Dans ce cas particulier, l'erreur est due à la commande
-<xref linkend="stmtstorepath"/> qui n'est pas encore répercutée sur le noeud 4 en attendant la propagation 
+<answer><para> Dans ce cas particulier, l'erreur est due Ã  la commande
+<xref linkend="stmtstorepath"/> qui n'est pas encore rÃ©percutÃ©e sur le noeud 4 en attendant la propagation 
 de <xref linkend="stmtsubscribeset"/> command</para>
 
-<para>Ceci démontre encore un autre exemple où l'approximatif ne devra pas prendre le dessus,
-et que on doit avec assurance vérifier le bon fonctionnement des choses 
-<emphasis>avant</emphasis> de suggérer un changement de la configuration.
+<para>Ceci dÃ©montre encore un autre exemple oÃ¹ l'approximatif ne devra pas prendre le dessus,
+et que on doit avec assurance vÃ©rifier le bon fonctionnement des choses 
+<emphasis>avant</emphasis> de suggÃ©rer un changement de la configuration.
 </para></answer>
 
 </qandaentry>
 
 <qandaentry>
 
-<question><para>J'ai juste utilisé <xref linkend="stmtmoveset"/> afin de déporter le noeud d'origine sur
-un nouveau serveur. Malheureusement certains abonnés sont toujours attachés à l'ancien noeud que je viens de migrer,
-or je ne peux les mettre hors service tant qu'il n'ont pas reçu le signalement de ce changement.
+<question><para>J'ai juste utilisÃ© <xref linkend="stmtmoveset"/> afin de dÃ©porter le noeud d'origine sur
+un nouveau serveur. Malheureusement certains abonnÃ©s sont toujours attachÃ©s Ã  l'ancien noeud que je viens de migrer,
+or je ne peux les mettre hors service tant qu'il n'ont pas reÃ§u le signalement de ce changement.
 Que puis-je faire?  </para></question>
 
 <answer><para> Vous avez besoin d'utiliser <xref linkend="stmtsubscribeset"/> afin de modifier les abonnements
- de ces serveurs abonnés, que leurs fournisseur <emphasis>sera</emphasis> indisponible durant une période maintenance.</para>
+ de ces serveurs abonnÃ©s, que leurs fournisseur <emphasis>sera</emphasis> indisponible durant une pÃ©riode maintenance.</para>
 
 <warning> <para> Que vous avez <emphasis>omis</emphasis> de faire <xref
-linkend="stmtunsubscribeset"/>; pour que vous soyez obligé de recommencer à rafraîchir les noeuds depuis le début.
+linkend="stmtunsubscribeset"/>; pour que vous soyez obligÃ© de recommencer Ã  rafraÃ®chir les noeuds depuis le dÃ©but.
 
 </para></warning>
 </answer>
 </qandaentry>
 
 <qandaentry>
-<question><para> Après la notification d'un abonnement auprès 
-<emphasis>d'un autre</emphasis> serveur fournisseur, la réplication tombe en erreur, et commençant des messages d'erreurs
+<question><para> AprÃ¨s la notification d'un abonnement auprÃ¨s 
+<emphasis>d'un autre</emphasis> serveur fournisseur, la rÃ©plication tombe en erreur, et commenÃ§ant des messages d'erreurs
 avec :</para>
 
 <screen>
@@ -946,8 +945,8 @@
 DETAIL:  Key (sub_provider,sub_receiver)=(1,501) is not present in table "sl_path".
 </screen>
 
-<para> Ceci est suivi plus tard par une série d'erreur de syncs puisque le <xref
-linkend="slon"/> est à l'arrêt:
+<para> Ceci est suivi plus tard par une sÃ©rie d'erreur de syncs puisque le <xref
+linkend="slon"/> est Ã  l'arrÃªt:
 
 <screen>
 DEBUG2 remoteListenThread_1: queue event 1,4897517 SYNC
@@ -964,17 +963,17 @@
 
 </para></question>
 
-<answer><para> Si lors d'un arrêt, vous voyez dans le journal d'un &lslon;  
-<emphasis>des nouveaux évènements ignorés dus à l'arrêt</emphasis> ,
-c'est le cas parlant où il faut revenir une étape en arrière 
-<emphasis>avant</emphasis> l'arrêt pour voir l'origine de l'erreur.
+<answer><para> Si lors d'un arrÃªt, vous voyez dans le journal d'un &lslon;  
+<emphasis>des nouveaux Ã©vÃ¨nements ignorÃ©s dus Ã  l'arrÃªt</emphasis> ,
+c'est le cas parlant oÃ¹ il faut revenir une Ã©tape en arriÃ¨re 
+<emphasis>avant</emphasis> l'arrÃªt pour voir l'origine de l'erreur.
 </para></answer>
 
-<answer><para> Dans ce cas particulier, le problème était que certain 
- <xref linkend="stmtstorepath"/> commandes n'ont pas été transmises aux noeud 4 avant <xref linkend="stmtsubscribeset"/> 
- la commande soit propagée. </para>
+<answer><para> Dans ce cas particulier, le problÃ¨me Ã©tait que certain 
+ <xref linkend="stmtstorepath"/> commandes n'ont pas Ã©tÃ© transmises aux noeud 4 avant <xref linkend="stmtsubscribeset"/> 
+ la commande soit propagÃ©e. </para>
 
-<para>C'est encore un exemple où il ne faut pas hâtivement modifier les choses
+<para>C'est encore un exemple oÃ¹ il ne faut pas hÃ¢tivement modifier les choses
 ;vous devrez avec certitude, constater le disfonctionnement 
 <emphasis>avant</emphasis> de faire de nouveau changement de configuration.
 </para></answer>
@@ -986,25 +985,25 @@
 est important ?</para>
 </question>
 <answer> <para> La plupart de temps il ne l'est pas. Vous devrez adapter un ordre selon lequel
-les tables <quote>maîtres</quote> sont mises à jour avant celles de <quote>détails</quote>
-en fonction de la relation de clef étrangère qui les relie; ceci ne sera <emphasis>pas exigé</emphasis> si sur le noeud abonné, 
-on a pris le soin, de désactiver les déclencheurs.
+les tables <quote>maÃ®tres</quote> sont mises Ã  jour avant celles de <quote>dÃ©tails</quote>
+en fonction de la relation de clef Ã©trangÃ¨re qui les relie; ceci ne sera <emphasis>pas exigÃ©</emphasis> si sur le noeud abonnÃ©, 
+on a pris le soin, de dÃ©sactiver les dÃ©clencheurs.
 </para>
 </answer>
 
 <answer> <para>(Les commentaires de Jan Wieck:) L'ordre des ID des tables
-a une importance uniquement lors d'une opération de <xref linkend="stmtlockset"/> en préparation de basculement.
-Si l'ordre est différent de celui selon lequel les applications obtiennent des verrous,
-ces derniers peuvent se transformer en verrous mortels et par conséquent faire tomber l'application ou bien
+a une importance uniquement lors d'une opÃ©ration de <xref linkend="stmtlockset"/> en prÃ©paration de basculement.
+Si l'ordre est diffÃ©rent de celui selon lequel les applications obtiennent des verrous,
+ces derniers peuvent se transformer en verrous mortels et par consÃ©quent faire tomber l'application ou bien
 <application>slon</application>.
 </para>
-<answer><para> (David Parker) Dans un autre cas, j'ai lancé l'opération où l'ordre des
-tables avait une importance : en présence des tables avec les contraintes d'intégrité référentielles.
-Si une table détail se présente avant celle de maître, alors le serveur abonné, supprime son 
-contenu, avant qu'elle soit à nouveau rafraîchie, car la logique de la commande
+<answer><para> (David Parker) Dans un autre cas, j'ai lancÃ© l'opÃ©ration oÃ¹ l'ordre des
+tables avait une importance : en prÃ©sence des tables avec les contraintes d'intÃ©gritÃ© rÃ©fÃ©rentielles.
+Si une table dÃ©tail se prÃ©sente avant celle de maÃ®tre, alors le serveur abonnÃ©, supprime son 
+contenu, avant qu'elle soit Ã  nouveau rafraÃ®chie, car la logique de la commande
 <command>copy_set</command> vaut que <command>delete</command>,
-ne soit pas un <command>delete only</command>, or la suppression des données de la table maître, impose bien la suppression de celle
-de détail.
+ne soit pas un <command>delete only</command>, or la suppression des donnÃ©es de la table maÃ®tre, impose bien la suppression de celle
+de dÃ©tail.
 </para>
 </answer></answer>
 
@@ -1012,13 +1011,13 @@
 
 <qandaentry>
 
-<question><para> Si votre script  <xref linkend="slonik"/> ressemble à quelque chose comme le suivant,
+<question><para> Si votre script  <xref linkend="slonik"/> ressemble Ã  quelque chose comme le suivant,
 il peut tomber en erreur et ne jamais se terminer, car vous n'avez pas
-<command>wait pour ev la mise à jour à nouveau. Bien sûr Of course, as mentioned
+<command>wait pour ev la mise Ã  jour Ã  nouveau. Bien sÃ»r Of course, as mentioned
 above, it could be faster to drop the node and recreate it than to let
-ent</command> à l'intérieur d'un bloc de 
-<command>try</command>. Un bloc de <command>try</command> est exécuté comme une seule et même transaction,
-et l'évènement pour lequel vous êtes en attente, peut jamais avoir lieu
+ent</command> Ã  l'intÃ©rieur d'un bloc de 
+<command>try</command>. Un bloc de <command>try</command> est exÃ©cutÃ© comme une seule et mÃªme transaction,
+et l'Ã©vÃ¨nement pour lequel vous Ãªtes en attente, peut jamais avoir lieu
 dans le scope de la transaction.</para>
 
 <programlisting>
@@ -1040,25 +1039,25 @@
 </programlisting></question>
 
 <answer><para> Vous ne devez pas invoquer<xref linkend="stmtwaitevent"/>
-à l'intérieur d'un bloc de<quote>try</quote>.</para></answer>
+Ã  l'intÃ©rieur d'un bloc de<quote>try</quote>.</para></answer>
 
 </qandaentry>
 
 <qandaentry>
 <question><para>Slony-I: cannot add table to currently subscribed set 1</para>
 
-<para> J'ai essayé de rajouter une table à un jeu d'ensemble et j'ai le message
+<para> J'ai essayÃ© de rajouter une table Ã  un jeu d'ensemble et j'ai le message
 d'erreur suivant :
 
 <screen>
 	Slony-I: cannot add table to currently subscribed set 1
 </screen></para></question>
 
-<answer><para> Vous ne pouvez pas rajouter des tables à un ensemble pour lequel il y a des abonnées.
+<answer><para> Vous ne pouvez pas rajouter des tables Ã  un ensemble pour lequel il y a des abonnÃ©es.
 </para>
 
-<para>Le contournement est de créer un <emphasis>AUTRE</emphasis>
-jeu de table, d'y rajouter la table souhaitée, brancher les serveurs abonnés au "jeu 1" sur le nouveau qu'on vient de créer,et en suite de
+<para>Le contournement est de crÃ©er un <emphasis>AUTRE</emphasis>
+jeu de table, d'y rajouter la table souhaitÃ©e, brancher les serveurs abonnÃ©s au "jeu 1" sur le nouveau qu'on vient de crÃ©er,et en suite de
 fusionner les 2 jeux ensemble.</para>
 </answer></qandaentry>
 
@@ -1066,7 +1065,7 @@
 <question><para>
 ERROR: duplicate key violates unique constraint "sl_table-pkey"</para>
 
-<para>En essayant de monter un deuxième jeu de réplication, j'ai ce message :I tried setting up a second replication set, and got the following error:
+<para>En essayant de monter un deuxiÃ¨me jeu de rÃ©plication, j'ai ce message :I tried setting up a second replication set, and got the following error:
 
 <screen>
 stdin:9: Could not create subscription set 2 for oxrslive!
@@ -1074,8 +1073,8 @@
 CONTEXT:  PL/pgSQL function "setaddtable_int" line 71 at SQL statement
 </screen></para></question>
 
-<answer><para> Les identifaiants des tables utilisées dans  <xref linkend="stmtsetaddtable"/>
-demande d'être unique <emphasis>A TRAVERS TOUT LE JEU</emphasis>.  Thus,
+<answer><para> Les identifaiants des tables utilisÃ©es dans  <xref linkend="stmtsetaddtable"/>
+demande d'Ãªtre unique <emphasis>A TRAVERS TOUT LE JEU</emphasis>.  Thus,
 you can't restart numbering at 1 for a second set; if you are
 numbering them consecutively, a subsequent set has to start with IDs
 after where the previous set(s) left off.</para> </answer>
@@ -1083,32 +1082,32 @@
 
 <qandaentry>
 <question><para> L'un de mes serveurs tombe en erreur sur (&lslon; / postmaster was
-down) et dont aucune notification depuis plusieurs jours.Maintenant lorsque &lslon; sur ce noeud démarre,
-ll tourne durant cinq minutes, puis s'arrête,
+down) et dont aucune notification depuis plusieurs jours.Maintenant lorsque &lslon; sur ce noeud dÃ©marre,
+ll tourne durant cinq minutes, puis s'arrÃªte,
 avec l'erreur suivante : <command>ERROR: remoteListenThread_%d: timeout
 for event selection</command> What's wrong, and what do I do? </para> 
 </question>
 
-<answer><para> Le problème est que le port d'écoute de ce processus (dans
-<filename>src/slon/remote_listener.c</filename>) arrive à une expiration de temps, lors il tente
-de déterminer quels est l'évènement à reprendre sur ce noeud.Par défaut
-le délai d'expiration de cette interrogation est de 5 minutes; si la reprise contient plus d'évènement,
+<answer><para> Le problÃ¨me est que le port d'Ã©coute de ce processus (dans
+<filename>src/slon/remote_listener.c</filename>) arrive Ã  une expiration de temps, lors il tente
+de dÃ©terminer quels est l'Ã©vÃ¨nement Ã  reprendre sur ce noeud.Par dÃ©faut
+le dÃ©lai d'expiration de cette interrogation est de 5 minutes; si la reprise contient plus d'Ã©vÃ¨nement,
 cela prendra beaucoup plus de temp.
  </para> </answer>
 
-<answer><para> La réponse à cette question pour les versions de &slony1; antérieur à  1.1.7, 1.2.7, et à 1.3, serait de dire
-d'augmenter le délai d'expiration dans
+<answer><para> La rÃ©ponse Ã  cette question pour les versions de &slony1; antÃ©rieur Ã   1.1.7, 1.2.7, et Ã  1.3, serait de dire
+d'augmenter le dÃ©lai d'expiration dans
 <filename>src/slon/remote_listener.c</filename>, de recompiler &lslon;, et enfin de ressayer.  </para> </answer>
 
-<answer><para> Une autre réponse serait de conseiller de reconstruire entièrement le noeud ayant échoué, 
-à l'aide de la commande &lslonik;  <xref linkend="stmtdropnode"/> en le supprimant d'abord et le recréer après.
-Si les mises à jours sont volumineuses côté base de données, il vaut mieux reconstruir plutôt que d'essayer de rattraper.
+<answer><para> Une autre rÃ©ponse serait de conseiller de reconstruire entiÃ¨rement le noeud ayant Ã©chouÃ©, 
+Ã  l'aide de la commande &lslonik;  <xref linkend="stmtdropnode"/> en le supprimant d'abord et le recrÃ©er aprÃ¨s.
+Si les mises Ã  jours sont volumineuses cÃ´tÃ© base de donnÃ©es, il vaut mieux reconstruir plutÃ´t que d'essayer de rattraper.
 </para> </answer>
   
-<answer><para> Dans les version récentes de &slony1;, il y a une nouveau paramètre appelé :<xref
-linkend="slon-config-remote-listen-timeout"/>;qui permet de modifier le délai d'expiration
-et de relancer les mises à jour. Bien sûr, comme il a été mentionné ci-dessus, il est plus efficace dans ce cas
-de supprimer et de recréer le noeud, que d'essayer de rattraper les mises à jours. </para> </answer>
+<answer><para> Dans les version rÃ©centes de &slony1;, il y a une nouveau paramÃ¨tre appelÃ© :<xref
+linkend="slon-config-remote-listen-timeout"/>;qui permet de modifier le dÃ©lai d'expiration
+et de relancer les mises Ã  jour. Bien sÃ»r, comme il a Ã©tÃ© mentionnÃ© ci-dessus, il est plus efficace dans ce cas
+de supprimer et de recrÃ©er le noeud, que d'essayer de rattraper les mises Ã  jours. </para> </answer>
 
 </qandaentry>
 
@@ -1125,28 +1124,28 @@
 </question>
 
 <answer> <para> Les causes de ce genre de choses sont multiples.
-Il y a une question évoquée par ce genre de pathologie, où le problème d'augmentation du volume dans
+Il y a une question Ã©voquÃ©e par ce genre de pathologie, oÃ¹ le problÃ¨me d'augmentation du volume dans
  <link linkend="pglistenerfull"> 
-&pglistener; est dû au fait que la purge via vaccume n'est pas exécutée.</link>
+&pglistener; est dÃ» au fait que la purge via vaccume n'est pas exÃ©cutÃ©e.</link>
 </para>
 
 <para> Par rapprochement <quote> on peut avancer </quote>, pour cette augmentation de volume,
 est que une session existante sur le serveur rend le noeud
  <command>
-IDLE IN TRANSACTION </command> pour une durée infinie. </para>
+IDLE IN TRANSACTION </command> pour une durÃ©e infinie. </para>
 
-<para> La session ouverte peut avoir des effets négatifs,
-entraînant une dégradation de performances.</para>
+<para> La session ouverte peut avoir des effets nÃ©gatifs,
+entraÃ®nant une dÃ©gradation de performances.</para>
 
 <itemizedlist>
 
-<listitem><para> Le fait de lancer un Vacuum sur la totalité des tables,
+<listitem><para> Le fait de lancer un Vacuum sur la totalitÃ© des tables,
 &pglistener; y compris, ne va pas nettoyer les tuplets pour les transactions qui sont ouvertes et disponible, car elle 
-viennent de démarrer. </para> </listitem>
+viennent de dÃ©marrer. </para> </listitem>
 
 <listitem><para> Le nettoyage des processus ne pourra pas se faire 
-sur les entrées dans <xref linkend="table.sl-log-1"/> et <xref
-linkend="table.sl-seqlog"/>, qui entraîne par conséquence, une croissance 
+sur les entrÃ©es dans <xref linkend="table.sl-log-1"/> et <xref
+linkend="table.sl-seqlog"/>, qui entraÃ®ne par consÃ©quence, une croissance 
 de volume tant que les transactions persistent. </para>
 </listitem>
 </itemizedlist>
@@ -1154,54 +1153,56 @@
 
 <answer> <para> Vous pouvez surveiller, dans la base, ces conditions que si
 dans le fichier d'initialisation de &postgres; <filename> postgresql.conf </filename>
-le paramètre <envar>stats_command_string</envar> est positionner à vrai.
-Dans ce cas, vous pouvez lancer une intérrogation sql comme suit :
+le paramÃ¨tre <envar>stats_command_string</envar> est positionner Ã  vrai.
+Dans ce cas, vous pouvez lancer une intÃ©rrogation sql comme suit :
 <command> select * from pg_stat_activity where current_query like '%IDLE% in transaction';
-</command> dont le résultat vous donnent les activités relatives.  </para> </answer>
+</command> dont le rÃ©sultat vous donnent les activitÃ©s relatives.  </para> </answer>
 
-<answer> <para> Vous devrez également être capable de rechercher
+<answer> <para> Vous devrez Ã©galement Ãªtre capable de rechercher
 les <quote> idle in transaction </quote> dans la table des processes 
-ceux qui détiennent encore des transactions actives.
+ceux qui dÃ©tiennent encore des transactions actives.
  </para> </answer>
 
-<answer> <para> Il est aussi possible (quoique plus rare)que le problème soit causé par
-une transaction, qui pour d’autres raisons, est conservée comme ouverte et ceci pour une longue durée.
+<answer> <para> Il est aussi possible (quoique plus rare)que le problÃ¨me soit causÃ© par
+une transaction, qui pour dÂ’autres raisons, est conservÃ©e comme ouverte et ceci pour une longue durÃ©e.
 La table <envar> query_start </envar> time in <envar>
-pg_stat_activity </envar> vous présentra les longues requêtes qui sont dans cet état. </para> </answer>
+pg_stat_activity </envar> vous prÃ©sentra les longues requÃªtes qui sont dans cet Ã©tat. </para> </answer>
 
-<answer> <para> Il est prévue que &postgres; aie un paramètre d'expiration de 
-délai, <envar> open_idle_transaction_timeout </envar>, qui permettrais
-de venir à bout des transactions dont le temps arrivent à échéance.
+<answer> <para> Il est prÃ©vue que &postgres; aie un paramÃ¨tre d'expiration de 
+dÃ©lai, <envar> open_idle_transaction_timeout </envar>, qui permettrais
+de venir Ã  bout des transactions dont le temps arrivent Ã  Ã©chÃ©ance.
 
 Le concept de connexion par pool, engendre ce genre de situation d'erreur.
-Il est prévu des amélioration où <productname> <link linkend="pgpool"> pgpool
-</link> </productname> devrait présenter des meilleurs alternatifs afin de mieux gérer les connexion partagée à
+Il est prÃ©vu des amÃ©lioration oÃ¹ <productname> <link linkend="pgpool"> pgpool
+</link> </productname> devrait prÃ©senter des meilleurs alternatifs afin de mieux gÃ©rer les connexion partagÃ©e Ã 
 travers la notion de 'pool'.
-Cela devrez faire diminuer les bugs rencontrés dans les applications
+Cela devrez faire diminuer les bugs rencontrÃ©s dans les applications
 Java ou PHP;si un nombre restreint de <emphasis> vrai </emphasis>
-connections sont conservées dans<productname>pgpool</productname>, ceci va faire croire à la base,
-que en réalité  les connexions de l'application reste dans un statut 
-disponible et en activité, pour de<para>J'avis lancé I have been running &slony1; on a node for a while, and am
+connections sont conservÃ©es dans<productname>pgpool</productname>, ceci va faire croire Ã  la base,
+que en rÃ©alitÃ©  les connexions de l'application reste dans un statut 
+disponible et en activitÃ©, pour de
+
+J'avis lancÃ© I have been running &slony1; on a node for a while, and am
 s heures durant.
 </para> </answer>
 
 </qandaentry> 
 
 <qandaentry id="faq17">
-<question><para>Après une suppression de noeud, le fichier journal <xref linkend="table.sl-log-1"/>
-n'est plus purgé.</para></question>
+<question><para>AprÃ¨s une suppression de noeud, le fichier journal <xref linkend="table.sl-log-1"/>
+n'est plus purgÃ©.</para></question>
 
-<answer><para> Ceci est un scénario commun dans les versions d'avant 1.0.5, comme
-le <quote>nettoyage</quote> du prend effet en oubliant les entrées des
- tables &slony1; <xref linkend="table.sl-confirm"/>, pour le serveur qui vient de disparaître.</para>
+<answer><para> Ceci est un scÃ©nario commun dans les versions d'avant 1.0.5, comme
+le <quote>nettoyage</quote> du prend effet en oubliant les entrÃ©es des
+ tables &slony1; <xref linkend="table.sl-confirm"/>, pour le serveur qui vient de disparaÃ®tre.</para>
 
-<para> Le noeud ne s'occupe plus de mettre à jour des confirmations, comme quoi 
-syncs vient de s'effectuer sur ce serveur, car il estime qu'il ne peut sans risque supprimer les entrées plus récentes
-que la dernière <xref linkend="table.sl-confirm"/> entrée, qui plutôt
-limite la capacité de purge des anciens fichiers journaux.</para>
+<para> Le noeud ne s'occupe plus de mettre Ã  jour des confirmations, comme quoi 
+syncs vient de s'effectuer sur ce serveur, car il estime qu'il ne peut sans risque supprimer les entrÃ©es plus rÃ©centes
+que la derniÃ¨re <xref linkend="table.sl-confirm"/> entrÃ©e, qui plutÃ´t
+limite la capacitÃ© de purge des anciens fichiers journaux.</para>
 
-<para>Diagnostics: Exécuter les requêtes suivantes pour voir si il y a 
-un résidus d'entrées en état de <quote>fantôme/obsolète/bloqué</quote> <xref
+<para>Diagnostics: ExÃ©cuter les requÃªtes suivantes pour voir si il y a 
+un rÃ©sidus d'entrÃ©es en Ã©tat de <quote>fantÃ´me/obsolÃ¨te/bloquÃ©</quote> <xref
 linkend="table.sl-confirm"/>:
 
 <screen>
@@ -1218,40 +1219,42 @@
 </screen></para>
 
 <para>En version 1.0.5, la fonction <xref linkend="stmtdropnode"/> 
-purges les données dans <xref linkend="table.sl-confirm"/> pour le noeud qui quitte la configuration.
-Dans les versions plus anciennes, cposés par quelques tables du groupe de réplication ? Cela bloquerait invisiblement That would somewhat-invisibly
-eci demande une exécution manuelle.
-Supposons que l'identifiant du noeud soit 3, alors la requête sera la suivante :
+purges les donnÃ©es dans <xref linkend="table.sl-confirm"/> pour le noeud qui quitte la configuration.
+Dans les versions plus anciennes, cposÃ©s par quelques tables du groupe de rÃ©plication ? Cela bloquerait invisiblement That would somewhat-invisibly
+eci demande une exÃ©cution manuelle.
+Supposons que l'identifiant du noeud soit 3, alors la requÃªte sera la suivante :
 
 
 <screen>
 delete from _namespace.sl_confirm where con_origin = 3 or con_received = 3;
 </screen></para>
 
-<para>Sinon, pour chasser <quote>tous les fantômes,</quote> vous pouvez utiliser 
+<para>Sinon, pour chasser <quote>tous les fantÃ´mes,</quote> vous pouvez utiliser 
 <screen>
 oxrsbar=# delete from _oxrsbar.sl_confirm where con_origin not in (select no_id from _oxrsbar.sl_node) or con_received not in (select no_id from _oxrsbar.sl_node);
 DELETE 6
 </screen></para>
 
 <para>Une  <quote>raisonnable diligence</quote> dicterait de commencer par
-<command>BEGIN</command>, voir le contenu de<command>SYNC</command> de se mettre à jour à l'origine, via le planificateur to be updated on the origin based on a
+<command>BEGIN</command>, voir le contenu de<command>SYNC</command> de se mettre Ã  jour Ã  l'origine, via le planificateur to be updated on the origin based on a
  
-<xref linkend="table.sl-confirm"/> avant, <question><para>Quelque noeud commencent à prendre du retard Some nodes start consistently falling behind</para>
-en veillant à ce que seul les bons enregistrements 
-sont purgés, et puis, seulement après avoir vérifier cette suppression, valider l'opération par une  <command>COMMIT</command>.  Si 
-vous supprimer par erreur les données d'un autre noeud, votre journée est perdu le temps de rattraper l'erreur commise.</para>
+<xref linkend="table.sl-confirm"/> avant, 
 
-<para>Vous aurez besoin d'exécuter cette opération, sur chaque noeud qui reste...</para>
+Quelque noeud commencent Ã  prendre du retard Some nodes start consistently falling behind
+en veillant Ã  ce que seul les bons enregistrements 
+sont purgÃ©s, et puis, seulement aprÃ¨s avoir vÃ©rifier cette suppression, valider l'opÃ©ration par une  <command>COMMIT</command>.  Si 
+vous supprimer par erreur les donnÃ©es d'un autre noeud, votre journÃ©e est perdu le temps de rattraper l'erreur commise.</para>
 
-<para>A noter que dans la version 1.0.5, ce n'est plus un problème, car il purge les entrées inutiles
-de <xref linkend="table.sl-confirm"/> à deux endroits :
+<para>Vous aurez besoin d'exÃ©cuter cette opÃ©ration, sur chaque noeud qui reste...</para>
 
+<para>A noter que dans la version 1.0.5, ce n'est plus un problÃ¨me, car il purge les entrÃ©es inutiles
+de <xref linkend="table.sl-confirm"/> Ã  deux endroits :
+
 <itemizedlist>
-<listitem><para> Lorsque un noeud est supprimé</para></listitem>
+<listitem><para> Lorsque un noeud est supprimÃ©</para></listitem>
 
-<listitem><para> Au démarrage de chaque lancement de 
-<function>cleanupEvent</function>, qui est l'évènement qui purge les vieilles données de
+<listitem><para> Au dÃ©marrage de chaque lancement de 
+<function>cleanupEvent</function>, qui est l'Ã©vÃ¨nement qui purge les vieilles donnÃ©es de
 <xref linkend="table.sl-log-1"/> et de <xref
 linkend="table.sl-seqlog"/></para></listitem> </itemizedlist></para>
 </answer>
@@ -1259,31 +1262,31 @@
 
 <qandaentry>
 
-<question><para>Le <application>slon</application> se dépense un week-end entier hors de la 
-commission [for some reason], et il prend énormément de temps pour exécuter un 
+<question><para>Le <application>slon</application> se dÃ©pense un week-end entier hors de la 
+commission [for some reason], et il prend Ã©normÃ©ment de temps pour exÃ©cuter un 
 sync.</para></question>
 
 <answer><para> Vous pourriez jeter un coup d'oeil, sur les tables <xref
 linkend="table.sl-log-1"/>/<xref linkend="table.sl-log-2"/>, 
-et voir brièvement si il y a réellement un énorme &slony1;
-encours d'exécution. Jusqu'au au moins la version  1.0.2, il faut qu'il y ait un 
-&lslon; connecté pour que <command>SYNC</command> soit encours.</para>
+et voir briÃ¨vement si il y a rÃ©ellement un Ã©norme &slony1;
+encours d'exÃ©cution. Jusqu'au au moins la version  1.0.2, il faut qu'il y ait un 
+&lslon; connectÃ© pour que <command>SYNC</command> soit encours.</para>
 
-<para>Si cet évènement n'est pas généré, alors toute la mise à jour, et celle-ci jusqu'au prochain évènement va se faire 
-à travers un énorme transaction &slony1;.</para>
+<para>Si cet Ã©vÃ¨nement n'est pas gÃ©nÃ©rÃ©, alors toute la mise Ã  jour, et celle-ci jusqu'au prochain Ã©vÃ¨nement va se faire 
+Ã  travers un Ã©norme transaction &slony1;.</para>
 
-<para>Conclusion: Même si il n'y a pas d'abonné en cause,
+<para>Conclusion: MÃªme si il n'y a pas d'abonnÃ© en cause,
 vous avez <emphasis>vraiment</emphasis> besoin d'un 
 <application>slon</application> en fonctionnement pour entretenir le noeud source.</para>
 
-<para>&slony1; 1.1 fournit une procédure stockée qui permet aux comptes Synchros d'être 
-mis à jour par le planificateur <application>cron</application>même si <xref
-linkend="slon"/> ne tourne pas en tâche de fond.</para> </answer></qandaentry>
+<para>&slony1; 1.1 fournit une procÃ©dure stockÃ©e qui permet aux comptes Synchros d'Ãªtre 
+mis Ã  jour par le planificateur <application>cron</application>mÃªme si <xref
+linkend="slon"/> ne tourne pas en tÃ¢che de fond.</para> </answer></qandaentry>
 
 <qandaentry id="PGLISTENERFULL">
-<question><para>Quelques noeuds commencent à se ralentir constamment. </para>
+<question><para>Quelques noeuds commencent Ã  se ralentir constamment. </para>
 
-<para>J'avais lancé, depuis un moment, &slony1; sur un noeud, et je vois que la machine est à
+<para>J'avais lancÃ©, depuis un moment, &slony1; sur un noeud, et je vois que la machine est Ã 
 genoux.</para>
 
 <para>Je vois des instructions en cours comme :
@@ -1291,73 +1294,75 @@
 	fetch 100 from LOG;
 </screen></para></question>
 
-<answer><para> Ceci peut être un exemple type de &pglistener; (la table qui contient les données de 
-<command>NOTIFY</command>)avec en abondance, des données obsolètes des tuplets mortes.
+<answer><para> Ceci peut Ãªtre un exemple type de &pglistener; (la table qui contient les donnÃ©es de 
+<command>NOTIFY</command>)avec en abondance, des donnÃ©es obsolÃ¨tes des tuplets mortes.
 
 
-Ce qui fait que l'évènement <command>NOTIFY</command> prend du temps,
-et cause le ralentissement de plus en plus fort du noeud affecté.</para>
+Ce qui fait que l'Ã©vÃ¨nement <command>NOTIFY</command> prend du temps,
+et cause le ralentissement de plus en plus fort du noeud affectÃ©.</para>
 
 <para>Vous avez probablement besoin d'effectuer un <command>VACUUM FULL</command> sur
 &pglistener;, pour le nettoyer vigoureusement, et besoin de purger 
-&pglistener; vraiment fréquemment. Une planification tous les cinq minutes fera l'affaire.</para>
+&pglistener; vraiment frÃ©quemment. Une planification tous les cinq minutes fera l'affaire.</para>
 
-<para> Le démon Slon fait déjà une purge d'un groupe de table,et
-<filename>cleanup_thread.c</filename> contient une liste de tables à nettoyer fréquemment de manière automatique.
-Dans &slony1; 1.0.2,&pglistener; ceci n'est pas inclus. Dans 1.0.5 et supérieur, il est purgé régulièrement,
-du coup ce problème n'a plus le lieu d'être. Dans la version 1.2,
-&pglistener; sera seulement utilisé quand le noeud reçoit périodiquement l'évènement,
-ce qui signifie que ce problème la plupart du temps disparaître même
-en présence des transaction longues et lentes...</para>
+<para> Le dÃ©mon Slon fait dÃ©jÃ  une purge d'un groupe de table,et
+<filename>cleanup_thread.c</filename> contient une liste de tables Ã  nettoyer frÃ©quemment de maniÃ¨re automatique.
+Dans &slony1; 1.0.2,&pglistener; ceci n'est pas inclus. Dans 1.0.5 et supÃ©rieur, il est purgÃ© rÃ©guliÃ¨rement,
+du coup ce problÃ¨me n'a plus le lieu d'Ãªtre. Dans la version 1.2,
+&pglistener; sera seulement utilisÃ© quand le noeud reÃ§oit pÃ©riodiquement l'Ã©vÃ¨nement,
+ce qui signifie que ce problÃ¨me la plupart du temps disparaÃ®tre mÃªme
+en prÃ©sence des transaction longues et lentes...</para>
 
-<para>Il y a, cependant, toujours un scénario où ceci peut
+<para>Il y a, cependant, toujours un scÃ©nario oÃ¹ ceci peut
 <quote>mordre toujours.</quote> Sous MVCC, vacuums ne peut pas supprimer des tuplets qui sont rendus 
-<quote>obsolètes</quote> à n'importe quel moment après le démarrage de la transaction la plus ancienne
-qui reste encore ouverte. Les transactions longues, devront être évitées, car elles sont sources de soucis, 
-même sur un serveur abonné.</para> </answer></qandaentry>
+<quote>obsolÃ¨tes</quote> Ã  n'importe quel moment aprÃ¨s le dÃ©marrage de la transaction la plus ancienne
+qui reste encore ouverte. Les transactions longues, devront Ãªtre Ã©vitÃ©es, car elles sont sources de soucis, 
+mÃªme sur un serveur abonnÃ©.</para> </answer></qandaentry>
 
-<qandaentry> <question> <para> J'ai soumis un requête <xref
+<qandaentry> <question> <para> J'ai soumis un requÃªte <xref
 linkend="stmtmoveset"/> / <xref linkend="stmtddlscript"/>, et 
-elle semble être coincée, sur mon serveur. Les journaux de &slony1; ne mon<listitem><para> La <command>restitution depuis LOG</command> procède à lire query will draw
+elle semble Ãªtre coincÃ©e, sur mon serveur. Les journaux de &slony1; ne mon
+
+La <command>restitution depuis LOG</command> procÃ¨de Ã  lire query will draw
 trent 
-pas d'qui est défini dans le fichier which is defined in the
+pas d'qui est dÃ©fini dans le fichier which is defined in the
 erreurs ni d'avertissement </para> </question>
 
-<answer> <para> Il est possible que vous soyez en train d'exécuter
+<answer> <para> Il est possible que vous soyez en train d'exÃ©cuter
 <application>pg_autovacuum</application>, et qu'l soit tombait sur des verrous
-posés par des tables dans le groupe de réplication ? Ceci voudra dire que de manière silencieuse
-ock &slony1; est bloqué d'effectuer des opérations qui exigent l'acquisition des <link
+posÃ©s par des tables dans le groupe de rÃ©plication ? Ceci voudra dire que de maniÃ¨re silencieuse
+ock &slony1; est bloquÃ© d'effectuer des opÃ©rations qui exigent l'acquisition des <link
 linkend="locking"> exclusifs. </link> </para>
 
 
-<para> Vous pourriez vérifier ce genre de verrous à l'aide de cette requête :
+<para> Vous pourriez vÃ©rifier ce genre de verrous Ã  l'aide de cette requÃªte :
 <command> select l.*, c.relname from pg_locks l, pg_class c
 where c.oid = l.relation ; </command> Un verrous
-<envar>ShareUpdateExclusiveLock</envar> va bloquer les opérations de &slony1;
-qui nécessitent leurs propres verrous exclusifs, qui sont probablement en attentes, 
-marqués comme n'étant pas garantis. </para>
+<envar>ShareUpdateExclusiveLock</envar> va bloquer les opÃ©rations de &slony1;
+qui nÃ©cessitent leurs propres verrous exclusifs, qui sont probablement en attentes, 
+marquÃ©s comme n'Ã©tant pas garantis. </para>
 </answer> </qandaentry>
 
 <qandaentry>
 
-<question><para> Je remarque que dans les journaux d'un &lslon; l'état commute fréquent 
-entre le <quote>vote</quote>  démarré et arrêt. 
-reporté fréquemment <quote>LISTEN - switch from polling mode to use
+<question><para> Je remarque que dans les journaux d'un &lslon; l'Ã©tat commute frÃ©quent 
+entre le <quote>vote</quote>  dÃ©marrÃ© et arrÃªt. 
+reportÃ© frÃ©quemment <quote>LISTEN - switch from polling mode to use
 LISTEN</quote> et  <quote>UNLISTEN - switch into polling
 mode</quote>. </para> </question>
 
-Les seuils pour commuter entre ces modes sont commandés par le linkend= le " slon-config-synchro-intervalle "/> 
-de <xref de paramètres de configuration et le linkend= le " slon-config-synchro-intervalle-temps mort "/> 
-de <xref ; si la valeur du dépassement de durée (qui se transfère sur 10000, impliquant 10s) est le bas gardé, 
-qui le rend facile pour le &lslon ; pour décider de retourner au mode de <quote>listening</quote>.  
-Vous pouvez vouloir augmenter la valeur du paramètre de temps imparti
+Les seuils pour commuter entre ces modes sont commandÃ©s par le <xref linkend="slon-config-synchro-intervalle "/> 
+de <xref linkend="slon-config-synchro-intervalle-temps mort "/> 
+de <xref /> ; si la valeur du dÃ©passement de durÃ©e (qui se transfÃ¨re sur 10000, impliquant 10s) est le bas gardÃ©, 
+qui le rend facile pour le &lslon; pour dÃ©cider de retourner au mode de <quote>listening</quote>.  
+Vous pouvez vouloir augmenter la valeur du paramÃ¨tre de temps imparti
 
-<answer><para> Les seuils pour commuter entre ces modes sont commandés par 
-le paramètres de configuration <xref
+<answer><para> Les seuils pour commuter entre ces modes sont commandÃ©s par 
+le paramÃ¨tres de configuration <xref
 linkend="slon-config-sync-interval"/> et celui de <xref
 linkend="slon-config-sync-interval-timeout"/>; si la valeur du temps d'expiration
-(par défaut étant à 10000, impliquant 10s) est maintenu bas, facilite la situation pour que 
-&lslon; décide de retourner à l'état  <quote>listening</quote>.
+(par dÃ©faut Ã©tant Ã  10000, impliquant 10s) est maintenu bas, facilite la situation pour que 
+&lslon; dÃ©cide de retourner Ã  l'Ã©tat  <quote>listening</quote>.
 Vous devriez augmenter cette valeur d'expiration de temps. </para>
 </answer>
 </qandaentry>
@@ -1366,26 +1371,26 @@
 </qandadiv>
 <qandadiv id="faqbugs"> <title> &slony1; FAQ: &slony1; Bugs dans les versions anciennes</title>
 <qandaentry>
-<question><para>Le process &lslon; processes entretenant mes abonnés devient énorme en taille
-, mettant en danger la ressource du système en terme de swap ainsi que le risque d'attendre la taille limite
+<question><para>Le process &lslon; processes entretenant mes abonnÃ©s devient Ã©norme en taille
+, mettant en danger la ressource du systÃ¨me en terme de swap ainsi que le risque d'attendre la taille limite
 de 2GB par processe . </para> 
 
-<para> D'ailleurs, les données que je suis en train de répliquer,
+<para> D'ailleurs, les donnÃ©es que je suis en train de rÃ©pliquer,
 ont une taille assez grande. Il y a des enregistrements dont la taille
-dépasse des dizaine de mega octets.Peut-être ceci n'est pas approprié ? </para> </question>
+dÃ©passe des dizaine de mega octets.Peut-Ãªtre ceci n'est pas appropriÃ© ? </para> </question>
 
-<answer> <para> Oui, ces enregistrements volumineux sont à la racine du problème.
-L'explication vient du fait que &lslon; normalement procède par paquet de
- 100 enregistrement à la fois, lorsqu'un abonné fait des interrogation depuis le fournisseur.
+<answer> <para> Oui, ces enregistrements volumineux sont Ã  la racine du problÃ¨me.
+L'explication vient du fait que &lslon; normalement procÃ¨de par paquet de
+ 100 enregistrement Ã  la fois, lorsqu'un abonnÃ© fait des interrogation depuis le fournisseur.
 Ainsi si la taille moyenne des enregistrements est de 
-is 10MB, ceci entraîne des données atteignant 1000MB qui sont en attente de 
+is 10MB, ceci entraÃ®ne des donnÃ©es atteignant 1000MB qui sont en attente de 
  <command>INSERT</command> ou de <command>UPDATE</command>
-à procéder par le processe &lslon;.</para>
+Ã  procÃ©der par le processe &lslon;.</para>
 
-<para> Cela mène évidemment à &lslon; d'atteindre des tailles gigantesques. </para>
+<para> Cela mÃ¨ne Ã©videmment Ã  &lslon; d'atteindre des tailles gigantesques. </para>
 
-<para> Nombre d'enregistrement restitués par la valeur <envar> SLON_DTA_FETCH_SIZE </envar>,
-défini par le fichier <filename>src/slon/slon.h</filename>. La partie extraite appropriée à ce paramètre est :
+<para> Nombre d'enregistrement restituÃ©s par la valeur <envar> SLON_DTA_FETCH_SIZE </envar>,
+dÃ©fini par le fichier <filename>src/slon/slon.h</filename>. La partie extraite appropriÃ©e Ã  ce paramÃ¨tre est :
 </para>
  
 <programlisting>
@@ -1400,79 +1405,79 @@
 #endif
 </programlisting>
 
-<para> Si vous rencontrez ce problème, vous devriez définir
- <envar> SLON_DATA_FETCH_SIZE </envar>, peut-être réduit par un facteur de 10
+<para> Si vous rencontrez ce problÃ¨me, vous devriez dÃ©finir
+ <envar> SLON_DATA_FETCH_SIZE </envar>, peut-Ãªtre rÃ©duit par un facteur de 10
  10, et de recompiler ensuite  &lslon;.  Il y a deux 
-définitions dont <envar> SLON_CHECK_CMDTUPLES</envar> qui laisse faire une certaine surveillance
-supplémentaire pour s'assurer que le abonnés ne sont pas tombé hors de la
-SYNC en regard du fournisseur. Par défaut, cette option est désactivée, ainsi il faudra prendre la deuxième option,
-afin de modifier la valeur par defeuillé, il faudra changer 
+dÃ©finitions dont <envar> SLON_CHECK_CMDTUPLES</envar> qui laisse faire une certaine surveillance
+supplÃ©mentaire pour s'assurer que le abonnÃ©s ne sont pas tombÃ© hors de la
+SYNC en regard du fournisseur. Par dÃ©faut, cette option est dÃ©sactivÃ©e, ainsi il faudra prendre la deuxiÃ¨me option,
+afin de modifier la valeur par defeuillÃ©, il faudra changer 
 <envar> SLON_DATA_FETCH_SIZE </envar> pour remplacer  10 par 1. </para> </answer>
 
 <answer><para> Dans la version 1.2, la configuration des valeurs de<xref
 linkend="slon-config-max-rowsize"/> et de <xref
-linkend="slon-config-max-largemem"/> sont associées avec un nouveau algorithme 
-qui change la logique des choses, plutôt que de restituer 100
-enregistrements à la fois.</para>
+linkend="slon-config-max-largemem"/> sont associÃ©es avec un nouveau algorithme 
+qui change la logique des choses, plutÃ´t que de restituer 100
+enregistrements Ã  la fois.</para>
 
 <itemizedlist>
 
 <listitem><para> La lecture de <command>fetch from LOG</command> se fera
-par paquet de 500 enregistrements à la fois, tant que la taille n'excède pas 
-<xref linkend="slon-config-max-rowsize"/>.  Avec une valeur par défaut, ceci limitera 
-ce phénomène de consommation de mémoire à la hauteur de 8MB.  </para>
+par paquet de 500 enregistrements Ã  la fois, tant que la taille n'excÃ¨de pas 
+<xref linkend="slon-config-max-rowsize"/>.  Avec une valeur par dÃ©faut, ceci limitera 
+ce phÃ©nomÃ¨ne de consommation de mÃ©moire Ã  la hauteur de 8MB.  </para>
 </listitem>
 
 
-<listitem><para> Les tuplets sont lus jusqu'à ce que la taille n'excède pas
-le paramètre  <xreflinkend="slon-config-max-largemem"/>.  Par défaut, cette restriction
+<listitem><para> Les tuplets sont lus jusqu'Ã  ce que la taille n'excÃ¨de pas
+le paramÃ¨tre  <xref linkend="slon-config-max-largemem"/>.  Par dÃ©faut, cette restriction
 ne consommera pas environ 5MB. Cette valeur n'est pas un seil de limitation stricte;
-si vous avez des tuplets dont la taille est de 50MB, il <emphasis>doit</emphasis> de manière forcée,
-être charger en mémoire. Il n'est pas question de négliger cela.
-Mais &lslon; au moins, n'essayera pas  de charger, à la fois 100 enregistrements coûte que coûte, dépassant les 10GB de 
-mémoire consommée à cet effet.</para> </listitem>
+si vous avez des tuplets dont la taille est de 50MB, il <emphasis>doit</emphasis> de maniÃ¨re forcÃ©e,
+Ãªtre charger en mÃ©moire. Il n'est pas question de nÃ©gliger cela.
+Mais &lslon; au moins, n'essayera pas  de charger, Ã  la fois 100 enregistrements coÃ»te que coÃ»te, dÃ©passant les 10GB de 
+mÃ©moire consommÃ©e Ã  cet effet.</para> </listitem>
 </itemizedlist>
 
-<para> Ceci devrait alléger des problèmes que les gens avaient éprouvé, quand ils ont sporadiquement,
-des séries de tuplets très volumineux. </para>
+<para> Ceci devrait allÃ©ger des problÃ¨mes que les gens avaient Ã©prouvÃ©, quand ils ont sporadiquement,
+des sÃ©ries de tuplets trÃ¨s volumineux. </para>
 </answer>
 </qandaentry>
 
-<qandaentry id="faqunicode"> <question> <para> Je suis en train de répliquer
-les données de type <envar>UNICODE</envar> depuis la version 8.0 de &postgres; à la  version 8.1, 
-et rencontre des problèmes. </para>
+<qandaentry id="faqunicode"> <question> <para> Je suis en train de rÃ©pliquer
+les donnÃ©es de type <envar>UNICODE</envar> depuis la version 8.0 de &postgres; Ã  la  version 8.1, 
+et rencontre des problÃ¨mes. </para>
 </question>
 
-<answer> <para> &postgres; 8.1 est un peu plus strict dans l'usage des codes caractères
-UTF-8 et Unicode, comparé à la version 8.0.</para>
+<answer> <para> &postgres; 8.1 est un peu plus strict dans l'usage des codes caractÃ¨res
+UTF-8 et Unicode, comparÃ© Ã  la version 8.0.</para>
 
-<para> Si vous êtes emmener à utiliser &slony1; pour migrer depuis une plus vieille version à celle  8.1, 
-et que au passage vous devrez faire une conversion depuis le format UTF-8, vous auriez une surprise déplaisante.</para>
+<para> Si vous Ãªtes emmener Ã  utiliser &slony1; pour migrer depuis une plus vieille version Ã  celle  8.1, 
+et que au passage vous devrez faire une conversion depuis le format UTF-8, vous auriez une surprise dÃ©plaisante.</para>
 
 <para> Permettez de supposer que votre version de base est 8.0, avec l'encodage en UTF-8.
-La base va accepter des séquences  <command>'\060\242'</command> en conformité avec UTF-8,
-même si il ne peut vraiment pas. </para>
+La base va accepter des sÃ©quences  <command>'\060\242'</command> en conformitÃ© avec UTF-8,
+mÃªme si il ne peut vraiment pas. </para>
 
-<para> Si vous répliquez dans des instance de &postgres; en version 8.1, il va se plaindre de cela,
-, à la fois lors d'enregistrement d'un abonné, où &slony1; va râler 
-à propos des codes caractères invalides qu'il vient de rencontrer durant la COPY des données,
-qui empêcherait que l'enregistrement se fasse, ou, empêchant de rajouter les données,plutard, 
-lorsqu'il se reproduira, la réplication tombera en erreur sans possibilité de reprise.
+<para> Si vous rÃ©pliquez dans des instance de &postgres; en version 8.1, il va se plaindre de cela,
+, Ã  la fois lors d'enregistrement d'un abonnÃ©, oÃ¹ &slony1; va rÃ¢ler 
+Ã  propos des codes caractÃ¨res invalides qu'il vient de rencontrer durant la COPY des donnÃ©es,
+qui empÃªcherait que l'enregistrement se fasse, ou, empÃªchant de rajouter les donnÃ©es,plutard, 
+lorsqu'il se reproduira, la rÃ©plication tombera en erreur sans possibilitÃ© de reprise.
 (Vous pouvez tricher sur le contenu de sl_log_1, mais assez rapidement 
-cela deviendra <emphasis>vraiment</emphasis> inintéressante...)</para>
+cela deviendra <emphasis>vraiment</emphasis> inintÃ©ressante...)</para>
 
-<para>Il y a déjà eu une discutions sur ce sujet pour savoir ce qu'il faudra faire.
-Pour le moment une stratégie attractive ne se dégage pas sur le sujet. </para>
+<para>Il y a dÃ©jÃ  eu une discutions sur ce sujet pour savoir ce qu'il faudra faire.
+Pour le moment une stratÃ©gie attractive ne se dÃ©gage pas sur le sujet. </para>
 
 <para>Si vous utilisez Unicode avec la version 8.0 de &postgres;, vous courrez un risque
-considérable de corrompre vos données. </para>
+considÃ©rable de corrompre vos donnÃ©es. </para>
 
-<para> Si votre réplication a pour but de convertir une fois pour toutes vos données,
-il y a le risque évoqué; si cela vous arrive, il voudra mieux de convertir vos données de la version 8.0
-d'abord et de re-essayer après. </para>
+<para> Si votre rÃ©plication a pour but de convertir une fois pour toutes vos donnÃ©es,
+il y a le risque Ã©voquÃ©; si cela vous arrive, il voudra mieux de convertir vos donnÃ©es de la version 8.0
+d'abord et de re-essayer aprÃ¨s. </para>
 
-<para> A propos des risques encourus, exécuter la réplication en mettant en jeu des versions différentes,
-semble être non pérennene à maintenir et qu'une migration vers 8.1 s'imposera. </para>
+<para> A propos des risques encourus, exÃ©cuter la rÃ©plication en mettant en jeu des versions diffÃ©rentes,
+semble Ãªtre non pÃ©rennene Ã  maintenir et qu'une migration vers 8.1 s'imposera. </para>
 
 <para> Pour plus d'information, voir la discutions<ulink url=
 "http://archives.postgresql.org/pgsql-hackers/2005-12/msg00181.php">
@@ -1481,11 +1486,11 @@
 </qandaentry>
 
 <qandaentry>
-<question> <para> J'utilise  &slony1; 1.1 avec 4+ nouds dans le jeu où il y a deux jeux d'abonnements,
- 1 et 2, qui ne partagent pas d'autre noeuds. Je découvre que la confirmation pour le jeu 1
+<question> <para> J'utilise  &slony1; 1.1 avec 4+ nouds dans le jeu oÃ¹ il y a deux jeux d'abonnements,
+ 1 et 2, qui ne partagent pas d'autre noeuds. Je dÃ©couvre que la confirmation pour le jeu 1
 n'arrivent jamais pour le noeud souscrivant au jeu 2, et inversement, celles du jeu 2 n'arrivent pas non plus 
-au noeud souscrivant au jeu 1. En conséquence, <xref
-linkend="table.sl-log-1"/> crois et grossi et n'est jamais purgée. Ceci est mentionné
+au noeud souscrivant au jeu 1. En consÃ©quence, <xref
+linkend="table.sl-log-1"/> crois et grossi et n'est jamais purgÃ©e. Ceci est mentionnÃ©
 comme &slony1; <ulink
 url="http://gborg.postgresql.org/project/slony1/bugs/bugupdate.php?1485">
 bug 1485 </ulink>.
@@ -1495,63 +1500,63 @@
 <answer><para> Apparemment le code pour 
 <function>RebuildListenEntries()</function> ne suffit pas pour ce cas.</para>
 
-<para> <function> RebuildListenEntries()</function> sera rectifié dans &slony1; en version 1.2 
+<para> <function> RebuildListenEntries()</function> sera rectifiÃ© dans &slony1; en version 1.2 
 avec un algorithme couvrant ce cas. </para>
 <para> 
-Dans l'intérim, vous voudrez ajouter manuellement quelques entrées <xref linkend="table.sl-listen"/> utilisant <xref
+Dans l'intÃ©rim, vous voudrez ajouter manuellement quelques entrÃ©es <xref linkend="table.sl-listen"/> utilisant <xref
 linkend="stmtstorelisten"/> ou <function>storeListen()</function>,
-basé sur les  (apparemment pas aussi désuet que nous avons pensé) principes décrits dans <xref linkend="listenpaths"/>.
+basÃ© sur les  (apparemment pas aussi dÃ©suet que nous avons pensÃ©) principes dÃ©crits dans <xref linkend="listenpaths"/>.
 
 </para></answer>
 </qandaentry>
 
 <qandaentry>
-<question> <para> Je trouve que quelques colonnes de multibyte (Unicode, Big5) sont tronqués un peu, avec outre les derniers caractères truncés. Pourquoi?
+<question> <para> Je trouve que quelques colonnes de multibyte (Unicode, Big5) sont tronquÃ©s un peu, avec outre les derniers caractÃ¨res truncÃ©s. Pourquoi?
 </para> </question>
 
-<answer> <para> C'était un bug présent jusqu'à la version 1.1.0 de &slony1; ; la manière dont des colonnes étaient capturées par la fonction <function>logtrigger()</function> qui coupait outre les derniers byte d'une colonne représentée dans un format de multibyte. Vérifiez pour voir que votre version de <filename>src/backend/slony1_funcs.c</filename> est bien 1.34 ou suppérieur; le e patch a été intégré dans la version  CVS de  1.34 de ce fichier.  </para> </answer>
+<answer> <para> C'Ã©tait un bug prÃ©sent jusqu'Ã  la version 1.1.0 de &slony1; ; la maniÃ¨re dont des colonnes Ã©taient capturÃ©es par la fonction <function>logtrigger()</function> qui coupait outre les derniers byte d'une colonne reprÃ©sentÃ©e dans un format de multibyte. VÃ©rifiez pour voir que votre version de <filename>src/backend/slony1_funcs.c</filename> est bien 1.34 ou suppÃ©rieur; le e patch a Ã©tÃ© intÃ©grÃ© dans la version  CVS de  1.34 de ce fichier.  </para> </answer>
 </qandaentry>
 
 <qandaentry id="sequenceset"><question><para> <ulink url=
 "http://gborg.postgresql.org/project/slony1/bugs/bugupdate.php?1226">
 Bug #1226 </ulink> indique une condition d'erreur qui peut survenir si
-vous faites placer une réplique composée seulement d'ordres.
+vous faites placer une rÃ©plique composÃ©e seulement d'ordres.
 </para>
 </question>
 
-<answer> <para> Une brève réponse serait de dire qu'une réplication composée seulement d'ordre, n'est pas une bonne pratique <link linkend="bestpractices">
+<answer> <para> Une brÃ¨ve rÃ©ponse serait de dire qu'une rÃ©plication composÃ©e seulement d'ordre, n'est pas une bonne pratique <link linkend="bestpractices">
 .</link> </para>
 </answer>
 
 <answer>
-<para> Le problème avec un ensemble d'ordre  seulement si vous avez un cas pour lequel les seuls abonnements qui sont en activité pour un abonné particulier vis à vis d'un fournisseur particulier, sont pour les jeux <quote>sequence-only</quote>. Si un noeud entre dans cet état,
-la réplique échouera, étant donnée la requête qui collectera les données depuis <xref
-linkend="table.sl-log-1"/> n'aura plus de tables à trouver et par conséquence la requête tombera en erreur.  S'un jeu de réplication de nouveau <emphasis>avec</emphasis>
-des tables reapparît, tout va fonctionner correctement; il 
- <emphasis>paraîtra</emphasis> tout simplement effrayant.
+<para> Le problÃ¨me avec un ensemble d'ordre  seulement si vous avez un cas pour lequel les seuls abonnements qui sont en activitÃ© pour un abonnÃ© particulier vis Ã  vis d'un fournisseur particulier, sont pour les jeux <quote>sequence-only</quote>. Si un noeud entre dans cet Ã©tat,
+la rÃ©plique Ã©chouera, Ã©tant donnÃ©e la requÃªte qui collectera les donnÃ©es depuis <xref
+linkend="table.sl-log-1"/> n'aura plus de tables Ã  trouver et par consÃ©quence la requÃªte tombera en erreur.  S'un jeu de rÃ©plication de nouveau <emphasis>avec</emphasis>
+des tables reapparÃ®t, tout va fonctionner correctement; il 
+ <emphasis>paraÃ®tra</emphasis> tout simplement effrayant.
 </para>
 
-<para> Ce problème devrait être résolu un certaine temps après &slony1;
+<para> Ce problÃ¨me devrait Ãªtre rÃ©solu un certaine temps aprÃ¨s &slony1;
 1.1.0.</para>
 </answer>
 </qandaentry>
 
 <qandaentry>
-<question><para>Je dois supprimer une table d'un ensemble de réplication</para></question>
+<question><para>Je dois supprimer une table d'un ensemble de rÃ©plication</para></question>
 <answer><para>
-Ceci peut être accompli de plusieurs manières, pas toutes également souhaitables;-).
+Ceci peut Ãªtre accompli de plusieurs maniÃ¨res, pas toutes Ã©galement souhaitables;-).
 
 <itemizedlist>
 
-<listitem><para> Vous pourriez supprimer tout  le jeu de réplication, et les recréer avec juste les tables dont vous avez besoin.  Hélas, ce signifie reproduire un tas de données, et tue l'intérêt du cluster sur lequel cela se produit.</para></listitem>
+<listitem><para> Vous pourriez supprimer tout  le jeu de rÃ©plication, et les recrÃ©er avec juste les tables dont vous avez besoin.  HÃ©las, ce signifie reproduire un tas de donnÃ©es, et tue l'intÃ©rÃªt du cluster sur lequel cela se produit.</para></listitem>
 
-<listitem><para> Si vous êtes en version 1.0.5 ou supérieur, il y a une commande SET DROP TABLE, qui fera  "l'affaire."</para></listitem>
+<listitem><para> Si vous Ãªtes en version 1.0.5 ou supÃ©rieur, il y a une commande SET DROP TABLE, qui fera  "l'affaire."</para></listitem>
 
 <listitem><para> Si vous employez toujours 1.0.1 ou 1.0.2, l'
-<emphasis>essentiel de la fonctionnalité de <xref linkend="stmtsetdroptable"/>
-impliquant <function>droptable_int()</function> est présent.
-Vous pouvez feuilleter cela à la main en trouvant l'identification de la table à supprimer, et que vous pouvez trouver dedans<xref
-linkend="table.sl-table"/>, et après lancer les trois requêtes suivantes sur chaque noeud :</emphasis>
+<emphasis>essentiel de la fonctionnalitÃ© de <xref linkend="stmtsetdroptable"/>
+impliquant <function>droptable_int()</function> est prÃ©sent.
+Vous pouvez feuilleter cela Ã  la main en trouvant l'identification de la table Ã  supprimer, et que vous pouvez trouver dedans<xref
+linkend="table.sl-table"/>, et aprÃ¨s lancer les trois requÃªtes suivantes sur chaque noeud :</emphasis>
 
 <programlisting>
   select _slonyschema.alterTableRestore(40);
@@ -1559,23 +1564,23 @@
   delete from _slonyschema.sl_table where tab_id = 40;
 </programlisting></para>
 
-<para>Le schéma dépendra évidemment de la façon dont vous avez défini le cluster &slony1;. L'identifiant de la table, dans cet exemple, 40, sera à vous de remplacer par celui que vous voulez vous en débarrasser.</para>
+<para>Le schÃ©ma dÃ©pendra Ã©videmment de la faÃ§on dont vous avez dÃ©fini le cluster &slony1;. L'identifiant de la table, dans cet exemple, 40, sera Ã  vous de remplacer par celui que vous voulez vous en dÃ©barrasser.</para>
 
-<para> Vous devrez lancer ces trois interrogations sur tous les noeuds, de préférence premièrement sur le noeud d'origine, de sorte que la réplique de ses propagations soit correcte.
-Implémenter ceci à travers un ordre de <xref linkend="slonik"/>
-avec un nouveau &slony1; pourra se faire. La soumission des trois requêtes utilisant <xref linkend="stmtddlscript"/> peut le faire aussi.
-Également il sera possible de se connecter à chaque base de données et de lancer les requêtes à la main.</para></listitem> </itemizedlist></para>
+<para> Vous devrez lancer ces trois interrogations sur tous les noeuds, de prÃ©fÃ©rence premiÃ¨rement sur le noeud d'origine, de sorte que la rÃ©plique de ses propagations soit correcte.
+ImplÃ©menter ceci Ã  travers un ordre de <xref linkend="slonik"/>
+avec un nouveau &slony1; pourra se faire. La soumission des trois requÃªtes utilisant <xref linkend="stmtddlscript"/> peut le faire aussi.
+Ã‰galement il sera possible de se connecter Ã  chaque base de donnÃ©es et de lancer les requÃªtes Ã  la main.</para></listitem> </itemizedlist></para>
 </answer>
 </qandaentry>
 
 <qandaentry>
-<question><para>Je dois supprimer un ordre dans une séquence pour un ensemble de réplication</para></question>
+<question><para>Je dois supprimer un ordre dans une sÃ©quence pour un ensemble de rÃ©plication</para></question>
 
-<answer><para></para><para>Si vous êtes en version 1.0.5 ou supérieur, il y a une commande <xref linkend="stmtsetdropsequence"/> dans Slonik vous permettant de le faire en paralelle <xref linkend="stmtsetdroptable"/>.</para>
+<answer><para></para><para>Si vous Ãªtes en version 1.0.5 ou supÃ©rieur, il y a une commande <xref linkend="stmtsetdropsequence"/> dans Slonik vous permettant de le faire en paralelle <xref linkend="stmtsetdroptable"/>.</para>
 
-<para>Si vous êtes en version 1.0.2 ou antérieur, l'opération sera un peu plus manuel.</para>
+<para>Si vous Ãªtes en version 1.0.2 ou antÃ©rieur, l'opÃ©ration sera un peu plus manuel.</para>
 
-<para>À supposer que je veux me débarrasser des deux ordres énumérés ci-dessous,<envar>whois_cachemgmt_seq</envar> and
+<para>Ã€ supposer que je veux me dÃ©barrasser des deux ordres Ã©numÃ©rÃ©s ci-dessous,<envar>whois_cachemgmt_seq</envar> and
 <envar>epp_whoi_cach_seq_</envar>, we start by needing the
 <envar>seq_id</envar> values.
 
@@ -1588,16 +1593,16 @@
 (2 rows)
 </screen></para>
 
-<para>Les données à supprimer, afin d'éviter que soit propager, nécessite l'arrêt de Slony :
+<para>Les donnÃ©es Ã  supprimer, afin d'Ã©viter que soit propager, nÃ©cessite l'arrÃªt de Slony :
 
 <programlisting>
 delete from _oxrsorg.sl_seqlog where seql_seqid in (93, 59);
 delete from _oxrsorg.sl_sequence where seq_id in (93,59);
 </programlisting></para>
 
-<para>Ces deux interrogations peuvent être soumises à l'ensemble des noeud via la fonction &funddlscript; / <xref
-linkend="stmtddlscript"/>, éliminant l'ordre partout en 
-<quote>même temps.</quote> Ou bien appliquer à la main à chacun des noeuds.</para>
+<para>Ces deux interrogations peuvent Ãªtre soumises Ã  l'ensemble des noeud via la fonction &funddlscript; / <xref
+linkend="stmtddlscript"/>, Ã©liminant l'ordre partout en 
+<quote>mÃªme temps.</quote> Ou bien appliquer Ã  la main Ã  chacun des noeuds.</para>
 
 <para>Similarly to <xref linkend="stmtsetdroptable"/>, this is
 implemented &slony1; version 1.0.5 as <xref
@@ -1608,25 +1613,25 @@
 <qandadiv id="faqobsolete"> <title> &slony1; FAQ: Hopefully Obsolete Issues </title>
 
 <qandaentry>
-<question><para> &lslon; ne se remet pas en marche après un incident</para>
+<question><para> &lslon; ne se remet pas en marche aprÃ¨s un incident</para>
 
-<para> Après un après brutal de &postgres; (en simulant une panne système)
+<para> AprÃ¨s un aprÃ¨s brutal de &postgres; (en simulant une panne systÃ¨me)
 dans &pglistener; un tuplets existe avec  <command>
-relname='_${cluster_name}_Restart'</command>. slon ne démarre pas car 
-il considère qu’une autre processe sert le  cluster sur ce noeud. Que puis-je faire? 
-Le tuplet ne peut pas être supprimé dans la relation.</para>
+relname='_${cluster_name}_Restart'</command>. slon ne dÃ©marre pas car 
+il considÃ¨re quÂ’une autre processe sert le  cluster sur ce noeud. Que puis-je faire? 
+Le tuplet ne peut pas Ãªtre supprimÃ© dans la relation.</para>
 
-<para> Le journal prétend que  <blockquote><para>un autre slon en tâche de fond
-sert ce noeud déjà</para></blockquote></para></question>
+<para> Le journal prÃ©tend que  <blockquote><para>un autre slon en tÃ¢che de fond
+sert ce noeud dÃ©jÃ </para></blockquote></para></question>
 
-<answer><para> Le problème est que la table système  &pglistener;, utilisée par
-&postgres; à gérer l'évènement de notification, contiens quelques entrées pointant vers le central,
+<answer><para> Le problÃ¨me est que la table systÃ¨me  &pglistener;, utilisÃ©e par
+&postgres; Ã  gÃ©rer l'Ã©vÃ¨nement de notification, contiens quelques entrÃ©es pointant vers le central,
 n'existent plus. La nouvelle instance de <xref
-linkend="slon"/> se  connecte à la base, et elle est convaincue, par la
-présence de ces entrées qu'un ancien
-<application>slon</application> est toujours en activité pour s'occuper de ce noeud de &slony1;.</para>
+linkend="slon"/> se  connecte Ã  la base, et elle est convaincue, par la
+prÃ©sence de ces entrÃ©es qu'un ancien
+<application>slon</application> est toujours en activitÃ© pour s'occuper de ce noeud de &slony1;.</para>
 
-<para> Le <quote>détritus</quote> dans cette table doit être nettoyer.</para>
+<para> Le <quote>dÃ©tritus</quote> dans cette table doit Ãªtre nettoyer.</para>
 
 <para>Il sera utile de maintenir un script manuel pour ce genre de situation:
 
@@ -1644,20 +1649,20 @@
 </programlisting></para>
 
 <para> <xref linkend="stmtrestartnode"/> nettoie les notifications mortes
-pour en suite redémarrer le noeud.</para>
+pour en suite redÃ©marrer le noeud.</para>
 
-<para>Comme en version 1.0.5, au démarrage de slon, les processes cherche ce genre de données obsolètes et les nettoient
-le cas échéant.</para>
+<para>Comme en version 1.0.5, au dÃ©marrage de slon, les processes cherche ce genre de donnÃ©es obsolÃ¨tes et les nettoient
+le cas Ã©chÃ©ant.</para>
 
 <para> Comme en version 8.1 de &postgres;, la  fonction manipulant
-&pglistener; ne supporte pas cet usage, alors pour la version de &slony1; après 
+&pglistener; ne supporte pas cet usage, alors pour la version de &slony1; aprÃ¨s 
 1.1.2 (<emphasis>e.g. - </emphasis> 1.1.5), ce 
-<quote>couplage</quote> est manipulé par l'intermédiaire d'une autre table, et l'issu de la situation est
+<quote>couplage</quote> est manipulÃ© par l'intermÃ©diaire d'une autre table, et l'issu de la situation est
 rendu un peu plus transparent. <quote>.</quote> </para>
 
 </answer></qandaentry>
 
-<qandaentry><question><para> J'ai essayé la requête suivante qui ne marche pas:</para> 
+<qandaentry><question><para> J'ai essayÃ© la requÃªte suivante qui ne marche pas:</para> 
 
 <programlisting>
 sdb=# explain select query_start, current_query from pg_locks join
@@ -1667,39 +1672,39 @@
 ERROR: could not find hash function for hash operator 716373
 </programlisting>
 
-<para> Il semble que &slony1; <function>xxid</function> les fonctions vont être 
-dôtées de brouillage(hashing), qu'elles n'ont pas actuellement.</para>
+<para> Il semble que &slony1; <function>xxid</function> les fonctions vont Ãªtre 
+dÃ´tÃ©es de brouillage(hashing), qu'elles n'ont pas actuellement.</para>
 
 
 <para> Que se passe-t-il ? </para>
 
 </question>
 
-<answer><para> &slony1; a défini un nouveau type de données et d'opérateurs XXID
-ce type afin de permettre la manipulation des IDs de transaction qui sont employés
-pour grouper ensemble, les mises à jour qui sont associées à la même transaction.
+<answer><para> &slony1; a dÃ©fini un nouveau type de donnÃ©es et d'opÃ©rateurs XXID
+ce type afin de permettre la manipulation des IDs de transaction qui sont employÃ©s
+pour grouper ensemble, les mises Ã  jour qui sont associÃ©es Ã  la mÃªme transaction.
 </para>
 
-<para> Opérateurs qui n'étaient pas disponible pour &postgres; version 
-7.3 et inférieur; afin de le rendre opérationnelle en 7.3, les fonctions spécifiques
-doivent être ajoutées. L'opérateur <function>=</function>  
-a été marqué comme soutenant
-le hachage, mais pour que celui-ci travaille correctement, l'opérateur de jointure doit 
-apparaître dans une classe d'opérateur d'index haché. Cela n'a pas été défini, 
-et en conséquence, les requêtes (comme celle ci-dessus) qui décident d'employer 
-le hash-joins échoueront. </para> </answer>
+<para> OpÃ©rateurs qui n'Ã©taient pas disponible pour &postgres; version 
+7.3 et infÃ©rieur; afin de le rendre opÃ©rationnelle en 7.3, les fonctions spÃ©cifiques
+doivent Ãªtre ajoutÃ©es. L'opÃ©rateur <function>=</function>  
+a Ã©tÃ© marquÃ© comme soutenant
+le hachage, mais pour que celui-ci travaille correctement, l'opÃ©rateur de jointure doit 
+apparaÃ®tre dans une classe d'opÃ©rateur d'index hachÃ©. Cela n'a pas Ã©tÃ© dÃ©fini, 
+et en consÃ©quence, les requÃªtes (comme celle ci-dessus) qui dÃ©cident d'employer 
+le hash-joins Ã©choueront. </para> </answer>
 
 <answer> <para> Ceci  <emphasis> n'a pas </emphasis> 
-été considéré comme bug <quote>release-critical</quote>, comme &slony1 ; 
-ne produit probablement pas des intérrogations intérnes employant des hash-join. Ce problème ne devrait 
-pas entacher &slony1 ; devant la capacité qu'il a de gérer la  réplication. </para> </answer>
+Ã©tÃ© considÃ©rÃ© comme bug <quote>release-critical</quote>, comme &slony1; 
+ne produit probablement pas des intÃ©rrogations intÃ©rnes employant des hash-join. Ce problÃ¨me ne devrait 
+pas entacher &slony1; devant la capacitÃ© qu'il a de gÃ©rer la  rÃ©plication. </para> </answer>
 
 <answer> <para> La nouvelle version de &slony1; (<emphasis>e.g.</emphasis>
 1.0.6, 1.1) omettra l'indicateur <command>HASHES</command>, donc ceci
 </para> </answer>
 
-<answer> <para> Supposons que vous souhaitez réparer une instance existante, et vous constatez 
-que vos propres scripts ne fonctionneront pas bien, vous pouvez suivre la démarche suivante : </para>
+<answer> <para> Supposons que vous souhaitez rÃ©parer une instance existante, et vous constatez 
+que vos propres scripts ne fonctionneront pas bien, vous pouvez suivre la dÃ©marche suivante : </para>
 
 <programlisting>
 /* cbbrowne@[local]/dba2 slony_test1=*/ \x     
@@ -1733,25 +1738,25 @@
 
 </qandaentry>
 <qandaentry> <question><para> Je peux faire un <command>pg_dump</command>
-et chargez les données en les sauvegardant, beaucoup plus rapidement que si <command>SUBSCRIBE
-SET</command> les exécutait lui-même. Pourquoi c'est ainsi?  </para></question>
+et chargez les donnÃ©es en les sauvegardant, beaucoup plus rapidement que si <command>SUBSCRIBE
+SET</command> les exÃ©cutait lui-mÃªme. Pourquoi c'est ainsi?  </para></question>
 
-<answer><para> &slony1; dépend des index, supposons qu'il soit sur un  clef primaire, dont les feuilles se trouvant isolées (sans branches), en utilisant la commande
- &postgres; <command>COPY</command> les données sont lues rapidement.
-Alors que il peut y avoir une dégradation de performance, provoquée par l'évènement <command>COPY SET</command> (un 
-évènement généré par le souscripteur) dans la mesure où l'opération dans ce cas démarre par d'abord une suppression des contenus des tables, et rien que cela laisse des tuplets morts.</para>
+<answer><para> &slony1; dÃ©pend des index, supposons qu'il soit sur un  clef primaire, dont les feuilles se trouvant isolÃ©es (sans branches), en utilisant la commande
+ &postgres; <command>COPY</command> les donnÃ©es sont lues rapidement.
+Alors que il peut y avoir une dÃ©gradation de performance, provoquÃ©e par l'Ã©vÃ¨nement <command>COPY SET</command> (un 
+Ã©vÃ¨nement gÃ©nÃ©rÃ© par le souscripteur) dans la mesure oÃ¹ l'opÃ©ration dans ce cas dÃ©marre par d'abord une suppression des contenus des tables, et rien que cela laisse des tuplets morts.</para>
 
-<para> Lorsque vous utilisez <command>pg_dump</command> pour exporter le contenus de la base, et que vous les re-importez après, les indexes ne sont crées qu'à la fin. Ceci est <emphasis>beaucoup</emphasis> plus performant des reconstruire les indexes sur une table entièrement re-importée, plutôt que de refaire les indexes à la volet lorsque les enregistrement sont rajoutés un à un à la table.</para></answer>
+<para> Lorsque vous utilisez <command>pg_dump</command> pour exporter le contenus de la base, et que vous les re-importez aprÃ¨s, les indexes ne sont crÃ©es qu'Ã  la fin. Ceci est <emphasis>beaucoup</emphasis> plus performant des reconstruire les indexes sur une table entiÃ¨rement re-importÃ©e, plutÃ´t que de refaire les indexes Ã  la volet lorsque les enregistrement sont rajoutÃ©s un Ã  un Ã  la table.</para></answer>
 
-<answer><para> Si d'emblée, vous pouvez supprimer des indexes inutiles, lorsque <command>COPY</command> se met en marche, les performances sont sensiblement améliorée. Encore mieux, si vous pouvez<command>TRUNCATER</command> les tables dont le contenu devra disparaître, les performance vont augmenter d'<emphasis>avantage.</emphasis> </para></answer>
+<answer><para> Si d'emblÃ©e, vous pouvez supprimer des indexes inutiles, lorsque <command>COPY</command> se met en marche, les performances sont sensiblement amÃ©liorÃ©e. Encore mieux, si vous pouvez<command>TRUNCATER</command> les tables dont le contenu devra disparaÃ®tre, les performance vont augmenter d'<emphasis>avantage.</emphasis> </para></answer>
 
-<answer><para> &slony1; en version 1.1.5 et supérieur, fait cela automatiquement; il <quote>cogne</quote> sur les indexes dans le catalogue de &postgres; afin de les inhiber, de plus, de la même façon il désactive les déclencheurs, tout en les <quote>réactivant</quote> à la fin sans oublier de reconstruire les indexes des tables en question. </para> </answer>
+<answer><para> &slony1; en version 1.1.5 et supÃ©rieur, fait cela automatiquement; il <quote>cogne</quote> sur les indexes dans le catalogue de &postgres; afin de les inhiber, de plus, de la mÃªme faÃ§on il dÃ©sactive les dÃ©clencheurs, tout en les <quote>rÃ©activant</quote> Ã  la fin sans oublier de reconstruire les indexes des tables en question. </para> </answer>
 </qandaentry>
 
 <qandaentry id="dupkey">
-<question><para>La réplication échoue - Violation des Constraintes unique</para>
+<question><para>La rÃ©plication Ã©choue - Violation des Constraintes unique</para>
 
-<para>Alors que la Réplication se déroule correctement, depuis un bout de temps, lorsque le noeud rencontre <quote>intempestivement,</quote> des erreurs suivant envoyées dans le journal:
+<para>Alors que la RÃ©plication se dÃ©roule correctement, depuis un bout de temps, lorsque le noeud rencontre <quote>intempestivement,</quote> des erreurs suivant envoyÃ©es dans le journal:
 
 <screen>
 DEBUG2 remoteWorkerThread_1: syncing set 2 with 5 table(s) from provider 1
@@ -1775,53 +1780,53 @@
 ERROR  remoteWorkerThread_1: SYNC aborted
 </screen></para>
 
-<para>La transaction s'annule, et &slony1; essaie à nouveau sans cesse.
-Le problème est dû à une des <emphasis>dernière</emphasis> requête SQL
-précisant  <command>log_cmdtype = 'I'</command>. Ce n'est pat tout à fait évident; ce qui se passe est que &slony1; regroupe 10 opérations de mise à jour, ensemble, afin de diminuer les aller-retour réseau.</para></question>
+<para>La transaction s'annule, et &slony1; essaie Ã  nouveau sans cesse.
+Le problÃ¨me est dÃ» Ã  une des <emphasis>derniÃ¨re</emphasis> requÃªte SQL
+prÃ©cisant  <command>log_cmdtype = 'I'</command>. Ce n'est pat tout Ã  fait Ã©vident; ce qui se passe est que &slony1; regroupe 10 opÃ©rations de mise Ã  jour, ensemble, afin de diminuer les aller-retour rÃ©seau.</para></question>
 
-<answer><para> Une origine <emphasis>certaine</emphasis>  pour ceci est difficile à déterminer.</para>
+<answer><para> Une origine <emphasis>certaine</emphasis>  pour ceci est difficile Ã  dÃ©terminer.</para>
 
-<para>En même temps, nous notons qu'il y a un problème de transactions manquées concernant les suppressions qui sont déjà nettoyées dans <xref
-linkend="table.sl-log-1"/>, et on constate qu'un recouvrement est impossible. A ce stade, ce qui semble nécessaire, est de supprimer le jeu de réplication (ou même carrément le noeud), est de redémarrer la réplication de début pour le noeud.</para>
+<para>En mÃªme temps, nous notons qu'il y a un problÃ¨me de transactions manquÃ©es concernant les suppressions qui sont dÃ©jÃ  nettoyÃ©es dans <xref
+linkend="table.sl-log-1"/>, et on constate qu'un recouvrement est impossible. A ce stade, ce qui semble nÃ©cessaire, est de supprimer le jeu de rÃ©plication (ou mÃªme carrÃ©ment le noeud), est de redÃ©marrer la rÃ©plication de dÃ©but pour le noeud.</para>
 
-<para>Dans &slony1; 1.0.5, l'opération de purge de <xref
+<para>Dans &slony1; 1.0.5, l'opÃ©ration de purge de <xref
 linkend="table.sl-log-1"/> devient plus prudente, en refusant 
-de purger des entrées qui n'ont pas encore été synchronisées. pour au moins 10 minutes sur l'ensemble des noeuds. Il n'est pas certain que ceci empêche que
-<quote>le problème</quote> ait lieu, mais il paraît plausible que  cela laisse assez de volume dans <xref linkend="table.sl-log-1"/> permettant un recouvrement ou bien de permettre d'au moins de diagnostiquer plus exactement la situation. Et peut-être que le problème venait du fait que <xref linkend="table.sl-log-1"/> a été brutalement purgée, donc cette solution permet de résoudre complètement ce genre d'incident.</para>
+de purger des entrÃ©es qui n'ont pas encore Ã©tÃ© synchronisÃ©es. pour au moins 10 minutes sur l'ensemble des noeuds. Il n'est pas certain que ceci empÃªche que
+<quote>le problÃ¨me</quote> ait lieu, mais il paraÃ®t plausible que  cela laisse assez de volume dans <xref linkend="table.sl-log-1"/> permettant un recouvrement ou bien de permettre d'au moins de diagnostiquer plus exactement la situation. Et peut-Ãªtre que le problÃ¨me venait du fait que <xref linkend="table.sl-log-1"/> a Ã©tÃ© brutalement purgÃ©e, donc cette solution permet de rÃ©soudre complÃ¨tement ce genre d'incident.</para>
 
-<para> C'est une honte de reconstruire un réplication volumineuse sur un noeud,
-si vous découvrez que le problème pérciste. La bonne idée serai de diviser la réplication
+<para> C'est une honte de reconstruire un rÃ©plication volumineuse sur un noeud,
+si vous dÃ©couvrez que le problÃ¨me pÃ©rciste. La bonne idÃ©e serai de diviser la rÃ©plication
 en plusieurs morceaux afin de dimin<envar>tgrelid</envar> en les pointant sur l'identifiant OID of the <quote>primary
 key</quote> index on the table rather than to the table
-uer la charge de travail lors de redémarrage de réplication.
-Si un seul jeu est cassé, vous n'auriez qu'à désabonner et supprimer celui-ci.
+uer la charge de travail lors de redÃ©marrage de rÃ©plication.
+Si un seul jeu est cassÃ©, vous n'auriez qu'Ã  dÃ©sabonner et supprimer celui-ci.
 </para>
 
-<para> Dans un cas, nous avons trouvé deux lignes dans le journal d'erreur des requêtes sql
+<para> Dans un cas, nous avons trouvÃ© deux lignes dans le journal d'erreur des requÃªtes sql
 qui sont  <emphasis> identique </emphasis> concernant l'insertion dans
  <xref linkend="table.sl-log-1"/>. Ceci <emphasis> doit
-</emphasis> être impossible d'autant plus qu'il s'agit d'une clef primaire sur <xref
-linkend="table.sl-log-1"/>.  La dernière théorie, moins forte, laisserait à penser que cette situation
-viendrait que <emphasis>cette</emphasis> clé serait peut-être corrompue (présence d'un bug de &postgres;), et afin de soulever ce doute, 
-on peut exécuter l'ordre suivant:</para>
+</emphasis> Ãªtre impossible d'autant plus qu'il s'agit d'une clef primaire sur <xref
+linkend="table.sl-log-1"/>.  La derniÃ¨re thÃ©orie, moins forte, laisserait Ã  penser que cette situation
+viendrait que <emphasis>cette</emphasis> clÃ© serait peut-Ãªtre corrompue (prÃ©sence d'un bug de &postgres;), et afin de soulever ce doute, 
+on peut exÃ©cuter l'ordre suivant:</para>
 
 <programlisting>
 # reindex table _slonyschema.sl_log_1;
 </programlisting>
 
-<para> Au moins dans une occasion cette solution s'est révélée efficace, alors cela sera dommage de ne pas suivre l'exemple.</para>
+<para> Au moins dans une occasion cette solution s'est rÃ©vÃ©lÃ©e efficace, alors cela sera dommage de ne pas suivre l'exemple.</para>
 </answer>
 
-<answer> <para> Ce problème s'est avéré comme un bug dans &postgres; par opposition à un autre dans &slony1;. La version 7.4.8 avait intégré deux solutions qui permettent de résoudre ce cas. Or si vous avez un noyau de &postgres; antérieur à 7.4.8,
-vous devriez migrer d'abord pour éviter l'erreur.
+<answer> <para> Ce problÃ¨me s'est avÃ©rÃ© comme un bug dans &postgres; par opposition Ã  un autre dans &slony1;. La version 7.4.8 avait intÃ©grÃ© deux solutions qui permettent de rÃ©soudre ce cas. Or si vous avez un noyau de &postgres; antÃ©rieur Ã  7.4.8,
+vous devriez migrer d'abord pour Ã©viter l'erreur.
 </para>
 </answer>
 </qandaentry>
-<qandaentry> <question><para>J'ai commencé à faire une sauvegarde via
+<qandaentry> <question><para>J'ai commencÃ© Ã  faire une sauvegarde via
 <application>pg_dump</application>, et Slony
-s'arrête soudainement</para></question>
+s'arrÃªte soudainement</para></question>
 
-<answer><para>Ouf. Ce qui se passe dans ce cas est à cause d'un conflit entre:
+<answer><para>Ouf. Ce qui se passe dans ce cas est Ã  cause d'un conflit entre:
 <itemizedlist>
 
 <listitem><para> <application>pg_dump</application>, qui sort un <command>AccessShareLock</command> pour toutes les tables de la base, y compris celle de &slony1; et</para></listitem>
@@ -1830,17 +1835,17 @@
 <command>AccessExclusiveLock</command> sur la table <xref
 linkend="table.sl-event"/>.</para></listitem> </itemizedlist></para>
 
-<para>La requête initiale qui est bloquée est :
+<para>La requÃªte initiale qui est bloquÃ©e est :
 
 <screen>
 select "_slonyschema".createEvent('_slonyschema, 'SYNC', NULL);	  
 </screen></para>
 
-<para>(vous pouvez voir ceci dans<envar>pg_stat_activity</envar>, si votre paramètre d'affichage des requête est positionné à vrai dans
+<para>(vous pouvez voir ceci dans<envar>pg_stat_activity</envar>, si votre paramÃ¨tre d'affichage des requÃªte est positionnÃ© Ã  vrai dans
 <filename>postgresql.conf</filename>)</para>
 
 <para>L'interrogation encours qui cause ce verrous vient de la fonction  <function>Slony_I_ClusterStatus()</function>, que vous trouverez dans 
-<filename>slony1_funcs.c</filename>, localisé dans un bloc de code qui est :
+<filename>slony1_funcs.c</filename>, localisÃ© dans un bloc de code qui est :
 
 <programlisting>
   LOCK TABLE %s.sl_event;
@@ -1848,69 +1853,69 @@
   SELECT currval('%s.sl_event_seq');
 </programlisting></para>
 
-<para>Le <command>VERROUS</command> se poste à ce moment et dure jusqu'à ce que 
-<command>pg_dump</command> (ou le temps que les verrous bloquent les accès à <xref linkend="table.sl-event"/>)
-se términe.</para>
+<para>Le <command>VERROUS</command> se poste Ã  ce moment et dure jusqu'Ã  ce que 
+<command>pg_dump</command> (ou le temps que les verrous bloquent les accÃ¨s Ã  <xref linkend="table.sl-event"/>)
+se tÃ©rmine.</para>
 
 <para>Chaque lecture touchant 
-<xref linkend="table.sl-event"/> sera bloqué derrière les appels à 
+<xref linkend="table.sl-event"/> sera bloquÃ© derriÃ¨re les appels Ã  
 <function>createEvent</function>.</para>
 
-<para>Les réponses à cette question sont multiples:
+<para>Les rÃ©ponses Ã  cette question sont multiples:
 <itemizedlist>
 
-<listitem><para> Faire spécifier à <application>pg_dump</application> d'exporter le schéma en utilisant l'option <option>--schema=whatever</option>, et ne pas essayer d'exporter le schéma du cluster entièrement.</para></listitem>
+<listitem><para> Faire spÃ©cifier Ã  <application>pg_dump</application> d'exporter le schÃ©ma en utilisant l'option <option>--schema=whatever</option>, et ne pas essayer d'exporter le schÃ©ma du cluster entiÃ¨rement.</para></listitem>
 
 <listitem><para> Il sera utile aussi d'ajouter une option 
-<option>--exclude-schema</option> à 
-<application>pg_dump</application> afin d'exclure le schéma du cluster de &slony1;. A rêver que dans 8.2...</para></listitem>
+<option>--exclude-schema</option> Ã  
+<application>pg_dump</application> afin d'exclure le schÃ©ma du cluster de &slony1;. A rÃªver que dans 8.2...</para></listitem>
 
-<listitem><para>Notez que 1.0.5 utilise des verrous plus précis et moins exclusifs qui soulage ce problème.</para></listitem>
+<listitem><para>Notez que 1.0.5 utilise des verrous plus prÃ©cis et moins exclusifs qui soulage ce problÃ¨me.</para></listitem>
 </itemizedlist></para>
 </answer></qandaentry>
 
 </qandadiv>
 
-<qandadiv id="faqoddities"> <title> &slony1; FAQ: Singularité des vulnérabilité dans Slony-I </title>
-<qandaentry><question><para> Que se produit à propos des règles et des déclencheurs pour des tables répliquées  par 
+<qandadiv id="faqoddities"> <title> &slony1; FAQ: SingularitÃ© des vulnÃ©rabilitÃ© dans Slony-I </title>
+<qandaentry><question><para> Que se produit Ã  propos des rÃ¨gles et des dÃ©clencheurs pour des tables rÃ©pliquÃ©es  par 
 &slony1;?</para>
 </question>
 
-<answer><para> Premièrement regardons comment elle  est gérée
-<emphasis>l'absence</emphasis> de gestion spécifique de  la commande Slonik<xref
+<answer><para> PremiÃ¨rement regardons comment elle  est gÃ©rÃ©e
+<emphasis>l'absence</emphasis> de gestion spÃ©cifique de  la commande Slonik<xref
 linkend="stmtstoretrigger"/>.  </para>
 
 <para> La fonction <xref
-linkend="function.altertableforreplication-integer"/> prépare chacune des tables
-pour la réplication.</para>
+linkend="function.altertableforreplication-integer"/> prÃ©pare chacune des tables
+pour la rÃ©plication.</para>
 
 <itemizedlist>
 
-<listitem><para> Sur le noeud maître, ceci implique l'ajout d'un déclencheur
-qui utilise la fonction <xref linkend="function.logtrigger"/> à la table.</para>
+<listitem><para> Sur le noeud maÃ®tre, ceci implique l'ajout d'un dÃ©clencheur
+qui utilise la fonction <xref linkend="function.logtrigger"/> Ã  la table.</para>
 
-<para> Le déclencheur a pour action d'enregistrer, toutes les mises à jours dans 
+<para> Le dÃ©clencheur a pour action d'enregistrer, toutes les mises Ã  jours dans 
 la table <xref linkend="table.sl-log-1"/> de &slony1;.
 </para></listitem>
 
-<listitem><para> Sur un noeud d'abonné, répliquer une table, revient à désactiver les déclencheurs,
-puis, via un déclencheur, de restreindre le droit d'accès en écriture sur celle-ci en
+<listitem><para> Sur un noeud d'abonnÃ©, rÃ©pliquer une table, revient Ã  dÃ©sactiver les dÃ©clencheurs,
+puis, via un dÃ©clencheur, de restreindre le droit d'accÃ¨s en Ã©criture sur celle-ci en
 utilisant la fonction <function>denyAccess()</function>.</para>
 
-<para> Jusqu'à la version 1.1 (et peut-être avant), le
-<quote>désactivation</quote> est faite en modifiant
+<para> Jusqu'Ã  la version 1.1 (et peut-Ãªtre avant), le
+<quote>dÃ©sactivation</quote> est faite en modifiant
 <envar>pg_trigger</envar> ou <envar>pg_rewrite</envar>
 <envar>tgrelid</envar> en pointant l'identifiant OID sur 
-la  <quote>clé primaire</quote> de l'index du catalogue, plutôt qu'une action directe sur la table
-elle-même.</para></listitem>
+la  <quote>clÃ© primaire</quote> de l'index du catalogue, plutÃ´t qu'une action directe sur la table
+elle-mÃªme.</para></listitem>
 
 </itemizedlist>
 
-<para> Un effet secondaire quelque part malheureu de ces actions sur les règles et les déclencheurs
-donne un effet de les <quote>piétiner</quote>. Dans la mesure où les règles et les déclencheurs sont toujours là, 
-mais ne plus correctement attachés à leurs tables. Si vous faite un <command>pg_dump</command> sur 
-<quote>le noeud d'abonné</quote>, il ne trouvera pas les contraintes  ni les déclencheur, et surtout il ne s'attend pas
-à les voir associés à un indexe.</para>
+<para> Un effet secondaire quelque part malheureu de ces actions sur les rÃ¨gles et les dÃ©clencheurs
+donne un effet de les <quote>piÃ©tiner</quote>. Dans la mesure oÃ¹ les rÃ¨gles et les dÃ©clencheurs sont toujours lÃ , 
+mais ne plus correctement attachÃ©s Ã  leurs tables. Si vous faite un <command>pg_dump</command> sur 
+<quote>le noeud d'abonnÃ©</quote>, il ne trouvera pas les contraintes  ni les dÃ©clencheur, et surtout il ne s'attend pas
+Ã  les voir associÃ©s Ã  un indexe.</para>
 
 </answer>
 
@@ -1918,13 +1923,13 @@
 entre en jeu.</para>
 
 <para> Mettez simplement cette commande  pour que 
-&slony1; restore les déclencheurs :
+&slony1; restore les dÃ©clencheurs :
 <function>alterTableRestore(table id)</function>, qui restaure l'identifiant OID 
 de la table dans <envar>pg_trigger</envar> ou 
-<envar>pg_rewrite</envar> <envar>tgrelid</envar> sur le noeud affecté.</para></answer> 
+<envar>pg_rewrite</envar> <envar>tgrelid</envar> sur le noeud affectÃ©.</para></answer> 
 
-<answer><para> Ceci implique que le jour où vous souhaitez lancer une sauvegarde directement
-sur un abonné, vous devrez reprendre le schéma depuis un noeud d'origine. Clairement il faudra faire : </para>
+<answer><para> Ceci implique que le jour oÃ¹ vous souhaitez lancer une sauvegarde directement
+sur un abonnÃ©, vous devrez reprendre le schÃ©ma depuis un noeud d'origine. Clairement il faudra faire : </para>
 
 <screen>
 % pg_dump -h originnode.example.info -p 5432 --schema-only --schema=public ourdb > schema_backup.sql
@@ -1936,7 +1941,7 @@
 
 <qandaentry> <question> <para> J'essaie de demander  <xref
 linkend="stmtddlscript"/> ou <xref linkend="stmtmoveset"/>, et trouves
-les messages suivants sur l'un des abonnés :</para>
+les messages suivants sur l'un des abonnÃ©s :</para>
 
 <screen>
 NOTICE: Slony-I: multiple instances of trigger defrazzle on table frobozz
@@ -1945,46 +1950,46 @@
 </screen>
 </question>
 
-<answer> <para> La  difficulté semble venir du fait que 
-vous ajouter un déclencheur à une table dont le nom rentre en conflit,
-avec le déclencheur que &slony1; cache. </para>
+<answer> <para> La  difficultÃ© semble venir du fait que 
+vous ajouter un dÃ©clencheur Ã  une table dont le nom rentre en conflit,
+avec le dÃ©clencheur que &slony1; cache. </para>
 
-<para> &slony1; cache des déclencheurs (sauf ceux marqués comme <quote>unhidden</quote>
-via <xref linkend="stmtstoretrigger"/>) en les attachant à la clé primaire de leur table.
-Dans le cas d'une clef étrangère, d'autre déclencheurs sont rajoutés afin de garantir la cohérence des données.
-Il est complètement inutile des les lancer depuis un abonné, ainsi ces déclencheurs doivent être provoquer 
-depuis le noeud d'origine. En revanche, les déclencheurs de type
-<quote>cache invalidation</quote> sont ceux que vous devrez lancer depuis l'abonné.</para>
+<para> &slony1; cache des dÃ©clencheurs (sauf ceux marquÃ©s comme <quote>unhidden</quote>
+via <xref linkend="stmtstoretrigger"/>) en les attachant Ã  la clÃ© primaire de leur table.
+Dans le cas d'une clef Ã©trangÃ¨re, d'autre dÃ©clencheurs sont rajoutÃ©s afin de garantir la cohÃ©rence des donnÃ©es.
+Il est complÃ¨tement inutile des les lancer depuis un abonnÃ©, ainsi ces dÃ©clencheurs doivent Ãªtre provoquer 
+depuis le noeud d'origine. En revanche, les dÃ©clencheurs de type
+<quote>cache invalidation</quote> sont ceux que vous devrez lancer depuis l'abonnÃ©.</para>
 
-<para> La <emphasis>bonne manière</emphasis> de manipuler ce genre de déclencheurs est d'utiliser
- <xref linkend="stmtstoretrigger"/>, qui indique à 
-&slony1; de ne pas désactiver des déclencheurs. </para> </answer>
+<para> La <emphasis>bonne maniÃ¨re</emphasis> de manipuler ce genre de dÃ©clencheurs est d'utiliser
+ <xref linkend="stmtstoretrigger"/>, qui indique Ã  
+&slony1; de ne pas dÃ©sactiver des dÃ©clencheurs. </para> </answer>
 
-<answer> <para> Mais il peut y avoir quelques DBA intrépides, qui vont assumer individuellement ce travail on
-installant les déclencheur à la main sur l'abonné, et donc capable de  créer ce genre de situation. Que faire?
+<answer> <para> Mais il peut y avoir quelques DBA intrÃ©pides, qui vont assumer individuellement ce travail on
+installant les dÃ©clencheur Ã  la main sur l'abonnÃ©, et donc capable de  crÃ©er ce genre de situation. Que faire?
 </para>
 
-<para> La réponse est assez simple : Retirez le déclencheur
-<quote>spécifique</quote> sur l'abonné avant de dérouler la restauration.
-Dans le meilleur des cas, si le DBA est intrépide et réactif, il aurait fait cela 
+<para> La rÃ©ponse est assez simple : Retirez le dÃ©clencheur
+<quote>spÃ©cifique</quote> sur l'abonnÃ© avant de dÃ©rouler la restauration.
+Dans le meilleur des cas, si le DBA est intrÃ©pide et rÃ©actif, il aurait fait cela 
 <emphasis>avant</emphasis> que le message ait le temps d'arriver. </para>
 
-<para> Si le DBA n'est pas intrépide, la réponse serait de se connecter au noeud
-offensé, et de supprimer la version <quote>visible</quote> du déclencheur utilisant l'ordre 
+<para> Si le DBA n'est pas intrÃ©pide, la rÃ©ponse serait de se connecter au noeud
+offensÃ©, et de supprimer la version <quote>visible</quote> du dÃ©clencheur utilisant l'ordre 
  <acronym>SQL</acronym> <command>DROP
-TRIGGER</command>. Ceci permet à l'évènement de se dérouler.
-Si l'évènement était <xref linkend="stmtddlscript"/>, alors notre 
-<quote>pas-tellement-intrépide </quote> DBA devra ajouter le trigger à la main,
-ou, s'il y a plus de sagesse, de les réactiver avec 
+TRIGGER</command>. Ceci permet Ã  l'Ã©vÃ¨nement de se dÃ©rouler.
+Si l'Ã©vÃ¨nement Ã©tait <xref linkend="stmtddlscript"/>, alors notre 
+<quote>pas-tellement-intrÃ©pide </quote> DBA devra ajouter le trigger Ã  la main,
+ou, s'il y a plus de sagesse, de les rÃ©activer avec 
 <xref linkend="stmtstoretrigger"/>.</para>
 </answer>
 </qandaentry>
 
 <qandaentry id="neededexecddl">
 
-<question> <para> Comportement - tous les noeuds d'abonné, ainsi que le noeud maître,
-commence à se planter, crachant le message d'erreur suivant dans le journal,
-(lorsque j'ai rencontré ce problème, il y avait une longue requête SQL devant chaque message ):</para>
+<question> <para> Comportement - tous les noeuds d'abonnÃ©, ainsi que le noeud maÃ®tre,
+commence Ã  se planter, crachant le message d'erreur suivant dans le journal,
+(lorsque j'ai rencontrÃ© ce problÃ¨me, il y avait une longue requÃªte SQL devant chaque message ):</para>
 
 <screen>
 ERROR remoteWorkerThread_1: helper 1 finished with error
@@ -1996,16 +2001,16 @@
 table</command> statements directly on the databases instead of using
 the slonik <xref linkend="stmtddlscript"/> command.</para>
 
-<para>La solution consiste à  remettre le trigger sur la table affectée,
-et de corriger les données afférentes dans <xref linkend="table.sl-log-1"/> by hand.</para>
+<para>La solution consiste Ã   remettre le trigger sur la table affectÃ©e,
+et de corriger les donnÃ©es affÃ©rentes dans <xref linkend="table.sl-log-1"/> by hand.</para>
 
 <itemizedlist>
 
 <listitem><para> Vous avez besoin d'extraire du journal soit de slon, soit
-du &postgres; l'ordre sql exact qui a causé l'anomalie.</para></listitem>
+du &postgres; l'ordre sql exact qui a causÃ© l'anomalie.</para></listitem>
 
-<listitem><para> Vous avez besoin de corriger le déclencheur Slony-defined dans la table 
-en question. Ceci peut se faire à l'aide de la procédure suivante :</para>
+<listitem><para> Vous avez besoin de corriger le dÃ©clencheur Slony-defined dans la table 
+en question. Ceci peut se faire Ã  l'aide de la procÃ©dure suivante :</para>
 
 <screen>
 BEGIN;
@@ -2015,10 +2020,10 @@
 COMMIT;
 </screen>
 
-<para>Ensuite vous avez besoin de sélectionner les enregistrements dans  <xref
-linkend="table.sl-log-1"/> qui sont incohérent pour les corriger. Il faudra ensuite arrêter
-les processes de Slon pour l'ensemble des noeuds excepté celui du maître;
-de cette manière vous évitez que l'erreur se propage immédiatement à travers tous les noeuds.</para>
+<para>Ensuite vous avez besoin de sÃ©lectionner les enregistrements dans  <xref
+linkend="table.sl-log-1"/> qui sont incohÃ©rent pour les corriger. Il faudra ensuite arrÃªter
+les processes de Slon pour l'ensemble des noeuds exceptÃ© celui du maÃ®tre;
+de cette maniÃ¨re vous Ã©vitez que l'erreur se propage immÃ©diatement Ã  travers tous les noeuds.</para>
 
 <para> Voici un exemple:</para>
 
@@ -2063,7 +2068,7 @@
 
 <qandaentry> 
 
-<question><para> Le noeud numéro 1 a été supprimé via <xref
+<question><para> Le noeud numÃ©ro 1 a Ã©tÃ© supprimÃ© via <xref
 linkend="stmtdropnode"/>, et le &lslon; d'un des noeuds fait cracher le message 
 d'erreurs suivant:</para>
 
@@ -2083,27 +2088,27 @@
 </screen>
 
 <para> Evidemment une demande de  <xref linkend="stmtstorelisten"/> n'avait pas encore
-été propagé avant que le noeud 1 soit éliminé.</para></question>
+Ã©tÃ© propagÃ© avant que le noeud 1 soit Ã©liminÃ©.</para></question>
 
-<answer id="eventsurgery"><para> Ceci indique le cas où vous avez besoin de 
-<quote>opération chirurgicale</quote> sur l'un ou plusieurs noeuds.
-Un évènement<command>STORE_LISTEN</command> demeure sans réponse lorsqu'il veut 
-ajouter un port d'écoute qui <emphasis>ne peut pas</emphasis> être satisfait car 
-le noeud 1 ainsi que tous les éléments indiquant ce noeud sont disparus.</para>
+<answer id="eventsurgery"><para> Ceci indique le cas oÃ¹ vous avez besoin de 
+<quote>opÃ©ration chirurgicale</quote> sur l'un ou plusieurs noeuds.
+Un Ã©vÃ¨nement<command>STORE_LISTEN</command> demeure sans rÃ©ponse lorsqu'il veut 
+ajouter un port d'Ã©coute qui <emphasis>ne peut pas</emphasis> Ãªtre satisfait car 
+le noeud 1 ainsi que tous les Ã©lÃ©ments indiquant ce noeud sont disparus.</para>
 
-<para> Supposons que pour la démonstration, les noeuds encore en place
-soient le 2 et le 3, ainsi le rapport d'erreur est remonté au noeud 3.</para>
+<para> Supposons que pour la dÃ©monstration, les noeuds encore en place
+soient le 2 et le 3, ainsi le rapport d'erreur est remontÃ© au noeud 3.</para>
 
-<para> cela implique que l'évènement se généré sur le noeud 2, comme il ne peut être sur le 
-noeud 3, si il n'a pas été traité avec succès. La manière la plus facile à faire face à cette situation,
-est, de supprimer sur le noeud offensé, les données dans <xref linkend="table.sl-event"/> relatives au noeud 2.
-Vous vous connectez à la base du noeud 2, et à l'aide de Sql suivant, de chercher l'évènement
+<para> cela implique que l'Ã©vÃ¨nement se gÃ©nÃ©rÃ© sur le noeud 2, comme il ne peut Ãªtre sur le 
+noeud 3, si il n'a pas Ã©tÃ© traitÃ© avec succÃ¨s. La maniÃ¨re la plus facile Ã  faire face Ã  cette situation,
+est, de supprimer sur le noeud offensÃ©, les donnÃ©es dans <xref linkend="table.sl-event"/> relatives au noeud 2.
+Vous vous connectez Ã  la base du noeud 2, et Ã  l'aide de Sql suivant, de chercher l'Ã©vÃ¨nement
 <command>STORE_LISTEN</command>:</para>
 
 <para> <command> select * from sl_event where ev_type =
 'STORE_LISTEN';</command></para>
 
-<para> L'ordre peut ramener plusieurs lignes, mais ne en supprimer que la partie nécessaire.</para>
+<para> L'ordre peut ramener plusieurs lignes, mais ne en supprimer que la partie nÃ©cessaire.</para>
 
 <screen> 
 -# begin;  -- Don't straight delete them; open a transaction so you can respond to OOPS
@@ -2116,10 +2121,10 @@
 COMMIT
 </screen>
 
-<para> La prochaine fois que <application>slon</application> pour le noeud 3 redémarre, 
-il ne trouvera plus le <quote>souffrant</quote> évènement 
-<command>STORE_LISTEN</command>, et la réplication peur se poursuivre.
-(Vous pouvez par contre voir surgir un vieil évènement enregistré qui ne soit plus en phase 
+<para> La prochaine fois que <application>slon</application> pour le noeud 3 redÃ©marre, 
+il ne trouvera plus le <quote>souffrant</quote> Ã©vÃ¨nement 
+<command>STORE_LISTEN</command>, et la rÃ©plication peur se poursuivre.
+(Vous pouvez par contre voir surgir un vieil Ã©vÃ¨nement enregistrÃ© qui ne soit plus en phase 
 avec la configuration existante...) </para></answer>
 
 </qandaentry>

Modified: traduc/trunk/slony/intro.xml
===================================================================
--- traduc/trunk/slony/intro.xml	2008-08-08 07:46:52 UTC (rev 1117)
+++ traduc/trunk/slony/intro.xml	2008-08-08 07:47:39 UTC (rev 1118)
@@ -51,8 +51,10 @@
 <listitem><para> Un situation <quote>d'hÃ©bergement web</quote> oÃ¹ les 
     utilisateurs peuvent de maniÃ¨re indÃ©pendante et arbitraire changer les
     schÃ©mas des donnÃ©es.
-</itemizedlist></para>
-
+    </para>
+  </listitem>
+  </itemizedlist>
+</para>
 <para> Il existe une extension de <link linkend="logshipping"> log shipping par fichier</link>
   qui permet de regrouper les mises Ã  jour dans des fichiers.
   Ainsi, les fichiers de mises Ã  jours peuvent Ãªtre distribuÃ©s 

Modified: traduc/trunk/slony/logshipping.xml
===================================================================
--- traduc/trunk/slony/logshipping.xml	2008-08-08 07:46:52 UTC (rev 1117)
+++ traduc/trunk/slony/logshipping.xml	2008-08-08 07:47:39 UTC (rev 1118)
@@ -17,7 +17,7 @@
 <para> Ces fichiers de log peuvent alors Ãªtre transfÃ©rÃ©s selon la
   mÃ©thode de votre choix vers le <quote>serveur esclave</quote>,
   que ce soit via   FTP, rsync, ou mÃªme avec une <quote>clÃ© USB</quote> 
-  d' 1GB <quote> transportÃ©e par avion.</para>
+  d' 1GB transportÃ©e par avion.</para>
 
 <para> Il y a plein de choses sympas Ã  faire avec un tel flux de donnÃ©e,
   en particulier :

Modified: traduc/trunk/slony/slon.xml
===================================================================
--- traduc/trunk/slony/slon.xml	2008-08-08 07:46:52 UTC (rev 1117)
+++ traduc/trunk/slony/slon.xml	2008-08-08 07:47:39 UTC (rev 1118)
@@ -181,7 +181,7 @@
       200 Ã©vÃ©nements <command>SYNC</command>s de retard, il essaiera de les regrouper 
       par groupes dont la taille maximale sera <envar>sync_group_maxsize</envar>.
       Ceci doit permettre de rÃ©duire le temps de lantence au dÃ©marrage (NdT : "overhead")
-      en rÃ©duisant le nombre de transactions Ã  <quote>comitter</quoter>.
+      en rÃ©duisant le nombre de transactions Ã  <quote>comitter</quote>.
      </para>
      <para>
       La valeur par dÃ©faut est 6 est probablement adÃ©quate pour les petits systÃ¨mes

Modified: traduc/trunk/slony/slonik_ref.xml
===================================================================
--- traduc/trunk/slony/slonik_ref.xml	2008-08-08 07:46:52 UTC (rev 1117)
+++ traduc/trunk/slony/slonik_ref.xml	2008-08-08 07:47:39 UTC (rev 1118)
@@ -1104,7 +1104,7 @@
       par vos applications, cela imposera un coupure de service
       significative qui correspond au tems de modification de la
       table sur le noeud d'origine. C'est pourquoi il est recommandÃ©
-      que cette commande ne sit pas utilisÃ©e quand c'est possible.      
+      que cette commande ne sit pas utilisÃ©e quand c'est possible.</para>      
    </refsect1>
    <refsect1> <title> Note de version </title>
     <para> Cette commande fut introduite dans &slony1; 1.0 </para>
@@ -1169,6 +1169,7 @@
       <listitem><para> Un text descriptif peut Ãªtre ajoutÃ©e pour l'ensemble de rÃ©plication.</para>
                 <para> Si aucune commentaire n'est fourni, la valeur par dÃ©faut est  <command>A replication set so boring no one thought to give it a name</command>  (NdT : <quote>Un ensemble de rÃ©plication tellement
 		  ennuyeux qui personne n'a pensÃ© Ã  lui donner un nom</quote>)
+	      </para>
       </listitem>
      </varlistentry>
     </variablelist>

