diff --git a/public/docs/ts/latest/guide/router.jade b/public/docs/ts/latest/guide/router.jade
index f476f43736..2470f006d7 100644
--- a/public/docs/ts/latest/guide/router.jade
+++ b/public/docs/ts/latest/guide/router.jade
@@ -779,7 +779,7 @@ code-example(format="." language="bash").
     the value `15` in the path clearly distinguishes the route to "Magneta" from
     a route for some other hero.
 
-    An [optional-route-parameter](#optional-route-parameter) might be a better choice if we were passing an *optional* value to `HeroDetailComponent`.
+    An [optional-route-parameter](#optional-route-parameters) might be a better choice if we were passing an *optional* value to `HeroDetailComponent`.
 
 a#navigate
 :marked
@@ -986,7 +986,7 @@ figure.image-display
   doing so greatly complicates the pattern matching required to translate an incoming URL to a named route.
 
   Optional parameters are the ideal vehicle for conveying arbitrarily complex information during navigation.
-  Optional parameters aren't involved in pattern matching and affords enormous flexibility of expression.
+  Optional parameters aren't involved in pattern matching and afford enormous flexibility of expression.
 
   The Router supports navigation with optional parameters as well as required route parameters.
   We define _optional_ parameters in an *object* after we define our required route parameters.
@@ -1817,7 +1817,7 @@ h3#can-deactivate-guard <i>CanDeactivate</i>: handling unsaved changes
   Users update crisis information in the `CrisisDetailComponent`.
   Unlike the `HeroDetailComponent`, the user changes do not update the
   crisis entity immediately. We update the entity when the user presses the *Save* button.
-  We discard the changes if the user presses he *Cancel* button.
+  We discard the changes if the user presses the *Cancel* button.
 
   Both buttons navigate back to the crisis list after save or cancel.
 
@@ -1922,7 +1922,7 @@ h3#resolve-guard <i>Resolve</i>: pre-fetching component data
 +makeExample('app/crisis-center/crisis-detail-resolve.service.ts', '')
 
 :marked
-  We'll take the relevant parts of the `ngOnInit` lifecycle hook in our `CrisisDetailComponent` and moved them into our `CrisisDetailResolve` guard.
+  We'll take the relevant parts of the `ngOnInit` lifecycle hook in our `CrisisDetailComponent` and move them into our `CrisisDetailResolve` guard.
   We import the `Crisis` model and `CrisisService` and also the `Router` for navigation from our resolve implementation. We want to be explicit about
   the data we are resolving, so we implement the `Resolve` interface with a type of `Crisis`. This lets us know that what we will resolve will match our
   `Crisis` model. We inject the `CrisisService` and `Router` and implement the `resolve` method that supports a `Promise`, `Observable` or a synchronous