diff --git a/src/glossary.md b/src/glossary.md
index 81eb62bc9..bff2a6557 100644
--- a/src/glossary.md
+++ b/src/glossary.md
@@ -43,7 +43,7 @@ region                  |  another term for "lifetime" often used in the literat
 sess                    |  the compiler session, which stores global data used throughout compilation
 side tables             |  because the AST and HIR are immutable once created, we often carry extra information about them in the form of hashtables, indexed by the id of a particular node.
 sigil                   |  like a keyword but composed entirely of non-alphanumeric tokens. For example, `&` is a sigil for references.
-skolemization           |  a way of handling subtyping around "for-all" types (e.g., `for<'a> fn(&'a u32)` as well as solving higher-ranked trait bounds (e.g., `for<'a> T: Trait<'a>`). See [the chapter on skolemization and universes](./mir-regionck.html#skol) for more details.
+skolemization           |  a way of handling subtyping around "for-all" types (e.g., `for<'a> fn(&'a u32)`) as well as solving higher-ranked trait bounds (e.g., `for<'a> T: Trait<'a>`). See [the chapter on skolemization and universes](./mir-regionck.html#skol) for more details.
 soundness               |  soundness is a technical term in type theory. Roughly, if a type system is sound, then if a program type-checks, it is type-safe; i.e. I can never (in safe rust) force a value into a variable of the wrong type. (see "completeness").
 span                    |  a location in the user's source code, used for error reporting primarily. These are like a file-name/line-number/column tuple on steroids: they carry a start/end point, and also track macro expansions and compiler desugaring. All while being packed into a few bytes (really, it's an index into a table). See the Span datatype for more.
 substs                  |  the substitutions for a given generic type or item (e.g. the `i32`, `u32` in `HashMap<i32, u32>`)
diff --git a/src/mir-regionck.md b/src/mir-regionck.md
index 571d7c673..e7b12405a 100644
--- a/src/mir-regionck.md
+++ b/src/mir-regionck.md
@@ -12,7 +12,7 @@ The MIR-based region analysis consists of two major functions:
 - `replace_regions_in_mir`, invoked first, has two jobs:
   - First, it finds the set of regions that appear within the
     signature of the function (e.g., `'a` in `fn foo<'a>(&'a u32) {
-    ... }`. These are called the "universal" or "free" regions -- in
+    ... }`). These are called the "universal" or "free" regions -- in
     particular, they are the regions that [appear free][fvb] in the
     function body.
   - Second, it replaces all the regions from the function body with
@@ -164,7 +164,8 @@ are in scope within some type or at some point. Universes are formed
 into a tree, where each child extends its parents with some new names.
 So the **root universe** conceptually contains global names, such as
 the the lifetime `'static` or the type `i32`. In the compiler, we also
-put generic type parameters into this root universe. So consider
+put generic type parameters into this root universe (in this sense,
+there is not just one root universe, but one per item). So consider
 this function `bar`:
 
 ```rust
@@ -175,7 +176,7 @@ fn bar<'a, T>(t: &'a T) {
 }
 ```
 
-Here, the root universe would consider of the lifetimes `'static` and
+Here, the root universe would consist of the lifetimes `'static` and
 `'a`.  In fact, although we're focused on lifetimes here, we can apply
 the same concept to types, in which case the types `Foo` and `T` would
 be in the root universe (along with other global types, like `i32`).
@@ -214,7 +215,7 @@ fn bar<'a, T>(t: &'a T) {
 ```
 
 When we enter *this* type, we will again create a new universe, which
-let's call `U2`. It's parent will be the root universe, and U1 will be
+we'll call `U2`. Its parent will be the root universe, and U1 will be
 its sibling:
 
 ```