diff --git a/docs/en/04_Changelogs/4.0.0.md b/docs/en/04_Changelogs/4.0.0.md
index bc6c0c9fd..aa8bdde05 100644
--- a/docs/en/04_Changelogs/4.0.0.md
+++ b/docs/en/04_Changelogs/4.0.0.md
@@ -12,7 +12,7 @@
  * `DataObject::ClassName` field has been refactored into a `DBClassName` type field.
  * Image manipulations have been moved into a new `[api:ImageManipulation]` trait.
  * `CMSFileAddController` removed.
- * UploadField::setAllowedFileCategories('image') now excludes non-resizeable images. 'unresizeable_image' is
+ * `UploadField::setAllowedFileCategories('image')` now excludes non-resizeable images. 'unresizeable_image' is
    can be used to validate these types.
  * `Image_Backend` API now loads and saves from `AssetContainer` instances rather than local files.
  * The following File categories have been renamed: 'zip' to 'archive', 'doc' to 'document', and 'mov' to 'video'
@@ -32,7 +32,7 @@
  * Updated PHPUnit from 3.7 to 4.8 ([upgrade notes](https://github.com/sebastianbergmann/phpunit/wiki/Release-Announcement-for-PHPUnit-4.0.0#backwards-compatibility-issues)). 
    Please remove any PHPUnit related `require_once()` calls (e.g. in `FeatureContext` 
    definitions of the [behat-extension](https://github.com/silverstripe-labs/silverstripe-behat-extension) module).
-   Run `composer require --dev 'phpunit/phpunit:~4.8' on existing projects to pull in the new dependency.
+   Run `composer require --dev 'phpunit/phpunit:~4.8'` on existing projects to pull in the new dependency.
  * `Object::invokeWithExtensions` now has the same method signature as `Object::extend` and behaves the same way.
 
 ## New API
@@ -64,9 +64,9 @@
  * `HtmlEditorField::setEditorConfig` may now take an instance of a `HtmlEditorConfig` class, as well as a
    standard config identifier name.
  * A lot of standard versioned API has been refactored from `SiteTree` into `Versioned` extension. Now
-   all versioned DataObjects have canPublish(), canArchive(), canUnpublish(), doPublish(), doArchive()
-   doUnpublish(), isPublished() and isonDraft() out of the box. However, do*() methods will no longer
-   automatically check can*() permissions, and must be done by usercode before invocation.
+   all versioned DataObjects have `canPublish()`, `canArchive()`, `canUnpublish()`, `doPublish()`, `doArchive()`
+   `doUnpublish()`, `isPublished()` and `isonDraft()` out of the box. However, `do*()` methods will no longer
+   automatically check `can*()` permissions, and must be done by usercode before invocation.
  * GridField edit form now has improved support for versioned DataObjects, with basic publishing
    actions available when editing records.
 
@@ -323,8 +323,8 @@ E.g.
 
 ### Upgrading code that writes to `File` dataobjects, or writes files to the 'assets' folder
 
-In the past all that was necessary to write a `File` dataobject to the database was to ensure a physical file
-existed in the assets folder, and that the Filename of the dataobject was set to the same location.
+In the past all that was necessary to write a `File` DataObject to the database was to ensure a physical file
+existed in the assets folder, and that the Filename of the DataObject was set to the same location.
 
 Since the storage of physical files is no longer a standard location, it's necessary to delegate the writing of such
 files to the asset persistence layer. As a wrapper for an individual file, you can use any of the `setFrom*`
@@ -364,10 +364,10 @@ stored in the assets folder.
 There are other important considerations in working with File dataobjects which differ from legacy:
 
 * File synchronisation is no longer automatic. This is due to the fact that there is no longer a 1-to-1 relationship
-  between physical files and File dataobjects.
-* Folder dataobjects are now purely logical dataobjects, and perform no actual filesystem folder creation on write.
+  between physical files and File DataObjects.
+* Folder DataObjects are now purely logical DataObjects, and perform no actual filesystem folder creation on write.
 * All Files are versioned, which means that by default, new File records will not be visibile
-  to the public site. You will need to make sure to invoke ->doPublish() on any File dataobject
+  to the public site. You will need to make sure to invoke `->doPublish()` on any File DataObject
   you wish visitors to be able to see.
 
 You can disable File versioning by adding the following to your _config.php
@@ -433,7 +433,7 @@ After:
 
 There are a few differences in this new API:
 
-* The extension is no longer specific to dataobjects, so it uses the generic 'Extension' class instead of 'DataExtension'
+* The extension is no longer specific to DataObjects, so it uses the generic 'Extension' class instead of 'DataExtension'
 * This extension is added to both `DBFile` and `File`, or order to make this manipulation available to non-dataobject
   file references as well, but it could be applied to either independently.
 * A helper method `variantName` is invoked in order to help generate a unique variant key. Custom code may use another
@@ -568,7 +568,7 @@ E.g.
 
 ### Upgrading asset web.config, .htaccess, or other server configuration
 
-Server configuration files for /assets are no longer static, and are regenerated via a set of
+Server configuration files for `/assets` are no longer static, and are regenerated via a set of
 standard silverstripe templates on flush. These templates include:
 
  * `Assets_HTAccess.ss`: Template for public permissions on the Apache server.
@@ -579,7 +579,7 @@ standard silverstripe templates on flush. These templates include:
 You will need to make sure that these files are writable via the web server, and that any necessary
 configuration customisation is done via overriding these templates.
 
-If upgrading from an existing installation, make sure to invoke ?flush=all at least once.
+If upgrading from an existing installation, make sure to invoke `?flush=all` at least once.
 
 See [/developer_guides/files/file_security] for more information.