--- a/cut.en.ms	Fri Sep 18 10:28:29 2015 +0200
+++ b/cut.en.ms	Fri Oct 02 07:01:20 2015 +0200
@@ -73,7 +73,7 @@
 .LP
 The remainder can be caught with \f(CWcut -b 501-\fP. This
 use of cut is important for POSIX, because it provides a
-transformation of text files with arbitrary line lenghts to text
+transformation of text files with arbitrary line lengths to text
 files with limited line length
 .[[ http://pubs.opengroup.org/onlinepubs/9699919799/utilities/cut.html#tag_20_28_17 .
 .PP
@@ -104,7 +104,7 @@
 (The values to the command line switches may be appended directly
 to them or separated by whitespace.)
 .PP
-The field mode is suited for simple tabulary data, like the
+The field mode is suited for simple tabular data, like the
 password 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,
@@ -222,7 +222,7 @@
 programs already existed that were able to cover its use
 cases. One reason for cut surely was its compactness and the
 resulting speed, in comparison to the then-bulky awk. This lean
-shape goes well with the Unix philosopy: Do one job and do it
+shape goes well with the Unix philosophy: Do one job and do it
 well! Cut was sufficiently convincing. It found its way to
 other Unix variants, it became standardized, and today it is
 present everywhere.
@@ -276,8 +276,8 @@
 conforming to POSIX, in the summer of 2004
 .[[ https://svnweb.freebsd.org/base?view=revision&revision=131194 .
 The question why the other BSD systems have not
-integrated this change is an open one. Maybe the answer can be
-found in the above quoted statement.
+integrated this change is an open one. Maybe the answer is
+a general ignorance of internationalization.
 .PP
 How do users find out if the cut on their own system handles
 multi-byte characters correctly? First, one needs to check if