WIP on json file

postgresql/json.xml

@@ -24,11 +24,11 @@
  </para>
 
  <para>
-  <productname>PostgreSQL</productname> offers two types for storing JSON
-  data: <type>json</type> and <type>jsonb</type>. To implement effective query
-  mechanisms for these data types, <productname>PostgreSQL</productname>
-  also provides the <type>jsonpath</type> data type described in
-  <xref linkend="datatype-jsonpath"/>.
+  <productname>PostgreSQL</productname> propose deux types pour stocker des
+  données JSON : <type>json</type> and <type>jsonb</type>.
+  Pour implémenter des mécanismes de requêtage efficaces pour ces types de
+  données <productname>PostgreSQL</productname> propose aussi le type
+  <type>jsonpath</type> décrit dans <xref linkend="datatype-jsonpath"/>.
  </para>
 
  <para>
@@ -238,8 +238,8 @@ SELECT '{"reading": 1.230e-5}'::json, '{"reading": 1.230e-5}'::jsonb;
   </para>
 
   <para>
-   For the list of built-in functions and operators available for
-   constructing and processing JSON values, see <xref linkend="functions-json"/>.
+   Pour la liste de fonctions et opérateurs intégrés disponibles pour construire
+   et traiter des valeurs JSON, voyez <xref linkend="functions-json"/>.
   </para>
  </sect2>
 
@@ -253,7 +253,7 @@ SELECT '{"reading": 1.230e-5}'::json, '{"reading": 1.230e-5}'::jsonb;
    au sein de la même application. Toutefois, même pour les applications où on
    désire le maximum de flexibilité, il est toujours recommandé que les
    documents JSON aient une structure quelque peu fixée. La structure est
-   typiquement non vérifiée (bien que vérifier des règles métier de manière 
+   typiquement non vérifiée (bien que vérifier des règles métier de manière
    déclarative soit possible), mais le fait d'avoir une
    structure prévisible rend plus facile l'écriture de requêtes qui résument
    utilement un ensemble de <quote>documents</quote> (datums) dans une table.
@@ -498,20 +498,21 @@ CREATE INDEX idxgintags ON api USING GIN ((jdoc -&gt; 'tags'));
    trouvées dans <xref linkend="indexes-expressional"/>.)
   </para>
   <para>
-    Also, GIN index supports <literal>@@</literal> and <literal>@?</literal>
-    operators, which perform <literal>jsonpath</literal> matching.
+    Les index GIN supportent aussi les opérateurs <literal>@@</literal>
+    et <literal>@?</literal>qui réalisent la correspondance avec le
+    <literal>jsonpath</literal>.
 <programlisting>
 SELECT jdoc->'guid', jdoc->'name' FROM api WHERE jdoc @@ '$.tags[*] == "qui"';
 </programlisting>
 <programlisting>
 SELECT jdoc->'guid', jdoc->'name' FROM api WHERE jdoc @@ '$.tags[*] ? (@ == "qui")';
 </programlisting>
-    GIN index extracts statements of following form out of
-    <literal>jsonpath</literal>: <literal>accessors_chain = const</literal>.
-    Accessors chain may consist of <literal>.key</literal>,
-    <literal>[*]</literal> and <literal>[index]</literal> accessors.
-    <literal>jsonb_ops</literal> additionally supports <literal>.*</literal>
-    and <literal>.**</literal> statements.
+    L'index GIN extrait les informations de la forme suivante du
+    <literal>jsonpath</literal>: <literal>chaîne accesseur = const</literal>.
+    La chaîne d'accesseurs peut être <literal>.key</literal>,
+    <literal>[*]</literal> et <literal>[index]</literal>.
+    <literal>jsonb_ops</literal> supporte aussi les syntaxes <literal>.*</literal>
+    et <literal>.**</literal>.
   </para>
   <para>
    Une autre approche pour le requêtage et l'exploitation de l'inclusion, par exemple&nbsp;:
@@ -647,42 +648,45 @@ SELECT jdoc-&gt;'guid', jdoc-&gt;'name' FROM api WHERE jdoc @&gt; '{"tags": ["qu
  </sect2>
 
  <sect2 id="datatype-jsonpath">
-  <title>jsonpath Type</title>
+  <title>Type jsonpath</title>
 
   <indexterm zone="datatype-jsonpath">
    <primary>jsonpath</primary>
   </indexterm>
 
   <para>
-   The <type>jsonpath</type> type implements support for the SQL/JSON path language
-   in <productname>PostgreSQL</productname> to effectively query JSON data.
-   It provides a binary representation of the parsed SQL/JSON path
-   expression that specifies the items to be retrieved by the path
-   engine from the JSON data for further processing with the
-   SQL/JSON query functions.
+   Le type <type>jsonpath</type> implémente le support du langage
+   SQL/JSONpath dans <productname>PostgreSQL</productname> de façon à requêter
+   correctement dans les données JSON.
+   Cela fournit une représentation binaire de l'expression SQL/JSONpath analysée
+   qui spécifie les items qui doivent être récupérés par le moteur de chemin
+   depuis les données JSON pour être traités par la suite avec les fonctions
+   de requêtage SQL/JSON.
   </para>
 
   <para>
-   The SQL/JSON path language is fully integrated into the SQL engine:
-   the semantics of its predicates and operators generally follow SQL.
-   At the same time, to provide a most natural way of working with JSON data,
-   SQL/JSON path syntax uses some of the JavaScript conventions:
+   Le langage SQL/JSONpath est complètement intégré dans le moteur SQL:
+   La sémantique des prédicats et opérateurs suit généralement SQL.
+   Dans le même temps, il propose la manière la plus naturelle de travailler
+   avec les données JSON en effet la syntaxe SQL/JSONpath utilise certaines des
+   conventions JavaScript:
   </para>
 
   <itemizedlist>
    <listitem>
     <para>
-     Dot <literal>.</literal> is used for member access.
+     Le point <literal>.</literal> est utilisé pour accéder à une valeur.
     </para>
    </listitem>
    <listitem>
     <para>
-     Square brackets <literal>[]</literal> are used for array access.
+     Les crochets <literal>[]</literal> est utilisé pour accéder à un tableau.
     </para>
    </listitem>
    <listitem>
     <para>
-     SQL/JSON arrays are 0-relative, unlike regular SQL arrays that start from 1.
+     Les tableaux SQL/JSON commencent à partir de 0, contrairement aux tableaux SQL classiques
+     qui commmencent à 1.
     </para>
    </listitem>
   </itemizedlist>