Fix typos and grammar (#1304)

* Fix typos and grammar

* Remove redundant words, fix articles

* More language fixes

* More typo fixes and resolve TODO about missing links

Author: jhrcek

CONTRIBUTING.md

@@ -103,7 +103,7 @@ the `news` label if you make a new package so we can know about it!
 
 ## Release policy
 
-We are currently moving to a more aggresive release policy, so that you can get
+We are currently moving to a more aggressive release policy, so that you can get
 what you contribute from Hackage fairly soon. However, note that prior to major
 releases it may take some time in between releases.
 

README.md

@@ -32,7 +32,7 @@ See `CONTRIBUTING.md`
         - It's a good idea to separate these steps, as tests often pass, if they compile :)
     - See `cabal.project` to selectively `allow-newer`
     - If some packages are broken, on your discretisation there are two options:
-        - Fix them and make PRs: it's good idea to test against older `servant` version too.
+        - Fix them and make PRs: it's a good idea to test against older `servant` version too.
         - Temporarily comment out broken package
     - If you make a commit for `servant-universe`, you can use it as submodule in private projects to test even more
 - When ripples are cleared out:
@@ -60,7 +60,7 @@ constraints:
   troublemaker <13.37 && > 13.37
 ```
 
-## TechEmpower framework bechmarks
+## TechEmpower framework benchmarks
 
 We develop and maintain the servant TFB entry in https://github.com/haskell-servant/FrameworkBenchmarks/
 

doc/cookbook/basic-streaming/Streaming.lhs

@@ -8,7 +8,10 @@ In other words, without streaming libraries.
 - Some basic usage doesn't require usage of streaming libraries,
   like `conduit`, `pipes`, `machines` or `streaming`.
   We have bindings for them though.
-- This is similar example file, which is bundled with each of the packages (TODO: links)
+- Similar example is bundled with each of our streaming library interop packages (see 
+[servant-pipes](https://github.com/haskell-servant/servant/blob/master/servant-pipes/example/Main.hs),
+[servant-conduit](https://github.com/haskell-servant/servant/blob/master/servant-conduit/example/Main.hs) and
+[servant-machines](https://github.com/haskell-servant/servant/blob/master/servant-machines/example/Main.hs))
 - `SourceT` doesn't have *Prelude* with handy combinators, so we have to write
   things ourselves. (Note to self: `mapM` and `foldM` would be handy to have). 
 

doc/cookbook/curl-mock/CurlMock.lhs

@@ -1,7 +1,7 @@
 # Generating mock curl calls
 
 In this example we will generate curl requests with mock post data from a servant API.
-This may be usefull for testing and development purposes.
+This may be useful for testing and development purposes.
 Especially post requests with a request body are tedious to send manually.
 
 Also, we will learn how to use the servant-foreign library to generate stuff from servant APIs.

doc/cookbook/db-mysql-basics/MysqlBasics.lhs

@@ -2,7 +2,7 @@
 
 This doc will walk through a single-module implementation of a servant API connecting to a MySQL database. It will also include some basic CRUD operations.
 
-Once you can wrap your head around this implemenation, understanding more complex features like resource pools would be beneficial next steps.
+Once you can wrap your head around this implementation, understanding more complex features like resource pools would be beneficial next steps.
 
 The only *prerequisite* is that you have a MySQL database open on port 3306 of your machine. Docker is an easy way to manage this.
 

doc/cookbook/file-upload/FileUpload.lhs

@@ -90,8 +90,8 @@ startServer = run 8080 (serve api upload)
 
 Finally, a main function that brings up our server and
 sends some test request with `http-client` (and not
-servant-client this time, has servant-multipart does not
-yet have support for client generation.
+servant-client this time, as servant-multipart does not
+yet have support for client generation).
 
 ``` haskell
 main :: IO ()

doc/cookbook/generic/Generic.lhs

@@ -43,13 +43,13 @@ api :: Proxy (ToServantApi Routes)
 api = genericApi (Proxy :: Proxy Routes)
 ```
 
-It's recommented to use `genericApi` function, as then you'll get
+It's recommended to use `genericApi` function, as then you'll get
 better error message, for example if you forget to `derive Generic`.
 
 ## Links
 
 The clear advantage of record-based generics approach, is that
-we can get safe links very conviently. We don't need to define endpoint types,
+we can get safe links very conveniently. We don't need to define endpoint types,
 as field accessors work as proxies:
 
 ```haskell
@@ -67,7 +67,7 @@ routesLinks = allFieldLinks
 ## Client
 
 Even more power starts to show when we generate a record of client functions.
-Here we use `genericClientHoist` function, which let us simultaneously
+Here we use `genericClientHoist` function, which lets us simultaneously
 hoist the monad, in this case from `ClientM` to `IO`.
 
 ```haskell

doc/cookbook/hoist-server-with-context/HoistServerWithContext.lhs

@@ -254,7 +254,7 @@ loginHandler cookieSettings jwtSettings form = do
           liftIO $ pushLogStrLn logset $ toLogStr logMsg
           throwError err401
         Just applyCookies -> do
-          let successMsg = logMsg{message = "AdminUser succesfully authenticated!"}
+          let successMsg = logMsg{message = "AdminUser successfully authenticated!"}
           liftIO $ pushLogStrLn logset $ toLogStr successMsg
           pure $ applyCookies successMsg
 loginHandler _ _ _ = throwError err401

doc/cookbook/open-id-connect/OpenIdConnect.lhs

@@ -8,7 +8,7 @@ some login token would be saved in the user agent local storage.
 
 Workflow:
 
-1.  user is presentend with a login button,
+1.  user is presented with a login button,
 2.  when the user click on the button it is redirected to the OIDC
     provider,
 3.  the user login in the OIDC provider,
@@ -222,8 +222,8 @@ The `AuthInfo` is about the infos we can grab from OIDC provider.
 To be more precise, the user should come with a `code` (a token) and
 POSTing that code to the correct OIDC provider endpoint should return a JSON
 object. One of the field should be named `id_token` which should be a
-JWT containing all the informations we need. Depending on the scopes we
-asked we might get more informations.
+JWT containing all the information we need. Depending on the scopes we
+asked we might get more information.
 
 ``` haskell
 -- | @AuthInfo@
@@ -248,13 +248,13 @@ instance JSON.ToJSON AuthInfo where
 type LoginHandler = AuthInfo -> IO (Either Text User)
 ```
 
-The `handleLoggedIn` is that part that will retrieve the informations from
+The `handleLoggedIn` is that part that will retrieve the information from
 the user once he is redirected from the OIDC Provider after login.
 
 If the user is redirected to the `redirect_uri` but with an `error` query
 parameter then it means something goes wrong.
 If there is no error query param but a `code` query param it means the user
-sucessfully logged in. From there we need to make a request to the token
+successfully logged in. From there we need to make a request to the token
 endpoint of the OIDC provider. Its a POST that should contains the code
 as well as the client id & secret.
 This is the role of the `requestTokens` to make this HTTP POST.
@@ -332,7 +332,7 @@ data Customer = Customer {
 Here is the code that display the homepage.
 It should contain a link to the the `/login` URL.
 When the user will click on this link it will be redirected to Google login page
-with some generated informations.
+with some generated information.
 
 The page also display the content of the local storage.
 And in particular the items `api-key` and `user-id`.
@@ -366,7 +366,7 @@ instance ToMarkup Homepage where
 We need some helpers to generate random string for generating state and API Keys.
 
 ``` haskell
--- | generate a random Bystestring, not necessarily extremely good randomness
+-- | generate a random ByteString, not necessarily extremely good randomness
 -- still the password will be long enough to be very difficult to crack
 genRandomBS :: IO ByteString
 genRandomBS = do

doc/cookbook/pagination/Pagination.lhs

@@ -18,7 +18,7 @@ For example: `Range: createdAt 2017-01-15T23:14:67.000Z; offset 5; order desc` i
 the client is willing to retrieve the next batch of document in descending order that were
 created after the fifteenth of January, skipping the first 5.
 
-As a response, the server may return the list of corresponding document, and augment the
+As a response, the server may return the list of corresponding documents, and augment the
 response with 3 headers:
 
 - `Accept-Ranges`: A comma-separated list of fields upon which a range can be defined
@@ -127,7 +127,7 @@ defaultRange =
   getDefaultRange (Proxy @Color)
 ```
 
-Note that `getFieldValue :: Proxy "name" -> Color -> String` is the minimal complete definintion
+Note that `getFieldValue :: Proxy "name" -> Color -> String` is the minimal complete definition
 of the class. Yet, you can define `getRangeOptions` to provide different parsing options (see
 the last section of this guide). In the meantime, we've also defined a `defaultRange` as it will
 come in handy when defining our handler.
@@ -148,7 +148,7 @@ type MyHeaders =
 ```
 
 `PageHeaders` is a type alias provided by the library to declare the necessary response headers
-we mentionned in introduction. Expanding the alias boils down to the following:
+we mentioned in introduction. Expanding the alias boils down to the following:
 
 ``` haskell
 -- type MyHeaders =
@@ -165,7 +165,7 @@ not, _servant-pagination_ provides an easy way to lift a collection of resources
 #### Server
 
 Time to connect the last bits by defining the server implementation of our colorful API. The `Ranges`
-type we've defined above (tight to the `Range` HTTP header) indicates the server to parse any `Range`
+type we've defined above (tied to the `Range` HTTP header) indicates the server to parse any `Range`
 header, looking for the format defined in introduction with fields and target types we have just declared.
 If no such header is provided, we will end up receiving `Nothing`. Otherwise, it will be possible
 to _extract_ a `Range` from our `Ranges`.
@@ -192,7 +192,7 @@ the format we defined, where `<field>` here can only be `name` and `<value>` mus
 - `Range: <field> [<value>][; offset <o>][; limit <l>][; order <asc|desc>]`
 
 Beside the target field, everything is pretty much optional in the `Range` HTTP header. Missing parts
-are deducted from the `RangeOptions` that are part of the `HasPagination` instance. Therefore, all
+are deduced from the `RangeOptions` that are part of the `HasPagination` instance. Therefore, all
 following examples are valid requests to send to our server:
 
 - 1 - `curl http://localhost:1442/colors -vH 'Range: name'`
@@ -219,7 +219,7 @@ The previous ranges reads as follows:
 Note that in the simple above scenario, there's no ambiguity with `extractRange` and `returnRange`
 because there's only one possible `Range` defined on our resource. Yet, as you've most probably
 noticed, the `Ranges` combinator accepts a list of fields, each of which must declare a `HasPagination`
-instance. Doing so will make the other helper functions more ambiguous and type annotation are
+instance. Doing so will make the other helper functions more ambiguous and type annotations are
 highly likely to be needed.
 
 
@@ -235,8 +235,8 @@ instance HasPagination Color "hex" where
 #### Parsing Options
 
 By default, `servant-pagination` provides an implementation of `getRangeOptions` for each
-`HasPagination` instance. However, this can be overwritten when defining the instance to provide
-your own options. This options come into play when a `Range` header is received and isn't fully
+`HasPagination` instance. However, this can be overridden when defining the instance to provide
+your own options. These options come into play when a `Range` header is received and isn't fully
 specified (`limit`, `offset`, `order` are all optional) to provide default fallback values for those.
 
 For instance, let's say we wanted to change the default limit to `5` in a new range on