ds-wizard · krystofkomanec · Aug 6, 2026 · Aug 6, 2026 · Aug 6, 2026
diff --git a/docs/about/introduction/knowledge-model.rst b/docs/about/introduction/knowledge-model.rst
@@ -82,7 +82,7 @@ The value question asks for a single value that users type in. There are many di
 
 The input field differs based on the value type (simple input for string, date picker for date, etc.). Some of these have a check whether the entered value is valid (such as valid email or URL) and displays a warning if not.
 
-Value Question also can have validations. Validations differ based on the value type. For example, we can set a minimum and maximum value for a number, or a minimum and maximum length for a string. For text based types (text, email, URL), we can set also use a regular expression to create validations.
+Value Question can also have validations. Validations differ based on the value type. For example, we can set a minimum and maximum value for a number, or a minimum and maximum length for a string. For text-based types (text, email, URL), we can also use a regular expression to create validations.
 
 .. _integration-question:
 
@@ -241,7 +241,7 @@ Integrations define a connection to an external service or resource where we can
 API Integration
 ^^^^^^^^^^^^^^^
 
-API integration connects to an external service API to search for the answers. We need to provide some **request** and **response** configuration, so |project_name| can use the API.
+API integration connects to an external service API to search for the answers. We need to provide some **request** and **response** configuration, so DSW can use the API.
 
 
 .. _annotations:

diff --git a/docs/about/introduction/project.rst b/docs/about/introduction/project.rst
@@ -23,7 +23,7 @@ The questionnaire is part of the project where we fill in our answers. It is gen
 Documents
 =========
 
-The outcome of our endeavors in |project_name| should be the data management plan, the document. Once we have enough answers to the questionnaire, we can generate a document using a document template. These documents are saved within the project. We can create as many as we wish with different document templates and formats. We can also set up a default document template for the project and quickly see a preview of the document.
+The outcome of our endeavors in DSW should be the data management plan, the document. Once we have enough answers to the questionnaire, we can generate a document using a document template. These documents are saved within the project. We can create as many as we wish with different document templates and formats. We can also set up a default document template for the project and quickly see a preview of the document.
 
 
 :ref:`Learn how to work with the documents →<project-documents>`
diff --git a/docs/application/administration/index.rst b/docs/application/administration/index.rst
@@ -3,7 +3,7 @@
 Administration
 **************
 
-Administration section serves as the name suggests to users with permission to manage the |project_name| instance. By navigating via :guilabel:`Administration` item from the main menu, we can manage the things listed below.
+Administration section serves as the name suggests to users with permission to manage the DSW instance. By navigating via :guilabel:`Administration` item from the main menu, we can manage the things listed below.
 
 ----
 

diff --git a/docs/application/administration/locales/create.rst b/docs/application/administration/locales/create.rst
@@ -1,17 +1,16 @@
 Create Locale
 *************
 
-We can create a new locale directly in |project_name| by pressing :guilabel:`Create` from :doc:`./index`. We need to fill the details about the new locale such as name, description, language code (`RFC5646 <https://www.rfc-editor.org/rfc/rfc5646.html>`__, e.g. ``en`` or ``en-GB``), locale ID, locale version, license, README (with Markdown syntax), and recommended app version. The recommended app version captures for which version of the |project_name| is this locale intended and compatible with (it can be used in other versions as well but may have some untranslated texts).
+We can create a new locale directly in DSW by pressing :guilabel:`Create` from :doc:`./index`. We need to fill the details about the new locale such as name, description, language code (`RFC5646 <https://www.rfc-editor.org/rfc/rfc5646.html>`__, e.g. ``en`` or ``en-GB``), locale ID, locale version, license, README (with Markdown syntax), and recommended app version. The recommended app version captures for which version of the DSW is this locale intended and compatible with (it can be used in other versions as well but may have some untranslated texts).
 
 Finally, a PO file is requested from us. We can create such PO file in a standard (`gettext <https://www.gnu.org/software/gettext/>`__-based) way.
 
 Similarly we can create a PO file for the emails.
 
 The needed POT files are placed in the localization repository `wizard-locales <https://github.com/ds-wizard/wizard-locales>`__ (select the desired release and there is ``default.pot`` asset).
 
-Recommended tool for creating the localization is the `Poedit <https://poedit.net/>`__.
+Recommended tool for creating the localization is the `Poedit <https://poedit.com/>`__.
 
 .. figure:: create/form.png
 
     Form for creating a new locale.
-
diff --git a/docs/application/administration/locales/detail.rst b/docs/application/administration/locales/detail.rst
@@ -1,7 +1,7 @@
 Locale Detail
 *************
 
-The detail of a locale provides us information about a locale after navigating to it from :doc:`./index`. The detail shows basic information about the locale such as its name, ID, language code (`RFC5646 <https://www.rfc-editor.org/rfc/rfc5646.html>`__, e.g. ``en`` or ``en-GB``), version, recommended compatible |project_name| version, license, and indication whether the locale is enabled or not.
+The detail of a locale provides us information about a locale after navigating to it from :doc:`./index`. The detail shows basic information about the locale such as its name, ID, language code (`RFC5646 <https://www.rfc-editor.org/rfc/rfc5646.html>`__, e.g. ``en`` or ``en-GB``), version, recommended compatible DSW version, license, and indication whether the locale is enabled or not.
 
 The main part of the detail is the README of the locale that should contain basic information and changelog. In the right panel under the basic information, we can navigate to other versions of the locale.
 

diff --git a/docs/application/administration/locales/import.rst b/docs/application/administration/locales/import.rst
@@ -11,7 +11,7 @@ We can import an existing locale by navigating to :menuselection:`Settings → L
 From DSW Registry
 =================
 
-If the |project_name| instance is connected to the `DSW Registry <https://registry.ds-wizard.org>`__, it is possible to import locales from it by entering the **locale ID** of desired template (e.g. ``dsw:cs:0.2.0``) and pressing the :guilabel:`Import` button.
+If the DSW instance is connected to the `DSW Registry <https://registry.ds-wizard.org>`__, it is possible to import locales from it by entering the **locale ID** of desired template (e.g. ``dsw:cs:0.2.0``) and pressing the :guilabel:`Import` button.
 
 .. NOTE::
 
@@ -28,7 +28,7 @@ If the |project_name| instance is connected to the `DSW Registry <https://regist
 From file
 =========
 
-We can import a locale as a ZIP package. Such a package can be created as an export from |project_name|. We can also select multiple files at once.
+We can import a locale as a ZIP package. Such a package can be created as an export from DSW. We can also select multiple files at once.
 
 .. figure:: import/file.png
     :width: 500

diff --git a/docs/application/administration/locales/index.rst b/docs/application/administration/locales/index.rst
@@ -1,13 +1,13 @@
 Locales
 *******
 
-After navigating to :guilabel:`Locales` (under :guilabel:`Administration`), we can browse and manage a list of locales in the |project_name| instance. Similarly to knowledge models and document templates, each locale has its unique identifier and version. Moreover, each locale has a language code specified. In the list we see the latest version and can quickly navigate to :doc:`./detail` (which includes also older versions) by clicking the locale name or selecting :guilabel:`View detail` from the right item menu of the desired row.
+After navigating to :guilabel:`Locales` (under :guilabel:`Administration`), we can browse and manage a list of locales in the DSW instance. Similarly to knowledge models and document templates, each locale has its unique identifier and version. Moreover, each locale has a language code specified. In the list we see the latest version and can quickly navigate to :doc:`./detail` (which includes also older versions) by clicking the locale name or selecting :guilabel:`View detail` from the right item menu of the desired row.
 
-The |project_name| UI and emails can be localized to different languages. The preferred language is determined by the user's browser settings or by the user's profile settings.
+The DSW UI and emails can be localized to different languages. The preferred language is determined by the user's browser settings or by the user's profile settings.
 
 .. NOTE::
 
-    Locales can be used not only for translations but also for customizing the |project_name| to a specific domain.
+    Locales can be used not only for translations but also for customizing the DSW to a specific domain.
 
 
 There is always the **English** locale (``~: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.
@@ -19,7 +19,7 @@ If there is a locale with newer version available in the `DSW Registry <https://
 
 .. NOTE ::
 
-    We support community of DSW translators by managing the repository `ds-wizard/wizard-client-locales <https://github.com/ds-wizard/wizard-client-locales>`__ and service for translating using web browser `localize.ds-wizard.org <https://localize.ds-wizard.org>`__.
+    We support community of DSW translators by managing the repository `ds-wizard/wizard-locales <https://github.com/ds-wizard/wizard-locales>`__ and service for translating using web browser `localize.ds-wizard.org <https://localize.ds-wizard.org>`__.
 
 .. figure:: index/list.png
 
@@ -39,4 +39,4 @@ If there is a locale with newer version available in the `DSW Registry <https://
 
     Import<import>
     Create<create>
-    Detail<detail>
+    Detail<detail>
diff --git a/docs/application/administration/roles/index.rst b/docs/application/administration/roles/index.rst
@@ -3,12 +3,12 @@
 Roles
 *****
 
-Roles define what users can do across the |project_name| instance. Each user has one global role. The role contains a set of permissions, such as whether the user can manage users, configure settings, work with knowledge models, or access all projects.
+Roles define what users can do across the DSW instance. Each user has one global role. The role contains a set of permissions, such as whether the user can manage users, configure settings, work with knowledge models, or access all projects.
 
 Default Roles
 =============
 
-New |project_name| instances include default roles for the usual workflows:
+New DSW instances include default roles for the usual workflows:
 
 - **Researcher** for users who mainly create and work on their own projects.
 - **Data Steward** for users who prepare content such as knowledge models, document templates, and project templates.
@@ -35,7 +35,7 @@ Custom roles are useful for cases such as:
 Role Permissions
 ================
 
-Permissions are grouped by the type of work they enable. The available groups depend on the |project_name| edition and enabled features.
+Permissions are grouped by the type of work they enable. The available groups depend on the DSW edition and enabled features.
 
 Project-related permissions can allow a role to:
 

diff --git a/docs/application/administration/settings/content/dsw-registry.rst b/docs/application/administration/settings/content/dsw-registry.rst
@@ -3,11 +3,11 @@
 DSW Registry
 ************
 
-In this settings, we can configure a connection to DSW Registry that will allow import of various content (Knowledge Models, Document Templates, and Locales) to our |project_name| instance.
+In these settings, we can configure a connection to DSW Registry that will allow importing various content (Knowledge Models, Document Templates, and Locales) to our DSW instance.
 
-Upon enabling the DSW Registry option, we are prompted to enter a **Token**. It can be obtained either by direct registration in the `DSW Registry<https://registry.ds-wizard.org>__` or through clicking :guilabel:`Sign up` button. After clicking the button, we will need to enter details about organization (it is prefilled from :doc:`../system/organization`) and email address to which the confirmation will be sent (prefilled by email of the current user). Then, after clicking a link in the confirmation email, the token will be prefilled automatically. After having the token filled in either way, we can :guilabel:`Save` the settings.
+Upon enabling the DSW Registry option, we are prompted to enter a **Token**. It can be obtained either by direct registration in the `DSW Registry <https://registry.ds-wizard.org>`__ or by clicking the :guilabel:`Sign up` button. After clicking the button, we will need to enter details about the organization (prefilled from :doc:`../system/organization`) and the email address to which the confirmation will be sent (prefilled with the email of the current user). Then, after clicking a link in the confirmation email, the token will be prefilled automatically. After the token has been filled in either way, we can :guilabel:`Save` the settings.
 
-After successfully setting the DSW Registry, we will see option to import from it for :ref:`Knowledge Models<km-import>`, :ref:`Document Templates<doc-template-import>`, and :ref:`Locales<locale-import>`.
+After successfully setting the DSW Registry, we will see the option to import from it for :ref:`Knowledge Models<km-import>`, :ref:`Document Templates<doc-template-import>`, and :ref:`Locales<locale-import>`.
 
 .. NOTE::
 

diff --git a/docs/application/administration/settings/content/projects.rst b/docs/application/administration/settings/content/projects.rst
@@ -4,7 +4,7 @@ Projects
 Project Visibility
 ==================
 
-If we want to let users select visibility of their projects within the |project_name| instance, we can enable **Project Visibility** feature. If it is disabled, the new projects will have the **Default Project Visibility** which is used when creating a new project:
+If we want to let users select visibility of their projects within the DSW instance, we can enable **Project Visibility** feature. If it is disabled, the new projects will have the **Default Project Visibility** which is used when creating a new project:
 
 * **Private** = the project is visible only to the users with explicit access to the project.
 * **Visible - View** = the project is visible in view-only mode to all logged-in users, i.e. all users will be able to see the project in their :ref:`projects list<project-list>` and access it (but not edit or comment anything unless they are invited with different permissions).
@@ -19,7 +19,7 @@ If we want to let users select visibility of their projects within the |project_
 Project Sharing
 ===============
 
-If we want to let users select sharing option of their projects within the |project_name| instance, we can enable **Project Sharing** feature. If it is disabled, the new projects will have the **Default Project Sharing** which is used when creating a new project:
+If we want to let users select sharing options for their projects within the DSW instance, we can enable the **Project Sharing** feature. If it is disabled, the new projects will have the **Default Project Sharing** which is used when creating a new project:
 
 * **Restricted** = only logged-in users can access the project depending on the project visibility (no public access for anonymous users).
 * **View with the link** = anyone with the link to the project may open it in view mode and browse it.
@@ -34,15 +34,15 @@ If we want to let users select sharing option of their projects within the |proj
 Anonymous Projects
 ==================
 
-If we have set Knowledge Model as Public, we can also allow anonymous users to create projects where they will be able to fill questionnaires by enabling **Anonymous Projects**. These anonymous project then work as any other projects with public link set to edit permissions. However, if a logged-in user accesses such a project, then such a user may claim the ownership by clicking :guilabel:`Add to my projects` button. Anonymous users cannot create new documents, for that they must register and open the project as a logged-in user.
+If we have set Knowledge Model as Public, we can also allow anonymous users to create projects where they will be able to fill questionnaires by enabling **Anonymous Projects**. These anonymous projects then work as any other projects with public link set to edit permissions. However, if a logged-in user accesses such a project, then they may claim the ownership by clicking the :guilabel:`Add to my projects` button. Anonymous users cannot create new documents; for that, they must register and open the project as a logged-in user.
 
 
 Project Creation
 ================
 
 * **Templates & Custom** = users can create both projects from project templates and custom projects.
 * **Templates Only** = users can create projects only from project templates.
-* **Custom Only** = users can create only custom projects, they have to select knowledge model and everything else by themselves.
+* **Custom Only** = users can create only custom projects, they have to select a knowledge model and everything else by themselves.
 
 
 Summary Report
@@ -56,4 +56,4 @@ The **Summary Report** shows how many questions are answered and unanswered in e
 Project Tagging
 ===============
 
-If enabled, users will be able to tag their projects (using so-called **Project Tags**) and then use those tags to filter the :ref:`projects list<project-list>`. The users will be always able to write their own tags but we can provide a list of pre-defined **Default Project Tags** (one per line).
+If enabled, users will be able to tag their projects (using so-called **Project Tags**) and then use those tags to filter the :ref:`projects list<project-list>`. The users will always be able to write their own tags, but we can provide a list of pre-defined **Default Project Tags** (one per line).
diff --git a/docs/application/administration/settings/info/index.rst b/docs/application/administration/settings/info/index.rst
@@ -1,7 +1,7 @@
 Info
 ****
 
-The info section of settings simply serves to let us check various information and statistics about the |project_name| instance.
+The info section of settings simply serves to let us check various information and statistics about the DSW instance.
 
 
 ----

diff --git a/docs/application/administration/settings/info/usage.rst b/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. 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.
+Usage allows us quickly see numbers of entities in the DSW 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
 

diff --git a/docs/application/administration/settings/system/authentication.rst b/docs/application/administration/settings/system/authentication.rst
@@ -8,7 +8,7 @@ The **Default Role** settings option allows us to define which :ref:`role<roles>
 
 .. WARNING::
 
-    It is recommended to set this to the lowest-privilege role that fits new users. Otherwise, new users may be able to change content or settings for other users in the |project_name| instance.
+    It is recommended to set this to the lowest-privilege role that fits new users. Otherwise, new users may be able to change content or settings for other users in the DSW instance.
 
 .. NOTE::
 
@@ -21,7 +21,7 @@ Internal
 For internal authentication, we can set:
 
 - **Registration** - whether users can sign up on their own or not.
-- **Non-Admin Login** - whether non-admin users can log in to the |project_name| instance or not.
+- **Non-Admin Login** - whether non-admin users can log in to the DSW instance or not.
 - **Two-Factor Authentication** - whether users need to confirm their login with a one-time code sent to their email address or not.
 - **Session Expiration** - how long the user session is valid before the user needs to log in again in hours.
 - **User Email Link Expiration** - how long the email links (e.g., for password reset) are valid before they expire and cannot be used anymore in hours.

diff --git a/docs/application/administration/settings/system/authentication/openid.png b/docs/application/administration/settings/system/authentication/openid.png
diff --git a/docs/application/administration/settings/system/index.rst b/docs/application/administration/settings/system/index.rst
@@ -1,7 +1,7 @@
 System
 ******
 
-System settings allow us to configure basics about the organization running the |project_name| instance, how can user register and login, and finally the privacy and support information for the users.
+System settings allow us to configure basics about the organization running the DSW instance, how can user register and login, and finally the privacy and support information for the users.
 
 
 ----