fix e.g. and i.e. typos (#732)

console/src/components/Services/Data/Add/AddWarning.js

@@ -9,6 +9,6 @@ export const primaryKeyAlreadyPresentMsg = key =>
 export const ATLEAST_ONE_COLUMN_MSG =
   'You need atleast one column for a given table.';
 export const RECOMMENEDED_NAMING_CONVENTION =
-  'We recommend using the snake_case naming convertion for table, column names. Eg: article_author.';
+  'We recommend using the snake_case naming convertion for table, column names. E.g.: article_author.';
 export const fieldRepeatedMsg = list =>
   `You have the following column names repeated: [${list}]`;

docs/graphql/manual/api-reference/schema-metadata-api/run-sql.rst

@@ -43,7 +43,7 @@ An example:
    }
 
 While ``run_sql`` lets you run any SQL, it tries to ensure that the Hasura GraphQL engine's
-state (relationships, permissions etc.) is consistent. i.e, you
+state (relationships, permissions etc.) is consistent. i.e., you
 cannot drop a column on which any metadata is dependent on (say a permission or
 a relationship). The effects, however, can be cascaded.
 

docs/graphql/manual/api-reference/schema-metadata-api/syntax-defs.rst

@@ -97,11 +97,11 @@ PGColumnType
 
       * - ``timestamp with time zone``
         - ``timestamptz``
-        - both date and time, with time zone. Allowed values should be of ISO8601 format. Eg. 2016-07-20T17:30:15Z, 2016-07-20T17:30:15+05:30, 2016-07-20T17:30:15.234890+05:30
+        - both date and time, with time zone. Allowed values should be of ISO8601 format. E.g. 2016-07-20T17:30:15Z, 2016-07-20T17:30:15+05:30, 2016-07-20T17:30:15.234890+05:30
 
       * - ``time with time zone``
         - ``timetz``
-        - time of day only, with time zone. Allowed values should be of ISO8601 format. Eg. 17:30:15Z, 17:30:15+05:30, 17:30:15.234890+05:30
+        - time of day only, with time zone. Allowed values should be of ISO8601 format. E.g. 17:30:15Z, 17:30:15+05:30, 17:30:15.234890+05:30
 
       * - ``date``
         -

docs/graphql/manual/auth/basics.rst

@@ -7,7 +7,7 @@ We're working with a simple ``author`` table where users have some information s
 Create a author table
 ---------------------
 
-Head to your console and create a ``author`` table with the following columns:
+Head to your console and create an ``author`` table with the following columns:
 
 +----------+--------+
 |      id  | integer|

docs/graphql/manual/auth/common-roles-auth-examples.rst

@@ -22,7 +22,7 @@ Logged-in users
 
 - Create a role called ``user``.
 - Access control rules in this case are usually dependent on a ``user_id`` or a ``owner_id`` column in your data model.
-- Setup a permission for insert/select/update/delete that uses said column. Eg: ``author_id: {_eq: "X-Hasura-User-Id"}`` for an article table.
+- Setup a permission for insert/select/update/delete that uses said column. E.g.: ``author_id: {_eq: "X-Hasura-User-Id"}`` for an article table.
 - Note that the ``X-Hasura-User-Id`` is a :doc:`dynamic session variable<./roles-variables>` that comes in from your :doc:`auth webhook's<./webhook>` response, or as a request as a header if you're testing.
 
 .. image:: ../../../img/graphql/manual/auth/user-select-graphiql.png

docs/graphql/manual/auth/index.rst

@@ -15,7 +15,7 @@ directly!
 
 Your app will likely only send an authorization token or cookie provided by your app's authentication
 system to Hasura. In this case, Hasura will make a request to a webhook set up by you with the request headers your
-app has sent (authorization tokens, cookies etc). The webhook should then return the variables required as context for
+app has sent (authorization tokens, cookies etc.). The webhook should then return the variables required as context for
 the access control rules. Alternatively, your app can send to Hasura JWT tokens, which can then be decoded by Hasura to
 get the variables required for the access control rules.
 See :doc:`webhook` or :doc:`jwt` for more details.

docs/graphql/manual/auth/jwt.rst

@@ -74,7 +74,7 @@ Example JWT claim:
 
 This contains standard (``sub``, ``iat`` etc.) and custom (``name``, ``admin``
 etc.) JWT claims, as well as Hasura specific claims inside a custom namespace
-(or key) i.e ``https://hasura.io/jwt/claims``.
+(or key) i.e. ``https://hasura.io/jwt/claims``.
 
 The ``https://hasura.io/jwt/claims`` is the custom namespace where all Hasura
 specific claims have to be present. This value can be configured in the JWT
@@ -132,7 +132,7 @@ public keys are not yet supported.
 
 ``key``
 ^^^^^^^
-- In case of symmetric key (i.e HMAC based key), the key as it is. (e.g -
+- In case of symmetric key (i.e. HMAC based key), the key as it is. (e.g. -
   "abcdef...").
 - In case of asymmetric keys (RSA etc.), only the public key, in a PEM encoded
   string or as a X509 certificate.
@@ -166,7 +166,7 @@ JWKs are not refreshed.
 ``claims_namespace``
 ^^^^^^^^^^^^^^^^^^^^
 This is an optional field. You can specify the key name
-inside which the Hasura specific claims will be present. E.g - ``https://mydomain.com/claims``.
+inside which the Hasura specific claims will be present. E.g. - ``https://mydomain.com/claims``.
 
 **Default value** is: ``https://hasura.io/jwt/claims``.
 

docs/graphql/manual/migrations/existing-project.rst

@@ -10,7 +10,7 @@ These are the steps you need to follow:
 #. Setup a project directory
 #. Initialize migrations
 #. For further changes, use the Hasura CLI console (``http://localhost:9695``) instead of the console served by the
-   GraphQL engine (Eg: ``http://my-graphql.herokuapp.com``)
+   GraphQL engine (E.g.: ``http://my-graphql.herokuapp.com``)
 
 Step 0: Take a note of your GraphQL engine endpoint
 ---------------------------------------------------

docs/graphql/manual/migrations/new-project.rst

@@ -9,7 +9,7 @@ These are the steps you need to follow:
 #. Install the Hasura CLI
 #. Setup a project directory
 #. Use the Hasura CLI console (``http://localhost:9695``) instead of the console served by the
-   GraphQL engine (Eg: ``http://my-graphql.herokuapp.com``) to set the schema up
+   GraphQL engine (E.g.: ``http://my-graphql.herokuapp.com``) to set the schema up
 
 
 Step 0: Take a note of your  GraphQL engine endpoint