Fix a few more typos

design/real_time_collab.md

@@ -22,7 +22,7 @@ Jon and his collaborators need the ability to do ad-hoc collaboration on particu
 are already version controlling their code, documentation and notebooks, but at times, Git/GitHub
 don't provide fast enough collaborative interactions. They want to continue to work on their local
 systems, with their own local notebook servers, but need to be able to initiate the RTC of
-one or more files or a diretory of files with a group of individuals.
+one or more files or a directory of files with a group of individuals.
 
 During the RTC sessions, the participants are focused on the following aspects of their
 work:
@@ -33,9 +33,9 @@ work:
 
 All individuals in the collaboration already have access to the files (Git/GitHub).
 Because of this, during the RTC they need to be able to collaborative edit the same exact
-version, which will later be commmited to the repository. Because of this, only one participant
+version, which will later be committed to the repository. Because of this, only one participant
 would have a live filesystem representation of the edited file. At the end of the ad-hoc RTC session,
-the inviduals would go back to syncing their changes through GitHub.
+the individuals would go back to syncing their changes through GitHub.
 
 ## The MTTU Scientific Collaboration
 
@@ -45,7 +45,7 @@ ten year observing cycle. Once operational, they will collect petabytes of data
 accessed by thousands of scientific users.
 
 The collaboration has a software stack based on Python and C++ and is embracing modern,
-software engieering practices (version control with Git/GitHub, Travis, Slack, etc.). They version
+software engineering practices (version control with Git/GitHub, Travis, Slack, etc.). They version
 control everything and run an extensive test suite on each commit. The collaboration is exploring the possibility of using JupyterHub to provide a unified user-experience for their users to access data
 and their analysis software.
 

packages/observables/README.md

@@ -1,3 +1,3 @@
 # @jupyterlab/observables
 
-A JupyterLab package which provides data structures (such as strings, lists, and maps), which can be listended to for changes.
+A JupyterLab package which provides data structures (such as strings, lists, and maps), which can be listened to for changes.

packages/rendermime-interfaces/README.md

@@ -8,7 +8,7 @@ The interfaces in this package are meant to give an easier way for extension aut
 to provide a plugin that renders mime bundles and documents of a specific mime type.
 
 When using these interfaces, extensions only need to provide some metadata about
-wht kind of mime bundle they are able to render, and a `Widget` with
+what kind of mime bundle they are able to render, and a `Widget` with
 a `renderModel` method that renders the mime bundle.
 
 Examples can be found in [@jupyterlab/vega5-extension](../vega5-extension) and [@jupyterlab/pdf-extension](../pdf-extension).

packages/ui-components/CONTRIBUTING.md

@@ -23,7 +23,7 @@ Design goals for JLIcon (already implemented):
   - where an icon is defined should not matter; all icons defined in core and extensions are reusable in any other extension
 - replacable
   - all icons can be customized by replacing their svg dynamically during runtime
-  - replacability does not depend on dynamic lookup (you can assign to the `.svgstr` property of any `LabIcon` instance to trigger replacement)
+  - replaceability does not depend on dynamic lookup (you can assign to the `.svgstr` property of any `LabIcon` instance to trigger replacement)
   - whenever its svg is replaced, all visible copies of an icon should immediately rerender
     - implementation, which depends on the method used to render the icon:
       - `LabIcon.element` method
@@ -50,7 +50,7 @@ Possible design patterns for JLIcon:
 2. each icon is a function with methods (ie a callable instance). The icon is used by calling the appropriate method
 3. each icon is an instance of a well-defined `class`. The icon is used by calling the appropriate instance method
 
-Patterns 1) and 2) were both initially investigated (see [jupyterlab/jupyterlab#7299](https://github.com/jupyterlab/jupyterlab/pull/7299)). Pattern 3) was found to be easiest to reason about, and had a desirable set of tradeoffs relating to features like dynamic lookup and replacability (eg you can replace the svg of an icon by just setting the `svgstr` field of the icon instance).
+Patterns 1) and 2) were both initially investigated (see [jupyterlab/jupyterlab#7299](https://github.com/jupyterlab/jupyterlab/pull/7299)). Pattern 3) was found to be easiest to reason about, and had a desirable set of tradeoffs relating to features like dynamic lookup and replaceability (eg you can replace the svg of an icon by just setting the `svgstr` field of the icon instance).
 
 ## How icon resolution works