Remplacement de déclencheur par trigger dans ddl.xml

Il reste beaucoup de fichiers contenant ce mot.

postgresql/ddl.xml

@@ -12,7 +12,7 @@
   L'organisation des tables dans des schémas et l'attribution de privilèges
   sur les tables sont ensuite décrites. Pour finir, d'autres fonctionnalités,
   telles que l'héritage, le partitionnement de tables, les vues, les fonctions
-  et les déclencheurs sont passés en revue.
+  et les triggers sont passés en revue.
  </para>
 
  <sect1 id="ddl-basics">
@@ -3740,7 +3740,7 @@ LANGUAGE plpgsql;
 
       <para>
        Après avoir créé la fonction, nous créons le trigger qui appelle
-       la fonction de déclencheur&nbsp;:
+       la fonction trigger&nbsp;:
 
        <programlisting>
 CREATE TRIGGER insert_mesure_trigger
@@ -3781,7 +3781,7 @@ $$
 LANGUAGE plpgsql;
        </programlisting>
 
-       La définition du déclencheur est la même qu'avant. Notez que chaque
+       La définition du trigger est la même qu'avant. Notez que chaque
        test <literal>IF</literal> doit correspondre exactement à la
        contrainte <literal>CHECK</literal> de la table fille correspondante.
       </para>
@@ -3960,10 +3960,10 @@ ANALYZE mesure;
 
      <listitem>
       <para>
-       Des déclencheurs ou des règles seront nécessaires pour rediriger les
+       Des triggers ou des règles seront nécessaires pour rediriger les
        lignes vers la table fille voulue, à moins que l'application ne soit
        explicitement au courant du schéma de partitionnement. Les
-       déclencheurs peuvent être compliqués à écrire, et seront bien plus
+       triggers peuvent être compliqués à écrire, et seront bien plus
        lents que la redirection de ligne effectuée en interne par le
        partitionnement déclaratif.
       </para>
@@ -4083,7 +4083,7 @@ EXPLAIN SELECT count(*) FROM mesure WHERE date_trace &gt;= DATE '2008-01-01';
        Pendant l'exécution effective du plan d'exécution. L'élagage des partitions
        peut également être effectué pour supprimer des partitions en utilisant
        des valeurs qui ne sont connues que pendant l'exécution de la requête.
-       Cela inclut les valeurs des sous-requêtes et des paramètres issus 
+       Cela inclut les valeurs des sous-requêtes et des paramètres issus
        de l'exécution, comme des jointures par boucle imbriquée
        (<literal>nested loop join</literal>) paramétrées.
        Comme la valeur de ces paramètres peut changer plusieurs fois pendant
@@ -4197,7 +4197,7 @@ EXPLAIN SELECT count(*) FROM mesure WHERE date_trace &gt;= DATE '2008-01-01';
      d'intervalle simples lors de partitionnement par intervalles sont
      recommandées, comme illustré dans les exemples précédents. Une
      règle générale est que les contraintes de partitionnement ne
-     doivent contenir que des comparaisons entre les colonnes partitionnées 
+     doivent contenir que des comparaisons entre les colonnes partitionnées
      et des constantes, à l'aide d'opérateurs utilisables
      par les index B-tree, car seules les colonnes indexables avec un index
      B-tree sont autorisées dans la clé de partitionnement.
@@ -4411,7 +4411,7 @@ EXPLAIN SELECT count(*) FROM mesure WHERE date_trace &gt;= DATE '2008-01-01';
 
  <listitem>
   <para>
-   Déclencheurs et règles de réécriture
+   Triggers et règles de réécriture
   </para>
  </listitem>
 </itemizedlist>
@@ -4438,7 +4438,7 @@ EXPLAIN SELECT count(*) FROM mesure WHERE date_trace &gt;= DATE '2008-01-01';
 <para>
  Lorsque des structures de base complexes sont créées qui impliquent
  beaucoup de tables avec des contraintes de clés étrangères, des
- vues, des déclencheurs, des fonctions, etc., un réseau de dépendances entre
+ vues, des triggers, des fonctions, etc., un réseau de dépendances entre
  les objets est implicitement créé.
  Par exemple, une table avec une contrainte de clé étrangère dépend
  de la table à laquelle elle fait référence.