Fix typos

Author: terehov

README.md

@@ -379,18 +379,18 @@ grandchildLogger.silly("grandchild1 message");
 #### Attach additional transports
 
 `tslog` focuses on the one thing it does well: capturing logs.
-Therefore, there is no build-in _file system_ logging, _log rotation_, or similar.
+Therefore, there is no built-in _file system_ logging, _log rotation_, or similar.
 Per default all logs go to `console`, which can be overwritten (s. below).
 
 However, you can easily attach as many _transports_ as you wish, enabling you to do fancy stuff
 like sending messages to _Slack_ or _Telegram_ in case of an urgent error or forwarding them to a log aggregator service.
 
-**Attached transports are also inherited to child loggers.**
+**Attached transports are also inherited by sub-loggers.**
 
 ##### Simple transport example
 
 Here is a very simple implementation used in our _jest_ tests. 
-This example with suppress logs from being send to `console` (`type: "hidden"`) and will instead collect them in an `array`.
+This example will suppress logs from being sent to `console` (`type: "hidden"`) and will instead collect them in an `array`.
 
 ```typescript
 const transports: any[] = [];
@@ -405,7 +405,7 @@ const logMsg = logger.info("Log message");
 
 ##### Storing logs in a file
 
-Here is an example how to store all logs in a file.
+Here is an example of how to store all logs in a file.
 
 ```typescript
 import { Logger } from "tslog";
@@ -422,7 +422,7 @@ logger.warn("I am a warn log with a json object:", { foo: "bar" });
 
 ```
 
-##### Storing logs in file system with rotating files
+##### Storing logs in a file system with rotating files
 
 If you want to limit the file size of the stored logs, a good practice is to use file rotation, where old logs will be deleted automatically. 
 There is a great library called `rotating-file-stream` solving this problem for us and even adding features like compression, file size limit etc.
@@ -554,9 +554,9 @@ const logMsg = logger.info("Test");
 **❗ Keep track of all subsequent calls and promises originated from a single request (e.g. HTTP).**
 
 In a real world application a call to an API would lead to many logs produced across the entire application.
-When debugging it can get quite handy to be able to group all logs based by a unique identifier, e.g.  `requestId`.
+When debugging it can be quite handy to be able to group all logs based on a unique identifier, e.g.  `requestId`.
 
-Some provides (e.g. `Heroku`) already set a `X-Request-ID` header, which we are going to use or fallback to a short ID generated by <a href="https://www.npmjs.com/package/nanoid" target="_blank">`nanoid`</a>.
+Some providers (e.g. `Heroku`) already set a `X-Request-ID` header, which we are going to use or fallback to a short ID generated by <a href="https://www.npmjs.com/package/nanoid" target="_blank">`nanoid`</a>.
 
 **In this example every subsequent logger is a sub logger of the main logger and thus inherits all of its settings making `requestId` available throughout the entire application without any further ado.**
 

docs/README.md

@@ -379,18 +379,18 @@ grandchildLogger.silly("grandchild1 message");
 #### Attach additional transports
 
 `tslog` focuses on the one thing it does well: capturing logs.
-Therefore, there is no build-in _file system_ logging, _log rotation_, or similar.
+Therefore, there is no built-in _file system_ logging, _log rotation_, or similar.
 Per default all logs go to `console`, which can be overwritten (s. below).
 
 However, you can easily attach as many _transports_ as you wish, enabling you to do fancy stuff
 like sending messages to _Slack_ or _Telegram_ in case of an urgent error or forwarding them to a log aggregator service.
 
-**Attached transports are also inherited to child loggers.**
+**Attached transports are also inherited by sub-loggers.**
 
 ##### Simple transport example
 
 Here is a very simple implementation used in our _jest_ tests. 
-This example with suppress logs from being send to `console` (`type: "hidden"`) and will instead collect them in an `array`.
+This example will suppress logs from being sent to `console` (`type: "hidden"`) and will instead collect them in an `array`.
 
 ```typescript
 const transports: any[] = [];
@@ -405,7 +405,7 @@ const logMsg = logger.info("Log message");
 
 ##### Storing logs in a file
 
-Here is an example how to store all logs in a file.
+Here is an example of how to store all logs in a file.
 
 ```typescript
 import { Logger } from "tslog";
@@ -422,7 +422,7 @@ logger.warn("I am a warn log with a json object:", { foo: "bar" });
 
 ```
 
-##### Storing logs in file system with rotating files
+##### Storing logs in a file system with rotating files
 
 If you want to limit the file size of the stored logs, a good practice is to use file rotation, where old logs will be deleted automatically. 
 There is a great library called `rotating-file-stream` solving this problem for us and even adding features like compression, file size limit etc.
@@ -554,9 +554,9 @@ const logMsg = logger.info("Test");
 **❗ Keep track of all subsequent calls and promises originated from a single request (e.g. HTTP).**
 
 In a real world application a call to an API would lead to many logs produced across the entire application.
-When debugging it can get quite handy to be able to group all logs based by a unique identifier, e.g.  `requestId`.
+When debugging it can be quite handy to be able to group all logs based on a unique identifier, e.g.  `requestId`.
 
-Some provides (e.g. `Heroku`) already set a `X-Request-ID` header, which we are going to use or fallback to a short ID generated by <a href="https://www.npmjs.com/package/nanoid" target="_blank">`nanoid`</a>.
+Some providers (e.g. `Heroku`) already set a `X-Request-ID` header, which we are going to use or fallback to a short ID generated by <a href="https://www.npmjs.com/package/nanoid" target="_blank">`nanoid`</a>.
 
 **In this example every subsequent logger is a sub logger of the main logger and thus inherits all of its settings making `requestId` available throughout the entire application without any further ado.**