public inbox for [email protected]
help / color / mirror / Atom feedECPG, sentence not complete
9+ messages / 5 participants
[nested] [flat]
* ECPG, sentence not complete
@ 2011-06-03 09:16 Marc Cousin <[email protected]>
0 siblings, 1 reply; 9+ messages in thread
From: Marc Cousin @ 2011-06-03 09:16 UTC (permalink / raw)
To: pgsql-docs
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
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: ECPG, sentence not complete
@ 2011-06-03 18:10 Satoshi Nagayasu <[email protected]>
parent: Marc Cousin <[email protected]>
0 siblings, 2 replies; 9+ messages in thread
From: Satoshi Nagayasu @ 2011-06-03 18:10 UTC (permalink / raw)
To: Marc Cousin <[email protected]>; +Cc: pgsql-docs
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 <[email protected]>
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: ECPG, sentence not complete
@ 2011-06-03 18:30 Kevin Grittner <[email protected]>
parent: Satoshi Nagayasu <[email protected]>
1 sibling, 1 reply; 9+ messages in thread
From: Kevin Grittner @ 2011-06-03 18:30 UTC (permalink / raw)
To: Marc Cousin <[email protected]>; Satoshi Nagayasu <[email protected]>; +Cc: pgsql-docs
Satoshi Nagayasu <[email protected]> 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
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: ECPG, sentence not complete
@ 2011-06-04 16:52 Marc Cousin <[email protected]>
parent: Kevin Grittner <[email protected]>
0 siblings, 2 replies; 9+ messages in thread
From: Marc Cousin @ 2011-06-04 16:52 UTC (permalink / raw)
To: Kevin Grittner <[email protected]>; +Cc: Satoshi Nagayasu <[email protected]>; pgsql-docs
On 06/03/2011 08:30 PM, Kevin Grittner wrote:
> Satoshi Nagayasu <[email protected]> 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
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: ECPG, sentence not complete
@ 2011-06-04 19:12 Peter Eisentraut <[email protected]>
parent: Satoshi Nagayasu <[email protected]>
1 sibling, 0 replies; 9+ messages in thread
From: Peter Eisentraut @ 2011-06-04 19:12 UTC (permalink / raw)
To: Satoshi Nagayasu <[email protected]>; +Cc: Marc Cousin <[email protected]>; pgsql-docs
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.
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: ECPG, sentence not complete
@ 2011-06-04 19:30 Peter Eisentraut <[email protected]>
parent: Marc Cousin <[email protected]>
1 sibling, 1 reply; 9+ messages in thread
From: Peter Eisentraut @ 2011-06-04 19:30 UTC (permalink / raw)
To: Marc Cousin <[email protected]>; +Cc: pgsql-docs
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.
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: ECPG, sentence not complete
@ 2011-06-05 09:08 Marc Cousin <[email protected]>
parent: Peter Eisentraut <[email protected]>
0 siblings, 1 reply; 9+ messages in thread
From: Marc Cousin @ 2011-06-05 09:08 UTC (permalink / raw)
To: Peter Eisentraut <[email protected]>; +Cc: pgsql-docs
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
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: ECPG, sentence not complete
@ 2011-06-09 22:48 Bruce Momjian <[email protected]>
parent: Marc Cousin <[email protected]>
1 sibling, 0 replies; 9+ messages in thread
From: Bruce Momjian @ 2011-06-09 22:48 UTC (permalink / raw)
To: Marc Cousin <[email protected]>; +Cc: Kevin Grittner <[email protected]>; Satoshi Nagayasu <[email protected]>; pgsql-docs
Marc Cousin wrote:
>
> On 06/03/2011 08:30 PM, Kevin Grittner wrote:
> > Satoshi Nagayasu <[email protected]> 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 <[email protected]> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
Attachments:
[text/x-diff] /rtmp/ecpg (6.1K, 2-%2Frtmp%2Fecpg)
download | inline diff:
diff --git a/doc/src/sgml/ecpg.sgml b/doc/src/sgml/ecpg.sgml
index 9130b12..def250c 100644
--- a/doc/src/sgml/ecpg.sgml
+++ b/doc/src/sgml/ecpg.sgml
@@ -9281,7 +9281,7 @@ risnull(CINTTYPE, (char *) &i);
<listitem>
<para>
Functions return this value if an overflow occurred in a
- calculation. Internally it is defined to -1200 (the <productname>Informix</productname>
+ calculation. Internally it is defined as -1200 (the <productname>Informix</productname>
definition).
</para>
</listitem>
@@ -9292,7 +9292,7 @@ risnull(CINTTYPE, (char *) &i);
<listitem>
<para>
Functions return this value if an underflow occurred in a calculation.
- Internally it is defined to -1201 (the <productname>Informix</productname> definition).
+ Internally it is defined as -1201 (the <productname>Informix</productname> definition).
</para>
</listitem>
</varlistentry>
@@ -9302,7 +9302,7 @@ risnull(CINTTYPE, (char *) &i);
<listitem>
<para>
Functions return this value if an attempt to divide by zero is
- observed. Internally it is defined to -1202 (the <productname>Informix</productname> definition).
+ observed. Internally it is defined as -1202 (the <productname>Informix</productname> definition).
</para>
</listitem>
</varlistentry>
@@ -9312,7 +9312,7 @@ risnull(CINTTYPE, (char *) &i);
<listitem>
<para>
Functions return this value if a bad value for a year was found while
- parsing a date. Internally it is defined to -1204 (the <productname>Informix</productname>
+ parsing a date. Internally it is defined as -1204 (the <productname>Informix</productname>
definition).
</para>
</listitem>
@@ -9323,7 +9323,7 @@ risnull(CINTTYPE, (char *) &i);
<listitem>
<para>
Functions return this value if a bad value for a month was found while
- parsing a date. Internally it is defined to -1205 (the <productname>Informix</productname>
+ parsing a date. Internally it is defined as -1205 (the <productname>Informix</productname>
definition).
</para>
</listitem>
@@ -9334,7 +9334,7 @@ risnull(CINTTYPE, (char *) &i);
<listitem>
<para>
Functions return this value if a bad value for a day was found while
- parsing a date. Internally it is defined to -1206 (the <productname>Informix</productname>
+ parsing a date. Internally it is defined as -1206 (the <productname>Informix</productname>
definition).
</para>
</listitem>
@@ -9346,7 +9346,7 @@ risnull(CINTTYPE, (char *) &i);
<para>
Functions return this value if a parsing routine needs a short date
representation but did not get the date string in the right length.
- Internally it is defined to -1209 (the <productname>Informix</productname> definition).
+ Internally it is defined as -1209 (the <productname>Informix</productname> definition).
</para>
</listitem>
</varlistentry>
@@ -9356,7 +9356,7 @@ risnull(CINTTYPE, (char *) &i);
<listitem>
<para>
Functions return this value if an error occurred during date
- formatting. Internally it is defined to -1210 (the
+ formatting. Internally it is defined as -1210 (the
<productname>Informix</productname> definition).
</para>
</listitem>
@@ -9367,7 +9367,7 @@ risnull(CINTTYPE, (char *) &i);
<listitem>
<para>
Functions return this value if memory was exhausted during
- their operation. Internally it is defined to -1211 (the
+ their operation. Internally it is defined as -1211 (the
<productname>Informix</productname> definition).
</para>
</listitem>
@@ -9379,7 +9379,7 @@ risnull(CINTTYPE, (char *) &i);
<para>
Functions return this value if a parsing routine was supposed to get a
format mask (like <literal>mmddyy</>) but not all fields were listed
- correctly. Internally it is defined to -1212 (the <productname>Informix</productname> definition).
+ correctly. Internally it is defined as -1212 (the <productname>Informix</productname> definition).
</para>
</listitem>
</varlistentry>
@@ -9392,7 +9392,7 @@ risnull(CINTTYPE, (char *) &i);
the textual representation for a numeric value because it contains
errors or if a routine cannot complete a calculation involving numeric
variables because at least one of the numeric variables is invalid.
- Internally it is defined to -1213 (the <productname>Informix</productname> definition).
+ Internally it is defined as -1213 (the <productname>Informix</productname> definition).
</para>
</listitem>
</varlistentry>
@@ -9401,7 +9401,8 @@ risnull(CINTTYPE, (char *) &i);
<term><literal>ECPG_INFORMIX_BAD_EXPONENT</></term>
<listitem>
<para>
- Functions return this value if Internally it is defined to -1216 (the
+ Functions return this value if a parsing routine cannot parse
+ an exponent. Internally it is defined as -1216 (the
<productname>Informix</productname> definition).
</para>
</listitem>
@@ -9411,7 +9412,8 @@ risnull(CINTTYPE, (char *) &i);
<term><literal>ECPG_INFORMIX_BAD_DATE</></term>
<listitem>
<para>
- Functions return this value if Internally it is defined to -1218 (the
+ Functions return this value if a parsing routine cannot parse
+ a date. Internally it is defined as -1218 (the
<productname>Informix</productname> definition).
</para>
</listitem>
@@ -9421,7 +9423,8 @@ risnull(CINTTYPE, (char *) &i);
<term><literal>ECPG_INFORMIX_EXTRA_CHARS</></term>
<listitem>
<para>
- Functions return this value if Internally it is defined to -1264 (the
+ Functions return this value if a parsing routine is passed extra
+ characters is cannot parse. Internally it is defined as -1264 (the
<productname>Informix</productname> definition).
</para>
</listitem>
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: ECPG, sentence not complete
@ 2011-06-09 22:48 Bruce Momjian <[email protected]>
parent: Marc Cousin <[email protected]>
0 siblings, 0 replies; 9+ messages in thread
From: Bruce Momjian @ 2011-06-09 22:48 UTC (permalink / raw)
To: Marc Cousin <[email protected]>; +Cc: Peter Eisentraut <[email protected]>; pgsql-docs
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 <[email protected]> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
Attachments:
[text/x-diff] /rtmp/ecpg (6.1K, 2-%2Frtmp%2Fecpg)
download | inline diff:
diff --git a/doc/src/sgml/ecpg.sgml b/doc/src/sgml/ecpg.sgml
index 9130b12..def250c 100644
--- a/doc/src/sgml/ecpg.sgml
+++ b/doc/src/sgml/ecpg.sgml
@@ -9281,7 +9281,7 @@ risnull(CINTTYPE, (char *) &i);
<listitem>
<para>
Functions return this value if an overflow occurred in a
- calculation. Internally it is defined to -1200 (the <productname>Informix</productname>
+ calculation. Internally it is defined as -1200 (the <productname>Informix</productname>
definition).
</para>
</listitem>
@@ -9292,7 +9292,7 @@ risnull(CINTTYPE, (char *) &i);
<listitem>
<para>
Functions return this value if an underflow occurred in a calculation.
- Internally it is defined to -1201 (the <productname>Informix</productname> definition).
+ Internally it is defined as -1201 (the <productname>Informix</productname> definition).
</para>
</listitem>
</varlistentry>
@@ -9302,7 +9302,7 @@ risnull(CINTTYPE, (char *) &i);
<listitem>
<para>
Functions return this value if an attempt to divide by zero is
- observed. Internally it is defined to -1202 (the <productname>Informix</productname> definition).
+ observed. Internally it is defined as -1202 (the <productname>Informix</productname> definition).
</para>
</listitem>
</varlistentry>
@@ -9312,7 +9312,7 @@ risnull(CINTTYPE, (char *) &i);
<listitem>
<para>
Functions return this value if a bad value for a year was found while
- parsing a date. Internally it is defined to -1204 (the <productname>Informix</productname>
+ parsing a date. Internally it is defined as -1204 (the <productname>Informix</productname>
definition).
</para>
</listitem>
@@ -9323,7 +9323,7 @@ risnull(CINTTYPE, (char *) &i);
<listitem>
<para>
Functions return this value if a bad value for a month was found while
- parsing a date. Internally it is defined to -1205 (the <productname>Informix</productname>
+ parsing a date. Internally it is defined as -1205 (the <productname>Informix</productname>
definition).
</para>
</listitem>
@@ -9334,7 +9334,7 @@ risnull(CINTTYPE, (char *) &i);
<listitem>
<para>
Functions return this value if a bad value for a day was found while
- parsing a date. Internally it is defined to -1206 (the <productname>Informix</productname>
+ parsing a date. Internally it is defined as -1206 (the <productname>Informix</productname>
definition).
</para>
</listitem>
@@ -9346,7 +9346,7 @@ risnull(CINTTYPE, (char *) &i);
<para>
Functions return this value if a parsing routine needs a short date
representation but did not get the date string in the right length.
- Internally it is defined to -1209 (the <productname>Informix</productname> definition).
+ Internally it is defined as -1209 (the <productname>Informix</productname> definition).
</para>
</listitem>
</varlistentry>
@@ -9356,7 +9356,7 @@ risnull(CINTTYPE, (char *) &i);
<listitem>
<para>
Functions return this value if an error occurred during date
- formatting. Internally it is defined to -1210 (the
+ formatting. Internally it is defined as -1210 (the
<productname>Informix</productname> definition).
</para>
</listitem>
@@ -9367,7 +9367,7 @@ risnull(CINTTYPE, (char *) &i);
<listitem>
<para>
Functions return this value if memory was exhausted during
- their operation. Internally it is defined to -1211 (the
+ their operation. Internally it is defined as -1211 (the
<productname>Informix</productname> definition).
</para>
</listitem>
@@ -9379,7 +9379,7 @@ risnull(CINTTYPE, (char *) &i);
<para>
Functions return this value if a parsing routine was supposed to get a
format mask (like <literal>mmddyy</>) but not all fields were listed
- correctly. Internally it is defined to -1212 (the <productname>Informix</productname> definition).
+ correctly. Internally it is defined as -1212 (the <productname>Informix</productname> definition).
</para>
</listitem>
</varlistentry>
@@ -9392,7 +9392,7 @@ risnull(CINTTYPE, (char *) &i);
the textual representation for a numeric value because it contains
errors or if a routine cannot complete a calculation involving numeric
variables because at least one of the numeric variables is invalid.
- Internally it is defined to -1213 (the <productname>Informix</productname> definition).
+ Internally it is defined as -1213 (the <productname>Informix</productname> definition).
</para>
</listitem>
</varlistentry>
@@ -9401,7 +9401,8 @@ risnull(CINTTYPE, (char *) &i);
<term><literal>ECPG_INFORMIX_BAD_EXPONENT</></term>
<listitem>
<para>
- Functions return this value if Internally it is defined to -1216 (the
+ Functions return this value if a parsing routine cannot parse
+ an exponent. Internally it is defined as -1216 (the
<productname>Informix</productname> definition).
</para>
</listitem>
@@ -9411,7 +9412,8 @@ risnull(CINTTYPE, (char *) &i);
<term><literal>ECPG_INFORMIX_BAD_DATE</></term>
<listitem>
<para>
- Functions return this value if Internally it is defined to -1218 (the
+ Functions return this value if a parsing routine cannot parse
+ a date. Internally it is defined as -1218 (the
<productname>Informix</productname> definition).
</para>
</listitem>
@@ -9421,7 +9423,8 @@ risnull(CINTTYPE, (char *) &i);
<term><literal>ECPG_INFORMIX_EXTRA_CHARS</></term>
<listitem>
<para>
- Functions return this value if Internally it is defined to -1264 (the
+ Functions return this value if a parsing routine is passed extra
+ characters is cannot parse. Internally it is defined as -1264 (the
<productname>Informix</productname> definition).
</para>
</listitem>
^ permalink raw reply [nested|flat] 9+ messages in thread
end of thread, other threads:[~2011-06-09 22:48 UTC | newest]
Thread overview: 9+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2011-06-03 09:16 ECPG, sentence not complete Marc Cousin <[email protected]>
2011-06-03 18:10 ` Satoshi Nagayasu <[email protected]>
2011-06-03 18:30 ` Kevin Grittner <[email protected]>
2011-06-04 16:52 ` Marc Cousin <[email protected]>
2011-06-04 19:30 ` Peter Eisentraut <[email protected]>
2011-06-05 09:08 ` Marc Cousin <[email protected]>
2011-06-09 22:48 ` Bruce Momjian <[email protected]>
2011-06-09 22:48 ` Bruce Momjian <[email protected]>
2011-06-04 19:12 ` Peter Eisentraut <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox