Send inn-workers mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/inn-workers
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of inn-workers digest..."
Today's Topics:
1. Re: [patch] Spelling fixes (Christoph Biedl)
2. Re: [patch] Spelling fixes (Russ Allbery)
3. Re: [patch] Spelling fixes (Julien ?LIE)
4. Re: [patch] Spelling fixes (Christoph Biedl)
5. Re: [patch] Spelling fixes (Marc Haber)
----------------------------------------------------------------------
Message: 1
Date: Mon, 23 Apr 2018 20:42:12 +0200
From: Christoph Biedl <[email protected]>
To: [email protected]
Subject: Re: [patch] Spelling fixes
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Christoph Biedl wrote...
> I'm attaching a patch below to change that.
Let me add this bit of information: On top of inn-2.6.2.tar.gz
Christoph
------------------------------
Message: 2
Date: Mon, 23 Apr 2018 11:53:34 -0700
From: Russ Allbery <[email protected]>
To: [email protected]
Subject: Re: [patch] Spelling fixes
Message-ID: <[email protected]>
Content-Type: text/plain
Christoph Biedl <[email protected]> writes:
> finally I started converting my sloppyly distributed inn2 installations
> into packages. Along the way, Debian's packaging checker reported quite
> a lot of spelling errors, I'm attaching a patch below to change that.
> As I'm not an English speaker: Please check for possible false
> positives. Most prominentely, I'm not really convinced about changing
> "allows to" into "allows one to", same for "permits".
I haven't looked at this in detail, but for the record, that change is
generally correct. For whatever reason, English doesn't let one say "this
permits to validate control articles" (for instance). I'm not sure I have
the details of the grammar exactly right, but the way I'd think of it is
that "permits" is a transitive verb that needs some sort of object (some
action to be permitted or some person who is being permitted). The
infinitive "to validate" can't normally function in English as a noun, so
it can't be the object of a verb.
You have to either say "this permits one to validate control articles" (so
"one" is the person being permitted), or say "this permits validating
control articles" (the gerund phrase "validating control articles" is the
action being permitted). Or "this permits validation of control
articles," which provides a regular noun object.
"Allows" is indeed the same issue.
As a matter of style, I'd probably prefer "this permits validation of
control articles," since it seems shorter and more direct than "this
permits one to validate control articles." The "one" there is a sort of
abstract grammatical placeholder that isn't adding much to the meaning of
the sentence. But that sort of rephrasing is far more of a style thing
than a correctness thing.
Lintian of course can't recommend the last form because there is no
general automated transformation from the infinitive of a verb ("to
validate") to a noun ("validation"), so it recommends the correction
that's the most generally applicable. It's almost always safe
grammatically to just insert "one," even if it's not great style.
--
Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/>
Please send questions to the list rather than mailing me directly.
<http://www.eyrie.org/~eagle/faqs/questions.html> explains why.
------------------------------
Message: 3
Date: Mon, 23 Apr 2018 21:07:53 +0200
From: Julien ?LIE <[email protected]>
To: [email protected]
Subject: Re: [patch] Spelling fixes
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Hi Christoph,
> I'm not really convinced about changing "allows to" into "allows one
> to", same for "permits".
I'm not also convinced by the need to change for instance "The new -c flag
permits to send" by "The new -c flag permits one to send".
--- a/doc/man/clientlib.3
+++ b/doc/man/clientlib.3
@@ -19,7 +19,7 @@ clientlib \- NNTP clientlib part of InterNetNews library
.B "int"
.B "handle_server_response(response, host)"
-.B " int reponse;"
+.B " int response;"
.B " char *host;"
I would suggest:
=> handle_server_response(int response, char *host)
Thanks for your message.
I've noted the following changes to do. I'll soon commit them.
--- a/control/pgpverify.in
-# accomodate the new build process of INN 2.5.
+# accommodate the new build process of INN 2.5.
-# the script, to accomodate the build process of INN.
+# the script, to accommodate the build process of INN.
--- a/doc/pod/checklist.pod
-accomodated. If you want to throw away large articles, do it explicitly
+accommodated. If you want to throw away large articles, do it explicitly
--- a/doc/pod/inndf.pod
-space rather than grow to accomodate more records. Currently, this flag
+space rather than grow to accommodate more records. Currently, this flag
--- a/lib/inndcomm.c
- /* Adjust the socket buffer size to accomodate large responses. Ignore
+ /* Adjust the socket buffer size to accommodate large responses. Ignore
--- a/doc/man/history.5
-recieved at 26 Aug 1999 08:06:54 GMT, could have a
+received at 26 Aug 1999 08:06:54 GMT, could have a
--- a/doc/pod/readers.conf.pod
-Alternatively, a res block can be used instead of a res: paramater.
+Alternatively, a res block can be used instead of a res: parameter.
--- a/doc/pod/uwildmat.pod
-characters, and has noticable functionality changes. Any bugs present in
+characters, and has noticeable functionality changes. Any bugs present in
--- a/frontends/inews.c
- die("emtpy control message");
+ die("empty control message");
--- a/innfeed/connection.c
- /* Now handle possible remaining partial reponse and set up for
+ /* Now handle possible remaining partial response and set up for
- * This is called when the timeout for the reponse from the remote
+ * This is called when the timeout for the response from the remote
- * process the "send article to be transfered" reponse to the IHAVE.
+ * process the "send article to be transfered" response to the IHAVE.
- * process the "not wanted" reponse to the IHAVE.
+ * process the "not wanted" response to the IHAVE.
- warn ("%s:%d cxnsleep message-id missing in reponse code %d: %s",
+ warn ("%s:%d cxnsleep message-id missing in response code %d: %s",
- warn ("%s:%d cxnsleep message-id invalid message-id in reponse code"
+ warn ("%s:%d cxnsleep message-id invalid message-id in response code"
- XXX - would be nice to have a timeout for reponses if we're sending a
+ XXX - would be nice to have a timeout for responses if we're sending a
--- a/innfeed/host.h
- * RESPTIMEOUT is the max amount of time we'll wait for any reponse
+ * RESPTIMEOUT is the max amount of time we'll wait for any response
--- a/innfeed/imap_connection.c
- * This is called when the timeout for the reponse from the remote
+ * This is called when the timeout for the response from the remote
- * This is called when the timeout for the reponse from the remote
+ * This is called when the timeout for the response from the remote
--- a/innfeed/misc.h
-/* parse a reponse line into it's code and body. *rest will end up pointing
+/* parse a response line into it's code and body. *rest will end up pointing
--- a/lib/dbz.c
- initalized in dbzinit */
+ initialized in dbzinit */
--- a/storage/cnfs/cnfs.c
- warn("CNFS: all cycbuff entries shoud be before metacycbuff"
+ warn("CNFS: all cycbuff entries should be before metacycbuff"
--- a/storage/tradindexed/tradindexed.c
-** Set various options or query various paramaters for the overview method.
+** Set various options or query various parameters for the overview method.
--- a/innd/innd.c
- die("SERVER cant initalize storage manager: %s", SMerrorstr);
+ die("SERVER cant initialize storage manager: %s", SMerrorstr);
--- a/frontends/ovdb_server.c
- /* shoudn't happen... */
+ /* shouldn't happen... */
--- a/expire/fastrm.c
-** initalize various global variables, and then go into a loop calling
+** initialize various global variables, and then go into a loop calling
--- a/doc/pod/libinnhist.pod
-specifed as <= 0 in which case that component shall be treated as
+specified as <= 0 in which case that component shall be treated as
-I<expired> may be specifed as <= 0 in which case that component shall
+I<expired> may be specified as <= 0 in which case that component shall
-hierachical storage management implementation).
+hierarchical storage management implementation).
--- a/doc/pod/control.ctl.pod
-to decode the sentence as CP1242 and reencode it as UTF-8.
+to decode the sentence as CP1242 and re-encode it as UTF-8.
--- a/doc/man/nntpget.1
+++ b/doc/man/nntpget.1
-succeedes, the file will be updated with a statistics line, modifying its
+succeeds, the file will be updated with a statistics line, modifying its
--
Julien ?LIE
??? Comment s'appelle cette ville??
? Divodurum.
? N'essaie pas de m'amadouer?! Non, je ne veux pas de rhum?!??
(Ast?rix)
------------------------------
Message: 4
Date: Tue, 24 Apr 2018 08:16:20 +0200
From: Christoph Biedl <[email protected]>
To: [email protected]
Subject: Re: [patch] Spelling fixes
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Russ Allbery wrote...
[ changing "allows to" into "allows one to" ]
> I haven't looked at this in detail, but for the record, that change is
> generally correct.
Thanks a lot for the lengthy explanation and the time to write it down,
things look a lot more clear to me now. About lintian, I might file a
bug report to improve the situation when time permits. While the program
certainly cannot simply create the "allows to <noun>" form, I see ways
to provide a recommendation for the better style by other means. This is
something for Debian's bugtracker, not here.
Regards,
Christoph
------------------------------
Message: 5
Date: Tue, 24 Apr 2018 12:03:24 +0200
From: Marc Haber <[email protected]>
To: [email protected]
Subject: Re: [patch] Spelling fixes
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
On Mon, Apr 23, 2018 at 09:07:53PM +0200, Julien ?LIE wrote:
> > I'm not really convinced about changing "allows to" into "allows one
> > to", same for "permits".
> I'm not also convinced by the need to change for instance "The new -c flag
> permits to send" by "The new -c flag permits one to send".
Not being a native speaker either, my gut feeling would prefer "The new
-c flag permits sending"...
Greetings
Ma "comp.lang.english anyone?" rc
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
------------------------------
Subject: Digest Footer
_______________________________________________
inn-workers mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/inn-workers
------------------------------
End of inn-workers Digest, Vol 105, Issue 3
*******************************************
