style: improve formatting

docs/components/connectors/custom-built-connectors/connector-templates.md

@@ -612,7 +612,7 @@ You can, for example, allow the user to model and configure the following **REST
 
 ## Develop Connector templates
 
-You can develop Connector templates using the [`element template` feature](/components/modeler/desktop-modeler/element-templates/defining-templates). You can also look at existing [examples](https://github.com/camunda/camunda-modeler/blob/master/resources/element-templates/cloud-samples.json).
+You can develop Connector templates using the [`element template` feature](/components/modeler/desktop-modeler/element-templates/defining-templates/index.md). You can also look at existing [examples](https://github.com/camunda/camunda-modeler/blob/master/resources/element-templates/cloud-samples.json).
 
 ## Providing and using Connector templates
 

docs/components/connectors/manage-connector-templates.md

@@ -27,7 +27,7 @@ Take the following steps to create a new Connector template:
  The components of the editor interface are as follows:
 
  - In the **breadcrumbs bar** at the top of the screen, you can rename your template by clicking the chevron next to the template name. Note that you cannot change the name of your template in the template JSON, but only with this action.
- - On the left, you see the **template JSON editor**. Here, you define the actual template descriptor. The descriptor follows the [most recent element template schema](https://github.com/camunda/element-templates-json-schema). The editor is divided into two sections: a read-only section, containing the schema reference, the template name, the template id, and an editable section, where you can [define your template descriptor](/components/modeler/desktop-modeler/element-templates/defining-templates/).
+ - On the left, you see the **template JSON editor**. Here, you define the actual template descriptor. The descriptor follows the [most recent element template schema](https://github.com/camunda/element-templates-json-schema). The editor is divided into two sections: a read-only section, containing the schema reference, the template name, the template id, and an editable section, where you can [define your template descriptor](/components/modeler/desktop-modeler/element-templates/defining-templates/index.md).
  - On the right, you see the live **Visual Preview**. The live preview shows how the properties panel will look when you apply the template to an element. It automatically updates on every valid change, and reflects the latest valid state of the template. The preview allows you to interactively check your template before publishing, enhancing its usability.
  - In the upper left, you can **Upload an icon** for your template. You can upload any image file you want, however we recommend to use squared SVG graphics. The icons get rendered 18x18 pixels in the element on the modeling canvas, and 32x32 pixels in the properties panel.
 

docs/components/modeler/desktop-modeler/element-templates/additional-resources.md

@@ -5,4 +5,4 @@ title: Additional resources
 
 Try playing around with custom elements and [our example templates](https://github.com/camunda/camunda-modeler/tree/master/resources/element-templates/cloud-samples.json).
 
-If you get stuck, ask for help [in our forums](https://forum.camunda.org/c/modeler).
+If you get stuck, ask for help in our [forums](https://forum.camunda.org/c/modeler).

docs/components/modeler/desktop-modeler/element-templates/configuring-templates.md

@@ -4,13 +4,13 @@ title: Configuring templates
 description: "Learn about global and local templates, which are loaded by the modeler at application startup."
 ---
 
-Templates will be loaded by the modeler at application startup. Reloading it using `CtrlOrCmd+R` will also reload all templates. Templates will be treated as global or local depending on their location in your file system.
+Templates are loaded by Desktop Modeler at application startup. Reloading it using `CtrlOrCmd+R` reloads also all templates. Templates are treated as global or local depending on their location in your file system.
 
-### Global templates
+## Global templates
 
 For templates to be available for all diagrams store them in the `resources/element-templates` directory containing the Camunda Modeler executable. Alternatively, for element templates to be available across Camunda Modeler installations, you can store them in the `resources/element-templates` directory in the modeler's [data directory](../../search-paths#user-data-directory).
 
-#### Example (Windows)
+### Example (Windows)
 
 ```
 └── camunda-modeler-5.10.0-win-x64
@@ -20,11 +20,11 @@ For templates to be available for all diagrams store them in the `resources/elem
  └── my-element-templates.json
 ```
 
-### Local templates
+## Local templates
 
 For element templates to only be available for specific diagrams, you can store them in a `.camunda/element-templates` directory in the diagrams parent directory or any of their parent directories.
 
-#### Example
+### Example
 
 ```
 ├── diagram.bpmn

docs/components/modeler/desktop-modeler/element-templates/defining-templates/index.md

@@ -32,38 +32,43 @@ Templates are defined in template descriptor files as a JSON array:
 ]
 ```
 
-As seen in the code snippet a template consists of a number of important components:
+As seen in the code snippet, a template consists of a number of important components:
 
-- `$schema : String`: URI pointing towards the [JSON schema](https://json-schema.org/) which defines the structure of the element template `.json` file. Element template schemas are maintained in the [element templates JSON schema](https://github.com/camunda/element-templates-json-schema) repository. Following the [JSON schema](https://json-schema.org/) standard, you may use them for validation or to get assistance (e.g., auto-completion) when working with them in your favorite IDE. Note that the `$schema` attribute is **required** for Camunda Platform 8 element templates.
+- `$schema : String`: URI pointing towards the [JSON schema](https://json-schema.org/) which defines the structure of the element template `.json` file. Element template schemas are maintained in the [element templates JSON schema](https://github.com/camunda/element-templates-json-schema) repository. Following the [JSON schema](https://json-schema.org/) standard, you may use them for validation or to get assistance (e.g., auto-completion) when working with them in your favorite IDE.
 
- Example:
+:::note
 
- ```json
- "$schema": "https://unpkg.com/@camunda/zeebe-element-templates-json-schema/resources/schema.json"
- ```
+The `$schema` attribute is **required** for Camunda Platform 8 element templates.
+:::
 
-- `name : String`: Name of the template. Will be shown in the element template selection modal and in the properties panel (after having applied an element template).
+Example:
+
+```json
+"$schema": "https://unpkg.com/@camunda/zeebe-element-templates-json-schema/resources/schema.json"
+```
+
+- `name : String`: Name of the template. Shown in the element template selection modal and in the properties panel (after applying an element template).
 - `id : String`: ID of the template.
-- `description : String`: Optional description of the template. Will be shown in the element template selection modal and in the properties panel (after having applied an element template).
-- `documentationRef : String`: Optional URL pointing to a template documentation. Will be shown in the properties panel (after having applied an element template).
-- `version : Integer`: Optional version of the template. If you add a version to a template it will be considered unique based on its ID and version. Two templates can have the same ID if their version is different.
+- `description : String`: Optional description of the template. Shown in the element template selection modal and in the properties panel (after applying an element template).
+- `documentationRef : String`: Optional URL pointing to a template documentation. Shown in the properties panel (after applying an element template).
+- `version : Integer`: Optional version of the template. If you add a version to a template, it is considered unique based on its ID and version. Two templates can have the same ID if their version is different.
 - `appliesTo : Array<String>`: List of BPMN types the template can be applied to.
-- `elementType : Object`: Optional type of the element. If you configure `elementType` on a template then the element will be replaced with the specified type when a user applies the template.
+- `elementType : Object`: Optional type of the element. If you configure `elementType` on a template, the element is replaced with the specified type when a user applies the template.
 - `properties : Array<Object>`: List of properties of the template.
 
 ## JSON schema compatibility
 
 The application uses the `$schema` property to ensure compatibility for a given element template. You find [the latest supported versions here](https://www.npmjs.com/package/@camunda/zeebe-element-templates-json-schema).
 
-The tooling will ignore element templates defining a higher `$schema` version and will log a warning message.
+The tooling ignores element templates defining a higher `$schema` version and logs a warning message.
 
-For example, given the following `$schema` definition, the application takes `0.9.1` as the JSON Schema version of the element template.
+For example, given the following `$schema` definition, the application takes `0.9.1` as the JSON schema version of the element template:
 
 ```json
 "$schema": "https://unpkg.com/@camunda/zeebe-element-templates-json-schema@0.9.1/resources/schema.json"
 ```
 
-The JSON Schema versioning is backward-compatible, meaning that all versions including or below the current one are supported.
+The JSON schema versioning is backward-compatible, meaning that all versions including or below the current one are supported.
 
 ## Supported BPMN types
 
@@ -76,7 +81,7 @@ Currently, element templates may be used on the following BPMN elements:
 
 ## Defining template properties
 
-With each template, you define some user-editable fields as well as their mapping to BPMN 2.0 XML as well as Camunda extension elements.
+With each template, you define some user-editable fields as well as their mapping to BPMN 2.0 XML, and Camunda extension elements.
 
 Let us consider the following example that defines a template for a mail sending task:
 
@@ -155,22 +160,22 @@ Let us consider the following example that defines a template for a mail sending
 
 The example defines five custom fields, each mapped to different technical properties:
 
-- The task type `http` is mapped to the `zeebe:taskDefinition:type` property in BPMN 2.0 XML
-- The `REST Endpoint URL` and `REST Method` are mapped to `task headers`
-- The `Request Body` is mapped to a local variable via an `input parameter`
-- The `Result Variable` is mapped into a process variable via an `output parameter`
+- The task type `http` is mapped to the `zeebe:taskDefinition:type` property in BPMN 2.0 XML.
+- The `REST Endpoint URL` and `REST Method` are mapped to `task headers`.
+- The `Request Body` is mapped to a local variable via an `input parameter`.
+- The `Result Variable` is mapped into a process variable via an `output parameter`.
 
 The task type is hidden to the user. Properties specified in the template can be edited through the properties panel as shown in the following screenshot:
 
 ![Custom Fields](../img/overview.png)
 
-As seen in the example the important attributes in a property definition are:
+As seen in the example, the important attributes in a property definition are:
 
-- `label`: A descriptive text shown with the property
-- `type`: Defining the visual appearance in the properties panel (may be any of `String`, `Text`, `Boolean`, `Dropdown` or `Hidden`)
-- `value`: An optional default value to be used if the property to be bound is not yet set
-- `binding`: Specifying how the property is mapped to BPMN or Camunda extensions (cf. [bindings](#bindings))
-- `constraints`: A list of editing constraints to apply to the template
+- `label`: A descriptive text shown with the property.
+- `type`: Defining the visual appearance in the properties panel (may be any of `String`, `Text`, `Boolean`, `Dropdown` or `Hidden`).
+- `value`: An optional default value to be used if the property to be bound is not yet set.
+- `binding`: Specifying how the property is mapped to BPMN or Camunda extensions (cf. [bindings](#bindings)).
+- `constraints`: A list of editing constraints to apply to the template.
 
 In addition, fields can be activated conditionally via these properties:
 
@@ -179,7 +184,7 @@ In addition, fields can be activated conditionally via these properties:
 
 ### Types
 
-The input types `String`, `Text`, `Boolean`, `Dropdown` and `Hidden` are available. As seen above `String` maps to a single-line input, `Text` maps to a multi-line input.
+The input types `String`, `Text`, `Boolean`, `Dropdown`, and `Hidden` are available. As seen above `String` maps to a single-line input, while `Text` maps to a multi-line input.
 
 #### Boolean / checkbox type
 
@@ -248,40 +253,40 @@ The property `feel` is supported on the following input types:
 
 ### Bindings
 
-The following ways exist to map a custom field to the underlying BPMN 2.0 XML. The _mapping result_ in the following section will use `[userInput]` to indicate where the input provided by the user in the `Properties Panel` is set in the BPMN XML. As default or if no user input was given, the value specified in `value` will be displayed and used for `[userInput]`. `[]` brackets will be used to indicate where the parameters are mapped to in the XML.
+The following ways exist to map a custom field to the underlying BPMN 2.0 XML. The **mapping result** in the following section uses `[userInput]` to indicate where the input provided by the user in the `Properties Panel` is set in the BPMN XML. As default or if no user input was given, the value specified in `value` is displayed and used for `[userInput]`. `[]` brackets are used to indicate where the parameters are mapped to in the XML.
 
 Notice that adherence to the following configuration options is enforced by design. If not adhering, it logs a validation error and ignores the respective element template.
 
 #### `property`
 
 | **Binding `type`** | `property` |
 | --------------------------- | -------------------------------- |
-| **Valid property `type`'s** | all property types are supported |
-| **Binding parameters** | `name`: the name of the property |
+| **Valid property `type`'s** | All property types are supported |
+| **Binding parameters** | `name`: The name of the property |
 | **Mapping result** | `<... [name]=[userInput] ... />` |
 
 #### `zeebe:input`
 
 | **Binding `type`** | `zeebe:input` |
 | --------------------------- | ----------------------------------------------------- |
 | **Valid property `type`'s** | `String`<br /> `Text`<br />`Hidden`<br />`Dropdown` |
-| **Binding parameters** | `name`: the name of the input parameter |
+| **Binding parameters** | `name`: The name of the input parameter |
 | **Mapping result** | `<zeebe:input target="[name]" source="[userInput] />` |
 
 #### `zeebe:output`
 
 | **Binding `type`** | `zeebe:output` |
 | --------------------------- | -------------------------------------------------------- |
 | **Valid property `type`'s** | `String`<br /> `Text`<br />`Hidden`<br />`Dropdown` |
-| **Binding parameters** | `source`: the source of the output parameter |
+| **Binding parameters** | `source`: The source of the output parameter |
 | **Mapping result** | `<zeebe:output target="[userInput]" source="[source] />` |
 
 #### `zeebe:taskHeader`
 
 | **Binding `type`** | `zeebe:taskHeader` |
 | --------------------------- | --------------------------------------------------- |
 | **Valid property `type`'s** | `String`<br /> `Text`<br />`Hidden`<br />`Dropdown` |
-| **Binding parameters** | `key`: the key of the task header |
+| **Binding parameters** | `key`: The key of the task header |
 | **Mapping result** | `<zeebe:header key="[key]" value="[userInput] />` |
 
 #### `zeebe:taskDefinition:type`
@@ -297,7 +302,7 @@ Notice that adherence to the following configuration options is enforced by desi
 | **Binding `type`** | `zeebe:property` |
 | --------------------------- | ----------------------------------------------------- |
 | **Valid property `type`'s** | `String`<br />`Text`<br />`Hidden`<br />`Dropdown` |
-| **Binding parameters** | `name`: the name of the property |
+| **Binding parameters** | `name`: The name of the property |
 | **Mapping result** | `<zeebe:property name="[name]" value="[userInput] />` |
 
 The `zeebe:property` binding allows you to set any arbitrary property for an outside system. It does not impact execution of the Zeebe engine.
@@ -405,7 +410,7 @@ Associate a field with a group (ID) via the fields `group` key:
 
 ### Constraints
 
-Custom Fields may have a number of constraints associated with them:
+Custom fields may have a number of constraints associated with them:
 
 - `notEmpty`: Input must be non-empty
 - `minLength`: Minimal length for the input

docs/components/modeler/desktop-modeler/element-templates/using-templates.md

@@ -6,7 +6,7 @@ description: "Learn how to apply, remove, update, and replace templates."
 
 ## Applying templates
 
-If a template matches a selected diagram element, the template catalog button will be shown in the properties panel.
+If a template matches a selected diagram element, the template catalog button is shown in the properties panel.
 
 ![Template Chooser](./img/chooser.png)
 
@@ -33,8 +33,8 @@ the user.
 
 To remove an applied template from an element, either the _Unlink_ or _Remove_ function can be used:
 
-- _Remove_: Remove the element template from the `modelerTemplate` property and reset all properties of the respective element.
-- _Unlink_: Remove the element template from the `modelerTemplate` property but keep the properties which were set.
+- **Remove**: Remove the element template from the `modelerTemplate` property and reset all properties of the respective element.
+- **Unlink**: Remove the element template from the `modelerTemplate` property but keep the properties which were set.
 
 ![Unlink or Remove](./img/unlink-remove.png)
 
@@ -46,22 +46,22 @@ If a template is applied and a new version of the template is found you can _upd
 
 Templates are updated according to the following rules:
 
-1. If the property is set in new template, it will override unless the property was set by the old template and changed afterwards.
-2. If the property is not defined in the new template, it will unset.
-3. Sub-properties of complex properties (e.g. `zeebe:input`, `zeebe:output`) are handled
-  according to these rules if they can be identified.
+- If the property is set in new template, it will override unless the property was set by the old template and changed afterwards.
+- If the property is not defined in the new template, it will unset.
+- Sub-properties of complex properties (e.g. `zeebe:input`, `zeebe:output`) are handled
+ according to these rules if they can be identified.
 
 ### Replacing templates
 
 If a template is deprecated with a new element template and you want to keep the same input values as in the
 deprecated template, you can:
 
-- _Unlink_: Remove the current template that is deprecated from the `modelerTemplate` property, but keep the properties
+- **Unlink**: Remove the current template that is deprecated from the `modelerTemplate` property, but keep the properties
  which
  were set.
-- _Select_ and apply the new element template.
+- **Select** and apply the new element template.
 
-### Missing templates
+## Missing templates
 
 If a template is applied to an element but the respective template cannot be found on the system, the editing of the
 element is disabled. _Unlinking_ or _removing_ the template for the element or adding the element template config