Router typos

public/docs/ts/latest/guide/router.jade

@@ -728,7 +728,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
@@ -935,7 +935,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.
@@ -1795,7 +1795,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.
 
@@ -1900,7 +1900,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

public/docs/ts/latest/guide/testing.jade

@@ -438,7 +438,7 @@ a#simple-component-test
 +makeExample('testing/ts/app/banner.component.spec.ts', 'imports', 'app/banner.component.spec.ts (imports)')(format='.')
 :marked
   Here's the setup for the tests followed by observations about the `beforeEach`:
-+makeExample('testing/ts/app/banner.component.spec.ts', 'setup', 'app/banner.component.spec.ts (imports)')(format='.')
++makeExample('testing/ts/app/banner.component.spec.ts', 'setup', 'app/banner.component.spec.ts (setup)')(format='.')
 :marked
   `TestBed.configureTestingModule` takes an `@NgModule`-like metadata object.
   This one simply declares the component to test, `BannerComponent`.