Merge pull request #108 from deining/fix-typos

Fixing typos
arc42 · Oct 22, 2023 · fdfc7ae · fdfc7ae
2 parents c791864 + 6ce7ef7
commit fdfc7ae
Show file tree

Hide file tree

Showing 15 changed files with 21 additions and 21 deletions.
diff --git a/_pages/contact.md b/_pages/contact.md
@@ -10,7 +10,7 @@ order: 25
 Please let us know - we're listening to you:
 
 
-* <a href="xmxaxixlxtxo:[email protected]" onmouseover="this.href=this.href.replace(/x/g,'');"><i class="fa fa-fw fa-envelope"></i>Email (our adress is spam-protected)</a>
+* <a href="xmxaxixlxtxo:[email protected]" onmouseover="this.href=this.href.replace(/x/g,'');"><i class="fa fa-fw fa-envelope"></i>Email (our address is spam-protected)</a>
 * on our [<i class="fab fa-fw fa-github"></i>github issue tracker](https://github.com/arc42/arc42-template/issues) at https://github.com/arc42/arc42-template/issues.
 * on various Twitter accounts:
   * [<i class="fab fa-fw fa-twitter"></i>@arc42Tipps](https://twitter.com/arc42Tipps)

diff --git a/_pages/home.md b/_pages/home.md
@@ -47,7 +47,7 @@ Check out  **[ practical tips](/keywords)** for using arc42, organized by templa
 >
 >* **[<font color="#dd354b">lean</font>](/keywords/#lean)**: You are looking for opportunities to shorten or  streamline your documentation pragmatically. You want to reduce efforts without loosing content or value. You are working in an agile environment and want to have lightweight documentation – based on the motto: _travel light_.
 >* **[<font color="#dd354b">thorough</font>](/keywords/#thorough)**: You are working in a more formal environment, e.g. developing very large or critical systems with hard quality requirements. Your stakeholders require thoroughness, accuracy and attention to detail. Maybe your systems and their documentation have to be audited.
->* **[<font color="#dd354b">essential</font>](/keywords/#essential)**: Despite lean and agile, there are some informations about your system that you should always document; i.e. quality goals of your architecture.
+>* **[<font color="#dd354b">essential</font>](/keywords/#essential)**: Despite lean and agile, there is some information about your system that you should always document; i.e. quality goals of your architecture.
 
 ## <font color="#dd354b">Still have questions?</font>
 

diff --git a/_pages/section-1.md b/_pages/section-1.md
@@ -36,7 +36,7 @@ Keep these excerpts as short as possible.
 Balance readability of this document with potential redundancy w.r.t to requirements documents. 
 <br>
 
-<!-- collect all examples that are releated to this section of arc42 -->
+<!-- collect all examples that are related to this section of arc42 -->
 {% include example.md category="overview" %}
 
 </div>
@@ -64,7 +64,7 @@ A table with the most important quality goals and concrete scenarios, ordered by
 
 See [section 10 (Quality Requirements)](/section-10/) for a complete overview of quality scenarios.
 
-<!-- collect all examples that are releated to this section of arc42 -->
+<!-- collect all examples that are related to this section of arc42 -->
 {% include example.md category="quality" %}
 
 </div>

diff --git a/_pages/section-10.md b/_pages/section-10.md
@@ -21,7 +21,7 @@ Since quality requirements will have a lot of influence on architectural
 decisions you should know for every stakeholder what is really important to them,
 concrete and measurable.
 
-<!-- collect all examples that are releated to this section of arc42 -->
+<!-- collect all examples that are related to this section of arc42 -->
 {% include example.md category="quality" %}
 
 </div>

diff --git a/_pages/section-11.md b/_pages/section-11.md
@@ -20,7 +20,7 @@ This should be your motto for systematic detection and evaluation of risks and t
 ### Form
 List of risks and/or technical debts, probably including suggested measures to minimize, mitigate or avoid risks or reduce technical debts.
 
-<!-- collect all examples that are releated to this section of arc42 -->
+<!-- collect all examples that are related to this section of arc42 -->
 {% include example.md category="risks" %}
 
 </div>

diff --git a/_pages/section-12.md b/_pages/section-12.md
@@ -29,7 +29,7 @@ You should clearly define your terms, so that all stakeholders
 | &lt;Term-1>    | &lt;definition-1> |
 | &lt;Term-2>    | &lt;definition-2> |
 
-<!-- collect all examples that are releated to this section of arc42 -->
+<!-- collect all examples that are related to this section of arc42 -->
 {% include example.md category="glossary" %}
 
 </div>

diff --git a/_pages/section-2.md b/_pages/section-2.md
@@ -22,7 +22,7 @@ Constraints must always be dealt with; they may be negotiable, though.
 ### Form
 Simple tables of constraints with explanations. If needed you can subdivide them into technical constraints, organizational and political constraints and conventions (e.g. programming or versioning guidelines, documentation or naming conventions)
 
-<!-- collect all examples that are releated to this section of arc42 -->
+<!-- collect all examples that are related to this section of arc42 -->
 {% include example.md category="constraints" %}
 
 </div>

diff --git a/_pages/section-3.md b/_pages/section-3.md
@@ -44,7 +44,7 @@ All kinds of diagrams that show the system as a black box and specify the domain
 
 Alternatively (or additionally) you can use a table. The title of the table is the name of your system, the three columns contain the name of the communication partner, the inputs, and the outputs.
 
-<!-- collect all examples that are releated to this section of arc42 -->
+<!-- collect all examples that are related to this section of arc42 -->
 {% include example.md category="business-context" %}
 
 </div>
@@ -68,7 +68,7 @@ Many stakeholders make architectural decision based on the technical interfaces
 #### Form
 E.g. UML deployment diagram describing channels to neighboring systems, together with a mapping table showing the relationships between channels and input/output.
 
-<!-- collect all examples that are releated to this section of arc42 -->
+<!-- collect all examples that are related to this section of arc42 -->
 {% include example.md category="technical-context" %}
 
 

diff --git a/_pages/section-4.md b/_pages/section-4.md
@@ -35,7 +35,7 @@ You might use a list of solution-approaches or a table similar to the following:
 | _&lt;Q-goal 1>_ | _&lt;Text>_ | _&lt;Text>_ |_&lt;Link>_ |
 | _&lt;Q-goal 2>_ | _&lt;Text>_ | _&lt;Text>_ |_&lt;Link>_ |
 
-<!-- collect all examples that are releated to this section of arc42 -->
+<!-- collect all examples that are related to this section of arc42 -->
 {% include example.md category="solutionstrategy" %}
 
 </div>

diff --git a/_pages/section-5.md b/_pages/section-5.md
@@ -32,7 +32,7 @@ The building block view is a hierarchial collection of black boxes and white box
 Thus it contains the white box description of selected building blocks of level 1, together with black box descriptions of their internal building blocks.
 * **Level 3** (not shown in the diagram above) zooms into details of selected building blocks of level 2, and so on.
 
-<!-- collect all examples that are releated to this section of arc42 -->
+<!-- collect all examples that are related to this section of arc42 -->
 {% include example.md category="building-block" %}
 
 </div>
@@ -79,7 +79,7 @@ boxes with name and  responsibility according to the following schema:
 | _&lt;black box 1>_ | _&lt;Text>_ |
 | _&lt;black box 2>_ | _&lt;Text>_ |
 
-If you use a list of black box decriptions then you fill in a separate black box template for every important building block .
+If you use a list of black box descriptions then you fill in a separate black box template for every important building block .
 Its headline is the name of the black box.
 
 </div>
@@ -139,7 +139,7 @@ _&lt;black box template>_
 <div class="arc42-help" markdown="1">
 Here you can specify the inner structure of (some) building blocks from level 1 as white boxes.
 
-You have to decide which building blocks of your system are important enough to justify such a detailed description. Please prefer relevance over completeness. Specify important, surprising, risky, compelx or volatile building blocks. Leave out normal, simple, boring or standardized parts of your system
+You have to decide which building blocks of your system are important enough to justify such a detailed description. Please prefer relevance over completeness. Specify important, surprising, risky, complex or volatile building blocks. Leave out normal, simple, boring or standardized parts of your system
 
 </div>
 

diff --git a/_pages/section-6.md b/_pages/section-6.md
@@ -34,7 +34,7 @@ There are many notations for describing scenarios, e.g.
 * state machines
 * ...
 
-<!-- collect all examples that are releated to this section of arc42 -->
+<!-- collect all examples that are related to this section of arc42 -->
 {% include example.md category="runtime" %}
 
 </div>

diff --git a/_pages/section-7.md b/_pages/section-7.md
@@ -43,7 +43,7 @@ nested diagrams, when your infrastructure is more complex.
 * When your (hardware) stakeholders prefer other kinds of diagrams rather than UML
 deployment diagram, let them use any kind that is able to show nodes and channels of the infrastructure.
 
-<!-- collect all examples that are releated to this section of arc42 -->
+<!-- collect all examples that are related to this section of arc42 -->
 {% include example.md category="deployment" %}
 
 </div>

diff --git a/_pages/section-8.md b/_pages/section-8.md
@@ -15,7 +15,7 @@ This section describes overall, principal regulations and solution ideas that ar
 Such concepts are often related to multiple building blocks. They include many different topics, such as
 
 * domain models
-* architectur patterns or design patterns
+* architectural patterns or design patterns
 * rules for using specific technology
 * principale, often technical decisions of overall decisions
 * implementation rules
@@ -60,7 +60,7 @@ In the diagram below, logging concerns all three components, whereas security is
 
 Some real-life examples:
 
-* Within a system, a common format for log-messages shall be established, combined with a common convention of chosing the appropriate log-destination.
+* Within a system, a common format for log-messages shall be established, combined with a common convention of choosing the appropriate log-destination.
 These decisions, along with implementation examples, could be described as "logging-concept".
 * A system has numerous backend services, that communicate among each other based upon remote procedure calls or http-based REST.
 Calling services ("consumers") always need to authenticate themselves to the called service ("provider").
@@ -71,7 +71,7 @@ All (7+) checker components within the system are structured according to the st
 
 
 
-<!-- collect all examples that are releated to this section of arc42 -->
+<!-- collect all examples that are related to this section of arc42 -->
 <!-- ================================================================-->
 {% include example.md category="concepts" %}
 

diff --git a/_pages/section-9.md b/_pages/section-9.md
@@ -49,7 +49,7 @@ You might follow the Nygard-structure, which works as follows:
 
 You can find additional structures of ADR in the [ADR Github collection](https://adr.github.io/)
 
-<!-- collect all examples that are releated to this section of arc42 -->
+<!-- collect all examples that are related to this section of arc42 -->
 {% include example.md category="decisions" %}
 
 </div>

diff --git a/_posts/05-buildingblocks/2016-03-02-t-5-16.md b/_posts/05-buildingblocks/2016-03-02-t-5-16.md
@@ -23,6 +23,6 @@ cohesive building blocks (i.e. you implement parts of the building block
 * If some of your frameworks/libraries or even used-products enforce
 _other_ structuring of code... then you should comply to the suggestions
 of your tools ("don't fight the platform"), but nevertheless create
-meaningful architectur building blocks.
+meaningful architectural building blocks.
 * If the stuff located in the package/namespace/module is not cohesive
 (see [tip 5-17 (cohesion is king)](/tips/5-17))