[Trad] [svn:pgfr] r1306 - traduc/trunk/postgresql
admin at listes.postgresql.fr
admin at listes.postgresql.fr
Jeu 23 Avr 23:59:12 CEST 2009
Author: gleu
Date: 2009-04-23 23:59:12 +0200 (Thu, 23 Apr 2009)
New Revision: 1306
Modified:
traduc/trunk/postgresql/auto-explain.xml
traduc/trunk/postgresql/citext.xml
Log:
Traduction 8.4 : travail de Florence Cousin.
Modified: traduc/trunk/postgresql/auto-explain.xml
===================================================================
--- traduc/trunk/postgresql/auto-explain.xml 2009-04-23 21:58:48 UTC (rev 1305)
+++ traduc/trunk/postgresql/auto-explain.xml 2009-04-23 21:59:12 UTC (rev 1306)
@@ -1,160 +1,171 @@
-<!-- $PostgreSQL: pgsql/doc/src/sgml/auto-explain.sgml,v 1.3 2009-01-02 01:16:02 tgl Exp $ -->
+<?xml version="1.0" encoding="ISO-8859-15"?>
+<!-- Dernière modification
+ le $Date: 2009-04-20 23:21:57 +0200 (lun 20 avr 2009) $
+ par $Author: gleu $
+ révision $Revision: 1300 $ -->
<sect1 id="auto-explain">
- <title>auto_explain</title>
-
- <indexterm zone="auto-explain">
- <primary>auto_explain</primary>
- </indexterm>
-
- <para>
- The <filename>auto_explain</filename> module provides a means for
- logging execution plans of slow statements automatically, without
- having to run <xref linkend="sql-explain" endterm="sql-explain-title"/>
- by hand. This is especially helpful for tracking down un-optimized queries
- in large applications.
- </para>
-
- <para>
- The module provides no SQL-accessible functions. To use it, simply
- load it into the server. You can load it into an individual session:
-
- <programlisting>
-LOAD 'auto_explain';
- </programlisting>
-
- (You must be superuser to do that.) More typical usage is to preload
- it into all sessions by including <literal>auto_explain</literal> in
- <xref linkend="guc-shared-preload-libraries"/> in
- <filename>postgresql.conf</filename>. Then you can track unexpectedly slow queries
- no matter when they happen. Of course there is a price in overhead for
- that.
- </para>
-
- <sect2>
- <title>Configuration parameters</title>
-
- <para>
- There are several configuration parameters that control the behavior of
- <filename>auto_explain</filename>. Note that the default behavior is
- to do nothing, so you must set at least
- <varname>auto_explain.log_min_duration</varname> if you want any results.
- </para>
-
- <variablelist>
- <varlistentry>
- <term>
- <varname>auto_explain.log_min_duration</varname> (<type>integer</type>)
- </term>
- <indexterm>
- <primary><varname>auto_explain.log_min_duration</varname> configuration parameter</primary>
- </indexterm>
- <listitem>
- <para>
- <varname>auto_explain.log_min_duration</varname> is the minimum statement
- execution time, in milliseconds, that will cause the statement's plan to
- be logged. Setting this to zero logs all plans. Minus-one (the default)
- disables logging of plans. For example, if you set it to
- <literal>250ms</literal> then all statements that run 250ms or longer
- will be logged. Only superusers can change this setting.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term>
- <varname>auto_explain.log_analyze</varname> (<type>boolean</type>)
- </term>
- <indexterm>
- <primary><varname>auto_explain.log_analyze</varname> configuration parameter</primary>
- </indexterm>
- <listitem>
- <para>
- <varname>auto_explain.log_analyze</varname> causes <command>EXPLAIN
- ANALYZE</command>
- output, rather than just <command>EXPLAIN</command> output, to be printed
- when an execution plan is logged. This parameter is off by default.
- Only superusers can change this setting.
- </para>
- <note>
- <para>
- When this parameter is on, per-plan-node timing occurs for all
- statements executed, whether or not they run long enough to actually
- get logged. This can have extremely negative impact on performance.
- </para>
- </note>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term>
- <varname>auto_explain.log_verbose</varname> (<type>boolean</type>)
- </term>
- <indexterm>
- <primary><varname>auto_explain.log_verbose</varname> configuration parameter</primary>
- </indexterm>
- <listitem>
- <para>
- <varname>auto_explain.log_verbose</varname> causes <command>EXPLAIN
- VERBOSE</command>
- output, rather than just <command>EXPLAIN</command> output, to be printed
- when an execution plan is logged. This parameter is off by default.
- Only superusers can change this setting.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term>
- <varname>auto_explain.log_nested_statements</varname> (<type>boolean</type>)
- </term>
- <indexterm>
- <primary><varname>auto_explain.log_nested_statements</varname> configuration parameter</primary>
- </indexterm>
- <listitem>
- <para>
- <varname>auto_explain.log_nested_statements</varname> causes nested
- statements (statements executed inside a function) to be considered
- for logging. When it is off, only top-level query plans are logged. This
- parameter is off by default. Only superusers can change this setting.
- </para>
- </listitem>
- </varlistentry>
- </variablelist>
-
- <para>
- In order to set these parameters in your
- <filename>postgresql.conf</filename> file,
- you will need to add <literal>auto_explain</literal> to
- <xref linkend="guc-custom-variable-classes"/>. Typical usage might be:
- </para>
-
- <programlisting>
-# postgresql.conf
-shared_preload_libraries = 'auto_explain'
-
-custom_variable_classes = 'auto_explain'
-auto_explain.log_min_duration = '3s'
- </programlisting>
- </sect2>
-
- <sect2>
- <title>Example</title>
-
- <programlisting>
- postgres=# LOAD 'auto_explain';
- postgres=# SET auto_explain.log_min_duration = 0;
- postgres=# SELECT count(*)
- FROM pg_class, pg_index
- WHERE oid = indrelid AND indisunique;
- </programlisting>
-
- <para>
- This might produce log output such as:
- </para>
-
- <programlisting><![CDATA[
- LOG: duration: 0.986 ms plan:
+ <title>auto_explain</title>
+
+ <indexterm zone="auto-explain">
+ <primary>auto_explain</primary>
+ </indexterm>
+
+ <para>
+ Le module <filename>auto_explain</filename> fournit un moyen de tracer les
+ plans d'exécution des requêtes lentes automatiquement, sans devoir lancer
+ <xref linkend="sql-explain" endterm="sql-explain-title"/>
+ manuellement. C'est particulièrement utile pour repérer les requêtes
+ non optimisées sur de grosses applications.
+ </para>
+
+ <para>
+ Le module ne fournit pas de fonctions accessibles par SQL.
+ Pour l'utiliser, chargez-le simplement sur le serveur.
+ Vous pouvez le charger dans une session individuelle :
+
+ <programlisting>
+ LOAD 'auto_explain';
+ </programlisting>
+
+ (Vous devez être le super-utilisateur pour faire cela.)
+ Un usage plus caractéristique est de le précharger dans toutes les sessions
+ en incluant <literal>auto_explain</literal> dans
+ <xref linkend="guc-shared-preload-libraries"/> dans le fichier
+ <filename>postgresql.conf</filename>. Ensuite vous pouvez pister les requêtes
+ étonnament lentes, quel que soit le moment où cela se produit. Évidemment, il y a un prix
+ à payer pour cela.
+ </para>
+
+ <sect2>
+ <title>Paramètres de configuration</title>
+
+ <para>
+ Il y a plusieurs paramètres de configuration qui contrôlent le comportement
+ d'<filename>auto_explain</filename>. Notez que le comportement par défaut est
+ de ne rien faire. Vous devez donc préciser au moins
+ <varname>auto_explain.log_min_duration</varname> si vous voulez un résultat.
+ </para>
+
+ <variablelist>
+ <varlistentry>
+ <term>
+ <varname>auto_explain.log_min_duration</varname> (<type>integer</type>)
+ </term>
+ <indexterm>
+ <primary>paramètre de configuration <varname>auto_explain.log_min_duration</varname></primary>
+ </indexterm>
+ <listitem>
+ <para>
+ <varname>auto_explain.log_min_duration</varname> est la durée minimale
+ d'exécution de requête à partir de laquelle le plan d'exécution
+ sera tracé. Son unité est la millisecondes. Le positionner à zéro trace
+ tous les plans. -1 (la valeur par défaut) désactive l'écriture des plans. Par
+ exemple, si vous le positionnez à <literal>250ms</literal>, alors
+ tous les ordres qui durent 250 ms ou plus seront tracés. Seuls les
+ super-utilisateurs peuvent modifier ce paramétrage.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>
+ <varname>auto_explain.log_analyze</varname> (<type>boolean</type>)
+ </term>
+ <indexterm>
+ <primary>paramètre de configuration <varname>auto_explain.log_analyze</varname></primary>
+ </indexterm>
+ <listitem>
+ <para>
+ <varname>auto_explain.log_analyze</varname> entraîne
+ l'écriture du résultat de <command>EXPLAIN ANALYZE</command>,
+ à la place du résultat de <command>EXPLAIN</command>,
+ lorsqu'un plan d'exécution est tracé.
+ Ce paramètre est désactivé par défaut.
+ Seuls les super-utilisateurs peuvent modifier ce paramètre.
+ </para>
+ <note>
+ <para>
+ Lorsque ce paramètre est activé, un chronométrage par
+ nœud du plan est calculé pour
+ tous les ordres exécutés, qu'ils durent suffisamment longtemps pour être réellement tracés, ou non.
+ Ceci peut avoir des conséquences très négatives sur les performances.
+ </para>
+ </note>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>
+ <varname>auto_explain.log_verbose</varname> (<type>boolean</type>)
+ </term>
+ <indexterm>
+ <primary>paramètre de configuration <varname>auto_explain.log_verbose</varname></primary>
+ </indexterm>
+ <listitem>
+ <para>
+ <varname>auto_explain.log_verbose</varname> entraîne l'écriture
+ du résultat de <command>EXPLAIN VERBOSE</command>
+ au lieu du résultat de la commande simple <command>EXPLAIN</command>
+ lorsqu'un plan d'exécution
+ est tracé. Ce paramètre est désactivé par défaut. Seuls les
+ superutilisateurs peuvent modifier ce paramètre.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>
+ <varname>auto_explain.log_nested_statements</varname> (<type>boolean</type>)
+ </term>
+ <indexterm>
+ <primary>paramètre de configuration <varname>auto_explain.log_nested_statements</varname></primary>
+ </indexterm>
+ <listitem>
+ <para>
+ <varname>auto_explain.log_nested_statements</varname> entraîne
+ la prise en compte des ordres imbriqués
+ (les requêtes exécutées dans une fonction) dans la trace.
+ Quand il est désactivé, seuls les plans d'exécution
+ de plus haut niveau sont tracés. Ce paramètre est désactivé par
+ défaut. Seuls les super-utilisateurs peuvent modifier ce paramètre.
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+
+ <para>
+ Afin de positionner ces paramètres dans votre fichier
+ <filename>postgresql.conf</filename>,
+ vous devez ajouter <literal>auto_explain</literal> à
+ <xref linkend="guc-custom-variable-classes"/>. Un usage classique serait :
+ </para>
+
+ <programlisting>
+ # postgresql.conf
+ shared_preload_libraries = 'auto_explain'
+
+ custom_variable_classes = 'auto_explain'
+ auto_explain.log_min_duration = '3s'
+ </programlisting>
+ </sect2>
+
+ <sect2>
+ <title>Exemple</title>
+
+ <programlisting>
+ postgres=# LOAD 'auto_explain';
+ postgres=# SET auto_explain.log_min_duration = 0;
+ postgres=# SELECT count(*)
+ FROM pg_class, pg_index
+ WHERE oid = indrelid AND indisunique;
+ </programlisting>
+
+ <para>
+ Ceci devrait produire un résultat de ce style dans les journaux applicatifs :
+ </para>
+
+ <programlisting><![CDATA[ LOG: duration: 0.986 ms plan:
Aggregate (cost=14.90..14.91 rows=1 width=0)
-> Hash Join (cost=3.91..14.70 rows=81 width=0)
Hash Cond: (pg_class.oid = pg_index.indrelid)
@@ -164,17 +175,16 @@
Filter: indisunique
STATEMENT: SELECT count(*)
FROM pg_class, pg_index
- WHERE oid = indrelid AND indisunique;
-]]>
- </programlisting>
- </sect2>
-
- <sect2>
- <title>Author</title>
-
- <para>
- Takahiro Itagaki <email>itagaki.takahiro at oss.ntt.co.jp</email>
- </para>
- </sect2>
-
+ WHERE oid = indrelid AND indisunique;]]>
+ </programlisting>
+ </sect2>
+
+ <sect2>
+ <title>Auteur</title>
+
+ <para>
+ Takahiro Itagaki <email>itagaki.takahiro at oss.ntt.co.jp</email>
+ </para>
+ </sect2>
+
</sect1>
Modified: traduc/trunk/postgresql/citext.xml
===================================================================
--- traduc/trunk/postgresql/citext.xml 2009-04-23 21:58:48 UTC (rev 1305)
+++ traduc/trunk/postgresql/citext.xml 2009-04-23 21:59:12 UTC (rev 1306)
@@ -1,4 +1,8 @@
-<!-- $PostgreSQL: pgsql/doc/src/sgml/citext.sgml,v 1.2 2008-09-12 18:29:49 tgl Exp $ -->
+<?xml version="1.0" encoding="ISO-8859-15"?>
+<!-- Dernière modification
+ le $Date: 2009-04-16 18:18:33 +0200 (jeu 16 avr 2009) $
+ par $Author: gleu $
+ révision $Revision: 1297 $ -->
<sect1 id="citext">
<title>citext</title>
@@ -8,20 +12,20 @@
</indexterm>
<para>
- The <filename>citext</filename> module provides a case-insensitive
- character string type, <type>citext</type>. Essentially, it internally calls
- <function>lower</function> when comparing values. Otherwise, it behaves almost
- exactly like <type>text</type>.
+ Le module <filename>citext</filename> fournit un type chaîne de caratères
+ insensible à la casse, <type>citext</type>. En réalité, il appelle en interne
+ la fonction <function>lower</function> lorsqu'il compare des valeurs. Dans
+ les autres cas, il se comporte presque exactement comme le type
+ <type>text</type>.
</para>
<sect2>
- <title>Rationale</title>
+ <title>Intérêt</title>
<para>
- The standard approach to doing case-insensitive matches
- in <productname>PostgreSQL</productname> has been to use the
- <function>lower</function>
- function when comparing values, for example
+ L'approche standard pour effectuer des rapprochements insensibles à
+ la casse avec <productname>PostgreSQL</productname> était d'utiliser la fonction
+ <function>lower</function> pour comparer des valeurs. Par exemple :
<programlisting>
SELECT * FROM tab WHERE lower(col) = LOWER(?);
@@ -29,51 +33,53 @@
</para>
<para>
- This works reasonably well, but has a number of drawbacks:
+ Ceci fonctionne plutôt bien, mais présente quelques inconvénients :
</para>
<itemizedlist>
<listitem>
<para>
- It makes your SQL statements verbose, and you always have to remember to
- use <function>lower</function> on both the column and the query value.
+ Cela rend les ordres SQL bavards, et vous devez sans arrêt vous souvenir
+ d'utiliser la fonction <function>lower</function> à la fois sur la
+ colonne et la valeur de la requête.
</para>
</listitem>
<listitem>
<para>
- It won't use an index, unless you create a functional index using
- <function>lower</function>.
+ Cela n'utilise pas les index, à moins que vous ne créiez un index
+ fonctionnel avec la fonction <function>lower</function>.
</para>
</listitem>
<listitem>
<para>
- If you declare a column as <literal>UNIQUE</literal> or <literal>PRIMARY
- KEY</literal>, the implicitly generated index is case-sensitive. So it's
- useless for case-insensitive searches, and it won't enforce
- uniqueness case-insensitively.
+ Si vous déclarez une colonne <literal>UNIQUE</literal> ou <literal>PRIMARY
+ KEY</literal>, l'index généré implicitement est sensible à la casse. Il
+ est donc inutile pour des recherches insensibles à la casse, et il ne va
+ pas garantir l'unicité de manière insensible à la casse.
</para>
</listitem>
</itemizedlist>
<para>
- The <type>citext</type> data type allows you to eliminate calls
- to <function>lower</function> in SQL queries, and allows a primary key to
- be case-insensitive. <type>citext</type> is locale-aware, just
- like <type>text</type>, which means that the comparison of uppercase and
- lowercase characters is dependent on the rules of
- the <literal>LC_CTYPE</literal> locale setting. Again, this behavior is
- identical to the use of <function>lower</function> in queries. But because it's
- done transparently by the datatype, you don't have to remember to do
- anything special in your queries.
+ Le type de données <type>citext</type> vous permet d'éviter les appels à
+ <function>lower</function> dans les requêtes SQL, et peut rendre une clé
+ primaire insensible à la casse. <type>citext</type> tient compte de la
+ locale, comme <type>text</type>, ce qui signifie que la comparaison entre
+ caractères majuscules et minuscules dépend des règles de la locale
+ paramétrée par <literal>LC_CTYPE</literal> . Ici également, le comportement
+ est identique à l'utilisation de la fonction
+ <function>lower</function> dans les requêtes. Mais comme cela est fait de
+ manière transparente par le type de données, vous n'avez pas à vous souvenir
+ de faire quelque chose de particulier dans vos requêtes.
</para>
</sect2>
<sect2>
- <title>How to Use It</title>
+ <title>Comment l'utiliser</title>
<para>
- Here's a simple example of usage:
+ Voici un exemple simple d'utilisation :
<programlisting>
CREATE TABLE users (
@@ -90,31 +96,35 @@
SELECT * FROM users WHERE nick = 'Larry';
</programlisting>
- The <command>SELECT</command> statement will return one tuple, even though
- the <structfield>nick</structfield> column was set to <quote>larry</quote> and the query
- was for <quote>Larry</quote>.
+ L'ordre <command>SELECT</command> va renvoyer un enregistrement, bien que
+ la colonne <structfield>nick</structfield> ait été positionnée à
+ <quote>larry</quote> et que la requête soit pour <quote>Larry</quote>.
</para>
</sect2>
<sect2>
- <title>String Comparison Behavior</title>
+ <title>Comportement des comparaisons de chaînes</title>
+
<para>
- In order to emulate a case-insensitive collation as closely as possible,
- there are <type>citext</type>-specific versions of a number of the comparison
- operators and functions. So, for example, the regular expression
- operators <literal>~</literal> and <literal>~*</literal> exhibit the same behavior when
- applied to <type>citext</type>: they both compare case-insensitively.
- The same is true
- for <literal>!~</literal> and <literal>!~*</literal>, as well as for the
- <literal>LIKE</literal> operators <literal>~~</literal> and
- <literal>~~*</literal>, and
- <literal>!~~</literal> and <literal>!~~*</literal>. If you'd like to match
- case-sensitively, you can always cast to <type>text</type> before comparing.
+ Afin d'émuler un tri insensible à la casse de la manière la plus
+ fidèle possible, il existe des versions spécifiques à <type>citext</type>
+ de plusieurs opérateurs et fonctions de comparaison.
+ Ainsi, par exemple, les opérateurs pour les expressions rationnelles
+ <literal>~</literal> and <literal>~*</literal> ont le même comportement quand
+ ils sont appliqués au type <type>citext</type> : ils comparent tous
+ les deux de manière insensible à la casse.
+ Cela est aussi vraie pour <literal>!~</literal> et <literal>!~*</literal>,
+ et également pour les opérateurs
+ <literal>LIKE</literal>, <literal>~~</literal>,
+ <literal>~~*</literal>, et
+ <literal>!~~</literal> et <literal>!~~*</literal>. Si vous voulez faire une
+ comparaison sensible à la casse, vous pouvez toujours convertir dans un
+ <type>text</type> avant de comparer.
</para>
<para>
- Similarly, all of the following functions perform matching
- case-insensitively if their arguments are <type>citext</type>:
+ De la même façon, toutes les fonctions ci-dessous font une comparaison insensible à la casse
+ si leurs arguments sont de type <type>citext</type> :
</para>
<itemizedlist>
@@ -156,10 +166,11 @@
</itemizedlist>
<para>
- For the regexp functions, if you want to match case-sensitively, you can
- specify the <quote>c</quote> flag to force a case-sensitive match. Otherwise,
- you must cast to <type>text</type> before using one of these functions if
- you want case-sensitive behavior.
+ Pour les fonctions regexp, si vous voulez effectuer des comparaisons
+ sensibles à la casse, vous pouvez positionner l'indicateur <quote>c</quote>
+ pour forcer une comparaison sensible à la casse. Sinon, si vous souhaitez
+ un comportement sensible à la casse, vous devez convertir dans un type
+ <type>text</type> avant d'utiliser une de ces fonctions.
</para>
</sect2>
@@ -170,56 +181,60 @@
<itemizedlist>
<listitem>
<para>
- <type>citext</type>'s behavior depends on
- the <literal>LC_CTYPE</literal> setting of your database. How it compares
- values is therefore determined when
- <application>initdb</application> is run to create the cluster. It is not truly
- case-insensitive in the terms defined by the Unicode standard.
- Effectively, what this means is that, as long as you're happy with your
- collation, you should be happy with <type>citext</type>'s comparisons. But
- if you have data in different languages stored in your database, users
- of one language may find their query results are not as expected if the
- collation is for another language.
+ Le comportement de <type>citext</type> dépend du paramètre
+ <literal>LC_CTYPE</literal> de votre base de données. Par conséquent,
+ la manière dont il compare les valeurs est fixée lorsque
+ <application>initdb</application> est exécuté pour créer le cluster.
+ Il n'est pas réellement insensible à la casse dans les termes définis par
+ le standard Unicode.
+ En pratique, ce que cela signifie est que, tant que vous êtes satisfait
+ de votre tri, vous devriez être satisfait des comparaisons de
+ <type>citext</type>. Mais si vous avez des données stockées dans
+ différentes langues dans votre base, des utilisateurs de certains langages
+ pourraient trouver que les résultats de leurs requêtes sont inattendus
+ si le tri est déterminé pour un autre langage.
</para>
</listitem>
<listitem>
<para>
- <type>citext</type> is not as efficient as <type>text</type> because the
- operator functions and the btree comparison functions must make copies
- of the data and convert it to lower case for comparisons. It is,
- however, slightly more efficient than using <function>lower</function> to get
- case-insensitive matching.
+ <type>citext</type> n'est pas aussi performant que <type>text</type> parce que
+ les fonctions opérateurs et les fonctions de comparaison btree
+ doivent faire des copies des données et les convertir en minuscules pour les
+ comparaisons. C'est cependant légèrement plus efficace qu'utiliser
+ <function>lower</function> pour obtenir des comparaisons insensibles à la casse.
</para>
</listitem>
<listitem>
<para>
- <type>citext</type> doesn't help much if you need data to compare
- case-sensitively in some contexts and case-insensitively in other
- contexts. The standard answer is to use the <type>text</type> type and
- manually use the <function>lower</function> function when you need to compare
- case-insensitively; this works all right if case-insensitive comparison
- is needed only infrequently. If you need case-insensitive most of
- the time and case-sensitive infrequently, consider storing the data
- as <type>citext</type> and explicitly casting the column to
- <type>text</type>
- when you want case-sensitive comparison. In either situation, you
- will need two indexes if you want both types of searches to be fast.
+ <type>citext</type> n'aide pas réellement dans un certain conctexte.
+ Vos données doivent être comparées de manière sensible à la casse dans
+ certains contextes, et de manière sensible à la casse dans d'autres
+ contextes. La réponse habituelle à cette question est d'utiliser le type
+ <type>text</type> et d'utiliser manuellement la fonction
+ <function>lower</function> lorsque vous avez besoin d'une comparaison
+ insensible à la casse ; ceci fonctionne très bien si vous avez besoin
+ peu fréquemment de comparaisons insensibles à la casse. Si vous avez
+ besoin de comparaisons insensibles à la casse la plupart du temps, pensez
+ à stocker les données en <type>citext</type> et à convertir explicitement
+ les colonnes en <type>text</type> quand vous voulez une comparaison
+ sensible à la casse. Dans les deux situations, vous aurez besoin de deux
+ index si vous voulez que les deux types de recherche soient rapides.
</para>
</listitem>
</itemizedlist>
</sect2>
<sect2>
- <title>Author</title>
+ <title>Auteur</title>
<para>
David E. Wheeler <email>david at kineticode.com</email>
</para>
<para>
- Inspired by the original <type>citext</type> module by Donald Fraser.
+ Inspiré par le module original <type>citext</type> par Donald Fraser.
</para>
</sect2>
More information about the Trad
mailing list