Fix possessive use in Manage documentation

These pages used the possessive form of GitLab, which isn't OK for
legal reasons.

doc/administration/compliance.md

@@ -6,9 +6,12 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # Compliance features
 
-You can configure the following GitLab features to help ensure that your GitLab instance meets common compliance standards. Click a feature name for further documentation.
+You can configure the following GitLab features to help ensure that your GitLab
+instance meets common compliance standards. Click a feature name for additional
+documentation.
 
-GitLab’s [security features](../security/README.md) may also help you meet relevant compliance standards.
+The [security features](../security/README.md) in GitLab may also help you meet
+relevant compliance standards.
 
 |Feature   |GitLab tier |GitLab.com |
 | ---------| :--------: | :-------: |
@@ -23,4 +26,4 @@ GitLab’s [security features](../security/README.md) may also help you meet rel
 |**[Audit events](audit_events.md)**<br>To maintain the integrity of your code, GitLab Enterprise Edition Premium gives admins the ability to view any modifications made within the GitLab server in an advanced audit events system, so you can control, analyze, and track every change.|Premium+||
 |**[Auditor users](auditor_users.md)**<br>Auditor users are users who are given read-only access to all projects, groups, and other resources on the GitLab instance.|Premium+||
 |**[Credentials inventory](../user/admin_area/credentials_inventory.md)**<br>With a credentials inventory, GitLab administrators can keep track of the credentials used by all of the users in their GitLab instance. |Ultimate||
-|**Separation of Duties using [Protected branches](../user/project/protected_branches.md#protected-branches-approval-by-code-owners) and [custom CI Configuration Paths](../ci/pipelines/settings.md#custom-ci-configuration-path)**<br> GitLab Silver and Premium users can leverage GitLab's cross-project YAML configuration's to define deployers of code and developers of code. View the [Separation of Duties Deploy Project](https://gitlab.com/guided-explorations/separation-of-duties-deploy/blob/master/README.md) and [Separation of Duties Project](https://gitlab.com/guided-explorations/separation-of-duties/blob/master/README.md) to see how to use this set up to define these roles.|Premium+||
+|**Separation of Duties using [Protected branches](../user/project/protected_branches.md#protected-branches-approval-by-code-owners) and [custom CI Configuration Paths](../ci/pipelines/settings.md#custom-ci-configuration-path)**<br> GitLab Silver and Premium users can leverage the GitLab cross-project YAML configurations to define deployers of code and developers of code. View the [Separation of Duties Deploy Project](https://gitlab.com/guided-explorations/separation-of-duties-deploy/blob/master/README.md) and [Separation of Duties Project](https://gitlab.com/guided-explorations/separation-of-duties/blob/master/README.md) to see how to use this set up to define these roles.|Premium+||

doc/development/i18n/index.md

@@ -6,7 +6,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # Translate GitLab to your language
 
-The text in GitLab's user interface is in American English by default.
+The text in the GitLab user interface is in American English by default.
 Each string can be translated to other languages.
 As each string is translated, it is added to the languages translation file,
 and is made available in future releases of GitLab.

doc/development/i18n/translation.md

@@ -79,7 +79,7 @@ determining a suitable level of formality.
 
 ### Inclusive language
 
-[Diversity](https://about.gitlab.com/handbook/values/#diversity) is one of GitLab's values.
+[Diversity](https://about.gitlab.com/handbook/values/#diversity) is a GitLab value.
 We ask you to avoid translations which exclude people based on their gender or
 ethnicity.
 In languages which distinguish between a male and female form, use both or

doc/user/admin_area/custom_project_templates.md

@@ -20,8 +20,8 @@ available to the user if they have access to them. For example:
 - Private projects will be available only if the user is a member of the project.
 
 Repository and database information that are copied over to each new project are
-identical to the data exported with
-[GitLab's Project Import/Export](../project/settings/import_export.md).
+identical to the data exported with the
+[GitLab Project Import/Export](../project/settings/import_export.md).
 
 NOTE:
 To set project templates at a group level,

doc/user/group/custom_project_templates.md

@@ -70,7 +70,7 @@ NOTE:
 Only direct subgroups can be set as the template source. Projects of nested subgroups of a selected template source cannot be used.
 
 Repository and database information that are copied over to each new project are
-identical to the data exported with [GitLab's Project Import/Export](../project/settings/import_export.md).
+identical to the data exported with the [GitLab Project Import/Export](../project/settings/import_export.md).
 
 <!-- ## Troubleshooting
 

doc/user/project/import/bitbucket.md

@@ -38,10 +38,10 @@ to enable this if not already.
 ## How it works
 
 When issues/pull requests are being imported, the Bitbucket importer tries to find
-the Bitbucket author/assignee in GitLab's database using the Bitbucket `nickname`.
+the Bitbucket author/assignee in the GitLab database using the Bitbucket `nickname`.
 For this to work, the Bitbucket author/assignee should have signed in beforehand in GitLab
 and **associated their Bitbucket account**. Their `nickname` must also match their Bitbucket
-`username.`. If the user is not found in GitLab's database, the project creator
+`username.`. If the user is not found in the GitLab database, the project creator
 (most of the times the current user that started the import process) is set as the author,
 but a reference on the issue about the original Bitbucket author is kept.
 

doc/user/project/import/gitea.md

@@ -27,7 +27,7 @@ This requires Gitea `v1.0.0` or newer.
 ## How it works
 
 Since Gitea is currently not an OAuth provider, author/assignee cannot be mapped
-to users in your GitLab's instance. This means that the project creator (most of
+to users in your GitLab instance. This means that the project creator (most of
 the times the current user that started the import process) is set as the author,
 but a reference on the issue about the original Gitea author is kept.
 

doc/user/project/import/github.md

@@ -65,7 +65,7 @@ must meet one of the following conditions prior to the import:
   [primary email address](https://docs.github.com/en/free-pro-team@latest/rest/reference/users#get-a-user)
   on their profile that matches their GitLab account's email address.
 
-If a user referenced in the project is not found in GitLab's database, the project creator (typically the user
+If a user referenced in the project is not found in the GitLab database, the project creator (typically the user
 that initiated the import process) is set as the author/assignee, but a note on the issue mentioning the original
 GitHub author is added.
 
@@ -103,7 +103,7 @@ If you are using a self-managed GitLab instance or if you are importing from Git
 1. From the top navigation bar, click **+** and select **New project**.
 1. Select the **Import project** tab and then select **GitHub**.
 1. Select the first button to **List your GitHub repositories**. You are redirected to a page on [GitHub](https://github.com) to authorize the GitLab application.
-1. Click **Authorize GitlabHQ**. You are redirected back to GitLab's Import page and all of your GitHub repositories are listed.
+1. Click **Authorize GitlabHQ**. You are redirected back to the GitLab Import page and all of your GitHub repositories are listed.
 1. Continue on to [selecting which repositories to import](#selecting-which-repositories-to-import).
 
 ### Using a GitHub token