Document Update (#27694)

* Document Update

Where to were

* Document Update

"re enter" to "reenter"

* Document Update

"an" to "a"

* Document Update

"an" to "a"

* Document update

"can not " to cannot

* Document update

Changes made from "and by that not function as expected." to "and by that it do not function as expected."

* Document update

Change made from "by that not function as expected" to "by that it does not function as expected"

* Update docs/sources/installation/upgrading.md

Commit, the document based on suggestion

Co-authored-by: Arve Knudsen <arve.knudsen@gmail.com>

* Update docs/sources/installation/upgrading.md

Commit the changes as per the suggestion

Co-authored-by: Arve Knudsen <arve.knudsen@gmail.com>

* Document update

Changes reverted from "cannot" to "can not" as per the suggestion

* Document Update

Changes as per the suggestion

* Document changes

Changes as per the suggestion

* Document Change

Changes made as per the suggestion

Co-authored-by: Arve Knudsen <arve.knudsen@gmail.com>

docs/sources/installation/upgrading.md

@@ -20,7 +20,7 @@ Upgrading is generally safe (between many minor and one major version) and dashb
 ## Backup
 ## Backup
 
 
 We recommend that you backup a few things in case you have to rollback the upgrade.
 We recommend that you backup a few things in case you have to rollback the upgrade.
-- Installed plugins - Back them up before you upgrade them in case you want to rollback the Grafana version and want to get the exact same versions you where running before the upgrade.
+- Installed plugins - Back them up before you upgrade them in case you want to rollback the Grafana version and want to get the exact same versions you were running before the upgrade.
 - Configuration files do not need to be backed up. However, you might want to in case you add new config options after upgrade and then rollback.
 - Configuration files do not need to be backed up. However, you might want to in case you add new config options after upgrade and then rollback.
 
 
 ### Database backup
 ### Database backup
@@ -174,7 +174,7 @@ Data sources store passwords and basic auth passwords in secureJsonData encrypte
 will keep working with unencrypted passwords. If you want to migrate to encrypted storage for your existing data sources
 will keep working with unencrypted passwords. If you want to migrate to encrypted storage for your existing data sources
 you can do that by:
 you can do that by:
 
 
-- For data sources created through UI, you need to go to data source config, re enter the password or basic auth
+- For data sources created through UI, you need to go to data source config, re-enter the password or basic auth
 password and save the data source.
 password and save the data source.
 - For data sources created by provisioning, you need to update your config file and use secureJsonData.password or
 - For data sources created by provisioning, you need to update your config file and use secureJsonData.password or
 secureJsonData.basicAuthPassword field. See [provisioning docs]({{< relref "../administration/provisioning" >}}) for example of current
 secureJsonData.basicAuthPassword field. See [provisioning docs]({{< relref "../administration/provisioning" >}}) for example of current
@@ -189,8 +189,8 @@ this new setting.
 ### Session storage is no longer used
 ### Session storage is no longer used
 
 
 In 6.2 we completely removed the backend session storage since we replaced the previous login session implementation with an auth token.
 In 6.2 we completely removed the backend session storage since we replaced the previous login session implementation with an auth token.
-If you are using Auth proxy with LDAP an shared cached is used in Grafana so you might want configure [remote_cache] instead. If not
-Grafana will fallback to using the database as an shared cache.
+If you are using Auth proxy with LDAP, a shared cached is used in Grafana, so you might want to configure [remote_cache] instead. If not,
+Grafana will fall back to using the database as a shared cache.
 
 
 ### Upgrading Elasticsearch to v7.0+
 ### Upgrading Elasticsearch to v7.0+
 
 
@@ -274,6 +274,6 @@ The following alert notifiers have been updated to support storing their sensiti
 
 
 For existing alert notification channels, there is no automatic migration of storing sensitive settings encrypted, and they will continue to work as before. Migration must be done manually. Opening a configured alert notification channel in the UI and saving it will store sensitive settings encrypted and at the same time reset the historic unencrypted setting of that alert notification channel in the database.
 For existing alert notification channels, there is no automatic migration of storing sensitive settings encrypted, and they will continue to work as before. Migration must be done manually. Opening a configured alert notification channel in the UI and saving it will store sensitive settings encrypted and at the same time reset the historic unencrypted setting of that alert notification channel in the database.
 
 
-> Please note that when migrating a notification channel and later downgrading Grafana to an earlier version, the notification channel will not be able to read stored sensitive settings and by that not function as expected.
+> Please note that when migrating a notification channel and later downgrading Grafana to an earlier version, the notification channel will not be able to read stored sensitive settings and, as a result, not function as expected.
 
 
 For provisioning of alert notification channels, refer to [Alert notification channels]({{< relref "../administration/provisioning.md#alert-notification-channels" >}}).
 For provisioning of alert notification channels, refer to [Alert notification channels]({{< relref "../administration/provisioning.md#alert-notification-channels" >}}).