Revisions per Robbie, Ingo

docs/en/04_Changelogs/4.0.0.md

@@ -27,12 +27,11 @@ guide developers in preparing existing 3.x code for compatibility with 4.0
   is required.
 * All code earlier marked as deprecated for 4.0 has now been removed. See
   [deprecation documentation](/contributing/release_process) for information on code deprecation.
-* All code has been migrated to follow the PSR-2 coding standard. most significantly, all SilverStripe
+* All code has been migrated to follow the PSR-2 coding standard. Most significantly, all SilverStripe
  classes are now namespaced, and some have been renamed. This has major implications for
   arrangement of templates, as well as other references to classes via string literals or configuration.
   Automatic upgrading tools have been developed to cope with the bulk of these changes (see
-  [upgrading notes](#upgrading)). Each class has been arrange in a single file per class, and it is recommended
-  that user code follows the same convention.
+  [upgrading notes](#upgrading)). Some classes have been rearranged so that each file contains only one class definition. It is recommended that user code follow the same convention.
   For example, page types and their controllers should longer be collated in a single file.
 * Object class has been removed.
 * Asset storage has been abstracted, and a new concept of `DBFile` references via database column references
@@ -105,7 +104,7 @@ The rename won't affect class-based permission codes or database table names.
 
 ##### Upgrade references to literal or class table names
 
-In 3.x the class name of any dataobject matched the table name, but in 4.x all classes are namespaced, and it is
+In 3.x the class name of any DataObject matched the table name, but in 4.x all classes are namespaced, and it is
 necessary to map between table and class for querying the database.
 
 In order to ensure you are using the correct table for any class a new
@@ -133,14 +132,15 @@ You'll need to update any strings that represent class names and make sure they'
 qualified. In particular, relationship definitions such as `has_one` and `has_many` will need
 to be updated to refer to fully qualified class names.
 
-In configs and with literal php strings it is recommended to use the php `::class` constant,
+In configs and with literal PHP strings it is recommended to use the php `::class` constant,
 as demonstrated below.
 
 ```diff
 <?php
 + use SilverStripe\ORM\DataObject;
 + use SilverStripe\Security\Member;
-class MyClass extends DataObject {
+class MyClass extends DataObject 
+{
     private static $has_one = [
     -  'Author' => 'Member',
     +  'Author' => Member::class,
@@ -148,7 +148,7 @@ class MyClass extends DataObject {
 }
 ```
  
-In the context of YAML, the magic constant `::class` does not apply. Class names must be hard coded.
+In the context of YAML, the magic constant `::class` does not apply. Fully qualified class names must be hard coded.
 
 ```diff
 -MyObject:
@@ -158,9 +158,9 @@ In the context of YAML, the magic constant `::class` does not apply. Class names
 
 ##### Update references to literal classes to use Injector
 
-In many places certain classes namespaced in SilverStripe 4.x will still have a non-namespaced service
-name reference that can be referred to with injector. You should upgrade direct object constructors with
-Injector api.
+In many places, classes namespaced in SilverStripe 4.x will still have a non-namespaced service
+name that can be accessed via Injector. You should upgrade direct object constructors with
+the Injector API.
 
 E.g.
 
@@ -1260,13 +1260,13 @@ of linked components are consistent with their "owner." Without the concept of o
 components could be implicitly exposed on the frontend, which may not align with the intent of the
 content author.
 
-For instance, on a products page which has a list of products, the products should not be published or
- unpublished unless the products page is, too. The ownership API solves this by allowing you to declare
+For instance, on a products page which has a list of products, the products should not be published unless the products page is, too. The ownership API solves this by allowing you to declare
  a two-way relationship between objects, typically, but not necessarily, linked by a database relationship
  (`has_many`, `many_many`, etc.).
 
 ```php
-class ProductPage extends Page {
+class ProductPage extends Page 
+{
     private static $has_many = [
         'Products' => Product::class
     ];
@@ -1276,7 +1276,8 @@ class ProductPage extends Page {
     ];
 }
 
-class Product extends DataObject {
+class Product extends DataObject 
+{
     private static $extensions = [
         Versioned::class
     ];
@@ -1290,10 +1291,7 @@ If your objects are linked by something other than a database relationship, for
 getter that is computed at runtime, the same rules can be applied, as long as you provide an `$owned_by`
 setting on the child object.
 
-For more information, see:
-
-* The [DataObject ownership](https://docs.silverstripe.org/en/4/developer_guides/model/versioning/#dataobject-ownership) documentation
-* The [versioned](/developer_guides/model/versioning) documentation
+For more information, see the [DataObject ownership](https://docs.silverstripe.org/en/4/developer_guides/model/versioning/#dataobject-ownership) documentation and the [versioning](/developer_guides/model/versioning) documentation
 
 #### ChangeSet batch publishing
 
@@ -1534,7 +1532,7 @@ automated as possible.
 
 ##### Using the upgrader tool to automatically apply namespaces
 
-HThe [upgrader tool](https://github.com/silverstripe/silverstripe-upgrader/) provides a feature
+The [upgrader tool](https://github.com/silverstripe/silverstripe-upgrader/) provides a feature
 to not only automatically namespace code, but will provide automatic upgrade of other code
 references to those classes.