Fix vale rules in installation guide

.vale/styles/Vocab/Che/accept.txt

@@ -1,10 +1,11 @@
-.NET
+\.NET
 adoc
+[Aa]nsible
 Antora
 API
 AsciiDoc
 autostart
-AWS
+AWS|aws
 Bitbucket
 [Bb]oolean
 breakpoint
@@ -24,6 +25,7 @@ DaemonSet
 Developer Perspective
 [Dd]evfile
 [Dd]evfiles
+Dev Workspace
 DNS
 Docker
 Dockerfile
@@ -56,6 +58,7 @@ Keycloak|keycloak
 Kubernetes
 Kubespray
 Java Lombok
+Let\'s Encrypt
 loopback
 Mattermost
 [Mm]aven
@@ -68,9 +71,10 @@ millicores
 [Mm]ixins
 [Mm]ultiuser
 MySQL
-namespace
-namespaces
+[Nn]amespace
+[Nn]amespaces
 [Nn]etcoredebug[Oo]utput
+[Nn]ginx
 Node.js
 npm
 NuGet
@@ -90,6 +94,7 @@ Pods
 PostgreSQL
 preconfigured
 Quarkus
+readonly
 runtime
 runtimes
 rollout

.vale/styles/Vocab/Che/reject.txt

@@ -1,14 +1,10 @@
 admin
 almost
 clicking
-e.g.
-etc.
 grab
-i.e.
 info
 [Kk]8[Ss]
 Kube
-let's
 look up
 maybe
 mostly

antora-playbook.yml

@@ -42,6 +42,7 @@ asciidoc:
     che-devfile-registry-directory: che-devfile-registry
     che-plugin-registry-container-image: quay.io/eclipse/che-plugin-registry
     che-plugin-registry-directory: che-plugin-registry
+    devworkspace: Dev Workspace
     identity-provider-docs-url: https://www.keycloak.org/docs/
     identity-provider-image-url: quay.io/eclipse/che-keycloak
     identity-provider-url: https://www.keycloak.org/
@@ -83,13 +84,14 @@ asciidoc:
     ocp4-ver: 4.6
     orch-cli: kubectl
     orch-cli-link: link:https://kubernetes.io/docs/reference/kubectl/overview/[Overview of kubectl]
+    orch-ingress: Kubernetes Ingress
+    orch-name: Kubernetes
+    orch-namespace: namespace # In context: orch-name orch-namespace
+    osd: OpenShift Dedicated
     platforms-cli: "`kubectl` or `oc`"
     platforms-ingress: Kubernetes Ingress or OpenShift Route
     platforms-name: Kubernetes or OpenShift
     platforms-namespace: Kubernetes namespace or OpenShift project
-    orch-name: Kubernetes
-    orch-namespace: namespace # In context: orch-name orch-namespace
-    osd: OpenShift Dedicated
     postgresql-image-url: quay.io/eclipse/che-postgres
     prod-checluster: eclipse-che
     prod-cli: chectl

modules/installation-guide/examples/checluster-properties.adoc

@@ -131,7 +131,7 @@ ingressDomain: Global ingress domain for a Kubernetes cluster. This MUST be expl
 ingressStrategy: Strategy for ingress creation. Options are\: `multi-host` (host is explicitly provided in ingress), `single-host` (host is provided, path-based rules) and `default-host` (no host is provided, path-based rules). Defaults to `multi-host` Deprecated in favor of `serverExposureStrategy` in the `server` section, which defines this regardless of the cluster type. When both are defined, the `serverExposureStrategy` option takes precedence.
 securityContextFsGroup: The FSGroup in which the Che Pod and workspace Pods containers runs in. Default value is `1724`.
 securityContextRunAsUser: ID of the user the Che Pod and workspace Pods containers run as. Default value is `1724`.
-singleHostExposureType: When the serverExposureStrategy is set to `single-host`, the way the server, registries and workspaces are exposed is further configured by this property. The possible values are `native`, which means that the server and workspaces are exposed using ingresses on K8s or `gateway` where the server and workspaces are exposed using a custom gateway based on link\:https\://doc.traefik.io/traefik/[Traefik]. All the endpoints whether backed by the ingress or gateway `route` always point to the subpaths on the same domain. Defaults to `native`.
+singleHostExposureType: When the serverExposureStrategy is set to `single-host`, the way the server, registries and workspaces are exposed is further configured by this property. The possible values are `native`, which means that the server and workspaces are exposed using ingresses on {kubernetes} or `gateway` where the server and workspaces are exposed using a custom gateway based on link\:https\://doc.traefik.io/traefik/[Traefik]. All the endpoints whether backed by the ingress or gateway `route` always point to the subpaths on the same domain. Defaults to `native`.
 tlsSecretName: Name of a secret that will be used to setup ingress TLS termination when TLS is enabled. When the field is empty string, the default cluster certificate will be used. See also the `tlsSupport` field.
 :=== 
 

modules/installation-guide/examples/ref_che-supported-platforms-and-installation-methods.adoc

@@ -17,10 +17,10 @@ The following options are available:
 |{kubernetes}
 |Installation method
 
-a|* minikube
-* microk8s
-* docker-desktop
-* kind
+a|* `minikube`
+* `microk8s`
+* `docker-desktop`
+* `kind`
 |`{prod-cli}` using Helm Chart or Operator
 |===
 

modules/installation-guide/pages/configuring-labels-for-ingresses.adoc

@@ -1,6 +1,5 @@
 [id="configuring-labels-for-ingresses"]
-// = Configuring Labels
-:navtitle: Configuring labels for Kubernetes Ingress
+:navtitle: Configuring labels for {orch-ingress}
 :keywords: installation-guide, configuring-labels
 :page-aliases: .:configuring-labels-for-ingresses
 

modules/installation-guide/partials/con_persistent-volume-configuration.adoc

@@ -20,7 +20,7 @@ All workspaces inside a {platforms-namespace} use the same Persistent Volume Cla
 * workspace logs
 * additional Volumes defined by a use
 
-When the `common` PVC strategy is in use,  user-defined PVCs are ignored and volumes that refer to these user-defined PVCs are replaced with a volume that refers to the common PVC.
+When the `common` PVC strategy is in use, user-defined PVCs are ignored and volumes that relate to these user-defined PVCs are replaced with a volume that refers to the common PVC.
 In this strategy, all {prod-short} workspaces use the same PVC. When the user runs one workspace, it only binds to one node in the cluster at a time.
 
 The corresponding containers volume mounts link to a common volume, and sub-paths are prefixed with `_<workspace-ID>_` or `__<original-PVC-name>__`. For more details, see xref:how-subpaths-are-used-in-pvcs_{context}[].

modules/installation-guide/partials/con_security-considerations.adoc

@@ -24,7 +24,7 @@ The JWT proxy accepts the workspace access token from the following places in th
 
 == Secured plug-ins and editors
 
-{prod-short} users do not need to secure workspace plug-ins and workspace editors (such as Che-Theia). This is because the JWT proxy authentication is transparent to the user and is governed by the plug-in or editor definition in their `meta.yaml` descriptors.
+{prod-short} users do not need to secure workspace plug-ins and workspace editors (such as Che-Theia). This is because the JWT proxy authentication is indiscernible to the user and is governed by the plug-in or editor definition in their `meta.yaml` descriptors.
 
 == Secured container-image components
 

modules/installation-guide/partials/con_understanding-che-server-advanced-configuration-using-the-operator.adoc

@@ -36,7 +36,7 @@ spec:
 
 [NOTE]
 ====
-Previous versions of the {prod-short} Operator had a configMap named `custom` to fulfill this role. If the {prod-short} Operator finds a `configMap` with the name `custom`, it adds the data it contains into the `customCheProperties` field, redeploys {prod-short}, and deletes the `custom` `configMap`.
+Previous versions of the {prod-short} Operator had a ConfigMap named `custom` to fulfill this role. If the {prod-short} Operator finds a `configMap` with the name `custom`, it adds the data it contains into the `customCheProperties` field, redeploys {prod-short}, and deletes the `custom` `configMap`.
 ====
 
 .Additional resources

modules/installation-guide/partials/con_workspace-exposure-strategies.adoc

@@ -42,7 +42,7 @@ Single-host strategy have two subtypes with different implementation methods. Fi
 With `gateway` single-host strategy, cluster network policies has to be configured so that workspace's services are reachable from reverse-proxy Pod (typically in {prod-short} {orch-namespace}). These typically lives in different {orch-namespace}.
 ====
 
-There are two ways of exposing the endpoints specified in the devfile. These can be configured using the `++CHE_INFRA_KUBERNETES_SINGLEHOST_WORKSPACE_DEVFILE__ENDPOINT__EXPOSURE++` environment variable of the {prod-short}. This environment variable is only effective with the single-host server strategy and is applicable to all workspaces of all users.
+To define how to expose the endpoints specified in the devfile, define the `++CHE_INFRA_KUBERNETES_SINGLEHOST_WORKSPACE_DEVFILE__ENDPOINT__EXPOSURE++` environment variable in the {prod-short} instance. This environment variable is only effective with the single-host server strategy and is applicable to all workspaces of all users.
 
 === devfile endpoints: `single-host`
 

modules/installation-guide/partials/proc_configuring-dns-on-azure.adoc

@@ -1,7 +1,3 @@
-// Module included in the following assemblies:
-//
-// installing-{prod-id-short}-on-microsoft-azure
-
 [id="configuring-DNS-on-azure_{context}"]
 = Configuring DNS on Azure
 
@@ -11,27 +7,27 @@ To configure DNS on Azure:
 
 . In the Azure web console, navigate to *Home* -> *DNS zones*.
 +
-image::installation/dns-zone-in-microsoft-azure.png[link="../_images/installation/dns-zone-in-microsoft-azure.png"]
+image::installation/dns-zone-in-microsoft-azure.png[DNS zone in Microsoft Azure,link="../_images/installation/dns-zone-in-microsoft-azure.png"]
 
 . Create a new zone.
 +
 .. In the *Resource group* drop-down list, click *eclipseCheResourceGroup*.
 +
-image::installation/selecting-the-resource-group.png[link="../_images/installation/selecting-the-resource-group.png"]
+image::installation/selecting-the-resource-group.png[Selecting the resource group,link="../_images/installation/selecting-the-resource-group.png"]
 
-.. In the *Instance details* section, in the *Name* field, type the name of the domain (*azr.my-ide.cloud*, in this case).
+.. In the *Instance details* section, in the *Name* field, type the name of the domain (`azr.my-ide.cloud`, in this case).
 
 .. Click the btn:[Review + create] button.
 +
-image::installation/entering-the-name-fo-the-domain.png[link="../_images/installation/entering-the-name-fo-the-domain.png"]
+image::installation/entering-the-name-fo-the-domain.png[Entering the name for the domain,link="../_images/installation/entering-the-name-fo-the-domain.png"]
 
 . Click the btn:[Create] button.
 +
-image::installation/completing-the-creation-of-the-zone.png[link="../_images/installation/completing-the-creation-of-the-zone.png"]
+image::installation/completing-the-creation-of-the-zone.png[Completing the creation of the zone,link="../_images/installation/completing-the-creation-of-the-zone.png"]
 +
 The created zone and the list of name servers (NS) are displayed in the *DNS Zones* section.
 +
-image::installation/list-of-created-zones-and-NS.png[link="../_images/installation/list-of-created-zones-and-NS.png"]
+image::installation/list-of-created-zones-and-NS.png[List of created zones and name servers,link="../_images/installation/list-of-created-zones-and-NS.png"]
 +
 These servers must be configured with the registrar of the domain.
 
@@ -43,8 +39,8 @@ These servers must be configured with the registrar of the domain.
 
 .. In the *IP Address* field, select the external IP of Ingress-nginx controller that the user had obtained in the xref:installing-ingress-on-kubernetes_{context}[] section (*40.89.129.194*, in this case).
 +
-image::installation/adding-a-record-set.png[link="../_images/installation/adding-a-record-set.png"]
+image::installation/adding-a-record-set.png[Adding a record set,link="../_images/installation/adding-a-record-set.png"]
 +
 The following is an example of an added DNS zone:
 +
-image::installation/example-of-an-added-dns-zone.png[link="../_images/installation/example-of-an-added-dns-zone.png"]
+image::installation/example-of-an-added-dns-zone.png[Example of an added DNS zone,link="../_images/installation/example-of-an-added-dns-zone.png"]

modules/installation-guide/partials/proc_configuring-labels-for-ingresses.adoc

@@ -1,8 +1,8 @@
 
 [id="configuring-labels-for-ingresses_{context}"]
-= Configuring labels for Kubernetes Ingress
+= Configuring labels for {orch-ingress}
 
-This procedure describes how to configure labels for Kubernetes Ingress to organize and categorize (scope and select) objects.
+This procedure describes how to configure labels for {orch-ingress} to organize and categorize (scope and select) objects.
 
 .Prerequisites
 
@@ -13,7 +13,7 @@ IMPORTANT: Use comma to separate labels: `key1=value1,key2=value2`
 
 .Procedure
 
-. To configure labels for Kubernetes Ingress update the Custom Resource with the following commands:
+. To configure labels for {orch-ingress}, update the Custom Resource with the following commands:
 +
 [subs="+quotes,+attributes"]
 ----

modules/installation-guide/partials/proc_configuring-namespace-strategies.adoc

@@ -192,7 +192,7 @@ To configure the labels, set the `CHE_INFRA_KUBERNETES_NAMESPACE_LABELS` to desi
 
 [WARNING]
 ====
-We do not recommend to create multiple namespaces for single user. It may lead to undefined behavior.
+Avoid creating multiple namespaces for single user. It may lead to undefined behavior.
 ====
 
 [IMPORTANT]

modules/installation-guide/partials/proc_configuring-storage-types.adoc

@@ -47,7 +47,7 @@ attributes:
 |===
 |Command
 |Ephemeral
-|Persitent
+|Persistent
 
 |Clone {prod}
 |0 m 19 s

modules/installation-guide/partials/proc_configuring-the-che-operator-checluster-resource-with-kubectl.adoc

@@ -2,12 +2,12 @@
 
 [id="configuring-the-che-operator-checluster-resource-with-kubectl_{context}"]
 
-= Configuring CheCluster Custom Resource with kubectl
-Edit the CheCluster custom resource configuration with kubectl:
+= Configuring CheCluster Custom Resource with {orch-cli}
+Edit the CheCluster custom resource configuration with {orch-cli}:
 
 [subs="+attributes"]
 ----
-kubectl edit CheCluster/eclipse-che -n {prod-namespace}
+{orch-cli} edit CheCluster/eclipse-che -n {prod-namespace}
 ----
 
 For more details on configuring CheCluster custom resource, see xref:installation-guide:configuring-the-che-installation.adoc[]

modules/installation-guide/partials/proc_creating-a-google-kubernetes-engine-instance.adoc

@@ -32,7 +32,7 @@ $ gcloud init
 $ gcloud projects create eclipse-che-1
 ----
 
-. Check from GCP webconsole that the {kubernetes} engine is available on this project.
+. Check from GCP Web Console that the {kubernetes} engine is available on this project.
 
 . Configure the different default options (such as using the `europe-west1-b` zone) in the shell:
 +

modules/installation-guide/partials/proc_deploying-che-with-support-for-git-repositories-with-self-signed-certificates.adoc

@@ -20,7 +20,7 @@ ifeval::["{project-context}" == "che"]
 In the instructions below, substitute `kubectl` for `oc` when running {prod-short} on {kubernetes}.
 endif::[]
 
-. Create a new *configMap* with details about the Git server:
+. Create a new *ConfigMap* with details about the Git server:
 +
 [subs="+quotes"]
 ----

modules/installation-guide/partials/proc_enabling-dev-workspace-engine.adoc

@@ -1,8 +1,8 @@
 
 [id="enabling-dev-workspace-engine_{context}"]
-= Enabling Dev Workspace engine
+= Enabling {devworkspace} engine
 
-This procedure describes how to enable the Dev Workspace engine to support the Devfile 2.0.0 file format and mentions how to do so on existing instances or those about to be installed.
+This procedure describes how to enable the {devworkspace} engine to support the Devfile 2.0.0 file format and mentions how to do so on existing instances or those about to be installed.
 
 .Prerequisites
 

modules/installation-guide/partials/proc_importing-untrusted-tls-certificates-old.adoc

@@ -3,15 +3,7 @@
 = Importing untrusted TLS certificates to {prod-short}
 
 ====
-NOTE: Starting from {prod-short} version
-ifeval::["{project-context}" == "che"]
-v7.23.0
-endif::[]
-ifeval::["{project-context}" != "che"]
-2.5.1
-endif::[]
-there is xref:importing-untrusted-tls-certificates.adoc[newer way] to apply additional TLS certificates.
-This method is kept for backward compatibility.
+NOTE: This obsolete method is kept for backward compatibility . See xref:importing-untrusted-tls-certificates.adoc[]
 ====
 
 Internal communications between {prod-short} components are, by default, encrypted with TLS. Communications of {prod-short} components with external services such as proxies, source code repositories, identity providers may require TLS tool. Those communications require the use of TLS certificates signed by trusted Certificate Authorities.

modules/installation-guide/partials/proc_installing-cert-manager-on-kubernetes.adoc

@@ -73,7 +73,7 @@ EOF
 
 . Check that the `issuerRef` name is the same as the `ClusterIssuer`. A new DNS challenge is added to the DNS zone for _Let’s Encrypt_.
 +
-image::installation/dns-challenge-gcp.png[link="../_images/installation/dns-challenge-gcp.png"]
+image::installation/dns-challenge-gcp.png[DNS challenge,link="../_images/installation/dns-challenge-gcp.png"]
 
 . The cert-manager logs contain information about the DNS challenge. To get the logs (here, `cert-manager-8d478bb45-2924h` is the name of the cert-manager Pod):
 +

modules/installation-guide/partials/proc_installing-che-on-kind-using-chectl.adoc

@@ -20,7 +20,7 @@ Following instruction is a way of configuring Kind cluster to have all needed fo
 
 . Install https://github.com/kubernetes-csi/csi-driver-host-path[csi-driver-host-path] in the kind cluster:
 +
-Install snapshotter CRDs as described in the https://github.com/kubernetes-csi/csi-driver-host-path/blob/master/docs/deploy-1.17-and-later.md#user-content-volumesnapshot-crds-and-snapshot-controller-installation[docs]:
+Install `snapshotter` CRDs as described in the https://github.com/kubernetes-csi/csi-driver-host-path/blob/master/docs/deploy-1.17-and-later.md#user-content-volumesnapshot-crds-and-snapshot-controller-installation[docs]:
 +
 [subs="+quotes"]
 ----
@@ -132,5 +132,5 @@ $ {prod-cli} server:deploy --installer operator --platform k8s --domain 172.17.2
 +
 [NOTE]
 ====
-In some cases, after all the steps above, it is still not possible to reach {prod-short} from the host machine. If you encounter such problem, refer to kind cluster documentation or forums on how to make an endpoint available outside the kind cluster for your system and network configuration.
+In some cases, after all the steps above, it is still not possible to reach {prod-short} from the host machine. If you encounter such problem, see `kind` cluster documentation or forums on how to make an endpoint available outside the kind cluster for your system and network configuration.
 ====

modules/installation-guide/partials/proc_installing-dns-on-google-cloud-platform.adoc

@@ -9,17 +9,17 @@
 
 . Using the Cloud DNS, create a zone called *eclipse-che* and, for example, a DNS name *gcp.my-ide.cloud*. Click the btn:[Create] button.
 +
-image::installation/creating-dns-zone-on-gcp.png[link="../_images/installation/creating-dns-zone-on-gcp.png"]
+image::installation/creating-dns-zone-on-gcp.png[Creating DNS zone on Google Cloud Platform,link="../_images/installation/creating-dns-zone-on-gcp.png"]
 +
 The Cloud DNS zone is created.
 +
-image::installation/cloud-dns-zone-on-gcp.png[link="../_images/installation/cloud-dns-zone-on-gcp.png"]
+image::installation/cloud-dns-zone-on-gcp.png[Cloud DNS zone on Google Cloud Platform,link="../_images/installation/cloud-dns-zone-on-gcp.png"]
 
 . Click the *Registrar Setup* link in the upper right corner of the window. The name servers (NS) to be added to the registrar are displayed.
 +
-image::installation/registrar-setup-gcp.png[link="../_images/installation/registrar-setup-gcp.png"]
+image::installation/registrar-setup-gcp.png[Registrar setup on Google Cloud Platform,link="../_images/installation/registrar-setup-gcp.png"]
 
 . Update the DNS zone (example: `ovh` domain).
 . Add the `*.gcp.my-ide.cloud` entry to the external Ingress IP on the cloud DNS.
 +
-image::installation/dns-settings-gcp.png[link="../_images/installation/dns-settings-gcp.png"]
+image::installation/dns-settings-gcp.png[DNS settings on Google Cloud Platform,link="../_images/installation/dns-settings-gcp.png"]