From 41fd7fbf46ca9e3a46f5ace2a1de213929d9e347 Mon Sep 17 00:00:00 2001
From: HonkingGoose <34918129+HonkingGoose@users.noreply.github.com>
Date: Mon, 28 Mar 2022 21:25:49 +0200
Subject: [PATCH] docs: replace however with but (#14707)

Co-authored-by: Anne Stellingwerf <astellin@opentext.com>
Co-authored-by: HonkingGoose <34918129+HonkingGoose@users.noreply.github.com>
Co-authored-by: Rhys Arkins <rhys@arkins.net>
---
 docs/development/design-decisions.md          |  2 +-
 docs/development/local-development.md         |  2 +-
 docs/usage/configuration-options.md           | 30 ++++++++++---------
 docs/usage/dependency-pinning.md              |  4 +--
 docs/usage/docker.md                          |  2 +-
 .../getting-started/installing-onboarding.md  |  2 +-
 .../usage/getting-started/private-packages.md |  4 +--
 docs/usage/gitlab-bot-security.md             |  4 +--
 docs/usage/java.md                            |  2 +-
 docs/usage/key-concepts/automerge.md          |  2 +-
 docs/usage/key-concepts/dashboard.md          |  2 +-
 docs/usage/known-limitations.md               |  2 +-
 lib/modules/versioning/composer/readme.md     |  2 +-
 13 files changed, 31 insertions(+), 29 deletions(-)

diff --git a/docs/development/design-decisions.md b/docs/development/design-decisions.md
index 79b0dc69c1..e45afb458e 100644
--- a/docs/development/design-decisions.md
+++ b/docs/development/design-decisions.md
@@ -51,7 +51,7 @@ By default, `renovate` will maintain separate branches for each dependency.
 So if 20 dependencies need updating, there will be at least 20 branches/PRs.
 Although this may seem undesirable, it's even less desirable if all 20 were in the same Pull Request and it's very difficult to work out which upgrade caused the test failure.
 
-However, you can override the default templates for branch name to get a single branch for all dependencies.
+But you can override the default templates for branch name to get a single branch for all dependencies.
 The `groupName` configuration option can be used at a repository level (e.g. give it the value `All`) and then all dependency updates will be in the same branch/PR.
 
 ## Separate Minor and Major PRs
diff --git a/docs/development/local-development.md b/docs/development/local-development.md
index fe9a54bb8d..d9d28660e3 100644
--- a/docs/development/local-development.md
+++ b/docs/development/local-development.md
@@ -164,7 +164,7 @@ To do this, see these GitHub guides:
 ### Running Renovate against forked repositories
 
 Quite often, the quickest way for you to test or fix something is to fork an existing repository.
-However, by default Renovate skips over repositories that are forked.
+But by default Renovate skips over repositories that are forked.
 To override this default, you need to specify the setting `includeForks` as `true`.
 
 Tell Renovate to run on your forked repository by doing one of the following:
diff --git a/docs/usage/configuration-options.md b/docs/usage/configuration-options.md
index cc5194f678..1d5cdb9b53 100644
--- a/docs/usage/configuration-options.md
+++ b/docs/usage/configuration-options.md
@@ -164,7 +164,7 @@ Important: Renovate won't automerge on GitHub if a PR has a negative review outs
 <!-- prettier-ignore -->
 !!! note
     On Azure there can be a delay between a PR being set as completed by Renovate, and Azure merging the PR / finishing its tasks.
-    Renovate tries to delay until Azure is in the expected state, however if it takes too long it will continue.
+    Renovate tries to delay until Azure is in the expected state, but it will continue if it takes too long.
     In some cases this can result in a dependency not being merged, and a fresh PR being created for the dependency.
 
 ## automergeComment
@@ -238,7 +238,7 @@ Creating a work item in Azure DevOps is beyond the scope of Renovate, but Renova
 
 By default, Renovate will detect and process only the repository's default branch.
 For most projects, this is the expected approach.
-However, Renovate also allows users to explicitly configure `baseBranches`, e.g. for use cases such as:
+Renovate also allows users to explicitly configure `baseBranches`, e.g. for use cases such as:
 
 - You wish Renovate to process only a non-default branch, e.g. `dev`: `"baseBranches": ["dev"]`
 - You have multiple release streams you need Renovate to keep up to date, e.g. in branches `main` and `next`: `"baseBranches": ["main", "next"]`
@@ -260,7 +260,7 @@ By default, Renovate won't enforce any concurrent branch limits.
 The `config:base` preset that many extend from limits the number of concurrent branches to 10, but in many cases a limit as low as 3 or 5 can be most efficient for a repository.
 
 If you want the same limit for both concurrent branches and concurrent PRs, then just set a value for `prConcurrentLimit` and it will be reused for branch calculations too.
-However, if you want to allow more concurrent branches than concurrent PRs, you can configure both values (e.g. `branchConcurrentLimit=5` and `prConcurrentLimit=3`).
+But if you want to allow more concurrent branches than concurrent PRs, you can configure both values (e.g. `branchConcurrentLimit=5` and `prConcurrentLimit=3`).
 
 This limit is enforced on a per-repository basis.
 
@@ -372,7 +372,7 @@ The "extra" is usually an identifier of the new version, e.g. "to v1.3.2" or "to
 ## commitMessagePrefix
 
 This is used to alter `commitMessage` and `prTitle` without needing to copy/paste the whole string.
-The "prefix" is usually an automatically applied semantic commit prefix, however it can also be statically configured.
+The "prefix" is usually an automatically applied semantic commit prefix, but it can also be statically configured.
 
 ## commitMessageSuffix
 
@@ -823,7 +823,8 @@ Also, approval rules overriding should not be [prevented in GitLab settings](htt
 
 ## golang
 
-Configuration added here applies for all Go-related updates, however currently the only supported package manager for Go is the native Go Modules (the `gomod` manager).
+Configuration added here applies for all Go-related updates.
+The only supported package manager for Go is the native Go Modules (the `gomod` manager).
 
 For self-hosted users, `GOPROXY`, `GONOPROXY` and `GOPRIVATE` environment variables are supported ([reference](https://go.dev/ref/mod#module-proxy)).
 
@@ -838,7 +839,7 @@ Also we support the `off` keyword which will stop any fetching immediately.
     Do not use unless you know what you're doing.
 
 The default configuration for groups are essentially internal to Renovate and you normally shouldn't need to modify them.
-However, you may choose to _add_ settings to any group by defining your own `group` configuration object.
+But you may _add_ settings to any group by defining your own `group` configuration object.
 
 ## groupName
 
@@ -1169,7 +1170,8 @@ For instance if you have a project with an `"examples/"` directory you wish to i
 }
 ```
 
-Useful to know: Renovate's default ignore is `node_modules` and `bower_components` only, however if you are extending the popular `config:base` preset then it adds ignore patterns for `vendor`, `examples`, `test(s)` and `fixtures` directories too.
+Renovate's default ignore is `node_modules` and `bower_components` only.
+If you are extending from the popular `config:base` preset then it adds ignore patterns for `vendor`, `examples`, `test(s)` and `fixtures` directories too.
 
 ## ignorePlugins
 
@@ -2112,7 +2114,7 @@ Using the `in-range-only` strategy may result in you being multiple releases beh
 ## rebaseLabel
 
 On supported platforms it is possible to add a label to a PR to manually request Renovate to recreate/rebase it.
-By default this label is `"rebase"` however you can configure it to anything you want by changing this `rebaseLabel` field.
+By default this label is `"rebase"` but you can configure it to anything you want by changing this `rebaseLabel` field.
 
 ## rebaseWhen
 
@@ -2157,7 +2159,7 @@ Users can define custom managers for cases such as:
 The custom manager concept is based on using Regular Expression named capture groups.
 For the fields `datasource`, `depName` and `currentValue`, it's mandatory to have either a named capture group matching them (e.g. `(?<depName>.*)`) or to configure it's corresponding template (e.g. `depNameTemplate`).
 It's not recommended to do both, due to the potential for confusion.
-It is recommended to also include `versioning` however if it is missing then it will default to `semver`.
+It is recommended to also include `versioning` but if it is missing then it will default to `semver`.
 
 For more details and examples, see the documentation page the for the regex manager [here](/modules/manager/regex/).
 For template fields, use the triple brace `{{{ }}}` notation to avoid Handlebars escaping any special characters.
@@ -2222,7 +2224,7 @@ ENV NODE_VERSION=10.19.0 # github-tags/nodejs/node&versioning=node
 
 If using `recursive` the `matchStrings` will be looped through and the full match of the last will define the range of the next one.
 This can be used to narrow down the search area to prevent multiple matches.
-However, the `recursive` strategy still allows the matching of multiple dependencies as described below.
+But the `recursive` strategy still allows the matching of multiple dependencies as described below.
 All matches of the first `matchStrings` pattern are detected, then each of these matches will used as basis be used as the input for the next `matchStrings` pattern, and so on.
 If the next `matchStrings` pattern has multiple matches then it will split again.
 This process will be followed as long there is a match plus a next `matchingStrings` pattern is available or a dependency is detected.
@@ -2231,7 +2233,7 @@ Matched groups will be available in subsequent matching layers.
 
 This is an example how this can work.
 The first regex manager will only upgrade `grafana/loki` as looks for the `backup` key then looks for the `test` key and then uses this result for extraction of necessary attributes.
-However, the second regex manager will upgrade both definitions as its first `matchStrings` matches both `test` keys.
+But the second regex manager will upgrade both definitions as its first `matchStrings` matches both `test` keys.
 
 renovate.json:
 
@@ -2425,7 +2427,7 @@ In case there is a need to configure them manually, it can be done using this `r
 }
 ```
 
-The field supports multiple URLs however it is datasource-dependent on whether only the first is used or multiple.
+The field supports multiple URLs but it is datasource-dependent on whether only the first is used or multiple.
 
 ## replacement
 
@@ -2554,7 +2556,7 @@ If you are using a semantic prefix for your commits, then you will want to enabl
 Although it's configurable to a package-level, it makes most sense to configure it at a repository level.
 If configured to `enabled`, then the `semanticCommitScope` and `semanticCommitType` fields will be used for each commit message and PR title.
 
-However, please note that Renovate will autodetect if your repository is already using semantic commits or not and follow suit, so you only really need to configure this if you wish to _override_ Renovate's autodetected setting.
+Renovate autodetects if your repository is already using semantic commits or not and follows suit, so you only need to configure this if you wish to _override_ Renovate's autodetected setting.
 
 ## separateMajorMinor
 
@@ -2639,7 +2641,7 @@ This works because Renovate will add a "renovate/stability-days" pending status
 ## stopUpdatingLabel
 
 On supported platforms it is possible to add a label to a PR to request Renovate stop updating the PR.
-By default this label is `"stop-updating"` however you can configure it to anything you want by changing this `stopUpdatingLabel` field.
+By default this label is `"stop-updating"` but you can configure it to anything you want by changing this `stopUpdatingLabel` field.
 
 ## suppressNotifications
 
diff --git a/docs/usage/dependency-pinning.md b/docs/usage/dependency-pinning.md
index a0eaac9718..5fccc798cd 100644
--- a/docs/usage/dependency-pinning.md
+++ b/docs/usage/dependency-pinning.md
@@ -6,7 +6,7 @@ description: The pros and cons of dependency pinning for JavaScript/npm
 # Should you Pin your JavaScript Dependencies?
 
 Once you start using a tool/service like Renovate, probably the biggest decision you need to make is whether to "pin" your dependencies instead of using SemVer ranges.
-The answer is "It's your choice", however we can certainly make some generalisations/recommendations to help you.
+The answer is "It's your choice", but we can certainly make some generalisations/recommendations to help you.
 
 If you do not want to read the in-depth discussion, and just want our recommendations, skip ahead to the ["So what's best?" section](#so-whats-best).
 
@@ -94,7 +94,7 @@ Depending on how many repositories you maintain, and how many dependencies are i
 ## Reducing the "noise" of dependency updates
 
 The increased volume of Pull Requests for upgrading dependencies may be considered by some to be undesirable "noise" in their day.
-To some extent this is simply a trade-off for having your dependencies pinned and predictable, however there are also ways you can reduce this noise while still gaining the majority of the benefits:
+To some extent this is simply a trade-off for having your dependencies pinned and predictable, but there are also ways you can reduce this noise while still gaining the majority of the benefits:
 
 ### Pull Request automerging
 
diff --git a/docs/usage/docker.md b/docs/usage/docker.md
index ec77b1f4d2..24c736d522 100644
--- a/docs/usage/docker.md
+++ b/docs/usage/docker.md
@@ -24,7 +24,7 @@ Renovate supports upgrading dependencies in various types of Docker definition f
 By default, Renovate preserves the precision level specified in the Docker images.
 For example, if the existing image is pinned at `myimage:1.1` then Renovate only proposes upgrades to `myimage:1.2` or `myimage:1.3`.
 This means that you will not get upgrades to a more specific versions like `myimage:1.2.0` or `myimage:1.3.0`.
-Renovate does not yet support "pinning" an imprecise version to a precise version, e.g. from `myimage:1.2` to `myimage:1.2.0`, however it's a feature we'd like to work on one day.
+Renovate does not yet support "pinning" an imprecise version to a precise version, e.g. from `myimage:1.2` to `myimage:1.2.0`, but it's a feature we'd like to work on one day.
 
 ## Version compatibility
 
diff --git a/docs/usage/getting-started/installing-onboarding.md b/docs/usage/getting-started/installing-onboarding.md
index 87855ad6d3..3d307f4c63 100644
--- a/docs/usage/getting-started/installing-onboarding.md
+++ b/docs/usage/getting-started/installing-onboarding.md
@@ -95,7 +95,7 @@ Sometimes Renovate detects that an override to these defaults is needed, and wil
 Please check the docs on this website for an exhaustive Configuration Reference.
 To help you get started, here are some of the most commonly changed (overridden) configuration settings:
 
-- **rangeStrategy**: By default (with zero config) it's `"replace"` however the `"config:base"` preset overrides it to `"auto"`. If you don't want to pin dependency versions and retain ranges, add the `":preserveSemverRanges"` preset to the `extends` array
+- **rangeStrategy**: By default (with zero config) it's `"replace"` but the `"config:base"` preset overrides it to `"auto"`. If you don't want to pin dependency versions and retain ranges, add the `":preserveSemverRanges"` preset to the `extends` array
 - **labels**: Labels to assign to Pull Requests
 - **assignees**: GitHub user(s) to assign the Pull Requests to
 
diff --git a/docs/usage/getting-started/private-packages.md b/docs/usage/getting-started/private-packages.md
index be2c30a065..3a3072fb45 100644
--- a/docs/usage/getting-started/private-packages.md
+++ b/docs/usage/getting-started/private-packages.md
@@ -56,7 +56,7 @@ Renovate does not use any package managers for this step and performs all HTTP(S
 Configuring Renovate with credentials requires `hostRules`.
 Each host rule consists of a `hostType` value and/or a way to match against hosts using `matchHost`.
 
-`hostType` is not particularly important at this step unless you have different credentials for the same host, however it is sometimes useful in later steps so is good to include if you can.
+`hostType` is not particularly important at this step unless you have different credentials for the same host, but it is sometimes useful in later steps so is good to include if you can.
 It can be either a "platform" name (e.g. `github`, `azure`, etc) or a "datasource" name (e.g. `npm`, `maven`, `github-tags`, etc).
 
 If you want to apply credentials only for a nested path within a host then write `matchHost` as a base URL like `https://registry.company.com/nested/path/`.
@@ -94,7 +94,7 @@ When Renovate creates Pull Requests, its default behavior is to locate and embed
 These release notes are fetched from the source repository of packages and not from the registries themselves, so if they are private then they will require different credentials.
 
 When it comes to open source, most packages host their source on `github.com` in public repositories.
-However, GitHub greatly rate limits unauthenticated API requests so there is a need to configure credentials for github.com as otherwise the bot will get rate limited quickly.
+GitHub greatly rate limits unauthenticated API requests, so you need to configure credentials for github.com or the bot will get rate limited quickly.
 It can be confusing for people who host their own source code privately to be asked to configure a `github.com` token but without it Release Notes for most open source packages will be blocked.
 
 Currently the preferred way to configure `github.com` credentials for self-hosted Renovate is:
diff --git a/docs/usage/gitlab-bot-security.md b/docs/usage/gitlab-bot-security.md
index 063e6b2eda..9924be1f6c 100644
--- a/docs/usage/gitlab-bot-security.md
+++ b/docs/usage/gitlab-bot-security.md
@@ -11,7 +11,7 @@ You should understand GitLab's security model, before deciding to run a "bot" se
 ## `CI_JOB_TOKEN` permissions
 
 The concept of `CI_JOB_TOKEN` permissions was [overhauled in GitLab release 8.12](https://docs.gitlab.com/ee/user/project/new_ci_build_permissions_model.html), jobs are now run with the permissions of the user account which _triggered_ the pipeline.
-For security reasons the token was limited to read-only permissions and a limited set of API endpoints, however it’s since been extended to allow [write access to the GitLab Package Registry](https://docs.gitlab.com/ee/api/README.html#gitlab-ci-job-token).
+For security reasons the token was limited to read-only permissions and a limited set of API endpoints, but it’s been extended to allow [write access to the GitLab Package Registry](https://docs.gitlab.com/ee/api/README.html#gitlab-ci-job-token).
 Any pipeline triggered by a user account thus has permissions to read any repository which that account has access to as well as publish packages to them.
 
 With the current GitLab CI permissions model, you should avoid committing to any project which you don’t trust completely, because that project could maliciously steal repository data, publish fake releases, or spam releases.
@@ -34,7 +34,7 @@ The following research notes may help you to assess the GitLab bot security risk
 ### Public projects only
 
 If a bot service is run on public projects only, then the risk of private project data being accessed by unauthorized users is zero.
-However, malicious users can still spoof or spam packages to any other public project they themselves are not a member of, so that rules out this approach for a public hosted service.
+But malicious users can still spoof or spam packages to any other public project they are not a member of, so that rules out this approach for a public hosted service.
 
 A public-visibility-only bot service should be low risk for most self-hosted GitLab instances.
 There is still a small problem that you can't _prevent_ users from inviting the bot into private projects if they are not aware of the risks of doing so.
diff --git a/docs/usage/java.md b/docs/usage/java.md
index 51f3a38e55..164868f745 100644
--- a/docs/usage/java.md
+++ b/docs/usage/java.md
@@ -54,7 +54,7 @@ As Renovate takes the `distributionUrl` defined inside the `gradle-wrapper.prope
 
 This can be used for hosting the official distributions with a proxy server, an offline mirror or even providing a custom distribution of the Gradle Wrapper, e.g. to provide a company-wide base configuration for all Gradle projects.
 
-However, the `gradle-version` datasource is used to determine available versions.
+But the `gradle-version` datasource is used to determine available versions.
 In case the available versions at the defined source differ from those available from Gradle or the [default datasource](https://services.gradle.org/versions/all) cannot be reached, e.g. due to network restrictions, the datasource may be reconfigured via a `packageRule`:
 
 ```json
diff --git a/docs/usage/key-concepts/automerge.md b/docs/usage/key-concepts/automerge.md
index a0bf0b2977..b8b9eeefe8 100644
--- a/docs/usage/key-concepts/automerge.md
+++ b/docs/usage/key-concepts/automerge.md
@@ -50,7 +50,7 @@ Here is an example of automerging lock file maintenance:
 
 Automerging lint tool updates can be a real time-saver.
 Sometimes an update to a lint tool or plugin definition causes tests to fail, and that is usually deliberate/intentional because the lint authors have added a new rule that you need to adhere to.
-However, in many cases the new version(s) will pass tests, and if so then there's really nothing else to consider before merging, so they may as well be automerged:
+But in many cases the new version(s) will pass tests, and if so then there's really nothing else to consider before merging, so they may as well be automerged:
 
 ```json
 {
diff --git a/docs/usage/key-concepts/dashboard.md b/docs/usage/key-concepts/dashboard.md
index 0d6f0ad56a..38f127df65 100644
--- a/docs/usage/key-concepts/dashboard.md
+++ b/docs/usage/key-concepts/dashboard.md
@@ -80,7 +80,7 @@ Maybe you find Renovate too noisy, and want to opt-out of getting automatic upda
 In this case, you can tell Renovate to wait for your approval before making any pull requests.
 This means that you have full control over when you get updates.
 
-However, vulnerability remediation PRs will still get created immediately without requiring approval.
+But vulnerability remediation PRs will still get created immediately without requiring approval.
 
 To require manual approval for _all updates_, add the `:dependencyDashboardApproval` presets to the `extends` array in your Renovate configuration file:
 
diff --git a/docs/usage/known-limitations.md b/docs/usage/known-limitations.md
index 0d27d63c3c..87a12f6709 100644
--- a/docs/usage/known-limitations.md
+++ b/docs/usage/known-limitations.md
@@ -40,4 +40,4 @@ The limitation to only automerge branches which are up-to-date is a decision due
 - PRs exist for `alice@2.0.0` and `bob@2.0.0` and both pass tests
 - The PR for `alice@2.0.0` is automerged
 - The PR for `bob@2.0.0` remains open, does not have conflicts, and has all tests passing
-- However, `alice@2.0.0` and `bob@2.0.0` are incompatible so merging the PR without rebasing and retesting it first would result in a broken base branch
+- But `alice@2.0.0` and `bob@2.0.0` are incompatible so merging the PR without rebasing and retesting it first would result in a broken base branch
diff --git a/lib/modules/versioning/composer/readme.md b/lib/modules/versioning/composer/readme.md
index f47e656cba..dc8fd52f9b 100644
--- a/lib/modules/versioning/composer/readme.md
+++ b/lib/modules/versioning/composer/readme.md
@@ -1,4 +1,4 @@
-Composer uses Semver-like versioning, however some package authors may use versions that are not completely valid, e.g. `1.2` instead of `1.2.0`.
+Composer uses Semver-like versioning, but some package authors may use versions that are not completely valid, e.g. `1.2` instead of `1.2.0`.
 
 Composer supports ranges in a similar manner to npm, but not identical. The main difference is with tilde ranges.
 
-- 
GitLab