[Trad] [svn:pgfr] r1187 - traduc/trunk/postgresql
admin at listes.postgresql.fr
admin at listes.postgresql.fr
Ven 31 Oct 14:18:05 CET 2008
Author: sas
Date: 2008-10-31 14:18:05 +0100 (Fri, 31 Oct 2008)
New Revision: 1187
Modified:
traduc/trunk/postgresql/sources.xml
Log:
Petites corrections en attendant une relecture plus profonde
Modified: traduc/trunk/postgresql/sources.xml
===================================================================
--- traduc/trunk/postgresql/sources.xml 2008-10-31 10:54:46 UTC (rev 1186)
+++ traduc/trunk/postgresql/sources.xml 2008-10-31 13:18:05 UTC (rev 1187)
@@ -12,7 +12,7 @@
<para>
Le formatage du code source utilise un espacement de quatre colonnes
- pour les tabulations, avec la préservation de celles-ci
+ pour les tabulations, avec préservation de celles-ci
(c'est-à-dire que les tabulations ne sont pas converties en
espaces). Chaque niveau logique d'indentation est une tabulation
supplémentaire. Les règles de disposition (positionnement des
@@ -20,18 +20,18 @@
</para>
<para>
- Bien que les correctifs (patchs) soumis ne sont absolument pas tenus de
- suivre ces règles de formatage, il est recommandé de le faire. Votre
- code sera passé dans <application>pgindent</application>, donc il n'y a pas
- d'intérêts à ce qu'il soit joli grâce à d'autres ensembles de
+ Bien que les correctifs (patchs) soumis ne soient absolument pas tenus de
+ suivre ces règles de formatage, il est recommandé de le faire. Le
+ code est passé dans <application>pgindent</application>, il n'y a donc pas
+ lieu à l'enjoliver par un quelconque ensemble de
conventions de formatage.
</para>
<para>
Le répertoire <filename>src/tools</filename> contient des fichiers d'exemples
- de configuration qui peuvent être employer avec les éditeurs <productname>emacs</productname>,
+ de configuration qui peuvent être employés avec les éditeurs <productname>emacs</productname>,
<productname>xemacs</productname> ou <productname>vim</productname>
- pour valider que le format du code écrit respecte ces conventions
+ pour valider que le format du code écrit respecte ces conventions.
</para>
<para>
@@ -56,18 +56,18 @@
</indexterm>
<para>
- Les messages d'erreurs, d'alertes et de traces générés à l'intérieur
- du code du serveur doivent être créés en utilisant
+ Les messages d'erreurs, d'alertes et de traces produites dans
+ le code du serveur doivent être créés avec
<function>ereport</function> ou son ancien cousin <function>elog</function>.
- L'utilisation de cette fonction est assez complexe pour que cela
- requiert quelques explications.
+ L'utilisation de cette fonction est suffisamment complexe pour nécessiter
+ quelques explications.
</para>
<para>
Il y a deux éléments requis pour chaque message : un niveau de
sévérité (allant de <literal>DEBUG</literal> à <literal>PANIC</literal>) et un
message texte primaire. De plus, il y a des éléments optionnels,
- le plus commun d'entre eux est le code d'identifiant de l'erreur
+ le plus commun d'entre eux est le code identifiant de l'erreur
qui suit les conventions SQLSTATE des spécifications SQL.
<function>ereport</function> en elle-même n'est qu'une fonction shell qui
existe principalement pour des convenances syntaxiques faisant
@@ -75,29 +75,29 @@
un code source C. Le seul paramètre directement accepté par
<function>ereport</function> est le niveau de sévérité. Le message texte
primaire et les autres éléments de messages optionnels sont
- générés en appelant des fonctions auxiliaires, comme
- <function>errmsg</function>, à l'intérieur de l'appel à
+ produits par appel de fonctions auxiliaires, comme
+ <function>errmsg</function>, dans l'appel à
<function>ereport</function>.
</para>
<para>
- Un appel typique à <function>ereport</function> peut ressembler à ceci :
+ Un appel typique à <function>ereport</function> peut ressembler à :
<programlisting>ereport(ERROR,
(errcode(ERRCODE_DIVISION_BY_ZERO),
errmsg("division by zero")));
</programlisting>
- Ceci met le niveau de sévérité de l'erreur à <literal>ERROR</literal>
- (une erreur banale). L'appel à <function>errcode</function> spécifie
+ Le niveau de sévérité de l'erreur est ainsi positionné à <literal>ERROR</literal>
+ (une erreur banale). L'appel à <function>errcode</function> précise
l'erreur SQLSTATE en utilisant une macro définie dans
<filename>src/include/utils/errcodes.h</filename>. L'appel à
- <function>errmsg</function> fournit le message texte primaire. Notez
- l'ensemble supplémentaire de parenthèses entourant les appels aux
- fonctions auxiliaires (cela est ennuyeux mais syntaxiquement
- nécessaire).
+ <function>errmsg</function> fournit le message texte primaire.
+ L'ensemble supplémentaire de parenthèses entourant les appels aux
+ fonctions auxiliaires est ennuyeux mais syntaxiquement
+ nécessaire.
</para>
<para>
- Voici un exemple plus complexe :
+ Exemple plus complexe :
<programlisting>ereport(ERROR,
(errcode(ERRCODE_AMBIGUOUS_FUNCTION),
errmsg("function %s is not unique",
@@ -106,7 +106,7 @@
errhint("Unable to choose a best candidate function. "
"You might need to add explicit typecasts.")));
</programlisting>
- Ceci illustre l'utilisation des codes de formatage pour intégrer
+ Cela illustre l'utilisation des codes de formatage pour intégrer
des valeurs d'exécution dans un message texte. Un message
<quote>conseil</quote>, optionnel, est également fourni.
</para>
@@ -117,32 +117,32 @@
<itemizedlist>
<listitem>
<para>
- <function>errcode(sqlerrcode)</function> spécifie le code SQLSTATE de
- l'identifiant de l'erreur pour la condition. Si cette routine
- n'est pas appelée, par défaut, l'identifiant de l'erreur sera
+ <function>errcode(sqlerrcode)</function> précise le code SQLSTATE de
+ l'identifiant erreur pour la condition. Si cette routine
+ n'est pas appelée, l'identifiant l'erreur est, par défaut,
<literal>ERRCODE_INTERNAL_ERROR</literal> quand le niveau de sévérité de
l'erreur est <literal>ERROR</literal> ou plus haut,
<literal>ERRCODE_WARNING</literal> quand le niveau d'erreur est
<literal>WARNING</literal> et <literal>ERRCODE_SUCCESSFUL_COMPLETION</literal>
pour <literal>NOTICE</literal> et inférieur. Bien que ces valeurs par
- défaut soient souvent commodes, demandez-vous toujours si elles
+ défaut soient souvent commodes, il faut se demander si elles
sont appropriées avant d'omettre l'appel à
<function>errcode()</function>.
</para>
</listitem>
<listitem>
<para>
- <function>errmsg(const char *msg, ...)</function> spécifie le message
+ <function>errmsg(const char *msg, ...)</function> indique le message
texte primaire de l'erreur et les possibles valeurs d'exécutions
- à insérer dedans. Les insertions sont spécifiées par les codes
+ à y insérer. Les insertions sont précisées par les codes
de formatage dans le style <function>sprintf</function>. En plus des
- codes de formatage standards acceptés par <function>sprintf</function>,
+ codes de formatage standard acceptés par <function>sprintf</function>,
le code <literal>%m</literal> peut être utilisé pour insérer le message
d'erreur retourné par <function>strerror</function> pour la valeur
courante de <literal>errno</literal>.
<footnote>
<para>
- C'est-à-dire que la valeur qui était courante quand l'appel à
+ C'est-à-dire la valeur qui était courante quand l'appel à
<function>ereport</function> a été atteinte ; les changements
d'<literal>errno</literal> dans les routines auxiliaires de rapports
ne l'affecteront pas. Cela ne sera pas vrai si vous devez
@@ -162,7 +162,7 @@
<para>
<function>errmsg_internal(const char *msg, ...)</function> fait la même
chose que <function>errmsg</function> à l'exception que la chaîne de
- caractères du message ne sera ni traduite ni inclue dans le dictionnaire
+ caractères du message ne sera ni traduite ni incluse dans le dictionnaire
de messages d'internationalisation. Cela devrait être utilisé
pour les cas qui <quote>ne peuvent pas arriver</quote> et pour
lesquels il n'est probablement pas intéressant de déployer un
@@ -248,17 +248,17 @@
<programlisting>elog(niveau, "chaine format", ...);</programlisting>
est strictement équivalent à :
<programlisting>ereport(level, (errmsg_internal("chaine format", ...)));</programlisting>
- Notez que le code d'erreur SQLSTATE est toujours par défaut et que
- la chaîne de caractères du message n'est pas sujet à une traduction.
+ Le code d'erreur SQLSTATE est toujours celui par défaut,
+ la chaîne de caractères du message n'est pas sujette à traduction.
Par conséquent,
- <function>elog</function> devrait être utilisé seulement pour les erreurs
+ <function>elog</function> ne devrait être utilisé que pour les erreurs
internes et l'enregistrement de trace de débogage de bas niveau.
- N'importe quel message qui est susceptible d'être intéressant pour
+ N'importe quel message susceptible d'intéresser
les utilisateurs ordinaires devrait passer par
- <function>ereport</function>. Néanmoins, il y a assez de contrôles
- d'erreurs internes qui <quote>ne peuvent pas arriver</quote> dans le
- système, que <function>elog</function> est toujours largement utilisé ;
- pour ces messages, cela est préféré à cause de sa simplicité
+ <function>ereport</function>. Néanmoins, il y a suffisamment de contrôles
+ des erreurs internes qui <quote>ne peuvent pas arriver</quote> dans le
+ système, pour que <function>elog</function> soit toujours largement
+ utilisée ; elle est préférée pour ces messages du fait de sa simplicité
d'écriture.
</para>
@@ -545,8 +545,8 @@
<title>Assembler les messages d'erreurs</title>
<para>
- Quand un message inclut du texte qui est généré ailleurs,
- intégrez-le dans ce style :
+ Quand un message inclut du texte produit ailleurs,
+ il est intégré dans ce style :
<programlisting>n'a pas pu ouvrir le fichier %s: %m</programlisting>
</para>
More information about the Trad
mailing list