docs: documentation review adjustments

Co-authored-by: Marcus Schmidt <MarSchmidt@intershop.com>

docs/concepts/authentication.md

@@ -20,7 +20,7 @@ The following identity providers are supported: The default [ICM server](../guid
 There is a lot of functionality related to authentication, e.g., logging a user in and out, registering a new user, keeping the user identified even if the user opens further browser tabs, etc.
 
 The PWA uses the library [angular-oauth2-oidc](https://github.com/manfredsteyer/angular-oauth2-oidc#readme) to support the implementation of these functionalities.
-It is used to fetching data from the the [icm token endpoint service](../../src/app/core/services/token/token.service.ts) and can be configured to provide access to other identity providers.
+It is used to fetch data from the [icm token endpoint service](../../src/app/core/services/token/token.service.ts) and can be configured to provide access to other identity providers.
 
 ## Implementation and Configuration of Identity Providers
 
@@ -55,8 +55,8 @@ To add or change the functionality of an identity provider, the following steps
    ```
 
    > [!NOTE]
-   > If a identity provider is using the OAuthService for authentication, then the identity provider have to inject the OAuthService with a new instance.
-   > Otherwise difficult side effects with the [TokenService](../../src/app/core/services/token/token.service.ts) will occur.
+   > If an identity provider is using the OAuthService for authentication, the identity provider have to inject the OAuthService with a new instance.
+   > Otherwise, difficult side effects with the [TokenService](../../src/app/core/services/token/token.service.ts) will occur.
    > Please checkout the [Auth0IdentityProvider](../../src/app/core/identity-provider/auth0.identity-provider.ts) for an example.
 
 2. Register the `<idp>.identity-provider.ts` in the [`IdentityProviderModule`](../../src/app/core/identity-provider.module.ts). The `APP_INITIALIZER` injection token is used to configure and initialize the identity provider before app initialization.
@@ -66,15 +66,15 @@ To add or change the functionality of an identity provider, the following steps
 ## PWA Initialization
 
 A PWA user has to be identified by the ICM server by a unique authentication token, even if it is an anonymous user.
-Once a unknown user create a basket in the PWA, an anonymous authentication token is requested by the [ICM Token REST endpoint](https://support.intershop.com/kb/index.php?c=Display&q1=U29770&q2=Text).
+Once an unknown user creates a basket in the PWA, an anonymous authentication token is requested by the [ICM Token REST endpoint](https://support.intershop.com/kb/index.php?c=Display&q1=U29770&q2=Text).
 This happens in the [`apiToken http interceptor`](../../src/app/core/utils/api-token/api-token.service.ts) method.
 Subsequently, this token will be saved as `apiToken` cookie and added to all REST requests in the request header, e.g.:
 
 ```typescript
 authentication-token: encryption0@PBEWithMD5AndTripleDES:1D7T8HyFqQ0=|k3PQLgujzUq0tudtw+6HLjWnExiwrd4o9/jVU7ZH74kTfTy3RS7/sYadsg7ODRM2
 ```
 
-This way it is possible to identify users even they are opening a new browser tab or refreshing the PWA in the browser.
+In this way, it is possible to identify users even if they are opening a new browser tab or refreshing the PWA in the browser.
 
 If a user opens the PWA and already has a valid apiToken cookie, no new token is requested by the ICM server but this token is used in the header of the REST requests.
 
@@ -89,7 +89,7 @@ The PWA needs to react in case the `apiToken` cookie is not available anymore.
 This could happen if a PWA is opened in many tabs and the user logs out, or when users remove the cookie themselves.
 When the cookie vanishes, the PWA emits a new value for the [`cookieVanishes$` subject](../../src/app/core/utils/api-token/api-token.service.ts).
 The identity provider implementation defines how the application should behave in such a case.
-With the ICM identity provider, for example, the user is then automatically logged out and routed to the `/login` page.
+With the ICM identity provider, for example, the user is automatically logged out and routed to the `/login` page in that case.
 
 ## Further References
 

docs/concepts/hybrid-approach.md

@@ -9,31 +9,27 @@ kb_sync_latest_only
 
 This document describes how to run PWA and ICM using the Hybrid Approach, so that pages from the Intershop Progressive Web App and pages from the classic storefront (Responsive Starter Store) can be run in parallel.
 
-A possible scenario would be to have the shopping experience with all its SEO optimizations handled by the PWA and to delegate highly customized parts of the checkout or my account area to the ICM.
+A possible scenario would be to have the shopping experience with all its SEO optimizations handled by the PWA and to delegate highly customized parts of the checkout or My Account area to the ICM.
 
 ## Requirements
 
-The best way to deploy a Hybrid Approach installation is using the [PWA Helm chart](https://github.com/intershop/helm-charts/tree/main/charts/pwa) (0.4.0 and above with ICM 11) provided by Intershop.
+The best way to deploy a Hybrid Approach installation with a shared domain is using the [PWA Helm chart](https://github.com/intershop/helm-charts/tree/main/charts/pwa) (0.4.0 and above with ICM 11) provided by Intershop.
 For information on configuration of the PWA Helm chart for PWA and ICM, refer to the according [Hybrid Approach](https://github.com/intershop/helm-charts/tree/main/charts/pwa#hybrid-approach) paragraph.
 
-The version requirements for the involved systems are the following:
+The minimum version requirements for the involved systems are the following:
 
-- Intershop 11
 - PWA 3.2.0
+- ICM 7.10.38.6-LTS
 
-The functional requirements for the Hybrid Approach to work are already available starting with the following versions of ICM and PWA.
-However, this way they cannot be deployed together with a combined Helm chart.
-
-- ICM 7.10.32.16-LTS or 7.10.38.6-LTS
-- PWA 2.3.0
+However, to deployed both together with a combined Helm chart ICM 11 is required.
 
 > [!NOTE]
 > This feature relies on the PWA and ICM being able to read and write each other's `apiToken` cookies.
 >
 > This means that cookies written by the PWA and ICM must have the same domain and the same path. This works since all Responsive Starter Store requests and responses are proxied through the PWA SSR, simulating a common domain (an actual common domain for PWA and ICM is not required).
 >
 > It is also important that the cookie must not be set to [`HttpOnly`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#restrict_access_to_cookies).
-> Instead the `apiToken` cookie should be set with `Secure` and `SameSite=Strict`.
+> Instead, the `apiToken` cookie should be set with `Secure` and `SameSite=Strict`.
 
 The secure access required for the PWA/NGINX deployments in production-like environments is handled by the Ingress controller, so the PWA and the NGINX container itself can be deployed without SSL.
 ICM only needs to be deployed with secure access anyway.
@@ -42,7 +38,7 @@ ICM only needs to be deployed with secure access anyway.
 
 ![Hybrid Approach Architecture](hybrid-approach-architecture.svg)
 
-For a minimal-invasive implementation, the mechanics for the Hybrid Approach are mainly implemented outside of the ICM and in deployment-specific components of the PWA.
+For a minimally invasive implementation, the mechanics for the Hybrid Approach are mainly implemented outside of ICM and in deployment-specific components of the PWA.
 
 The ICM is proxied in the _express.js_ server of the server-side rendering (SSR) process and hereby made available to the outside.
 A newly introduced mapping table is used in the SSR to decide whether an incoming request should be handled by the PWA or the ICM.
@@ -54,7 +50,7 @@ This mapping table is also used in the browser-side PWA to switch from the singl
 
 The ICM must be run with [Secure URL-only Server Configuration](https://docs.intershop.com/icm/7.10/olh/oma/en/topics/managing_site_settings/topic_secure_url-only_server_configuration.html), which can be done by adding `SecureAccessOnly=true` to the appserver configuration.
 
-Furthermore the synchronization of the `apiToken` cookie must be switched on, so that users and baskets are synchronized between PWA and ICM.
+Furthermore, the synchronization of the `apiToken` cookie must be switched on, so that users and baskets are synchronized between PWA and ICM.
 See [Concept - Integration of Progressive Web App and inSPIRED Storefront](https://support.intershop.com/kb/index.php/Display/2928F6).
 
 If you also want to support the correct handling for links generated in e-mails, the property `intershop.WebServerSecureURL` must point to NGINX.
@@ -84,9 +80,9 @@ The server-side rendering process must be started with `SSR_HYBRID=1`.
 >
 > **Only for development environments**
 >
-> The PWA must also be run with secure URLs if NGINX to handle `https` access to the PWA is not deployed.
+> The PWA must also be run with secure URLs if no NGINX is deployed to handle `https` access to the PWA.
 >
-> See [SSR Startup - Development](../guides/ssr-startup.md#development) for a reference on how you to achieve this locally.
+> See [SSR Startup - Development](../guides/ssr-startup.md#development) for a reference on how to achieve this locally.
 
 > [!WARNING]
 >
@@ -136,13 +132,13 @@ For this reason, the PWA must be configured to know which application to use to
 - Follow the Hybrid configuration setup
 
 > [!NOTE]
-> If for some reason the CMS content of the Responsive Starter Store is to be reused directly in the PWA in a Hybrid Approach, the PWA needs some code adaptions and has to use the same application as the Responsive Starter Store. For more details see the older version of this documentation - [Hybrid Approach - PWA Adaptions (3.0.0)](https://github.com/intershop/intershop-pwa/blob/3.0.0/docs/concepts/hybrid-approach.md#pwa-adaptions).
+> If for some reason the CMS content of the Responsive Starter Store is to be reused directly in the PWA in a Hybrid Approach, the PWA needs some code adaptions and has to use the same application as the Responsive Starter Store. For more details, see the older version of this documentation - [Hybrid Approach - PWA Adaptions (3.0.0)](https://github.com/intershop/intershop-pwa/blob/3.0.0/docs/concepts/hybrid-approach.md#pwa-adaptions).
 
 ## Development Environment
 
 This section describes how to develop and test a PWA using the Hybrid Approach in a local development environment.
 
-This development environment includes a local installation of ICM with the Responsive Starter Store, the PWA and the NGINX.
+This development environment includes a local installation of ICM with the Responsive Starter Store, the PWA, and the NGINX.
 In addition, it meets the requirements for a common domain and for `https` access.
 
 After successful configuration and deployment, you can access the different systems with these URLs:
@@ -245,7 +241,7 @@ The configurations relevant to the Hybrid Approach for running the NGINX are:
 - `UPSTREAM_PWA` points to the PWA SSR process - `http://hybrid.local:7200`
 - For secure access, set `SSL=true` (available since PWA 3.1.0)
 - To avoid unexpected caching side effects, set `CACHE=false`
-- Set NGINX to respond on the default https port `443`
+- Set NGINX to respond to the default https port `443`
 
 To start the NGINX container from the project sources with Docker:
 
@@ -255,7 +251,7 @@ docker build -t dev_nginx nginx && docker run -it -p 443:443 -e UPSTREAM_PWA=htt
 
 > [!NOTE]
 > The NGINX of PWA releases prior to 3.1.0 does not support the `SSL=true` configuration.
-> Previous versions needed the `UPSTREAM_PWA` to be configured with `https` and the the files `server.key` and `server.crt` had to be supplied in the container folder `/etx/nginx` to start the NGINX with SSL.
+> Previous versions needed the `UPSTREAM_PWA` to be configured with `https` and the files `server.key` and `server.crt` had to be supplied in the container folder `/etx/nginx` to start the NGINX with SSL.
 
 ```bash
 docker build -t dev_nginx nginx && docker run -it -p 443:443 -e UPSTREAM_PWA=https://hybrid.local:7200 -e CACHE=false -v <full-path-to>/server.crt:/etc/nginx/server.crt -v <full-path-to>/server.key:/etc/nginx/server.key --name hybrid-nginx dev_nginx

docs/concepts/search-engine-optimization.md

@@ -26,7 +26,7 @@ Official documentation for Angular Universal can be found at [https://angular.io
 
 We use the library [express-robots-txt](https://github.com/modosc/express-robots-txt) in the express.js server (`server.ts` in the project root) to supply a response to `robots.txt` for crawlers.
 
-By default the universal server provides a response with access to all pages except some restricted paths (e.g. `/error` or `/account`).
+By default, the universal server provides a response with access to all pages except some restricted paths (e.g. `/error` or `/account`).
 To use a custom `robots.txt`, place it as a file in the `dist` folder.
 
 ## Page Metadata
@@ -54,10 +54,12 @@ Parameters are appended to theses paths that contain localization-independent an
 | product      | complete category path with product name | **-prd**: product sku, </br>**-ctg**: category id | /computers/notebooks-and-pcs/notebook-accessories/kensington-keyfolio-prd5981602-ctgComputers.1835.1284 |
 | content page | complete content page path               | **-pg**: content page id                          | /help/faq/seo/how-to-pghow-to-seo                                                                       |
 
-**_NOTE:_** The given parameters for each url are needed to differentiate category, product, and content page routes.
-It is important to ensure that no identifier contains the specified parameter id.
-For example, a category name including a `-ctg` substring could lead to unwanted behavior.
+> [!NOTE]
+> The given parameters for each url are needed to differentiate category, product, and content page routes.
+> It is important to ensure that no identifier contains the specified parameter id.
+> For example, a category name including a `-ctg` substring could lead to unwanted behavior.
 
-**_NOTE:_** Route generation and parsing for category, product, and content-page routes can be customized.
-This will require changes to the well documented [`product.route.ts`](../../src/app/core/routing/product/product.route.ts), [`category.route.ts`](../../src/app/core/routing/category/category.route.ts), or [`content-page.route.ts`](../../src/app/core/routing/content-page/content-page.route.ts) files.
-Additionally, the corresponding pipes (e.g., [`product-route.pipe.ts`](../../src/app/core/routing/product/product-route.pipe.ts)) may have to be updated to fit your needs as will [`routing.ts`](../../src/app/core/utils/routing.ts).
+> [!NOTE]
+> Route generation and parsing for category, product, and content-page routes can be customized.
+> This will require changes to the well documented [`product.route.ts`](../../src/app/core/routing/product/product.route.ts), [`category.route.ts`](../../src/app/core/routing/category/category.route.ts), or [`content-page.route.ts`](../../src/app/core/routing/content-page/content-page.route.ts) files.
+> Additionally, the corresponding pipes (e.g., [`product-route.pipe.ts`](../../src/app/core/routing/product/product-route.pipe.ts)) may have to be updated to fit your needs, as will [`routing.ts`](../../src/app/core/utils/routing.ts).

docs/guides/angular-change-detection.md

@@ -7,12 +7,12 @@ kb_sync_latest_only
 
 # Angular Change Detection
 
-Change detection is on of the core concepts of Angular.
+Change detection is one of the core concepts of Angular.
 Component templates contain data bindings that embed data from the component class into the view.
 The change detection cycle keeps view and data in sync.
 To do so, Angular re-evaluates all data expressions from the templates every time the CD runs.
 If the newly returned value differs from the current value, the corresponding DOM element will be updated in the view.
-This way, the template stays synchronized with the underlying data.
+In this way, the template stays synchronized with the underlying data.
 
 ## Zones
 
@@ -21,19 +21,19 @@ Data changes are most likely invoked by async events (timeout/interval or XHR) o
 Running CD whenever such an event occurs is – in most cases – enough for establishing a solid view update mechanism.
 
 To access those events, Angular uses the concept of zones.
-In short words, a zone is an asynchronous execution context that keeps track of all events happening and reports their status to our program.
+In short, a zone is an asynchronous execution context that keeps track of all events happening and reports their status to our program.
 See also: [Using Zones in Angular for better performance](https://blog.thoughtram.io/angular/2017/02/21/using-zones-in-angular-for-better-performance.html)
 
-Zones wrap asynchronous browser APIs, and notify a consumer when an asynchronous task has started or ended.
+Zones wrap asynchronous browser APIs and notify a consumer when an asynchronous task has started or ended.
 Angular takes advantage of these APIs to get notified when any asynchronous task is done.
-This includes things like XHR calls, `setTimeout()` and pretty much all user events like `click`, `submit`, `mousedown`, … etc.
+This includes things like XHR calls, `setTimeout()` and basically all user events like `click`, `submit`, `mousedown`, etc.
 
-When async events happen in the application, the zone informs Angular which then triggers change detection.
+When async events happen in the application, the zone informs Angular, which then triggers change detection.
 
 ## Zone Stability
 
-The zone tracks all ongoing async events and does also know whether there are pending tasks in the queue.
-If so (e.g., a running timer or XHR) it is likely that some change will happen in near future.
+The zone tracks all ongoing async events and also knows whether there are pending tasks in the queue.
+If so (e.g., a running timer or XHR), it is likely that some change will happen in the near future.
 This makes the zone **unstable**.
 Once all async tasks have been finished, the zone enters the **stable** status.
 
@@ -63,21 +63,21 @@ export class MyComponent {
 ## Using Zone Stability
 
 Getting to know whether a zone is stable or not is crucial when programmatically accessing the application from the "outside".
-Having a stable zone means that Angular has finished rendering and that we do not expect any async tasks to finish in near future.
+Having a stable zone means that Angular has finished rendering and that we do not expect any async tasks to finish in the near future.
 The Intershop PWA effectively uses this concept for communication with the CMS Design View.
 Also, Angular waits for stability in Service Workers and in Universal Rendering (Server-Side Rendering).
 
 ### Service Workers and Universal
 
 Both `@angular/service-worker` and `@angular/platform-server` use zone stability information internally.
-The Service Worker will not be attached to the page before the zone has become stable.
+The Service Worker will not be attached to the page before the zone will have become stable.
 The same applies for server-side rendering: The page will be rendered as soon as the zone is stable.
 This is necessary because data from HTTP requests must be resolved to render meaningful content.
 
 ### Pitfall: The Zone Must Become Stable
 
-For all of those aspects – Design View, Service Workers and Universal rendering – it is essential to get a stable zone at some point.
-If not, those aspects will not work properly, e.g.
+For all of those aspects – Design View, Service Workers, and Universal rendering – it is essential to get a stable zone at some point.
+If not, those aspects will not work properly, e.g.,
 Universal rendering will never return the rendered HTML and the Design View will never render the component tree view.
 
 > [!NOTE]