Re: [PATCH] docs: fix grammar and punctuation of 2.26 release notes

[Peter Cordes <peter@cordes.ca>]

On Sat, Jan 17, 2015 at 06:56:43PM +0100, Benno Schulenberg wrote:
> 
> On Fri, Jan 16, 2015, at 04:15, Peter Cordes wrote:
> > > + The new version no longer supports some obscure MBR-specific command-line
> > >   options and legacy CHS addressing.
> > 
> >  s/and/or/ in the last line.  "no longer supports x or y" is the proper
> > usage here.
> 
> Hmm.   I would tend to use "nor" here.  It may not be grammatical or
> proper usage, but I think it is the most clear.  ("No longer foo or bar"
> works fine, but "no longer foo-foo-baz-foo-baz or bar" is unclear to me --
> the negation has been mostly forgotten when the eye arrives at "or bar".
> The "nor" is then a nice reminder.)

 You're right, nor might actually be more proper.  And agree on using
it to avoid ambiguity.

> 
> > > +   -o for mount(8); it's now possible to specify swap options on the command
> > > +   line by the same string as in fstab
> > 
> >  I think "with the same string", rather than "by the same string".
> 
> Well, "is specified by" gives me many more google hits than "is specified with".

 "Is specified by <name of standard / person / organization>" is common usage.
 "Is specified with <how you specify it>" is a strange usage that I'm
not sure is correct.  What I am pretty sure about is that "by" isn't
correct usage for the 2nd case.  If we were writing a book, I'd
probably think of a way to reword the whole sentence.

 Perhaps "using the same string as in fstab"?  I think that sounds
less clunky than either "by" or "with".

> This comparison may not be valid, but I think "by" is okay here.  And even if
> most native speakers would prefer "with" here, I think it's fine to let some of
> the foreignness of Karel's tongue sound through in his text.

 I agree that the meaning is still clear, so it doesn't really need a
change.

>  
> > > +The debug infrastructure in the libraries libmount, libsmartcolsm, libfdisk and
> > > +libblkid allows to specify debug options by human-readable strings too. For
> > >  example "LIBMOUNT_DEBUG=all mount /mnt".
> > 
> > "libblkid allows specifying debug options with human-readable strings, too. For"
> > 
> >  would read a bit better.
> 
> To a native speaker probably yes.

 Definitely, not just probably.  The meaning is totally clear, but I
don't think any native speaker would have used "by" instead of "with"
or "as".

>  But I'm trying to make the minimum
> amount of changes, fixing just the things where my comprehension is
> hindered.

 Fair enough.  I didn't think it would be a problem to make more
changes around lines you're already changing anyway, but if there's a
downside, it can stay.

>  There's no need to make this text into "English English";
> "understandable and acceptable foreigner English" seems good enough.

 Yup, "acceptable foreigner English" is a good description of a lot of
free software docs.  I agree it's not worth the time to try to get
global open-source projects up to the level a book editor would be
happy with.  It just caught my interest, so I took the time, and
probably found some changes just for the sake of changing something.


> Thanks for the review.
> Shall I add a Reviewed-by tag to V2?  Or an Acked-by?

 Either would be cool.  I'm not too familiar with the usual practices
for tagging git commits, so whichever you think is most appropriate
would be appreciated.

-- 
#define X(x,y) x##y
Peter Cordes ;  e-mail: X(peter@cor , des.ca)

"The gods confound the man who first found out how to distinguish the hours!
 Confound him, too, who in this place set up a sundial, to cut and hack
 my day so wretchedly into small pieces!" -- Plautus, 200 BC