[jboss-cvs] JBossAS SVN: r78516 - projects/docs/enterprise/4.3/Cache/Cache_Tree_Cache_Guide/fr-FR.

[jboss-cvs-commits at lists.jboss.org]

Author: croe at redhat.com
Date: 2008-09-14 23:19:34 -0400 (Sun, 14 Sep 2008)
New Revision: 78516

Modified:
   projects/docs/enterprise/4.3/Cache/Cache_Tree_Cache_Guide/fr-FR/Mgmt_information.po
   projects/docs/enterprise/4.3/Cache/Cache_Tree_Cache_Guide/fr-FR/Replication.po
   projects/docs/enterprise/4.3/Cache/Cache_Tree_Cache_Guide/fr-FR/State_transfer.po
   projects/docs/enterprise/4.3/Cache/Cache_Tree_Cache_Guide/fr-FR/Transactions.po
   projects/docs/enterprise/4.3/Cache/Cache_Tree_Cache_Guide/fr-FR/Tree_Cache_Guide.po
   projects/docs/enterprise/4.3/Cache/Cache_Tree_Cache_Guide/fr-FR/Treecache_marshaller.po
Log:
Translation completed and proof read 100%

Modified: projects/docs/enterprise/4.3/Cache/Cache_Tree_Cache_Guide/fr-FR/Mgmt_information.po
===================================================================
--- projects/docs/enterprise/4.3/Cache/Cache_Tree_Cache_Guide/fr-FR/Mgmt_information.po	2008-09-15 00:44:53 UTC (rev 78515)
+++ projects/docs/enterprise/4.3/Cache/Cache_Tree_Cache_Guide/fr-FR/Mgmt_information.po	2008-09-15 03:19:34 UTC (rev 78516)
@@ -9,7 +9,7 @@
 "Project-Id-Version: Mgmt_information\n"
 "Report-Msgid-Bugs-To: http://bugs.kde.org\n"
 "POT-Creation-Date: 2008-05-30 04:03+0000\n"
-"PO-Revision-Date: 2008-09-11 16:22+1000\n"
+"PO-Revision-Date: 2008-09-15 09:11+1000\n"
 "Last-Translator: Corina Roe <croe at redhat.com>\n"
 "Language-Team: French <i18 at redhat.com>\n"
 "MIME-Version: 1.0\n"
@@ -760,7 +760,7 @@
 "notifications when running in a JBoss application server environment. In "
 "this example, the client uses a filter to specify which events are of "
 "interest."
-msgstr "Vous trouverez ci-dessous un exemple sur la façon de recevoir programmatiquement des notifications cache en cours d'exécution dans un environnement de serveru d'application JBoss. Dans cet exemple, le client utilise un filtre pour préciser les événements qui l'interesse."
+msgstr "Vous trouverez ci-dessous un exemple sur la façon de recevoir programmatiquement des notifications cache en cours d'exécution dans un environnement de serveur d'application JBoss. Dans cet exemple, le client utilise un filtre pour préciser les événements qui l'intéressent."
 
 #. Tag: programlisting
 #: Mgmt_information.xml:612
@@ -896,7 +896,7 @@
 "after a client registers to receive MBean notifications. As soon as no "
 "clients are registered for notifications, the MBean will remove itself as a "
 "cache listener."
-msgstr "Notez: l'implémentation de gestion de JBoss Cache n'écoute les événements cache qu'après qu'un client n'ait été enregistré pour recevoir les notifications MBean. Dés qu'aucun client n'est enregistré pour recevoir les notifications, le MBean se retirera en tant que listener cache."
+msgstr "Notez: l'implémentation de gestion de JBoss Cache n'écoute les événements cache qu'après qu'un client ait été enregistré pour recevoir les notifications MBean. Dès qu'aucun client n'est enregistré pour recevoir les notifications, le MBean se retirera en tant que listener cache."
 
 #. Tag: title
 #: Mgmt_information.xml:623
@@ -912,7 +912,7 @@
 "application server that provides an MBean server interface such as JBoss JMX "
 "Console. Refer to server documentation for instructions on how to access "
 "MBeans running in a server's MBean container."
-msgstr "Les Mbeans JBoss Cache sont accessibles facilement en cours d'exécution des instances cache au seinf d'un serveur d'applications qui procure une interface de serveur MBean comme la Console JBoss JMX. Voir la documentation serveur pour les instructions sur la façon d'accéder aux Mbeans actifs sur un container MBean de serveur."
+msgstr "Les Mbeans JBoss Cache sont accessibles facilement en cours d'exécution des instances cache au sein d'un serveur d'applications qui procure une interface de serveur MBean comme la Console JBoss JMX. Voir la documentation serveur pour les instructions sur la façon d'accéder aux Mbeans actifs sur un container MBean de serveur."
 
 #. Tag: para
 #: Mgmt_information.xml:627
@@ -945,7 +945,7 @@
 msgid ""
 "When the utility loads, you will be able to select your JVM and connect to "
 "it. The JBoss Cache MBeans will be available on the MBeans panel."
-msgstr "Quand l'utilitaire se chargera, vous serez en mesure de sélectionner votre JVM et de la connecter. Les MBeans JBoss Cache seront disponibles sur le panneau MBeans."
+msgstr "Quand l'utilitaire sera en cours de chargement, vous serez en mesure de sélectionner votre JVM et de la connecter. Les MBeans JBoss Cache seront disponibles sur le panneau MBeans."
 
 #. Tag: para
 #: Mgmt_information.xml:643

Modified: projects/docs/enterprise/4.3/Cache/Cache_Tree_Cache_Guide/fr-FR/Replication.po
===================================================================
--- projects/docs/enterprise/4.3/Cache/Cache_Tree_Cache_Guide/fr-FR/Replication.po	2008-09-15 00:44:53 UTC (rev 78515)
+++ projects/docs/enterprise/4.3/Cache/Cache_Tree_Cache_Guide/fr-FR/Replication.po	2008-09-15 03:19:34 UTC (rev 78516)
@@ -9,7 +9,7 @@
 "Project-Id-Version: Replication\n"
 "Report-Msgid-Bugs-To: http://bugs.kde.org\n"
 "POT-Creation-Date: 2008-05-30 04:03+0000\n"
-"PO-Revision-Date: 2008-09-08 15:08+1000\n"
+"PO-Revision-Date: 2008-09-15 12:22+1000\n"
 "Last-Translator: Corina Roe <croe at redhat.com>\n"
 "Language-Team: French <i18 at redhat.com>\n"
 "MIME-Version: 1.0\n"
@@ -21,7 +21,7 @@
 #: Replication.xml:10
 #, no-c-format
 msgid "Clustered Caches"
-msgstr "Caches clusterisés"
+msgstr "Caches clustérisés"
 
 #. Tag: para
 #: Replication.xml:11
@@ -47,7 +47,7 @@
 "a cluster. Therefore their elements don't need to be serializable - however, "
 "we recommend making them serializable, enabling a user to change the cache "
 "mode at any time."
-msgstr "Les caches locaux ne rejoignent pas un groupement, ni ne communiquent avec les autres noeuds au sein d'un même groupement. De ce fait, les éléments n'ont pas besoin d'être sérialisables = cependant, nous recommandons que vous les rendiez sérialisables, permettant ainsi à un utilisateur de modifier le mode cache à tout moment."
+msgstr "Les caches locaux ne rejoignent pas un groupement, ni ne communiquent avec les autres noeuds au sein d'un même groupement. De ce fait, les éléments n'ont pas besoin d'être sérialisables - cependant, nous recommandons que vous les rendiez sérialisables, permettant ainsi à un utilisateur de modifier le mode cache à tout moment."
 
 #. Tag: title
 #: Replication.xml:22
@@ -78,7 +78,7 @@
 "also offers a replication queue, where modifications are replicated "
 "periodically (i.e. interval-based), or when the queue size exceeds a number "
 "of elements, or a combination thereof."
-msgstr "La réplication peut être synchrône ou bien asynchrône. L'utilisation de l'une ou l'autre des options dépend de l'application. La replication synchrône bloque l'appelant (pae ex. sur un put() jsuqu'à ce que toutes les modifications avoir été répliquées aevc succès sur tous les noeuds du groupement. La replication asynchrône procède à des réplications en arrière-plan (le put() retourne immédiatement). <literal>TreeCache</literal> propose également une queue de réplication, ou les modifications sont répliquées périodiquement (par ex. basées intervalle), ou quand la taille de la file d'attente dépasse une nombre d'éléments, ou une de leurs combinaison."
+msgstr "La réplication peut être synchrone ou bien asynchrone. L'utilisation de l'une ou l'autre des options dépend de l'application. La replication synchrone bloque l'appelant (par ex. sur un put() jusqu'à ce que toutes les modifications aient été répliquées avec succès sur tous les noeuds du groupement. La replication asynchrone procède à des réplications en arrière-plan (le put() retourne immédiatement). <literal>TreeCache</literal> propose également une queue de réplication, où les modifications sont répliquées périodiquement (par ex. basées intervalle), ou quand la taille de la file d'attente dépasse une nombre d'éléments, ou bien encore, une de leurs combinaison."
 
 #. Tag: para
 #: Replication.xml:29
@@ -93,7 +93,7 @@
 "asynchronous replication, errors are simply written to a log. Even when "
 "using transactions, a transaction may succeed but replication may not "
 "succeed on all <literal>TreeCache</literal> instances."
-msgstr "La replication asynchrône est plus rapide (pas de blocage), car la réplication synchrone nécessite le feu rouge de tous les noeuds reçus du groupement et qu'ils appliquent cette modification avec succès (aller-retour). Cependant, lorsqu'une replication synchrône retourne avec succès, l'appelant peut être sûr que toutes les modifications ont été appliquées à tous les noeuds, alors que ce peut être ou non le cas pour la réplication asynchrone. En replication asynchrone, les erreurs sont tout simplement enregistrées. Même lorsqu'on utilise des transactions, une transaction peut réussir, mais la réplication peut échouer sur toutes les instances de <literal>TreeCache</literal>."
+msgstr "La replication asynchrone est plus rapide (pas de blocage), car la réplication synchrone nécessite le feu rouge de tous les noeuds reçus du groupement et qu'ils appliquent cette modification avec succès (aller-retour). Cependant, lorsqu'une replication synchrone retourne avec succès, l'appelant peut être sûr que toutes les modifications ont été appliquées à tous les noeuds, alors que ce peut être ou non le cas pour la réplication asynchrone. En replication asynchrone, les erreurs sont tout simplement enregistrées. Même lorsqu'on utilise des transactions, une transaction peut réussir, mais la réplication peut échouer sur toutes les instances de <literal>TreeCache</literal>."
 
 #. Tag: title
 #: Replication.xml:33
@@ -111,7 +111,7 @@
 "individual modifications, and can be a lot more efficient than not using "
 "transactions. Another effect of this is that if a transaction were to roll "
 "back, nothing is broadcast across a cluster."
-msgstr "Quand on utilise les transactions, la réplication n'a lieu qu'à la limite de la transaction - c'est à dire, quand la transaction est validée. Cela se traduit par une réduction du traffic au minimum qu'il n'y a plus qu'une seule modification d'émise, et cela peut être bien plus efficace que de ne pas utiliser les transactions. De plus, si une transaction ne venait pas à rollback, rien se serait émis à travers le groupement."
+msgstr "Quand on utilise les transactions, la réplication n'a lieu qu'à la limite de la transaction - c'est à dire, quand la transaction est validée. Cela se traduit par une réduction du trafic de réplication au minimum puisqu' au lieu d'une série, il n'y a plus qu'une seule modification d'émise, et cela peut être bien plus efficace que de ne pas utiliser les transactions. De plus, si une transaction ne venait pas à reprise (rollback), rien se serait émis à travers le groupement."
 
 #. Tag: para
 #: Replication.xml:37
@@ -122,7 +122,7 @@
 "\"http://en.wikipedia.org/wiki/Two-phase_commit_protocol\">two phase commit</"
 "ulink> protocol, respectively."
 msgstr ""
-"Suivant que vous exécutiez votre groupement en mode asynchrône ou synchrône, JBoss Cache va utiliser une phase unique ou le protocole .<ulink url="
+"Suivant que vous exécutiez votre groupement en mode asynchrone ou synchrone, JBoss Cache va utiliser une phase unique ou le protocole .<ulink url="
 "\"http://en.wikipedia.org/wiki/Two-phase_commit_protocol\">two phase commit</"
 "ulink>. respectivement"
 
@@ -141,7 +141,7 @@
 "local in-memory state and commit locally. Remote errors/rollbacks are never "
 "fed back to the originator of the transaction since the communication is "
 "asynchronous."
-msgstr "Utilisé quand votre mode cache est REPL_ASYNC. Toutes les modifications sont répliquées en un seul appel, qui instruit les caches éloignés d'appliquer les changements à leur état local en mémoire et de valider localement. Les erreurs/rollbacks éloignés ne sont jamais communiqués à l'initiateur de la transaction du fait que la communication est asynchrône."
+msgstr "Utilisé quand votre mode cache est REPL_ASYNC. Toutes les modifications sont répliquées en un seul appel, qui instruit les caches éloignés d'appliquer les changements à leur état local en mémoire et de valider localement. Les erreurs/rollbacks éloignés ne sont jamais communiqués à l'initiateur de la transaction du fait que la communication est asynchrone."
 
 #. Tag: title
 #: Replication.xml:48
@@ -160,7 +160,7 @@
 "to the prepare call, the originator of the transaction broadcasts a commit. "
 "This instructs all remote caches to commit their data. If any of the caches "
 "fail to respond to the prepare phase, the originator broadcasts a rollback."
-msgstr "Utilisé quand votre cache mode est REPL_SYNC\" Au moment de la validation de votre transaction, JBoss Cache émet un appel 'prepare', qui comporte toutes les modifications relatives à la transaction. Les cahes éloignés obtiennent alors les verrous locaux sur leur état en-mémoire et appliquent les modifications. Une fois que tous les caches éloignés ont répondu à l'appel 'prepare', l'initiateur de la transaction émet une validation. Cela instruit tous les caches éloignés de valider leurs données. SI aucun cache ne répond à l'étape 'prepare', l'initiateur émet un roolback."
+msgstr "Utilisé quand votre cache mode est REPL_SYNC. Au moment de la validation de votre transaction, JBoss Cache émet un appel 'prepare', qui comporte toutes les modifications relatives à la transaction. Les caches éloignés obtiennent alors les verrous locaux sur leur état en-mémoire et appliquent les modifications. Une fois que tous les caches éloignés ont répondu à l'appel 'prepare', l'initiateur de la transaction émet une validation. Cela instruit tous les caches éloignés de valider leurs données. Si aucun cache ne répond à l'étape 'prepare', l'initiateur émet un rollback."
 
 #. Tag: para
 #: Replication.xml:52
@@ -176,8 +176,8 @@
 "can be forced to be synchronous using the <literal>SyncCommitPhase</literal> "
 "and <literal>SyncRollbackPhase</literal> configuration options."
 msgstr ""
-"Notez que malgré que l'étape 'prepare' soit synchrône, les étapes 'valider' et 'rollback' sont asynchrônes. C'est parce que <ulink url=\"http://java.sun.com/"
-"products/jta/\">Sun's JTA specification</ulink> ne précise pas comment les ressources transactionnelles doivent appréhender les échecs à cette étape de la transaction, et d'autres ressources participant à la transaction pourraient avoir un état indéterminé de toutes façoncs. Ainsi, on règle le problème de communication synchrone pour cette phase de la transaction. Cela étant dit, ils peuvent être forcés à être synchrônes en utilisant les options de configuration <literal>SyncRollbackPhase</literal>."
+"Notez que malgré que l'étape 'prepare' soit synchrone, les étapes 'valider' et 'rollback' sont asynchrones. C'est parce que <ulink url=\"http://java.sun.com/"
+"products/jta/\">Sun's JTA specification</ulink> ne précise pas comment les ressources transactionnelles doivent appréhender les échecs à cette étape de la transaction, et d'autres ressources participant à la transaction pourraient avoir un état indéterminé de toutes façons. Ainsi, on règle le problème de communication synchrone pour cette phase de la transaction. Cela étant dit, ils peuvent être forcés à être synchrones en utilisant les options de configuration <literal>SyncRollbackPhase</literal>."
 
 #. Tag: title
 #: Replication.xml:60
@@ -194,7 +194,7 @@
 "in the cluster, and only replicates to these specific buddies. This greatly "
 "helps scalability as there is no longer a memory and network traffic impact "
 "every time another instance is added to a cluster."
-msgstr "Buddy Replication vous autorise à cesser de dupliquervos données dans toutes les instances d'un groupement. Au lieu de cela, chaque instance choisit un ou plusieurs 'buddies' dans le groupement, et ne duplique que vers ces 'buddies' particuliers. Cela facilite énormément la variabilité d'échelle car il n'y a plus de mémoire, ni d'impact de traffic sur le réseau à cahque fois qu'une instance est ajoutée au groupement."
+msgstr "Buddy Replication vous autorise à cesser de dupliquer vos données dans toutes les instances d'un groupement. Au lieu de cela, chaque instance choisit un ou plusieurs 'buddies' dans le groupement, et ne duplique que vers ces 'buddies' particuliers. Cela facilite énormément la variabilité d'échelle car il n'y a plus de mémoire, ni d'impact de trafic sur le réseau à chaque fois qu'une instance est ajoutée au groupement."
 
 #. Tag: para
 #: Replication.xml:64
@@ -209,9 +209,7 @@
 "that this is always accessed on one instance rather than in a round-robin "
 "fashion as this helps the cache cluster optimise how it chooses buddies, "
 "where it stores data, and minimises replication traffic."
-msgstr ""
-"Un des cas les plus communs de Buddy Replication est lorsqu'un cache dupliqué est utilisé par un container de servlet pour stocker les données d'une session HTTP. Une des conditions préliminaires du succès de Buddy Replication est l'utilisation de <emphasis>session affinity</emphasis>, connue également sous le nom de "
-"<emphasis>sticky sessions</emphasis> dans le langage de replication de sessions HTTP. Cela signifie que si on accède souvent à certaines données, il est désirable de la faire par une seule instance plutôt que d'une manière cyclique, car cela permet au groupement cache d'optimiser la façon dont il doit choisir les buddies, ou il devra stocker les données, et minimiser le traffic de réplication."
+msgstr "Un des cas les plus communs de Buddy Replication est lorsqu'un cache dupliqué est utilisé par un container de servlet pour stocker les données d'une session HTTP. Une des conditions préliminaires du succès de Buddy Replication est l'utilisation de <emphasis>session affinity</emphasis>, connue également sous le nom de <emphasis>sticky sessions</emphasis> dans le langage de replication de session HTTP. Cela signifie que si on accède souvent à certaines données, il est désirable de la faire par une seule instance plutôt que d'une manière cyclique, car cela permet au groupement cache d'optimiser la façon dont il doit choisir les buddies, où il devra stocker les données, et minimiser le trafic de réplication."
 
 #. Tag: para
 #: Replication.xml:67
@@ -219,7 +217,7 @@
 msgid ""
 "If this is not possible, Buddy Replication may prove to be more of an "
 "overhead than a benefit."
-msgstr "Si ce n'est pas possible, Buddy Replication se révèlera être plus un inconvénient qu'un avantage."
+msgstr "Si ce n'est pas possible, Buddy Replication sera plutôt un inconvénient qu'un avantage."
 
 #. Tag: title
 #: Replication.xml:71
@@ -242,7 +240,7 @@
 msgstr ""
 "La réplication des 'buddies' utilise une instance de <literal>org.jboss.cache."
 "buddyreplication.BuddyLocator</literal> qui contient la logique de sélection des 'buddies' dans le réseau. JBoss Cache est actuellement proposé dans une seule implémentation, <literal>org.jboss.cache.buddyreplication."
-"NextMemberBuddyLocator</literal>, qui est utilisée par défaut si aucune implémentation n'est offerte. Le <literal>NextMemberBuddyLocator</literal> sélectionne le prochain membre du groupement, comme son nom l'indique, et garantit une répartition équilibrée des 'buddies' de chaque instance."
+"NextMemberBuddyLocator</literal>, est utilisée par défaut si aucune implémentation n'est offerte. Le <literal>NextMemberBuddyLocator</literal> sélectionne le prochain membre du groupement, comme son nom l'indique, et garantit une répartition équilibrée des 'buddies' de chaque instance."
 
 #. Tag: para
 #: Replication.xml:75
@@ -270,7 +268,7 @@
 "defaults to <literal>true</literal>."
 msgstr ""
 "<literal>ignoreColocatedBuddies</literal> - signifie que chaque instance va "
-"<emphasis>essayer</emphasis> de sélectionner un buddy sur hôte physique différent. Si ce n'est pas possible, il va retomber dans les instances colocated. La valeur par défaut est <literal>true</literal>."
+"<emphasis>essayer</emphasis> de sélectionner un buddy sur hôte physique différent. Si ce n'est pas possible, il va retomber dans les instances colocalisées. La valeur par défaut est <literal>true</literal>."
 
 #. Tag: title
 #: Replication.xml:88
@@ -293,7 +291,7 @@
 "picking an instance on a different host on the same rack, "
 "<literal>BuddyLocator</literal>s would rather pick the instance in the same "
 "buddy pool, on a separate rack which may add a degree of redundancy."
-msgstr "Egalement connnu sous le nom de groupes de réplication, un buddy poo; est une construction optionnelle ou chaque instance d'un groupement peut être configurée avec un nom de buddy pool. Imaginez une 'carte de membre de club exclusif' pour laquelle, lorsque vous sélectionnez 'buddies', <literal>BuddyLocator</literal> tente de sélectionner des 'buddies' qui partagent le même nom de buddy pool. Par exemple, un sysadmin peut mettre deux instances sur deux serveurs séparés, qui pourraient se trouver sur deux racks séparés, dans la même buddy pool. Donc, au lieu de choisir une instance sur un hôte différent sur le même rack, <literal>BuddyLocator</literal> préfèrera choisir une instance dans la même buddy pool, sur un rack séparé, qui pourrait ajouter un degré de redondance."
+msgstr "Egalement connnu sous le nom de groupes de réplication, un 'buddy pool'; est une construction optionnelle pour laquelle chaque instance d'un groupement peut être configurée avec un nom de buddy pool. Imaginez une 'carte de membre de club exclusif' pour laquelle, lorsque vous sélectionnez 'buddies', <literal>BuddyLocator</literal> tente de sélectionner des 'buddies' qui partagent le même nom de buddy pool. Par exemple, un sysadmin peut mettre deux instances sur deux serveurs séparés, qui pourraient se trouver sur deux racks séparés, dans la même buddy pool. Donc, au lieu de choisir une instance sur un hôte différent sur le même rack, <literal>BuddyLocator</literal> préférera choisir une instance dans la même buddy pool, sur un rack séparé, qui pourrait ajouter un degré de redondance."
 
 #. Tag: title
 #: Replication.xml:95
@@ -310,7 +308,7 @@
 "service such as HTTP session replication) is able to redirect the request to "
 "any other random cache instance in the cluster. This is where a concept of "
 "Data Gravitation comes in."
-msgstr "Dans le triste cas d'un échec d'une instance, on assume que le client qui se connecte au cache (directement ou indirectement, par l'intermédiaire de quelqu'autre service comme la replication de session HTTP) est capable de rediriger la demande vers n'importe quelle instance cache au hasard du groupement, d'ou le concept de gravitation de données (Data Gravitation)."
+msgstr "Dans le cas malencontreux d'un échec d'une instance, on assume que le client qui se connecte au cache (directement ou indirectement, par l'intermédiaire de quelqu'autre service comme la replication de session HTTP) est capable de rediriger la demande vers n'importe quelle instance cache au hasard du groupement, d'où le concept de gravitation de données (Data Gravitation)."
 
 #. Tag: para
 #: Replication.xml:99
@@ -323,7 +321,7 @@
 "other caches. This means that even if a cache containing your session dies, "
 "other instances will still be able to access this data by asking the cluster "
 "to search through their backups for this data."
-msgstr "Le concept de gravitation de données implique que si lance une requête sur un cache d'un groupement et que le cache me comprend aucune information, il demande alors les données aux autres instances du groupement. Si cela échoue, il demanderait (en option) aux autres instances de vérifier s'il n'existe pas d'autres caches dans les données de sauvegarde. Cela implique que même si le cache qui contient votre session se meurt, les autres instances seront toujours en mesure d'accéder à ces données en demandant au groupement de chercher ces données en mémoire."
+msgstr "Le concept de gravitation de données implique que si on lance une requête sur un cache d'un groupement et que le cache me comprend aucune information, il demande alors les données aux autres instances du groupement. Si cela échoue, il demanderait (en option) aux autres instances de vérifier s'il n'existe pas d'autres caches dans les données de sauvegarde. Cela implique que même si le cache qui contient votre session se meurt, les autres instances seront toujours en mesure d'accéder à ces données en demandant au groupement de chercher ces données en mémoire."
 
 #. Tag: para
 #: Replication.xml:102
@@ -334,7 +332,7 @@
 "removed from all other instances (and backups) so that if session affinity "
 "is used, the affinity should now be to this new cache instance which has "
 "just <emphasis>taken ownership</emphasis> of this data."
-msgstr "Une fois localisé, les données sont alors transferrées à l'instance qui l'ont réclamées et sont ajoutées à l'arborescence de cette instance. Elles sont alors (en option) supprimées de toutes autres instances (et backups) de façon à ce que si l'affinité de session est utilisée, l'affinité devrait maintenant se trouver dans l'instance de ce nouveau cache, qui vient juste de <emphasis>s'approprier</emphasis> ces données."
+msgstr "Une fois localisé, les données sont alors transférées à l'instance qui les ont réclamées et sont ajoutées à l'arborescence de cette instance. Elles sont alors (en option) supprimées de toutes autres instances (et backups) de façon à ce que si l'affinité de session est utilisée, elle devrait maintenant se trouver dans l'instance de ce nouveau cache, qui vient juste de <emphasis>s'approprier</emphasis> ces données."
 
 #. Tag: para
 #: Replication.xml:105
@@ -342,7 +340,7 @@
 msgid ""
 "Data Gravitation is implemented as an interceptor. The following (all "
 "optional) configuration properties pertain to data gravitation."
-msgstr "La gravitation de données est implémentée en tant qu'intercepteur, Les propriétés de configuration suivantes (toutes optionelles) affèrent à la gravitation des données."
+msgstr "La gravitation de données est implémentée en tant qu'intercepteur. Les propriétés de configuration suivantes (toutes optionelles) affèrent à la gravitation des données."
 
 #. Tag: para
 #: Replication.xml:108
@@ -355,7 +353,7 @@
 "in cache loaders will remain. This is useful if you have a shared cache "
 "loader configured. Defaults to <literal>true</literal>."
 msgstr ""
-"<literal>dataGravitationRemoveOnFind</literal> - force tous les caches éloignés qui contiennent les données et les backups, permettant ainsi au cache réclamateur de devenir le nouveau propriétaire des données. S'il est paramétré à <literal>false</"
+"<literal>dataGravitationRemoveOnFind</literal> - force tous les caches éloignés qui possèdent les données et les backups pour que ces données puissent extraire ces mêmes données, permettant ainsi au cache réclamateur de devenir le nouveau propriétaire des données. S'il est paramétré à <literal>false</"
 "literal> (faux) une éviction (evict) est émise à la place d'une suppression (remove), et tout état persistant du cache loader demeurera. C'est utile si vous avez une cache loader partagé de configuré. La valeur par défaut est <literal>true</literal> (vrai)."
 
 #. Tag: para
@@ -368,8 +366,8 @@
 "<literal>true</literal> then backup nodes can respond to data gravitation "
 "requests in addition to data owners."
 msgstr ""
-"<literal>dataGravitationSearchBackupTrees</literal> - Demande aux instances éloignées de charcher parmi leurs arborescences de données principales et backups. La valeur par défaut est <literal>true</literal>. Ainsi, si c'est "
-"<literal>true</literal>, les noeuds de backup peuvent alors répondre aux demandes de gravitation des données en plus des propriétaires de données."
+"<literal>dataGravitationSearchBackupTrees</literal> - Demande aux instances éloignées de chercher parmi leurs arborescences de données principales et backups. La valeur par défaut est <literal>true</literal>. Ainsi, si configuré à "
+"<literal>true</literal>, les noeuds de backup peuvent alors répondre aux demandes de gravitation des données en plus des demandes de propriétaires de données."
 
 #. Tag: para
 #: Replication.xml:114
@@ -382,15 +380,13 @@
 "data gravitation on a per-invocation basis. If <literal>autoDataGravitation</"
 "literal> is <literal>true</literal> this <literal>Option</literal> is "
 "unnecessary."
-msgstr ""
-"<literal>autoDataGravitation</literal> - Si la gravitation des données a lieu pour chaque cache manqué. Cela est fixé à <literal>false</literal> par défaut pour éviter tout appel de réseau non nécessaire. Dans la plupart des cas, on saura si on a besoin des données de gravitaion,et on âssera une <literal>Option</literal> qui va activer la gravitation sur la base d'une invocation. Si <literal>autoDataGravitation</"
-"literal> est <literal>true</literal> (vrai) cette <literal>Option</literal> est nécessaire."
+msgstr "<literal>autoDataGravitation</literal> - Si la gravitation des données a lieu pour chaque cache manqué. Cela est fixé à <literal>false</literal> (faux) par défaut pour éviter tout appel de réseau non nécessaire. Dans la plupart des cas, on saura si on a besoin des données de gravitation, et on passera une <literal>Option</literal> qui va activer la gravitation sur la base d'une invocation. Si <literal>autoDataGravitation</literal> est congiguré à <literal>true</literal> (vrai) cette <literal>Option</literal> n'est pas nécessaire."
 
 #. Tag: title
 #: Replication.xml:121
 #, no-c-format
 msgid "Implementation"
-msgstr "Implementation"
+msgstr "Implémentation"
 
 #. Tag: title
 #: Replication.xml:124
@@ -398,7 +394,7 @@
 msgid ""
 "Class diagram of the classes involved in buddy replication and how they are "
 "related to each other"
-msgstr "Diagramme des classes impliquées dans la buddy replication et comment elles dépendent les unes des aures."
+msgstr "Diagramme des classes impliquées dans la buddy replication et comment elles dépendent les unes des autres."
 
 #. Tag: title
 #: Replication.xml:135
@@ -534,7 +530,7 @@
 #: Replication.xml:146
 #, no-c-format
 msgid "Clustered Cache - Using Invalidation"
-msgstr "Cache clusterisé - Utiliser l'invalidation"
+msgstr "Cache clustérisé - Utiliser l'invalidation"
 
 #. Tag: para
 #: Replication.xml:147
@@ -549,7 +545,7 @@
 "traffic is minimised as invalidation messages are very small compared to "
 "replicating updated data, and also that other caches in the cluster look up "
 "modified data in a lazy manner, only when needed."
-msgstr "Si un cache est configuré pour une invalidation plutôt que pour une réplication, à chaque fois que les données sont changées dans un cache, les autres caches du groupement reçoivent un message les informant que leurs données sont maintenant stale et devraient maintenant être évincées de la mémoire. L'invalidation, lorsqu'elle est utilisée en conjonction à un cache loader partagé (voir le chapitre sur les Cache Loaders), entraînerait les caches éloignés à se référer au cache loader partagé pour retirer les données modifiées. Le bénéfice est à deux niveaux: le traffic du réseau est minimisé du fait que les messages d'invalidation sont très petits par rapport aux données répliquées mises à jour, et aussi du fait que les autres caches du groupement cherchent les données modifiées de façon 'lazy', seulement si nécessaire."
+msgstr "Si un cache est configuré pour une invalidation plutôt que pour une réplication, à chaque fois que les données sont changées dans un cache, les autres caches du groupement reçoivent un message les informant que leurs données sont maintenant périmées et devraient être évincées de la mémoire. L'invalidation, lorsqu'elle est utilisée en conjonction à un cache loader partagé (voir le chapitre sur les Cache Loaders), entraînerait les caches éloignés à se référer au cache loader partagé pour retirer les données modifiées. Le bénéfice est à deux niveaux: le trafic du réseau est minimisé du fait que les messages d'invalidation sont très petits par rapport aux données répliquées mises à jour, et aussi du fait que les autres caches du groupement cherchent les données modifiées de façon 'lazy', seulement si nécessaire."
 
 #. Tag: para
 #: Replication.xml:150
@@ -570,5 +566,5 @@
 "cluster receive invalidation messages and have evicted stale data while "
 "asynchronous invalidation works in a 'fire-and-forget' mode, where "
 "invalidation messages are broadcast but doesn't block and wait for responses."
-msgstr "L'invalidation aussi peut être synchrône ou asynchrône, et tout comme dans un cas de replication, l'invalidation synchrône bloque jusqu'à ce que tous les caches du groupement reçoivent les messages d'invalidation et aient des données d'éviction stale, tandis que l'invalidation asynchrone fonctionne dans un mode 'fire-and-forget' (*autonome après lancement), pour lequel les messages d'invalidation sont émis, mais ne bloquent pas et attendent des réponses."
+msgstr "L'invalidation aussi peut être synchrone ou asynchrone, et tout comme dans un cas de replication, l'invalidation synchrone bloque jusqu'à ce que tous les caches du groupement reçoivent les messages d'invalidation et aient expulsé les données d'éviction périmées, tandis que l'invalidation asynchrone fonctionne dans un mode 'fire-and-forget' (autonome après lancement), pour lequel les messages d'invalidation sont émis, mais ne bloquent pas et attendent des réponses."
 

Modified: projects/docs/enterprise/4.3/Cache/Cache_Tree_Cache_Guide/fr-FR/State_transfer.po
===================================================================
--- projects/docs/enterprise/4.3/Cache/Cache_Tree_Cache_Guide/fr-FR/State_transfer.po	2008-09-15 00:44:53 UTC (rev 78515)
+++ projects/docs/enterprise/4.3/Cache/Cache_Tree_Cache_Guide/fr-FR/State_transfer.po	2008-09-15 03:19:34 UTC (rev 78516)
@@ -9,7 +9,7 @@
 "Project-Id-Version: State_transfer\n"
 "Report-Msgid-Bugs-To: http://bugs.kde.org\n"
 "POT-Creation-Date: 2008-05-30 04:03+0000\n"
-"PO-Revision-Date: 2008-09-08 16:06+1000\n"
+"PO-Revision-Date: 2008-09-15 12:32+1000\n"
 "Last-Translator: Corina Roe <croe at redhat.com>\n"
 "Language-Team: French <i18 at redhat.com>\n"
 "MIME-Version: 1.0\n"
@@ -61,9 +61,7 @@
 msgid ""
 "\"In-memory\" state transfer is enabled by setting the cache's "
 "<literal>FetchInMemoryState</literal> property to <literal>true</literal>."
-msgstr ""
-"Le transfert de l'état\"In-memory\" est activé lorsqu'on paramètre la propriété du cache "
-"<literal>FetchInMemoryState</literal> à <literal>true</literal> (vrai)."
+msgstr "Le transfert de l'état\"In-memory\" (en mémoire) est activé lorsqu'on paramètre la propriété du cache <literal>FetchInMemoryState</literal> à <literal>true</literal> (vrai)."
 
 #. Tag: para
 #: State_transfer.xml:29
@@ -85,8 +83,7 @@
 "chain, only one can have this property set to true; otherwise you will get "
 "an exception at startup."
 msgstr ""
-"Le transfert de l'état \"Persistent\" est activé quand on fixe la propriété du cache loader "
-"<literal>CacheLoaderFetchPersistentState</literal> à "
+"Le transfert de l'état \"Persistent\" est activé quand on fixe la propriété du cache loader <literal>CacheLoaderFetchPersistentState</literal> à "
 "<literal>true</literal> (vrai). Si on configure des caches loaders multiples dans une chaîne, on ne peut paramétrer la propriété d'un seul à 'true', sinon on obtiendra une exception au démarrage."
 
 #. Tag: para
@@ -100,7 +97,7 @@
 "<literal>CacheLoaderFetchPersistentState</literal> set to <literal>true</"
 "literal>."
 msgstr ""
-"Le transfert de l'état persistent avec un cache loader partagé n'est pas logique, car le même store persistant qui fournit les données finira par les recevoir lui-même. Ainsi, si on utilise ne cache loader partagé, le cache ne permettra pas de transfert d'état persistant, même si le cache loader a <literal>CacheLoaderFetchPersistentState</literal> paramétré à <literal>true</"
+"Le transfert de l'état persistent avec un cache loader partagé n'est pas logique, car le même store persistant qui fournit les données finira par les recevoir lui-même. Ainsi, si on utilise un cache loader partagé, le cache ne permettra pas de transfert d'état persistant, même si le cache loader a <literal>CacheLoaderFetchPersistentState</literal> paramétré à <literal>true</"
 "literal>."
 
 #. Tag: para
@@ -127,7 +124,7 @@
 "transfer. This approach somewhat reduces the burden on the cache instance "
 "providing state, but increases the load on the persistent store on the "
 "recipient side.)"
-msgstr "Si un cache loader write-through est utilisé, l'état du cache actuelle est totalement représenté par l'état persistent. Les données peuvent avoir été évincées d'un état en mémoire, mais elles seront toujours dans le store persistant. Dans un tel cas, si le cache loader n'est pas partagé, le transfert d'état persistant est utilisé pour veiller à ce que le nouveau cache est associé à l'état qui convient. L'état en-mémoire peut être transféré également si on souhaite un cache \"hot\" -- qui comprend toutes les données pertinentes en mémoire quand le cache commence à entrer en service. (Notez que le paramètre de configuration \"CacheLoaderPreload\" peut être utilisé également pour procurer un cache \"warm\" ou \"hot\" sans besoin d'un transfert d'état en-mémoire. Cette approche réduit quelque peu la pression sur l'instance de cache qui fournit l'état, mais augmente la charge sur le store persistant du côté du destinataire.)"
+msgstr "Si un cache loader write-through est utilisé, l'état du cache actuel est totalement représenté par l'état persistent. Les données peuvent avoir été évincées d'un état en mémoire, mais elles seront toujours dans le store persistant. Dans un tel cas, si le cache loader n'est pas partagé, le transfert d'état persistant est utilisé pour veiller à ce que le nouveau cache est associé à l'état qui convient. L'état en-mémoire peut être transféré également si on souhaite un cache \"hot\" -- qui comprend toutes les données pertinentes en mémoire quand le cache commence à entrer en service. (Notez que le paramètre de configuration \"CacheLoaderPreload\" peut être utilisé également pour procurer un cache \"warm\" ou \"hot\" sans besoin d'un transfert d'état en-mémoire. Cette approche réduit quelque peu la pression sur l'instance de cache qui fournit l'état, mais augmente la charge sur le store persistant du côté du destinataire.)"
 
 #. Tag: para
 #: State_transfer.xml:50
@@ -166,7 +163,7 @@
 "related to the entire tree -- i.e. the root node and all nodes below it. A "
 "\"partial\" state transfer is one where just a portion of the tree is "
 "transferred -- i.e. a node at a given Fqn and all nodes below it."
-msgstr "Si le transfert d'état persistant ou en-mémoire est activé, un transfert d'état partial ou complet sera effectué à des moments différents, suivant la manière dont le cache sera utilisé. Un transfert d'état \"complet\" fait référence à un état qui se rapporte à l'arborescence dans son ensemble -- c'est à dire le noeud racine et tous les noeuds en dessous. Un transfert \"partiel\" signifie qu'une seule partie de l'arborescence est transferrée - c'est à dire pour un Fqn donné et tous les noeuds qui en dépendent."
+msgstr "Si le transfert d'état persistant ou en-mémoire est activé, un transfert d'état partial ou complet sera effectué à des moments différents, suivant la manière dont le cache sera utilisé. Un transfert d'état \"complet\" fait référence à un état qui se rapporte à l'arborescence dans son ensemble -- c'est à dire le noeud racine et tous les noeuds en dessous. Un transfert \"partiel\" signifie qu'une seule partie de l'arborescence est transférée - c'est à dire pour un Fqn donné et tous les noeuds qui en dépendent."
 
 #. Tag: para
 #: State_transfer.xml:67
@@ -256,7 +253,7 @@
 "transfer, which are based on a \"pull\" approach (i.e. recipient asks for "
 "and receives state). However, the process of preparing and integrating the "
 "state is the same."
-msgstr "Buddy replication. Lorsque budy replication est utilisée, le transfert d'état initial est désactivé. A la place, lorsqu'une instance du cache rejoint le groupement, il devient le buddy de l'une ou de plusieurs instances, et un eou plusieurs instances deviennent son buddy. A chaque fois qu'une instance détermine qu'elle a un nouveau 'buddy' poiur son backup, elle pousse son état courant vers le nouveau 'buddy'. Cette façon de 'pousser' son 'buddy' est légèrement différente des autres formes de transfert d'état, qui sont basées sur une approche \"pull\" (c'est à dire que le receveur demande et reçoit l'état). Cependant , le processus de préparation et d'intégration d'état est le même."
+msgstr "Buddy replication. Lorsque budy replication est utilisée, le transfert d'état initial est désactivé. A la place, lorsqu'une instance du cache rejoint le groupement, il devient le buddy de l'une ou de plusieurs instances, et un ou plusieurs instances deviennent son buddy. A chaque fois qu'une instance détermine qu'elle a un nouveau 'buddy' pour son backup, elle pousse son état courant vers le nouveau 'buddy'. Cette façon de 'pousser' son 'buddy' est légèrement différente des autres formes de transfert d'état, qui sont basées sur une approche \"pull\" (c'est à dire que le receveur demande et reçoit l'état). Cependant , le processus de préparation et d'intégration d'état est le même."
 
 #. Tag: para
 #: State_transfer.xml:103
@@ -282,5 +279,5 @@
 "instances until one responds, with buddy replication the instance that is "
 "activating a region will request partial state from each instance for which "
 "it is serving as a backup."
-msgstr "Le transfert d'état partiel suivant un appel <literal>activateRegion()</literal> est légèrement différent dans le cas de buddy replication également. A lieu de demander à une instance de cache un état partiel, et d'essayer toutes les instances jusqu'à l'obtention d'une réponse, avec la buddy replication, l'instance qui active la région demandera une état partiel de chaque instance qu'elle sert, comme backup."
+msgstr "Le transfert d'état partiel suivant un appel <literal>activateRegion()</literal> est légèrement différent dans le cas de buddy replication. Au lieu de demander à une instance de cache un état partiel, et d'essayer toutes les instances jusqu'à l'obtention d'une réponse, avec la buddy replication, l'instance qui active la région demandera une état partiel de chaque instance qu'elle sert en tant que  backup."
 

Modified: projects/docs/enterprise/4.3/Cache/Cache_Tree_Cache_Guide/fr-FR/Transactions.po
===================================================================
--- projects/docs/enterprise/4.3/Cache/Cache_Tree_Cache_Guide/fr-FR/Transactions.po	2008-09-15 00:44:53 UTC (rev 78515)
+++ projects/docs/enterprise/4.3/Cache/Cache_Tree_Cache_Guide/fr-FR/Transactions.po	2008-09-15 03:19:34 UTC (rev 78516)
@@ -9,7 +9,7 @@
 "Project-Id-Version: Transactions\n"
 "Report-Msgid-Bugs-To: http://bugs.kde.org\n"
 "POT-Creation-Date: 2008-05-30 04:03+0000\n"
-"PO-Revision-Date: 2008-09-09 14:05+1000\n"
+"PO-Revision-Date: 2008-09-15 13:18+1000\n"
 "Last-Translator: Corina Roe <croe at redhat.com>\n"
 "Language-Team: French <i18 at redhat.com>\n"
 "MIME-Version: 1.0\n"
@@ -67,7 +67,7 @@
 "two-phase commit protocol (see below) across the cluster, the "
 "<literal>GlobalTransaction</literal> uniquely identifies the unit of work "
 "across a cluster."
-msgstr "Les propriétaires des verrous sont soit des transactions (l'appel est fait dans le cadre d'une transaction existante) soit des threads (aucune transaction n,est associée à l'appel). En dépit de tout cela, une transaction ou un thread est transformé en interne en une instance de <literal>GlobalTransaction</literal>, qui est utilisée en tant qu'ID unique globale pour effectuer des modifications dans le groupement. Par ex. quand on exécute un protocole de validation en deux-phases (voir ci-dessous) <literal>GlobalTransaction</literal> identifie uniquement l'unité de travail à travers le groupement."
+msgstr "Les propriétaires des verrous sont soit des transactions (l'appel est fait dans le cadre d'une transaction existante), soit des threads (fils) (aucune transaction n'est associée à l'appel). En dépit de tout cela, une transaction ou un thread est transformé en interne en une instance de <literal>GlobalTransaction</literal>, qui est utilisée en tant qu'ID unique globale pour effectuer des modifications dans le groupement. Par ex. quand on exécute un protocole de validation en deux-phases (voir ci-dessous) <literal>GlobalTransaction</literal> identifie uniquement l'unité de travail à travers le groupement."
 
 #. Tag: para
 #: Transactions.xml:24
@@ -80,7 +80,7 @@
 "has to wait until all read locks have been released. When scheduled "
 "concurrently, write locks always have precedence over read locks. Note that "
 "(if enabled) read locks can be upgraded to write locks."
-msgstr "Les verrous peuvent être lus ou écrits. Les verrous écriture sérialisent l'accès lecture et écriture, alors que les verrous lecture-seulement ne sérialisent que l'accès lecture. Lorsqu'un verrou écriture est détenu, on ne peut pas acquérir de verrous écriture ou lecture. Quand un verrou lecture est détenu, les autres peuvent acquérir les verrous lecture. Malgré tout, pour acquérir des verrous écriture, on doit attendre que tous les verrous lectures aient été libérés. Lorsqu'ils sont ordonnancés concurament, les verrous lecture sont toutjours précédent sur les verrous lecture. Notez que les verrous lecture (si activés) peuvent être mis à niveau à des verrous écriture."
+msgstr "Les verrous peuvent être lus ou écrits. Les verrous écriture sérialisent l'accès lecture et écriture, alors que les verrous lecture-seulement ne sérialisent que l'accès lecture. Lorsqu'un verrou écriture est détenu, on ne peut pas acquérir de verrous écriture ou lecture. Quand un verrou lecture est détenu, les autres peuvent acquérir les verrous lecture. Malgré tout, pour acquérir des verrous écriture, on doit attendre que tous les verrous lectures aient été libérés. Lorsqu'ils sont ordonnancés concouramment, les verrous lecture sont toujours prioritaires par rapport aux verrous lecture. Notez que les verrous lecture (si activés) peuvent être mis à niveau à des verrous écriture."
 
 #. Tag: para
 #: Transactions.xml:27
@@ -94,7 +94,7 @@
 "is then able to acquire read-locks for \"/a/b\" as well, plus a read-write "
 "lock for \"/a/b/n2\". This allows for more concurrency in accessing the "
 "cache."
-msgstr "L'utilisation des verrous lecture-écriture est utile dans le scénario suivant: considérer un arbre avec les entrées \"a/b/n1\" et /a/b/n2\". Avec les verrous-écriture, quand Tx1 accède a/b/n1\", Tx2 ne peut pas accéder \"/a/b/n2\" jusqu'à ce que Tx1 ait terminé et libéré ses verrous. Cependant, avec les verrous lecture-écriture, c'est possible, car Tx1 obtient les verrous-lecture pour \"/a/b\" et le verrou lecture-écriture de \"/a/b/n1\". Tx2 est alors capable d'obtenir des verrous-lecture pour \"a/b\" également, plus un verrou lecture-écriture pour \"/a/b/n2\". Cela permet plus de concurrence pour accéder le cache."
+msgstr "L'utilisation des verrous lecture-écriture est utile dans le scénario suivant: considérer un arbre avec les entrées \"a/b/n1\" et /a/b/n2\". Avec les verrous-écriture, quand Tx1 accède a/b/n1\", Tx2 ne peut pas accéder \"/a/b/n2\" jusqu'à ce que Tx1 ait terminé et libéré ses verrous. Cependant, avec les verrous lecture-écriture, c'est possible, car Tx1 obtient les verrous-lecture pour \"/a/b\" et le verrou lecture-écriture de \"/a/b/n1\". Tx2 est alors capable d'obtenir des verrous-lecture pour \"a/b\" également, plus un verrou lecture-écriture pour \"/a/b/n2\". Cela permet plus de concurrence pour accéder au cache."
 
 #. Tag: title
 #: Transactions.xml:33
@@ -136,7 +136,7 @@
 "NONE. No transaction support is needed. There is no locking at this level, e."
 "g., users will have to manage the data integrity. Implementations use no "
 "locks."
-msgstr "NONE. Aucun support de transaction n'est nécessaire. Il n'y a pas de verrouillage  ce niveau, par ex., les utilisateurs devront gérer l'intégrité des données. Les implémentations n'utilisent pas de verrous."
+msgstr "NONE. Aucun support de transaction n'est nécessaire. Il n'y a pas de verrouillage à ce niveau, par ex., les utilisateurs devront gérer l'intégrité des données. Les implémentations n'utilisent pas de verrous."
 
 #. Tag: para
 #: Transactions.xml:49
@@ -153,7 +153,7 @@
 "Implementations typically use an exclusive lock for writes while reads don't "
 "need to acquire a lock."
 msgstr ""
-"READ_UNCOMMITTED. Les données peuvent être lues à tout moment alors que les opérations écriture sont exclusives. Notez que ce niveau n'empêche pas les soit disant \"dirty read\" (lectures corrompues) lorsque les données modifiées en Tx1 peuvent être lues en Tx2 avant que Tx1 ne soit validé. En d'autres mots, il vous rencontrez la séquence suivante, <programlisting>\n"
+"READ_UNCOMMITTED. Les données peuvent être lues à tout moment alors que les opérations écriture sont exclusives. Notez que ce niveau n'empêche pas les soit disant \"dirty read\" (lectures corrompues) lorsque les données modifiées en Tx1 peuvent être lues en Tx2 avant que Tx1 ne soit validé. En d'autres mots, si vous rencontrez la séquence suivante, <programlisting>\n"
 "   Tx1   Tx2\n"
 "  W\n"
 "     R\n"
@@ -167,7 +167,7 @@
 "level prevents the dirty read. But it doesn&#8217;t prevent the so-called "
 "&#8216;non-repeatable read&#8217; where one thread reads the data twice can "
 "produce different results. For example, if you have the following sequence,"
-msgstr "READ_COMMITTED. Les données peuvent être lues à n'importe quel moment dans la mesure ou il n'y a pas d'écriture. Mais cela n'empêche pas la fameuse 'lecture non-répétitive' pour laquelle un thread lit les données à deux reprises et produit des résultats différents. Par exemple, si vous avez la séquence suivante,"
+msgstr "READ_COMMITTED. Les données peuvent être lues à n'importe quel moment dans la mesure où il n'y a pas d'écriture. Mais cela n'empêche pas la fameuse 'lecture non-répétitive' pour laquelle un thread lit les données à deux reprises et produit des résultats différents. Par exemple, si vous avez la séquence suivante,"
 
 #. Tag: programlisting
 #: Transactions.xml:56
@@ -201,7 +201,7 @@
 "a read-lock; this leads to nonrepeatable reads, where 2 reads of the same "
 "data might return different values. Note that, the write only applies "
 "regardless of transaction state (whether it has been committed or not)."
-msgstr "Les implémentations utilisent normalement un verrou lecture-écriture, les lectures parviennent à obtenir le verrou quand il n'y a que des lectures, les écritures doivent attendre jusqu'à ce qu'il n'y ait plus de lecteurs qui tiennent le verrou, et les lecteurs sont bloqués quand ils tentent d'obtenir le verrou jusqu'à ce qu'il n'y ait plus d'écrivains qui tiennent le verrou. Les lectures libèrent normalement le verrou-lecture lorsqu'elles ont terminé, de façon à ce qu'une lecture ultérieure des même données doive re-acquérir un verrou-lecture. Cela mène à des lectures non-répétables, ou 2 lectures des mêmes données risquent de retourner des valeurs différentes. Notez que, l'écriture s'applique indépendamment de l'état de la transaction (qu'elle ait été validée ou non)."
+msgstr "Les implémentations utilisent normalement un verrou lecture-écriture, les lectures parviennent à obtenir le verrou quand il n'y a que des lectures, les écritures doivent attendre jusqu'à ce qu'il n'y ait plus de lecteurs qui tiennent le verrou, et les lecteurs sont bloqués quand ils tentent d'obtenir le verrou jusqu'à ce qu'il n'y ait plus d'écrivains qui tiennent le verrou. Les lectures libèrent normalement le verrou-lecture lorsqu'elles ont terminé, de façon à ce qu'une lecture ultérieure des même données doive re-acquérir un verrou-lecture. Cela mène à des lectures non-répétables, où 2 lectures des mêmes données risquent de retourner des valeurs différentes. Notez que l'écriture s'applique indépendamment de l'état de la transaction (qu'elle ait été validée ou non)."
 
 #. Tag: para
 #: Transactions.xml:66
@@ -212,7 +212,7 @@
 "called \"phantom read\" where new data can be inserted into the tree from "
 "the other transaction. Implementations typically use a read-write lock. This "
 "is the default isolation level used."
-msgstr "REPEATABLE_READ. Les données peuvent être lues même s'il N,y a pas d'écriture et vice-versa. Ce niveau empêche les \"lectures non-répétables\" mais cela n'empêche pas les \"lectures fantômes\" lorsque des nouvelles données peuvent être insérées dans l'arborescence à partir d'une autre transaction. Les implémentations utilisent normalement un verrou lecture-écriture. Il s'agit du niveau d'isolation par défaut utilisé."
+msgstr "REPEATABLE_READ. Les données peuvent être lues même s'il n'y a pas d'écriture et vice-versa. Ce niveau empêche les \"lectures non-répétables\" mais cela n'empêche pas les \"lectures fantômes\" lorsque des nouvelles données peuvent être insérées dans l'arborescence à partir d'une autre transaction. Les implémentations utilisent normalement un verrou lecture-écriture. Il s'agit du niveau d'isolation utilisé par défaut."
 
 #. Tag: para
 #: Transactions.xml:71
@@ -222,7 +222,7 @@
 "writer or reader can have the lock at any given time. Locks are released at "
 "the end of the transaction. Regarded as very poor for performance and thread/"
 "transaction concurrency."
-msgstr "SERIALIZABLE. L'accès aux données est synchronisé avec des verrous exclusifs. Seul 1 écrivain ou un lecteur peut obtenir un verrou à la fois. Les verrous sont libérés en fin de transaction. Considéré inefficace pour la concurrence de transaction/thread."
+msgstr "SERIALIZABLE. L'accès aux données est synchronisé avec des verrous exclusifs. Seul 1 écrivain ou un lecteur peut obtenir un verrou à la fois. Les verrous sont libérés en fin de transaction. Considéré peu efficace pour la concurrence de transaction/thread."
 
 #. Tag: title
 #: Transactions.xml:79
@@ -245,7 +245,7 @@
 "<literal>false</literal>, insertions and removals of child nodes only "
 "require the acquisition of a <emphasis>read lock</emphasis> on the parent "
 "node."
-msgstr "Par défaut, avant d'insérer un nouveau noeud dans une arborescence, ou de supprimer un noeud existant d'une arborescence, JBoss Cache va tenter d'obtenir un verrou écriture sur le nouveau noeud parent du nouveau noeud. Cette approche considère les noeuds enfant en tant que partie intégrale de l'état d'un noeud parent. Cette approche est plus précise, au détriment de la concurrence dans le cas ou les noeuds sont fréquemment ajoutés ou supprimés. Pour les cas d'utilisation pour lesquels cette plus grande précision n'est pas nécessaire, JBoss Cache offre une option de configuration <literal>LockParentForChildInsertRemove</literal>. Si elle est configurée à <literal>false</literal>, les insertions et suppressions de noeuds enfant ne nécessitent uniquement l'acquisition d'un <emphasis>read lock</emphasis> sur le noeud-parent."
+msgstr "Par défaut, avant d'insérer un nouveau noeud dans une arborescence, ou de supprimer un noeud existant d'une arborescence, JBoss Cache va tenter d'obtenir un verrou écriture sur le nouveau noeud parent du nouveau noeud. Cette approche considère les noeuds enfant en tant que partie intégrale de l'état d'un noeud parent. Cette approche est plus précise, au détriment de la concurrence dans le cas où les noeuds sont fréquemment ajoutés ou supprimés. Pour les cas d'utilisation pour lesquels cette plus grande précision est inutile, JBoss Cache offre une option de configuration <literal>LockParentForChildInsertRemove</literal>. Si elles sont configurées à <literal>false</literal>, les insertions et suppressions de noeuds enfant ne nécessitent uniquement l'acquisition d'un <emphasis>read lock</emphasis> sur le noeud-parent."
 
 #. Tag: title
 #: Transactions.xml:88
@@ -264,7 +264,7 @@
 "locking allows for greater concurrency of threads and transactions by using "
 "a technique called data versioning, explained here. Note that isolation "
 "levels (if configured) are ignored if optimistic locking is enabled."
-msgstr "La motivation derrière un verrouillage optimiste est d'améliorer la concurrence. Lorsqu'un grand nombre de threads rencontre beaucoup de contention pour accéder è l'arborescence de données, il peut sembler inefficace de verrouiller des portions de l'arborescence - pour lecture ou écriture - pendant la durée totale de la transaction, tout comme on le fait en verrouillage pessimiste. Le verrouillage optimiste permet une plus grande concurrence de threads et de transactions en utilisant une technique qui s'appelle data versioning, qui est expliquée ici. Notez que les niveaux d'isolation (si configurés) sont ignorés si le verrouillage optimiste est activé."
+msgstr "La raison derrière un verrouillage optimiste est d'améliorer la concurrence. Lorsqu'un grand nombre de threads rencontre beaucoup de contention pour accéder à l'arborescence de données, il peut sembler inefficace de verrouiller des portions de l'arborescence - pour lecture ou écriture - pendant la durée totale de la transaction, tout comme on le fait en verrouillage pessimiste. Le verrouillage optimiste permet une plus grande concurrence de threads et de transactions en utilisant une technique qui s'appelle data versioning, qui est expliquée ici. Notez que les niveaux d'isolation (si configurés) sont ignorés quand le verrouillage optimiste est activé."
 
 #. Tag: title
 #: Transactions.xml:93
@@ -283,7 +283,7 @@
 "creates an implicit transaction and commits this transaction when the "
 "invocation completes. Each transaction maintains a transaction workspace, "
 "which contains a copy of the data used within the transaction."
-msgstr "Le verrouillage optimiste considère tous les appels de méthode comme transactionnels <footnote><para> En raison de cette exigence, vous devez toujours avoir un gestionnaire de transaction de configuré lorsque vous utilisez le verrouillage optimiste. </para> </footnote>. Meme si vous n'invoquez pas un appel dans la limite d'une transaction en cours, JBoss Cache crée une transaction implicite et valide cette transaction quand l'invocation se termine. Chaque transaction entretient un espace de travail de transaction, qui comprend une copie des données utilisées au sein de la transaction."
+msgstr "Le verrouillage optimiste considère tous les appels de méthode comme transactionnels <footnote><para> En raison de cette exigence, vous devez toujours avoir un gestionnaire de transaction de configuré lorsque vous utilisez le verrouillage optimiste. </para> </footnote>. Même si vous n'invoquez pas un appel dans la limite d'une transaction en cours, JBoss Cache crée une transaction implicite et valide cette transaction quand l'invocation se termine. Chaque transaction entretient un espace de travail de transaction, qui comprend une copie des données utilisées au sein de la transaction."
 
 #. Tag: para
 #: Transactions.xml:100
@@ -299,7 +299,7 @@
 "change it and commit before the first transaction can finish - the "
 "transaction throws a <literal>RollbackException</literal> when committing "
 "and the commit fails."
-msgstr "Par exemple, si une transaction appelle get(\"/a/b/c\"), les noeuds a,b et c sont copiés de l'arborescence de données principale et sont transferés dans l'espace de travail. Les données sont versioned et tous les appels de la transaction opèrent sur une copie des données plutôt que sur les données elle-mêmes. Quand la transaction est validée, son espace de travail est mergé à nouveau dans l'aborescence sous-jacente par les versions correspondantes. S'il existe un défaut d'adaptation - comme lorsque l'arborescence de données correspond à une version supérieure par rapport à celle de l'espace de travail, peut-être que si une autre transaction devait accéder aux mêmes données, changer là et faites la valider avant que la première transaction ne soit terminée - la transaction émet un <literal>RollbackException</literal> lorsque la validation échoue."
+msgstr "Par exemple, si une transaction appelle get(\"/a/b/c\"), les noeuds a,b et c sont copiés de l'arborescence de données principale et sont transférés dans l'espace de travail. Les données sont versionnées et tous les appels de la transaction opèrent sur une copie des données plutôt que sur les données elle-mêmes. Quand la transaction est validée, son espace de travail est émergé à nouveau dans l'aborescence sous-jacente par les versions correspondantes. S'il existe un défaut d'adaptation - comme lorsque l'arborescence de données correspond à une version supérieure par rapport à celle de l'espace de travail, peut-être que si une autre transaction devait accéder aux mêmes données, changer là et faites la valider avant que la première transaction ne soit terminée - la transaction émet un <literal>RollbackException</literal> lorsque la validation échoue."
 
 #. Tag: para
 #: Transactions.xml:103
@@ -309,7 +309,7 @@
 "only held for a very short duration - at the start of a transaction to build "
 "a workspace, and when the transaction commits and has to merge data back "
 "into the tree."
-msgstr "Le verrouillage optimiste utilise les même verrous que ceux dont on a parlé ci-dessus, mais les verrous ne sont maintenus que pour une courte durée - au début de la transaction pour construire un espace de travail, et quand la transaction est validée et doit merger des données à nouveau de retour dans l'arborescence."
+msgstr "Le verrouillage optimiste utilise les mêmes verrous que ceux évoqués ci-dessus, mais les verrous ne sont maintenus que pour une courte durée - au début de la transaction pour construire un espace de travail, et quand la transaction est validée et doit merger des données à nouveau de retour dans l'arborescence."
 
 #. Tag: para
 #: Transactions.xml:106
@@ -320,7 +320,7 @@
 "inevitable overhead and extra processing of maintaining workspaces, "
 "versioned data and validating on commit, it does buy you a near-SERIALIZABLE "
 "degree of data integrity while maintaining a very high level of concurrency."
-msgstr "Donc même si le verrouillage optimiste échoue parfois, et si les validations de version ne fonctionnent pas ou si elles vont légèrement plus doucement que le verrouillage pessimiste à cause de l'overhead inévitable et le traitement additionnel de maintient des espaces de travail, les données versionnées et la validation, il vous apporte néanmoins un degré d'intégrité de données presque-SERIALIZABLE tout en maintenant un très haut degré de concurrence."
+msgstr "Donc même si le verrouillage optimiste échoue parfois quand les validations de version ne fonctionnent pas ou si elles vont légèrement plus doucement que le verrouillage pessimiste à cause de l'inévitable surcharge et du traitement additionnel de maintient des espaces de travail, des données versionnées et de leur validation, il vous apporte néanmoins un degré d'intégrité de données presque-SERIALIZABLE tout en maintenant un très haut degré de concurrence."
 
 #. Tag: title
 #: Transactions.xml:112
@@ -374,7 +374,7 @@
 "modifications are potentially<footnote><para> Depending on whether interval-"
 "based asynchronous replication is used </para> </footnote> replicated after "
 "every change (if replication is enabled)."
-msgstr "JBoss Cache peut être configuré pour utiliser des transactions pour assembler des unités de travail, qui peuvent ensuite être répliquées en une seule unité. Sinon, si le support de transaction des désactivé, c'est l'équivalent à activer AutoCommit to pour les cas possibles ou les modifications sont potentiellement <footnote><para> suivant que la réplication asynchrone basée-intervalle est utilisée </para> </footnote> répliquées après chaque changement (si la réplication est activée)."
+msgstr "JBoss Cache peut être configuré pour utiliser des transactions pour assembler des unités de travail, qui peuvent ensuite être répliquées en une seule unité. Sinon, si le support de transaction est désactivé, c'est l'équivalent d'activer 'AutoCommit to' pour les cas possibles où les modifications sont potentiellement <footnote><para> suivant que la réplication asynchrone basée-intervalle est utilisée </para> </footnote> répliquées après chaque changement (si la réplication est activée)."
 
 #. Tag: para
 #: Transactions.xml:128
@@ -394,7 +394,7 @@
 msgid ""
 "register (if not already done) with the transaction manager to be notified "
 "when a transaction commits or is rolled back."
-msgstr "enregistrer (si ce n'est pas encore fait) vous avec le gestionnaire de transaction pour que vous puissiez être mis au courant si la transaction est validée ou si elle rool back."
+msgstr "enregistrer (si ce n'est pas encore fait) vous avec le gestionnaire de transaction pour que vous puissiez être mis au courant si la transaction est validée ou si elle reprise (rolled back)."
 
 #. Tag: para
 #: Transactions.xml:143
@@ -425,9 +425,9 @@
 msgstr ""
 "JBoss Cache est proposé avec <literal>JBossTransactionManagerLookup</literal> et "
 "<literal>GenericTransactionManagerLookup</literal>. Le "
-"<literal>JBossTransactionManagerLookup</literal> peut être relié à un serveur Jboss Application en cours d'exécution et d'extraire un <literal>TransactionManager</"
+"<literal>JBossTransactionManagerLookup</literal> peut être relié à un serveur Jboss Application en cours d'exécution et peut extraire un <literal>TransactionManager</"
 "literal> tandis que le <literal>GenericTransactionManagerLookup</literal> peut être relié aux serveurs d'application Java EE les plus populaires tout en offrant la même fonctionnalité. Une implémentation factice - "
-"<literal>DummyTransactionManagerLookup</literal> - est également proposée, utilisable pour les applications autonomes JBoss Cache et les tests d'unités exécutées en dehors du serveur d'application Java EE. Comme il est factice, il est utilisé uniquement pour les démonstrations et les tests, mais il n'est pas recommandé pour l'utilisation dans un contexte de production."
+"<literal>DummyTransactionManagerLookup</literal> - est également proposée, utilisable pour les applications autonomes JBoss Cache et les tests d'unités exécutés en dehors du serveur d'application Java EE. Comme il est factice, il est utilisé uniquement pour les démonstrations et les tests, et n'est pas recommandé pour l'utilisation dans un contexte de production."
 
 #. Tag: para
 #: Transactions.xml:149
@@ -495,7 +495,7 @@
 msgid ""
 "When a transaction rolls back, we undo the changes in the cache and release "
 "all locks."
-msgstr "Quand une transaction roll back, on supprime les changements dans le cache et on libère tous les verrous."
+msgstr "Quand une transaction est retournée (rolls back), on supprime les changements dans le cache et on libère tous les verrous."
 
 #. Tag: para
 #: Transactions.xml:162
@@ -522,7 +522,7 @@
 "initiated: a ROLLBACK message is sent to all nodes in the cluster. On "
 "reception of the ROLLBACK message, every node undoes the changes for the "
 "given transaction, and releases all locks held for the transaction."
-msgstr "Le coordinateur du protocole de validation en deux-phases atttend toutes les réponses (ou bien un timeout, suivant ce qui apparaît en premier). Si un des noeuds du groupement répond avec un FAIL (ou bien si on atteint le timeout), alors la phase rollback est initiée: un message ROLLBACK est envoyé vers tous les noeuds du groupement. Dès la réception du message ROLLBACK, chaque noeud annule les changements pour une transaction donnée, et libère tous les verrous contenus pour la transaction."
+msgstr "Le coordinateur du protocole de validation en deux-phases attend toutes les réponses (ou bien un timeout, suivant ce qui apparaît en premier). Si un des noeuds du groupement répond avec un FAIL (ou bien si on atteint le timeout), alors la phase de reprise (rollback) est initiée: un message ROLLBACK est envoyé vers tous les noeuds du groupement. Dès la réception du message ROLLBACK, chaque noeud annule les changements pour une transaction donnée, et libère tous les verrous contenus pour la transaction."
 
 #. Tag: para
 #: Transactions.xml:171
@@ -554,7 +554,7 @@
 msgid ""
 "Let's look at an example of how to use JBoss Cache in a standalone (i.e. "
 "outside an application server) fashion with dummy transactions:"
-msgstr "Etudions un exemple sur la façon d'utiliser JBoss Cache de façon autonome (commepar exemple à l'extérieur d'un serveur d'applications) avec des transactions fictives:"
+msgstr "Etudions un exemple sur la façon d'utiliser JBoss Cache de façon autonome (comme par exemple à l'extérieur d'un serveur d'applications) avec des transactions fictives:"
 
 #. Tag: programlisting
 #: Transactions.xml:182
@@ -642,5 +642,5 @@
 "exception in the methods (e.g. lock acquisition failed), or in the two-phase "
 "commit protocol applying the modifications to all nodes in the cluster, the "
 "transaction is rolled back."
-msgstr "Ensuite, on démarre le cache. Puis, on démarre une transaction (et on l'associe au thread courant en interne). Toutes les méthodes invoquées sur le cache seront maintenant collectées et ne seront appliquées que quand la transaction sera validée. Dans le cas ci-dessus, on crée un noeud \"/classes/cs-101\" et on ajoute 2 éléments sur sa map. En assumant que le cache soit configuré pour utiliser une réplication synchrone, les modifications sont répliquées en cours de validation de la transaction. S'il y a u ne exception dans les méthodes (par exe. l'acquisition du verrou échoue), ou dans le protocole de validation en deux-phases qui applique les modifications à tous les noeuds du groupement, la transaction est rolled back."
+msgstr "Ensuite, on démarre le cache. Puis, on démarre une transaction (et on l'associe au thread courant en interne). Toutes les méthodes invoquées sur le cache seront maintenant collectées et ne seront appliquées que quand la transaction sera validée. Dans le cas ci-dessus, on crée un noeud \"/classes/cs-101\" et on ajoute 2 éléments sur son schéma de correspondance (map). En assumant que le cache soit configuré pour utiliser une réplication synchrone, les modifications sont répliquées en cours de validation de la transaction. S'il y a u ne exception dans les méthodes (par exe. l'acquisition du verrou échoue), ou dans le protocole de validation en deux-phases qui applique les modifications à tous les noeuds du groupement, la transaction est retournée."
 

Modified: projects/docs/enterprise/4.3/Cache/Cache_Tree_Cache_Guide/fr-FR/Tree_Cache_Guide.po
===================================================================
--- projects/docs/enterprise/4.3/Cache/Cache_Tree_Cache_Guide/fr-FR/Tree_Cache_Guide.po	2008-09-15 00:44:53 UTC (rev 78515)
+++ projects/docs/enterprise/4.3/Cache/Cache_Tree_Cache_Guide/fr-FR/Tree_Cache_Guide.po	2008-09-15 03:19:34 UTC (rev 78516)
@@ -9,7 +9,7 @@
 "Project-Id-Version: Tree_Cache_Guide\n"
 "Report-Msgid-Bugs-To: http://bugs.kde.org\n"
 "POT-Creation-Date: 2008-05-30 04:03+0000\n"
-"PO-Revision-Date: 2008-09-04 14:26+1000\n"
+"PO-Revision-Date: 2008-09-15 12:35+1000\n"
 "Last-Translator: Corina Roe <croe at redhat.com>\n"
 "Language-Team: French <i18 at redhat.com>\n"
 "MIME-Version: 1.0\n"
@@ -76,7 +76,7 @@
 "Si vous avez des questions, utilisez le forum d'utilisateurs <ulink url=\"http://www.jboss.com/index.html?"
 "module=bb&amp;op=viewforum&amp;f=157\"> </ulink> lié au site Web "
 "<ulink url=\"http://labs.jboss.com/jbosscache\"> </"
-"ulink> . Nous proposons également un mécanisme de suivi des rapports de bogage et de demandes de fonctionalités sur le lien JBoss JIRA suivant <ulink url=\"http://jira.jboss.com\"></ulink> . Si vous êtes intéressés par le développement de JBoss Cache ou de traduire cette documentation en d'autres langues, faîtes-nous le savoir. Veuillez alors soumettre un message dans le forum de l'utilisateur ou biencontactez-nous sur la liste de messagerie des développeurs suivante <ulink url=\"http://lists.jboss.org\"> </ulink> ."
+"ulink> . Nous proposons également un mécanisme de suivi des rapports de bogage et de demandes de fonctionalités sur le lien JBoss JIRA suivant <ulink url=\"http://jira.jboss.com\"></ulink> . Si vous êtes intéressés par le développement de JBoss Cache ou de traduire cette documentation en d'autres langues, faîtes-nous le savoir. Veuillez alors soumettre un message dans le forum de l'utilisateur ou bien contactez-nous sur la liste de messagerie des développeurs suivante <ulink url=\"http://lists.jboss.org\"> </ulink> ."
 
 #. Tag: para
 #: Tree_Cache_Guide.xml:24

Modified: projects/docs/enterprise/4.3/Cache/Cache_Tree_Cache_Guide/fr-FR/Treecache_marshaller.po
===================================================================
--- projects/docs/enterprise/4.3/Cache/Cache_Tree_Cache_Guide/fr-FR/Treecache_marshaller.po	2008-09-15 00:44:53 UTC (rev 78515)
+++ projects/docs/enterprise/4.3/Cache/Cache_Tree_Cache_Guide/fr-FR/Treecache_marshaller.po	2008-09-15 03:19:34 UTC (rev 78516)
@@ -9,7 +9,7 @@
 "Project-Id-Version: Treecache_marshaller\n"
 "Report-Msgid-Bugs-To: http://bugs.kde.org\n"
 "POT-Creation-Date: 2008-05-30 04:03+0000\n"
-"PO-Revision-Date: 2008-09-10 13:56+1000\n"
+"PO-Revision-Date: 2008-09-15 13:17+1000\n"
 "Last-Translator: Corina Roe <croe at redhat.com>\n"
 "Language-Team: French <i18 at redhat.com>\n"
 "MIME-Version: 1.0\n"
@@ -34,7 +34,7 @@
 "<literal>TreeCacheMarshaller</literal>."
 msgstr ""
 "Au lieu d'utiliser la sérialisation Java standard pour sérialiser les objets <literal>java."
-"lang.reflect.Method</literal> et leurs paramètres quand les caches éloignés communiquent entre eux pour répliquer les données, JBoss Cache utilise son propre mécanisme pour marshall et unmarshall des données, qui se nomme <literal>TreeCacheMarshaller</literal>."
+"lang.reflect.Method</literal> et leurs paramètres quand les caches éloignés communiquent entre eux pour répliquer les données, JBoss Cache utilise son propre mécanisme pour ordonnancer (marshalling) et désordonnancer (unmarshalling) les données, qui se nomme <literal>TreeCacheMarshaller</literal>."
 
 #. Tag: para
 #: Treecache_marshaller.xml:14
@@ -51,7 +51,7 @@
 "to use different classloaders on a per-region basis by allowing application "
 "code to register a classloader that should be used to handle replication for "
 "a portion of the tree."
-msgstr "En plus de procurer les améliorations de performance et d'éfficacité par rapport à la sérialisation Java standard, le <literal>TreeCacheMarshaller</literal> performe une autre fonction également. Pour déssérialiser un objet répliqué à partir d'un cache éloigné, l'instance d'un cache doit pouvoir avoir accès au classloader qui détermine la classe de l'objet. C'est simple si le classloader du cache peut accéder aux classes requises, mais pour les cas ou le JBoss Cache est utilisé comme service de support de clients qui utilisent des classloaders différents, le <literal>TreeCacheMarshaller</literal> peut être configuré pour utiliser les classloader différents sur la base d'une région en permettant au code d'application d'enregistrer un classloader qui devrait être utilisé pour gérer la replication pour une portion de l'arborescence."
+msgstr "En plus de procurer les améliorations de performance et d'efficacité par rapport à la sérialisation Java standard, le <literal>TreeCacheMarshaller</literal> performe une autre fonction également. Pour déssérialiser un objet répliqué à partir d'un cache éloigné, l'instance d'un cache doit pouvoir avoir accès au classloader qui détermine la classe de l'objet. C'est simple si le classloader du cache peut accéder aux classes requises, mais pour les cas où le JBoss Cache est utilisé comme service de support de clients qui utilisent des classloaders différents, le <literal>TreeCacheMarshaller</literal> peut être configuré pour utiliser les classloader différents sur la base d'une région, en permettant au code d'application d'enregistrer un classloader qui devrait être utilisé pour gérer la replication pour une portion de l'arborescence."
 
 #. Tag: title
 #: Treecache_marshaller.xml:18
@@ -183,7 +183,7 @@
 "classloader-based marshalling should be used. This property should be set as "
 "part of normal cache configuration, typically in the cache's XML "
 "configuration file:"
-msgstr "La propriété <literal>UseRegionBasedMarshalling</literal> contrôle si un marshalling basé-classloader doit être utilisé. Cette propriété devrait être déterminée dans le cadre de la configuration normale du cache, normalement dans le fichier de configuration XML du cache."
+msgstr "La propriété <literal>UseRegionBasedMarshalling</literal> contrôle si un ordonnancement basé-classloader doit être utilisé. Cette propriété devrait être déterminée dans le cadre de la configuration normale du cache, normalement dans le fichier de configuration XML du cache."
 
 #. Tag: programlisting
 #: Treecache_marshaller.xml:26
@@ -204,7 +204,7 @@
 msgstr ""
 "Après que<literal>UseRegionBasedMarshalling</literal> ait été fixé à "
 "<literal>true</literal> (vrai), le code d'application peut appeler le"
-"<literal>registerClassLoader</literal> pour qu'il puisse associer un classloader à une portion du cache enracinée dans un FQN particullier. Une fois enregistré, le classloader sera utilisé pour unmarshal tout traffic de réplication relatif à  un noeud identifié par le FQN ou à n'importe quel de ses descendants."
+"<literal>registerClassLoader</literal> pour qu'il puisse associer un classloader à une portion du cache enracinée dans un FQN particulier. Une fois enregistré, le classloader sera utilisé pour désordonnancer tout trafic de réplication relatif à un noeud identifié par le FQN ou à n'importe quel de ses descendants."
 
 #. Tag: para
 #: Treecache_marshaller.xml:30
@@ -225,7 +225,7 @@
 "be thrown if an attempt is made to register classloader <literal>Y</literal> "
 "for FQN <literal>/a/b</literal>."
 msgstr ""
-"Notez qu'il est illégal d'enregistrer un classloader pour un FQN qui est un descendant d'un FQN pour lequel in classloader a déjà été enregistré. Par exemple, si le classloader <literal>X</literal> est enregistré pour le FQN "
+"Notez qu'il est illégal d'enregistrer un classloader pour un FQN qui est un descendant d'un FQN pour lequel un classloader a déjà été enregistré. Par exemple, si le classloader <literal>X</literal> est enregistré pour le FQN "
 "<literal>/a</literal>, a <literal>RegionNameConflictException</literal> sera émis pour tenter d'enregistrer le classloader <literal>Y</literal> "
 "pour FQN <literal>/a/b</literal>."
 
@@ -256,7 +256,7 @@
 "The result of this is that it is difficult or impossible to register all "
 "required classloaders before a cache is started. For example, consider the "
 "following scenario:"
-msgstr "L'API de base dont on a parlé ci-dessus est utile, mais dans des situations ou des applications qui comportent des classloaders différents partagent un cache, le cycle de vie de ces applications sera typiquement différent de celui du cache. Par conséquence, il est difficile, voire impossible d'enregistrer tous les classloaders requis avant qu'un cache ne démarre. Par exemple, considerez le scénario suivant:"
+msgstr "L'API de base dont on a parlé ci-dessus est utile, mais dans des situations où des applications qui comportent des classloaders différents partagent un cache, le cycle de vie de ces applications sera typiquement différent de celui du cache. Par conséquence, il est difficile, voire impossible, d'enregistrer tous les classloaders requis avant qu'un cache ne démarre. Considérez, par exemple, le scénario suivant:"
 
 #. Tag: para
 #: Treecache_marshaller.xml:48
@@ -303,7 +303,7 @@
 "Furthermore, if any objects had been added to server A before server B was "
 "started, the initial transfer of state from A to B would have failed as "
 "well, as B would not be able to unmarshal the transferred objects."
-msgstr "De plus, si un objet avait été ajouté au serveur A avant que le serveur B n'ai démarré, le transfert initial d'un état de A à B aurait échoué également, car B n'aurait pas pu unmarshall les objets transférés."
+msgstr "De plus, si un objet avait été ajouté au serveur A avant que le serveur B n'ait démarré, le transfert initial d'un état de A à B aurait échoué également, car B n'aurait pas pu désordonnancer les objets transférés."
 
 #. Tag: para
 #: Treecache_marshaller.xml:69
@@ -314,7 +314,7 @@
 "tree. That portion of the tree is considered \"inactive\". After the needed "
 "classloader has been registered, the portion of the tree can be \"activated"
 "\". Activation causes the following events to occur:"
-msgstr "Pour résoudre ce problème, si le marshalling basé-région est utilisé, une instance cache peut être configurée pour ignorer les événements de replication pour une portion de l'arborescence. Cette portion de l'arborescence est considérée comme \"inactive\". Après que le classloader qu'il faut ait été enregistré, la portion de l'arborescence peut être \"activée\". L'activation entraîne l'apparition des erreurs suivantes:"
+msgstr "Pour résoudre ce problème, si l'ordonnancement basé-région est utilisé, une instance cache peut être configurée pour ignorer les événements de replication pour une portion de l'arborescence. Cette portion de l'arborescence est considérée comme \"inactive\". Après que le classloader qu'il faut ait été enregistré, la portion de l'arborescence peut être \"activée\". L'activation entraîne l'apparition des erreurs suivantes:"
 
 #. Tag: para
 #: Treecache_marshaller.xml:74
@@ -322,7 +322,7 @@
 msgid ""
 "Any existing state for that portion of the tree is transferred from another "
 "node in the cluster and integrated into the local tree."
-msgstr "Un état existant pour cette portion de l'arborescence est transferé à partir d'un autre noeud du groupement et intégré dans l'arborescence locale."
+msgstr "Un état existant pour cette portion de l'arborescence est transféré à partir d'un autre noeud du groupement et intégré dans l'arborescence locale."
 
 #. Tag: para
 #: Treecache_marshaller.xml:77
@@ -330,7 +330,7 @@
 msgid ""
 "TreeCacheMarshaller begins normal handling of replication traffic related to "
 "the portion of the tree."
-msgstr "TreeCacheMarshaller commence une gestion normale du traffic de replication, relatif à une portion de l'arborecence."
+msgstr "TreeCacheMarshaller commence une gestion normale du trafic de replication, relatif à une portion de l'arborescence."
 
 #. Tag: para
 #: Treecache_marshaller.xml:80
@@ -339,7 +339,7 @@
 "In addition to the basic marshalling related API discussed above, TreeCache "
 "exposes the following API related to activating and inactivating portions of "
 "the cache:"
-msgstr "En plus du marshalling de base relatif à l'API dont on a parlé ci-dessus, TreeCache expose l'API suivant relatif à l'activation et l'inactivation des portions du cache:"
+msgstr "En plus de l'ordonnancement de base relatif à l'API dont on a parlé ci-dessus, TreeCache expose l'API suivant relatif à l'activation et l'inactivation des portions du cache:"
 
 #. Tag: programlisting
 #: Treecache_marshaller.xml:83
@@ -548,7 +548,7 @@
 "local activity on an inactive region, but, as discussed above "
 "<literal>activateRegion()</literal> will throw an exception if it discovers "
 "data in a region that is being activated."
-msgstr "Il est important que comprendre que lorsqu'une région de l'arborescence est marquée comme inactive, cela signifie simplement que le trafic de réplication provenant des autres noeuds du groupement vers cette portion de l'arborescence, sera ignoré. Il est toujours possible techniquement pour les objets d'être placés dans la portion inactive de l'arborescence localement (via un appel <literal>put</literal>), et une telle activité locale sera répliquée aux autres noeuds. TreeCache n'empêchera pas ce genre d'activité locale sur une région inactive, mais, comme expliqué ci-dessus, <literal>activateRegion()</literal> va émettre un exception s'il découvre des données dans une région qui est activée."
+msgstr "Il est important que comprendre que lorsqu'une région de l'arborescence est marquée comme inactive, cela signifie simplement que le trafic de réplication provenant des autres noeuds du groupement vers cette portion de l'arborescence, sera ignoré. Il est toujours possible techniquement pour les objets d'être placés dans la portion inactive de l'arborescence localement (via un appel <literal>put</literal>), et une telle activité locale sera répliquée aux autres noeuds. TreeCache n'empêchera pas ce genre d'activité locale sur une région inactive, mais, comme expliqué ci-dessus, <literal>activateRegion()</literal> va émettre une exception s'il découvre des données dans une région qui est activée."
 
 #. Tag: title
 #: Treecache_marshaller.xml:101
@@ -574,7 +574,7 @@
 msgid ""
 "First, the XML configuration file for the shared cache service would be "
 "configured as follows (only relevant portions are shown):"
-msgstr "Tout d'abord, le fichier de configuration XML du service cache partagé serait configuré comme suit (on ne montre que les portions qui nous interessent):"
+msgstr "Tout d'abord, le fichier de configuration XML du service cache partagé serait configuré comme suit (on ne montre que les portions qui nous intéressent):"
 
 #. Tag: programlisting
 #: Treecache_marshaller.xml:108
@@ -750,7 +750,7 @@
 "isn't leaked via a reference to it held by TreeCacheMarshaller)."
 msgstr ""
 "Le listener fait usage de la classe d'utilitaire <literal>MBeanProxyExt</"
-"literal> pour trouver le TreeCache dans JMX et créer in proxy, (voir la section \"Running and using TreeCache inside JBoss\" ci-dessous pour davantage d'informations sur la façon d'accéder un TreeCache). Il enregistre ensuite son classloader avec le cache et active sa région. Quand le webapp est détruit, il inactive sa région et désenregistre son classloader (assurant ainsi que le classloader n'a pas fui  via une référence qui s'y rapporte et contenue dans TreecacheMarshaller)."
+"literal> pour trouver le TreeCache dans JMX et créer in proxy, (voir la section \"Running and using TreeCache inside JBoss\" ci-dessous pour davantage d'informations sur la façon d'accéder un TreeCache). Il enregistre ensuite son classloader avec le cache et active sa région. Quand le webapp est détruit, il inactive sa région et désenregistre son classloader (assurant ainsi que le classloader n'a pas fui via une référence qui s'y rapporte et contenue dans TreecacheMarshaller)."
 
 #. Tag: para
 #: Treecache_marshaller.xml:116
@@ -778,7 +778,7 @@
 "literal> interface. It additionally specifies the following methods needed "
 "to support the partial state transfer that occurs when a region is activated:"
 msgstr ""
-"L'API activateRegion()/inactivateRegion() peut être utilisée en conjonction avec un CacheLoader également, mais seulement si l'implémentation du cache loader implémente l'interface <literal>org.jboss.cache.loader.ExtendedCacheLoader</"
+"L'API activateRegion()/inactivateRegion() peut être utilisé en conjonction avec un CacheLoader également, mais seulement si l'implémentation du cache loader implémente l'interface <literal>org.jboss.cache.loader.ExtendedCacheLoader</"
 "literal>. Il s'agit d'une sous-interface de l'interface usuelle <literal>CacheLoader</"
 "literal>. Elle spécifie en plus les méthodes suivantes qui sont nécessaires pour prendre en charge le transfert d'état qui a lieu quand une région est activée:"
 
@@ -895,7 +895,7 @@
 "method ids for known methods and magic numbers for known internal class "
 "types which drastically reduces the size of calls to remote caches, greatly "
 "improving throughput and reducing the overhead of Java serialization."
-msgstr "Pour réussir les gains de performance et d'efficacité, le <literal>TreeCacheMarshaller</literal> utilise un nombre de techniques, y compris des méthodes ids pour des méthodes connues et des nombres magiques pour des types de classes internes connues, ce qui réduit drastiquement la taille des appels vers les caches éloignés, améliorant ainsi considérablement le débit de réduisant le temps système de la sérialisation Java."
+msgstr "Pour réussir les gains de performance et d'efficacité, le <literal>TreeCacheMarshaller</literal> utilise un nombre de techniques, y compris des méthodes ids pour des méthodes connues et des nombres magiques pour des types de classes internes connues, ce qui réduit dramatiquement la taille des appels vers les caches éloignés, améliorant ainsi considérablement le débit de réduisant le temps système de la sérialisation Java."
 
 #. Tag: para
 #: Treecache_marshaller.xml:139
@@ -913,7 +913,7 @@
 msgstr ""
 "Pour accélérer les choses, le <literal>TreeCacheMarshaller</literal> utiliser "
 "<ulink url=\"http://labs.jboss.org/portal/index.html?ctrl:id=page.default."
-"info&amp;project=serialization\">JBoss Serialization</ulink>, un remplacement très efficace pour les classes définies par l'utilisateur. La serialisation JBoss est activée et toujours utilisée par défaut, quoique cela puisse être désactivé, entraînant le marshalling des classes définies par l'utilisateur pour revenir à la sérialisation Java. La sérialisation JBoss est désactivée en passant la variable d'environnement <literal>-Dserialization.jboss=false</literal> dans votre JVM."
+"info&amp;project=serialization\">JBoss Serialization</ulink>, un remplacement très efficace pour les classes définies par l'utilisateur. La sérialisation JBoss est activée et toujours utilisée par défaut, quoique cela puisse être désactivé, entraînant le marshalling des classes définies par l'utilisateur pour revenir à la sérialisation Java. La sérialisation JBoss est désactivée en passant la variable d'environnement <literal>-Dserialization.jboss=false</literal> dans votre JVM."
 
 #. Tag: title
 #: Treecache_marshaller.xml:145
@@ -936,7 +936,7 @@
 "moved to a much more efficient and sophisticated marshalling mechanism."
 msgstr ""
 "Marshalling est maintenant contrôlé dans les versions de JBoss Cache. Toutes les communications entre les caches contiennent une version <literal>courte</literal> qui permet aux instances de JBoss Cache qui appartiennent à différentes versions de communiquer entre elles puisque, de toutes façons, ces versions utilisaient toutes une simple sérialisation des objets <literal>org.jgroups."
-"MethodCall</literal> , entendu qu'elles utilisent toutes la même version de JGroups. Ce prérequis (qui est plutôt une exigence de la couche de messagerie JGroups par rapport à JBoss Cache) existe toujours, même si avec JBoss Cache 1.4.0, nous a évolué vers un mécanisme de marshalling plus efficace et plus sophistiqué."
+"MethodCall</literal> , entendu qu'elles utilisent toutes la même version de JGroups. Ce prérequis (qui est plutôt une exigence de la couche de messagerie JGroups par rapport à JBoss Cache) existe toujours, même si avec JBoss Cache 1.4.0, nous avons évolué vers un mécanisme d'ordonnancement (marshalling) plus efficace et plus sophistiqué."
 
 #. Tag: para
 #: Treecache_marshaller.xml:149
@@ -947,7 +947,7 @@
 "and future releases to marshall data in a format that is compatible with "
 "older versions, however, you would have to start JBoss Cache with the "
 "following configuration attribute:"
-msgstr "Jboss Cache 1.4.0 et les versions à venir de JBoss Cache seront toujours en mesure de unmarshall des données des versions antérieurs de JBoss Cache. Pour JBoss Cache 1.4.0 et versions supérieures, cependant, vous devrez démarrer JBoss Cache avec l'attribut de configuration suivant:"
+msgstr "Jboss Cache 1.4.0 et les versions à venir de JBoss Cache seront toujours en mesure de désordonner des données des versions antérieures de JBoss Cache. Pour JBoss Cache 1.4.0 et versions supérieures, cependant, vous devrez démarrer JBoss Cache avec l'attribut de configuration suivant:"
 
 #. Tag: programlisting
 #: Treecache_marshaller.xml:150