Fixing few typos in the documentation (#3103)

* few typos / small grammatical errors corrected in documentation

* one more typo

* one last typo

website/usage/_linguistic-features/_named-entities.jade

@@ -159,7 +159,7 @@ p
     |  To provide training examples to the entity recogniser, you'll first need
     |  to create an instance of the #[+api("goldparse") #[code GoldParse]] class.
     |  You can specify your annotations in a stand-off format or as token tags.
-    |  If a character offset in your entity annotations don't fall on a token
+    |  If a character offset in your entity annotations doesn't fall on a token
     |  boundary, the #[code GoldParse] class will treat that annotation as a
     |  missing value.  This allows for more realistic training, because the
     |  entity recogniser is allowed to learn from examples that may feature

website/usage/_linguistic-features/_rule-based-matching.jade

@@ -444,7 +444,7 @@ p
     |  Let's say you're analysing user comments and you want to find out what
     |  people are saying about Facebook. You want to start off by finding
     |  adjectives following "Facebook is" or "Facebook was". This is obviously
-    |  a very rudimentary solution, but it'll be fast, and a great way get an
+    |  a very rudimentary solution, but it'll be fast, and a great way to get an
     |  idea for what's in your data. Your pattern could look like this:
 
 +code.

website/usage/_linguistic-features/_sentence-segmentation.jade

@@ -40,7 +40,7 @@ p
     |  constrained to predict parses consistent with the sentence boundaries.
 
 +infobox("Important note", "⚠️")
-    |  To prevent inconsitent state, you can only set boundaries #[em before] a
+    |  To prevent inconsistent state, you can only set boundaries #[em before] a
     |  document is parsed (and #[code Doc.is_parsed] is #[code False]). To
     |  ensure that your component is added in the right place, you can set
     |  #[code before='parser'] or #[code first=True] when adding it to the

website/usage/_linguistic-features/_tokenization.jade

@@ -21,7 +21,7 @@ p
     |  which needs to be split into two tokens: #[code {ORTH: "do"}] and
     |  #[code {ORTH: "n't", LEMMA: "not"}]. The prefixes, suffixes and infixes
     |  mosty define punctuation rules – for example, when to split off periods
-    |  (at the end of a sentence), and when to leave token containing periods
+    |  (at the end of a sentence), and when to leave tokens containing periods
     |  intact (abbreviations like "U.S.").
 
 +graphic("/assets/img/language_data.svg")

website/usage/_visualizers/_ent.jade

@@ -74,7 +74,7 @@ p
     displacy.serve(doc, style='ent')
 
 p
-    |  This feature is espeically handy if you're using displaCy to compare
+    |  This feature is especially handy if you're using displaCy to compare
     |  performance at different stages of a process, e.g. during training. Here
     |  you could use the title for a brief description of the text example and
     |  the number of iterations.

website/usage/_visualizers/_html.jade

@@ -61,7 +61,7 @@ p
         output_path.open('w', encoding='utf-8').write(svg)
 
 p
-    |  The above code will generate the dependency visualizations as to
+    |  The above code will generate the dependency visualizations as
     |  two files, #[code This-is-an-example.svg] and #[code This-is-another-one.svg].
 
 

website/usage/visualizers.jade

@@ -24,7 +24,7 @@ include ../_includes/_mixins
         |  standards.
 
     p
-        |  The quickest way visualize  #[code Doc] is to use
+        |  The quickest way to visualize  #[code Doc] is to use
         |  #[+api("displacy#serve") #[code displacy.serve]]. This will spin up a
         |  simple web server and let you view the result straight from your browser.
         |  displaCy can either take a single #[code Doc] or a list of #[code Doc]