ECPG, sentence not complete
Hi, we're translating the ecpg.xml from scratch in french, as it seems
to have moved a lot with 9.0 and 9.1.
I'm having trouble with this:
3948 <term><literal>desc_next</></term>
3949 <listitem>
3950 <para>
3951 If the query returns more than one records, multiple linked
SQLDA structures
3952 are returned, the first record is stored in the SQLDA
returned in the
3953 </para>
3954 </listitem>
Seems to me there are some words missing, but maybe it's a continuation
to the next paragraph. Anyway I don't want to guess what should be
there, so if anyone can explain this to me :)
Cheers
Marc
Hi,
2011/06/03 18:16, Marc Cousin wrote:
Hi, we're translating the ecpg.xml from scratch in french, as it seems
to have moved a lot with 9.0 and 9.1.I'm having trouble with this:
3948<term><literal>desc_next</></term>
3949<listitem>
3950<para>
3951 If the query returns more than one records, multiple linked
SQLDA structures
3952 are returned, the first record is stored in the SQLDA
returned in the
3953</para>
3954</listitem>Seems to me there are some words missing, but maybe it's a continuation
to the next paragraph. Anyway I don't want to guess what should be
there, so if anyone can explain this to me :)
This problem has been living since 9.0 or before.
I think it should be rewritten as following:
---------------------------------------------------------
If the query returns more than one records, multiple linked
SQLDA structures are returned, and <literal>desc_next</>
holds a pointer to the next element (record) in the list.
---------------------------------------------------------
Thanks,
--
NAGAYASU Satoshi <satoshi.nagayasu@gmail.com>
Satoshi Nagayasu <satoshi.nagayasu@gmail.com> wrote:
I think it should be rewritten as following:
---------------------------------------------------------
If the query returns more than one records, multiple linked
SQLDA structures are returned, and <literal>desc_next</>
holds a pointer to the next element (record) in the list.
---------------------------------------------------------
"more than one records" isn't right -- it could be "multiple
records" or "more than one record".
-Kevin
On 06/03/2011 08:30 PM, Kevin Grittner wrote:
Satoshi Nagayasu <satoshi.nagayasu@gmail.com> wrote:
I think it should be rewritten as following:
---------------------------------------------------------
If the query returns more than one records, multiple linked
SQLDA structures are returned, and <literal>desc_next</>
holds a pointer to the next element (record) in the list.
---------------------------------------------------------"more than one records" isn't right -- it could be "multiple
records" or "more than one record".-Kevin
Hi, I've found another problem in ECPG's doc:
<varlistentry>
<term><literal>ECPG_INFORMIX_DATE_CONVERT</></term>
<listitem>
<para>
Functions return this value if Internally it is defined to -1210
(the
<productname>Informix</productname> definition).
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>ECPG_INFORMIX_OUT_OF_MEMORY</></term>
<listitem>
<para>
Functions return this value if Internally it is defined to -1211
(the
<productname>Informix</productname> definition).
</para>
</listitem>
</varlistentry>
There are a few words missing.
Cheers
On lör, 2011-06-04 at 03:10 +0900, Satoshi Nagayasu wrote:
Hi,
2011/06/03 18:16, Marc Cousin wrote:
Hi, we're translating the ecpg.xml from scratch in french, as it seems
to have moved a lot with 9.0 and 9.1.I'm having trouble with this:
3948<term><literal>desc_next</></term>
3949<listitem>
3950<para>
3951 If the query returns more than one records, multiple linked
SQLDA structures
3952 are returned, the first record is stored in the SQLDA
returned in the
3953</para>
3954</listitem>Seems to me there are some words missing, but maybe it's a continuation
to the next paragraph. Anyway I don't want to guess what should be
there, so if anyone can explain this to me :)This problem has been living since 9.0 or before.
I think it should be rewritten as following:
---------------------------------------------------------
If the query returns more than one records, multiple linked
SQLDA structures are returned, and <literal>desc_next</>
holds a pointer to the next element (record) in the list.
---------------------------------------------------------
Fixed.
On lör, 2011-06-04 at 18:52 +0200, Marc Cousin wrote:
Hi, I've found another problem in ECPG's doc:
<varlistentry>
<term><literal>ECPG_INFORMIX_DATE_CONVERT</></term>
<listitem>
<para>
Functions return this value if Internally it is defined to -1210
(the
<productname>Informix</productname> definition).
</para>
</listitem>
</varlistentry><varlistentry>
<term><literal>ECPG_INFORMIX_OUT_OF_MEMORY</></term>
<listitem>
<para>
Functions return this value if Internally it is defined to -1211
(the
<productname>Informix</productname> definition).
</para>
</listitem>
</varlistentry>There are a few words missing.
Fixed.
Sorry to give them as small batches like that. I've found 3 other ones
(the last ones I hope, as I've finished translating everything else from
the file).
Same problem as before, there are a few words missing.
<term><literal>ECPG_INFORMIX_BAD_EXPONENT</></term>
<listitem>
<para>
Functions return this value if Internally it is defined to -1216
(the
<productname>Informix</productname> definition).
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>ECPG_INFORMIX_BAD_DATE</></term>
<listitem>
<para>
Functions return this value if Internally it is defined to -1218
(the
<productname>Informix</productname> definition).
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>ECPG_INFORMIX_EXTRA_CHARS</></term>
<listitem>
<para>
Functions return this value if Internally it is defined to -1264
(the
<productname>Informix</productname> definition).
</para>
</listitem>
Marc
Marc Cousin wrote:
On 06/03/2011 08:30 PM, Kevin Grittner wrote:
Satoshi Nagayasu <satoshi.nagayasu@gmail.com> wrote:
I think it should be rewritten as following:
---------------------------------------------------------
If the query returns more than one records, multiple linked
SQLDA structures are returned, and <literal>desc_next</>
holds a pointer to the next element (record) in the list.
---------------------------------------------------------"more than one records" isn't right -- it could be "multiple
records" or "more than one record".-Kevin
Hi, I've found another problem in ECPG's doc:
<varlistentry>
<term><literal>ECPG_INFORMIX_DATE_CONVERT</></term>
<listitem>
<para>
Functions return this value if Internally it is defined to -1210
(the
<productname>Informix</productname> definition).
</para>
</listitem>
</varlistentry><varlistentry>
<term><literal>ECPG_INFORMIX_OUT_OF_MEMORY</></term>
<listitem>
<para>
Functions return this value if Internally it is defined to -1211
(the
<productname>Informix</productname> definition).
</para>
</listitem>
</varlistentry>There are a few words missing.
I have applied the attached patch to fix these cases, and clean up the
wording a little. Thanks for the report. It is great you are
translating the docs into French.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
Attachments:
/rtmp/ecpgtext/x-diffDownload+17-14
Marc Cousin wrote:
Sorry to give them as small batches like that. I've found 3 other ones
(the last ones I hope, as I've finished translating everything else from
the file).
Same problem as before, there are a few words missing.<term><literal>ECPG_INFORMIX_BAD_EXPONENT</></term>
<listitem>
<para>
Functions return this value if Internally it is defined to -1216
(the
<productname>Informix</productname> definition).
</para>
</listitem>
</varlistentry><varlistentry>
<term><literal>ECPG_INFORMIX_BAD_DATE</></term>
<listitem>
<para>
Functions return this value if Internally it is defined to -1218
(the
<productname>Informix</productname> definition).
</para>
</listitem>
</varlistentry><varlistentry>
<term><literal>ECPG_INFORMIX_EXTRA_CHARS</></term>
<listitem>
<para>
Functions return this value if Internally it is defined to -1264
(the
<productname>Informix</productname> definition).
</para>
</listitem>Marc
Sorry, these are the cases I fixed.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +