chore: Vale errors fix

.vale.ini

@@ -1,5 +1,5 @@
 # Vale configuration file for `che-docs` repository.
-# See: https://docs.errata.ai/vale/config
+# See: https://vale.sh/docs/topics/config/
 
 # The relative path to the folder containing linting rules (styles).
 StylesPath = .vale/styles
@@ -16,15 +16,15 @@ Packages = https://github.com/redhat-documentation/vale-at-red-hat/releases/late
 MinAlertLevel = warning
 
 # IgnoredScopes specifies inline-level HTML tags to ignore.
-# These tags may occur in an active scope (unlike SkippedScopes, skipped entirely) but their content still will not raise any alerts.
+# These tags can occur in an active scope (unlike SkippedScopes, skipped entirely) but their content still will not raise any alerts.
 # Default: ignore `code` and `tt`.
 IgnoredScopes = code, tt, img, url, a, body.id
 # SkippedScopes specifies block-level HTML tags to ignore. Ignore any content in these scopes.
 # Default: ignore `script`, `style`, `pre`, and `figure`.
 # For AsciiDoc: by default, listingblock, and literalblock.
 SkippedScopes = script, style, pre, figure, code, tt, blockquote, listingblock, literalblock
 
-# Rules for matching file types. See: https://docs.errata.ai/vale/scoping
+# Rules for matching file types. See: https://vale.sh/docs/topics/scoping/
 [[!.]*.adoc]
 
 # Styles to load, located in the `StylesPath` folder:

code_review_checklist.adoc

@@ -27,9 +27,9 @@ The author and the reviewers validate the content of a pull request with this ad
 * [ ] Builds on https://workspaces.openshift.com[Eclipse Che hosted by Red Hat].
 * [ ] *`Validate language on files added or modified`* step reports no vale warnings.
 
-## In depth language review checklist
+## In-depth language review checklist
 
-The technical writer reviewers validate the language with this additional in depth checklist. We do recognize the subjectivity of some of these objectives.
+The technical writer reviewers validate the language with this additional in-depth checklist. We do recognize the subjectivity of some of these objectives.
 
 - [ ] Content is appropriate for the intended audience.
 - [ ] Downstream friendly: correct use of attributes, `ifdef` statements, examples.

modules/administration-guide/examples/snip_che-upgrading-the-chectl-management-tool.adoc

@@ -24,7 +24,7 @@ Two update channels are available for `{prod-cli}`: `stable` and `next`.
 * `stable` is for the latest released version of {prod}. 
 * `next` is updated after each activity in the `main` branch of the link:https://github.com/che-incubator/{prod-cli}[{prod-cli} repository].
 
-To move to a different channel, invoke the update with the name of the channel as an optional argument.
+To move to a different channel, start the update with the name of the channel as an optional argument.
 
 [subs="+attributes"]
 ----

modules/administration-guide/pages/configuring-storage-sizes.adoc

@@ -7,6 +7,8 @@
 [id="configuring-storage-sizes"]
 = Configuring storage sizes
 
+pass:[<!-- vale RedHat.CaseSensitiveTerms = NO -->]
+
 You can configure the persistent volume claim (PVC) size using the `per-user` or `per-workspace` storage strategies. You must specify the PVC sizes in the `CheCluster` Custom Resource in the format of a link:https://kubernetes.io/docs/reference/kubernetes-api/common-definitions/quantity/[{kubernetes} resource quantity]. For more details on the available storage strategies, see xref:configuring-the-storage-strategy.adoc[this page].
 
 Default persistent volume claim sizes:
@@ -53,4 +55,6 @@ spec:
 ----
 <1> Select the storage strategy: `per-user` or `per-workspace` or `ephemeral`. Note: the `ephemeral` storage strategy does not use persistent storage, therefore you cannot configure its storage size or other PVC-related attributes. 
 <2> Specify a claim size on the next line or omit the next line to set the default claim size value. The specified claim size is only used when you select this storage strategy.
-<3> The claim size must be specified as a link:https://kubernetes.io/docs/reference/kubernetes-api/common-definitions/quantity/[{kubernetes} resource quantity]. The available quantity units include: `Ei`, `Pi`, `Ti`, `Gi`,  `Mi` and `Ki`.
+<3> The claim size must be specified as a link:https://kubernetes.io/docs/reference/kubernetes-api/common-definitions/quantity/[{kubernetes} resource quantity]. The available quantity units include: `Ei`, `Pi`, `Ti`, `Gi`,  `Mi` and `Ki`.
+
+pass:[<!-- vale RedHat.CaseSensitiveTerms = YES -->]

modules/administration-guide/pages/user-workspaces.adoc

@@ -31,13 +31,13 @@ A workspace is one {orch-name} Deployment containing the workspace containers an
 * Secrets
 * Persistent Volumes (PV)
 
-A {prod-short} workspace contains the source code of the projects, persisted in a {platforms-name} Persistent Volume (PV). Microservices have read-write access to this shared directory.
+A {prod-short} workspace contains the source code of the projects, persisted in a {platforms-name} Persistent Volume (PV). Microservices have read/write access to this shared directory.
 
 Use the devfile v2 format to specify the tools and runtime applications of a {prod-short} workspace.
 
 The following diagram shows one running {prod-short} workspace and its components.
 
 .{prod-short} workspace components
-image::workspace-components-with-dw.png[]
+image::workspace-components-with-dw.png[Workspace components]
 
 In the diagram, there is one running workspaces.

modules/end-user-guide/pages/authenticating-to-a-git-server-from-a-workspace.adoc

@@ -7,6 +7,8 @@
 [id="authenticating-to-a-git-server-from-a-workspace"]
 = Authenticating to a Git server from a workspace
 
+pass:[<!-- vale RedHat.CaseSensitiveTerms = NO -->]
+
 In a workspace, you can run Git commands that require user authentication like cloning a remote private Git repository or pushing to a remote public or private Git repository.
 
 User authentication to a Git server from a workspace is configured by the administrator or, in some cases, by the individual user:
@@ -18,4 +20,6 @@ User authentication to a Git server from a workspace is configured by the admini
 .Additional resources
 * xref:administration-guide:configuring-oauth-for-git-providers.adoc[Administration Guide: Configuring OAuth for Git providers]
 * xref:using-a-git-provider-access-token.adoc[User Guide: Using a Git-provider access token]
-* link:https://github.com/devfile/devworkspace-operator/blob/main/docs/additional-configuration.adoc#configuring-devworkspaces-to-use-ssh-keys-for-git-operations[Configuring DevWorkspaces to use SSH keys for Git operations]
+* link:https://github.com/devfile/devworkspace-operator/blob/main/docs/additional-configuration.adoc#configuring-devworkspaces-to-use-ssh-keys-for-git-operations[Configuring DevWorkspaces to use SSH keys for Git operations]
+
+pass:[<!-- vale RedHat.CaseSensitiveTerms = YES -->]

modules/end-user-guide/pages/requesting-persistent-storage-for-workspaces.adoc

@@ -7,6 +7,8 @@
 [id="requesting-persistent-storage-for-workspaces"]
 = Requesting persistent storage for workspaces
 
+pass:[<!-- vale RedHat.CaseSensitiveTerms = NO -->]
+
 {prod-short} workspaces and workspace data are ephemeral and are lost when the workspace stops.
 
 To preserve the workspace state in persistent storage while the workspace is stopped, request a {kubernetes} PersistentVolume (PV) for the `{devworkspace}` containers in the {orch-name} cluster of your organization's {prod-short} instance.
@@ -29,3 +31,5 @@ Starting another, concurrently running workspace with a link:https://kubernetes.
 
 include::partial$proc_requesting-persistent-storage-in-a-devfile.adoc[leveloffset=+1]
 include::partial$proc_requesting-persistent-storage-in-a-pvc.adoc[leveloffset=+1]
+
+pass:[<!-- vale RedHat.CaseSensitiveTerms = YES -->]

modules/end-user-guide/pages/using-a-git-provider-access-token.adoc

@@ -7,22 +7,16 @@
 [id="using-a-git-provider-access-token"]
 = Using a Git-provider access token
 
-pass:[<!-- vale RedHat.Spelling = NO -->]
+pass:[<!-- vale RedHat.CaseSensitiveTerms = NO -->]
 
 OAuth for GitHub, GitLab, Bitbucket, or Microsoft Azure Repos needs to be xref:administration-guide:configuring-oauth-for-git-providers.adoc[configured by the administrator] of your organization's {prod-short} instance. If your administrator could not configure it for {prod-short} users, the workaround is for you to use a personal access token. You can configure personal access tokens on the *User Preferences* page of your {prod-short} dashboard: `pass:c,a,q[{prod-url}]/dashboard/#/user-preferences?tab=personal-access-tokens`, or apply it manually as a {kubernetes} Secret in the namespace.
 
-pass:[<!-- vale RedHat.Spelling = YES -->]
-
 Mounting your access token as a Secret enables the {prod-short} Server to access the remote repository that is cloned during workspace creation, including access to the repository's `/.che` and `/.vscode` folders.
 
 Apply the Secret in your user {orch-namespace} of the {orch-name} cluster of your organization's {prod-short} instance.
 
-pass:[<!-- vale RedHat.Spelling = NO -->]
-
 After applying the Secret, you can create workspaces with clones of private Git repositories that are hosted on GitHub, GitLab, Bitbucket Server, or Microsoft Azure Repos.
 
-pass:[<!-- vale RedHat.Spelling = YES -->]
-
 You can create and apply multiple access-token Secrets per Git provider. You must apply each of those Secrets in your user {orch-namespace}.
 
 .Prerequisites
@@ -132,3 +126,10 @@ EOF
 
 * xref:administration-guide:deploying-che-with-support-for-git-repositories-with-self-signed-certificates.adoc[Deploying Che with support for Git repositories with self-signed certificates]
 * link:https://docs.github.com/en/enterprise-cloud@latest/authentication/authenticating-with-saml-single-sign-on/authorizing-a-personal-access-token-for-use-with-saml-single-sign-on[Authorizing a personal access token for use with SAML single sign-on]
+
+pass:[<!-- vale RedHat.CaseSensitiveTerms = YES -->]
+
+
+
+
+

modules/end-user-guide/pages/using-credentials-and-configurations-in-workspaces.adoc

@@ -7,13 +7,15 @@
 [id="using-credentials-and-configurations-in-workspaces"]
 = Using credentials and configurations in workspaces
 
+pass:[<!-- vale RedHat.CaseSensitiveTerms = NO -->]
+
 You can use your credentials and configurations in your workspaces.
 
 To do so, mount your credentials and configurations to the `{devworkspace}` containers in the {orch-name} cluster of your organization's {prod-short} instance:
 
 * Mount your credentials and sensitive configurations as {kubernetes} xref:mounting-secrets.adoc[Secrets].
 
-* Mount your non-sensitve configurations as {kubernetes} xref:mounting-configmaps.adoc[ConfigMaps].
+* Mount your non-sensitive configurations as {kubernetes} xref:mounting-configmaps.adoc[ConfigMaps].
 
 If you need to allow the `{devworkspace}` Pods in the cluster to access container registries that require authentication, create an xref:creating-image-pull-secrets.adoc[image pull Secret] for the `{devworkspace}` Pods.
 
@@ -33,3 +35,5 @@ You can create permanent mount points for various components:
 
 * link:https://kubernetes.io/docs/concepts/configuration/secret/[Kubernetes Documentation: Secrets]
 * link:https://kubernetes.io/docs/concepts/configuration/configmap/[Kubernetes Documentation: ConfigMaps]
+
+pass:[<!-- vale RedHat.CaseSensitiveTerms = YES -->]

modules/end-user-guide/partials/proc_requesting-persistent-storage-in-a-pvc.adoc

@@ -41,7 +41,7 @@ Defaults to `/tmp/__<PVC_name>__`.
 | `controller.devfile.io/read-only:`
 | Set to `'true'` or `'false'` to specify whether the PVC is to be mounted as read-only.
 
-Defaults to `'false'`, resulting in the PVC mounted as read-write.
+Defaults to `'false'`, resulting in the PVC mounted as read/write.
 |===
 
 .Mounting a read-only PVC