Apply suggestions from code review

Co-authored-by: Michael Latouche <michael@crossingpaths.be>

Author: Luuk1983

16/umbraco-cms/customizing/foundation/context-api/README.md

@@ -8,7 +8,7 @@ description: >-
 
 The Context API is a powerful communication system in Umbraco's backoffice. It enables extensions to share data and functionality through the component hierarchy without tight coupling. Think of it as a way for different parts of your UI to talk to each other and access shared services.
 
-Contexts are used throughout the Umbraco backoffice to provide access to workspace data, notifications, user information, and many other services. When building custom extensions, you'll often need to consume existing contexts or create your own to share functionality between your components.
+Contexts are used throughout the Umbraco backoffice to provide access to workspace data, notifications, user information, and many other services. When building custom extensions, you will often need to consume existing contexts or create your own to share functionality between your components.
 
 ## Key Concepts
 

16/umbraco-cms/customizing/foundation/context-api/consume-a-context.md

@@ -8,10 +8,10 @@ There are two ways to consume a context: get a __one-time reference__ to the con
 
 A one-time reference approach is suitable for fire-and-forget events. The key here is that the context is not needed on initialization, but is only needed when a specific criteria is met. For instance, events that occur after user interaction or when a specific function is called. In that case, you need to get a context, do something and forget about the context after that.
 
-If you need a context during initialization which is then set as a variable, you should always use a subscription. Otherwise you risk holding on to a context that could be disconnected or replaced without you knowing.
+If you need a context during initialization which is then set as a variable, you should always use a subscription. Otherwise, you risk holding on to a context that could be disconnected or replaced without you knowing.
 
 ## Consuming contexts in an element
-An [Umbraco Element](../umbraco-element/) is **any web component** that extends `UmbLitElement` or uses the `UmbElementMixin` to wrap its base class. Whether you're building with Lit, vanilla JavaScript, or any other web component framework, you can make it an Umbraco Element. This gives it full access to the Context API.
+An [Umbraco Element](../umbraco-element/) is **any web component** that extends `UmbLitElement` or uses the `UmbElementMixin` to wrap its base class. Whether you are building with Lit, vanilla JavaScript, or any other web component framework, you can make it an Umbraco Element. This gives it full access to the Context API.
 
 Umbraco Elements provide two methods for consuming contexts:
 
@@ -21,7 +21,7 @@ Umbraco Elements provide two methods for consuming contexts:
 Both methods accept a Context Token (or string alias) to identify which context to consume.
 
 ### Get as one-time reference
-The first example uses Lit and that is the way Umbraco builds their elements. If you don't want to use Lit, there is also an example using vanilla JavaScript. Both examples don't have any TypeScript specific code. You can use them in either a JavaScript or TypeScript file.
+The first example uses Lit and that is the way Umbraco builds their elements. If you do not want to use Lit, there is also an example using vanilla JavaScript. Both examples do not have any TypeScript specific code. You can use them in either a JavaScript or a TypeScript file.
 
 {% tabs %}
 {% tab title="Lit element" %}
@@ -125,14 +125,14 @@ customElements.define('example-element', ExampleElement);
 {% endtabs %}
 
 ### Get as a subscription
-When you're dealing with a subscription, it's good practice to consume the context in the constructor for the following reasons:
+When you are dealing with a subscription, it is good practice to consume the context in the constructor for the following reasons:
 
-* The constructor runs once when the element is created. This ensures your context subscription is set up before the element connects to the DOM. This guarantees you won't miss any context updates that occur during the element's initialization.
-* Context consumers created in the constructor are automatically connected when the element enters the DOM (`connectedCallback`). They are disconnected when it's removed (`disconnectedCallback`). You don't need to manually manage this lifecycle as Umbraco's controller system handles it for you.
-* By establishing context subscriptions in the constructor, your element's state is consistent from the moment it's created. This prevents race conditions where the element might render or perform actions before its required contexts are available.
+* The constructor runs once when the element is created. This ensures your context subscription is set up before the element connects to the DOM. This guarantees you will not miss any context updates that occur during the element's initialization.
+* Context consumers created in the constructor are automatically connected when the element enters the DOM (`connectedCallback`). They are disconnected when it is removed (`disconnectedCallback`). You do not need to manually manage this lifecycle as Umbraco's controller system handles it for you.
+* By establishing context subscriptions in the constructor, your element's state is consistent from the moment it is created. This prevents race conditions where the element might render or perform actions before its required contexts are available.
 * Creating context consumers in the constructor is more efficient than creating them in lifecycle methods that are called multiple times. For example, `connectedCallback` fires every time the element is added to the DOM.
 
-The first example uses Lit and that is the way Umbraco builds their elements. If you don't want to use Lit, there is also an HTML element example. Both examples don't have any TypeScript specific code. You can use them in either a JavaScript or TypeScript file.
+The first example uses Lit and that is the way Umbraco builds their elements. If you do not want to use Lit, there is also an HTML element example. Both examples do not have any TypeScript specific code. You can use them in either a JavaScript or a TypeScript file.
 
 {% tabs %}
 {% tab title="Lit element" %}
@@ -204,7 +204,7 @@ customElements.define('example-element', ExampleElement);
 {% endtabs %}
 
 ## Consuming contexts in non-UI elements
-Not all code that needs contexts lives in UI elements (web components). Services, managers, repositories, and helper classes often need access to contexts. These may include notifications, workspaces, or application state. However, they don't exist as elements in the DOM.
+Not all code that needs contexts lives in UI elements (web components). Services, managers, repositories, and helper classes often need access to contexts. These may include notifications, workspaces, or application state. However, they do not exist as elements in the DOM.
 
 For these non-UI classes, extend `UmbControllerBase` to gain the same context consumption capabilities as elements. This base class provides `getContext()` and `consumeContext()` methods. This allows any class with a controller host to access the Context API.
 
@@ -271,10 +271,10 @@ export class ExampleService extends UmbControllerBase {
 In rare cases, you may need complete manual control over context consumption. This means not extending `UmbControllerBase` or using element mixins. This is typically necessary when:
 
 - Integrating with third-party libraries or frameworks
-- Working with legacy code that can't be refactored
+- Working with legacy code that cannot be refactored
 - Building custom architectural patterns outside Umbraco's standard controller system
 
-For these scenarios, use `UmbContextConsumer` directly. This low-level API gives you full control but requires manual lifecycle management. You must call `hostConnected()`, `hostDisconnected()`, and `destroy()`.
+For these scenario's, use `UmbContextConsumer` directly. This low-level API gives you full control but requires manual lifecycle management. You must call `hostConnected()`, `hostDisconnected()`, and `destroy()`.
 
 {% hint style="warning" %}
 **Use this approach only when necessary.** The methods shown in previous sections handle lifecycle management automatically. These include `UmbLitElement`, `UmbElementMixin`, and `UmbControllerBase`. They are suitable for most use cases.

16/umbraco-cms/customizing/foundation/context-api/context-api-fundamentals.md

@@ -34,12 +34,12 @@ An object that encapsulates both data and methods to interact with that data. Th
 An element that creates and makes a context available to its descending elements. The provider is responsible for the context's lifecycle. One element can provide multiple different contexts if needed.
 
 ### Context consumer
-Any element that requests and consumes a context provided by one of its ancestor elements. An element becomes a consumer by requesting a context. The element doesn't need to know which specific ancestor provides the context or implement any special interfaces. The consuming element receives callbacks when the requested context becomes available or unavailable. This allows the element to react appropriately to changes in the element hierarchy.
+Any element that requests and consumes a context provided by one of its ancestor elements. An element becomes a consumer by requesting a context. The element does not need to know which specific ancestor provides the context nor implement any special interfaces. The consuming element receives callbacks when the requested context becomes available or unavailable. This allows the element to react appropriately to changes in the element hierarchy.
 
 ### Context Token
-A unique identifier used to request specific contexts. Context tokens serve as contracts between providers and consumers. They define exactly which context is being requested and ensure that the right provider responds. Using a context token prevents conflicts when multiple contexts might have similar names and makes clear what functionality is being shared.
+A unique identifier used to request a specific context. Context tokens serve as contracts between providers and consumers. They define exactly which context is being requested and ensure that the right provider responds. Using a context token prevents conflicts when multiple contexts might have similar names and makes clear what functionality is being shared.
 
-## Context consume flow
+## Context consuming flow
 Each DOM element can be a context provider. Each descendant in the DOM hierarchy can consume that context if desired. When an element wants to consume a context, the following happens:
 
 1. An element requests a context by a given Context Token.
@@ -53,7 +53,7 @@ If no context could be found and the event reaches the top-level element (the do
 ## Common contexts
 Although every element can be a context provider, the most important contexts are registered at specific hierarchy levels. These levels are also explicit extension points in the Umbraco manifest. 
 
-The hierarchy levels to which contexts can be registered are:
+The most common hierarchy levels to which the contexts can be registered are:
 
 * Global
 * Section
@@ -64,11 +64,11 @@ The hierarchy levels to which contexts can be registered are:
 * `Notification context`: used for displaying notifications in the backoffice. This context is consumable in elements anywhere in the DOM tree.
 * `Current user context`: has information about the currently logged in user. This context is consumable anywhere in the DOM tree.
 
-**Section contexts** are available in the context of a section. That's everything in the backoffice except the menubar. Examples of section contexts:
+**Section contexts** are available in the context of a section. That is everything in the backoffice except the menubar. Examples of section contexts:
 * `Section context`: provides information about the section, like path, alias, and label.
 * `Sidebar menu section context`: holds information about the sidebar menu, like which menu is currently selected.
 
-**Workspace contexts** work on a workspace; the part of Umbraco that's next to the tree. Example of this level:
+**Workspace contexts** work on a workspace, the part of Umbraco that is next to the tree. Example for this level:
 * `Workspace context`: holds information about the current entity being edited in the workspace. This holds minimal information about an entity and the entity type. There are specific workspace contexts per entity type. For instance, the `Document workspace context` for documents and `Media workspace context` for media.
 
 **Property contexts** are contexts that work at the property level. They can work on one or more property editors. An example is the clipboard functionality where blocks can be copied and pasted between block grids and block lists. Because these contexts are scoped at the property level, they are typically not consumed directly.