From 4e86de80edfdab36bd68ce3b13ff46f8d2a90f47 Mon Sep 17 00:00:00 2001
From: Amy Qualls <aqualls@gitlab.com>
Date: Wed, 22 Apr 2020 15:58:05 +0000
Subject: [PATCH] Create an initial test for British English
This commit adds and begins populating a substitution list for
words that vary between British and American English.
---
doc/.vale/gitlab/British.yml | 106 ++++++++++++++++++
doc/administration/database_load_balancing.md | 2 +-
.../background_verification.md | 4 +-
.../geo/disaster_recovery/planned_failover.md | 2 +-
doc/administration/high_availability/nfs.md | 2 +-
doc/administration/object_storage.md | 4 +-
.../packages/container_registry.md | 2 +-
doc/ci/yaml/README.md | 4 +-
doc/development/api_graphql_styleguide.md | 4 +-
doc/development/api_styleguide.md | 2 +-
.../contributing/issue_workflow.md | 10 +-
doc/development/dangerbot.md | 2 +-
doc/development/ee_features.md | 8 +-
doc/development/fe_guide/frontend_faq.md | 2 +-
doc/development/fe_guide/style/javascript.md | 2 +-
doc/development/hash_indexes.md | 2 +-
.../merge_request_performance_guidelines.md | 2 +-
doc/development/packages.md | 2 +-
doc/development/performance.md | 2 +-
doc/development/reactive_caching.md | 2 +-
doc/development/secure_coding_guidelines.md | 2 +-
.../testing_guide/best_practices.md | 2 +-
.../testing_guide/testing_levels.md | 2 +-
doc/development/value_stream_analytics.md | 2 +-
.../verifying_database_capabilities.md | 2 +-
doc/topics/git/lfs/index.md | 2 +-
doc/university/support/README.md | 2 +-
doc/user/project/integrations/bamboo.md | 2 +-
doc/user/project/repository/index.md | 2 +-
29 files changed, 145 insertions(+), 39 deletions(-)
create mode 100644 doc/.vale/gitlab/British.yml
diff --git a/doc/.vale/gitlab/British.yml b/doc/.vale/gitlab/British.yml
new file mode 100644
index 000000000000..943e85beba15
--- /dev/null
+++ b/doc/.vale/gitlab/British.yml
@@ -0,0 +1,106 @@
+---
+# Checks for use of some of the top misused terms at GitLab.
+#
+# For a list of all options, see https://errata-ai.github.io/vale/styles/
+extends: substitution
+message: 'Use the American spelling "%s" instead of the British "%s".'
+link: https://about.gitlab.com/handbook/communication/#top-misused-terms
+level: error
+ignorecase: true
+swap:
+ aeon: eon
+ aeroplane: airplane
+ ageing: aging
+ aluminium: aluminum
+ anaemia: anemia
+ anaesthesia: anesthesia
+ analyse: analyze
+ annexe: annex
+ apologise: apologize
+ behaviour: behavior
+ busses: buses
+ calibre: caliber
+ centre: center
+ cheque: check
+ civilisation: civilization
+ civilise: civilize
+ colour: color
+ cosy: cozy
+ cypher: cipher
+ dependant: dependent
+ defence: defense
+ distil: distill
+ draught: draft
+ encyclopaedia: encyclopedia
+ enquiry: inquiry
+ enrol: enroll
+ enrolment: enrollment
+ enthral: enthrall
+ # equalled: equaled // Under discussion
+ # equalling: equaling // Under discussion
+ favourite: favorite
+ fibre: fiber
+ fillet: filet
+ flavour: flavor
+ furore: furor
+ fulfil: fulfill
+ gaol: jail
+ grey: gray
+ humour: humor
+ honour: honor
+ initialled: initialed
+ initialling: initialing
+ instil: instill
+ jewellery: jewelry
+ labelling: labeling
+ labelled: labeled
+ labour: labor
+ libellous: libelous
+ licence: license
+ likeable: likable
+ liveable: livable
+ lustre: luster
+ manoeuvre: maneuver
+ marvellous: marvelous
+ matt: matte
+ meagre: meager
+ metre: meter
+ mitre: miter
+ modelling: modeling
+ moustache: mustache
+ neighbour: neighbor
+ normalise: normalize
+ offence: offense
+ organise: organize
+ orientated: oriented
+ paralyse: paralyze
+ plough: plow
+ pretence: pretense
+ programme: program
+ pyjamas: pajamas
+ rateable: ratable
+ realise: realize
+ recognise: recognize
+ reconnoitre: reconnoiter
+ rumour: rumor
+ sabre: saber
+ saleable: salable
+ saltpetre: saltpeter
+ sceptic: skeptic
+ sepulchre: sepulcher
+ signalling: signaling
+ sizeable: sizable
+ skilful: skillful
+ sombre: somber
+ smoulder: smolder
+ speciality: specialty
+ spectre: specter
+ splendour: splendor
+ sulphur: sulfur
+ theatre: theater
+ travelled: traveled
+ traveller: traveler
+ travelling: traveling
+ unshakeable: unshakable
+ wilful: willful
+ yoghurt: yogurt
diff --git a/doc/administration/database_load_balancing.md b/doc/administration/database_load_balancing.md
index cecc372f3874..b208a5052cbe 100644
--- a/doc/administration/database_load_balancing.md
+++ b/doc/administration/database_load_balancing.md
@@ -246,7 +246,7 @@ is in sync with the primary. If the data is determined to be recent enough the
secondary can be used, otherwise it will be ignored. To reduce the overhead of
these checks we only perform these checks at certain intervals.
-There are three configuration options that influence this behaviour:
+There are three configuration options that influence this behavior:
| Option | Description | Default |
|------------------------------|----------------------------------------------------------------------------------------------------------------|------------|
diff --git a/doc/administration/geo/disaster_recovery/background_verification.md b/doc/administration/geo/disaster_recovery/background_verification.md
index 6d6aee08c955..5b24c222f063 100644
--- a/doc/administration/geo/disaster_recovery/background_verification.md
+++ b/doc/administration/geo/disaster_recovery/background_verification.md
@@ -54,14 +54,14 @@ Feature.enable('geo_repository_verification')
Navigate to the **{admin}** **Admin Area >** **{location-dot}** **Geo** dashboard on the **primary** node and expand
the **Verification information** tab for that node to view automatic checksumming
status for repositories and wikis. Successes are shown in green, pending work
-in grey, and failures in red.
+in gray, and failures in red.
Navigate to the **{admin}** **Admin Area >** **{location-dot}** **Geo** dashboard on the **secondary** node and expand
the **Verification information** tab for that node to view automatic verification
status for repositories and wikis. As with checksumming, successes are shown in
-green, pending work in grey, and failures in red.
+green, pending work in gray, and failures in red.
diff --git a/doc/administration/geo/disaster_recovery/planned_failover.md b/doc/administration/geo/disaster_recovery/planned_failover.md
index 4b3b464b7109..00ca1e4b8b01 100644
--- a/doc/administration/geo/disaster_recovery/planned_failover.md
+++ b/doc/administration/geo/disaster_recovery/planned_failover.md
@@ -95,7 +95,7 @@ ensure these processes are close to 100% as possible during active use.
Navigate to the **{admin}** **Admin Area >** **{location-dot}** **Geo** dashboard on the **secondary** node to
review status. Replicated objects (shown in green) should be close to 100%,
and there should be no failures (shown in red). If a large proportion of
-objects aren't yet replicated (shown in grey), consider giving the node more
+objects aren't yet replicated (shown in gray), consider giving the node more
time to complete
diff --git a/doc/administration/high_availability/nfs.md b/doc/administration/high_availability/nfs.md
index fd5d8694cdf2..d63afcb8cf92 100644
--- a/doc/administration/high_availability/nfs.md
+++ b/doc/administration/high_availability/nfs.md
@@ -184,7 +184,7 @@ The NFS man page states:
Read the [Linux man page](https://linux.die.net/man/5/nfs) to understand the difference,
and if you do use `soft`, ensure that you've taken steps to mitigate the risks.
-If you experience behaviour that might have been caused by
+If you experience behavior that might have been caused by
writes to disk on the NFS server not occurring, such as commits going missing,
use the `hard` option, because (from the man page):
diff --git a/doc/administration/object_storage.md b/doc/administration/object_storage.md
index 1b0c7f8a907b..aec5f7f5566f 100644
--- a/doc/administration/object_storage.md
+++ b/doc/administration/object_storage.md
@@ -98,9 +98,9 @@ object storage back end, like when Git clients request large files via LFS or wh
downloading CI artifacts and logs.
When the files are stored on local block storage or NFS, GitLab has to act as a proxy.
-This is not the default behaviour with object storage.
+This is not the default behavior with object storage.
-The `proxy_download` setting controls this behaviour: the default is generally `false`.
+The `proxy_download` setting controls this behavior: the default is generally `false`.
Verify this in the documentation for each use case. Set it to `true` so that GitLab proxies
the files.
diff --git a/doc/administration/packages/container_registry.md b/doc/administration/packages/container_registry.md
index aaf1ca290846..102ae3206251 100644
--- a/doc/administration/packages/container_registry.md
+++ b/doc/administration/packages/container_registry.md
@@ -427,7 +427,7 @@ NOTE: **Note:**
By default, users accessing a registry configured with a remote backend are redirected to the default backend for the storage driver. For example, registries can be configured using the `s3` storage driver, which redirects requests to a remote S3 bucket to alleviate load on the GitLab server.
-However, this behaviour is undesirable for registries used by internal hosts that usually can't access public servers. To disable redirects, set the `disable` flag to true as follows. This makes all traffic to always go through the Registry service. This results in improved security (less surface attack as the storage backend is not publicly accessible), but worse performance (all traffic is redirected via the service).
+However, this behavior is undesirable for registries used by internal hosts that usually can't access public servers. To disable redirects, set the `disable` flag to true as follows. This makes all traffic to always go through the Registry service. This results in improved security (less surface attack as the storage backend is not publicly accessible), but worse performance (all traffic is redirected via the service).
**Omnibus GitLab installations**
diff --git a/doc/ci/yaml/README.md b/doc/ci/yaml/README.md
index 3b0a527897ed..9da1224a9b94 100644
--- a/doc/ci/yaml/README.md
+++ b/doc/ci/yaml/README.md
@@ -2607,7 +2607,7 @@ rspec:
> Introduced in GitLab 9.4.
-The default behaviour of a caching job is to download the files at the start of
+The default behavior of a caching job is to download the files at the start of
execution, and to re-upload them at the end. This allows any changes made by the
job to be persisted for future runs, and is known as the `pull-push` cache
policy.
@@ -3198,7 +3198,7 @@ job1:
### `retry`
> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/12909) in GitLab 9.5.
-> - [Behaviour expanded](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/21758) in GitLab 11.5 to control on which failures to retry.
+> - [Behavior expanded](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/21758) in GitLab 11.5 to control on which failures to retry.
`retry` allows you to configure how many times a job is going to be retried in
case of a failure.
diff --git a/doc/development/api_graphql_styleguide.md b/doc/development/api_graphql_styleguide.md
index f19016968d44..68da6b01aabb 100644
--- a/doc/development/api_graphql_styleguide.md
+++ b/doc/development/api_graphql_styleguide.md
@@ -110,7 +110,7 @@ When exposing an `ID` field on a type, we will by default try to
expose a global ID by calling `to_global_id` on the resource being
rendered.
-To override this behaviour, you can implement an `id` method on the
+To override this behavior, you can implement an `id` method on the
type for which you are exposing an ID. Please make sure that when
exposing a `GraphQL::ID_TYPE` using a custom method that it is
globally unique.
@@ -598,7 +598,7 @@ ID. Otherwise use a [globally unique ID](#exposing-global-ids).
We already have a `FullPathLoader` that can be included in other
resolvers to quickly find Projects and Namespaces which will have a
-lot of dependant objects.
+lot of dependent objects.
To limit the amount of queries performed, we can use `BatchLoader`.
diff --git a/doc/development/api_styleguide.md b/doc/development/api_styleguide.md
index 948644fa7867..25c8cbd3fde9 100644
--- a/doc/development/api_styleguide.md
+++ b/doc/development/api_styleguide.md
@@ -100,7 +100,7 @@ Model.create(foo: params[:foo])
## Using HTTP status helpers
-For non-200 HTTP responses, use the provided helpers in `lib/api/helpers.rb` to ensure correct behaviour (`not_found!`, `no_content!` etc.). These will `throw` inside Grape and abort the execution of your endpoint.
+For non-200 HTTP responses, use the provided helpers in `lib/api/helpers.rb` to ensure correct behavior (`not_found!`, `no_content!` etc.). These will `throw` inside Grape and abort the execution of your endpoint.
For `DELETE` requests, you should also generally use the `destroy_conditionally!` helper which by default returns a `204 No Content` response on success, or a `412 Precondition Failed` response if the given `If-Unmodified-Since` header is out of range. This helper calls `#destroy` on the passed resource, but you can also implement a custom deletion method by passing a block.
diff --git a/doc/development/contributing/issue_workflow.md b/doc/development/contributing/issue_workflow.md
index 13ff35ed65cd..ddd4e84bfd1f 100644
--- a/doc/development/contributing/issue_workflow.md
+++ b/doc/development/contributing/issue_workflow.md
@@ -36,7 +36,7 @@ project.
To allow for asynchronous issue handling, we use [milestones](https://gitlab.com/groups/gitlab-org/-/milestones)
and [labels](https://gitlab.com/gitlab-org/gitlab/-/labels). Leads and product managers handle most of the
-scheduling into milestones. Labelling is a task for everyone.
+scheduling into milestones. Labeling is a task for everyone.
Most issues will have labels for at least one of the following:
@@ -156,9 +156,9 @@ As a team needs some way to collect the work their members are planning to be as
Normally there is a 1:1 relationship between Stage labels and Group labels. In
the spirit of "Everyone can contribute", any issue can be picked up by any group,
depending on current priorities. When picking up an issue belonging to a different
-group, it should be relabelled. For example, if an issue labelled `~"devops::create"`
+group, it should be relabeled. For example, if an issue labeled `~"devops::create"`
and `~"group::knowledge"` is picked up by someone in the Access group of the Plan stage,
-the issue should be relabelled as `~"group::access"` while keeping the original
+the issue should be relabeled as `~"group::access"` while keeping the original
`~"devops::create"` unchanged.
We also use stage and group labels to help quantify our [throughput](https://about.gitlab.com/handbook/engineering/management/throughput/).
@@ -347,7 +347,7 @@ there is the ~"stewardship" label.
This label is to be used for issues in which the stewardship of GitLab
is a topic of discussion. For instance if GitLab Inc. is planning to add
-features from GitLab EE to GitLab CE, related issues would be labelled with
+features from GitLab EE to GitLab CE, related issues would be labeled with
~"stewardship".
A recent example of this was the issue for
@@ -461,7 +461,7 @@ fixing in the same MR, but not worth creating a follow-up issue for. Renaming a
method that is used in many places to make its intent slightly clearer may be
worth fixing, but it should not happen in the same MR, and is generally not
worth the overhead of having an issue of its own. These issues would invariably
-be labelled `~P4 ~S4` if we were to create them.
+be labeled `~P4 ~S4` if we were to create them.
More severe technical debt can have implications for development velocity. If
it isn't addressed in a timely manner, the codebase becomes needlessly difficult
diff --git a/doc/development/dangerbot.md b/doc/development/dangerbot.md
index e090281f2bfd..483559672a7c 100644
--- a/doc/development/dangerbot.md
+++ b/doc/development/dangerbot.md
@@ -65,7 +65,7 @@ First, be aware of GitLab's [commitment to dogfooding](https://about.gitlab.com/
The code we write for Danger is GitLab-specific, and it **may not** be most
appropriate place to implement functionality that addresses a need we encounter.
Our users, customers, and even our own satellite projects, such as [Gitaly](https://gitlab.com/gitlab-org/gitaly),
-often face similar challenges, after all. Think about how you could fulfil the
+often face similar challenges, after all. Think about how you could fulfill the
same need while ensuring everyone can benefit from the work, and do that instead
if you can.
diff --git a/doc/development/ee_features.md b/doc/development/ee_features.md
index bd70d5b87ba0..c9fd1b75606d 100644
--- a/doc/development/ee_features.md
+++ b/doc/development/ee_features.md
@@ -111,7 +111,7 @@ There are a few gotchas with it:
smaller methods. Or create a "hook" method that is empty in CE,
and with the EE-specific implementation in EE.
- when the original implementation contains a guard clause (e.g.
- `return unless condition`), we cannot easily extend the behaviour by
+ `return unless condition`), we cannot easily extend the behavior by
overriding the method, because we can't know when the overridden method
(i.e. calling `super` in the overriding method) would want to stop early.
In this case, we shouldn't just override it, but update the original method
@@ -131,7 +131,7 @@ There are a few gotchas with it:
```
Instead of just overriding `Base#execute`, we should update it and extract
- the behaviour into another method:
+ the behavior into another method:
```ruby
class Base
@@ -613,9 +613,9 @@ module EE
end
```
-#### EE-specific behaviour
+#### EE-specific behavior
-Sometimes we need EE-specific behaviour in some of the APIs. Normally we could
+Sometimes we need EE-specific behavior in some of the APIs. Normally we could
use EE methods to override CE methods, however API routes are not methods and
therefore can't be simply overridden. We need to extract them into a standalone
method, or introduce some "hooks" where we could inject behavior in the CE
diff --git a/doc/development/fe_guide/frontend_faq.md b/doc/development/fe_guide/frontend_faq.md
index 3b0b1d8f0da8..8f8f162609a0 100644
--- a/doc/development/fe_guide/frontend_faq.md
+++ b/doc/development/fe_guide/frontend_faq.md
@@ -39,7 +39,7 @@ bundle exec rake routes | grep "issues"
### 2. `modal_copy_button` vs `clipboard_button`
-The `clipboard_button` uses the `copy_to_clipboard.js` behaviour, which is
+The `clipboard_button` uses the `copy_to_clipboard.js` behavior, which is
initialized on page load, so if there are vue-based clipboard buttons that
don't exist at page load (such as ones in a `GlModal`), they do not have the
click handlers associated with the clipboard package.
diff --git a/doc/development/fe_guide/style/javascript.md b/doc/development/fe_guide/style/javascript.md
index 7951c702601c..2f0ed3c8918d 100644
--- a/doc/development/fe_guide/style/javascript.md
+++ b/doc/development/fe_guide/style/javascript.md
@@ -192,7 +192,7 @@ if (isThingNull) {
## ESLint
-ESLint behaviour can be found in our [tooling guide](../tooling.md).
+ESLint behavior can be found in our [tooling guide](../tooling.md).
## IIFEs
diff --git a/doc/development/hash_indexes.md b/doc/development/hash_indexes.md
index 417ea18e22f1..bc962ac0cd6c 100644
--- a/doc/development/hash_indexes.md
+++ b/doc/development/hash_indexes.md
@@ -14,7 +14,7 @@ documentation:
> answers to queries that subsequently use them. For these reasons, hash index
> use is presently discouraged.
-RuboCop is configured to register an offence when it detects the use of a hash
+RuboCop is configured to register an offense when it detects the use of a hash
index.
Instead of using hash indexes you should use regular btree indexes.
diff --git a/doc/development/merge_request_performance_guidelines.md b/doc/development/merge_request_performance_guidelines.md
index 4a9b5d26aeff..b51fc681e270 100644
--- a/doc/development/merge_request_performance_guidelines.md
+++ b/doc/development/merge_request_performance_guidelines.md
@@ -24,7 +24,7 @@ The term `SHOULD` per the [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt) means
> carefully weighed before choosing a different course.
Ideally, each of these tradeoffs should be documented
-in the separate issues, labelled accordingly and linked
+in the separate issues, labeled accordingly and linked
to original issue and epic.
## Impact Analysis
diff --git a/doc/development/packages.md b/doc/development/packages.md
index 66b50ce12c87..c6d874d68154 100644
--- a/doc/development/packages.md
+++ b/doc/development/packages.md
@@ -139,7 +139,7 @@ During this phase, the idea is to collect as much information as possible about
- **Requests**: Which requests are needed to have a working MVC. Ideally, produce
a list of all the requests needed for the MVC (including required actions). Further
investigation could provide an example for each request with the request and the response bodies.
-- **Upload**: Carefully analyse how the upload process works. This will probably be the most
+- **Upload**: Carefully analyze how the upload process works. This will probably be the most
complex request to implement. A detailed analysis is desired here as uploads can be
encoded in different ways (body or multipart) and can even be in a totally different
format (for example, a JSON structure where the package file is a Base64 value of
diff --git a/doc/development/performance.md b/doc/development/performance.md
index 5068103ff161..8eb8c4eada97 100644
--- a/doc/development/performance.md
+++ b/doc/development/performance.md
@@ -109,7 +109,7 @@ In short:
By collecting snapshots of process state at regular intervals, profiling allows
you to see where time is spent in a process. The [StackProf](https://github.com/tmm1/stackprof)
gem is included in GitLab's development environment, allowing you to investigate
-the behaviour of suspect code in detail.
+the behavior of suspect code in detail.
It's important to note that profiling an application *alters its performance*,
and will generally be done *in an unrepresentative environment*. In particular,
diff --git a/doc/development/reactive_caching.md b/doc/development/reactive_caching.md
index bc5fbb58af98..0021dceefc87 100644
--- a/doc/development/reactive_caching.md
+++ b/doc/development/reactive_caching.md
@@ -256,7 +256,7 @@ which `calculate_reactive_cache` can be called.
end
```
-- The default behaviour can be overridden by defining a custom `reactive_cache_worker_finder`.
+- The default behavior can be overridden by defining a custom `reactive_cache_worker_finder`.
```ruby
class Foo < ApplicationRecord
diff --git a/doc/development/secure_coding_guidelines.md b/doc/development/secure_coding_guidelines.md
index 8e34f5490504..b473c3106472 100644
--- a/doc/development/secure_coding_guidelines.md
+++ b/doc/development/secure_coding_guidelines.md
@@ -78,7 +78,7 @@ The output of this example is `#<MatchData "bar">`, as Ruby treats the input `te
#### Impact
-This Ruby Regex speciality can have security impact, as often regular expressions are used for validations or to impose restrictions on user-input.
+This Ruby Regex specialty can have security impact, as often regular expressions are used for validations or to impose restrictions on user-input.
#### Examples
diff --git a/doc/development/testing_guide/best_practices.md b/doc/development/testing_guide/best_practices.md
index 2baf4df8f75e..2cf939eddb42 100644
--- a/doc/development/testing_guide/best_practices.md
+++ b/doc/development/testing_guide/best_practices.md
@@ -337,7 +337,7 @@ Feature.enabled?(:ci_live_trace, project2) # => true
The code exercised by a single GitLab test may access and modify many items of
data. Without careful preparation before a test runs, and cleanup afterward,
-data can be changed by a test in such a way that it affects the behaviour of
+data can be changed by a test in such a way that it affects the behavior of
following tests. This should be avoided at all costs! Fortunately, the existing
test framework handles most cases already.
diff --git a/doc/development/testing_guide/testing_levels.md b/doc/development/testing_guide/testing_levels.md
index 331b829b34d4..a7baec23e388 100644
--- a/doc/development/testing_guide/testing_levels.md
+++ b/doc/development/testing_guide/testing_levels.md
@@ -540,7 +540,7 @@ and the basic idea is that the cost of a test includes:
### Frontend-related tests
-There are cases where the behaviour you are testing is not worth the time spent
+There are cases where the behavior you are testing is not worth the time spent
running the full application, for example, if you are testing styling, animation,
edge cases or small actions that don't involve the backend,
you should write an integration test using Jasmine.
diff --git a/doc/development/value_stream_analytics.md b/doc/development/value_stream_analytics.md
index 3ceb523ab73e..69b07eb7c86a 100644
--- a/doc/development/value_stream_analytics.md
+++ b/doc/development/value_stream_analytics.md
@@ -185,7 +185,7 @@ Currently supported parents:
The [original implementation](https://gitlab.com/gitlab-org/gitlab/issues/847) of value stream analytics defined 7 stages. These stages are always available for each parent, however altering these stages is not possible.
​
-To make things efficient and reduce the number of records created, the default stages are expressed as in-memory objects (not persisted). When the user creates a custom stage for the first time, all the stages will be persisted. This behaviour is implemented in the value stream analytics service objects.
+To make things efficient and reduce the number of records created, the default stages are expressed as in-memory objects (not persisted). When the user creates a custom stage for the first time, all the stages will be persisted. This behavior is implemented in the value stream analytics service objects.
​
The reason for this was that we'd like to add the abilities to hide and order stages later on.
diff --git a/doc/development/verifying_database_capabilities.md b/doc/development/verifying_database_capabilities.md
index 1413c782c5d9..a5f5661ac9b0 100644
--- a/doc/development/verifying_database_capabilities.md
+++ b/doc/development/verifying_database_capabilities.md
@@ -2,7 +2,7 @@
Sometimes certain bits of code may only work on a certain database
version. While we try to avoid such code as much as possible sometimes it is
-necessary to add database (version) specific behaviour.
+necessary to add database (version) specific behavior.
To facilitate this we have the following methods that you can use:
diff --git a/doc/topics/git/lfs/index.md b/doc/topics/git/lfs/index.md
index 325a87215c46..03f2ddfc1de4 100644
--- a/doc/topics/git/lfs/index.md
+++ b/doc/topics/git/lfs/index.md
@@ -217,7 +217,7 @@ If you push a LFS object to a project and you receive an error similar to:
the LFS client is trying to reach GitLab through HTTPS. However, your GitLab
instance is being served on HTTP.
-This behaviour is caused by Git LFS using HTTPS connections by default when a
+This behavior is caused by Git LFS using HTTPS connections by default when a
`lfsurl` is not set in the Git config.
To prevent this from happening, set the lfs url in project Git config:
diff --git a/doc/university/support/README.md b/doc/university/support/README.md
index 0a81a5ddbcdf..5e824bcb6f9c 100644
--- a/doc/university/support/README.md
+++ b/doc/university/support/README.md
@@ -103,7 +103,7 @@ Our integrations add great value to GitLab. User questions often relate to integ
### Learn about the Support process
-Zendesk is our Support Centre and our main communication line with our Customers. We communicate with customers through several other channels too
+Zendesk is our Support Center and our main communication line with our Customers. We communicate with customers through several other channels too
- Familiarize yourself with ZenDesk:
- [UI Overview](https://support.zendesk.com/hc/en-us/articles/203661806-Introduction-to-the-Zendesk-agent-interface)
diff --git a/doc/user/project/integrations/bamboo.md b/doc/user/project/integrations/bamboo.md
index 8c7e6edbf389..db8f24fc1e1d 100644
--- a/doc/user/project/integrations/bamboo.md
+++ b/doc/user/project/integrations/bamboo.md
@@ -27,7 +27,7 @@ need to be configured in a Bamboo build plan before GitLab can integrate.
1. In the left pane, select a build stage. If you have multiple build stages
you want to select the last stage that contains the Git checkout task.
1. Select the 'Miscellaneous' tab.
-1. Under 'Pattern Match Labelling' put `${bamboo.repository.revision.number}`
+1. Under 'Pattern Match Labeling' put `${bamboo.repository.revision.number}`
in the 'Labels' box.
1. Save
diff --git a/doc/user/project/repository/index.md b/doc/user/project/repository/index.md
index 847397ebca9e..bcdac86d2a00 100644
--- a/doc/user/project/repository/index.md
+++ b/doc/user/project/repository/index.md
@@ -215,7 +215,7 @@ minutes.
Not all files are detected, among others; documentation,
-vendored code, and most markup languages are excluded. This behaviour can be
+vendored code, and most markup languages are excluded. This behavior can be
adjusted by overriding the default. For example, to enable `.proto` files to be
detected, add the following to `.gitattributes` in the root of your repository.
--
GitLab