--- a/cut.en.ms	Sun Aug 16 23:03:04 2015 +0200
+++ b/cut.en.ms	Sat Sep 12 12:18:52 2015 +0200
@@ -108,13 +108,13 @@
 passwd file. Beyond that, it soon reaches its limits. The typical
 case of whitespace-separated fields, in particular, is covered
 poorly by it. Cut's delimiter is exactly one character,
-therefore one may not split at both space and tab characters.
+therefore one can not split at both space and tab characters.
 Furthermore, multiple adjacent delimiter characters lead to
 empty fields. This is not the expected behavior for
 the processing of whitespace-separated fields. Some
 implementations, e.g. the one of FreeBSD, have extensions that
-handle this case in the expected way. Apart from that, i.e.
-if one likes to stay portable, awk comes to rescue.
+handle this case in the expected way. On other systems or
+to stay portable, awk comes to rescue.
 .PP
 Awk provides another functionality that cut lacks: Changing the order
 of the fields in the output. For cut, the order of the field
@@ -237,9 +237,9 @@
 Multi-byte support
 .LP
 The byte mode and thus the multi-byte support of the POSIX
-character mode have benn standardized since 1992. But
-how about their presence in the available implementations?
-Which versions implement POSIX correctly?
+character mode have been standardized since 1992. But are
+they present in the available implementations? Which versions
+implement POSIX correctly?
 .PP
 The situation is divided into three parts: There are historic
 implementations, which have only \f(CW-c\fP and \f(CW-f\fP.
@@ -252,8 +252,9 @@
 that implement \f(CW-c\fP and \f(CW-b\fP in a POSIX-compliant
 way.
 .PP
-Historic two-mode implementations are the ones of 
-System III, System V, and the BSD ones until the mid-90s.
+Historic two-mode implementations are the ones of
+System III, System V, and the BSD ones from the beginning
+until the mid-90s.
 .PP
 Pseudo multi-byte implementations are provided by GNU,
 modern NetBSD, and modern OpenBSD. The level of POSIX compliance