Fix glossary and typos (#90)

fixed the review comments from Pekka and fixed multiple typos or grammar
issues.

This PR polishes the RFCP website content by correcting typos/grammar
and refining glossary terminology so the syllabus pages and glossary
tooltips read more consistently across the site.

**Changes:**
- Updated `glossary.json` definitions and added/adjusted several
glossary entries (e.g., dictionary/list variable syntax, IF statement,
suite directory).
- Corrected typos and grammar across multiple syllabus chapters,
overview pages, and the example exam page.
- Aligned repeated learning objective phrasing across docs, `README.md`,
and `LOs.csv`.

---------

Signed-off-by: René <snooz@posteo.de>
Co-authored-by: Gerwin <8427040+GerwinLaagland@users.noreply.github.com>

Author: Snooz82

LOs.csv

@@ -74,7 +74,7 @@ LO-3.2.4,(K2),Understand how to create variables using the VAR statement,,,
 LO-3.2.5,(K2),Understand how `local` and `suite` scope variables are created,,,
 LO-3.3.2,(K1),Recall the rules how keyword names are matched.,,,
 LO-3.3.3,(K1),Recall all available settings and their purpose for User Keywords,,,
-LO-3.3.4,(K1),Recall the significance of the first logical line and in keyword documentation for the log file.,,,
+LO-3.3.4,(K1),Recall the significance of the first logical line in keyword documentation for the log file.,,,
 LO-3.3.5,(K2),Understand the purpose and syntax of the [Arguments] setting in User Keywords.,,,
 LO-3.3.5.1-1,(K1),Recall what makes an argument mandatory in a user keyword.,,,
 LO-3.3.5.1-2,(K3),Define User Keywords with mandatory arguments.,,,
@@ -108,7 +108,7 @@ LO-4.2.1-2,(K2),Understand when Suite Teardown is executed and used,,,
 LO-4.2.2-1,(K1),"Recall key characteristics, benefits, and syntax of Test|Task Teardown",,,
 LO-4.2.2-2,(K2),Understand when Test|Task Teardown is executed and used,,,
 LO-4.2.3,(K1),"Recall key characteristics, benefits, and syntax of Keyword Teardown",,,
-LO-4.3,(K1),Recall how to define Initialization Files and its purpose,,,
+LO-4.3,(K1),Recall how to define Initialization Files and their purpose,,,
 LO-4.3.2,(K2),Understand the execution order of Suite Setup and Suite Teardown in Initialization Files and their sub-suites and tests|tasks,,,
 LO-4.3.3,(K1),Recall the allowed sections and their content in Initialization Files,,,
 LO-4.4,(K1),Recall the purpose of Test|Task Tags in Robot Framework,,,

README.md

@@ -163,7 +163,7 @@
 - [`3.3.3 User Keyword Settings`](website/docs/chapter-03/03_user_keyword.md#333-user-keyword-settings)
   - LO-3.3.3 (K1) Recall all available settings and their purpose for User Keywords
 - [`3.3.4 User Keyword Documentation`](website/docs/chapter-03/03_user_keyword.md#334-user-keyword-documentation)
-  - LO-3.3.4 (K1) Recall the significance of the first logical line and in keyword documentation for the log file.
+  - LO-3.3.4 (K1) Recall the significance of the first logical line in keyword documentation for the log file.
 - [`3.3.5 User Keyword Arguments`](website/docs/chapter-03/03_user_keyword.md#335-user-keyword-arguments)
   - LO-3.3.5 (K2) Understand the purpose and syntax of the [Arguments] setting in User Keywords.
   - [`3.3.5.1 Defining Mandatory Arguments`](website/docs/chapter-03/03_user_keyword.md#3351-defining-mandatory-arguments)
@@ -222,7 +222,7 @@
 - [`4.2.3 Keyword Teardown`](website/docs/chapter-04/02_teardowns.md#423-keyword-teardown)
   - LO-4.2.3 (K1) Recall key characteristics, benefits, and syntax of Keyword Teardown
 - [`4.3 Initialization Files`](website/docs/chapter-04/03_init_files.md)
-- LO-4.3 (K1) Recall how to define Initialization Files and its purpose
+- LO-4.3 (K1) Recall how to define Initialization Files and their purpose
 - [`4.3.1 Purpose of Initialization Files`](website/docs/chapter-04/03_init_files.md#431-purpose-of-initialization-files)
 - [`4.3.2 Suite Setup and Suite Teardown of Initialization Files`](website/docs/chapter-04/03_init_files.md#432-suite-setup-and-suite-teardown-of-initialization-files)
   - LO-4.3.2 (K2) Understand the execution order of Suite Setup and Suite Teardown in Initialization Files and their sub-suites and tests|tasks

website/docs/chapter-01/01_purpose.md

@@ -46,7 +46,7 @@ Robot Framework is typically not used for **component testing** nor **integratio
 
 ### 1.1.1.1 Synthetic Monitoring
 
-Beyond traditional test levels, **Synthetic Monitoring**, also referred to as **Active Monitoring** or **Proactive Monitoring**, is a proactive approach that simulates user interactions with live systems at regular intervals. It detects performance issues or downtime early with the goal of detecting such failure before they affect actual users.
+Beyond traditional test levels, **Synthetic Monitoring**, also referred to as **Active Monitoring** or **Proactive Monitoring**, is a proactive approach that simulates user interactions with live systems at regular intervals. It detects performance issues or downtime early with the goal of detecting such failures before they affect actual users.
 
 
 

website/docs/chapter-01/02_architecture.md

@@ -58,7 +58,7 @@ Robot Framework itself focuses primarily on **test|task execution**.
 It includes:
 
 - A parser to read test|task data and build an execution model.
-- An execution engine to process model and execute the keywords.
+- An execution engine to process the model and execute the keywords.
 - A result generation mechanism to provide logs and reports.
 - A collection of generic standard libraries to process and handle data or interact with files and processes.
 - Defined APIs for extensions and customizations.

website/docs/chapter-01/03_syntax.md

@@ -15,7 +15,7 @@ Robot Framework is a script-based interpreter for files that contain textual spe
 These files are typically organized into directories.
 The syntax of Robot Framework is designed to be simple and human-readable, allowing for quick learning and ease of use.
 
-Key attributes of the syntax that improves the before mentioned:
+Key attributes of the syntax that improve the before mentioned:
 
 - **Space-separated syntax**: Robot Framework uses two or more spaces as the primary separator (although one space is allowed as a character).
   A use of **FOUR (4)** spaces is recommended to ensure clarity and readability of the specification.
@@ -25,7 +25,7 @@ Key attributes of the syntax that improves the before mentioned:
 - **String first**: Unquoted strings are considered as strings, while variables need special syntax.
 - **Single spaces are valid**: Single spaces are valid as a character in most elements and values without quotation.
 - **Mostly case-insensitive**: Most elements like keyword or variable names are case insensitive.
-However, some syntax, like library imports is case-sensitive.
+However, some syntax, like library imports, is case-sensitive.
 
 :::tip[Note]
 

website/docs/chapter-01/04_styles.md

@@ -16,16 +16,16 @@ While **Keyword-Driven Testing (KDT)** and **Behavior-Driven Development (BDD)**
 
 Both styles can be mixed, even within the same test or task, but it is strongly recommended to have separate styles for separate purposes and not mix them within the same body.
 One practical solution would be to define acceptance test cases that cover users' expectations in a declarative *Behavior-Driven Style*, while using keywords that are implemented in an imperative *Keyword-Driven style*.
-Further system level :term[test cases]{term="Test Case"}, that are not covering acceptance criteria could be written in a *Keyword-Driven style*.
+Further system level :term[test cases]{term="Test Case"}, that are not covering acceptance criteria, could be written in a *Keyword-Driven style*.
 
 The approach of both styles is different in that way,
 that the *Behavior-Driven Style* is a **declarative** specification,
-where the script describe/declare what the system should do or how it should behave,
+where the script describes/declares what the system should do or how it should behave,
 while the *Keyword-Driven Style* is an **imperative** specification,
 where the script specifies what the automation should do to control the system.
 
 
-Beside these two different specification approaches how to write/formulate
+Besides these two different specification approaches how to write/formulate
 your automation script and their step sequences,
 there is also a third specification method, **Data-Driven Specification** that can be combined
 with the other two styles, to define the data that is used in the automation.

website/docs/chapter-02/01_suitefile.md

@@ -19,7 +19,7 @@ If the path to a single file is given as **Root Suite** directly to Robot Framew
 
 If a directory path is given, starting at this location, Robot Framework will parse all `*.robot` files and directories within this path.
 Robot Framework analyzes all containing files and determines if they contain test cases or tasks. If they do, they are considered **Suite Files** or **Low-Level Suites**.
-All directories that either directly or indirectly contain a Suite File are considered **Suites Directories** or **Higher-Level Suites**.
+All directories that either directly or indirectly contain a Suite File are considered **Suite Directories** or **Higher-Level Suites**.
 
 The ordering of suites during execution is, by default, defined by their name and hierarchy.
 All files and directories, which are suites in one directory, are considered on the same level and are executed in case-insensitive alphabetical order.
@@ -128,7 +128,7 @@ It allows you to import keywords from external libraries (`Library`) or resource
 
 In this section, the suite name, that is normally derived from the file name, can be redefined with the `Name` setting and its documentation can be defined with the `Documentation` setting.
 
-Additional metadata can be defined by multiple `Metadata` entries, which can contain key-value pairs that can be used to store additional information about the suite, like the author, the version, or related requirements of the suite.
+Additional suite metadata can be defined by multiple `Metadata` entries, which can contain key-value pairs that can be used to store additional information about the suite, like the author, the version, or related requirements of the suite.
 
 This section can also define keywords called for execution flow control, such as `Suite Setup` and `Suite Teardown`, which are executed before and after the suite's tests run. See [4.1 Setups (Suite, Test|Task, Keyword)](chapter-04/01_setups.md) and
 [4.2 Teardowns (Suite, Test|Task, Keyword)](chapter-04/02_teardowns.md) for more information.

website/docs/chapter-02/02_suitefile_syntax.md

@@ -15,7 +15,7 @@ Understand the basic syntax of test cases and tasks.
 ::::
 
 Suite files and resource files share the same syntax, however they differ in their capabilities.
-Resource files are explained in more detail in [2.4.2 Resource Files](chapter-02/04_keyword_imports.md#242-resource-files) [3.1 Resource File Structure](chapter-03/01_resource_file.md).
+Resource files are explained in more detail in [2.4.2 Resource Files](chapter-02/04_keyword_imports.md#242-resource-files) and [3.1 Resource File Structure](chapter-03/01_resource_file.md).
 
 
 ## 2.2.1 Separation and Indentation
@@ -219,9 +219,9 @@ Some examples are:
 All those characters or character sequences that are interpreted as control characters can be escaped by a backslash `\`.
 This means that the character following the backslash is interpreted as a normal character and not as a control character.
 
-This leads to the fact that a backslash itself must be escaped by another backslash to be interpreted as a normal backslash character. Therefore it is strongly recommended to use forward slashes `/` as path separators in paths also on windows environments and avoid backslashes `\` whenever possible.
+This leads to the fact that a backslash itself must be escaped by another backslash to be interpreted as a normal backslash character. Therefore it is strongly recommended to use forward slashes `/` as path separators in paths also on Windows environments and avoid backslashes `\` whenever possible.
 
-Leading and trailing spaces in values are normally considered being part of the separator surrounding the values.
+Leading and trailing spaces in values are normally considered to be part of the separator surrounding the values.
 If values shall contain leading or trailing spaces they must be either enclosed in backslashes `\` or replaced by the special variable `${SPACE}` that contains a single space character.
 
 Example:

website/docs/chapter-02/03_executing.md

@@ -32,7 +32,7 @@ Understand how to run the `robot` command and its basic usage.
 
 The `robot` command is used to run a Robot Framework execution, which will execute suites and their containing tests|tasks.
 
-At a basic level, you can run `robot` by providing the path to a suite file or suite directory containing suite files as last argument.
+At a basic level, you can run `robot` by providing the path to a suite file or suite directory containing suite files as the last argument.
 ```plaintext
 robot <path_to_root_suite>
 ```
@@ -93,7 +93,7 @@ After executing a suite, Robot Framework, by default, generates three output fil
 
 `log.html` and `report.html` are generated based on the information stored in `output.xml`.
 
-A unique feature of Robot Framework is, that it logs each keyword call and its arguments with its log outputs and timestamps, so that it is possible to have a very detailed view of the execution flow and the data that was used during the execution.
+A unique feature of Robot Framework is that it logs each keyword call and its arguments with its log outputs and timestamps, so that it is possible to have a very detailed view of the execution flow and the data that was used during the execution.
 In case of a failure it is possible to see the exact keyword call that failed and the arguments that were used, which can be very helpful for debugging or reporting. Furthermore, you also get all passed keywords and even the non‑executed keywords, allowing you to trace the whole execution flow.
 
 
@@ -143,7 +143,7 @@ This status is used if an element was executed successfully without any errors o
 
 **Atomic elements** are `PASS` if they were executed successfully without reporting an error by raising an exception.
 
-**Composite elements** are `PASS` if all their executed body elements are pass.
+**Composite elements** are `PASS` if all their executed body elements are `PASS`.
 E.g. in case of User Keywords this means that if all keywords or Robot Framework language statements that were directly called by that User Keyword were `PASS` the User Keyword itself is considered `PASS`.
 
 Library Keywords like `Run Keyword And Expect Error`, from BuiltIn Library, do `PASS` if the keyword they are internally calling does raise an error with the expected message or type.
@@ -170,12 +170,12 @@ Exceptions are teardowns, as explained in [Chapter 4: Advanced Structuring and E
 
 **Atomic elements** are `FAIL` if they were tried to be executed but raised an exception.
 
-**Composite elements** are `FAIL` if at least one of their executed direct body elements are `FAIL`.
+**Composite elements** are `FAIL` if at least one of their executed direct body elements is `FAIL`.
 Therefore a failure typically distributes upwards through the hierarchy of elements until it reaches the root suite.
 
 A User Keyword is `FAIL` if one of its called Library Keywords is `FAIL`.
 A test|task is `FAIL` if one of its directly called Keywords is `FAIL`.
-A suite (file) is `FAIL` if one of its test|task is `FAIL` and
+A suite (file) is `FAIL` if one of its tests|tasks is `FAIL` and
 a suite (directory) is `FAIL` if one of its suites (file) is `FAIL`.
 
 

website/docs/chapter-02/04_keyword_imports.md

@@ -34,17 +34,14 @@ Recall the three types of libraries in Robot Framework.
 
 From a user perspective there are three different kinds of libraries:
 - **Robot Framework Standard Libraries**: These are libraries that are shipped with Robot Framework and are available without any additional installation. See documentation of [ext: Robot Framework Standard Libraries](https://robotframework.org/robotframework/#standard-libraries) for more information.
-- **3rd Party Libraries** / **External Libraries**: These are libraries have been developed and maintained by community members and have to be installed/downloaded separately.
+- **3rd Party Libraries** / **External Libraries**: These are libraries that have been developed and maintained by community members and have to be installed/downloaded separately.
 - **Custom Libraries**: These libraries are developed by the users themselves to solve specific problems or to encapsulate more complex functionality.
 
-Further more detailed information about the different types of libraries and are described in later chapters.
-{/* TODO: Do we fulfill this promise? */}
-
-To import a library into a suite or resource file the `Library` setting is used in the `*** Settings ***` section followed by the name of the library as long as they are located in the Python module search path, which automatically happens if they are installed via `pip`.
+To import a library into a suite or resource file the `Library` setting is used in the `*** Settings ***` section followed by the name of the library as long as it is located in the Python module search path, which automatically happens if it is installed via `pip`.
 The name of the library is case-sensitive and should be taken from the library's keyword documentation.
 By default, libraries in Robot Framework are implemented in Python and the name of the library is the name of the Python module that contains the library implementation.
 
-Alternatively, if a library is not in Python module search path, a library can be imported using the path to the Python module. See [2.4.3 Import Paths](chapter-02/04_keyword_imports.md#243-import-paths).
+Alternatively, if a library is not in the Python module search path, a library can be imported using the path to the Python module. See [2.4.3 Import Paths](chapter-02/04_keyword_imports.md#243-import-paths).
 
 Be aware that the library [`BuiltIn`](https://robotframework.org/robotframework/latest/libraries/BuiltIn.html) is always imported invisibly and does not need to be imported explicitly.