Fix typos

docs/about/introduction/knowledge-model.rst

@@ -21,10 +21,10 @@ Knowledge model consists of several entities connected together. You can see how
    Knowledge model schema
 
 
-Knowlege Model
---------------
+Knowledge Model
+---------------
 
-At the top level, the knowledge model contains :ref:`chapters<chapter>`, and entities refered to elsewhere from the knowledge model: :ref:`metrics<metric>`, :ref:`phases<phase>`, :ref:`question tags<question-tag>`, and :ref:`integrations<integration>`.
+At the top level, the knowledge model contains :ref:`chapters<chapter>`, and entities referred to elsewhere from the knowledge model: :ref:`metrics<metric>`, :ref:`phases<phase>`, :ref:`question tags<question-tag>`, and :ref:`integrations<integration>`.
 
 
 .. _chapter:

docs/application/administration/locales/index.rst

@@ -5,7 +5,7 @@ After navigating to :guilabel:`Locales` (under :guilabel:`Administration`), we c
 
 There is always the **English** locale (``wizard:default:1.0.0``) which is embedded and cannot be deleted. For others, we can use :guilabel:`Export` and :guilabel:`Delete` options from the right item menu.
 
-Another option is to switch other locale to be the default one using :guilabel:`Set default` action. The default locale will be used in case no available locale tgat matching user's preferences (explicit or implicit from the web browser). We can :guilabel:`Disable` or :guilabel:`Enable` locales except the default one (which must be enabled).
+Another option is to switch other locale to be the default one using :guilabel:`Set default` action. "The default locale will be used if there isn't an available locale that matches the user's preferences (explicit or implicit from the web browser). We can :guilabel:`Disable` or :guilabel:`Enable` locales except the default one (which must be enabled).
 
 If there is a locale with newer version available in the `DSW Registry <https://registry.ds-wizard.org>`__ (and if configured), *update available* clickable badge may appear. Finally, we can use :guilabel:`Import` to :doc:`./import` and :guilabel:`Create` to :doc:`./create`.
 

docs/application/administration/settings/content/document-submission.rst

@@ -3,7 +3,7 @@ Document Submission Settings
 
 If we enable the **Document Submission** feature, users will be able to see :guilabel:`Submit` option for their documents. After selecting it, they will be prompted to select a service compatible with the document where they want to submit it.
 
-Each service must have its own **ID** (recommended is to use lowecase alphanumeric symbols and dash symbols). Then, we can set human-readable **Name** and **Description** (Markdown-enabled) to clarify for users what is this service and in what cases they should use it. We also need to specify the **Supported Formats**, for each we need to select a document template, its version, and the desired format. Finally, we configure how the document is sent to the external service, the request may contain some **User Properties** (users will be able to set values for them in their user profiles) and it is a HTTP request with a specific **Method**, sent to the **URL**, possibly with HTTP **Headers**. The very last option is to check whether the file should be sent as **Multipart** (with its own **File Name**) instead of plainly in the request body. Most of this configuration should be specified by the external submission service.
+Each service must have its own **ID** (recommended is to use lowercase alphanumeric symbols and dash symbols). Then, we can set human-readable **Name** and **Description** (Markdown-enabled) to clarify for users what is this service and in what cases they should use it. We also need to specify the **Supported Formats**, for each we need to select a document template, its version, and the desired format. Finally, we configure how the document is sent to the external service, the request may contain some **User Properties** (users will be able to set values for them in their user profiles) and it is a HTTP request with a specific **Method**, sent to the **URL**, possibly with HTTP **Headers**. The very last option is to check whether the file should be sent as **Multipart** (with its own **File Name**) instead of plainly in the request body. Most of this configuration should be specified by the external submission service.
 
 .. NOTE::
 

docs/application/administration/settings/content/knowledge-models.rst

@@ -6,12 +6,12 @@ Knowledge Models Settings
 Public Knowledge Models
 =======================
 
-If we want to let users to see and browse certain Knowledge Models (specifically, visit the :ref:`KM detail<km-detail>` and the :ref:`KM preview<km-preview>`) even if not logged in, we can enable **Public Knowledge Models**. Then, we need to specify **Allowed Packages**, e.g. which ranges of verions of a certain knowledge model will be publicly available. A blank value serves as *any value*, for example, if we fill the **Organization ID** and **Knowledge Model ID** but leave **Min Version** and **Max Version**, it will result in all version of that knowledge model to be public.
+If we want to let users to see and browse certain Knowledge Models (specifically, visit the :ref:`KM detail<km-detail>` and the :ref:`KM preview<km-preview>`) even if not logged in, we can enable **Public Knowledge Models**. Then, we need to specify **Allowed Packages**, e.g. which ranges of versions of a certain knowledge model will be publicly available. A blank value serves as *any value*, for example, if we fill the **Organization ID** and **Knowledge Model ID** but leave **Min Version** and **Max Version**, it will result in all version of that knowledge model to be public.
 
 Integration Config
 ==================
 
-The integrations specified in Knowledge Models can use configuration values (typicaly secrets such as API keys or tokens) from YAML configuration specified in :ref:`integration.yml file<integration-yml-file>` or the content specified here under **Integration Config**. The value here can be for example:
+The integrations specified in Knowledge Models can use configuration values (typically secrets such as API keys or tokens) from YAML configuration specified in :ref:`integration.yml file<integration-yml-file>` or the content specified here under **Integration Config**. The value here can be for example:
 
 .. CODE-BLOCK:: yaml
 

docs/application/administration/settings/info/usage.rst

@@ -1,7 +1,7 @@
 Usage
 *****
 
-Usage allows us quickly see numbers of entities in the |project_name| instance such as number of users, active users, knowledge models, KM editors, templates, projects, or documents. Moverover, we can see storage usage, i.e. how much capacity is being used by documents and templates (their files). We cannot perform any actions on this page.
+Usage allows us quickly see numbers of entities in the |project_name| instance such as number of users, active users, knowledge models, KM editors, templates, projects, or documents. Moreover, we can see storage usage, i.e. how much capacity is being used by documents and templates (their files). We cannot perform any actions on this page.
 
 .. figure:: usage/usage.png
 

docs/application/administration/settings/user-interface/dashboard-and-login-screen.rst

@@ -26,7 +26,7 @@ We can select the **Dashboard Style** whether the user should see a standard **w
 
   * **Outdated KM / Document Templates Widgets** allow to quickly see outdated packages and document templates in case the DSW Registry connection is configured.
 
-  * **Usage Widget** summarises the usage just as is also possible to see in the :doc:`../info/usage`.
+  * **Usage Widget** summarizes the usage just as is also possible to see in the :doc:`../info/usage`.
 
   * **Configure Organization Widget** quickly navigates to :doc:`../system/organization` if it is not yet done.
 
@@ -64,7 +64,7 @@ Announcements
 
 Another option to adjust the dashboard and/or the login screen is to add Announcements. Announcements are displayed above the main content in the login screen. In dashboard, they are also displayed above the main content for both **welcome** and **role-based** dashboard style. There are three levels of Announcements:
 
-* **Info** - light blue color for sending informations to the users.
+* **Info** - light blue color for sending information to the users.
 * **Warning** - yellow to warn the users about something.
 * **Critical** - red to signalize the Announcement is critical and it needs attention.
 

docs/application/administration/settings/user-interface/look-and-feel.rst

@@ -7,13 +7,13 @@ This part of settings allows us to adjust how the |project_name| instance looks
 Application Titles
 ==================
 
-There are two titles that we can set. First, **Application Title** is the full title that should identify the |project_name| instance, for example, in browser's tab. Second is **Short Application Title** which is visibile, for example, at the top of the main (left) menu next to the icon. We should keep **Short Application Title** really short (about 10 characters at maximum) so it fits well.
+There are two titles that we can set. First, **Application Title** is the full title that should identify the |project_name| instance, for example, in browser's tab. Second is **Short Application Title** which is visible, for example, at the top of the main (left) menu next to the icon. We should keep **Short Application Title** really short (about 10 characters at maximum) so it fits well.
 
 
 Custom Menu Links
 =================
 
-We can easily add custom links to the main (left) menu by clicking :guilabel:`Add` under **Custom Menu Links**. For each link, we can set **Icon** (from `Font Awesome <https://fontawesome.com/v5/search>`_), **Title** and the target **URL**. We can also set whether the link should open in **New Window** (if not, it will nagivate user directly in the same window/tab from |project_name| instance). Once the links are there, we can manage them or delete them at this place.
+We can easily add custom links to the main (left) menu by clicking :guilabel:`Add` under **Custom Menu Links**. For each link, we can set **Icon** (from `Font Awesome <https://fontawesome.com/v5/search>`_), **Title** and the target **URL**. We can also set whether the link should open in **New Window** (if not, it will navigate user directly in the same window/tab from |project_name| instance). Once the links are there, we can manage them or delete them at this place.
 
 
 .. figure:: look-and-feel/custom-links.png

docs/application/document-templates/index.rst

@@ -3,7 +3,7 @@
 Document Templates
 ******************
 
-This section is about managing the document templates and document template editors. Similarly to Knowledge Models, we can manage :doc:`./list/index` or work on new or customise existing templates using :doc:`./editors/index`.
+This section is about managing the document templates and document template editors. Similarly to Knowledge Models, we can manage :doc:`./list/index` or work on new or customize existing templates using :doc:`./editors/index`.
 
 ----
 

docs/application/knowledge-models/editors/create.rst

@@ -17,6 +17,6 @@ Every knowledge model needs to have a **name**, a **knowledge model ID** and **v
 
     <organizationId>:<knowledgeModelId>:<version>
 
-We can create a new project either from scratch, i.e. the new knowledge model will be empty and we will build it all ourselves, or based on an existing knowledge models, which means that everything from the chosen knowledge model will be copied to ours. We can start from there and add, delete, or modifiy the existing entities in there. We just need to choose the original knowledge model in the **based on** field. Alternatively, we can open the :ref:`knowledge model detail<km-detail>` and click on :guilabel:`Fork KM` there.
+We can create a new project either from scratch, i.e. the new knowledge model will be empty and we will build it all ourselves, or based on an existing knowledge models, which means that everything from the chosen knowledge model will be copied to ours. We can start from there and add, delete, or modify the existing entities in there. We just need to choose the original knowledge model in the **based on** field. Alternatively, we can open the :ref:`knowledge model detail<km-detail>` and click on :guilabel:`Fork KM` there.
 
 We can only have one knowledge model editor with the same knowledge model ID. If we deleted the editor but want to continue working on that knowledge model, we can create a new editor with the same knowledge model ID. Or we can open the :ref:`knowledge model detail<km-detail>` and click on :guilabel:`Create KM editor` there to have the editor create form prefilled.

docs/application/knowledge-models/editors/index.rst

@@ -3,7 +3,7 @@
 Knowledge Model Editors
 ***********************
 
-Here, we can see a list of all knoweldge model editors. Everyone with the data steward role assigned can see all the knowledge model editors.
+Here, we can see a list of all knowledge model editors. Everyone with the data steward role assigned can see all the knowledge model editors.
 
 .. figure:: index/knowledge-model-editors-list.png
 

docs/application/knowledge-models/editors/migration.rst

@@ -47,7 +47,7 @@ During the migration, we can see all the changes one by one and can choose wheth
 Cancelling a Knowledge Model Migration
 ======================================
 
-We can cancell the knowledge model migration at any point before we publish the new version of the Child KM. We need to navigate to the :ref:`list of knowledge model editors<knowledge-model-editors>` and choose :guilabel:`Cancel migration` from the dropdown menu for the desired KM editor.
+We can cancel the knowledge model migration at any point before we publish the new version of the Child KM. We need to navigate to the :ref:`list of knowledge model editors<knowledge-model-editors>` and choose :guilabel:`Cancel migration` from the dropdown menu for the desired KM editor.
 
 
 Finishing a Knowledge Model Migration
@@ -64,6 +64,6 @@ The publish screen shows us some information about the knowledge model, such as
 
 Then we need to add some additional metadata (these fields are pre-filled if there was a previous version published):
 
-- **License** - this is used when we want to share the knowledge model with other people so they know how they can do that. We recommend using a license identifier from `SPDX Licens List <https://spdx.org/licenses/>`_.
+- **License** - this is used when we want to share the knowledge model with other people so they know how they can do that. We recommend using a license identifier from `SPDX Licenses List <https://spdx.org/licenses/>`_.
 - **Description** - this should be really short and descriptive. It is used, for example, in select boxes when creating a new project to help researchers choose the best knowledge model for their use case.
 - **Readme** - this is where we can describe everything we need about the knowledge model. We can, for example, include a changelog of what changed in what version, etc. We can use :ref:`Markdown<markdown>` in this field to provide some nice formatting.

docs/application/profile/edit/index.rst

@@ -7,7 +7,7 @@ In case of configured submission services, there might be additional inputs unde
 
 .. figure:: index/form.png
 
-    Form for editting profile with example submission settings.
+    Form for editing profile with example submission settings.
 
 
 .. NOTE::

docs/more/development/document-templates/document-context.rst

@@ -31,7 +31,7 @@ Document context is an object that carries all information related to a DSW ques
 * ``updatedAt`` = timestamp when the document was last updated
 * ``uuid`` = UUID of the document
 
-This structure is provided to a Jinja template in :doc:`steps/jinja` and outputed from :doc:`steps/json`. We can use the JSON step to observe the actual content of the document context (structure as well as the values). Finally, we can also check :doc:`../metamodel-schemas` (the relevant JSON schema for document context).
+This structure is provided to a Jinja template in :doc:`steps/jinja` and outputted from :doc:`steps/json`. We can use the JSON step to observe the actual content of the document context (structure as well as the values). Finally, we can also check :doc:`../metamodel-schemas` (the relevant JSON schema for document context).
 
 
 Objectified Document Context

docs/more/development/document-templates/steps/jinja.rst

@@ -49,8 +49,8 @@ Filters
 
 Within Jinja templates, you can use so-called `filters <https://jinja.palletsprojects.com/en/3.0.x/templates/#filters>`__.Basically, those are functions applied to a first argument using pipe ``|`` symbol.
 
-Bultin Filters
-~~~~~~~~~~~~~~
+Builtin Filters
+~~~~~~~~~~~~~~~
 
 There are several widely used `builtin filters <https://jinja.palletsprojects.com/en/3.0.x/templates/#builtin-filters>`__ directly in Jinja.
 
@@ -182,8 +182,8 @@ Within Jinja templates, you can use so-called `tests <https://jinja.palletsproje
    {% endif %}
 
 
-Bultin Tests
-~~~~~~~~~~~~
+Builtin Tests
+~~~~~~~~~~~~~
 
 There are several widely used `builtin tests <https://jinja.palletsprojects.com/en/3.0.x/templates/#builtin-tests>`__ directly in Jinja.
 

docs/more/development/index.rst

@@ -1,7 +1,7 @@
 Development
 ***********
 
-|project_name| can be extended in many ways and new components and ways of integrations can be developed to support our needs. Besides the API available for everything that can be done in |project_name|, new :ref:`integration questions<integration_questions>` and :ref:`project importers<development-importers>` can be implementet to get data from outside to |project_name|, or new :ref:`document templates<document-template-development>` and :ref:`submission services<submission-service>` can be created to get the data outside of |project_name| in the desired form.
+|project_name| can be extended in many ways and new components and ways of integrations can be developed to support our needs. Besides the API available for everything that can be done in |project_name|, new :ref:`integration questions<integration_questions>` and :ref:`project importers<development-importers>` can be implemented to get data from outside to |project_name|, or new :ref:`document templates<document-template-development>` and :ref:`submission services<submission-service>` can be created to get the data outside of |project_name| in the desired form.
 
 This section provides information on how to develop custom content for |project_name| to fully tailor the tool to our specific requirements.
 

docs/more/development/integration-questions/integration-api.rst

@@ -38,7 +38,7 @@ The configuration is done in the :ref:`knowledge model editor<knowledge-model-ed
 Request Configuration
 ---------------------
 
-In the **Request** section, we configure how to make an HTTP requrests to the external service's API. For that, we need to configure the following (the specific values depends on how the API works):
+In the **Request** section, we configure how to make an HTTP requests to the external service's API. For that, we need to configure the following (the specific values depends on how the API works):
 
 - **Request URL** - what is the URL where we want to send search requests
 - **Request HTTP Method** - what HTTP method should be used
@@ -56,10 +56,10 @@ There is a special property ``${q}`` that we can use within those fields. The pr
 Response Configuration
 ----------------------
 
-In the **Response** section, we configure how to process the JSON respnonse from the external service. For that, we need to configure the following:
+In the **Response** section, we configure how to process the JSON response from the external service. For that, we need to configure the following:
 
 - **Response List Field** - where in the JSON response is the list of items corresponding to the search query
-- **Respone Item ID** - what field represents an item ID in the returned JSON
+- **Response Item ID** - what field represents an item ID in the returned JSON
 - **Response Item Template** - how we want to present the result to the user
 
 We can use Jinja2 templates (`Ginger <https://ginger.tobiasdammers.nl>`_ implementation) in Response Item ID and especially in Response Item Template to make the response item look better.
@@ -72,7 +72,7 @@ Sometimes, we might need to use some secrets (for example for authentication tok
 
 We need to navigate to :guilabel:`Administration → Settings → Knowledge Models` and there is a field called **Integration Config**. It is a YAML organized by the **Integration ID** at the top level and key value pairs for each property.
 
-We can fill some propertes in. So, for example, if the **Integration ID** of our integration is *ourIntegration* we can write:
+We can fill some properties in. So, for example, if the **Integration ID** of our integration is *ourIntegration* we can write:
 
 .. code-block:: yaml