Typo corrections, I avoided making changes to words that have regional spelling differences.

docs/src/architecture/platform.md

@@ -616,7 +616,7 @@ follows:
   part of an action's extension definition.
 * `CreateActionProvider` provides the various Create actions which
   populate the Create menu. These are driven by the available types,
-  so do not map easily ot extension category `actions`; instead, these
+  so do not map easily to extension category `actions`; instead, these
   are generated after looking up which actions are available from the
   [`TypeService`](#type-service).
 * `ActionAggregator` merges together actions from multiple providers.

docs/src/design/proposals/APIRedesign.md

@@ -98,7 +98,7 @@ Worked on bug fixes in the platform and a plugin for search.
   It is hard to figure out what the difference between the various ways of
   dealing with telemetry are. e.g., what is the difference between just
   "Telemetry" and the "Telemetry Service"? There are many
-  "Telemetry Thing"s which seem related, but in an unclear way.
+  "Telemetry Things" which seem related, but in an unclear way.
 
 ### Developer Intern 2
 
@@ -456,7 +456,7 @@ Instead, propose that:
 For parity with actions, a `View` would be a constructor which
 takes an `ActionContext` as a parameter (with similarly-defined
 properties) and exposes a method to retrieve the HTML elements
-associateed with it.
+associated with it.
 
 The platform would then additionally expose an `AngularView`
 implementation to improve compatibility with existing

docs/src/design/proposals/APIRedesign_PeteRichards.md

@@ -99,7 +99,7 @@ To reduce interface depth, we can replace our own provider and registry patterns
 
 ## More angular: for all services
 
-Increasing our commitment to angular would mean using more of the angular factorys, services, etc, and less of our home grown tools.  We'd implement our services and extension points as angular providers, and make them configurable via app.config.
+Increasing our commitment to angular would mean using more of the angular factories, services, etc, and less of our home grown tools.  We'd implement our services and extension points as angular providers, and make them configurable via app.config.
 
 As an example, registering a specific type of model provider in angular would look like:
 

docs/src/tutorials/index.md

@@ -3238,7 +3238,7 @@ define(
 __tutorials/telemetry/src/ExampleTelemetryServerAdapter.js__
 
 Here, we have added `subscribe` and `unsubscribe` methods which issue the 
-corresponding requests to the server. Seperately, we introduce the ability to 
+corresponding requests to the server. Separately, we introduce the ability to 
 listen for `data` messages as they come in: These will contain the data associated 
 with these subscriptions.