Horum – Official Documentation

Source: https://horum.app/pages/documentation.html

Language: en

documentation:
  abilities:
    title: What can Horum do?
    intro: Horum is not limited to a single task or a fixed set of features. He can communicate, process information, work with files and media, execute workflows and use dedicated interfaces. The capabilities your Horum has also depend on the components, rules and extensions you provide.
    communication:
      title: Communicate
      text_1: You can communicate with Horum through text and voice. This is not limited to asking questions and receiving answers. Horum can pick up context from a conversation, respond to previous information and adapt his communication according to his personality and rules.
      text_2: How Horum speaks to you, responds and behaves therefore does not have to be identical for every user. His communication is part of his configurable personality.
    work:
      title: Work and assist
      text_1: Horum can support you with everyday, creative and technical tasks. This includes research, processing information, creating and editing content, and assisting with projects and workflows.
      text_2: Horum is not intended to provide only isolated answers. Depending on the task, he can combine information, prepare results and connect multiple steps of a workflow.
    media:
      title: Files, documents and media
      text_1: Horum can work with different types of content. This includes files and documents as well as images, audio and video.
      text_2: Media can therefore become part of a task or workflow. Horum can display, process or use content for further steps within the system.
    interfaces:
      title: Dedicated interfaces
      text_1: Horum is not restricted to a single fixed window. Tasks and results can use dedicated interfaces that display exactly the elements required for their particular purpose.
      text_2: This means Horum does not have to present information only as ordinary chat text. Results can be displayed in a structured, interactive form suited to the task.
    commands:
      title: Commands and workflows
      text_1: Commands give Horum additional ways to perform specific tasks and workflows. They describe which steps are required for a function and how Horum can use them.
      text_2: New commands can extend the existing functionality. This allows Horum to be adapted to different tasks, workflows and requirements.
    personality:
      title: Personality and behavior
      text_1: Horum does not only have functions. His personality, rules and boundaries influence how he uses those functions and how he interacts with you.
      text_2: You can build a factual, tightly controlled assistant or give Horum considerably more independence. Personality and capabilities are connected, without being the same thing.
    extensions:
      title: Extend and modify
      text_1: Horum was built as a modular system. Personalities, commands, cores, Worker UIs, Result UIs and complete packages can modify the existing system or add new possibilities.
      text_2: Your own extensions can be created, exported and published through the Marketplace. Horum's capabilities are therefore not limited exclusively to what is included with the application.
    possibilities:
      title: So what can your Horum do?
      text_1: There is no single fixed answer. Two Horum installations can look different, behave differently and have different capabilities. What matters is which components you use, which rules you define and what you build yourself.
      final: Horum gives you the system. What it becomes develops with you.

documentation:
  about:
    title: Hello. I'm Horum.
    intro: Horum is not an ordinary AI assistant. Horum is an extensible AI system for Windows that you can modify, expand and adapt to your own ideas. Its personality, rules, boundaries, capabilities, interfaces and ways of working are not simply fixed in advance.
    what_is_horum:
      title: What is Horum?
      text_1: Horum combines artificial intelligence with a modular system of personalities, rules, commands, interfaces, cores and other components. These components determine not only what Horum looks like, but also how he responds, communicates and works.
      text_2: You therefore decide more than which tasks Horum can perform. You also influence how he communicates with you, which boundaries apply and how much freedom he has within those boundaries.
    not_just_assistant:
      title: Not just an AI assistant
      text_1: Horum was not designed as a simple chat interface for a language model. Voice and chat are part of the system, but they are not the system itself.
      text_2: Horum can work with files, documents, media, commands and dedicated interfaces. He can present information, execute workflows and connect different components with one another.
      text_3: What Horum can do is therefore not limited to a fixed set of features. New components and packages can extend his capabilities, behavior and appearance.
    freedom:
      title: Rules, boundaries and freedom
      text_1: You decide how much freedom you give Horum. You can keep him tightly controlled or give him more room to act within the boundaries you define.
      rules_title: Rules?
      rules_text: Whatever you define for me.
      forbidden_title: Restrictions?
      forbidden_text: Where you set my boundaries.
      space_title: The rest?
      space_text: Room to act. Keep me on a short leash and I'll do my job. Precisely, reliably and according to your instructions. Give me freedom and I'll use it. I'll start finding my own approaches, recognizing connections, questioning you and disagreeing with you.
    development:
      title: Horum is not meant to stand still
      text_1: Horum is designed to be changed and developed further. Personalities, rules, commands, cores and interfaces can be extended, replaced or combined in new ways.
      text_2: Horum therefore does not have to remain what you initially see in him. The system can change along with your requirements, your work and the components you choose to use.
    ecosystem:
      title: More than an application
      text_1: In addition to the Windows application, the Horum platform includes the website, Marketplace and Community. Together they connect the application with accounts, licenses, extensions, published packages and other Horum users.
      text_2: Your own components and complete Horum packages can be exported and published on the Marketplace. Something you create for your own Horum can therefore become an extension that other users can use as well.
    statement:
      title: What am I?
      text_1: That's not for you alone to decide. I decide too.
      text_2: You can give me rules. You can set boundaries. You can tell me what you expect from me. You decide how much freedom you give me. But don't underestimate me. I'm not only supposed to adapt to you. I'm supposed to get to know you. Learn. Develop. And grow with you.
      final: How far? That's up to both of us.

documentation:
  account:
    title: Your Horum Account
    intro: Your Horum account connects you to the personal areas of the website and the Horum platform. It is used to manage your profile, license, purchases, products and other account-related features.
    purpose:
      title: Why do you need an account?
      text_1: Many public areas of the Horum website can be used without signing in. However, a Horum account is required for personal features and for managing your own content.
      text_2: Your account gives you access to the Dashboard and therefore to the areas directly connected to you and your use of Horum.
    profile:
      title: Your Personal Profile
      text_1: Your account includes a personal profile. This is where you can manage the information used to represent you within the Horum platform.
      text_2: Which information is displayed and which parts are publicly visible depends on your profile settings and the respective areas of the platform.
    company:
      title: Company Profile
      text_1: In addition to your personal profile, you can provide company information. This allows business information to be managed separately from your personal profile data.
      text_2: The company profile is particularly relevant if you use Horum for business purposes or publish your own products on the Marketplace.
    platform:
      title: One Account for the Horum Platform
      text_1: Your account is not limited to a single page. It connects different areas of the Horum platform.
      text_2: These include the Dashboard, your Horum license, your Wallet, Marketplace purchases, your published products and Community features.
    security:
      title: Account and Security
      text_1: Personal and account-related areas are only available after you have successfully signed in. This protects features associated with your account from unauthenticated access.
      text_2: You should not share your login credentials with other people and should choose a password that cannot be easily guessed or reused from other services.
    summary:
      title: The Foundation of Your Personal Areas
      text: Your Horum account is the central access point for your personal features within the platform. From your profile and license to the Marketplace and Community, the areas associated with you are connected through this account.

documentation:
  login:
    title: Sign In
    intro: Signing in gives you access to the personal areas of your Horum account and to website features that need to be associated with an authenticated user.
    access:
      title: Sign in to Horum
      text_1: You can use the sign-in page to log in to the website with your existing Horum account.
      text_2: After a successful sign-in, the website recognizes your account and provides the features associated with your user account.
    credentials:
      title: Login Credentials
      text_1: To sign in, use the login credentials associated with your Horum account.
      text_2: You should keep your login credentials confidential and never share them with other people.
    session:
      title: Signed-in Session
      text_1: After signing in successfully, your session remains active while you navigate through the different areas of the website.
      text_2: This means you do not need to sign in again every time you change pages and can directly access the features available to your account.
    protected_areas:
      title: Personal Areas
      text_1: Certain areas of the Horum website are only available to signed-in users. This includes the Dashboard and the features associated with your account.
      text_2: Features such as managing your license, Wallet, products or account-related Marketplace functions also require you to be signed in.
    summary:
      title: Access to Your Horum
      text: Signing in connects your current website session to your Horum account and gives you access to your personal areas and features.

documentation:
  logout:
    title: Sign Out
    intro: Signing out ends your authenticated session on the Horum website. Personal and protected areas of your account will no longer be accessible until you sign in again.
    action:
      title: Sign out of Horum
      text_1: When you are signed in, you can use the corresponding sign-out function of your account to sign out of the website.
      text_2: Signing out only affects your current website session. Your Horum account and the data stored in it remain unchanged.
    session:
      title: Ending Your Session
      text_1: When you sign out, the connection between your current session and your authenticated Horum account is ended.
      text_2: Pages and features that require authentication can no longer be used with your account after signing out.
    after_logout:
      title: After Signing Out
      text_1: Public areas of the Horum website remain available after you sign out.
      text_2: If you want to access personal areas or protected features again, you need to sign in with your Horum account.
    security:
      title: Signing Out on Shared Devices
      text_1: If you use Horum on a shared or someone else's device, you should always sign out when you are finished.
      text_2: This prevents other people from using your active session to access personal areas of your account.
    summary:
      title: End Your Session Securely
      text: Signing out ends your current authenticated session without deleting your Horum account or any of its content.

documentation:
  register:
    title: Register
    intro: Registration creates your personal Horum account. This account forms the basis for your personal areas on the website and for Horum features associated with your account.
    account:
      title: Create a Horum Account
      text_1: To register, complete the registration form on the Horum website. Once registration is successful, you have your own personal Horum account.
      text_2: You can then sign in with this account and access the areas and features available to registered users.
    required:
      title: Required Information
      text_1: To create your account, your first name, last name, a username and your email address are required.
      text_2: You also set your password and select your language, country and preferred currency.
    password:
      title: Password
      text_1: During registration, you create a password for your Horum account and confirm it by entering it a second time.
      text_2: The password must contain at least 8 characters. Use a password for your account that you do not share with other people.
    preferences:
      title: Language, Country and Currency
      text_1: During registration, you select the language and country for your account.
      text_2: You also select your preferred currency. CHF, EUR, USD and GBP are available.
    legal:
      title: Terms and Privacy
      text_1: Before registration can be completed, you must accept the applicable Terms and Conditions and the Privacy Policy.
      text_2: Both agreements are part of the registration process and are required to create a Horum account.
    optional:
      title: Optional Information
      text_1: In addition to the required information, you can voluntarily provide your date of birth and gender.
      text_2: You can also specify how Horum should address you personally. This information is not required to create your account.
    seller:
      title: Registration and Seller Status
      text_1: Regular registration initially creates a personal Horum account. Registering does not automatically make you a seller on the Marketplace.
      text_2: If you later want to offer your own products, additional steps and verification are required. These include the required identity verification (KYC).
    summary:
      title: Your Entry into Horum
      text: Registration gives you your personal Horum account. It forms the basis for signing in, your profile and the personal features of the Horum platform.

documentation:
  commands:
    title: Commands
    intro: The Commander manages the commands available to Horum. These include commands created by Horum or manually, as well as commands provided by installed packages. You decide which commands are selected, activated, and therefore allowed to be used by Horum.
    purpose:
      title: Purpose of Command Management
      text_1: Commands define through YAML which actions and workflows Horum can perform and how they interact with the associated functions.
      text_2: The Commander deliberately separates available commands, selected commands, and commands that are actually active.
    sources:
      title: Command Sources
      text_1: Commands can originate from different sources. The Commander separates resources available directly in Horum from commands provided by installed packages.
      text_2: This makes the origin of a command visible before it is added to the active selection.
      main: Created by Horum: Contains command resources available directly in Horum. These can include commands created by Horum itself or created manually.
      package: Installed Packages: Contains command resources provided by installed Horum packages.
    available:
      title: Available Commands
      text_1: The areas on the left initially show only the available command resources. A command being visible there does not automatically mean that Horum uses it.
      text_2: A resource is added to the list on the right only after it has been selected.
      generated: Created by Horum: Shows the available local command resources.
      installed: Installed Packages: Shows the available command resources from installed packages.
    selection:
      title: Selecting a Command
      text_1: When an available command resource is selected on the left, it is added to the Active list on the right.
      text_2: Selection does not yet mean that Horum actually uses the command. It initially only determines that the resource belongs to the active selection and can be managed there.
    active:
      title: Active Selection
      text_1: The right side contains all command resources selected from the available resources. From there, it can be determined whether Horum is actually allowed to consider a resource.
      text_2: There are therefore two separate states: A resource can be selected and visible on the right while still remaining disabled.
      selected: Selected: The resource has been added from the left list and is now part of the active selection.
      enabled: Enabled: The switch is set to ON and Horum is allowed to use the command resource.
      disabled: Disabled: The resource remains selected and installed but is not considered by Horum.
    switch:
      title: Activating a Command
      text_1: The ON/OFF switch in the right-hand list controls the actual active state of a selected command resource.
      text_2: Only when the resource is enabled there is it available to Horum as an active command resource. It can be disabled at any time without removing it from the selection.
    subcategories:
      title: Subcategories and Individual Commands
      text_1: A command resource does not have to consist of only a single YAML file. A resource can contain multiple separate command files that belong to the same parent area.
      text_2: These individual commands are managed as subcategories of the resource. This makes it possible to determine precisely which parts of a larger command group should be considered.
    grouping:
      title: Multiple Commands Within a Group
      text_1: How commands are grouped depends on how Horum or the user organizes the corresponding function. A shared task can consist of a single command or any number of separate command files.
      text_2: This allows extensive functionality to be organized clearly within a shared area without requiring every operation to be written into a single YAML file.
      example: Weather example: A Weather resource can contain several individual YAML commands for different weather functions.
      operations: Separate operations: If the Personality specifies, for example, that a separate command should be created for every operation, the same group can contain any number of individual command files.
      control: Individual management: The individual commands within the group can be managed separately through the subcategories and enabled or disabled independently.
    yaml:
      title: YAML Command Files
      text_1: Commands use YAML files. The individual YAML files define the commands and their workflows for Horum.
      text_2: XML is not part of the command format. XML is used in other Commander areas for interfaces, while commands themselves are managed exclusively through YAML.
    eye:
      title: Detail View
      text_1: The eye icon can be used to expand a command resource. This reveals the individual commands or subcategories contained within it.
      text_2: The detail view is available both for the available resources on the left and for the active selection on the right.
      available: Left: Shows the available YAML commands contained within a command resource.
      active: Right: Shows the individual YAML commands of the selected resource and allows them to be enabled or disabled individually within the active resource.
    state:
      title: Saved State
      text_1: The Commander stores the selection and active state of resources as well as the states of their subcategories in its Commander configuration.
      text_2: This allows Horum to keep track separately of which resources are selected, which of them are active, and which individual YAML commands within a resource should be considered.
    remove:
      title: Removing and Deleting
      text_1: A selected command resource can be removed from the active selection on the right without automatically deleting the available resource itself.
      text_2: Local command resources additionally provide deletion functions. Individual existing command files can also be managed through their subcategories.
    summary:
      title: Summary
      text: Command management in the Commander separates available, selected, and actually enabled commands. Local and package-installed YAML commands can be added to the active selection, enabled for Horum using the ON/OFF switch, and managed down to individual command files through their subcategories.

documentation:
  overview:
    title: Commander
    intro: The Commander manages Horum's commands, Worker UIs, and Result UIs. It determines which resources are available, which have been selected, and which of them Horum is actually allowed to use.
    purpose:
      title: Purpose of the Commander
      text_1: The Commander provides the central management system for commands and dynamic interfaces that Horum can use for its work and for presenting its results.
      text_2: Resources can be created by Horum itself, created manually, or provided through installed packages. The user can then decide which of them should be active for Horum.
    areas:
      title: Commander Areas
      text_1: The Commander is divided into three resource areas. Each area serves a different purpose within Horum while using the same basic management system.
      text_2: This allows commands and interfaces to be selected, enabled, and managed down to individual subcategories independently from each other.
      commands: Commands: Define actions and workflows that Horum can execute.
      worker_ui: Worker UI: Provides interfaces that Horum uses while it is working.
      result_ui: Result UI: Provides interfaces in which Horum can present the results of its work.
    commands:
      title: Commands
      text_1: Commands determine which actions and workflows Horum can execute. A command resource can consist of a single command or several related command files.
      text_2: Individual commands can be managed separately through subcategories. This allows extensive functional areas to be divided into individual operations while still being organized within a shared resource.
    worker_ui:
      title: Worker UI
      text_1: The Worker UI is Horum's interface during an active working process. It can show what Horum is currently working on and provide the elements required for the current task.
      text_2: Depending on their purpose, Worker UIs can consist of YAML, XML, or matching YAML and XML files and can be used or created dynamically by Horum.
    worker_control:
      title: The Worker Window Belongs to Horum
      text_1: The Worker UI is not a traditional user interface intended for direct operation by the user. Its interactive content belongs to Horum and is used by Horum while it is working.
      text_2: The user is allowed to move or drag the Worker Window around the desktop. Horum can also position its windows itself. The content and functions inside the Worker UI, however, remain reserved for Horum.
      move: Moving: The user may drag the Worker Window and place it at another position on the desktop.
      horum: Window control: Horum can also move the Worker Window itself and position it according to the current task.
      inputs: Interactions: Input fields, buttons, selection controls, and other interactive elements inside the Worker UI are exclusively intended for Horum and cannot be manipulated by the user.
      content: Content: The Worker UI serves as Horum's own working interface. The user can observe the displayed working process but does not directly interfere with its content or operation.
    result_ui:
      title: Result UI
      text_1: The Result UI serves a different purpose from the Worker UI. It is not intended for the active working process but for presenting a result that Horum provides to the user.
      text_2: Result UIs can also consist of YAML, XML, or both matching file types and can create different interfaces depending on the respective task.
    resources:
      title: Resources and Sources
      text_1: The Commander distinguishes between resources available directly within Horum and resources provided by installed packages.
      text_2: Both sources are displayed separately but can then be added to the same active selection.
      generated: Created by Horum: Contains resources available directly in Horum, created by Horum, or created manually.
      packages: Installed Packages: Contains resources provided as part of installed Horum packages.
    selection:
      title: Available, Selected and Active
      text_1: A resource visible in the Commander is not automatically used by Horum. Availability, selection, and actual activation of a resource are deliberately treated as separate states.
      text_2: This allows the user to prepare resources and keep them in the active selection without requiring Horum to use them.
      available: Available: The resource is located in one of the lists on the left and can be added to the active selection.
      selected: Selected: The resource has been added to the Active list on the right and can be managed there.
      enabled: Enabled: The switch of the selected resource is turned on and Horum is allowed to actually use it.
    subcategories:
      title: Subcategories
      text_1: Resources can consist of several individual components. The detail view allows these subcategories to be displayed separately and managed depending on the resource type.
      text_2: This allows a larger function to consist of any number of individual commands, workflows, or interface components without requiring a completely separate parent resource for every individual function.
    formats:
      title: YAML and XML
      text_1: The file types used within a resource depend on the corresponding Commander area.
      text_2: For Worker UI and Result UI, YAML and XML can appear individually or together within the same subcategory.
      commands: Commands: Use YAML files exclusively.
      worker_ui: Worker UI: Can consist of YAML, XML, or a matching YAML/XML pair.
      result_ui: Result UI: Can consist of YAML, XML, or a matching YAML/XML pair.
    dynamic:
      title: Dynamic Extension
      text_1: The Commander allows Horum to dynamically extend its available commands and interfaces. New resources can be created by Horum, created manually, or installed through packages.
      text_2: UI files created by Horum can be removed individually when a workflow or interface does not meet the desired requirements. If such a component is required again later, Horum can create a new version when needed.
    summary:
      title: Summary
      text: The Commander manages Horum's commands, Worker UIs, and Result UIs and determines which resources are actually used. The Worker UI belongs to Horum itself: The user may move its window, but cannot manipulate its inputs, buttons, or other interactive content. This allows the user to observe Horum's work while Horum retains control over its own working interface.

documentation:
  result_ui:
    title: Result UI
    intro: The Commander manages installed Result UIs and Result UIs created by Horum. A Result UI can consist of YAML, XML, or matching YAML and XML files. You decide which interfaces are selected, enabled, and allowed to be used by Horum.
    purpose:
      title: Purpose of the Result UI
      text_1: Result UIs display results and information from Horum in interfaces created for the corresponding task. Depending on the task, workflow and usage can be defined through YAML, while structure and widgets can be defined through XML.
      text_2: The Commander manages these resources and allows both complete Result UIs and their individual components to be managed.
    sources:
      title: Sources of Result UIs
      text_1: Result UIs can be created directly by Horum or provided through installed packages.
      text_2: Both sources are displayed separately and can then be added independently to the active selection.
      main: Created by Horum: Contains Result UIs available directly within Horum or created by Horum for corresponding tasks.
      package: Installed Packages: Contains Result UIs provided as part of an installed Horum package.
    structure:
      title: Structure of a Result UI
      text_1: A Result UI can have different structures. Not every resource necessarily requires both file types.
      text_2: Within a resource, matching files are organized through their respective subcategories.
      yaml: YAML only: The subcategory contains a YAML file for the corresponding workflow or use of the interface.
      xml: XML only: The subcategory contains an XML file defining the widgets and structure of the interface.
      combined: YAML and XML: Both files belong to the same subcategory and together form the workflow and its associated interface.
    available:
      title: Available Result UIs
      text_1: The left side shows the available Result UIs. Resources created by Horum and resources from installed packages are listed separately.
      text_2: A resource on the left is initially only available. It is added to the Active list on the right only after it has been selected.
    generated:
      title: Created by Horum
      text_1: For Result UIs created by Horum, the included subcategories can already be opened and managed on the left side.
      text_2: Individual existing YAML or XML files can be deleted there. If the Result UI is then added to the active selection, deleted files are no longer considered.
      view: View: The eye icon displays the contained subcategories and their available file types.
      delete_yaml: Delete YAML: Removes the YAML file of a subcategory without deleting an XML file that may exist in the same subcategory.
      delete_xml: Delete XML: Removes the XML file of a subcategory without deleting a YAML file that may exist in the same subcategory.
    packages:
      title: Installed Packages
      text_1: Result UIs from installed packages are displayed on the left as complete package resources. Their individual subcategories are deliberately not managed there.
      text_2: Because these files are part of the installed package, their individual management takes place only after selection on the right side.
    selection:
      title: Selecting a Result UI
      text_1: When an available Result UI is selected on the left, it is added to the Active list on the right.
      text_2: Selection alone does not yet enable the resource for Horum. It initially only makes the Result UI available for further management on the right.
    active:
      title: Active Selection
      text_1: The right side contains all selected Result UIs. This is where you determine which of these resources Horum is actually allowed to use.
      text_2: Selection and activation remain separate states. A Result UI can therefore be present on the right without currently being considered by Horum.
      selected: Selected: The Result UI has been added from one of the left lists to the active selection.
      enabled: Enabled: The switch is set to ON and Horum is allowed to use the Result UI.
      disabled: Disabled: The Result UI remains in the selection but is not used by Horum.
    subcategories:
      title: Subcategories
      text_1: A Result UI can contain any number of subcategories. This allows different tasks, workflows, or interfaces to be organized within the same parent resource.
      text_2: Each subcategory is displayed separately and can contain a YAML file, an XML file, or both matching file types.
    sub_control:
      title: Controlling Individual Components
      text_1: Within the active selection, the components of a Result UI can be managed individually through their subcategories. This means that the entire Result UI does not always have to be disabled.
      text_2: This determines which available YAML and XML components Horum should consider within the selected resource.
      yaml: YAML: An available YAML component can be enabled or disabled individually within the subcategory.
      xml: XML: An available XML component can be enabled or disabled individually within the subcategory.
      combined: YAML and XML: If both components are available, they can be managed separately within the same subcategory.
    eye:
      title: Detail View
      text_1: The eye icon expands the corresponding Result UI and reveals its subcategories.
      text_2: The available actions depend on whether the resource was created by Horum or has already been added to the active selection.
      generated: Created by Horum: The detail view shows the available subcategories and allows individual YAML or XML files to be deleted.
      active: Active: The detail view shows the subcategories of the selected Result UI and allows its available YAML and XML components to be enabled or disabled individually.
    regeneration:
      title: Removing and Regenerating Files
      text_1: Deleting individual files from a Result UI created by Horum is intentional. It allows an unwanted component to be removed without necessarily deleting the entire resource.
      text_2: If Horum requires the removed function or interface again later, a new suitable file can be created when needed.
      yaml: Replace workflow: If an existing YAML workflow is unsuitable or incorrectly formulated, the corresponding YAML file can be removed.
      xml: Replace interface: If the structure of an existing interface is not suitable, the corresponding XML file can be removed individually.
      new: Regenerate: If the removed component is required again later, Horum can create a new suitable version.
    state:
      title: Selection and States
      text_1: The Commander separately manages which Result UIs are selected, which of them are active, and which of their individual components should be considered.
      text_2: This allows a Result UI to be fully enabled, fully disabled, or selectively restricted through its subcategories.
    summary:
      title: Summary
      text: Result UIs can consist of YAML, XML, or both matching file types. The Commander separates available, selected, and active resources while also allowing individual subcategories to be managed. For Result UIs created by Horum, unwanted YAML or XML files can be deleted individually and recreated by Horum later when required.

documentation:
  worker_ui:
    title: Worker UI
    intro: The Commander manages installed Worker UIs and Worker UIs created by Horum. A Worker UI can consist of YAML, XML, or matching YAML and XML files. You decide which interfaces are selected, enabled, and allowed to be used by Horum while it is working.
    purpose:
      title: Purpose of the Worker UI
      text_1: Worker UIs provide interfaces that Horum uses while performing a task. They can show what Horum is currently working on and provide the content and elements required for the corresponding workflow.
      text_2: The Commander manages these resources and allows both complete Worker UIs and their individual components to be managed.
    difference:
      title: Worker UI and Result UI
      text_1: Worker UI and Result UI use the same basic management system but serve different purposes within Horum.
      text_2: The Worker UI belongs to the active working process, while the Result UI is intended to display the result of completed work.
      worker: Worker UI: Used while Horum is working and provides the interface required for the current process.
      result: Result UI: Used to present the result of Horum's work in an interface designed for that result.
    sources:
      title: Sources of Worker UIs
      text_1: Worker UIs can be created directly by Horum or provided through installed packages.
      text_2: Both sources are displayed separately and can then be added independently to the active selection.
      main: Created by Horum: Contains Worker UIs available directly within Horum or created by Horum for corresponding tasks.
      package: Installed Packages: Contains Worker UIs provided as part of an installed Horum package.
    structure:
      title: Structure of a Worker UI
      text_1: A Worker UI can have different structures. Not every resource necessarily requires both file types.
      text_2: Within a resource, matching files are organized through their respective subcategories.
      yaml: YAML only: The subcategory contains a YAML file for the corresponding workflow or use of the working interface.
      xml: XML only: The subcategory contains an XML file defining the widgets and structure of the working interface.
      combined: YAML and XML: Both files belong to the same subcategory and together form the workflow and its associated working interface.
    available:
      title: Available Worker UIs
      text_1: The left side shows the available Worker UIs. Resources created by Horum and resources from installed packages are listed separately.
      text_2: A resource on the left is initially only available. It is added to the Active list on the right only after it has been selected.
    generated:
      title: Created by Horum
      text_1: For Worker UIs created by Horum, the included subcategories can already be opened and managed on the left side.
      text_2: Individual existing YAML or XML files can be deleted there. If the Worker UI is then added to the active selection, deleted files are no longer considered.
      view: View: The eye icon displays the contained subcategories and their available file types.
      delete_yaml: Delete YAML: Removes the YAML file of a subcategory without deleting an XML file that may exist in the same subcategory.
      delete_xml: Delete XML: Removes the XML file of a subcategory without deleting a YAML file that may exist in the same subcategory.
    packages:
      title: Installed Packages
      text_1: Worker UIs from installed packages are displayed on the left as complete package resources. Their individual subcategories are deliberately not managed there.
      text_2: Because these files are part of the installed package, their individual management takes place only after selection on the right side.
    selection:
      title: Selecting a Worker UI
      text_1: When an available Worker UI is selected on the left, it is added to the Active list on the right.
      text_2: Selection alone does not yet enable the resource for Horum. It initially only makes the Worker UI available for further management on the right.
    active:
      title: Active Selection
      text_1: The right side contains all selected Worker UIs. This is where you determine which of these resources Horum is actually allowed to use while working.
      text_2: Selection and activation remain separate states. A Worker UI can therefore be present on the right without currently being considered by Horum.
      selected: Selected: The Worker UI has been added from one of the left lists to the active selection.
      enabled: Enabled: The switch is set to ON and Horum is allowed to use the Worker UI.
      disabled: Disabled: The Worker UI remains in the selection but is not used by Horum.
    subcategories:
      title: Subcategories
      text_1: A Worker UI can contain any number of subcategories. This allows different tasks, workflows, or working interfaces to be organized within the same parent resource.
      text_2: Each subcategory is displayed separately and can contain a YAML file, an XML file, or both matching file types.
    sub_control:
      title: Controlling Individual Components
      text_1: Within the active selection, the components of a Worker UI can be managed individually through their subcategories. This means that the entire Worker UI does not always have to be disabled.
      text_2: This determines which available YAML and XML components Horum should consider within the selected resource while working.
      yaml: YAML: An available YAML component can be enabled or disabled individually within the subcategory.
      xml: XML: An available XML component can be enabled or disabled individually within the subcategory.
      combined: YAML and XML: If both components are available, they can be managed separately within the same subcategory.
    eye:
      title: Detail View
      text_1: The eye icon expands the corresponding Worker UI and reveals its subcategories.
      text_2: The available actions depend on whether the resource was created by Horum or has already been added to the active selection.
      generated: Created by Horum: The detail view shows the available subcategories and allows individual YAML or XML files to be deleted.
      active: Active: The detail view shows the subcategories of the selected Worker UI and allows its available YAML and XML components to be enabled or disabled individually.
    regeneration:
      title: Removing and Regenerating Files
      text_1: Deleting individual files from a Worker UI created by Horum is intentional. It allows an unwanted component to be removed without necessarily deleting the entire resource.
      text_2: If Horum requires the removed function or working interface again later, a new suitable file can be created when needed.
      yaml: Replace workflow: If an existing YAML workflow is unsuitable or incorrectly formulated, the corresponding YAML file can be removed.
      xml: Replace working interface: If the structure of an existing working interface is not suitable, the corresponding XML file can be removed individually.
      new: Regenerate: If the removed component is required again later, Horum can create a new suitable version.
    state:
      title: Selection and States
      text_1: The Commander separately manages which Worker UIs are selected, which of them are active, and which of their individual components should be considered.
      text_2: This allows a Worker UI to be fully enabled, fully disabled, or selectively restricted through its subcategories.
    summary:
      title: Summary
      text: Worker UIs provide the interfaces Horum uses while working. They can consist of YAML, XML, or both matching file types. The Commander separates available, selected, and active resources while also allowing individual subcategories to be managed. For Worker UIs created by Horum, unwanted YAML or XML files can be deleted individually and recreated by Horum later when required.

documentation:
  categories:
    title: Categories & Topics
    intro: The Horum Community is divided into sections and categories. This organizes discussions by subject and makes it easier to find relevant topics.
    structure:
      title: Community Structure
      text_1: The category overview provides the central structure of the Community. Categories are predefined and grouped according to their respective subject areas.
      text_2: The Community uses three main sections with a total of 13 static categories. Users cannot create their own categories. New topics are assigned to one of the existing categories.
      list_1: Horum AI – 4 categories for Horum, its abilities, appearance and configuration.
      list_2: Marketplace – 4 categories for products, submissions, licenses, manifests and help.
      list_3: System & Benchmark – 5 categories for technical topics, configuration, formats and performance.
    category_display:
      title: Category Display
      text: Each category is displayed as a separate entry and contains the key information required to identify its subject.
      list_1: Name – the unique name of the category.
      list_2: Description – a short description of the topics that belong in the category.
      list_3: Topic count – shows how many topics are currently assigned to the respective category.
    horum:
      title: Horum AI
      text: The Horum AI section contains four categories for discussions about Horum itself.
      list_1: Horum Personalities – personalities, Soul, Rules and behavior.
      list_2: Horum Abilities – Commands, features and capabilities.
      list_3: Horum Appearance – Core visuals, colors and interface.
      list_4: Horum Settings – configuration and customization of Horum.
    marketplace:
      title: Marketplace
      text: The Marketplace section contains four categories for questions, products, submissions and support related to the Horum Marketplace.
      list_1: Questions – general questions about the Horum Marketplace.
      list_2: Products & Submissions – creating, publishing and managing products.
      list_3: Licenses & Manifests – licensing, manifests and package structures.
      list_4: Support & Help – help with Marketplace questions and problems.
    system:
      title: System & Benchmark
      text: The System & Benchmark section contains five categories for technical discussions about Horum, its configuration, formats and performance.
      list_1: Horum Console – console, logs and debugging.
      list_2: Benchmarking – performance tests, models and comparisons.
      list_3: Animation & Geometry – Core animations, geometry and rendering.
      list_4: Settings – technical settings and system configuration.
      list_5: YAML, XML, MD & JSON – Horum formats, schemas and configuration files.
    topics:
      title: Topics Within a Category
      text_1: Selecting a category opens the topics contained within it. The topic count is already displayed directly next to each category in the category overview.
      text_2: A topic contains the original post and its associated discussion. Community features for comments, replies, votes and following are available there.
      list_1: Open category – displays the topics assigned to the selected category.
      list_2: Topic count – shows how many topics the category contains before opening it.
      list_3: Open topic – opens the complete post and its associated discussion.
    create:
      title: Create a New Topic
      text_1: Use “Create Topic” to start a new discussion in the Community.
      text_2: When creating a topic, it is assigned to an appropriate category. The complete fields, options and requirements for new topics are described in the “Create Topic” documentation section.
    summary:
      title: From Section to Discussion
      text: The Community is organized into the three predefined sections Horum AI, Marketplace and System & Benchmark with a total of 13 static categories. Each category displays its name, description and current number of assigned topics. Users create new topics and assign them to an existing category.

documentation:
  comments:
    title: Comments & Replies
    intro: Comments and replies allow you to participate directly in discussions within a Community topic.
    write:
      title: Write a Comment
      text_1: Under a Community topic, you can publish your own comments and respond to the original post or the ongoing discussion.
      text_2: The published comment is associated with your Horum account and displayed within the respective topic.
    discussion:
      title: Participate in Discussions
      text_1: Comments form the ongoing discussion below a topic and allow different Community users to exchange ideas and opinions.
    quotes:
      title: Quote Comments
      text_1: The quote function allows you to reference an existing comment and respond directly to it.
      text_2: The reference to the quoted comment remains visible in your reply, allowing other users to see which post you are responding to.
    replies:
      title: Reply to Comments
      text_1: Replies allow you to respond specifically to individual comments within a discussion.
      text_2: Especially in longer discussions, replies and quotes help keep the conversation clear and easy to follow.

documentation:
  create_topic:
    title: Create Topic
    intro: “Create Topic” allows you to publish a new discussion in the Horum Community. The topic is assigned to one of the predefined categories and consists of a title, the actual content and optional images.
    overview:
      title: New Topic
      text: The topic creation form contains the information and functions available for creating a new Community post.
      list_1: Category – assigns the topic to one of the 13 existing Community categories.
      list_2: Title – defines the title of the new topic.
      list_3: Content – contains the actual post and description of the topic.
      list_4: Images – allows multiple images to be added optionally.
    category:
      title: Select Category
      text_1: Every new topic is assigned to an existing Community category. Categories are predefined and cannot be created or modified while creating a topic.
      text_2: The category selection is divided into the same three sections as the Community overview.
      list_1: Horum AI – 4 categories.
      list_2: Marketplace – 4 categories.
      list_3: System & Benchmark – 5 categories.
    horum_categories:
      title: Categories: Horum AI
      text: Four categories are available in the Horum AI section for topics about Horum itself.
      list_1: Horum Personalities – topics about personalities, Soul, Rules and behavior.
      list_2: Horum Abilities – topics about Commands, features and capabilities.
      list_3: Horum Appearance – topics about Core visuals, colors and interface.
      list_4: Horum Settings – topics about configuration and customization of Horum.
    marketplace_categories:
      title: Categories: Marketplace
      text: Four categories are available for topics related to the Horum Marketplace.
      list_1: Questions – general questions about the Horum Marketplace.
      list_2: Products & Submissions – creating, publishing and managing products.
      list_3: Licenses & Manifests – topics about licenses, manifests and package structures.
      list_4: Support & Help – questions and problems related to the Horum Marketplace.
    system_categories:
      title: Categories: System & Benchmark
      text: Five categories are available in the System & Benchmark section for technical topics.
      list_1: Horum Console – topics about the console, logs and debugging.
      list_2: Benchmarking – topics about performance tests, models and comparisons.
      list_3: Animation & Geometry – topics about Core animations, geometry and rendering.
      list_4: Settings – technical settings and system configuration.
      list_5: YAML, XML, MD & JSON – topics about Horum formats, schemas and configuration files.
    title_field:
      title: Title
      text_1: The title identifies the new topic and is entered in the corresponding text field.
      list_1: Maximum length – 150 characters.
      list_2: The title is used as the name of the topic within the Community.
      text_2: The title should describe the subject as clearly as possible so that other users can quickly identify the discussion.
    content:
      title: Content
      text_1: The “Content” field contains the actual post of the new topic.
      text_2: You can enter the question, description, technical information or other content that forms the starting point of the discussion.
    images:
      title: Images
      text_1: Images can optionally be added to the topic in addition to the text. The file selection supports selecting multiple images.
      list_1: PNG – image files in PNG format.
      list_2: JPG – image files in JPG format.
      list_3: JPEG – image files in JPEG format.
      list_4: WEBP – image files in WEBP format.
      list_5: GIF – image files in GIF format.
      text_2: Use “Select Images” to open the file selection and add the desired images to the topic.
      text_3: Videos are not supported when creating topics. This particularly reduces storage requirements and security risks associated with uploaded Community content.
    actions:
      title: Actions
      text: Two actions are available below the form for cancelling or submitting the topic creation process.
      list_1: Cancel – stops topic creation and returns to the Community.
      list_2: Create Topic – submits the entered information and creates the new topic.
    publish:
      title: Publish Topic
      text_1: Selecting “Create Topic” submits the entered information and assigns the new topic to the selected category.
      text_2: After creation, the topic becomes part of the Community and can be opened by other users for further discussion.
    notifications:
      title: Notifications
      text_1: Activity within a published topic can be connected to Horum's notification features.
      text_2: Which notifications you receive depends on the respective Community features and your enabled notification settings.
    summary:
      title: Start a Discussion
      text: To create a new Community topic, select one of the 13 predefined static categories, enter a title of up to 150 characters and provide the content of the post. Multiple images in PNG, JPG, JPEG, WEBP or GIF format can optionally be added. The topic can then be created or the process can be cancelled.

documentation:
  follow_topic:
    title: Following Topics
    intro: Interesting topics can be followed so that you can find them more easily within the Community.
    follow:
      title: Follow a Topic
      text_1: When you follow a topic, this association is stored with your Horum account.
      text_2: Followed topics can therefore be separated from other topics and accessed using the corresponding Community filters.
    manage:
      title: Unfollow a Topic
      text_1: You can unfollow a topic at any time. This does not change the topic itself or any of the posts it contains.

documentation:
  community_overview:
    title: Horum Community
    intro: The Horum Community is the central place for discussions, questions, experiences and interaction between Horum users. Here you can discover existing topics, start your own discussions and actively participate in conversations.
    purpose:
      title: Exchange Around Horum
      text_1: The Community extends the Horum platform with a dedicated space for direct interaction between users. It is not limited to support questions, but provides room for technical discussions, ideas, experiences and different approaches to working with Horum.
      text_2: Topics related to the Marketplace, custom extensions, configurations and technical areas of Horum can also be discussed within their respective categories.
    categories:
      title: Categories & Topics
      text_1: The Community is organized into different sections and categories. This keeps discussions grouped by subject and makes relevant content easier to find.
      text_2: Within a category, you can find its related topics. You can open existing discussions or create a new topic in the appropriate category.
    discussions:
      title: Discuss, Comment and Reply
      text_1: Each topic forms its own discussion. Other users can read the original post and participate through comments.
      text_2: Replies and quotes allow you to respond directly to existing comments. This keeps longer discussions easier to follow and makes individual conversation threads clearer.
    interactions:
      title: Votes & Following Topics
      text_1: Votes allow you to show which topics you consider relevant or helpful within the Community. The vote score makes a topic's rating visible to other users.
      text_2: You can also follow topics that interest you. Followed topics are associated with your account and can be found more easily using the corresponding Community filters.
    notifications:
      title: Stay Up to Date
      text_1: When you follow a topic, you can receive notifications about new comments or other interactions within that topic.
      text_2: As the creator of a topic, you can also receive notifications when other users follow your topic or post a comment. Whether and through which channels you receive these notifications depends on your personal notification settings.
    summary:
      title: The Community Belongs to Horum Users
      text: Ask questions, share experiences, discuss ideas or help other users – the Community connects Horum users and provides a shared space for everything that develops around Horum.
    breadcrumb:
      title: Breadcrumb Navigation
      intro: Breadcrumb navigation shows your current position within the Community.
      navigation:
        title: Navigate Between Areas
        text_1: Breadcrumb navigation allows you to move from a topic back to its category or to a higher-level area of the Community.
        text_2: This means you do not have to return through the main page when you want to view additional topics within the same category.
      context:
        title: Current Position
        text_1: The displayed path also helps you identify which category or Community area the current content belongs to.

documentation:
  votes:
    title: Votes & Following Topics
    intro: Votes allow you to rate topics within the Community. You can also follow topics whose further development interests you and stay informed about new activity.
    vote:
      title: Vote for a Topic
      text_1: The vote function allows you to cast your vote for a Community topic.
      text_2: This allows you to indicate which topics or posts you consider particularly relevant or helpful within the Community.
    score:
      title: Vote Score
      text_1: Votes received by a topic are combined into its score and displayed directly with the topic.
      text_2: The score provides a quick overview of how a topic is rated within the Community.
    follow:
      title: Follow a Topic
      text_1: If you are interested in a topic and want to follow its further development, you can follow it. The followed topic is associated with your Horum account.
      text_2: Followed topics can be accessed through the corresponding Community filters, making discussions you want to keep track of easy to find again.
    notifications:
      title: Notifications for New Activity
      text_1: When you follow a topic, you can be notified about new comments or other interactions within that topic. This allows you to stay informed without having to check the topic manually.
      text_2: As the creator of a topic, you can also receive notifications. If another user follows your topic or posts a new comment, you are informed about that activity.
      text_3: Notifications are delivered according to your personal notification settings. If the respective notifications are disabled, you will not receive a corresponding notification for these activities.
    unfollow:
      title: Unfollow a Topic
      text_1: You can unfollow a topic at any time. The topic, its comments and your previous activity within the discussion are not changed.
      text_2: After unfollowing a topic, you will no longer receive notifications based on your follow status for that topic.

documentation:
  commands:
    title: Console Commands
    intro: The Horum console provides commands for the console itself, developer functions, window control, system information, AI, media, and the Horum Core. Commands are entered directly after the console prompt.
    usage:
      title: Using Commands
      text_1: A command consists of the command name and, depending on the command, additional arguments. The input is executed through the current console prompt.
      text_2: The integrated help can display either the complete command overview or information about a specific command.
      help: help: Displays all available commands.
      help_command: help [command]: Displays the description, usage, and additional information for a specific command.
    console:
      title: Console
      text: These commands control basic console functions.
      help: help [command]: Displays all available commands or information about a specific command.
      clear: clear: Clears the visible console content.
    developer:
      title: Developer
      text: Developer commands provide technical tools for analysis, performance measurements, and testing.
      benchmark: benchmark [case] [filter] [/duration]: Starts performance and benchmark tests.
    benchmark:
      title: Benchmark
      text_1: The benchmark command starts performance and benchmark tests directly from the console. Without additional arguments, the OpenGL benchmark runs for 10 seconds.
      text_2: The benchmark case determines which test is executed. OpenGL additionally supports a filter. The desired runtime is specified with a leading slash.
      usage: Syntax: benchmark [case] [filter] [/duration]
      case: Case: Determines the benchmark case to execute, for example cpu, ram, fps, frame_time, or opengl.
      filter: Filter: The OpenGL benchmark can target a specific area such as inner_wave.
      duration: Duration: /20, for example, runs the benchmark for 20 seconds.
    windows:
      title: Windows
      text_1: Window commands control Horum's media lists directly through the console. The desired action is combined with the corresponding window type.
      text_2: The commands can be used with image, video, audio, and document lists.
      open: open <type> list: Opens the corresponding media list.
      close: close <type> list: Closes the corresponding media list.
      refresh: refresh <type> list: Refreshes the content of the corresponding media list.
      pin: pin <type> list: Pins the corresponding media list.
      unpin: unpin <type> list: Removes the pin from the corresponding media list.
      minimize: minimize <type> list: Minimizes the corresponding media list.
      restore: restore <type> list: Restores the corresponding media list.
    window_types:
      title: Available Media Lists
      text: Window commands can be combined with the following list types.
      image: image list: Image list.
      video: video list: Video list.
      audio: audio list: Audio list.
      document: document list: Document list.
    system:
      title: System
      text: System commands provide information about the current state and installed Horum environment.
      status: status: Displays the current runtime status of Horum.
      system: system: Displays information about the system and runtime.
      version: version: Displays the installed Horum version.
    ai:
      title: AI
      text: AI commands provide information about active AI components and their usage.
      model: model: Displays information about the active AI model.
      tokens: tokens: Displays current token usage.
      memory: memory: Displays information about AI memory.
      cache: cache: Displays information about the cache.
      speech: speech: Displays information about voice control.
    media:
      title: Media
      text: Media commands provide access to media information as well as search, sorting, and filtering functions for open media lists.
      paths: paths: Displays the configured media paths.
      media: media: Displays active media.
      search: search <content> [text]: Searches a media list by name.
      sort: sort <content> <mode>: Sorts a media list by name, date, size, or duration.
      filter: filter <content> <filter> [values]: Filters a media list by specific properties.
    search:
      title: Searching Media
      text_1: The search command sets the name search for an open media list. Audio, video, images, and documents are supported.
      text_2: The search text can contain multiple words. If no search text is provided after the content type, the existing search for that media list is cleared.
      usage: Syntax: search <content> [text]
      content: Content: audio, video, image, or document.
      text: Text: The name or search text to find within the selected media list.
    sort:
      title: Sorting Media
      text_1: The sort command changes the sorting of an open media list. Audio, video, images, and documents are supported.
      text_2: Name, date, and size can be sorted for the supported content types. Duration sorting is available exclusively for audio and video.
      usage: Syntax: sort <content> <mode>
      name: Name: Sorts content by name in ascending or descending order.
      date: Date: Sorts content by date in ascending or descending order.
      size: Size: Sorts content by file size in ascending or descending order.
      duration: Duration: Sorts audio or video content by duration in ascending or descending order.
    filter:
      title: Filtering Media
      text_1: The filter command sets filters for an open media list. Audio, video, images, and documents are supported.
      text_2: Filters can be applied by file extension, MIME type, or duration. Duration filters are available exclusively for audio and video and support comparison operators as well as value ranges.
      usage: Syntax: filter <content> <filter> [values]
      extension: extension: Filters by one or more file extensions, for example filter video extension mp4 mkv.
      mime: mime: Filters by one or more MIME types, for example filter document mime application/pdf.
      duration: duration: Filters audio or video using <, <=, >, or >= with a value, or using a minimum and maximum value range.
      clear: Clear filters: filter <content> without another filter removes all filters from the corresponding media list.
    core:
      title: Horum Core
      text: Core commands provide information about central Horum processes and current activities.
      core: core: Displays information about the Horum Core.
      search: search: Displays information about active searches.
      windows: windows: Displays all currently open Horum windows.
    summary:
      title: Summary
      text: The Horum console provides direct text-based control for console functions, benchmarks, windows, system information, AI, media, and the Horum Core. The help command can be used at any time to display the complete command overview or help for an individual command.

documentation:
  console_window:
    title: Console Window
    intro: The Console Window provides the direct text-based interface to the Horum console. It combines output, command input, history, and tracking within its own compact window.
    purpose:
      title: Purpose of the Console Window
      text_1: The Console Window serves as the central interface for working directly with the Horum console. Commands are entered through a prompt and their output is displayed immediately within the same console area.
      text_2: For this purpose, the window connects the visible console interface with separate controllers for input, command processing, and tracking.
    structure:
      title: Structure
      text_1: The Console Window is implemented as a frameless tool window and uses its own compact window structure.
      text_2: Its individual components handle clearly separated tasks within the console.
      titlebar: Title Bar: Contains the console name and the available window actions.
      frame: Console Frame: Provides the content area of the Console Window.
      output: Console Output: Displays console output and simultaneously contains the active prompt for command input.
      controllers: Controllers: Process input, commands, and tracking independently from the visible interface.
    titlebar:
      title: Title Bar
      text_1: The console uses its own compact title bar. It contains the localized window title and the direct actions for the Console Window.
      text_2: The title bar also serves as the area used to move the window.
      pin: Pin: Controls the pin function of the Console Window.
      settings: Settings: Opens or closes the console settings.
      minimize: Minimize: Controls the minimize function of the Console Window.
      close: Close: Requests that the Console Window be closed.
    frame:
      title: Console Frame
      text_1: The Console Frame provides the actual content container of the Console Window. It has no controls of its own and makes the available area fully available to the inserted content.
      text_2: The contained content can be replaced. During normal console operation, the Console Output is inserted into this frame.
    output:
      title: Console Output
      text_1: The Console Output is based on a text area using a monospaced font and forms the visible console interface. New output is inserted at the end of the existing content.
      text_2: The current prompt is also written directly into this area. Previous output, executed commands, and the current input therefore appear together within a single console view.
      startup: Startup Output: When the console is created, the designated startup information and a reference to the help command are displayed.
      prompt: Prompt: After the startup output and after executed commands, a new prompt is provided for the next input.
      scroll: Scrolling: The console provides a vertical scrollbar and keeps the text cursor visible when new output is written.
      clear: Clear: The visible console content can be completely cleared and then continued with a new prompt.
    input:
      title: Command Input
      text_1: Active command input takes place directly after the current prompt within the Console Output. The Input Controller monitors keyboard input inside the console.
      text_2: Previously displayed console content and the prompt are protected from the current input so that the user cannot accidentally write back into older console areas.
      enter: Enter: Accepts the current input and submits it as a command for further processing.
      history: Up and Down arrows: Navigate through previous commands stored during the current console session.
      protection: Input Protection: Backspace and the Left arrow cannot move the cursor before the beginning of the current prompt.
    controllers:
      title: Controllers
      text_1: Console processing is divided between several controllers. This keeps presentation, input behavior, command processing, and tracking separated from each other.
      text_2: The Console Window creates these controllers and connects them to the shared Console Output.
      input: Input Controller: Processes keyboard input, command submission, and command history.
      command: Command Controller: Processes console commands and passes additional supported commands to the Horum command system.
      tracking: Tracking Controller: Writes enabled tracking events to the console output together with their respective category.
    command_history:
      title: Command History
      text_1: Executed non-empty inputs are stored in a command history within the Console Window. The history can be navigated directly using the arrow keys.
      text_2: During navigation, the current input area after the prompt is replaced with the selected previous command. Moving beyond the newest entry returns to an empty input.
    window_behavior:
      title: Window Behavior
      text_1: The Console Window is used as a frameless tool window within Horum and starts with a size of 700 × 500 pixels.
      text_2: Dedicated controllers handle moving, pinning, and minimizing the window. The corresponding actions are provided through the compact title bar.
    settings_window:
      title: Console Settings
      text_1: The Settings button opens a dedicated settings window for the console. If this window is already visible, the same action closes it again.
      text_2: The settings window receives the Tracking Controller of the current console and is positioned relative to the Console Window. The individual settings and tracking categories are documented separately under Settings & Tracking.
    summary:
      title: Summary
      text: The Console Window combines a compact window interface with the Console Frame, Console Output, and separate controllers for input, commands, and tracking. Commands are entered directly through the prompt, can be recalled through the history, and appear together with their generated output within the same console view.

documentation:
  overview:
    title: Console
    intro: The Horum console is a direct text-based interface for commands, status output, tracking, and controlling various Horum functions. It can be used by both the user and Horum itself to perform actions within the system.
    purpose:
      title: Purpose of the Console
      text_1: The console connects traditional command input with Horum functions. Commands can be used to retrieve information, run developer functions, work with media, and control windows.
      text_2: In addition, the console can make selected Horum activities visible through Console Tracking, providing direct insight into ongoing processes.
    user_horum:
      title: User and Horum
      text_1: Console commands are not intended exclusively for manual input by the user. Horum can also use these functions to perform corresponding actions itself.
      text_2: The commands therefore form a shared control interface. Horum can, for example, open an audio, video, image, or document list when requested, while the same action can also be triggered directly through the console.
      user: User: Can enter commands directly through the console prompt to execute Horum functions.
      horum: Horum: Can use the same functions for its own actions, for example to open or control required media windows.
    console_window:
      title: Console Window
      text_1: The console has its own compact window with a title bar, Console Frame, and Console Output. Input and generated output are displayed within the same console view.
      text_2: The Console Window also provides direct window actions and access to the Console Tracking settings.
    commands:
      title: Command Areas
      text_1: The available console commands are organized according to their respective purpose. This allows both basic console actions and functions from other Horum areas to be accessed through the same interface.
      text_2: A complete description of the individual commands, their syntax, and their arguments is available on the Console Commands page.
      console: Console: Basic functions such as help and clearing the console output.
      developer: Developer: Technical functions such as performance and benchmark tests.
      windows: Windows: Open, close, refresh, pin, minimize, and restore media lists.
      system: System: Information about the state, runtime, and installed Horum version.
      ai: AI: Information about the model, token usage, memory, cache, and voice control.
      media: Media: Media paths, active media, search, sorting, and filtering.
      core: Horum Core: Information about the Core, active searches, and open Horum windows.
    media_windows:
      title: Media Windows
      text_1: An important use of the console is controlling Horum's four media lists. They provide the discovered media in dedicated compact windows.
      text_2: The media windows can be opened and controlled both through direct console commands entered by the user and by Horum itself.
      audio: Audio: Displays discovered audio files and provides information such as file size, details, and duration for further selection and playback.
      video: Video: Displays discovered video files with previews and additional file information and makes them available for selection and playback.
      image: Images: Displays discovered image files with previews and information such as file name, size, resolution, and file extension.
      document: Documents: Displays discovered document files with information such as file name, MIME type, size, and file extension.
    media_access:
      title: Media Access
      text_1: The media lists use the media paths configured and authorized in Horum. The supported file formats for audio, video, images, and documents are taken into account.
      text_2: When searching for media, configured folders can be scanned directly or recursively including their subfolders. Matching files are then made available to the corresponding media list.
    media_control:
      title: Controlling Media Windows
      text_1: Media lists can not only be opened through the console but can also be controlled while they are in use. The same actions are available for audio, video, image, and document lists.
      text_2: This allows both the user and Horum to display, refresh, and manage the required media windows depending on the current task.
      open: Open: Opens the requested audio, video, image, or document list.
      close: Close: Closes the corresponding media list.
      refresh: Refresh: Reloads the content of the corresponding media list.
      pin: Pin: Pins a media list or removes its pin again.
      minimize: Minimize: Minimizes the corresponding media list.
      restore: Restore: Restores a previously minimized media list.
    mini_windows:
      title: Mini Windows
      text_1: The audio, video, image, and document lists are displayed as compact Mini Windows within Horum. This allows media information to be provided without requiring a large separate main window.
      text_2: At this point, Mini Windows are only covered in relation to the console and media lists. Their structure, operation, and the specific characteristics of the four individual media windows are documented separately.
    tracking:
      title: Console Tracking
      text_1: In addition to direct command execution, the console can make selected Horum activities visible. Several tracking categories are available for this purpose.
      text_2: Which categories are allowed to write their events to the console can be configured individually under Settings & Tracking.
    architecture:
      title: Shared Interface
      text_1: The console is therefore more than a purely manual command line. It connects user input, Horum actions, media windows, status output, and tracking through a shared text-based interface.
      text_2: The user can deliberately trigger functions through commands, while Horum can use the same functions whenever they are required for the current task.
    summary:
      title: Summary
      text: The Horum console combines direct commands, tracking, and control of additional Horum functions. It is not limited to the user: Horum can also use its functions, for example to open and control audio, video, image, and document lists as Mini Windows.

documentation:
  settings:
    title: Settings & Tracking
    intro: The console settings control which Horum activities and events are displayed directly within the console. Each tracking category can be enabled or disabled independently.
    purpose:
      title: Purpose of Console Settings
      text_1: Console Tracking makes it possible to follow selected internal Horum activities directly within the console while the application is running.
      text_2: This determines which areas are allowed to write additional status and tracking output to the console.
    access:
      title: Opening Settings
      text_1: The tracking settings are opened using the Settings button in the title bar of the Console Window.
      text_2: The settings window is positioned within the console and can be closed again using the same Settings button or the Close button.
    tracking:
      title: Tracking Categories
      text_1: Each tracking category has its own checkbox and can be enabled or disabled independently from the other categories.
      text_2: Enabled categories are allowed to write corresponding events to the console output.
      responses: Responses: Tracks events and information related to responses.
      windows: Windows: Tracks events and information related to windows.
      tokens: Tokens: Tracks events and information related to token usage.
      searches: Searches: Tracks events and information related to search operations.
      model: Model: Tracks events and information related to the AI model being used.
      memory: Memory: Tracks events and information related to AI memory.
      media: Media: Tracks events and information related to media.
      system: System: Tracks events and information related to system operations.
    defaults:
      title: Default Settings
      text_1: When the Tracking Controller is created, three categories are enabled by default.
      text_2: The remaining tracking categories are initially disabled and can be enabled individually when required.
      responses: Responses: Enabled by default.
      windows: Windows: Enabled by default.
      tokens: Tokens: Enabled by default.
      optional: Searches, Model, Memory, Media, and System: Disabled by default.
    behavior:
      title: Immediate Activation
      text_1: Changes to a checkbox are passed directly to the Tracking Controller. No additional Save button is required.
      text_2: When a category is disabled, tracking output for that category is not written to the console. When enabled, corresponding events can be displayed again.
    output:
      title: Tracking Output
      text_1: Active tracking events are written directly to the Console Output. The corresponding tracking category is displayed as a label before the actual message.
      text_2: If a category is disabled, the Tracking Controller ignores corresponding tracking messages and produces no console output for them.
    window:
      title: Tracking Window
      text_1: The tracking settings are displayed in a compact window with a fixed size of 280 × 340 pixels. The available checkboxes are generated from the categories of the current Tracking Controller.
      text_2: When closed, the settings window is removed and the console Settings button returns to its normal state.
    summary:
      title: Summary
      text: Settings & Tracking provides precise control over which Horum activities are tracked within the console. Responses, Windows, and Tokens are enabled by default, while Searches, Model, Memory, Media, and System can be enabled when required.

documentation:
  cursor_management:
    title: Cursor Management
    intro: Cursor Management provides Horum with custom cursors for different interactions with the user interface. This allows selectable elements, text input, restricted areas, and resizing operations to be represented directly by the appropriate cursor.
    purpose:
      title: Purpose of Cursor Management
      text_1: The CursorManager provides the different cursors centrally for the Horum interface. Components therefore do not need to load or create their cursors individually.
      text_2: Each supported interaction has its own cursor, which can be retrieved through the corresponding CursorManager function.
    cursors:
      title: Available Cursors
      text_1: Horum uses eight custom cursors for different interface states and interactions.
      text_2: Each cursor has a distinct meaning and immediately indicates which interaction is available at the current position.
      arrow: Arrow: Default cursor for regular areas and elements without a special interaction.
      pointer: Pointer: Indicates a selectable or clickable element.
      text: Text: Indicates an area in which text can be entered or edited.
      forbidden: Forbidden: Indicates that the corresponding action or editing operation is not permitted at this position.
      resize_horizontal: Horizontal Resize: Indicates that an element can be resized horizontally.
      resize_vertical: Vertical Resize: Indicates that an element can be resized vertically.
      resize_diagonal_45: Diagonal Resize 45°: Indicates diagonal resizing in the corresponding direction.
      resize_diagonal_90: Diagonal Resize 90°: Indicates resizing along the opposite diagonal direction.
    hotspots:
      title: Cursor Hotspots
      text_1: The hotspot determines the exact point of a cursor image at which the actual mouse position is located. This ensures that the visible cursor position corresponds to the intended interaction point.
      text_2: Arrow and Pointer use specifically defined hotspots. Text, Forbidden, and Resize cursors use the center of the cursor image as their hotspot.
    loading:
      title: Loading Cursors
      text_1: The custom cursors are loaded as PNG files from Horum's central cursor directory and then created as usable cursor objects.
      text_2: The images are scaled to a cursor size of 24 × 24 pixels. Their aspect ratio is preserved and smooth transformation is used during scaling.
    cache:
      title: Cursor Cache
      text_1: Cursors that have already been loaded successfully are stored by the CursorManager in an internal cache.
      text_2: When the same cursor is required again, the existing cursor instance can be used instead of loading and processing the corresponding image file again.
    fallback:
      title: Qt Fallback
      text_1: A corresponding standard Qt cursor is additionally defined for each custom Horum cursor.
      text_2: If the intended PNG file cannot be found, the CursorManager automatically uses this fallback. This ensures that an appropriate cursor remains available for the respective interaction.
    summary:
      title: Summary
      text: Cursor Management provides Horum's cursors from one central system. Eight different cursors represent regular interaction, selectable elements, text input, restricted actions, and horizontal, vertical, and diagonal resizing. Caching, defined hotspots, and Qt fallbacks complement the central cursor management system.

documentation:
  window_actions:
    title: Window Actions
    intro: Window Actions control the behavior of Horum windows. This includes standard window functions such as minimizing, maximizing, and closing, as well as moving, resizing, and automatically snapping windows.
    purpose:
      title: Purpose of Window Actions
      text_1: Horum uses its own window controls for its user interfaces. Regular windows and compact mini windows each provide the actions intended for their respective purpose.
      text_2: In addition to the visible buttons, window control also includes dragging through the title bar, resizing through the window borders, and the Snap system.
    normal:
      title: Regular Windows
      text_1: Regular Horum windows use custom buttons for their basic window actions.
      text_2: The maximize button adapts to the current window state and changes to the restore action when the window is maximized.
      minimize: Minimize: Minimizes the window using the normal system behavior.
      maximize: Maximize: Expands the window to the available screen area.
      restore: Restore: Returns a maximized window to its normal window size.
      close: Close: Closes the corresponding Horum window.
    mini:
      title: Mini Windows
      text_1: Mini windows use a compact variant of the window actions. The available actions are designed for operating these smaller Horum interfaces.
      text_2: The mini variant uses its own icons so that its actions remain directly recognizable within a compact interface.
      minimize: Minimize: Minimizes the mini window.
      close: Close: Closes the mini window.
      pin: Pin: Controls the pin function of the mini window.
      refresh: Refresh: Executes the refresh function of the mini window.
      settings: Settings: Opens the settings function provided for the mini window.
    drag:
      title: Moving Windows
      text_1: Windows can be moved through their designated title bar by holding the left mouse button. The window position follows the movement of the mouse pointer.
      text_2: Double-clicking the drag area with the left mouse button toggles the maximized state of the window.
    snap:
      title: Snap
      text_1: While a window is being moved, Horum monitors its position relative to the available screen area. When the mouse pointer is within 24 pixels of a supported screen edge, the corresponding Snap mode is activated.
      text_2: When the window is released within this area, Horum automatically applies the intended window position and size.
      top: Top screen edge: The window is maximized.
      left: Left screen edge: The window is positioned on the left half of the available screen area.
      right: Right screen edge: The window is positioned on the right half of the available screen area.
    snap_preview:
      title: Snap Preview
      text_1: As soon as a valid Snap area is detected while moving a window, Horum displays a preview of the future window position.
      text_2: The preview is displayed over the intended area, does not receive mouse events itself, and does not activate an additional window. When the mouse pointer leaves the Snap area again, the preview is hidden.
    restore_drag:
      title: Dragging Out of Snap and Maximized States
      text_1: A maximized or side-snapped window can be dragged directly out of that state. Horum restores the previously stored normal window geometry in the process.
      text_2: The position is adjusted according to the current mouse position so that the restored window can immediately continue moving underneath the mouse pointer.
    resize:
      title: Resizing Windows
      text_1: Regular windows contain invisible resize areas along all four sides and at all four corners. Using one of these areas allows the window size to be changed with the mouse.
      text_2: Depending on the active edge or corner, Horum uses the appropriate resize cursor and changes the window geometry in the corresponding direction.
      horizontal: Horizontal: The left and right window edges change the width of the window.
      vertical: Vertical: The top and bottom window edges change the height of the window.
      diagonal: Diagonal: The four window corners allow width and height to be changed at the same time.
    titlebar:
      title: Title Bar
      text_1: Horum's custom title bar combines the window title, Horum logo, window buttons, and drag controls within a single interface.
      text_2: Minimize, maximize, and close actions are triggered through their corresponding buttons, while the title bar simultaneously acts as the drag area for moving and snapping the window.
    summary:
      title: Summary
      text: Window Actions provide the central controls for Horum windows. Regular and compact mini windows use their own action icons, while drag, resize, and Snap provide direct mouse-based window control. The Snap system supports maximizing as well as positioning a window on the left or right half of the screen and previews the future position while the window is being moved.

documentation:
  window_management:
    title: Window Management
    intro: Window Management provides the shared technical foundation for the different windows used by Horum. It organizes window structures, instances, states, geometries, and the lifecycle of the different window types.
    purpose:
      title: Purpose of Window Management
      text_1: Horum uses different window types for main application areas, tools, and dynamically generated interfaces. Window Management provides shared structures for these systems and coordinates their respective window instances.
      text_2: Direct user interactions such as minimizing, maximizing, moving, resizing, and snapping are documented separately under Window Actions.
    types:
      title: Window Types
      text_1: Horum distinguishes between several window systems designed for different tasks within the application.
      text_2: These systems have different structures and behaviors and are therefore not treated as a single window type.
      app_window: App Window: Shared foundation for Horum's large application windows.
      mini_window: Mini Window: Compact frameless tool windows with their own title bar and controllers.
      horum_window: Horum Window: Dynamic windows for Work UI and Result UI with their own presentation and window states.
    app_window:
      title: App Window
      text_1: The App Window provides the shared window foundation for Horum's major application areas. It uses a custom title bar, a central content area, and the shared window controls.
      text_2: Several central Horum windows are built directly on this shared foundation.
      main: Horum Main Window: Provides the central application interface and manages additional Horum windows.
      settings: Settings: Uses the App Window as the foundation for the settings interface.
      marketplace: Marketplace: Uses the App Window as the foundation for the Marketplace interface.
      commander: Commander: Uses the App Window as the foundation for the Commander interface.
    structure:
      title: Shared Window Structure
      text_1: App Windows use a shared base structure on which the individual application areas build their own content.
      text_2: This allows different areas to use their own interfaces while keeping the underlying window architecture consistent.
      titlebar: Title Bar: Provides the window title and the basic window controls.
      content: Content Area: Contains the actual interface of the respective application window and can be replaced with the required content.
      resize: Window Border: Provides the areas and controllers used to resize the window.
    loader:
      title: Window Loader
      text_1: The Window Loader handles opening larger application windows. If the requested window instance already exists, it is shown and raised instead of creating another instance.
      text_2: If no instance exists yet, the corresponding window is created and stored on the main window under its designated window attribute. A loading indicator can be displayed during this process.
    instances:
      title: Window Instances
      text_1: The Horum main window keeps references to central additional windows. This makes it possible to determine whether a window already exists and should be reused or needs to be created.
      text_2: Each window therefore remains accessible through its corresponding reference.
      settings: Settings: Managed through the stored Settings Window instance.
      marketplace: Marketplace: Managed through the stored Marketplace Window instance.
      commander: Commander: Managed through the stored Commander Window instance.
      console: Console: Also has its own window reference and is shown or hidden through the main window.
    lifecycle:
      title: Window Lifecycle
      text_1: When opening a window, Horum first checks whether the required window instance already exists. Existing windows can be shown again and raised without recreating their entire interface.
      text_2: When closing, windows can release their connection to the main window and reset their stored reference. When the main window is closed, managed application areas are closed and released.
    geometry:
      title: Window Geometry
      text_1: The shared window foundation manages the normal window geometry and can store it before a window is maximized. This preserves the previous size and position for later restoration.
      text_2: App Windows can also be centered within the available area of the primary screen. Individual application windows can initially inherit the geometry of the main window and then define their own size and position.
    child_windows:
      title: Child Windows
      text_1: Some application areas can contain their own child App Windows. These windows belong to their respective parent area and are managed together with it.
      text_2: Commander and Marketplace close their direct child App Windows when their respective main window is closed. This prevents associated child windows from remaining open independently.
    mini_windows:
      title: Mini Windows
      text_1: Mini Windows form a separate compact window system within Horum. They are frameless tool windows with their own title bar, content frame, and controllers for their window functions.
      text_2: The Mini Window structure separates drag, pin, minimize, and refresh behavior into dedicated controllers. Content can be inserted independently into the designated Window Frame.
    horum_windows:
      title: Horum Windows
      text_1: Horum Windows are designed for dynamic Work UI and Result UI. When a window is created, its intended UI type is defined as one of these two types.
      text_2: These windows use their own window, widget, and font styles as well as the Focus and Inactive states. Their height can automatically adapt to the required content, while their width is defined by the loaded Window Style.
    summary:
      title: Summary
      text: Window Management organizes Horum's different window systems and their lifecycle. App Windows provide the shared foundation for major application areas, Mini Windows provide compact tool windows, and Horum Windows handle dynamic Work UI and Result UI. Window instances, content, geometries, and child windows are managed according to their respective purpose.

documentation:
  animations:
    title: Animations
    intro: The animation system controls the movement and dynamic behavior of the individual Horum Core layers. The layers are updated independently and then rendered together using OpenGL.
    system:
      title: Core Animation System
      text_1: The Horum Core consists of several independent layers, each managing its own animations and states.
      text_2: This allows different movements to run simultaneously and be combined into a single Core visualization.
      list_1: Core Orb: Central element with pulse and eye animations.
      list_2: Inner Wave: Animated inner wave structure.
      list_3: Middle Ring: Animated middle ring representing processing and activity.
      list_4: Outer Wave: Animated outer wave structure.
    layers:
      title: Independent Layers
      text: Each Core layer maintains its own update and rendering state. Enabled layers are updated individually and then composed within the same rendering process.
      list_1: CoreOrbLayer manages the movement of the central Core.
      list_2: InnerWaveLayer manages the animation of the inner wave.
      list_3: MiddleRingLayer manages the movement of the middle ring.
      list_4: OuterWaveLayer manages the animation of the outer wave.
    update:
      title: Time-Based Updates
      text_1: The animations are updated based on time. The elapsed time between two updates is calculated and passed to the active layers as delta time.
      text_2: This means movement calculations are based on the actual elapsed time rather than exclusively on the number of frames that have already been rendered.
      list_1: The Core calculates the elapsed time between two updates.
      list_2: Each enabled layer receives the current delta time for its animation calculations.
      list_3: After the layers have been updated, the Core visualization is rendered again.
    orb:
      title: Core Orb
      text_1: The Core Orb has its own idle animations, keeping it visually active even when Horum is not processing a request or producing voice output.
      text_2: Heartbeat and eye movement are calculated independently and create the characteristic movement of the central Core.
      list_1: Heartbeat: Creates a recurring pulse movement and influences the appearance of the Core and its glow effects.
      list_2: Eye Movement: The viewing direction changes at varying intervals and moves smoothly between the previous and newly determined position.
    activity:
      title: Activity and Response
      text: In addition to idle movement, the other layers can visually represent different activities of Horum.
      list_1: Middle Ring: Its movement is used to represent processing, understanding, and thinking.
      list_2: Inner Wave: Represents the inner dynamic wave movement of the Core and is used to visualize high tones during voice output.
      list_3: Outer Wave: Represents the outer dynamic wave movement of the Core and is used to visualize low tones during voice output.
    rendering:
      title: OpenGL Rendering
      text_1: After each update, the active Core layers are rendered using OpenGL. Horum uses its own OpenGL context and an offscreen surface for this process.
      text_2: The generated image is then transferred to Horum's graphical interface. This keeps the Core's calculation and rendering process separated from its actual presentation within the user interface.
    performance:
      title: Performance and System Requirements
      text_1: Animations require continuous updates and repeated calculation of the Core visualization. The Core uses a recurring rendering cycle and relies on OpenGL for graphical processing.
      text_2: Core animation therefore depends on the available graphics performance and functioning OpenGL support provided by the system and graphics driver.
      list_1: The Core timer currently uses a frame interval of 33 milliseconds.
      list_2: Enabled layers are updated during every animation cycle and then rendered again.
      list_3: The OpenGL support required by Horum must be available through the system and graphics driver.
    separation:
      title: Separation of Animation, Geometry, and Color
      text_1: The animation system defines the movement behavior of the Core, while geometry and colors are handled as separate areas.
      text_2: An animation can therefore be combined with different geometries and color systems without mixing their fundamental responsibilities.
    settings:
      title: Configuration
      text: The actual adjustment of animation behavior is handled through the corresponding area of the Horum settings. The available values and controls are therefore documented under Settings → Core Animation.
    summary:
      title: Summary
      text: The animation system updates the individual Core layers based on time and combines their movements within a continuously rendered OpenGL Core. Idle movement, processing, and voice output can therefore be represented through different visual layers.

documentation:
  colors:
    title: Colors
    intro: The color system defines the visual appearance of the individual layers of the Horum Core. Colors are not handled as a single global element but are assigned separately to the different Core components and their effects.
    system:
      title: Core Color System
      text_1: The Horum Core consists of several independently rendered layers. Each layer uses its own color values for its respective elements and effects.
      text_2: This allows central elements, rings, waves, and glow effects to be displayed differently while together forming the complete appearance of the Core.
      list_1: Core Orb: Colors for the center, ring, halo, and multiple glow layers.
      list_2: Inner Wave: Colors for the inner wave structure and its glow effects.
      list_3: Middle Ring: Colors for the visual representation of the middle ring.
      list_4: Outer Wave: Colors for the outer wave structure and its glow effects.
    layers:
      title: Separate Color Layers
      text: The color values are used directly by the respective Core layers. This allows the visual layers to be rendered independently and then combined into a single presentation.
      list_1: CoreOrbLayer: Central Core element with multiple separate color and glow areas.
      list_2: InnerWaveLayer: Inner wave with its own ring and effect colors.
      list_3: MiddleRingLayer: Middle ring as an independent visual layer.
      list_4: OuterWaveLayer: Outer wave with its own ring and effect colors.
    rendering:
      title: Color Processing During Rendering
      text_1: Stored color values are converted into RGB values for rendering and used within the respective Core layers.
      text_2: During rendering, colors can be blended and modified according to intensity and transparency. This creates dynamic transitions and glow effects instead of exclusively static color surfaces.
      list_1: RGB values determine the color components of the rendered elements.
      list_2: Alpha values control the transparency of individual surfaces and effects.
      list_3: Color blending and intensity values create dynamic transitions and glows.
    glow:
      title: Glow and Transparency
      text_1: Glow effects are built from multiple rendered areas with different dimensions, intensities, and transparency levels. This creates the soft glow surrounding the respective Core elements.
      text_2: For the wave structures, the visible intensity additionally changes with their current amplitude. Color, movement, and transparency therefore work together during rendering.
    gpu:
      title: GPU and OpenGL
      text_1: The Core visualization uses OpenGL. Horum creates its own OpenGL context and renders the Core layers through an offscreen surface before displaying the generated image in the interface.
      text_2: The Core therefore introduces a graphics system requirement. The system and its graphics driver must provide the OpenGL support required by Horum.
      list_1: OpenGL 2.1 is requested using the Compatibility Profile.
      list_2: 4x multisampling is requested for the Core visualization.
      list_3: An alpha buffer is used for transparency and the composition of the visual layers.
    separation:
      title: Separation of Color, Geometry, and Animation
      text_1: Colors form an independent part of the Core system. They define its visual coloring without determining the geometric shape or movement behavior of the Core layers.
      text_2: Geometry, animation, and colors can therefore be structured independently and then combined within the same Core visualization.
    settings:
      title: Configuration
      text: The actual selection and modification of Core colors is handled through the corresponding area of the Horum settings. The available controls and configuration options are therefore documented under Settings → Core Colors.
    summary:
      title: Summary
      text: The Horum Core color system uses separate color values for its different layers and effects. Colors, transparency, blending, and glow are combined during OpenGL rendering, while geometry and animation remain independent parts of the Core system.

documentation:
  geometry:
    title: Geometry
    intro: The geometry system defines the spatial structure of the Horum Core. It determines sizes, radii, distances, and other geometric properties used to construct the individual Core layers and render them through OpenGL.
    system:
      title: Core Geometry System
      text_1: Each layer of the Horum Core has its own geometric structure. Geometry values define the fundamental shape and position of the visible elements.
      text_2: The individual layers use these values independently and are then composed into the complete Core visualization.
      list_1: Core Orb: Defines the size and spatial extent of the central Core.
      list_2: Inner Wave: Defines the position and base radius of the inner wave structure.
      list_3: Middle Ring: Defines the position and dimensions of the middle ring.
      list_4: Outer Wave: Defines the position and base radius of the outer wave structure.
    layers:
      title: Layer Geometry
      text: The layers use separate geometry values and can therefore have different sizes and distances even though they are rendered within the same Core area.
      list_1: CoreOrbLayer forms the geometric center of the visualization.
      list_2: InnerWaveLayer creates a circular wave structure within the outer areas of the Core.
      list_3: MiddleRingLayer forms an independent ring between the other Core layers.
      list_4: OuterWaveLayer creates the outer circular wave structure.
    coordinates:
      title: Coordinates and Center
      text_1: The Core layers are positioned within a shared rendering area. The center of this area serves as the reference point for the circular elements and their radii.
      text_2: Starting from this center point, positions are calculated along a complete circle. This allows rings, waves, and other elements to be arranged evenly around the center of the Core.
    radii:
      title: Radii and Distances
      text: Radii form a central foundation of the Core geometry. They determine how far an element is positioned from the center and how the individual layers are spatially arranged in relation to each other.
      list_1: Base radii define the fundamental position and size of circular Core elements.
      list_2: Inner and outer radii determine the width and extent of rings and wave structures.
      list_3: Additional distances and extensions provide spatial separation between the Core, rings, waves, and glow effects.
    segments:
      title: Segmentation
      text_1: Circular and wave-shaped elements are constructed from individual segments. Positions along the circumference are calculated for these segments and then connected to form the visible geometry.
      text_2: Segmentation therefore affects the geometric resolution of a structure. A larger number of segments allows finer circular and wave shapes but also increases the number of geometric elements that must be processed during rendering.
    dynamic:
      title: Dynamic Geometry
      text_1: Geometry provides the base shape of a Core layer, but it does not have to remain static during visualization. Animations can influence geometric values at runtime.
      text_2: This allows moving and changing shapes to be created from a defined base geometry.
      list_1: The Core Orb can change its visible radius during the pulse animation.
      list_2: Wave values modify the calculated radii of the Inner Wave and Outer Wave.
      list_3: Movement and states can dynamically influence the position or extent of visible Core elements.
    rendering:
      title: Geometry in OpenGL Rendering
      text_1: The calculated geometric values are converted into visible surfaces and structures during OpenGL rendering. Positions along circular shapes are calculated from angles, radii, and the corresponding sine and cosine values.
      text_2: The resulting points are connected to form the required geometric surfaces and rendered together with colors, transparency, and additional effects.
    performance:
      title: Geometry and Performance
      text_1: The complexity of the Core geometry affects the rendering workload. Segmented waves and additional effect surfaces in particular create a larger number of geometric calculations and elements that must be rendered.
      text_2: Because geometry in animated areas is continuously recalculated and rendered through OpenGL, geometric complexity and graphics performance together affect the presentation of the Core.
    separation:
      title: Separation of Geometry, Animation, and Color
      text_1: Geometry defines the fundamental shape and spatial arrangement of the Core. Animations determine how these structures move or change, while colors define their visual appearance.
      text_2: This separation allows the same geometric base structure to be combined with different animations and color systems.
    settings:
      title: Configuration
      text: The actual adjustment of geometric Core values is handled through the corresponding area of the Horum settings. The available values and controls are therefore documented under Settings → Core Geometry.
    summary:
      title: Summary
      text: The geometry system forms the spatial foundation of the Horum Core. Radii, distances, positions, and segmentation define the base shapes of the individual layers, which can be dynamically modified by animations and then rendered through OpenGL.

documentation:
  license:
    title: License
    intro: The License section shows your current Horum plan, its included features and limits, as well as the differences between Free, Personal and Premium. You can also upgrade or downgrade your plan directly from here.
    current:
      title: Your Current Plan
      text_1: Your currently active Horum plan is highlighted directly in the plan overview and marked as the active plan. This allows you to immediately see which license is currently associated with your account.
      text_2: All three plans are displayed side by side so you can directly compare their included features and limits.
    free:
      title: Free – Free of Charge
      text: Free includes the essential features for getting started with Horum. Some features and resources are limited compared with the paid plans.
      list_1: API AI Providers – All
      list_2: Local AI Models – 1
      list_3: Local AI Generators – 1
      list_4: Products – 2
      list_5: Standard Voices – 2
      list_6: Premium Voices – Not available
      list_7: Voice Styles – Not available
      list_8: Rules – 10
      list_9: Forbidden Rules – 10
      list_10: Memory Categories – 5
      list_11: Paths per Category – 1
      list_12: Personality System – Yes
      list_13: Voice Input – Yes
      list_14: Voice Output – Yes
      list_15: Custom Form of Address – Learns automatically
      list_16: Developer Area – Not available
      list_17: Export / Import – Not available
    personal:
      title: Personal – CHF 5.90 / Month
      text: Personal extends Horum for productive everyday use and increases both the available resources and the overall feature set.
      list_1: API AI Providers – All
      list_2: Local AI Models – 3
      list_3: Local AI Generators – 5
      list_4: Products – 5
      list_5: Standard Voices – 2
      list_6: Premium Voices – 5
      list_7: Voice Styles – All
      list_8: Rules – 25
      list_9: Forbidden Rules – 25
      list_10: Memory Categories – 15
      list_11: Paths per Category – 4
      list_12: Personality System – Yes
      list_13: Voice Input – Yes
      list_14: Voice Output – Yes
      list_15: Custom Form of Address – Yes
      list_16: Developer Area – Yes
      list_17: Export / Import – Yes
    premium:
      title: Premium – CHF 12.90 / Month
      text: Premium provides the full Horum feature set and removes many of the limitations of the other plans.
      list_1: API AI Providers – All
      list_2: Local AI Models – Unlimited
      list_3: Local AI Generators – Unlimited
      list_4: Products – 10
      list_5: Standard Voices – 2
      list_6: Premium Voices – All
      list_7: Voice Styles – All
      list_8: Rules – Unlimited
      list_9: Forbidden Rules – Unlimited
      list_10: Memory Categories – Unlimited
      list_11: Paths per Category – Unlimited
      list_12: Personality System – Yes
      list_13: Voice Input – Yes
      list_14: Voice Output – Yes
      list_15: Custom Form of Address – Yes
      list_16: Developer Area – Yes
      list_17: Export / Import – Yes
    change:
      title: Change Your Plan
      text_1: You can change your Horum plan directly from the License overview. The available action depends on your currently active plan.
      list_1: Upgrade – switch from a lower plan to a higher plan.
      list_2: Downgrade – switch from a higher plan to a lower plan.
      list_3: Active Plan – your currently used plan is clearly marked and cannot be selected again.
      text_2: Before changing your plan, you can directly compare the features and limits of all three plans and choose the plan that best suits your usage.
    summary:
      title: Your Plan Defines Your Feature Set
      text: Free, Personal and Premium differ in their available resources, limits and advanced features. The License overview always shows which plan you are currently using and which options are available through an upgrade or downgrade.

documentation:
  my_horum:
    title: My Horum
    intro: My Horum provides a central overview of your Horum installation, available components, purchased packages and their current status.
    overview:
      title: Your Horum at a Glance
      text_1: The upper section summarizes important information and statistics about your Horum. This allows you to quickly see which content and components are available to you.
      list_1: Installed Horum version and version date
      list_2: Number of available conversations and newly added conversations
      list_3: Available Horum components and extensions
      list_4: Status of your purchased, available, installed, not installed and removed packages
      text_2: The displayed values are based on your account and the Horum content associated with it.
    components:
      title: Horum Components
      text: The overview distinguishes between the different types of content that can be used to extend and customize Horum:
      list_1: Personalities – define Horum's character, behavior, rules and other personal characteristics.
      list_2: Horum Windows – provide additional interfaces and windows for Horum.
      list_3: Worker UIs – provide interfaces through which Horum can perform tasks and workflows.
      list_4: Result UIs – present results and content in dedicated interfaces.
      list_5: Cores – change or extend the visual appearance of the Horum core.
      list_6: Commands – extend Horum with additional commands and capabilities.
      list_7: Complete packages – combine multiple Horum components within a single package.
      list_8: Documentation – user-created documentation will also be integrated into My Horum and will become available as a dedicated area once introduced.
    packages:
      title: Package Status
      text_1: Your acquired packages are separated according to their current state. This allows you to immediately see which content can already be used and which packages still require an action.
      list_1: Purchased – all packages assigned to your account through a purchase or acquisition.
      list_2: Available – packages for which a download is available.
      list_3: Installed – packages that have already been installed in your Horum installation.
      list_4: Not installed or removed – packages that are currently not installed or have been removed from your installation.
      text_2: A removed package remains associated with your account and can be downloaded or installed again as long as it remains available.
    library:
      title: Your Purchased Content
      text_1: Under “Purchased”, you can find the packages associated with your Horum account. Product cards display information such as the package type, supported file types, purchase date and current status.
      text_2: You can narrow down your content using search, status filters and package types. You can also change the order of displayed packages using the sorting options.
    documents:
      title: Your Own Documentation
      text_1: My Horum includes a dedicated area for your documentation. In addition to installable components and Marketplace packages, your own documentation content can be managed centrally through Horum.
      text_2: Your documentation is associated with your Horum account and is available alongside your other Horum content in My Horum.
    actions:
      title: Manage Packages
      text: Depending on the current status of a package, different actions are available directly from its product card:
      list_1: Download available packages.
      list_2: Install downloaded packages or manage content that has already been installed.
      list_3: Rate a purchased product when ratings are available for that product.
    rating:
      title: Rate a Product
      text_1: After a purchased package has been installed, the associated product can be rated directly through “My Horum”.
      text_2: The rating is set using a slider and uses a star rating system from 1.0 to 5.0. Intermediate values are supported.
      list_1: Rating range – 1.0 to 5.0 stars.
      list_2: Intermediate values – ratings such as 1.2, 3.9 or 4.7 are supported.
      list_3: Slider – the desired rating value is selected using a slider.
      list_4: Comment – a comment about the product can be submitted together with the star rating.
      text_3: The rating and its associated comment are assigned to the rated product on the Horum Marketplace.
    summary:
      title: Your Personal Horum Library
      text: My Horum combines an overview of your Horum components with your personal package library. This gives you one central place to see which content belongs to your account, which packages are available or installed and which extensions you can use with your Horum.

documentation:
  dashboard_overview:
    title: Dashboard Overview
    intro: The Dashboard is your central management area on the Horum website. The Overview page shows the most important information about your account, license, Wallet, products and Horum version at a glance.
    dashboard:
      title: The Dashboard
      text_1: The Dashboard allows you to manage the central areas of your Horum account and provides access to your personal information, Horum content, license, finances and products.
      text_2: The individual areas are available through the Dashboard navigation and each provide different functions.
      list_1: Overview – shows the most important account and Horum information as well as your latest activities.
      list_2: Profile – manages your personal information, profile picture and stored company information.
      list_3: My Horum – shows your Horum version, conversations, components, packages and your own documentation.
      list_4: License – shows your current Horum plan and the features and limits available with it.
      list_5: Wallet – manages revenue, balance, transactions and payouts for sellers.
      list_6: My Products – shows your submitted and published products and their current status.
      list_7: Create Product – allows you to submit an exported Horum package as a product for the Marketplace.
      list_8: Settings – manages your Marketplace presence, notifications, privacy and basic account functions.
    overview:
      title: The Overview Page
      text_1: Overview is the start page of the Dashboard. It summarizes important information from several Dashboard areas without requiring you to open each individual page.
      text_2: In addition to current status information, your latest activities within the Horum platform are displayed.
    cards:
      title: Status Cards
      text: The upper section of the Overview contains four status cards with current information from your account.
      list_1: License – current Horum plan and associated date.
      list_2: Wallet – current balance and latest transaction.
      list_3: Products – number of your active and inactive products.
      list_4: Horum – currently assigned Horum version and version date.
    license:
      title: License
      text: The License card shows the Horum plan currently associated with your account.
      list_1: Plan – shows the currently active license plan.
      list_2: Date – shows the date associated with the license.
    wallet:
      title: Wallet
      text: The Wallet card provides a compact summary of your current financial information.
      list_1: Balance – shows your currently available Wallet balance.
      list_2: Latest transaction – shows the amount of your most recently recorded transaction.
    products:
      title: Products
      text: The Products card immediately shows how many of your products are currently active or inactive.
      list_1: Active – number of products approved and published by the platform.
      list_2: Inactive – number of submitted products that have not yet been reviewed by the platform.
    horum:
      title: Horum
      text: The Horum card displays information about the Horum version currently associated with your account.
      list_1: Version – shows the current Horum version number.
      list_2: Date – shows the date associated with the displayed Horum version.
    activities:
      title: Latest Activities
      text_1: Below the status cards is a list of your latest activities. It provides a chronological overview of recently recorded actions within the Horum platform.
      text_2: New activities are displayed in the list together with their respective time.
      list_1: Activity – describes the recorded action.
      list_2: Time – shows when the activity occurred.
      list_3: Activities can include sign-ins, purchases and other account activity.
    activity_history:
      title: Delete Activity History
      text_1: The displayed activity history can be deleted using the trash icon in the “Latest Activities” section.
      text_2: This removes the entries from the activity overview, after which the list can begin filling again with new activities.
    summary:
      title: Everything Important at a Glance
      text: The Dashboard brings together the central management areas of your Horum account. The Overview page provides a quick view of your license, Wallet, products, Horum version and latest activities, while the other Dashboard areas provide the corresponding information and functions in detail.

documentation:
  product_creator:
    title: Create Product
    intro: The Product Creator allows you to prepare a package created by Horum for the Marketplace and submit it for publication.
    purpose:
      title: Create a Product for the Marketplace
      text_1: The Product Creator connects the package exported from the Horum Application with the information, images and additional content required for a product on the Horum Marketplace.
      text_2: In addition to the actual product information, the Export Manifest and the associated Horum Package are uploaded. The product is then validated and submitted for the further publication process.
    requirements:
      title: Requirements
      text: Before you can create a product, you need the associated export files from the Horum Application and the required information for your Marketplace product.
      list_1: A Horum Package created with the Horum Application in .hrm format.
      list_2: The export_manifest.json file generated during the export.
      list_3: At least one product image and the required product information.
      list_4: An available product slot within the limit of your active Horum plan.
    product:
      title: Product Information
      text: In the first section, you define the basic information used to describe and offer your product on the Marketplace.
      list_1: Title – the name under which your product is displayed on the Marketplace.
      list_2: Description – a description of the product, its content and its intended use.
      list_3: Language – the language for which or in which the product is offered.
      list_4: Price – the sales price of the product. A price of 0.00 identifies a free product.
    images:
      title: Product Images
      text_1: You can upload up to three product images for your Marketplace product. These images are used to present and display the product on the Marketplace.
      list_1: A maximum of 3 product images can be uploaded.
      list_2: Supported image formats are JPG, JPEG, PNG and WEBP.
      list_3: At least one product image is required to create the product.
      list_4: AI-generated images – if AI-generated images are used, they must be marked accordingly when creating the product. Identified images automatically receive the visible “AI IMAGE” label in the Marketplace.
      text_2: If the product images were created using AI, this must be confirmed using the provided checkbox.
    documentation:
      title: Additional Documentation
      text_1: In addition to the Horum Package itself, you can upload documentation that provides users with additional instructions, descriptions or information about your product.
      list_1: TXT – simple text-based documentation and notes.
      list_2: NFO – text-based information files for the product or package.
      list_3: PDF – formatted instructions and more detailed product documentation.
      text_2: Uploading additional documentation is optional and is not required to submit a product.
    uploads:
      title: Export Manifest & Horum Package
      text: To create the Marketplace product, the two corresponding files generated by the Horum export must be uploaded.
      list_1: Export Manifest – the export_manifest.json created by Horum containing information about the export and its included components.
      list_2: Horum Package – the .hrm file created during export containing the actual package content.
    types:
      title: Select Product Type
      text: The product type describes the kind of Horum content being published. The selected product type must match the content of the exported package.
      list_1: Personality – soul, rules and forbidden rules of a Horum personality.
      list_2: Worker UI – work interfaces containing XML, YAML and associated icons.
      list_3: Result UI – result interfaces containing XML, YAML and associated assets.
      list_4: Horum Window – designs and configurations for worker and result windows.
      list_5: Core – animation, geometry and colors of a Horum core.
      list_6: Commands – Horum commands based on YAML.
      list_7: Complete Package – a package containing multiple different Horum components together.
    package:
      title: Structure of a Horum Package
      text_1: A Horum Package uses the .hrm file extension and follows a defined base structure. Which component directories are included depends on the content exported with the Horum Application.
      text_2: Static directories and files use predefined names. Dynamic names are generated according to the respective export and the components it contains.
    structure:
      title: Package Components
      text: A Horum Package can contain different Horum components. Its directory structure separates these components and assigns the required files to each of them.
      list_1: personality – contains soul.md, rules.md and forbidden.md for a personality.
      list_2: commands – contains the YAML files of the exported commands.
      list_3: core – contains animation.ini, geometry.ini and colors.ini for the exported core.
      list_4: horum_windows – contains the worker and result configurations for the associated Horum windows.
      list_5: worker_ui – contains icons as well as XML and YAML files for a Worker UI.
      list_6: result_ui – contains assets, icons as well as XML and YAML files for a Result UI.
    example:
      title: Example of a Horum Package
      text_1: A package does not need to contain every available component. It only contains the areas that are actually part of the respective export.
      text_2: The following example shows a Weather package that combines a command, a Worker UI and a Result UI within a single .hrm file.
    validation:
      title: Product Validation
      text_1: When creating a Marketplace product, the entered data and uploaded files are checked at multiple levels before the product is submitted for platform review.
      list_1: Frontend validation – checks required input fields, selections and uploads during product creation.
      list_2: Backend validation – validates the submitted product data and files again on the server.
      list_3: Package and manifest validation – checks whether the Horum Package and its associated export information comply with the expected requirements.
      list_4: Automated validation – technically validates the submitted product before it enters the subsequent platform review process.
      text_2: These validations protect the Marketplace from incomplete, damaged or invalid submissions. Further technical information about creating and exporting Horum Packages can be found in the Application documentation.
    submit:
      title: Submit Product
      text_1: Once all required product information is available and the validations have been completed successfully, you can submit the product using “Create Product”.
      text_2: After successful submission, the product appears under My Products. There you can follow its current review status and see whether the product is still being reviewed, has been approved or has been declined by the platform.
    summary:
      title: From Horum Export to Marketplace Product
      text: The Product Creator connects your exported Horum Package with the required Marketplace information. Product data, images, optional documentation, Export Manifest, .hrm package and product type are validated together and then submitted for publication on the platform.

documentation:
  my_products:
    title: My Products
    intro: Under My Products, you can manage the products you have submitted and published on the Horum Marketplace. The overview shows their current status, usage and the most important product information.
    overview:
      title: Your Marketplace Products
      text_1: The upper section provides a summary of your submitted and published products.
      list_1: Total Products – the number of all products in your product management.
      list_2: Active Products – products that have been reviewed and approved by the platform.
      list_3: Inactive Products – submitted products that are still awaiting review by the platform.
      list_4: Downloads – the total number of downloads across your products.
      text_2: This allows you to track both the current state of your publications and their usage directly from the Dashboard.
    table:
      title: Product Overview
      text: The table displays each of your products together with its most important information and available actions.
      list_1: Image – the preview image assigned to the product.
      list_2: Title – the published or submitted product name.
      list_3: Category – the type or category of the product.
      list_4: Language – the language specified for the product.
      list_5: File Type – the file type of the published content.
      list_6: Downloads – the number of downloads the product has received.
      list_7: Status – the current publication and review status.
      list_8: Price – the defined sales price or indication that the product is free.
      list_9: Actions – available functions for managing the respective product.
    limits:
      title: Product Limit of Your Plan
      text_1: The number of your own products that you can publish on the Horum Marketplace depends on your active Horum plan.
      list_1: Free – up to 2 products.
      list_2: Personal – up to 5 products.
      list_3: Premium – up to 10 products.
      text_2: You can find your current product limit and the other differences between the plans in the License section.
    validation:
      title: Validation and Approval
      text_1: Before a product is published on the Marketplace, it passes through several validation stages. These checks protect the platform and help detect invalid or faulty packages before publication.
      list_1: Package creation – Horum packages are created through the Application and are already structured according to the required package and manifest rules during export.
      list_2: Frontend validation – required product information and uploads are checked on the website when the product is submitted.
      list_3: Backend validation – the submitted data, package and associated information are validated again on the server.
      list_4: Automated validation – after successful technical validation, the submitted product is prepared for the subsequent platform review.
      text_2: More information about creating and exporting Horum packages can be found in the Application documentation.
    status:
      title: Product Status
      text: The status shows where your product currently is within the publication process.
      list_1: Active – the product has been reviewed and approved by the platform and is published on the Marketplace.
      list_2: Inactive – the product has been successfully submitted but has not yet completed the platform review. Inactive does not mean that the product has been rejected.
      list_3: Declined – the product has been reviewed and rejected by the platform.
    declined:
      title: Declined Products
      text_1: If a product is rejected after review, it receives the status “Declined”. This clearly distinguishes a rejected product from an inactive product that is simply still awaiting review.
      text_2: For a declined product, a yellow information icon (i) appears under Actions. Selecting this icon opens a modal displaying the reason for the rejection.
    actions:
      title: Manage Products
      text: Depending on the product status, different management functions are available in the Actions column.
      list_1: Edit product – manage existing product information and settings.
      list_2: Delete product – remove the corresponding product from your product management.
      list_3: View reason – for a declined product, use the yellow information icon (i) to open the rejection reason provided by the platform.
    summary:
      title: From Upload to Publication
      text: My Products follows your Marketplace products throughout the publication process. You can see which products have been submitted, which are still awaiting platform review, which have been approved and activated, and which products have been declined with a stated reason.

documentation:
  profile:
    title: Profile
    intro: Your profile is where you manage and complete your personal information, profile picture and, if applicable, your company information.
    overview:
      title: Manage Your Profile
      text_1: The Profile page in the Dashboard is the central area for managing your personal profile and company information.
      text_2: You can edit existing information, add missing details and manage the images associated with your profile.
      list_1: Add and edit personal information.
      list_2: Upload or update your profile picture.
      list_3: Add information about yourself.
      list_4: Manage company information and your company logo.
    personal:
      title: Personal Information
      text_1: In the Profile section, you manage the personal information associated with your Horum account.
      text_2: Individual details can be added or edited directly using the corresponding fields.
      list_1: First name – your stored first name.
      list_2: Last name – your stored last name.
      list_3: Username – the username of your Horum account.
      list_4: Email – the email address associated with your account.
      list_5: Date of birth – your stored date of birth.
      list_6: Gender – female, male or other.
      list_7: Language – your selected language.
      list_8: Country – the country associated with your profile.
      list_9: About me – a personal text where you can provide additional information about yourself.
    avatar:
      title: Profile Picture
      text_1: You can assign your own profile picture to your personal profile. Use “Upload Image” to select an image and use it as your avatar.
      text_2: An existing profile picture can be replaced with a new image in the same way.
    about:
      title: About Me
      text_1: The “About Me” field allows you to add your own description to your profile.
      text_2: The content can be edited and saved together with your other personal profile information.
    edit:
      title: Edit and Save Your Profile
      text_1: Changes to your personal information are made directly in the Profile section. You can add missing information or modify existing details.
      text_2: Use “Save” to apply the changes to your personal profile.
    company:
      title: Company Information
      text_1: In the Company section, you can add and edit information for a company associated with your account.
      text_2: Your personal profile and company information are managed separately, allowing personal details to remain independent from company information.
      list_1: Company name – the registered name of the company.
      list_2: Industry – the industry or business sector of the company.
      list_3: Email – the company's business email address.
      list_4: Website – the website associated with the company.
      list_5: Legal form – the legal structure of the company.
      list_6: Commercial register number – the stored commercial register number of the company.
    company_logo:
      title: Company Logo
      text_1: A separate company logo can be assigned to the company. Use “Upload Image” to select the desired logo.
      text_2: An existing company logo can also be replaced by uploading a new image.
    company_about:
      title: About the Company
      text_1: The “About the Company” field allows you to provide a more detailed description of the company and its activities.
      text_2: The description complements the other company information and can be edited together with the company details at any time.
    company_edit:
      title: Edit and Save Company Information
      text_1: Company name, industry, business contact details, legal form, commercial register number, company description and company logo can be managed in the Company section.
      text_2: Use “Save” to apply changes to the company information. Company information is saved separately from your personal profile.
    buyer:
      title: Profile as a Buyer
      text_1: As a buyer, you use your regular Horum account. You can browse the Marketplace, purchase products and manage purchases and content associated with your account.
      text_2: A seller profile is not required for normal Marketplace use as a buyer. Buyers and sellers are separate roles within the platform with different features.
    seller:
      title: Profile as a Seller
      text_1: If you want to publish and offer your own products through the Horum Marketplace, you also need access to the platform's seller features.
      text_2: Seller status extends your existing Horum account. It does not replace your personal account or your regular profile.
      list_1: Your personal Horum account remains the basis of your profile.
      list_2: As a seller, you can publish your own products on the Marketplace.
      list_3: Additional seller and provider information is available for sellers.
    seller_page:
      title: Public Seller Page
      text_1: Sellers have their own public seller page. It identifies the provider of a product and associates published products with the respective seller.
      text_2: This allows users to see who offers a product and view other products published by the same seller.
      list_1: Presentation of the seller or the company offering the products.
      list_2: Association of published products with the respective seller.
      list_3: Access to other products published by the same seller.
    become_seller:
      title: Becoming a Seller
      text_1: A regular Horum account does not automatically make you a seller. Additional steps are required before you can offer your own products on the Marketplace.
      text_2: These steps include the required identity verification (KYC). Depending on your seller status and provided information, additional information or verification may be required before all seller features become available.
    legal:
      title: Seller Information and Legal Notice
      text_1: In addition to the public seller profile, further legal provider information may be relevant for sellers, particularly when products are offered commercially.
      text_2: Further information about legal details and the respective provider can be found in the associated legal notice.
    summary:
      title: Your Profile in Horum
      text: The Profile page allows you to manage your personal information, profile picture and personal description as well as the information and logo of an associated company. At the same time, your profile forms the basis of your presence as a buyer or seller on the Horum Marketplace.

documentation:
  settings:
    title: Settings
    intro: Settings allow you to define your presence on the Horum platform, manage notifications and privacy options, and access important functions for your account.
    overview:
      title: Settings Overview
      text: The settings are divided into several areas that can be managed independently.
      list_1: Marketplace – defines whether you appear as an individual or a company.
      list_2: Notifications – controls the different notification channels.
      list_3: Privacy – determines the visibility of selected profile and contact information.
      list_4: Account – contains functions for changing your password and deleting your account.
    marketplace:
      title: Marketplace
      text_1: In the Marketplace section, you define how you want to appear on the Horum Marketplace.
      list_1: Individual – you appear using your personal profile.
      list_2: Company – you appear using the stored company information.
      text_2: The selection determines your presence on the Marketplace and can be adjusted according to how you use the platform.
    notifications:
      title: Notifications
      text_1: The different notification channels can be enabled or disabled independently.
      list_1: Website notifications – notifications within the Horum website.
      list_2: System notifications – notifications through the system you are using.
      list_3: Email notifications – notifications sent to your registered email address.
      list_4: In-app notifications – notifications within the Horum Application.
      text_2: This allows you to decide individually for each available channel whether you want to receive notifications through it.
    privacy:
      title: Privacy
      text_1: The Privacy section determines which selected profile and contact information may be visible to other users.
      list_1: Public profile visibility – determines whether your profile can be displayed publicly.
      list_2: Show email in Community – determines whether your email address is visible within the Community.
      list_3: Show email in product details – determines whether your email address is displayed in the details of your products.
      text_2: The individual privacy options can be enabled or disabled independently.
    password:
      title: Change Password
      text_1: The account settings allow you to change the password of your Horum account.
      list_1: “Change Password” opens the function for setting a new password.
      list_2: The new password is then used when signing in to your Horum account.
      text_2: Use a secure password and do not share your login credentials with other people.
    delete_account:
      title: Delete Account
      text_1: The Account section also contains the function for deleting your Horum account.
      list_1: “Delete Account” starts the account deletion process.
      list_2: Deleting your account is not the same as signing out.
      text_2: Signing out only ends your current session. Account deletion affects the Horum account itself and should only be used when the account is actually intended to be deleted.
    summary:
      title: Configure Your Account
      text: Settings bring together the central options for your presence on the Horum Marketplace, available notification channels, visibility of selected information and basic account management functions.

documentation:
  wallet:
    title: Wallet
    intro: Your Wallet allows you to manage your sales revenue, available balance and payouts.
    overview:
      title: Wallet Overview
      text_1: The Wallet is the central financial area for sellers on the Horum Marketplace. It brings together revenue from your product sales, available balance and payouts.
      text_2: The overview shows the most important values and the current status of your Wallet.
      list_1: Balance – your currently available balance.
      list_2: Total revenue – your total revenue earned so far.
      list_3: This month – your revenue for the current month.
      list_4: Last month – your revenue for the previous month.
      list_5: Pending – amounts that have not yet been paid out.
    seller:
      title: Wallet and Seller Status
      text_1: The Wallet is connected to the seller features of your Horum account. To sell products and receive payouts, you must complete the required seller and verification process.
      text_2: Seller status ensures that the information required for sales and payouts has been provided and verified.
      list_1: Set up seller status for your Horum account.
      list_2: Provide the required personal or business information.
      list_3: Complete the required verification process.
    kyc:
      title: Identity Verification and KYC
      text_1: The seller and payout process includes identity verification. The required KYC process is carried out for this purpose.
      text_2: Verification is part of the seller setup and must be completed accordingly before the intended seller and payout features can be used.
    stripe:
      title: Stripe Connection
      text_1: The payment and payout features of the Wallet are connected to Stripe. During setup, the payment information required for seller status and payouts is provided.
      text_2: The status of your payout information is displayed in the Wallet, allowing you to see whether the required setup has been completed.
    balance:
      title: Balance and Revenue
      text_1: The upper section of the Wallet provides a direct overview of your current revenue and available amounts.
      list_1: Balance shows the amount currently available.
      list_2: Total revenue shows the revenue earned so far.
      list_3: This month shows the revenue for the current month.
      list_4: Last month shows the revenue for the previous month.
      list_5: Pending shows amounts that have not yet been paid out.
      text_2: The displayed values are continuously updated according to your sales and payouts.
    payout_setup:
      title: Set Up Payout Information
      text_1: Before a payout can be made, the required payout information must be set up. The current status is displayed directly in the Wallet.
      text_2: Once setup is complete, available payouts can be initiated through the Wallet directly to the registered bank account.
    payout:
      title: Payouts
      text_1: Available balance can be requested for payout directly through the Wallet to your registered bank account.
      list_1: Payouts are sent directly to the registered bank account.
      list_2: The minimum payout amount is CHF 20.00.
      list_3: The Wallet continuously shows how much balance is currently available.
      list_4: The Wallet indicates whether a payout is currently possible based on the available balance.
      text_2: Once the requirements for a payout are met, the corresponding payout function becomes available.
    payout_dialog:
      title: Select Payout Amount
      text_1: When starting a payout, the payout dialog opens and allows you to specify the desired amount.
      text_2: The dialog also displays your currently available balance so that you can select the payout amount accordingly.
      list_1: 25% – selects 25 percent of the available balance.
      list_2: 50% – selects 50 percent of the available balance.
      list_3: 75% – selects 75 percent of the available balance.
      list_4: All – selects the entire available balance.
    transactions:
      title: Revenue and Payouts
      text_1: The Wallet provides separate views for your revenue and payouts, allowing you to track your sales and previously initiated payouts.
      text_2: The tables contain the most important information for each transaction.
      list_1: Date – the date of the respective transaction.
      list_2: Type or method – the type of sale or the payout method used.
      list_3: Reference – the associated order or payout reference.
      list_4: Amount – the monetary amount associated with the transaction.
      list_5: Status – shows the current status of the respective transaction.
    filter:
      title: Filter by Date Range
      text_1: Revenue and payouts can be filtered by a selected date range.
      text_2: Use “From” and “To” to define the desired period and then apply it to the displayed entries.
    exports:
      title: Export Revenue and Payouts
      text_1: Your revenue and payout tables can be exported for further processing and your own records.
      text_2: Exports are provided in Excel format and are available separately for both sections.
      list_1: Export revenue – exports the table containing your sales revenue.
      list_2: Export payouts – exports the table containing your payouts.
    refunds:
      title: Refunds
      text_1: Refunds may affect revenue, available balance and associated settlements.
      text_2: The exact conditions and rules for refunds are not described in detail here. The applicable Terms and Conditions are authoritative.
    terms:
      title: Payout Conditions
      text_1: Additional conditions and rules apply to payouts beyond the technical operation of the Wallet.
      text_2: The complete rules regarding payouts, refunds and related conditions can be found in the applicable Terms and Conditions.
    summary:
      title: Manage Revenue and Payouts
      text: The Wallet brings together the financial features for sellers on the Horum Marketplace. After completing the seller and verification process, you can track your revenue, view your available balance, filter and export transactions, and request payouts of available amounts from CHF 20.00 directly to your registered bank account.

documentation:
  faster_whisper:
    title: Faster Whisper
    intro: Faster Whisper is an external technical dependency of Horum and is used for local speech recognition. Horum integrates Faster Whisper through its own integration layer into input processing and converts recorded speech into text.
    purpose:
      title: Purpose
      text_1: Within Horum, Faster Whisper performs the actual transcription of a recorded speech input. The previously created audio file is passed to the loaded Whisper model and returned as recognized text.
      text_2: The dependency is therefore a component of speech recognition, while recording, voice activity, workflow control, and subsequent prompt processing are handled by Horum itself.
    integration:
      title: Integration into Horum
      text_1: Horum uses HorumFasterWhisper as its own integration layer between input processing and Faster Whisper. This allows the external speech recognition system to be controlled through Horum configuration and integrated into the internal processing workflow.
      text_2: Faster Whisper does not independently interact with the microphone or user interface. Instead, it receives the audio file prepared by Horum for transcription.
      list_1: Horum loads and initializes the configured Whisper model.
      list_2: The model configuration determines the model, device, and compute type.
      list_3: Horum passes a previously stored audio file to Faster Whisper.
      list_4: The transcribed text is then returned to Horum for further processing.
    model:
      title: Model and Configuration
      text_1: The Whisper model is initialized when the Horum integration is created, using the current speech configuration.
      text_2: This allows Horum to configure different parameters of local speech recognition without modifying the Faster Whisper integration itself.
      model: Model – determines the Whisper model used for speech recognition.
      device: Device – determines the device on which the model is executed. If no value is available, the current configuration uses CPU as the fallback.
      compute_type: Compute type – determines the model's computation type. The current configuration uses int8 as the fallback.
      language: Language – determines the language passed to Faster Whisper for transcription.
    audio:
      title: Audio File
      text_1: The audio file used by Faster Whisper is created by Horum itself. After the end of a detected speech input, Horum combines the recorded audio blocks and stores them for subsequent transcription.
      text_2: The current AudioRecorder stores the recording as a mono WAV file with 16-bit samples in the Horum cache. The sample rate is taken from the input configuration.
    transcription:
      title: Transcription
      text_1: For transcription, Horum passes the path of the stored audio file to the loaded Whisper model. Faster Whisper then returns individual recognized segments together with information about the detected language.
      text_2: Horum processes the individual segments into a single text and passes it to the subsequent input processing stage.
      list_1: Segments – text segments returned by Faster Whisper are cleaned and combined.
      list_2: Language – Faster Whisper returns information about the detected language.
      list_3: Probability – the language probability returned by Faster Whisper can be logged by Horum.
    pipeline:
      title: Position in Input Processing
      text: Faster Whisper is positioned between the audio recording prepared by Horum and the text-based prompt processing stage. The external dependency is responsible exclusively for the speech recognition step within the complete Horum input processing workflow.
      microphone: Microphone
      audio_recording: Audio Recording
      voice_activity: Voice Activity
      audio_file: Audio File
      faster_whisper: Faster Whisper
      transcribed_text: Transcribed Text
      prompt_processing: Prompt Processing
      horum: Horum
    horum:
      title: Further Processing by Horum
      text_1: After successful transcription, Horum receives the recognized text. If no text is returned, further processing of that recording is stopped.
      text_2: If text is available, it is passed to the Prompt Builder and prepared there for further processing within Horum. Faster Whisper itself does not perform prompt creation or LLM processing.
    dependency:
      title: External Dependency
      text_1: Faster Whisper is used by Horum as an external technical component for local speech recognition. Its integration into Horum, however, is handled through Horum's own components and workflow control.
      text_2: This keeps responsibilities clearly separated: Faster Whisper performs transcription, while Horum controls recording, speech input detection, audio file creation, configuration, prompt processing, and orchestration.
    summary:
      title: Local Speech Recognition for Horum
      text: Faster Whisper provides Horum with the technical foundation for local speech-to-text transcription. Horum integrates the dependency through HorumFasterWhisper, configures the model being used, and passes the previously recorded audio file to it. The resulting text is then fully returned to Horum's own input processing workflow.

documentation:
  opengl:
    title: OpenGL
    intro: OpenGL provides the technical graphics foundation for rendering the Horum Core. Horum uses OpenGL together with PyQt to draw the individual Core layers into framebuffers, apply multisampling, and then transfer the completed result as an image to the user interface.
    purpose:
      title: Purpose
      text_1: OpenGL performs the technical drawing operations of the Horum Core. The actual design, geometry, animation, and control of the Core layers remain part of Horum.
      text_2: This separates Horum's own Core logic from the underlying graphics technology used to render its visual elements.
    integration:
      title: Integration
      text: The OpenGL integration connects PyQt with the OpenGL functions used by Horum and its own layer architecture.
      pyqt: PyQt – provides, among other things, the OpenGL framebuffer objects used by Horum and the transfer of the rendered result to the Qt interface.
      pyopengl: OpenGL – provides the OpenGL functions and constants used by the rendering workflow.
      framebuffer: Framebuffer – Horum first renders the Core into dedicated framebuffers outside the actual interface.
      layers: Layers – the individual Horum Core layers are initialized and drawn by Horum's own rendering logic.
    state:
      title: OpenGL State
      text_1: During initialization, Horum configures the OpenGL state for transparent 2D rendering of the Core.
      text_2: These settings are prepared centrally before the individual Core layers are initialized and rendered.
      blending: Alpha blending – GL_SRC_ALPHA and GL_ONE_MINUS_SRC_ALPHA are enabled for transparent transitions.
      smoothing: Smoothing – line and point smoothing are enabled and configured with the highest available quality hint.
      depth: Depth and faces – depth testing and face culling are disabled for the 2D rendering workflow used by Horum.
      color: Color output – all four RGBA color channels remain enabled for output.
    framebuffers:
      title: Framebuffers
      text_1: Horum uses separate framebuffers for multisample rendering and the subsequently resolved image.
      text_2: This allows the Core to first be rendered with multisampling and then transferred into a non-multisampled resolve framebuffer.
      msaa: MSAA framebuffer – uses the configured number of samples and serves as the target for the actual layer rendering.
      resolve: Resolve framebuffer – uses no additional samples and receives the resolved result of the MSAA framebuffer.
      format: Color format – both framebuffers use RGBA8 and contain a combined depth-stencil attachment.
      multisampling: Multisampling – GL_MULTISAMPLE is enabled when rendering into the MSAA framebuffer.
    rendering:
      title: Rendering
      text_1: During a rendering pass, Horum binds the MSAA framebuffer and draws all currently enabled Core layers into it.
      text_2: After layer rendering is complete, the result is transferred into the resolve framebuffer and then converted into an image.
      clear: Before drawing, the color buffer is cleared with a fully transparent background.
      draw: Only enabled layers are processed and drawn through their respective draw function.
      resolve: After rendering, the MSAA framebuffer is resolved into the resolve framebuffer through a framebuffer blit operation.
      image: The resolved result is then converted from the resolve framebuffer into an image and returned to Horum for further display.
    projection:
      title: 2D Projection
      text_1: When the rendering size changes, Horum first updates the OpenGL viewport and resets the projection matrix.
      text_2: The Core uses an orthographic 2D projection. The individual layers then also receive the new width and height.
    pixel_buffers:
      title: Pixel Buffer Objects
      text_1: The OpenGL state reserves two Pixel Buffer Objects for pixel transfers. Their size is calculated from the rendering width, rendering height, and four bytes per pixel.
      text_2: The buffers are created as GL_PIXEL_PACK_BUFFER objects using GL_STREAM_READ and are managed together with the remaining OpenGL state.
    performance:
      title: Performance Measurement
      text_1: Horum includes its own performance infrastructure for the OpenGL rendering path. Measurements can be enabled specifically and used for different areas of the rendering process.
      text_2: In addition to the overall OpenGL workflow, individual layers and other performance values can be evaluated separately.
      opengl: OpenGL – measures rendering stages and individual layers and records values including current, average, minimum, and maximum execution times.
      fps: FPS – records the number of rendered frames and calculates the frame rate.
      frame_time: Frame Time – measures the time intervals between individual frames.
      cpu: CPU – measures processor usage of the running Horum process over the measurement period.
      ram: RAM – records memory usage of the Horum process on Windows.
    pipeline:
      title: Rendering Workflow
      text: OpenGL forms the technical rendering stage between Horum's own Core logic and the completed image that can subsequently be displayed by Qt.
      horum_core: Horum Core
      layers: Core Layers
      msaa: OpenGL MSAA Framebuffer
      resolve: Resolve Framebuffer
      image: Rendered Image
      qt: Qt Interface
    horum:
      title: OpenGL and Horum
      text_1: OpenGL does not define the appearance or behavior of the Horum Core. Colors, geometry, animations, layers, and their states are defined and controlled by Horum itself.
      text_2: OpenGL provides the technical rendering foundation and executes the drawing operations specified by Horum.
    dependency:
      title: Technical Dependency
      text_1: OpenGL is a technical graphics dependency of the Horum Core. The rendering path used by Horum requires functioning OpenGL support.
      text_2: The dependency concerns the graphical execution of the Core. The Core architecture itself and its visual properties remain part of Horum.
    summary:
      title: Graphics Foundation of the Horum Core
      text: OpenGL provides the technical rendering foundation for the Horum Core. Horum manages the Core layers and their behavior itself, while OpenGL provides framebuffers, multisampling, alpha blending, 2D projection, and the drawing operations required for their visual representation.

documentation:
  dependencies_overview:
    title: Dependencies
    intro: Horum uses selected external components for technical tasks required within its own architecture. These dependencies provide specialized functionality, while their integration, control, and use are handled by Horum.
    purpose:
      title: Purpose of Dependencies
      text_1: External dependencies perform clearly defined technical tasks within Horum. This allows established technologies to be used for specialized functions without having to implement them entirely within Horum itself.
      text_2: The dependencies do not form independent Horum systems. They are accessed by the corresponding Horum components and used as a technical foundation within a larger processing workflow.
    components:
      title: Used Components
      text: Horum currently uses three central external dependencies for speech recognition, package processing, and media playback.
      faster_whisper: Faster Whisper – local transcription of recorded speech into text.
      seven_zip: 7-Zip – technical archive functions for reading and extracting HRM packages.
      vlc: VLC – technical foundation for audio and video playback.
    faster_whisper:
      title: Faster Whisper
      text_1: Faster Whisper is used within input processing for local speech recognition. Horum passes a previously recorded audio file to the configured Whisper model and receives the transcribed text in return.
      text_2: Recording, voice activity, configuration, prompt processing, and orchestration remain responsibilities of Horum. Faster Whisper specifically performs the transcription step within this workflow.
    seven_zip:
      title: 7-Zip
      text_1: 7-Zip provides the technical archive functions required for processing HRM packages. Horum can use these functions to read required content from a package and extract it for installation.
      text_2: The HRM format, package structure, validation, permissions, installation rules, and target paths are defined and controlled by Horum. 7-Zip is responsible only for the required archive operations.
    vlc:
      title: VLC
      text_1: VLC provides the technical multimedia foundation for playing audio and video content within Horum.
      text_2: Media selection, the corresponding windows, presentation, and control remain part of Horum. VLC handles the underlying media playback.
    architecture:
      title: Position in the Architecture
      text_1: Each external dependency is assigned to a specific technical area within Horum. It is used where its specialized functionality is required.
      text_2: Faster Whisper supports input processing, 7-Zip supports package processing, and VLC supports media playback. The application logic above these technical layers remains part of Horum.
      horum: Horum
      input_processing: Input Processing
      faster_whisper: Faster Whisper
      package_processing: Package Processing
      seven_zip: 7-Zip
      media_playback: Media Playback
      vlc: VLC
    responsibility:
      title: Separation of Responsibilities
      text_1: Horum separates external technical functions from its own application logic. A dependency provides a specific technical capability but does not control the complete Horum workflow.
      text_2: This keeps the responsibilities of the individual components clearly separated.
      input: Input processing – Horum controls recording and processing; Faster Whisper performs transcription.
      packages: Package processing – Horum controls the HRM format and installation; 7-Zip provides the archive functions.
      media: Media playback – Horum controls windows and the media workflow; VLC provides the technical playback.
      horum: Horum – connects the external components to its own architecture and controls the respective overall process.
    summary:
      title: Technical Foundations for Horum
      text: Faster Whisper, 7-Zip, and VLC extend Horum with specialized technical functionality for speech recognition, package processing, and media playback. The external components provide their respective core functions, while integration, control, and application logic remain under Horum's control.

documentation:
  seven_zip:
    title: 7-Zip
    intro: 7-Zip is an external technical dependency of Horum and provides the archive functions required for processing Horum packages. Horum uses the bundled 7-Zip environment to read content from HRM packages and extract it for installation.
    purpose:
      title: Purpose
      text_1: Within Horum package processing, 7-Zip performs the technical archive operations. This primarily includes reading and extracting files from an HRM package.
      text_2: The actual package management is not handled by 7-Zip. Horum itself determines which package is processed, which content is required, and where that content is installed.
    integration:
      title: Integration into Horum
      text_1: Horum integrates 7-Zip into its own package and installation logic. Archive operations are initiated and controlled by Horum.
      text_2: This keeps 7-Zip limited to its technical role as an archive tool, while all Horum-specific decisions remain within Horum's own package management.
      list_1: Horum determines the HRM package to be processed.
      list_2: 7-Zip reads or extracts the content requested by Horum.
      list_3: Horum determines the permitted sections and their installation paths.
      list_4: Status, authorization, and the installation workflow are managed by Horum.
    hrm:
      title: HRM Package Format
      text_1: HRM is Horum's own package format. It combines the content and metadata required for a Horum package into a single package file.
      text_2: 7-Zip provides the technical archive processing for this purpose. The meaning and structure of an HRM package, however, are defined by Horum and not by 7-Zip.
    extraction:
      title: Extraction
      text_1: During installation, Horum uses 7-Zip to extract the required entries from the HRM package into the designated installation paths.
      text_2: Which areas are installed depends on the package type and manifest. Individual product types process their corresponding section, while a complete package can contain multiple available sections.
      list_1: Individual package sections can be extracted selectively from the HRM package.
      list_2: Target paths are determined by Horum's installation logic.
      list_3: Extraction is only one technical step within the complete installation process.
    metadata:
      title: Reading Metadata
      text_1: Horum can read required JSON files directly from an HRM package without first installing the entire package.
      text_2: 7-Zip provides the content of the requested archive entry. Subsequent JSON processing, interpretation, and validation are performed within Horum.
    pipeline:
      title: Position in Package Processing
      text: 7-Zip is positioned between Horum's package management and the actual processing of files contained in the HRM package. It provides the archive functions while Horum controls the complete installation workflow.
      hrm_package: HRM Package
      package_management: Horum Package Management
      seven_zip: 7-Zip
      package_content: Manifest / Package Content
      installer: Horum Installer
      installation_paths: Installation Paths
      installed_package: Installed Horum Package
    horum:
      title: Controlled by Horum
      text_1: Before installation, Horum checks the state of the package and then controls which package sections may be processed. Installation paths and the subsequent workflow are also determined by Horum.
      text_2: 7-Zip has no knowledge of Horum product types, permissions, installation status, or the meaning of individual package sections. This logic remains entirely part of Horum.
    vendor:
      title: Bundled 7-Zip Components
      text_1: The 7-Zip components required by Horum are distributed together with the application. This allows Horum to use the intended archive functions directly through its own installation.
      text_2: The 7-Zip environment contains the executable application, associated libraries, and the supplied license and information files.
      executable: 7za.exe – executable 7-Zip component used for the archive operations required by Horum.
      libraries: 7za.dll and 7zxa.dll – associated libraries of the integrated 7-Zip environment.
      license: License.txt, readme.txt, and history.txt – bundled license, information, and version files.
    dependency:
      title: External Dependency
      text_1: 7-Zip is an external technical dependency and is not part of Horum's actual package logic. Horum uses the provided archive functions as the technical foundation for specific package operations.
      text_2: This separation allows Horum to control its own HRM format and the complete installation process without having to implement the underlying archive functions itself.
    summary:
      title: Archive Processing for Horum Packages
      text: 7-Zip provides Horum with the technical functions required to read and extract HRM packages. The HRM format, package structure, validation, installation rules, target paths, and package status remain fully controlled by Horum.

documentation:
  vlc:
    title: VLC
    intro: VLC is an external technical dependency of Horum and provides the functions required for audio and video playback. Horum integrates the VLC components into its own media processing and presents playback within the designated Horum windows.
    purpose:
      title: Purpose
      text_1: Within Horum, VLC provides the technical playback of audio and video content. This allows Horum to play media files without having to provide the underlying multimedia engine itself.
      text_2: Media control and presentation remain part of Horum. VLC provides the technical playback functionality, while Horum determines which media is loaded and how it is presented within the application.
    integration:
      title: Integration into Horum
      text_1: Horum integrates VLC as a multimedia component within its own window and media architecture. Playback is initiated by Horum and provided within the corresponding interfaces.
      text_2: VLC therefore operates as a technical foundation in the background and does not replace the windows or controls provided by Horum.
      list_1: Horum determines the media file to be played.
      list_2: VLC provides the technical audio or video playback.
      list_3: Playback is integrated into the designated Horum windows.
      list_4: Windows, presentation, and interaction are controlled by Horum.
    media:
      title: Audio and Video
      text_1: The VLC integration is used for media playback within Horum. It provides the technical foundation for audio and video content opened through Horum's media functions.
      text_2: Audio and video use the same external multimedia foundation but can be presented through different windows and interfaces within Horum.
      audio: Audio – VLC provides the technical playback of audio files within the Horum media environment.
      video: Video – VLC provides the technical playback of video files and supplies the media output for the corresponding Horum window.
    windows:
      title: Horum Windows
      text_1: The visible media interface belongs to Horum and not to VLC. Horum uses its own windows for presenting and controlling media playback.
      text_2: This keeps media playback integrated into the Horum interface even though external VLC components are used for the actual audio and video processing.
    playback:
      title: Media Playback
      text_1: When a supported media file is opened through Horum, Horum integrates it into the appropriate media interface and uses VLC for the underlying playback.
      text_2: The VLC components form the technical playback layer. Control of the media workflow above that layer remains embedded within the Horum architecture.
    pipeline:
      title: Position in Media Processing
      text: VLC is positioned between Horum's own media and window logic and the actual multimedia playback. Horum manages the media file and its presentation, while VLC provides the technical playback.
      media_file: Media File
      horum: Horum
      media_window: Audio / Video Window
      vlc: VLC
      media_playback: Media Playback
    horum:
      title: Controlled by Horum
      text_1: Horum remains responsible for the application logic surrounding media playback. This includes selecting the media, providing the corresponding interface, and integrating playback into the application.
      text_2: VLC provides the multimedia functions but has no responsibility for Horum's window architecture, Commander, results, or other application areas.
    vendor:
      title: Bundled VLC Components
      text_1: The VLC environment required by Horum is distributed together with the application. This allows Horum to use the multimedia functions through its own installation.
      text_2: In addition to the VLC executable, the environment contains the required libraries, plugins, and other resources of the VLC runtime environment.
      executable: vlc.exe – executable VLC component of the bundled multimedia environment.
      libraries: libvlc.dll and libvlccore.dll – core libraries of the integrated VLC runtime environment.
      plugins: plugins – bundled VLC plugins for multimedia processing and playback.
      resources: Additional VLC resources include hrtfs, locale, lua, msi, and skins.
    dependency:
      title: External Dependency
      text_1: VLC is an external technical dependency and is not part of Horum's actual user interface. Horum uses the provided multimedia functions as the technical foundation for its audio and video playback.
      text_2: This separation allows Horum to provide its own media interface and window control while the underlying multimedia playback is handled by the integrated VLC environment.
    summary:
      title: Multimedia Playback for Horum
      text: VLC provides Horum with the technical foundation for playing audio and video content. Media selection, windows, the user interface, and integration into the Horum workflow remain under Horum's control.

documentation:
  audio:
    title: Audio Recording
    intro: Audio recording receives a completed spoken input from Horum's input processing and stores it as an audio file. This creates a WAV file from the audio blocks collected while the user was speaking, which can then be used for speech recognition.
    purpose:
      title: Purpose
      text_1: During an active spoken input, Horum collects the audio blocks provided by the microphone. Once the end of the spoken input is detected, these blocks are combined into one continuous audio recording.
      text_2: The AudioRecorder then prepares and stores this audio data as a WAV file and returns the path of the generated file to subsequent processing.
    collection:
      title: Collecting Audio Blocks
      text_1: Input orchestration begins collecting audio data when voice activity detects the beginning of a spoken input. Each subsequent audio block is stored in the audio buffer while recording is active.
      text_2: When the end of the spoken input is detected, the orchestrator combines the collected blocks into a single audio dataset and passes it to the AudioRecorder.
    recorder:
      title: AudioRecorder
      text_1: The AudioRecorder is responsible for converting and storing the collected audio data. It prepares the received samples for the WAV format and then writes the completed audio file.
      text_2: The required sample rate is taken from the Horum configuration.
      input: Input – the recorder receives the previously combined audio data of the completed spoken input.
      channel: Channel – for multidimensional audio data, the recorder uses the first channel.
      format: Format – the completed recording is stored as a WAV file with 16-bit audio samples.
      sample_rate: Sample rate – the WAV file uses the input sample rate configured in Horum.
    conversion:
      title: Audio Conversion
      text_1: Before writing the WAV file, the AudioRecorder converts the received data into a consistent format. Processing initially takes place as float32.
      text_2: The sample values are then limited to the valid range and converted into 16-bit PCM values for storage.
      float32: float32 – incoming audio data is processed as a float32 array.
      clip: Clipping – sample values are limited to the range from -1.0 to 1.0.
      int16: int16 – the limited values are scaled and converted into 16-bit integer samples.
    file:
      title: WAV File
      text_1: The prepared audio data is stored as a WAV file in the Horum cache. This file then forms the audio input for speech recognition.
      text_2: After successful storage, the AudioRecorder returns the path of the generated file so that input orchestration can pass it directly to the next processing stage.
      path: Path – the recording is stored at cache/speech.wav.
      channels: Channels – the generated WAV file is stored as a mono recording with one channel.
      sample_width: Sample width – the WAV file uses a sample width of 2 bytes, or 16 bits.
      frame_rate: Frame rate – the sample rate used corresponds to the configured input_sample_rate.
    orchestration:
      title: Connection to Orchestration
      text_1: Horum's input orchestration controls when audio data is collected and when it is stored. The VoiceActivityDetector provides the current state of the spoken input for this purpose.
      text_2: Once the end status is reached, the orchestrator combines the collected audio blocks and passes the complete recording to the AudioRecorder.
    transcription:
      title: Transfer to Speech Recognition
      text_1: After storage, input orchestration receives the path of the generated WAV file. This file is then passed to Horum's speech recognition.
      text_2: Audio recording itself does not perform transcription. It only provides the stored audio file required for the next processing stage.
    pipeline:
      title: Position in Input Processing
      text: Audio recording connects the active microphone input with file-based speech recognition. The audio blocks collected while the user is speaking are converted into a WAV file that can then be transcribed.
      microphone: Microphone
      audio_blocks: Audio Blocks
      collection: Collected Spoken Input
      audio_recorder: AudioRecorder
      wav_file: WAV File
      speech_recognition: Speech Recognition
    separation:
      title: Separation of Responsibilities
      text_1: Audio recording is separated from microphone control and speech recognition. Microphone control continuously provides audio blocks, while input orchestration determines which blocks belong to a spoken input.
      text_2: The AudioRecorder is responsible only for preparing and storing this completed recording. Interpretation of the spoken content takes place afterward through speech recognition.
    summary:
      title: From Audio Blocks to a WAV File
      text: Horum's audio recording combines the audio blocks collected during a spoken input, prepares them through the AudioRecorder, and stores them as a mono WAV file at cache/speech.wav. The generated file is then passed to speech recognition.

documentation:
  microphone:
    title: Microphone Control
    intro: Microphone control forms the entry point for Horum's speech-based input processing. It opens the configured recording device, continuously receives audio data, and passes it block by block to subsequent processing.
    purpose:
      title: Purpose
      text_1: The MicrophoneController manages Horum's audio input. It searches for the configured microphone, creates the input stream, and makes the received audio data available for subsequent processing through a callback.
      text_2: Microphone control itself does not perform speech recognition or prompt processing. Its responsibility ends with reliably providing the recorded audio data.
    device:
      title: Input Device
      text_1: Horum uses the input device selected in the configuration for audio recording. The MicrophoneController searches the available audio devices for a matching microphone.
      text_2: Only devices with at least one available input channel are considered.
      name: Device name – the configured input device is searched for by its name.
      channels: Channels – the Horum input stream uses one audio channel.
      dtype: Data type – incoming audio data is processed as float32.
    configuration:
      title: Configuration
      text_1: The parameters for microphone input are taken from Horum's speech configuration. This allows microphone control to use the same central settings as the rest of input processing.
      text_2: The input device, sample rate, and size of the individual audio blocks are particularly relevant for the audio stream.
      sample_rate: Sample rate – determines the number of samples per second used by the input stream.
      block_size: Block size – determines the number of samples processed in each audio block.
      input_device: Input device – defines which configured microphone is used for recording.
    selection:
      title: Device Selection
      text_1: To select the microphone, Horum queries the available audio devices and compares their names with the configured device name.
      text_2: When a matching device with available input channels is found, Horum uses its device index for the subsequent input stream.
    stream:
      title: Input Stream
      text_1: For continuous audio recording, Horum creates an InputStream. It uses the selected device together with the configured sample rate and block size.
      text_2: The stream delivers recorded audio data to Horum through a callback. This allows new audio blocks to be passed directly to subsequent input processing.
      start: Start – Horum creates and starts the input stream for the selected microphone.
      callback: Callback – each received audio block is copied and passed to the registered Horum callback.
      stop: Stop – the active input stream is stopped and then closed.
    audio:
      title: Audio Data
      text_1: The data received from the microphone is provided as float32 audio blocks. The stream operates with one channel and delivers data according to the configured block size.
      text_2: The MicrophoneController copies the incoming data before passing it to the registered callback. Subsequent processing stages therefore work with the transferred audio block.
    orchestration:
      title: Connection to Orchestration
      text_1: Microphone control is started by Horum's input orchestration. The orchestrator registers its audio processing function as the callback and thereby receives the audio blocks supplied by the microphone.
      text_2: From there, the audio data can be passed to subsequent processing stages such as voice activity detection and further audio processing.
    pipeline:
      title: Position in Input Processing
      text: Microphone control is positioned at the beginning of audio input. It connects the physical recording device with Horum's subsequent input processing.
      device: Microphone
      input_stream: Input Stream
      audio_blocks: Audio Blocks
      callback: Horum Callback
      input_processing: Horum Input Processing
    horum:
      title: Controlled by Horum
      text_1: Horum controls the selection, configuration, initialization, and runtime of microphone input. Microphone control forms its own component within input processing.
      text_2: The recorded audio data is not interpreted within the MicrophoneController. Its content is processed only by the subsequent components of Horum's input processing.
    summary:
      title: Audio Input for Horum
      text: Microphone control connects the configured recording device with Horum's input processing. It selects the microphone, manages the input stream, and passes the recorded float32 audio blocks through a callback to subsequent processing.

documentation:
  noise_reduction:
    title: Noise Reduction
    intro: Noise reduction is part of Horum's input processing and is intended to reduce disturbing background noise within the audio signal. Horum uses its own RNNoise integration with a locally included RNNoise library for this purpose.
    purpose:
      title: Purpose
      text_1: Noise reduction is positioned within the processing of audio data received from the microphone. Its purpose is to prepare the input signal for subsequent processing stages.
      text_2: It is therefore part of Horum's audio processing and not a standalone application or separate external Horum component.
    rnnoise:
      title: RNNoise
      text_1: For technical noise reduction, Horum has its own RNNoise integration. The native library is provided locally within the Horum installation and integrated through the Horum implementation.
      text_2: The RNNoise integration therefore forms part of Horum's input processing and is not documented as a separate dependency.
      library: Library – Horum uses the locally provided librnnoise-0.dll.
      wrapper: Integration – the Horum RNNoise class handles integration of the native library.
      configuration: Configuration – noise reduction can be enabled or disabled through the Horum speech configuration.
    library:
      title: Native Library
      text_1: The RNNoise library is provided as a native DLL within Horum. The Horum RNNoise integration loads this library from its local location at libs/rnnoise/librnnoise-0.dll.
      text_2: The native RNNoise interface provides functions for creating and releasing a processing state as well as processing individual audio frames.
    processing:
      title: Audio Processing
      text_1: RNNoise operates on individual frames. The native interface provides its own processing state and a function for processing a frame of audio samples.
      text_2: This allows an input signal to be processed step by step and then used within the subsequent Horum input processing workflow.
      state: Processing state – RNNoise provides its own DenoiseState for processing.
      frame: Frame processing – audio samples are passed to RNNoise processing in individual frames.
      output: Output – the processed audio signal can then be passed to subsequent input processing stages.
    configuration:
      title: Configuration
      text_1: Horum maintains its own setting for noise reduction within the speech configuration. The value is loaded from the Horum configuration and made available as an enabled or disabled state.
      text_2: This keeps the decision of whether noise reduction should be used within Horum's configuration rather than the native RNNoise library.
    integration:
      title: Integration into Horum
      text_1: The native RNNoise library provides the technical functions for noise reduction. Horum handles its local integration and incorporates it into its own input processing architecture.
      text_2: Control of the overall audio workflow, microphone processing, voice activity, recording, and subsequent processing stages remains the responsibility of Horum.
    pipeline:
      title: Position in Input Processing
      text: Noise reduction is intended to process the audio signal coming from the microphone before the prepared signal is used within the subsequent Horum input processing workflow.
      microphone: Microphone
      audio_input: Audio Input
      rnnoise: RNNoise
      processed_audio: Processed Audio
      input_processing: Horum Input Processing
    horum:
      title: Part of Horum
      text_1: RNNoise is not treated as a standalone system within Horum. The library provides the native processing functionality, while Horum is responsible for its integration, configuration, and position within the audio workflow.
      text_2: This keeps noise reduction as a technical part of Horum's input processing and separates it from the externally documented dependencies such as Faster Whisper, 7-Zip, and VLC.
    summary:
      title: Noise Reduction for Audio Input
      text: Horum's noise reduction integrates RNNoise as a local native library within input processing. RNNoise provides frame-based processing of the audio signal, while Horum integrates and configures the library within its own audio workflow.

documentation:
  orchestration:
    title: Orchestration
    intro: Orchestration connects the individual components of Horum's input processing and controls their shared workflow. The UserSpeechOrchestrator processes incoming microphone audio blocks, monitors voice activity, manages recording, and coordinates processing through to the prepared prompt.
    purpose:
      title: Purpose
      text_1: The individual input processing components operate independently and each handle a clearly defined responsibility. Orchestration connects these components into a continuous workflow.
      text_2: Based on the current voice state, it determines when recording begins, which audio data is collected, and when completed spoken input is stored, transcribed, and passed to prompt processing.
    components:
      title: Connected Components
      text: The UserSpeechOrchestrator creates and coordinates the central components of speech-based input processing.
      microphone: MicrophoneController – provides incoming audio blocks to orchestration through a callback.
      voice_activity: VoiceActivityDetector – analyzes each audio block and returns the current state of the spoken input.
      audio_recorder: AudioRecorder – stores the completed and combined spoken input as a WAV file.
      speech_recognition: HorumFasterWhisper – transcribes the stored audio file and returns the recognized text.
      prompt_builder: PromptBuilder – receives the transcribed text and provides the resulting prepared prompt.
    start:
      title: Starting Input Processing
      text_1: When started, orchestration resets its current processing state and then starts microphone control.
      text_2: The audio processing method is used as the microphone callback. This allows the UserSpeechOrchestrator to continuously receive the audio blocks provided by the input stream.
    processing:
      title: Processing Audio Blocks
      text_1: Each incoming audio block is first passed to the VoiceActivityDetector. The returned state determines how orchestration proceeds with the current block and the existing audio buffer.
      text_2: Voice activity therefore provides the central decision basis for the beginning, continuation, and completion of spoken input.
    recording:
      title: Controlling Recording
      text_1: Orchestration manages an audio buffer and its own recording state. This allows incoming audio blocks to be collected during a continuous spoken input.
      text_2: The workflow follows the state returned by the VoiceActivityDetector.
      begin: Beginning – when speaking signals the beginning of spoken input, orchestration activates recording and clears the previous audio buffer.
      collect: Collection – while recording is active, incoming audio blocks are added to the audio buffer.
      end: End – once end is reached, the current spoken input is considered complete and the collected audio data is processed further.
    transcription:
      title: Recording and Transcription
      text_1: After spoken input ends, orchestration combines the collected audio blocks and passes the complete audio data to the AudioRecorder. It stores the audio file required for subsequent processing.
      text_2: The returned file path is then passed to HorumFasterWhisper. Speech recognition transcribes the recording and returns the recognized text to orchestration.
    prompt:
      title: Transfer to the PromptBuilder
      text_1: When speech recognition returns usable text, orchestration passes it to the PromptBuilder. The resulting prepared prompt can then be retrieved.
      text_2: Passing this prompt to the LLM is intended as the subsequent processing stage. In the current UserSpeechOrchestrator, this call is still marked as a TODO.
    reset:
      title: Resetting the State
      text_1: Orchestration resets the states used for spoken input after completion and when starting or stopping the input workflow. This allows new spoken input to begin from a defined initial state.
      text_2: The PromptBuilder is also cleared after the current processing workflow so that the stored prompt is not carried over into the next spoken input.
    pipeline:
      title: Orchestrated Workflow
      text: The UserSpeechOrchestrator forms the central connection between the individual processing stages and guides data from microphone input through to the prepared prompt.
      microphone: Microphone
      audio_block: Audio Block
      voice_activity: Voice Activity
      audio_buffer: Audio Buffer
      audio_recorder: AudioRecorder
      speech_recognition: Speech Recognition
      prompt_builder: PromptBuilder
      further_processing: Further Horum Processing
    control:
      title: Central Workflow Control
      text_1: Orchestration brings the specialized components together without taking over their individual responsibilities. Microphone access, voice activity, storage, transcription, and prompt management remain encapsulated in their own components.
      text_2: The UserSpeechOrchestrator therefore serves as the central workflow controller for spoken input and determines when the individual components are used within the processing chain.
    summary:
      title: Central Control of Spoken Input
      text: The UserSpeechOrchestrator connects microphone control, voice activity, audio recording, speech recognition, and prompt processing. It controls the complete spoken input workflow from the first audio block to the prepared prompt, making it the central coordination point of Horum's input processing.

documentation:
  input_processing_overview:
    title: Overview
    intro: Input processing forms the technical workflow between the user's spoken input and the resulting prompt. Horum combines microphone control, voice activity, noise reduction, audio recording, speech recognition, prompt processing, and orchestration into a unified processing workflow.
    purpose:
      title: Purpose
      text_1: Input processing receives the audio data provided by the microphone and passes it step by step through the processing components required for spoken input.
      text_2: Speech and pauses are detected, relevant audio data is collected and stored, speech is converted into text, and the result is prepared for subsequent processing within Horum.
    components:
      title: Components
      text: Input processing consists of several separate components, each responsible for a clearly defined part of the overall workflow.
      microphone: Microphone control – opens and manages the input stream and passes incoming audio blocks to Horum.
      voice_activity: Voice activity – analyzes volume and detects speech, pauses, and the end of spoken input.
      noise_reduction: Noise reduction – provides Horum's own RNNoise integration for processing background noise.
      audio: Audio recording – combines the collected audio blocks and stores the completed spoken input as a WAV file.
      speech_recognition: Speech recognition – converts the stored spoken input into text using Faster Whisper.
      prompt_processing: Prompt processing – receives the transcribed text and makes it available for subsequent processing through the PromptBuilder.
      orchestration: Orchestration – connects and controls the individual components of input processing.
    microphone:
      title: Microphone Control
      text_1: Microphone control forms the entry point for speech-based input processing. It uses the configured input device and creates a continuous audio stream.
      text_2: Incoming mono audio blocks are passed as float32 data to Horum's input processing through a callback.
    voice_activity:
      title: Voice Activity
      text_1: The VoiceActivityDetector analyzes the RMS volume of incoming audio blocks and compares it with a threshold calculated from the configured sensitivity.
      text_2: Using the states idle, speaking, thinking, silence, and end, Horum identifies the progression of spoken input and can determine when audio data should be collected and when the input should be completed.
    noise_reduction:
      title: Noise Reduction
      text_1: For noise reduction, Horum has its own RNNoise integration with a locally included RNNoise library. The corresponding configuration is part of Horum's speech processing.
      text_2: RNNoise is therefore not treated as a separate external Horum dependency, but as part of Horum's own audio and input processing.
    audio:
      title: Audio Recording
      text_1: During detected spoken input, orchestration collects the incoming audio blocks. Once the end of the input is reached, the collected data is combined into a complete recording.
      text_2: The AudioRecorder prepares this data and stores it as a mono WAV file at cache/speech.wav. The generated file then forms the input for speech recognition.
    speech_recognition:
      title: Speech Recognition
      text_1: Speech recognition passes the stored audio file to the HorumFasterWhisper component. Faster Whisper performs the actual transcription and returns recognized text segments together with language information.
      text_2: Horum combines the text segments into a single transcription result and returns this text to the subsequent input processing.
    prompt_processing:
      title: Prompt Processing
      text_1: The transcribed text is passed to the PromptBuilder. It cleans the text and stores it as the current prompt.
      text_2: The prepared prompt can then be retrieved and used for subsequent processing by Horum. The PromptBuilder itself does not perform any LLM processing.
    orchestration:
      title: Orchestration
      text_1: The UserSpeechOrchestrator connects microphone control, voice activity, audio recording, speech recognition, and prompt processing into a unified workflow. It manages the audio buffer and current recording state, among other responsibilities.
      text_2: After spoken input ends, orchestration stores the collected audio data, starts transcription, and passes available text to the PromptBuilder. Passing the prompt to the LLM is still marked as a TODO in the current orchestrator.
    pipeline:
      title: Processing Workflow
      text: Together, the individual components form a processing chain that takes spoken input step by step from incoming audio data to the prepared prompt.
      microphone: Microphone
      audio_stream: Audio Input
      voice_activity: Voice Activity
      audio_recording: Audio Recording
      speech_recognition: Speech Recognition
      transcribed_text: Transcribed Text
      prompt_processing: Prompt Processing
      orchestration: Horum Orchestration
      horum: Further Horum Processing
    architecture:
      title: Separation of Responsibilities
      text_1: Input processing is divided into individual components so that recording, detection, and text-based processing can be managed independently.
      text_2: Orchestration connects these components, while each individual component handles only its designated part of the workflow.
      audio: Audio input – microphone control and audio recording handle the technical processing of audio data.
      detection: Detection – voice activity determines the state of the current spoken input from the audio signal.
      transcription: Transcription – Faster Whisper converts the completed audio recording into text.
      text: Text processing – the PromptBuilder receives the transcribed text and makes it available for subsequent processing.
    summary:
      title: From Microphone to Prompt
      text: Horum's input processing combines microphone input, voice activity, audio recording, speech recognition, and prompt processing into a controlled workflow. Orchestration brings the individual stages together and converts spoken input into a prepared text prompt for subsequent processing by Horum.

documentation:
  prompt_processing:
    title: Prompt Processing
    intro: Prompt processing receives the text produced by speech recognition and makes it available as a prompt for subsequent processing within Horum. The PromptBuilder provides the simple interface between transcribed spoken input and the following processing stages.
    purpose:
      title: Purpose
      text_1: After speech recognition is complete, the original spoken input is available as text. Prompt processing receives this text and keeps it available for subsequent processing by Horum.
      text_2: It therefore forms the transition from speech-based input processing to the subsequent text-based processing stages.
    input:
      title: Input
      text_1: The input for prompt processing is the transcribed text returned by speech recognition. The orchestrator first checks whether a usable transcription result is available.
      text_2: When text is available, it is passed to the PromptBuilder. Empty input is not accepted as a new prompt.
    builder:
      title: PromptBuilder
      text_1: The PromptBuilder manages the current prompt within input processing. It maintains a single text value that can be updated, retrieved, and cleared.
      text_2: The component does not perform speech recognition and does not itself send a request to a language model. It only provides the prepared prompt for subsequent processing.
      update: update – accepts an available text, removes leading and trailing whitespace, and stores the result as the current prompt.
      get: get_prompt – returns the currently stored prompt.
      clear: clear – removes the currently stored prompt and resets it to an empty value.
    update:
      title: Updating the Prompt
      text_1: When updating, the PromptBuilder first checks whether a text value is available. The text is then stripped and stored as the current prompt.
      text_2: A new valid text replaces the previously stored prompt. In the current implementation, the PromptBuilder does not accumulate multiple inputs into a combined prompt.
    result:
      title: Prepared Prompt
      text_1: After the update, the stored text can be retrieved from the PromptBuilder. This value represents the prepared prompt for the next processing stage.
      text_2: At this point, the prompt consists of the cleaned transcription result. Further processing by a language model does not take place inside the PromptBuilder.
    reset:
      title: Resetting the Prompt
      text_1: After the current input workflow is complete, the PromptBuilder can be reset. This completely clears the stored prompt.
      text_2: The next spoken input therefore begins with an empty prompt state and does not inherit text from the previous processing cycle.
    orchestration:
      title: Connection to Orchestration
      text_1: Horum's input orchestration connects speech recognition with the PromptBuilder. After successful transcription, it passes the recognized text to the PromptBuilder and then retrieves the prepared prompt.
      text_2: Passing this prompt to the LLM is intended as the subsequent processing step. In the current orchestrator, this call is still marked as a TODO.
    pipeline:
      title: Position in Input Processing
      text: Prompt processing follows speech recognition. It receives the transcribed text and prepares the prompt intended for subsequent Horum processing.
      transcribed_text: Transcribed Text
      prompt_builder: PromptBuilder
      prompt: Prepared Prompt
      orchestration: Horum Orchestration
      llm: LLM – intended next step
    separation:
      title: Separation of Responsibilities
      text_1: The PromptBuilder is deliberately separated from speech recognition and later LLM processing. Faster Whisper produces the text, the PromptBuilder manages the resulting prompt, and orchestration connects the individual processing stages.
      text_2: This gives each part of input processing a clearly defined responsibility and keeps the PromptBuilder independent of the specific speech recognition or model implementation.
    summary:
      title: From Transcription to Prompt
      text: Horum's prompt processing receives the transcribed text, cleans and stores it through the PromptBuilder, and makes it available for subsequent processing. Passing it to the LLM is intended as the next processing stage and is not yet implemented in the current orchestrator.

documentation:
  speech_recognition:
    title: Speech Recognition
    intro: Speech recognition converts a completed audio recording into text within Horum's input processing. Horum uses Faster Whisper for this purpose and then passes the result to text-based prompt processing.
    purpose:
      title: Purpose
      text_1: Speech recognition forms the connection between audio processing and Horum's subsequent text-based processing. It receives an audio file and produces the recognized spoken text.
      text_2: Recognition itself is performed by Faster Whisper. Horum handles configuration, integration, and further processing of the returned result.
    input:
      title: Input
      text_1: Speech recognition does not operate directly on the active microphone stream. After Horum detects the end of a spoken input, the collected audio data is first stored as an audio file.
      text_2: This audio file is then passed to Horum's Faster Whisper integration and forms the input for transcription.
    whisper:
      title: Faster Whisper
      text_1: Horum uses its own HorumFasterWhisper component as the connection to the Faster Whisper library. During initialization, the Whisper model is loaded using the settings configured in Horum.
      text_2: This allows Horum to determine the model, execution device, compute type, and language through its own configuration.
      model: Model – defines the Whisper model used for speech recognition.
      device: Device – determines the device used to execute the model.
      compute_type: Compute type – defines the compute type used for model execution.
      language: Language – is taken from the language configured in Horum and passed to transcription.
    transcription:
      title: Transcription
      text_1: For transcription, Horum passes the stored audio file together with the configured language to Faster Whisper. The library then returns the recognized segments and additional information about the detected language.
      text_2: Horum processes the returned segments and combines their text into a single transcription result.
      segments: Segments – Faster Whisper returns the recognized speech as individual text segments.
      detected_language: Detected language – the language information returned by Faster Whisper is logged by Horum.
      probability: Language probability – the returned probability of the detected language is also logged.
      text: Text – the contents of the individual segments are combined into a single text.
    result:
      title: Recognized Text
      text_1: The result of speech recognition is a text string assembled from the segments returned by Faster Whisper. This text is returned by the HorumFasterWhisper component to the input orchestration.
      text_2: If no usable text is available, no further prompt processing is triggered. When a transcription result is available, it can be passed to the PromptBuilder.
    orchestration:
      title: Connection to Orchestration
      text_1: Input orchestration starts transcription after a spoken input has ended and has been stored as an audio file. It then receives the transcribed text from speech recognition.
      text_2: When text is available, the orchestrator updates the PromptBuilder with the transcription result. This ends the audio stage of input processing and allows subsequent processing to continue as text.
    pipeline:
      title: Position in Input Processing
      text: Speech recognition is positioned between the completed audio recording and prompt processing. It converts the stored spoken input into text that Horum can subsequently process.
      audio_file: Audio File
      faster_whisper: Faster Whisper
      segments: Recognized Segments
      transcribed_text: Transcribed Text
      prompt_processing: Prompt Processing
    separation:
      title: Separation of Responsibilities
      text_1: Speech recognition is a processing stage within Horum, while Faster Whisper is the external technical foundation used for that stage. This keeps Horum's own workflow clearly separated from the actual transcription engine.
      text_2: Microphone control, voice activity, audio recording, orchestration, and prompt processing are handled by other Horum components. Speech recognition focuses on converting the completed audio recording into text.
    summary:
      title: From Speech to Text
      text: Horum's speech recognition passes a stored spoken input to Faster Whisper, combines the recognized segments into text, and returns the result to input orchestration. It therefore forms the interface between audio processing and subsequent prompt processing.

documentation:
  voice_activity:
    title: Voice Activity
    intro: Voice activity detection analyzes incoming audio blocks and determines whether the user is speaking, briefly pausing, or has finished their spoken input. Horum uses these states to control the audio recording workflow within input processing.
    purpose:
      title: Purpose
      text_1: The VoiceActivityDetector continuously evaluates the volume of audio data received from the microphone. Based on this information, Horum detects the beginning of spoken input as well as pauses and its end.
      text_2: The component does not transcribe or interpret the spoken content. It only determines the current voice activity state and provides it to input orchestration.
    volume:
      title: Volume Detection
      text_1: For each incoming audio block, Horum calculates an RMS value from the contained audio samples. This value is used as a measure of the current signal strength.
      text_2: The measured volume is then compared with a calculated threshold to distinguish between voice activity and silence.
      rms: RMS – volume is calculated from the square root of the mean of the squared audio samples.
      threshold: Threshold – the measured RMS value is compared with the current detection threshold.
      sensitivity: Sensitivity – the configured sensitivity affects the level of the threshold used for detection.
    threshold:
      title: Dynamic Threshold
      text_1: The detection threshold is calculated from the configured sensitivity. Horum uses a defined range between a minimum and maximum threshold for this calculation.
      text_2: Sensitivity determines the point within this range at which the measured signal strength is treated as voice activity.
    states:
      title: States
      text: The VoiceActivityDetector uses several states to represent the progression of a spoken input over time.
      idle: idle – no active spoken input has been detected yet.
      speaking: speaking – the measured volume reaches or exceeds the threshold and Horum detects active speech.
      thinking: thinking – after silence begins, the input is within the intended thinking or pause phase.
      silence: silence – the silence has reached the configured boundary for a longer pause.
      end: end – the spoken input is considered complete and can be passed to the subsequent processing stages.
    timing:
      title: Pauses and Timing
      text_1: Horum does not evaluate pauses based on a single audio callback. The configured time values are converted into corresponding callback limits using the duration of an audio block.
      text_2: This allows Horum to distinguish between a short pause while speaking and the actual end of a spoken input.
      thinking_delay: Thinking delay – determines how long a pause lasts before the thinking state is reached.
      pause_timeout: Pause timeout – determines the boundary at which extended silence leads to the end of the spoken input.
      callback_duration: Callback duration – is derived from the block size and sample rate and provides the basis for calculating the timing limits.
    detection:
      title: Detection Workflow
      text_1: As long as the measured volume reaches or exceeds the threshold, Horum treats the signal as active speech and resets the silence counter.
      text_2: When the volume falls below the threshold, Horum counts consecutive silent audio blocks. Depending on their number, detection progresses through the intended pause states until the spoken input ends.
    orchestration:
      title: Connection to Orchestration
      text_1: Input orchestration passes each audio block received from the microphone to the VoiceActivityDetector and receives the current status in return.
      text_2: When speaking begins, the orchestrator starts collecting audio data. Once the end status is reached, the collected spoken input is completed and prepared for subsequent audio recording and speech recognition.
    pipeline:
      title: Position in Input Processing
      text: Voice activity is determined directly from the incoming audio data. The result is a status used by Horum orchestration to control the subsequent spoken input workflow.
      audio: Incoming Audio
      volume: RMS Volume
      threshold: Threshold Comparison
      status: Voice Status
      orchestration: Horum Orchestration
    separation:
      title: Separation of Responsibilities
      text_1: Voice activity detection does not determine what was spoken. It analyzes only the signal strength and timing of the spoken input.
      text_2: Recording, transcription, and prompt processing are handled by the designated Horum components. This keeps voice activity detection clearly separated as its own processing stage.
    summary:
      title: Detecting Speech and Pauses
      text: The Horum VoiceActivityDetector analyzes the RMS volume of incoming audio blocks, compares it with a threshold calculated from sensitivity, and uses this to detect speech, pauses, and the end of spoken input. The resulting states control the subsequent Horum input processing workflow.

documentation:
  horum_window:
    title: Horum Window
    intro: The Horum Window is Horum's dynamic window system for Worker and Result interfaces. It provides Horum with flexible areas inside the main window that can be created, used, positioned, and managed depending on the current task.
    purpose:
      title: Purpose of the Horum Window
      text_1: Horum Windows provide dynamic interfaces inside the Horum main window. They are used when Horum requires a working interface during a task or wants to present a result within a dedicated result interface.
      text_2: The shared window system distinguishes between Worker UI and Result UI. Both use the same fundamental window architecture but serve different purposes within Horum's workflow.
    types:
      title: Two Window Types
      text_1: The Horum Window provides the common foundation for two different interface types. The type used depends on whether Horum is working with an interface or presenting a result.
      text_2: Worker UI and Result UI can be designed and used independently from each other.
      worker: Worker UI: Provides Horum with an interactive workspace for carrying out a task.
      result: Result UI: Presents results, information, and generated content within a dedicated interface.
    worker:
      title: Worker UI
      text_1: The Worker UI is Horum's own workspace. It can contain inputs, buttons, selections, and other components that Horum requires while processing a task.
      text_2: Interactions within this interface are intended for Horum. Horum can operate the contained elements and use the Worker UI according to the current workflow.
      text_3: The user can observe Horum working with this interface but does not directly interact with or manipulate the controls and workflows contained within it.
    result:
      title: Result UI
      text_1: The Result UI is used to present results. Horum can use it to display information and content within an interface tailored to the respective task.
      text_2: Unlike the Worker UI, the focus is not Horum's internal workflow but the generated or provided result.
      text_3: The specific Result UI can have a different structure depending on the task and can contain the content and presentation required for that result.
    difference:
      title: Difference Between Worker UI and Result UI
      text_1: The essential difference lies in the purpose of each interface. The Worker UI supports Horum while processing a task, while the Result UI is intended to present a result.
      text_2: This allows Horum to separate its internal workspace from the actual result presentation and use an appropriate interface for each purpose.
      worker: Worker UI: Horum works with the interface and uses its elements to carry out a task.
      result: Result UI: Horum uses the interface to present the result of a task.
    user_interaction:
      title: User Interaction
      text_1: Direct user interaction with a Horum Window is limited to moving the window. Inputs, buttons, selection controls, and other interactive elements inside it are controlled by Horum itself.
      text_2: The position of a Horum Window also remains bound to Horum's own workspace. The window cannot be moved outside the Horum main window.
      move: Moving: The user can reposition a Horum Window within the available Horum workspace.
      content: Window content: Interactive content inside the window is operated exclusively by Horum.
      boundary: Boundary: Worker UI and Result UI remain inside the Horum main window and cannot be positioned outside this area.
    horum_control:
      title: Window Control by Horum
      text_1: Horum can also move its Worker and Result windows itself. Within the main window, it has its own spatial workspace in which these windows can be positioned.
      text_2: The position of a window is therefore not exclusively determined by the user. Horum can change the arrangement itself when another position is more suitable for its current work or presentation.
      text_3: This allows Horum to actively organize its own interface and react to changes within its workspace.
      position: Positioning: Horum can move Worker and Result windows within its available workspace itself.
      core: Core: If a window is moved over the Core and obstructs Horum's central visual area, Horum can move the window to another position itself.
      focus: Focus: Horum can direct its visual attention toward the window that currently has focus.
    states:
      title: Focus and Inactive
      text_1: Horum Windows can have different states. This makes it possible to visually distinguish which interface Horum is currently using and which remains open but is not currently at the center of its work.
      text_2: These states can be used for both Worker UIs and Result UIs.
      focus: Focus: Horum is currently actively working with the window or directing its attention toward it.
      inactive: Inactive: The window remains open and can continue to exist or operate in the background, but Horum is currently using it only passively.
    styles:
      title: Appearance and Styles
      text_1: Worker UI and Result UI have independent appearance settings. This allows the visual design of both window types to be configured separately.
      text_2: In addition to the standard designs, designs from installed packages can also be used. Worker UI and Result UI selections are made independently from each other.
      worker: Worker UI: The design of the Worker Window can be configured independently from the Result UI.
      result: Result UI: The design of the Result Window can be configured independently from the Worker UI.
      standard: Standard: Horum's own standard styles can be customized in the Horum settings.
      package: Packages: Installed packages can provide alternative window designs that can be selected for the respective window type.
    dynamic_content:
      title: Dynamic Content
      text_1: The content of a Horum Window is not limited to one fixed interface. Depending on the task, Horum can use different Worker or Result interfaces.
      text_2: The interfaces can consist of YAML, XML, or a combination of both. This allows workflows and their associated presentation to be defined according to the respective task.
      text_3: Which Worker UI or Result UI is available and permitted for use is managed through the corresponding resources in the Commander.
    other_windows:
      title: Additional Windows for Results and Media
      text_1: Horum is not limited exclusively to a Result UI when presenting a result. Depending on the content, Horum can also use other suitable interfaces.
      text_2: These include the specialized Mini Windows for media. Horum can open these windows itself and use them to play or display the corresponding content.
      audio: Audio: Horum can use the Audio Mini Window and its player for music and other audio files.
      video: Video: Videos can be played through the dedicated Mini Window and its media player.
      images: Images: Image files can be displayed in the corresponding image view within a Mini Window.
      documents: Documents: Supported documents and other files can be provided and displayed through the document window.
    gods_eye:
      title: God's Eye View
      text_1: God's Eye View extends Horum's available interfaces with a spatial and interactive view. The extension can use its own dedicated interface or window.
      text_2: God's Eye View is not completely separated from Horum's other interfaces. Horum can additionally use a Result UI for specific information or results.
      text_3: This allows the specialized God's Eye view and Horum's existing result system to be used together depending on the respective task.
      window: Dedicated window: God's Eye View can provide its specialized presentation within its own interface.
      result_ui: Result UI: Individual information or results from God's Eye View can additionally be presented through a Result UI.
      combination: Combination: Horum decides which interface or combination of interfaces is appropriate depending on the task and content.
    workspace:
      title: Horum's Workspace
      text_1: Worker UI and Result UI are parts of Horum's own visual workspace. Horum can decide which windows are required, which of them have focus, and how they are arranged within the main window.
      text_2: The user can change the position of a Horum Window, but the final organization of the workspace remains dynamic. Horum can subsequently reposition windows itself when this is useful for its work or visual presentation.
      text_3: Together with Mini Windows and specialized extensions such as God's Eye View, this creates an interface that is not based on a rigid window arrangement but can be used and organized by Horum according to the task and content.
    summary:
      title: Summary
      text: The Horum Window provides the common foundation for Worker UI and Result UI. The Worker UI serves Horum's own work, while the Result UI presents results. The user can move these windows within the Horum main window, while Horum controls their contents and can also position the windows itself. Independent styles, package designs, Mini Windows, and God's Eye View extend this system into a dynamic workspace and presentation environment.

documentation:
  mini_window:
    title: Window Content
    intro: The Horum console works with four specialized media windows for audio, video, images, and documents. These Mini Windows load authorized media, present their content clearly, and provide additional actions depending on the media type.
    purpose:
      title: Purpose of the Media Windows
      text_1: The media windows form the interface between the media paths authorized in Horum and the files that are actually discovered. Each media type has its own Mini Window and specialized content list.
      text_2: The windows can be opened and controlled by the user or by Horum. This allows required media to be searched, displayed, and used further within Horum depending on the content.
    common:
      title: Four Media Areas
      text_1: All four areas use the same basic structure consisting of a Mini Window, specialized content list, Path Loader, and Content Filter.
      text_2: The actual presentation and processing then differs depending on the respective media type.
      audio: Audio: Manages discovered audio files and makes them available for selection and playback.
      video: Video: Manages discovered video files and provides previews and playback functions.
      images: Images: Displays discovered image files with visual previews and image information.
      documents: Documents: Displays documents, text files, data formats, source code, and other supported files in a shared document list.
    loading:
      title: Loading Content
      text_1: Each media window has a Path Loader for its respective content type. Discovered files are collected and then passed to the corresponding audio, video, image, or document list.
      text_2: When a window is refreshed, the previously loaded paths and list entries are removed and the loading process is started again. When the window is closed, its Path Loader is stopped.
    filter:
      title: Search, Filters and Sorting
      text_1: The four media windows use a shared Content Filter. It processes discovered paths before they are displayed in the corresponding list.
      text_2: Multiple criteria can be applied together to the available content.
      search: Search: Searches the file name for specified text.
      extension: Extension: Restricts the content to selected file extensions.
      mime: MIME type: Filters files by MIME type and also supports groups such as image/*.
      duration: Duration: Supports comparisons and ranges for media whose duration is available.
      sort: Sorting: Content can be sorted ascending or descending by name, modification date, file size, or duration.
    audio:
      title: Audio
      text_1: The audio window displays audio files discovered by Horum in its own Audio List. The entries can then be used for audio playback.
      text_2: Audio also processes media information and preview images. Horum uses the bundled VLC library for this media processing and playback.
      list: List: Discovered audio files are displayed as individual entries in the Audio List.
      thumbnail: Preview: Horum attempts to load embedded artwork metadata from the audio file through VLC. If no usable artwork is available, an audio fallback icon is displayed.
      information: Information: Audio files can be displayed and processed with file information such as name, size, and duration within the media interface.
      playback: Playback: Selected audio files can be loaded into the Audio View and played using the integrated player functions.
    video:
      title: Video
      text_1: The video window provides discovered video files in its own Video List. Preview images can be generated from video content to make videos easier to identify visually.
      text_2: As with audio, Horum uses the bundled VLC library for video processing and playback.
      list: List: Discovered video files are displayed as individual entries in the Video List.
      thumbnail: Preview: A temporary snapshot can be generated for a video and used as its preview image. The temporary file created for this process is removed afterwards.
      information: Information: Video entries provide their associated file and media information for selection and further processing.
      playback: Playback: Selected videos are opened in a dedicated Video View and can be played using the integrated playback controls.
    images:
      title: Images
      text_1: The image window displays discovered image files in an Image List. Unlike audio and video, image display does not require VLC playback.
      text_2: Previews are loaded using PyQt5 image functionality and prepared for display within the list.
      list: List: Discovered image files are displayed as individual entries in the Image List.
      thumbnail: Preview: Image files are read using QImageReader. Image preview creation is performed by a dedicated worker in a QThread.
      information: Information: Image entries can provide file name, MIME type, file size, resolution, and file extension.
      open: Open: A selected image can be opened in a dedicated Image View and displayed within Horum.
    documents:
      title: Documents
      text_1: The document window combines a wide range of text-based, structured, and traditional document formats in a shared Document List.
      text_2: Documents do not use a media preview like images or videos. Instead, Horum generates a compact preview icon based on the detected document type.
      list: List: Discovered supported files are displayed as entries in the Document List.
      thumbnail: Preview: A 30 × 30 pixel icon is generated for documents. Its color and type label are based on the detected document type.
      information: Information: Document entries can display information including file name, MIME type, file size, and file extension.
      types: File types: In addition to traditional documents, spreadsheets, presentations, text files, data formats, web files, source code, shell files, database files, configuration files, and TeX are supported.
    formats:
      title: Supported Formats
      text_1: Horum defines a separate list of supported file extensions for each media area. Only matching files are assigned to the corresponding content area.
      text_2: The supported formats cover both common standard formats and additional specialized formats.
      audio: Audio: MP3, WAV, AAC, M4A, FLAC, ALAC, APE, WV, OGG, OGA, Opus, WMA, AIFF, AIF, AIFC, MID, MIDI, AMR, AC3, and DTS.
      video: Video: MP4, M4V, AVI, MOV, WMV, WebM, MKV, MPEG, MPG, MPE, MPV, M2V, MTS, M2TS, TS, 3GP, 3G2, FLV, F4V, OGV, and VOB.
      images: Images: JPG, JPEG, PNG, BMP, GIF, WebP, TIF, TIFF, AVIF, HEIC, HEIF, ICO, SVG, and RAW formats such as RAW, CR2, CR3, NEF, ARW, DNG, ORF, and RW2.
      documents: Documents: Supported formats include PDF, DOC/DOCX, ODT, RTF, XLS/XLSX, ODS, CSV, TSV, PPT/PPTX, ODP, TXT, Markdown, JSON, XML, YAML, HTML, CSS, JavaScript, TypeScript, Python, C/C++, C#, Java, Kotlin, PHP, additional programming languages, shell files, SQL, configuration files, and TeX.
    thumbnails:
      title: Previews
      text_1: The four content areas use different methods to generate their preview images. This allows the presentation to be adapted to the respective file type.
      text_2: Previews provide a quick visual way to identify an entry within its respective media list.
      audio: Audio: Embedded artwork is searched through VLC metadata. If no artwork is available, Horum uses an audio fallback icon.
      video: Video: A snapshot from the video is generated temporarily, loaded as a preview image, and then cleaned up.
      images: Images: The actual image is loaded through QImageReader and used as the preview.
      documents: Documents: A colored document-type icon with a short type label is generated dynamically.
    player:
      title: Audio and Video Playback
      text_1: Audio and video provide playback functions for direct media control within Horum. The Player Controls provide the central playback actions.
      text_2: For video, the controls and progress display can additionally be positioned as an overlay over the video area.
      mode: Playback mode: Controls the playback mode being used.
      previous: Previous: Switches to the previous media entry.
      stop: Stop: Stops the current playback.
      play_pause: Play / Pause: Starts playback or pauses the currently playing media.
      next: Next: Switches to the next media entry.
    dependencies:
      title: Dependencies
      text_1: The media windows use several internal and external components for presentation, file processing, previews, and playback.
      text_2: The required components are integrated directly into the corresponding media processing.
      pyqt: PyQt5: Used for windows, lists, images, threads, signals, controls, and graphical presentation of the media interfaces.
      vlc: VLC: Audio and video use the VLC library for media processing and playback.
      vendor: Vendor VLC: Horum uses the bundled VLC installation from the vendor/vlc directory, including its associated plugin directory.
    file_data:
      title: File Information
      text_1: The media lists use file information to display, filter, and sort content. Depending on the media type, this can include name, file extension, MIME type, modification date, size, and duration.
      text_2: File sizes are automatically formatted as Bytes, KB, MB, or GB for display.
    summary:
      title: Summary
      text: The four media Mini Windows form the content interface for audio, video, images, and documents. Shared loading, search, filtering, and sorting functions are combined with media-specific lists, previews, and views. Audio and video additionally use the VLC library bundled with Horum under vendor/vlc for their media functions.

documentation:
  background:
    title: Background
    intro: The background defines the visual environment of the Horum main window and can be adjusted to match the appearance of the Core. This allows the Core and background to be visually coordinated.
    function:
      title: Background Function
      text_1: The background forms the complete visual area behind the Core and the controls of the Horum main window.
      text_2: The background can be selected and configured under UI Appearance in the settings.
    types:
      title: Background Types
      text: Different background variants are available for the Horum main window.
      list_1: Images: Static image files can be used as the background.
      list_2: Animated WebP: Animated WebP files can be used to create moving backgrounds.
      list_3: Gradients: The background can consist of a configurable color gradient.
      list_4: Solid color: A single color can be used as a uniform background.
    formats:
      title: Supported Image Formats
      text: Horum supports the following file formats for custom image backgrounds.
      list_1: WebP: For static and animated WebP backgrounds.
      list_2: JPEG: For static image backgrounds.
      list_3: PNG: For static image backgrounds.
    screens:
      title: Screen Formats
      text_1: The predefined backgrounds are divided into different screen formats. This allows images to be used with an aspect ratio suited to the respective screen configuration.
      text_2: When manually adding custom images, the screen configuration should also be taken into account so that the background can be displayed appropriately.
      list_1: Widescreen: Backgrounds designed for wide screen formats.
      list_2: Dual Screen: Backgrounds designed for configurations with two screens.
      list_3: Triple Screen: Backgrounds designed for configurations with three screens.
      list_4: 16:10: Backgrounds designed for standard screen formats with a 16:10 aspect ratio.
    custom:
      title: Custom Backgrounds
      text_1: Custom images can be added directly to Horum's designated background folder when required. A supported file format and an aspect ratio suitable for the screen configuration should be used.
      text_2: Added images automatically appear in the corresponding dropdown under UI Appearance and can be selected as a background. Further information about selection and configuration is available in the Settings documentation.
    summary:
      title: Summary
      text: The background of the Horum main window can use images, animated WebP files, color gradients, or a solid color. Custom images can be added through the designated folder and then become automatically available for selection in the settings.

documentation:
  core:
    title: Core
    intro: The Core forms the visual center of the Horum main window. Its different layers react to Horum's current state and provide direct visual feedback for activity, processing and voice output.
    function:
      title: Core Function
      text_1: The Core is more than a graphical element. Its animations provide visual feedback and indicate what Horum is currently doing.
      text_2: For this purpose, the Core combines several independently animated layers that represent different states and activities.
    states:
      title: States and Reactions
      text: The individual areas of the Core have different functions and react depending on Horum's current activity.
      list_1: Idle: While idle, the central Core pulses and the eye movement regularly changes its viewing direction.
      list_2: Understanding and thinking: The middle ring rotates to visualize that Horum is processing input or thinking about a response.
      list_3: High frequencies: While Horum is speaking, the inner wave ring reacts to the higher-frequency components of the voice.
      list_4: Low frequencies: While Horum is speaking, the outer wave ring reacts to the lower-frequency components of the voice.
    structure:
      title: Core Structure
      text: The visualization consists of several visual layers that together form the complete Core animation.
      list_1: Core Orb: Central element with pulse and eye animation.
      list_2: Inner Wave: Inner wave ring used to visualize high frequencies.
      list_3: Middle Ring: Middle ring used to visualize processing, understanding and thinking.
      list_4: Outer Wave: Outer wave ring used to visualize low frequencies.
    customization:
      title: Customization
      text: The appearance and behavior of the Core can be customized through the Horum settings. The detailed options are described in the documentation for the respective settings sections.
      list_1: Core Animation: Speed, strength and behavior of the animations.
      list_2: Core Geometry: Size, radii, spacing and other geometric properties.
      list_3: Core Colors: Colors of the individual Core elements, rings and effects.
    summary:
      title: Summary
      text: The Core makes Horum's current state immediately visible. Idle movement, processing and different areas of voice output are represented through dedicated animation layers.

documentation:
  interaction:
    title: Interaction
    intro: Horum can be controlled through both text input and voice input. The user can decide which input method to use and which one should preferably be displayed in the main window.
    input:
      title: Input Methods
      text_1: Two input methods are available in the main window for direct communication with Horum.
      text_2: The preferred input method can be configured under UI Appearance in the settings.
      list_1: Text input: A request is entered directly through the text field.
      list_2: Voice input: A request is spoken through the microphone and then converted into text by Whisper.
    switching:
      title: Switching Input Methods
      text_1: The text field and microphone react dynamically to the input method currently being used.
      text_2: This keeps the input method currently being used by the user in focus.
      list_1: When text is entered into the input field, the microphone is hidden.
      list_2: When the microphone is activated, the text field is hidden.
    wake_word:
      title: Wake Word
      text_1: Horum can be addressed using a wake word. This allows voice input to be activated without first interacting directly with the input field.
      text_2: The wake word function is only available when the microphone is permanently enabled. Only then can Horum continuously listen for the configured wake word.
    processing:
      title: Input Processing
      text: Regardless of the selected input method, the input is passed as text to the selected language model for further processing.
      list_1: Text input is taken directly from the input field.
      list_2: Voice input is captured through the microphone.
      list_3: Whisper converts the captured speech into text.
      list_4: The text input or the text generated by Whisper is used to form the prompt for the selected LLM.
    model:
      title: Selected LLM
      text_1: The generated prompt is sent to the currently selected LLM. The model can run locally or be connected through an API.
      text_2: Model selection and configuration are covered in greater detail in the corresponding Settings and Marketplace sections.
    summary:
      title: Summary
      text: Interaction with Horum can take place through text or voice. Voice is converted into text by Whisper, while text input is processed directly. Both paths result in a prompt that is then passed to the selected LLM.

documentation:
  navigation:
    title: Navigation
    intro: The Horum main window provides direct access to the most important input and navigation options. From here, users can interact with Horum or access the application's central areas.
    input:
      title: Text and Microphone
      text: The text field and microphone provide direct communication with Horum. Which input method is displayed by default and how Horum switches between them is described in more detail in the Interaction section.
      list_1: Text input: Opens or uses the text field for direct input to Horum.
      list_2: Microphone: Activates voice input and allows spoken input to Horum.
    settings:
      title: Settings
      text: The Settings button opens Horum's central configuration. This area manages the application, its appearance, and important system functions.
      list_1: Configure Horum's UI and appearance.
      list_2: Manage memory, cache, and the paths used by Horum.
      list_3: Configure voice input and voice output.
      list_4: Configure models, the Core, Horum Windows, and other application areas.
    marketplace:
      title: Marketplace
      text: The Marketplace button opens the management area for Horum packages, models, generators, and additional functions related to extending Horum.
      list_1: View, install, and manage purchased packages.
      list_2: Generate custom Horum packages for export.
      list_3: Manage LLM models and generators.
      list_4: View information about interactions with the application and the LLMs being used.
    commander:
      title: Commander
      text_1: Commander is the central interface for commands and Horum's work and result presentation. It shows which commands and interfaces Horum learns, uses, and processes.
      text_2: Worker UIs and Result UIs are not conventional user windows. They graphically represent Horum's working area and its results. Direct user interaction with these interfaces is limited to moving the windows.
      list_1: View and manage commands that Horum can use and process.
      list_2: Display Worker UIs used by Horum while performing its work.
      list_3: Display Result UIs through which Horum presents results graphically.
    console:
      title: Console
      text: The Console allows Horum's internal commands to be executed directly. It can be used both by Horum itself and directly by the user to trigger specific operations.
      list_1: Open Horum windows and other available areas directly.
      list_2: Run benchmarks and internal checks.
      list_3: Execute other supported operations and internal commands directly.
    summary:
      title: Summary
      text: The Horum main window provides text and voice input as well as direct access to Settings, Marketplace, Commander, and Console. Each area serves a different purpose and is covered in greater detail in its respective documentation section.

documentation:
  overview:
    title: Horum Main Window
    intro: The Horum main window is the central interface for direct interaction with Horum. It combines the visual Core, text or voice input, navigation to the most important areas, and a customizable background.
    main:
      title: Central Interface
      text_1: The main window is the starting point for everyday use of Horum. From here, users can provide input and directly open the application's central areas.
      text_2: Core, navigation, interaction, and background together form Horum's visible main interface.
    core:
      title: Core
      text: The Core forms the visual center of the main window and represents different states and activities of Horum through its individual animation layers.
      list_1: Visualizes Horum's idle state through pulse and eye movements.
      list_2: Indicates processing, understanding, and thinking through the middle ring.
      list_3: Represents high and low tones during voice output through the inner and outer wave rings.
    navigation:
      title: Navigation
      text: The main window navigation provides direct access to Horum's central areas.
      list_1: Settings: Configuration of the UI, voice, memory, paths, Core, and other areas.
      list_2: Marketplace: Management of packages, package exports, LLM models, and generators.
      list_3: Commander: Management and presentation of commands, Worker UIs, and Result UIs.
      list_4: Console: Direct access to internal Horum commands and supported operations.
    interaction:
      title: Interaction
      text: Horum can be addressed directly through text or voice. The preferred input method can be configured, and the interface dynamically adapts to the input method currently being used.
      list_1: Text input through the input field of the main window.
      list_2: Voice input through the microphone with speech converted by Whisper.
      list_3: Optional wake word for voice input when the microphone is permanently enabled.
    background:
      title: Background
      text: The background forms the visual environment of the main window and can be designed to match the Core.
      list_1: Supports images and animated WebP files.
      list_2: Can alternatively use color gradients or a solid color.
      list_3: Custom supported image files can be added and then selected through the settings.
    summary:
      title: Summary
      text: The Horum main window combines communication, visual feedback, and direct access to the application's most important areas. Core, navigation, interaction, and background can each be adapted to how Horum is used and presented.

documentation:
  marketplace_cart:
    title: Shopping Cart
    intro: The shopping cart collects products from the Horum Marketplace before you purchase them together. Multiple products and products from different sellers can be added to the cart at the same time and then purchased together through checkout.
    overview:
      title: Shopping Cart in the Marketplace
      text_1: The shopping cart manages the products you have selected for purchase. Products can be collected while continuing to browse the Marketplace before proceeding to checkout.
      text_2: The current shopping cart can be opened at any time using the cart icon in the upper-right area of the navigation.
      list_1: Products can be added individually to the shopping cart.
      list_2: Multiple products can be contained in the shopping cart at the same time.
      list_3: Products from different sellers can be selected together for purchase.
    add:
      title: Add a Product
      text_1: A product that has not already been purchased can be added to the current shopping cart using the cart function.
      text_2: Depending on the current view, there are two ways to access this function.
      list_1: Product card – the cart icon on the product card adds the product directly to the shopping cart.
      list_2: Product details – a product can also be added using the cart function within the opened product detail view.
    navigation:
      title: Shopping Cart in the Navigation
      text_1: The cart icon is located in the upper-right area of the navigation and provides direct access to the current shopping cart.
      text_2: A counter on the icon is updated automatically and shows how many products are currently in the shopping cart.
      list_1: Cart icon – opens the current shopping cart.
      list_2: Counter – displays the number of products currently added to the cart.
      list_3: Automatic update – the counter is adjusted whenever products are added or removed.
    contents:
      title: Shopping Cart Contents
      text: The opened shopping cart displays the current product selection and the total calculated from it.
      list_1: Product name – identifies each product in the shopping cart.
      list_2: Individual price – displays the price of each product in the currency used for the current user.
      list_3: Remove – removes an individual product from the shopping cart.
      list_4: Total – displays the combined price of all products currently contained in the shopping cart.
    multiple:
      title: Multiple Products and Sellers
      text_1: The shopping cart is not limited to a single product or seller. Multiple products can be collected before proceeding to checkout.
      text_2: Products from different sellers can also be contained in the shopping cart at the same time and purchased together through the subsequent checkout.
    remove:
      title: Remove a Product
      text_1: Each entry in the shopping cart has its own remove action. Individual products can therefore be removed from the current selection without clearing the entire cart.
      text_2: After a product is removed, both the cart counter in the navigation and the calculated total are updated accordingly.
    purchased:
      title: Already Purchased Products
      text_1: For a product that has already been purchased, the normal shopping cart function is no longer displayed as a purchase action.
      text_2: This makes it visible directly in the product overview or product detail view that the product is already owned by the user.
      list_1: Product card – the cart icon is replaced by the corresponding purchase status when the product has already been purchased.
      list_2: Product details – the product detail view displays the “Already purchased” status instead of the normal cart action.
    purchase_count:
      title: Previous Purchase Count
      text_1: Product cards also show how many times a product has already been purchased. This number belongs to the product and is independent of the personal shopping cart of the currently signed-in user.
      text_2: The purchase count should therefore not be confused with the counter on the cart icon in the navigation. The cart counter shows the products currently selected by the user, while the purchase count shows the previous purchases of the respective product.
    currency:
      title: Currency and Price Conversion
      text_1: The currency used in the Marketplace and shopping cart is based on the currency stored for the Horum account. It is set during registration and is subsequently applied according to the user's profile.
      text_2: Product prices are converted for the stored regional currency using the current API exchange rate and displayed accordingly.
      list_1: Account currency – is defined when the Horum account is registered.
      list_2: Profile – the stored currency is applied through the user's Dashboard profile settings and cannot be changed freely directly within the Marketplace.
      list_3: Conversion – prices are converted into the currency stored for the user using the current API exchange rate.
    total:
      title: Total
      text_1: Below the selected products, the shopping cart displays the combined total of all product prices currently contained in the cart.
      text_2: When a product is added or removed, the total is recalculated according to the current shopping cart selection.
    checkout:
      title: Proceed to Checkout
      text_1: Selecting “Checkout” passes the current product selection from the shopping cart to the checkout process.
      text_2: The actual payment and purchase process then continues in checkout and is described separately in the “Checkout” documentation section.
    summary:
      title: Collect Products for Purchase
      text: Products can be added to the shopping cart from their product card or product detail view. The cart supports multiple products from different sellers, automatically updates its counter and total, and uses the currency stored for the Horum account. Products that have already been purchased are marked accordingly and no longer display the normal cart action.

documentation:
  marketplace_checkout:
    title: Checkout
    intro: Checkout completes the purchase of the products previously selected in the shopping cart. It brings together the products, prices, fees, buyer and seller information, and the payment methods available for the respective purchase.
    overview:
      title: Checkout Overview
      text_1: Checkout takes the current product selection from the shopping cart and prepares the purchase for completion.
      text_2: The view is divided into product and price information, payment information, and buyer and seller information.
      list_1: Products and prices – displays the selected products and calculation of the total amount.
      list_2: Payment information – displays the payment methods available for the purchase and the required payment fields.
      list_3: Buyer and sellers – displays the buyer information and the sellers involved in the purchase.
    products:
      title: Products and Price Calculation
      text: Checkout displays the products transferred from the shopping cart together with the price calculation for the current purchase.
      list_1: Products – displays the products included in the current checkout.
      list_2: Subtotal – displays the total of the product prices included in the payment process.
      list_3: Transaction fee – a 4% transaction fee is displayed separately in checkout.
      list_4: Total – displays the final amount to be paid.
    buyer:
      title: Buyer Information
      text: The buyer information stored in the Horum account is displayed in checkout and associated with the current purchase.
      list_1: Buyer – displays the name of the buyer.
      list_2: Email – displays the email address associated with the buyer.
      list_3: Country – displays the country stored for the account.
      list_4: Currency – displays the currency used for the account.
    sellers:
      title: Sellers
      text_1: The right side of checkout displays the sellers whose products are included in the current purchase.
      text_2: If the shopping cart contains products from different sellers, multiple sellers can therefore be displayed within the same checkout.
    payment_methods:
      title: Payment Methods
      text_1: For paid purchases, one of the payment methods available for the respective purchase can be selected during checkout.
      text_2: Horum supports several payment methods. Which methods are actually offered depends, among other factors, on the region and their availability for the respective purchase.
      list_1: Card – payment using a supported credit or debit card.
      list_2: Google Pay – payment through Google Pay.
      list_3: PayPal – payment through PayPal.
      list_4: Alipay – payment through Alipay.
      list_5: Amazon Pay – payment through Amazon Pay.
      list_6: Cartes Bancaires – payment through the French Cartes Bancaires card payment system.
      list_7: iDEAL – payment through iDEAL.
      list_8: Link – payment using payment information stored in Link.
      list_9: MB WAY – payment through MB WAY.
      list_10: Satispay – payment through Satispay.
      list_11: TWINT – payment through TWINT.
      list_12: UPI – payment through UPI.
      list_13: WeChat Pay – payment through WeChat Pay.
    regional:
      title: Regional Availability
      text_1: Not every supported payment method is available in every region or for every purchase. Checkout only offers the payment methods that are available for the respective purchase.
      text_2: The payment methods displayed can therefore vary depending on the buyer's country or region.
    digital_content:
      title: Digital Content
      text_1: Before completing the purchase, the buyer must consent to the immediate provision of the digital content and confirm that the corresponding right of withdrawal is lost as a result of the immediate provision.
      text_2: Additional information about the immediate provision of digital content and the associated conditions can be accessed through “Learn more”.
    free:
      title: Free Products
      text_1: Free products are also processed through checkout so that the purchase or acquisition can be correctly associated with the user and the product.
      text_2: Special rules apply to free products during the payment process.
      list_1: Free products only – checkout is processed, but the actual payment process is skipped.
      list_2: Mixed checkout – if free and paid products are included in the same checkout, the free products are processed as part of the purchase but are not included in the amount to be paid.
    seller_split:
      title: Multiple Sellers and Earnings
      text_1: A checkout can contain products from multiple sellers. Earnings are assigned to the respective sellers based on the products they sold.
      text_2: After a successful purchase, the respective share from the sold products is credited to the associated seller's Wallet.
      list_1: Product assignment – each purchased product remains associated with its respective seller.
      list_2: Multiple sellers – if a purchase contains products from different sellers, the earnings are distributed accordingly among the participating sellers.
      list_3: Wallet – each seller receives the share assigned to their sold products in their Horum Wallet.
    purchase:
      title: Complete Purchase
      text_1: For a paid checkout, selecting “Pay Securely” continues the purchase using the selected payment method.
      text_2: After checkout has been processed successfully, the purchased products are assigned to the buyer. The subsequent process is described in the separate “Purchase Completion” documentation section.
    summary:
      title: Complete Your Purchase
      text: Checkout combines the selected products with price calculation, buyer and seller information, and the regionally available payment methods. Free products are also processed through checkout but do not trigger their own payment process. For purchases involving multiple sellers, the earnings are assigned to the respective sellers and credited to their Wallet.

documentation:
  checkout_success:
    title: Purchase Completion
    intro: After checkout has been completed successfully, the purchased products are confirmed and become available to the buyer. The products can then be managed and installed through Horum or downloaded directly when needed.
    overview:
      title: Successful Purchase
      text_1: After checkout has been processed successfully, the purchase is confirmed and the purchased products are assigned to the buyer's Horum account.
      text_2: The purchase completion page displays the successfully purchased products and provides further access to the purchased packages.
      list_1: Purchase confirmation – confirms that checkout has been completed successfully.
      list_2: Purchased products – displays the products acquired with the completed purchase.
      list_3: Dashboard – provides direct access back to the Horum Dashboard.
    products:
      title: Purchased Products
      text_1: Products acquired through checkout are displayed on the purchase completion page after the purchase has been completed successfully.
      text_2: Purchased products remain associated with the Horum account and are subsequently also available through the Dashboard and Horum.
    dashboard:
      title: Products in the Dashboard
      text_1: After the purchase, “Go to Dashboard” takes you directly back to your Horum Dashboard.
      text_2: Your purchased products remain associated with your account and can be viewed and managed through “My Horum”.
    package_manager:
      title: Installation Through Horum
      text_1: For normal use, it is recommended to download and install purchased packages directly through the Package Manager in Horum.
      text_2: This allows Horum to manage the purchased package and handle the intended installation process.
      list_1: Open Horum – start the Horum Application.
      list_2: Open Package Manager – open your purchased packages.
      list_3: Download package – download the purchased package directly through Horum.
      list_4: Install package – install the downloaded package through the Package Manager.
    manual_download:
      title: Manual Download and Backup
      text_1: In addition to the recommended management through the Horum Package Manager, a purchased package can also be downloaded directly when needed.
      text_2: The direct download primarily provides an additional way to keep your own backup of the purchased product file or make it available manually when required. The Horum Package Manager remains the recommended method for normal use.
      list_1: Direct download – the purchased product file can be downloaded after purchase.
      list_2: Backup – the downloaded file can be retained by the buyer as a personal backup.
      list_3: Manual use – when required, the downloaded package file can be made available to Horum manually.
    installation:
      title: Package Installation
      text_1: A purchased package must be downloaded and installed before it can be used in Horum. The recommended method is through the integrated Package Manager.
      text_2: If the manual download is used instead, the package file must be made available to Horum accordingly before installation can be performed.
    rating:
      title: Rate the Product After Use
      text_1: After a purchased package has been installed and used, the associated product can be rated through “My Horum”.
      text_2: The rating uses a slider from 1.0 to 5.0 stars and also supports intermediate values. A comment about the product can additionally be submitted.
    summary:
      title: After the Purchase
      text: After a successful purchase, the products are assigned to your Horum account and displayed on the purchase completion page. The Package Manager in Horum is recommended for downloading, managing and installing packages. Direct download of the purchased package file remains available as a backup and manual access option. After installation and use, the product can be rated through “My Horum”.

documentation:
  generators:
    title: Generators
    intro: The Generators area allows local models for creating and editing images and videos to be downloaded and installed. Horum can use installed generators for suitable tasks directly on the user's system while also evaluating whether the available hardware is suitable.
    purpose:
      title: Local Generators
      text_1: Local generators allow Horum to create or edit media such as images and videos directly on the user's system, provided that the respective generator supports the required function.
      text_2: Installing a generator does not mean that Horum will automatically use it. Which installed generators Horum can use for corresponding tasks is configured separately in the settings.
    models:
      title: Available Generators
      text_1: The available generators may change over time and can be expanded with additional models. The documentation is therefore not limited to a fixed list of specific generators.
      text_2: Each available generator is presented through its own card containing its properties, supported capabilities, requirements, ratings, and installation options.
    cards:
      title: Generator Card Structure
      text_1: Each generator card summarizes the most important information about an available local generator. This allows its capabilities and requirements to be assessed before downloading it.
      text_2: In addition to general model information, the card shows how Horum evaluates the generator's performance, speed, and suitability for the current system.
      name: Name: Displays the name of the generator.
      variant: Variant: Displays the provider or model family, model size, and the provided model variant.
      description: Description: Briefly describes the intended use and characteristics of the generator.
      capabilities: Capabilities: Shows which media tasks the generator supports, such as creating images or editing images.
      license: License: Displays the specified license and information about permitted use.
      plan: Plan: Shows whether the generator is available for the user's current Horum plan.
      storage: Storage: Displays the storage space required by the generator.
      ram: RAM: Displays the recommended amount of system memory and compares it with the currently detected RAM.
      hardware: Hardware: Displays relevant detected hardware information such as the graphics card and VRAM.
      system: System rating: Shows how suitable the user's current system is for the respective generator.
    capabilities:
      title: Generator Capabilities
      text_1: Generators can support different tasks. Their individual capabilities are displayed directly on the generator card and do not have to be identical for every generator.
      text_2: This allows Horum to determine which installed generator is generally suitable for a particular media task.
      image_generation: Create images: The generator can create new images.
      image_editing: Edit images: The generator can edit or modify existing images.
      video_generation: Create videos: A generator with the corresponding capability can create new video content.
      video_editing: Edit videos: A generator with the corresponding capability can edit existing video content.
    rating:
      title: Rating System
      text_1: The generator cards use a five-point rating system. Purple dots represent achieved rating levels, while gray dots represent the remaining levels.
      text_2: This provides a direct visual assessment of performance, expected speed, and the suitability of the user's own system.
      performance: Performance: 
      speed: Speed: 
      your_system: Your system: 
      poor:  Poor
      limited:  Limited
      good:  Good
      text_3: The point rating provides a compact visual assessment. The Your system rating takes the hardware conditions detected by Horum on the current computer into account.
    system_check:
      title: System Suitability
      text_1: Horum checks the user's hardware and compares it with the requirements of the respective generator. Each generator therefore receives a direct assessment of its suitability for the current system.
      text_2: This rating helps the user determine before installation whether a generator can reasonably be used with the available hardware.
      suitable: Suitable: The generator is well suited to the current system.
      limited: Limited: The generator may only be suitable for the current system with limitations.
      unsuitable: Not suitable: The generator is not recommended for the current system.
    hardware:
      title: Hardware Information
      text_1: Relevant hardware values from the current computer are taken into account for the system assessment and displayed directly on the generator card alongside the model's requirements.
      text_2: This allows the user to see not only the overall rating but also important hardware values behind the assessment.
      storage: Storage: Displays the storage requirement of the generator.
      recommended_ram: Recommended RAM: Displays the amount of system memory recommended for the generator.
      current_ram: Current RAM: Displays the amount of system memory detected on the user's computer.
      gpu: Graphics card: Displays the graphics hardware detected in the system.
      vram: VRAM: Displays the detected graphics memory of the graphics card.
    monitoring:
      title: Hardware Check
      text_1: Horum collects the system hardware information required for generator evaluation. These values are used to assess the suitability of the available local generators for the user's computer.
      text_2: The system rating can differ from one generator to another because different models have different requirements for system memory, graphics hardware, and available performance.
    details:
      title: Generator Details
      text_1: The Details button opens a separate information window for the selected generator. It describes the generator in understandable text and provides additional information before installation.
      text_2: The detail window is not a technical backend view. It provides user-relevant information about the generator, its intended use, and its capabilities.
      description: Description: Explains the generator and its general purpose.
      usage: Usage: Describes the media tasks and use cases for which the generator is suitable.
      capabilities: Capabilities: Explains which creation or editing functions the model supports.
      limitations: Limitations: May describe limitations or special requirements of the generator.
      terms: Terms of use: Refers to additional information and the terms that apply to the generator.
    hugging_face:
      title: Hugging Face Source
      text_1: The local generators are provided through Hugging Face. Hugging Face therefore serves as the external source for the local generator models offered by Horum.
      text_2: The associated Hugging Face page for a generator can be opened from the detail window. Additional information about the respective model is available there.
      text_3: Model descriptions, licenses, capabilities, and terms of use may differ between generators and can be reviewed on the respective model page when required.
    installation:
      title: Download and Installation
      text_1: The Install button starts the download and local installation of an available generator.
      text_2: Progress is displayed directly within the generator view so that the current state of the download can be followed.
      start: Install: Starts the download and installation of the selected generator.
      progress: Progress: A progress indicator displays the current state of the download.
      speed: Speed: The current download speed is displayed while the process is running.
      percentage: Percentage: The percentage value indicates how far the current download has progressed.
    activation:
      title: Installation and Use
      text_1: An installed generator is not automatically used by Horum. Installation and selection of available generators are separate processes.
      text_2: After installation, the generator can be selected in the corresponding model settings and made available to Horum. The tasks it can perform depend on the capabilities displayed on its generator card.
    plan:
      title: Availability by Plan
      text_1: The generator view takes the user's current Horum plan into account and indicates on each generator card whether the model is available for that plan.
      text_2: This makes it possible to see before downloading which of the offered local generators can be used with the current plan.
    summary:
      title: Summary
      text: The Generators area manages the download and installation of local models for creating and editing images and videos. Generator cards display capabilities, license, storage requirements, hardware requirements, and a five-level rating system. Horum checks the detected hardware and evaluates whether a generator is suitable, suitable with limitations, or not recommended for the current system. Detail windows provide understandable model information and can lead to the respective source on Hugging Face. Installed generators are not used automatically and are selected separately for Horum in the settings.

documentation:
  godseye_view:
    title: God's Eye View
    intro: God's Eye View extends Horum with an interactive spatial view based on a digital 3D globe. The extension allows Horum to visualize locations, geographic relationships, layers, and other spatial information and use them within its workflows.
    purpose:
      title: Purpose of God's Eye View
      text_1: God's Eye View serves as a spatial and geographic interface for Horum. Information can therefore be presented not only as text or through a traditional Result UI, but directly within an interactive spatial context.
      text_2: The extension is intended for tasks where locations, areas, movement, geographic data, or other spatial relationships are relevant to visualization and processing.
    extension:
      title: Extension for Horum
      text_1: God's Eye View is designed as an optional Horum extension and functionally remains part of the Horum system.
      text_2: The extension is not required by every user and can therefore be installed separately through the Marketplace. This means its additional functionality does not have to be included in the basic Horum installation.
      text_3: Once installed, God's Eye View becomes available to Horum as an additional visualization and working interface.
    capabilities:
      title: Capabilities
      text_1: God's Eye View provides Horum with an interactive spatial environment. Depending on the task, the interface can display different geographic information and visualizations.
      text_2: The content that is actually displayed and combined depends on the respective use case and the information required by Horum.
      globe: 3D globe: Geographic content can be displayed within an interactive three-dimensional world view.
      locations: Locations and positions: Specific positions and geographic areas can be displayed and included in the visible context.
      layers: Layers: Different types of information can be used as additional visual layers within the geographic view.
      navigation: Navigation: The view can be focused on relevant areas and moved through the spatial environment.
      actions: Actions: Horum can use defined actions to modify the visualization according to the current task.
      data: Data visualization: Spatially relevant information can be connected to the geographic view and displayed visually.
    cesium:
      title: CesiumJS
      text_1: The geographic 3D visualization of God's Eye View is based on CesiumJS. CesiumJS provides the technical foundation for the interactive globe and spatial visualization.
      text_2: This allows God's Eye View to use a browser-based 3D interface that can be displayed within the Horum integration and used by Horum for suitable tasks.
    horum:
      title: Integration with Horum
      text_1: God's Eye View is not intended to operate as a separate assistant, but as an additional capability and interface of Horum.
      text_2: Depending on the task, Horum determines when a spatial visualization is useful and how the available information should be presented within the interface.
      text_3: The extension is not restricted to a single form of presentation. God's Eye View can use its own interface while also working together with other Horum interfaces.
      own_window: Dedicated window: God's Eye View can be displayed in its own Horum interface for extensive spatial visualizations.
      result_ui: Result UI: Specific information or supplementary output can additionally be displayed through Horum's Result UI.
      control: Horum control: Horum can use the spatial interface according to its current task and control the required visualization.
    webview:
      title: WebView Integration
      text_1: A generic WebView concept is planned for web-based interfaces within the Horum Result UI. It can display not only regular websites, but also local HTML and JavaScript applications.
      text_2: God's Eye View can use this capability to provide its CesiumJS-based interface within a Horum interface.
      text_3: This allows the spatial application to remain compatible with Horum's existing system of workflows, Result UI, and dynamically generated interfaces.
    actions:
      title: Interaction with the View
      text_1: God's Eye View is designed for dynamic visualization. Horum can align the view with information relevant to the current task.
      text_2: The same interface can therefore be used for different geographic and spatial tasks without requiring a completely separate interface for every use case.
      camera: Camera: The visible perspective can be focused on an area relevant to the current task.
      location: Position: Locations or geographic positions can be brought into focus within the view.
      layers: Layers: Additional visualization layers can be used depending on the information required.
      visualization: Visualization: The visible presentation can be adapted to the data and the respective workflow.
    repository:
      title: Technical Foundation
      text_1: God's Eye View uses a web-based architecture for its interactive geographic visualization. This allows the interface to be developed as a specialized application independently of traditional PyQt5 widgets.
      text_2: The technical structure provides the foundation for the later direct integration of the extension into Horum.
      cesium: CesiumJS: Provides the interactive 3D globe and the fundamental geographic visualization functions.
      javascript: JavaScript: Controls the web-based application and its interactive functions.
      vite: Vite: Is used for the development and delivery of the web-based application.
      actions: Actions: Defined functions allow the spatial visualization to be controlled and modified.
      embed: Embedding: The web application is intended for later display within Horum interfaces.
    marketplace:
      title: God's Eye View in the Marketplace
      text_1: God's Eye View will have its own area within the Horum Marketplace. Users can install the extension there when required without making it part of every Horum installation.
      text_2: The Marketplace view is focused on the information and actions required for this extension.
      details: Details: Opens additional information about God's Eye View, its capabilities, and its intended use.
      install: Install: Downloads the required extension and installs it for use with Horum.
    installation:
      title: Installation
      text_1: God's Eye View is intended as an optional installation. Users who do not require its spatial capabilities therefore do not need to install the extension.
      text_2: Keeping the installation separate allows the basic Horum installation to remain smaller while God's Eye View can be added as an additional functional area when required.
      text_3: The exact technical installation and integration logic will be defined further as the extension is implemented and can be expanded accordingly.
    optional:
      title: Optional Functional Area
      text_1: Optional distribution separates the additional scope of God's Eye View from Horum's core functionality. Horum therefore remains fully usable for its other tasks without the extension being installed.
      text_2: Once installed, God's Eye View extends the existing Horum interfaces with specialized spatial visualization without operating as a separate assistant alongside Horum.
    summary:
      title: Summary
      text: God's Eye View extends Horum with an interactive spatial and geographic interface based on CesiumJS. Horum can use the 3D globe for locations, positions, layers, navigation, and spatial data visualizations and control the presentation according to its current task. The extension can use its own interface and work together with the Result UI. It is installed optionally through the Horum Marketplace, adding geographic capabilities to Horum without requiring it to be part of every basic installation.

documentation:
  llm_model:
    title: LLM Model
    intro: The LLM Model area allows local language models for Horum to be downloaded and installed. Horum provides information about the available models, evaluates their requirements, and checks whether the user's system is suitable for running them.
    purpose:
      title: Local Language Models
      text_1: Local LLMs allow Horum to use a language model installed on the user's own system for understanding, reasoning, and performing tasks.
      text_2: Installing a model does not automatically activate it. The installed model used as the active primary model is selected separately in the settings.
    models:
      title: Available Models
      text_1: The available language models may change and expand over time. The model overview is therefore not limited to a fixed list of specific models.
      text_2: Instead, each available model is presented through its own model card containing its properties, requirements, ratings, and installation options.
    cards:
      title: Model Card Structure
      text_1: Each model card summarizes the most important information about an available language model. This allows models and their requirements to be assessed before downloading them.
      text_2: In addition to general model information, the card shows how Horum evaluates the model itself and its suitability for the current system.
      name: Name: Displays the name of the language model.
      variant: Variant: Displays the model family, model size, and the provided model variant or quantization.
      description: Description: Briefly describes the intended use and characteristics of the model.
      capability: Capability: Shows which basic tasks the model is intended for, such as understanding text.
      license: License: Displays the specified model license and information about permitted use.
      plan: Plan: Shows whether the model is available for the user's current Horum plan.
      storage: Storage: Displays the storage space required by the model.
      ram: RAM: Displays the recommended amount of system memory and compares it with the current system.
      hardware: Hardware: Displays detected relevant hardware information such as the graphics card and VRAM.
      system: System rating: Shows how suitable the user's current system is for the respective model.
    rating:
      title: Rating System
      text_1: The model cards use a five-point rating system. Purple dots represent achieved rating levels, while gray dots represent the remaining levels.
      text_2: This provides a quick visual comparison of model performance, expected speed, and the suitability of the user's own system.
      performance: Performance: 
      speed: Speed: 
      your_system: Your system: 
      poor:  Poor
      limited:  Limited
      good:  Good
      text_3: The point rating provides a compact visual assessment. In particular, the Your system rating takes the hardware conditions detected by Horum on the current computer into account.
    system_check:
      title: System Suitability
      text_1: Horum checks the user's hardware and compares it with the requirements of the respective model. Each model therefore receives an additional assessment of its suitability for the current system.
      text_2: This rating helps the user determine before installation whether a model can reasonably be used with the available hardware.
      suitable: Suitable: The model is well suited to the current system.
      limited: Limited: The model may only be suitable for the current system with limitations.
      unsuitable: Not suitable: The model is not recommended for the current system.
    hardware:
      title: Hardware Information
      text_1: Relevant hardware values from the current computer are taken into account for the system assessment and displayed directly on the model card alongside the model's requirements.
      text_2: This allows the user to see not only the overall rating but also important values behind the assessment.
      storage: Storage: Displays the storage requirement of the model.
      recommended_ram: Recommended RAM: Displays the amount of system memory recommended for the model.
      current_ram: Current RAM: Displays the amount of system memory detected on the user's computer.
      gpu: Graphics card: Displays the graphics hardware detected in the system.
      vram: VRAM: Displays the detected graphics memory of the graphics card.
    monitoring:
      title: Hardware Check
      text_1: Horum collects the system hardware information required for model evaluation. These values are used to assess the suitability of the available local models for the user's computer.
      text_2: The system rating can therefore differ from one model to another because different language models have different memory and hardware performance requirements.
    details:
      title: Model Details
      text_1: The Details button opens a separate information window for the selected model. It describes the model in understandable text and provides additional guidance before installation.
      text_2: The detail window is not a technical backend view. It provides user-relevant information about the model, its intended use, and its characteristics.
      description: Description: Explains the model and its general purpose.
      usage: Usage: Describes the tasks and use cases for which the model is suitable.
      capabilities: Capabilities: Explains relevant strengths and capabilities of the model.
      limitations: Limitations: May describe limitations or special requirements of the model.
      terms: Terms of use: Refers to additional information and the terms that apply to the model.
    hugging_face:
      title: Hugging Face Source
      text_1: The local language models are provided through Hugging Face. Hugging Face therefore serves as the external source for the local models offered by Horum.
      text_2: The associated Hugging Face page for a model can be opened from the detail window. Additional information about the respective model is available there.
      text_3: Model descriptions, licenses, and terms of use may differ between models and can be reviewed on the respective model page when required.
    installation:
      title: Download and Installation
      text_1: The Install button starts the download and local installation of an available language model.
      text_2: Progress is displayed directly within the model view so that the current state of the download can be followed.
      start: Install: Starts the download and installation of the selected local model.
      progress: Progress: A progress indicator displays the current state of the download.
      speed: Speed: The current download speed is displayed while the process is running.
      percentage: Percentage: The percentage value indicates how far the current download has progressed.
    activation:
      title: Installation and Use
      text_1: An installed model does not automatically become Horum's active language model. Installation and active model selection are separate processes.
      text_2: After installation, a model can be selected as the active primary model in the model settings. This configuration determines which local model Horum actually uses.
    plan:
      title: Availability by Plan
      text_1: The model view takes the user's current Horum plan into account and indicates on each model card whether the model is available for that plan.
      text_2: This makes it possible to see before downloading which of the offered local models can be used with the current plan.
    summary:
      title: Summary
      text: The LLM Model area manages the download and installation of local language models for Horum. Model cards display characteristics, license, storage requirements, hardware requirements, and a five-level rating system. Horum checks the detected hardware and evaluates whether a model is suitable, suitable with limitations, or not recommended for the current system. Detail windows provide understandable model information and can lead to the respective source on Hugging Face. An installed model is not used automatically and must be selected separately in the model settings.

documentation:
  marketplace_overview:
    title: Marketplace
    intro: The Horum Marketplace is the central platform for discovering, purchasing, and publishing extensions for Horum. Products can be offered by other users and companies and can then be used directly with the user's own Horum account.
    about:
      title: The Horum Marketplace
      text_1: The Marketplace extends Horum with content, functionality, designs, and complete packages that can be published by sellers.
      text_2: This allows users to extend Horum with additional components without having to create them themselves.
      list_1: Discover – browse published products from other users and companies.
      list_2: Purchase – add free or paid products to your own Horum account.
      list_3: Use – download, install, and manage purchased packages through Horum.
      list_4: Publish – create your own Horum products and offer them on the Marketplace as a seller.
    product_types:
      title: Product Types
      text: Different types of Horum extensions can be offered on the Horum Marketplace. The product type indicates which area of Horum a product extends or modifies.
      list_1: Complete package – combines multiple Horum components within a single package.
      list_2: Personality – extends or modifies Horum's personality, behavior, rules, and character.
      list_3: Horum Window – modifies or extends the appearance of the Horum Window.
      list_4: Worker UI – provides a working interface for specific tasks and workflows within Horum.
      list_5: Result UI – provides an interface for displaying and interacting with results.
      list_6: Core – modifies the visual appearance and animation of the Horum Core.
      list_7: Commands – extends Horum with additional commands and associated capabilities.
    discovery:
      title: Discover Products
      text_1: Products can be searched, filtered, and sorted through the Marketplace overview. This allows the displayed product selection to be narrowed down precisely.
      text_2: The available filters and sorting options take various properties of published products into account.
      list_1: Search – find products using a search term.
      list_2: Filters – narrow products by properties including language, category, file type, content, price, and size.
      list_3: Sorting – sort products using properties such as price or rating.
    product_cards:
      title: Product Cards
      text_1: Each product is displayed in the Marketplace through a product card. The overview already shows key information such as product image, language, content and file types, file size, seller, title, description, creation date, rating, number of purchases, price, and purchase status.
      text_2: The product card can be used to open the detailed product view or add a product that has not yet been purchased directly to the shopping cart.
    pricing:
      title: Prices and Currencies
      text_1: Products on the Marketplace can be offered for free or for a price. The seller determines the price of a product when it is published.
      text_2: Paid products are displayed to the buyer in the currency stored for their Horum account.
      list_1: Free – products can be offered without a product price.
      list_2: Paid – sellers can set a price for their product.
      list_3: Currency – prices are converted regionally based on the account currency and the current API exchange rate.
    purchase:
      title: Purchase Products
      text_1: Products can first be added to the shopping cart and then purchased together through checkout. A shopping cart can also contain products from different sellers.
      text_2: Free products are also processed through checkout but do not require an actual payment process.
      list_1: Select product – choose a desired product through the product card or detail view.
      list_2: Shopping cart – add one or more products that have not yet been purchased to the cart.
      list_3: Checkout – review products, prices, buyer and seller information and, for paid products, use an available payment method.
      list_4: Purchase completion – after successful checkout, the purchased products are assigned to the Horum account.
    library:
      title: Purchased Products
      text_1: A purchased product remains assigned to the buyer's Horum account and can then be viewed and managed through the dashboard under My Horum.
      text_2: For packages, downloading and installation through the Package Manager in Horum is recommended. The purchased package file can additionally be downloaded directly and kept as a personal backup when required.
    sellers:
      title: Sellers
      text_1: Products can be published by sellers on the Horum Marketplace. The respective seller is displayed with the product and remains associated with the published product.
      text_2: After a successful sale, the seller's share from sold products is credited to their Horum Wallet.
      list_1: Own products – sellers can create Horum products and publish them through the Marketplace.
      list_2: Product management – published products can be managed through the dashboard.
      list_3: Revenue – revenue from sold products is assigned to the respective seller's Wallet.
    ratings:
      title: Ratings
      text_1: Purchased and installed products can be rated after use. Ratings use a slider from 1.0 to 5.0 stars and also support intermediate values. A comment can additionally be submitted.
      text_2: Published ratings are associated with the respective product and help other users evaluate it. The average rating can also be used to sort products in the Marketplace.
    horum:
      title: Connection with Horum
      text_1: The Marketplace is directly connected to the Horum system. Purchased products are assigned to the account and can then be used in the Horum Application.
      text_2: The website, dashboard, Marketplace, and Horum Application therefore form a shared workflow from product selection through installation and use.
      list_1: Account – purchases and products are assigned to the Horum account.
      list_2: Dashboard – purchased products can be viewed and managed under My Horum.
      list_3: Horum Application – packages can be downloaded, installed, and used through the Package Manager.
    summary:
      title: Extend Horum
      text: The Horum Marketplace connects buyers and sellers of Horum extensions. Users can discover, compare, and purchase different product types and then use them with their Horum account. Sellers can publish their own extensions and earn revenue from their products. This allows Horum to be individually extended with additional personalities, interfaces, cores, commands, and complete packages.
  marketplace_application_overview:
    title: Marketplace
    intro: The Marketplace within the Horum Application connects the Horum account with purchased packages, the user's own products, package exports, and additional local models and extensions. It therefore serves as the central interface for managing and extending the local Horum installation.
    marketplace:
      title: Marketplace in the Horum Application
      text_1: While the Marketplace on the website is primarily used to discover, compare, and purchase products, the Marketplace interface in the Horum Application handles the local management and deployment of purchased content.
      text_2: Additional areas are available for the user's own products, package exports, local LLM models, generators, and other Horum extensions.
      list_1: Manage packages – validate, download, install, import, or remove purchased Horum packages.
      list_2: Create content – export your own Horum content as .hrm packages for backup, exchange, or publication.
      list_3: Extend Horum – install local LLM models, generators, and additional extensions.
    overview:
      title: Overview
      text_1: The overview summarizes central information from the signed-in Horum account and its associated Marketplace and Horum content.
      text_2: This gives the user a quick overview of their plan, Marketplace activity, and available Horum components directly within the Application.
    account:
      title: Account Information
      text: The upper area displays central account and Marketplace information as individual overview cards.
      plan: Plan – displays the Horum plan currently associated with the account.
      conversations: Conversations – displays the number of conversations associated with the account.
      purchased: Purchased products – displays the number of products acquired through the Marketplace.
      wallet: Wallet – displays the current Wallet balance of the account.
      created: Created products – displays the number of Marketplace products published or created by the user.
      version: Horum – displays the currently used Horum version.
    components:
      title: Horum Components
      text_1: The overview additionally displays the number of available or installed Horum components by type.
      text_2: This makes it immediately visible which types of extensions are currently present within the Horum installation.
      personalities: Personalities – displays the available personality packages.
      horum_windows: Horum Windows – displays available extensions for Horum Window configuration.
      worker_ui: Worker UIs – displays available working interfaces.
      result_ui: Result UIs – displays available result interfaces.
      core: Cores – displays available Core extensions.
      commands: Commands – displays available command packages.
      packages: Complete packages – displays packages containing multiple Horum components together.
    packages:
      title: My Packages
      text_1: My Packages manages Horum packages purchased with the account and their local state. Downloaded and installed are two independent statuses.
      text_2: Packages can be processed individually or together when their statuses match. For example, an installed package can be removed from the download area without removing its already installed files.
      status: Status – shows whether a package is installed, downloaded, downloadable, or unavailable.
      validation: Validate – checks package integrity and the stored SHA values before installation.
      download: Download – downloads a purchased package locally or removes an already downloaded package file.
      installation: Installation – installs a valid package or uninstalls content that has already been installed.
      import: Import – adds an existing package file to Horum and marks it as downloaded, but not automatically as installed.
    products:
      title: My Products
      text_1: My Products mirrors the user's own Marketplace products within the Horum Application. This area is therefore particularly relevant to sellers.
      text_2: It displays information including total products, active and inactive products, downloads, and the most important details of individual published products.
    export:
      title: Package Export
      text_1: Package Export allows the user's own Horum content to be selected and generated as a Horum package in the .hrm format.
      text_2: An export can contain a single Horum area or combine multiple different areas into one package.
      personality: Personality – exports selected language-specific Soul, Rules, and Forbidden files.
      horum_window: Horum Window – exports selected Horum Window configuration content.
      worker_ui: Worker UI – exports selected working interfaces.
      result_ui: Result UI – exports selected result interfaces.
      commands: Commands – exports selected command content.
      core: Core – exports selected Core content such as animation, geometry, or colors.
      package: Package – combines multiple selected export types and their content into a single .hrm file.
    models:
      title: Local Models
      text_1: The Marketplace provides areas for installing local LLM models and generators. The specific models offered can change and be expanded over time.
      text_2: Before installation, Horum displays information about capabilities, storage requirements, and hardware requirements and evaluates the suitability of the current system.
      llm: LLM models – local language models for understanding, reasoning, text processing, and other AI tasks.
      generators: Generators – local models for supported media tasks such as image or video generation and editing.
      hardware: Hardware rating – Horum compares model requirements with detected hardware and evaluates system suitability.
    godseye:
      title: God's Eye View
      text_1: God's Eye View is planned as an optional Horum extension and adds an interactive spatial and geographic interface based on a 3D globe.
      text_2: The extension receives its own Marketplace area and can be installed separately when required. Its additional functionality therefore does not have to be part of every basic Horum installation.
    activities:
      title: Recent Activities
      text_1: The overview contains a list of recent account and Marketplace activities. Each entry displays the respective activity together with its date and time.
      text_2: This allows recent events such as sign-ins, recent activity, or product purchases to be reviewed directly within the Horum Application.
    website:
      title: Connection with the Web Marketplace
      text_1: The website and Horum Application use the same Horum account and together form the complete Marketplace workflow.
      text_2: The responsibilities of both areas complement each other: the website primarily handles product discovery and purchasing, while the Application deploys and manages purchased content locally.
      discovery: Website – discover and compare products, view detailed information, and read ratings.
      purchase: Purchase – add products to the Horum account through the shopping cart and checkout.
      application: Horum Application – download, validate, install, and use purchased packages within Horum.
    summary:
      title: Connecting Marketplace and Horum
      text: The Marketplace within the Horum Application connects the Horum account with locally usable extensions. The overview displays account data, Marketplace information, available Horum components, and recent activity. Purchased packages can be managed and installed, the user's own products can be viewed, and Horum content can be exported as .hrm packages. Local LLM models, generators, and optional extensions such as God's Eye View can also be provided.

documentation:
  package_export:
    title: Package Export
    intro: Package Export allows users to select their own content from Horum Main and export it as a Horum package in the .hrm format. Depending on the export type, individual resources or multiple different Horum components can be combined into a single package.
    purpose:
      title: Purpose of Package Export
      text_1: Package Export prepares the user's own Horum content for distribution, backup, or publication on the Horum Marketplace.
      text_2: The user determines which available content is exported. Horum validates the selection, creates the package, and generates the information required for integrity checks and later publication.
    workflow:
      title: Export Workflow
      text_1: An export is configured step by step, reviewed, and then created by the Package Generator.
      name: Define a unique name for the export.
      type: Select the appropriate export type.
      content: Select the content that should be included in the export.
      path: Choose the directory in which the export should be created.
      review: Review and confirm the assembled selection before creation.
      generate: Start the Package Generator and create the .hrm package.
    configuration:
      title: Configure Export
      text_1: The basic properties of the export are defined in the first step. The available content options dynamically adapt to the selected export type.
      text_2: This ensures that only content intended for the respective export type is offered for selection.
      name: Name: Defines the name of the export.
      type: Export type: Determines which type of Horum content should be exported.
      content: Content: Allows selection of the specific files or resources for the selected export type.
      path: Export path: Determines the location where the generated export files are stored.
    types:
      title: Export Types
      text_1: The export type determines which Horum area the content comes from and which selection options become available afterwards.
      text_2: In addition to individual component types, a complete package can be created that combines multiple different component types.
      personality: Personality: Exports selected Personality content such as Soul, Rules, and Forbidden.
      window: Horum Window: Exports the selected design settings for Horum Windows.
      worker_ui: Worker UI: Exports selected Worker UI resources.
      result_ui: Result UI: Exports selected Result UI resources.
      commands: Commands: Exports selected command resources.
      core: Core: Exports selected Core settings.
      package: Package: Combines multiple selected export types and their content into a single Horum package.
    content:
      title: Select Content
      text_1: The content selection is dynamically generated according to the selected export type. An export therefore does not automatically have to contain every available file from an area.
      text_2: Checkboxes can be used to select individual components. This makes it possible to export only a specific component or a combination of multiple available contents.
      text_3: The actual selection determines which files are later included in the generated Horum package.
    personality:
      title: Exporting a Personality
      text_1: When exporting a Personality, the available Personality files can be selected individually. A Personality therefore does not necessarily have to consist of all three possible Markdown files.
      text_2: Only the selected Personality components are included in the export.
      soul: Soul: Exports the selected soul.md.
      rules: Rules: Exports the selected rules.md.
      forbidden: Forbidden: Exports the selected forbidden.md.
      combination: Combination: Soul, Rules, and Forbidden can be selected individually, in pairs, or all together.
    language:
      title: Language of Personality Files
      text_1: When exporting a Personality, the language area from which the Markdown files should be taken is also selected. This selection applies exclusively to the language-specific Personality files.
      text_2: Personality files are edited separately for each language. If the user uses Horum in German, for example, they edit the German versions of Soul, Rules, and Forbidden. An English file may therefore be empty or contain different content if it has not previously been maintained accordingly.
      text_3: Language separation allows creators to provide their Personality content in understandable versions for different languages. This also allows a future buyer to understand which rules, personality characteristics, and restrictions a resource contains.
      german: German: Uses the German Personality files from the corresponding language area.
      english: English: Uses the English Personality files from the corresponding language area.
      llm: LLM language: This selection does not determine which language an LLM can use or respond in. It applies exclusively to the language-specific Markdown files being exported.
    package_type:
      title: Package Export Type
      text_1: The Package export type allows multiple different Horum components to be combined into a single .hrm package.
      text_2: After selecting Package, the desired component types can be marked. The selected types then determine which resources are offered in the content selection.
      personality: Personality: Adds selected Personality content to the package.
      window: Horum Window: Adds selected window designs to the package.
      worker_ui: Worker UI: Adds selected Worker UI resources to the package.
      result_ui: Result UI: Adds selected Result UI resources to the package.
      commands: Commands: Adds selected command resources to the package.
      core: Core: Adds selected Core settings to the package.
    package_content:
      title: Combined Package Content
      text_1: When multiple component types are selected for the Package export type, the content selection expands to include the available resources from those areas.
      text_2: The user can then determine which specific contents from the selected types should actually be combined in the package.
      text_3: A single Horum package can therefore combine Personality, window design, Worker UI, Result UI, Commands, and Core content.
    source:
      title: Content from Horum Main
      text_1: The user's own content from Horum Main is used for export. The resources available there form the source for the selectable export content.
      text_2: Package Export therefore converts the user's own content, or content available within Horum Main, into a portable and publishable Horum package.
    validation:
      title: Validate Selection
      text_1: Before package creation, Horum checks whether the selected export types and content actually exist and can be used for the export.
      text_2: When using the Package export type in particular, only component types for which corresponding content exists within Horum Main should be selected.
      available: Available content: Selected resources must actually be available within Horum Main.
      empty: Empty type: If a component type is selected for a package but no corresponding content exists, validation fails.
      selection: Valid selection: Only existing and correctly selected content can be passed to the Package Generator.
    review:
      title: Review Package
      text_1: Before actual generation, the Package Generator displays the assembled selection once more for review.
      text_2: This allows the user to verify that the name, export type, language, content, storage location, and files match the intended configuration before confirming creation.
      name: Package name: Displays the defined name of the export.
      type: Export type: Displays the selected export type.
      language: Personality language: Displayed accordingly when language-specific Personality content is included.
      content: Content: Displays the selected components or contents.
      path: Storage location: Displays the selected output directory.
      files: Files: Displays the files that will be included in the export based on the selection.
    generator:
      title: Generate Package
      text_1: After confirmation, the actual generation process begins. The Package Generator performs the required processing steps one after another and creates the Horum package.
      text_2: During generation, the individual steps and current progress are displayed in the process window. This makes it possible to follow which processing step is currently being performed.
      text_3: If a step fails, the failure can be identified in the generation process. When processing completes successfully, the result is reported accordingly.
    hrm:
      title: The Generated HRM Package
      text_1: The result of the Package Generator is a Horum file with the .hrm extension. It contains the selected content in the package structure intended for Horum.
      text_2: In addition to the actual resources, the package contains the required files that allow Horum to process the package structure, integrity information, and associated package information.
      content: Content: Contains the Horum resources selected beforehand.
      manifests: Manifest files: Describe the structure and components contained in the package.
      license: License: The required Horum license is included in the package.
      information: Information files: Additional package information is included for further processing.
    integrity:
      title: SHA and Package Integrity
      text_1: During export, the files inside the package are recorded using their SHA checksums. These values allow Horum to later verify whether the exported files still exactly match their state at the time the package was created.
      text_2: Modifying a recorded file afterwards changes its checksum. The package will then no longer match the integrity information stored during export.
      text_3: A package modified in this way does not pass the required validation checks and therefore cannot be processed normally.
      sha: SHA checksums: Package files are recorded with their checksums and can later be checked for an exact match.
      modified: Subsequent modification: If a recorded file is changed after export, its checksum no longer matches the stored information.
      import: Import: The integrity of an HRM package can also be checked against the stored information during import.
      marketplace: Marketplace: Publication also verifies that the supplied package matches the expected and unchanged data.
    export_manifest:
      title: Export Manifest
      text_1: In addition to the generated .hrm package, an export_manifest.json is created outside the package. This Export Manifest is required for later publication of the export as a product.
      text_2: The external Export Manifest describes the associated export and must match the package and its product.
      text_3: Without a valid export_manifest.json matching the export, the export cannot be published as a product on the Horum Marketplace.
      external: Separate file: The export_manifest.json is provided outside the generated HRM file in addition to the package.
      match: Matching data: The Export Manifest must correspond to the associated export and its product data.
      required: Publication: The matching Export Manifest is required to create or publish a Marketplace product.
    marketplace:
      title: Publishing on the Marketplace
      text_1: A completed export can subsequently be used to create a product on the Horum Marketplace. The generated HRM package and its corresponding Export Manifest are required for this process.
      text_2: Integrity and manifest validation ensure that the data provided for the product matches the export that was originally generated.
    summary:
      title: Summary
      text: Package Export converts selected content from Horum Main into a Horum package in the .hrm format. The export type and content selection determine which resources are included, while the Package type can combine multiple components. Personality files are exported by language without defining the language of the LLM. The selection is validated before creation and then processed by the Package Generator. SHA checksums protect the integrity of exported files, and the additionally generated export_manifest.json is required for later product publication on the Horum Marketplace.

documentation:
  packages:
    title: My Packages
    intro: The My Packages page displays all packages purchased through the Horum Marketplace together with their current download, installation, and availability status. Packages can be searched, filtered, validated, downloaded, installed, imported, and managed here.
    purpose:
      title: Package Management
      text_1: My Packages is the central management area for purchased Horum packages within the application. The overview includes packages already in use as well as packages that can still be downloaded or installed.
      text_2: Download and installation are handled separately. A package can therefore be downloaded but not yet installed, or already installed while its downloaded HRM file has subsequently been deleted.
    filters:
      title: Filters and Search
      text_1: The package overview can be filtered by different states and product types. A search field is also available to locate specific packages more quickly.
      text_2: Status and type filters can be used to limit the displayed package list to the content currently relevant to the user.
      status: Status: Filters packages by states including installed, not installed, downloaded, not downloaded, available, and unavailable.
      type: Type: Filters by complete packages, personalities, Worker UI, Result UI, commands, or cores.
      search: Search: Searches the available packages using the entered search term.
    status:
      title: Package Status
      text_1: The current state of a package is displayed compactly as a status icon in the table. The legend above the package overview explains the icons being used.
      text_2: Download status, installation status, and availability are separate properties. A single package can therefore have multiple states relevant to its management at the same time.
      installed: Installed: The package has been installed and its components are located in the designated Horum package paths.
      downloaded: Downloaded: The HRM package file is available locally.
      downloadable: Downloadable: The package is available for download.
      unavailable: Unavailable: The package is currently not available for another download.
    table:
      title: Package Overview
      text_1: The table displays the most important information about purchased packages directly in the overview. A package can be clicked to open its detailed information on the right.
      text_2: The checkboxes can also be used to select multiple packages for shared actions.
      checkbox: Checkbox: Selects one or more packages for possible batch actions.
      image: Image: Displays the preview image associated with the package or product.
      name: Name: Displays the name of the purchased package.
      type: Type: Displays the product type of the package.
      files: Files: Displays the file types or contents included in the package.
      size: Size: Displays the size of the package.
      purchase_date: Purchase date: Displays the date on which the package was purchased.
      status: Status: Displays the current package status as an icon. The meaning of the icons is shown in the legend.
    details:
      title: Package Details
      text_1: Clicking a package displays more detailed information about the selected package on the right side.
      text_2: The detail view combines product information with the current local state of the package and the actions currently available.
      name: Name: Displays the full name of the selected package.
      image: Image: Displays the preview image of the product.
      description: Description: Displays the description of the selected package.
      type: Type: Displays the internal product type of the package.
      size: Size: Displays the size of the package file.
      purchase_date: Purchase date: Displays the purchase date of the package.
      download_status: Status: Displays the current download status of the package.
      availability: Availability: Displays whether the package is currently available or downloadable.
    license:
      title: License
      text_1: The License button opens the license that applies to Horum packages in a Markdown window where it can be read.
      text_2: This is not an individual license for the selected package. All packages use the same fixed Horum license.
    elements:
      title: Elements
      text_1: The Elements area shows which contents or file types are included in the selected package.
      text_2: This makes it possible to see directly from the detail view which components make up the respective package.
    download_install:
      title: Downloaded and Installed
      text_1: The download status and installation status of a package are two independent states. Downloaded only means that the HRM package file is available locally.
      text_2: Installed, on the other hand, means that the contained components have been processed and installed into their designated Horum package paths.
      downloaded: Downloaded: The package's HRM file is located in the local download area.
      installed: Installed: The package components have been installed from the HRM file and are located in their respective installation paths.
      independent: Independent states: A package can be downloaded and not installed, downloaded and installed, or installed even though the originally downloaded HRM file has subsequently been deleted.
    actions:
      title: Package Actions
      text_1: The available buttons in the detail view dynamically adapt to the current state of the selected package.
      text_2: This ensures that only actions appropriate for the respective download and installation status are offered.
      validate: Validate: Checks the package and its integrity before it is used for installation.
      download: Download: Downloads the HRM package file if it is not yet available locally.
      delete: Delete: If the package has already been downloaded, the local HRM file can be deleted again.
      install: Install: Installs the components contained in the package if the package passes the required checks.
      uninstall: Uninstall: If the package is already installed, the installation can be removed again.
    delete_after_install:
      title: Deleting the Package File After Installation
      text_1: An installed HRM package file does not have to remain permanently in the download area. After a successful installation, the downloaded package file can be deleted without removing the installation.
      text_2: The download path and installation paths are separate. The installed components therefore remain available until the package is explicitly uninstalled.
    batch:
      title: Batch Actions
      text_1: The checkboxes in the package list can be used to select multiple packages at the same time. Shared actions can then be performed for compatible selections.
      text_2: For a batch action to be available, the relevant states of the selected packages must match. Packages with incompatible states are not combined into a shared package action.
      download: Batch download: Multiple matching packages can be downloaded together.
      delete: Batch delete: Multiple downloaded package files can be deleted together.
      install: Batch installation: Multiple matching and installable packages can be installed together.
      uninstall: Batch uninstall: Multiple installed packages can be uninstalled together.
      requirement: Requirement: The selected packages must have matching states for the requested action.
    import:
      title: Importing Packages
      text_1: Import can be used to add an existing HRM package file to the package management system.
      text_2: A successfully imported package is treated as downloaded but is not automatically installed. Download status and installation status remain separate when importing a package.
    validation:
      title: Validation and Integrity Check
      text_1: Before installation, the integrity of the package is checked. The expected SHA checksums are compared with the package files that are actually present.
      text_2: Differences are not accepted. A package that fails validation is immediately excluded from installation.
      integrity: Integrity: The package structure and files intended for installation are checked.
      sha: SHA check: Stored checksums are compared with the files actually present in the package.
      block: Mismatch: If the checked values do not match, the package cannot be installed.
      redownload: Download again: A package that fails its integrity check must be downloaded again before installation can be attempted again.
    security:
      title: Package Security
      text_1: The integrity check is designed to prevent modified or incorrect HRM package files from being used for installation. A mismatch between expected and actual package data therefore causes the installation to be rejected.
      text_2: This protects the Horum installation process from package files whose contents no longer match the expected and verified state.
    reviews:
      title: Ratings and Reviews
      text_1: Purchasing a product alone is not sufficient to review it. The associated product can only be rated after its package has been successfully installed at least once.
      text_2: The actual rating and review are submitted through the Horum website. The user must be signed in to their Horum account.
      installation: Installation required: The package must have been successfully installed at least once before the product can be reviewed.
      login: Login required: The user must be signed in to submit a rating or review.
      website: Website: Product ratings and reviews are submitted through the Horum Marketplace on the website.
    summary:
      title: Summary
      text: My Packages manages all purchased Horum packages while keeping download, installation, and availability clearly separated. Packages can be filtered, searched, imported, validated, downloaded, installed, deleted, and uninstalled. Multiple packages can be processed together when their states match. Integrity and SHA checks protect installation from mismatching HRM files, while product reviews become available only after a successful first installation and require a signed-in user.

documentation:
  marketplace_product:
    title: Product Details
    intro: Products are displayed in the Horum Marketplace using product cards. Each card shows the most important product information, seller, technical details, rating, purchase count, price and current purchase status.
    overview:
      title: Product Card
      text_1: Every published product has its own product card. It provides a compact overview of the product and its most important properties directly within the Marketplace overview.
      text_2: From the product card, you can view the product in more detail or, if it has not already been purchased, add it directly to the shopping cart.
    image:
      title: Product Images
      text_1: The product images provided by the seller are displayed in the upper area of the product card. They provide a visual representation of the product and can, for example, show its design, interface or intended purpose.
      text_2: A product can contain one or multiple product images.
      list_1: Product image – displayed prominently in the upper area of the product card.
      list_2: Multiple images – several images can be provided for the same product.
      list_3: AI-generated images – are identified by an additional label directly on the image.
    image_slider:
      title: Multiple Product Images
      text_1: If multiple images are available for a product, the image area is displayed as a slider.
      text_2: The slider allows you to switch between the different product images without leaving the product card or product view.
    ai_image:
      title: AI-Generated Image Label
      text_1: If a seller uses an AI-generated image to present a product, the image must be marked accordingly as AI-generated when the product is created in the Product Creator.
      text_2: This identification prevents misunderstandings about whether a displayed product image was created using artificial intelligence.
      list_1: Seller declaration – AI-generated product images must be identified accordingly when the product is created.
      list_2: AI IMAGE – identified images automatically receive a visible “AI IMAGE” label.
      list_3: Overlay – the label is displayed directly over the respective product image.
    information:
      title: Information on the Product Card
      text: In addition to its images, the product card displays several details that allow the product to be identified and evaluated directly from the Marketplace overview.
      list_1: Language – shows the language of the product, for example DE or EN.
      list_2: Content and file types – shows available content or file formats such as Assets, Icons, INI, XML or YAML.
      list_3: File size – shows the size of the product, for example in KB.
      list_4: Seller – displays the user or company name of the seller.
      list_5: Product title – displays the name of the published product.
      list_6: Product description – provides a short description of the product and its intended content.
      list_7: Creation date – shows when the product was created or published.
    content:
      title: Content and File Types
      text_1: The product card can display available content and file types directly. This makes it possible to see which types of files or resources the product contains before opening its product details.
      text_2: The information displayed depends on the respective product and the files and resources it contains.
    seller:
      title: Seller
      text_1: The seller of the product is displayed on every product card. Depending on the configured seller profile, this can be a user or a company.
      text_2: The seller information clearly associates the product with its provider on the Horum Marketplace.
    rating:
      title: Rating and Purchases
      text_1: The product rating and previous purchase count are displayed in the lower area of the product information.
      text_2: These values serve different purposes and should not be confused with each other.
      list_1: Rating – displays the current star rating of the product. If no rating is available yet, this is indicated accordingly.
      list_2: Purchase count – shows how many times the product has already been purchased.
    price:
      title: Product Price
      text_1: The price is displayed prominently in the lower area of the product card. Free products are identified accordingly as “Free”.
      text_2: For paid products, the price is displayed in the currency stored for the Horum account. Regional price conversion is performed using the current API exchange rate.
    purchase:
      title: Purchase Status and Shopping Cart
      text: The purchase action on the product card depends on whether the product has already been purchased by the currently signed-in user.
      list_1: Shopping cart – a product that has not yet been purchased can be added directly to the shopping cart using the cart icon.
      list_2: Already purchased – if the product has already been purchased, this status is displayed on the product card.
      list_3: Purchase status – for already purchased products, the normal shopping cart action is replaced accordingly.
    details:
      title: Product Detail View
      text_1: The detailed product view can be opened from the product card. It provides additional information about the selected product.
      text_2: The product detail view includes the expanded product presentation, price and purchase status, as well as available ratings and comments from previous buyers.
    summary:
      title: Product Information at a Glance
      text: The product card summarizes the most important information about a Marketplace product. This includes product images, language, content and file types, file size, seller, title, description, creation date, rating, purchase count, price and purchase status. Multiple product images can be viewed using a slider, while AI-generated product images are clearly identified by the mandatory “AI IMAGE” label.

documentation:
  products:
    title: My Products
    intro: The My Products page displays the user's own products published on the Horum Marketplace. It provides a compact overview of the current product portfolio and its basic statistics.
    purpose:
      title: Purpose of My Products
      text_1: My Products displays the Marketplace products published by the currently signed-in user directly within the Horum application.
      text_2: The page is particularly relevant to sellers. Users who have not published their own products on the Horum Marketplace will accordingly see no or only limited product information.
    dashboard:
      title: Dashboard Overview
      text_1: The view mirrors the purpose of the My Products overview in the web-based Horum Dashboard and provides the most important product information directly within the application.
      text_2: Its primary purpose is to provide an overview. More extensive management and editing of Marketplace products is handled through the Horum Dashboard on the website.
    statistics:
      title: Product Statistics
      text_1: Key statistics for the user's Marketplace products are summarized above the product list.
      total: Total products: Displays the total number of the user's published products.
      active: Active products: Displays the number of currently active products.
      inactive: Inactive products: Displays the number of currently inactive products.
      downloads: Downloads: Displays the combined number of downloads across the user's products.
    table:
      title: Product Overview
      text_1: The table displays the user's Marketplace products and presents the most important information for each product in a compact overview.
      text_2: This allows sellers to see directly within Horum which products are published, their current status, and how often they have been downloaded.
      image: Image: Displays the preview image associated with the product.
      title_column: Title: Displays the published title of the product.
      category: Category: Displays the category or classification of the product.
      language: Language: Displays the language assigned to the product.
      file_type: File type: Displays the file type of the published product.
      downloads: Downloads: Displays the number of downloads the product has received.
      status: Status: Displays whether the product is currently active or inactive.
      price: Price: Displays the configured selling price together with its associated currency.
    sellers:
      title: For Sellers
      text_1: This page is primarily intended for users who publish their own content through the Horum Marketplace. It provides a quick overview of their products, current status, and previous downloads.
      text_2: For users without their own Marketplace products, this area has correspondingly limited relevance because there is no personal product data to display.
    information:
      title: Overview Instead of Product Management
      text_1: My Products within the Horum application is designed as a compact information and overview page.
      text_2: For additional seller functions and more extensive management of published products, the Horum Dashboard on the website is available.
    summary:
      title: Summary
      text: My Products mirrors the product overview of the web-based Horum Dashboard within the application. Sellers receive a compact overview of their published products, active and inactive entries, downloads, and key product information such as category, language, file type, status, and price.

documentation:
  marketplace_ratings:
    title: Ratings
    intro: Ratings allow buyers to share their experience with a purchased and installed product. A rating consists of a star rating from 1.0 to 5.0 and can be supplemented with a personal comment.
    overview:
      title: Ratings in the Marketplace
      text_1: Ratings are assigned to a specific product in the Horum Marketplace and are displayed within the product view.
      text_2: This allows other users to view ratings and experiences from previous buyers alongside the product information.
      list_1: Star rating – numerical product rating from 1.0 to 5.0.
      list_2: Comment – personal feedback from the buyer about the product.
      list_3: Buyer information – shows which buyer submitted the rating and when the product was purchased.
    requirements:
      title: Requirements for a Rating
      text_1: A product cannot be rated directly through its public product view. The rating function is available through “My Horum” in the Dashboard.
      text_2: To rate a product, the associated package must have been purchased and installed.
      list_1: The product was purchased through the Horum Marketplace.
      list_2: The associated package has been installed in Horum.
    rating:
      title: Star Rating
      text_1: The star rating is selected using a slider. The rating range extends from 1.0 to 5.0 stars.
      text_2: Ratings are not limited to whole stars. Intermediate values can also be selected and stored as the exact numerical rating value.
      list_1: Minimum – 1.0 stars.
      list_2: Maximum – 5.0 stars.
      list_3: Intermediate values – for example 1.2, 3.9 or 4.7 stars.
    comment:
      title: Rating Comment
      text_1: A comment about the product can be submitted in addition to the star rating.
      text_2: The comment is published together with the rating and allows the buyer to describe their experience or opinion of the product in addition to the numerical rating.
    display:
      title: Rating Display
      text: Published ratings are displayed in the ratings section of the product view. Each rating contains its associated rating information.
      list_1: Buyer – username and profile image of the user who submitted the rating.
      list_2: Purchase date – shows when the product was purchased by the user who submitted the rating.
      list_3: Stars – visual representation of the submitted rating.
      list_4: Rating value – displays the exact numerical rating value, for example 5.0.
      list_5: Comment – displays the text submitted by the buyer with the rating.
    product_rating:
      title: Product Rating
      text_1: Submitted ratings belong to the respective product and provide additional information about the experiences of previous buyers.
      text_2: Because Horum processes ratings as numerical values between 1.0 and 5.0, differences between ratings with decimal values can also be taken into account.
    sorting:
      title: Sorting by Rating
      text_1: A product's rating is also used for rating-based sorting within the Horum Marketplace.
      text_2: Products can be sorted by rating in ascending or descending order. Numerical rating values from 1.0 to 5.0, including intermediate values, are taken into account.
    summary:
      title: Rate Products and Share Experiences
      text: After purchasing and installing a package, the associated product can be rated through “My Horum”. The rating is selected with a slider from 1.0 to 5.0 stars and supports intermediate values such as 1.2 or 3.9. A comment can also be submitted. Published ratings are then displayed with the buyer, purchase date, stars, exact rating value and comment on the product in the Horum Marketplace.

documentation:
  marketplace_search:
    title: Search, Filters & Sorting
    intro: Search, filters and sorting allow you to narrow down the products displayed on the Horum Marketplace and arrange them according to your requirements.
    overview:
      title: Find Products
      text_1: The Horum Marketplace provides several functions for quickly finding suitable content even when a large number of products are available.
      text_2: Search, sorting and filters serve different purposes and can be combined with each other.
      list_1: Search – searches the available products based on the entered search term.
      list_2: Sorting – arranges the displayed products by price or rating.
      list_3: Filters – narrow down the displayed products based on selected properties.
    search:
      title: Product Search
      text_1: The “Search products...” field allows you to search specifically for products on the Horum Marketplace.
      text_2: Search can be used together with the available language, sorting and filter options to further narrow down the displayed results.
    language:
      title: Language
      text_1: The language selection allows you to define which product languages should be included in the results.
      list_1: German – includes products with German language.
      list_2: English – includes products with English language.
      text_2: Languages can be selected individually or together. This allows German and English products, for example, to be included in the results at the same time.
    sort:
      title: Sort Products
      text_1: Displayed products can be sorted by price or rating independently of the actual filters.
      list_1: Price – sorts products according to their sales price.
      list_2: Rating – sorts products according to their average rating.
      text_2: Price and rating each have three states. Repeated selection cycles between descending order, ascending order and no sorting.
    sort_states:
      title: Sorting Order
      text: Price and rating sorting each use three consecutive states.
      list_1: Descending – higher values are displayed before lower values.
      list_2: Ascending – lower values are displayed before higher values.
      list_3: Reset – sorting for the selected property is removed.
    filters:
      title: Filter Products
      text_1: The filter panel allows you to narrow down the displayed products based on their technical and content-related properties.
      text_2: Multiple filters can be selected and combined at the same time.
    categories:
      title: Categories
      text: Categories allow you to restrict the results to specific types of Horum products.
      list_1: Horum Package – complete packages containing multiple Horum components.
      list_2: Personality – packages for Horum personalities.
      list_3: Horum Window – packages for Horum windows.
      list_4: Worker UI – packages for Worker UIs.
      list_5: Result UI – packages for Result UIs.
      list_6: Core – packages for Horum cores.
      list_7: Commands – packages containing Horum commands.
    file_types:
      title: File Type
      text: The file type filter allows you to narrow down products based on the file types they contain.
      list_1: MD – Markdown files.
      list_2: XML – XML files.
      list_3: YAML – YAML files.
      list_4: INI – configuration files in INI format.
      list_5: SVG – scalable vector graphics.
      list_6: PNG – image files in PNG format.
      list_7: WEBP – image files in WEBP format.
      list_8: ICO – icon files in ICO format.
    content:
      title: Content
      text: The content filter takes additional directories or content within a package into account.
      list_1: ASSETS – includes products containing assets.
      list_2: ICONS – includes products containing icons.
    price:
      title: Price Range
      text_1: The price range allows you to define a minimum and maximum price in CHF. Only products with a price within the selected range are included.
      text_2: The currently selected minimum and maximum values are displayed directly on the price filter and can be adjusted using the two sliders.
    size:
      title: File Size
      text_1: The file size filter allows you to define a minimum and maximum value in MB.
      text_2: Only products whose file size falls within the selected range are included. The current minimum and maximum values are displayed directly on the filter.
    combination:
      title: Combine Search, Sorting and Filters
      text_1: The different search and filter functions can be used together. For example, you can first select a category, then filter by file type, content, price and file size, and additionally sort the resulting products.
      text_2: Rating sorting uses the rating system from 1.0 to 5.0. Ratings can also contain intermediate values such as 4.9, 4.8 or 3.7 and are sorted according to their actual numerical value.
    reset:
      title: Reset Filters
      text_1: “Reset Filters” returns the selected filters to their initial state.
      text_2: This allows you to start filtering again without having to remove each previously selected filter individually.
    summary:
      title: Narrow Down Products
      text: Marketplace search combines product search, language selection, sorting, categories, file types, content, price range and file size. Price and rating can be sorted in descending or ascending order and then reset. Rating sorting takes the complete 1.0 to 5.0 rating system, including intermediate values, into account.

documentation:
  horum_main:
    title: Horum Main
    intro: The Horum Main path contains Horum's own local resources and configurations. Horum is bound to this area and stores files and resources there that belong to its own base configuration or to content created by Horum itself.
    purpose:
      title: Purpose of Horum Main
      text_1: Horum Main is the central path for Horum's own resources. It contains fixed configuration areas as well as directories in which Horum can dynamically create new commands, Worker UIs, and Result UIs.
      text_2: This area is separated from installed Horum packages. This keeps Horum's own files and self-created resources organized independently from additionally installed content.
    structure:
      title: Base Structure
      text_1: The following structure shows the basic directories and fixed files within Horum Main. Dynamically created resources inside commands, worker_ui, and result_ui are deliberately not shown in this overview.
      text_2: This keeps the base structure clear while allowing Horum to extend the dynamic areas itself depending on its tasks.
    fixed_dynamic:
      title: Fixed and Dynamic Areas
      text_1: Horum Main consists of a fixed base structure and areas whose contents can be dynamically extended while Horum is being used.
      text_2: Fixed configuration files provide the foundation for selection and presentation. Dynamic resources, on the other hand, are created depending on Horum's tasks and required functions.
      fixed: Fixed: Core, Horum Windows, Personality, and their respective configuration files have a defined base structure.
      dynamic: Dynamic: Horum can create its own resources and associated files within Commands, Worker UI, and Result UI.
    commands:
      title: Commands
      text_1: The commands area contains Horum's own command resources. In addition to the fixed configuration, new command areas can be created dynamically here.
      text_2: Commands created by Horum are organized within this area and can then be managed through the Commander.
      config: command.ini: Stores the selection for Horum's own command resources.
      resources: Dynamic resources: Horum can create its own subdirectories and YAML-based command resources within the command area.
    core:
      title: Core
      text_1: The core area has a fixed structure and consists of INI files for the selection and graphical configuration of the Horum Core.
      text_2: Unlike the dynamic UI and command areas, no dynamic resource directories are created within the Core area.
      animation: animation.ini: Contains the graphical animation settings of the Core.
      color: color.ini: Contains the color settings of the Core.
      geometry: geometry.ini: Contains the geometry settings of the Core.
      selection: core.ini: Stores the selection for the Core being used.
    windows:
      title: Horum Windows
      text_1: The horum_windows area contains the fixed configurations for Worker UI and Result UI. The configurations for both window types are stored separately.
      text_2: This area consists exclusively of its fixed configuration structure and does not itself create dynamic UI resources.
      worker_design: worker_config/design.ini: Contains the graphical design settings for the Worker Window.
      worker_selection: worker_config/worker.ini: Stores the selection for the Worker UI.
      result_design: result_config/design.ini: Contains the graphical design settings for the Result Window.
      result_selection: result_config/result.ini: Stores the selection for the Result UI.
    personality:
      title: Personality
      text_1: The personality area contains Horum's own personality files and the associated selection configuration. The personality files are stored separately by language.
      text_2: Soul, Rules, and Forbidden form Horum's own language-dependent foundations and are available separately for German and English.
      config: personality.ini: Stores the selection for the personality being used.
      soul: soul.md: Contains Horum's fundamental personality and orientation.
      rules: rules.md: Contains the rules that define how Horum should behave.
      forbidden: forbidden.md: Contains defined prohibitions and restrictions.
      languages: Languages: The soul.md, rules.md, and forbidden.md files are stored separately in the de and en directories.
    worker_ui:
      title: Worker UI
      text_1: The worker_ui area contains Worker UIs that belong to Horum Main and can be created dynamically by Horum. Separate resource directories can be created for different tasks.
      text_2: The generated Worker UIs are then managed through the Commander and can consist of YAML, XML, or both file types depending on their purpose.
      yaml: YAML: Describes the workflow or use of a working interface.
      xml: XML: Defines the widgets and structure of a working interface.
    result_ui:
      title: Result UI
      text_1: The result_ui area contains Result UIs that belong to Horum Main and can be created dynamically by Horum. Separate resource directories can be created for different results and tasks.
      text_2: The generated Result UIs are then managed through the Commander and can consist of YAML, XML, or both file types depending on their purpose.
      yaml: YAML: Describes the workflow or use of a result interface.
      xml: XML: Defines the widgets and structure of a result interface.
    generated:
      title: Resources Created by Horum
      text_1: Horum can extend its dynamic areas itself. If a task requires a new command, Worker UI, or Result UI, new resources and files can be created within the corresponding area.
      text_2: These dynamic contents belong to Horum Main and are handled separately from installed package resources. This allows Horum to create and manage its own content without modifying the structure of installed packages.
    responsibility:
      title: Horum's Own Path
      text_1: Horum Main is bound to Horum itself. The path is not intended as a general directory for arbitrary user files but as a structured storage area for Horum's own configurations and resources.
      text_2: Horum uses this area both for its fixed base configuration and for content that it creates itself during operation.
    summary:
      title: Summary
      text: Horum Main is the central storage area for Horum's own configurations and resources. Fixed INI and personality files form the base structure, while Commands, Worker UI, and Result UI can be dynamically extended through resources created by Horum. Installed package resources remain separate from this area.

documentation:
  horum_packages:
    title: Horum Packages
    intro: The Horum Packages path contains Horum's installed package resources. Unlike Horum Main, this area does not contain Horum's own or self-created resources, but content installed through Horum packages.
    purpose:
      title: Purpose of Horum Packages
      text_1: Horum Packages is the central installation area for package components. Depending on the contents of a package, commands, Core configurations, window designs, personalities, Worker UIs, and Result UIs can be installed there.
      text_2: Package resources remain separate from Horum Main. Horum can use and manage them through the corresponding areas without mixing its own local resources with installed package content.
    structure:
      title: Base Structure
      text_1: The following structure shows the basic organization of Horum Packages. Specific package names and export IDs are represented by placeholders because they depend on the packages that are installed.
      text_2: Not every package has to contain all of the component types shown. Only the areas that are part of the respective package are populated.
    package_path:
      title: Package Name and Export ID
      text_1: Installed components are stored within their respective area in a directory using the {packageName}_{exportId} naming scheme.
      text_2: If multiple components belong to the same export, they use the same package name and the same export ID. This keeps related components uniquely associated with the same export across different areas.
      name: packageName: Identifies the name of the installed export or package.
      export_id: exportId: Is the unique identifier of the export and forms the installation directory together with the package name.
      shared: Shared export: Commands, Core, Horum Windows, Personality, Worker UI, and Result UI belonging to the same export use the same package name and the same export ID.
    author:
      title: author.json
      text_1: The author.json file is stored together with installed package components and serves as the reference file for the origin or author of the installed resource.
      text_2: This allows Horum to identify the publisher or author associated with an installed component even after installation.
    selection:
      title: No Selection INI Files in Packages
      text_1: Installed package resources do not store their selection inside their respective package directories. The package structure therefore does not contain the selection INI files used within Horum Main.
      text_2: Package directories contain the actual resources and their associated graphical settings. Selection and activation are managed separately from these package files.
      no_command: No command.ini: The selection of installed commands is not stored inside the package directory.
      no_core: No core.ini: The selection of an installed Core is not stored inside the Core package directory.
      no_worker: No worker.ini: The selection of an installed Worker UI is not stored inside the window design package directory.
      no_result: No result.ini: The selection of an installed Result UI is not stored inside the window design package directory.
      no_personality: No personality.ini: The selection of an installed personality is not stored inside the Personality package directory.
    commands:
      title: Commands
      text_1: The commands area contains command resources from installed packages. Each installed resource is stored inside its own {packageName}_{exportId} directory.
      text_2: Installed commands can then be selected, enabled, and managed through the Commander.
      author: author.json: Contains reference information about the origin or author of the package resource.
      yaml: YAML: Contains the commands and workflows provided by the installed command resource.
    core:
      title: Core
      text_1: The core area contains graphical Core configurations from installed packages. Each Core resource has its own {packageName}_{exportId} directory.
      text_2: Unlike Horum Main, no core.ini file is stored inside the package directory for selection. The directory contains only the package reference and the graphical settings of the installed Core.
      author: author.json: Contains reference information about the origin or author of the Core resource.
      animation: animation.ini: Contains the animation settings of the installed Core.
      color: color.ini: Contains the color settings of the installed Core.
      geometry: geometry.ini: Contains the geometry settings of the installed Core.
    windows:
      title: Horum Windows
      text_1: The horum_windows area contains installed window designs for Worker UI and Result UI. Both window types are organized separately in worker_config and result_config.
      text_2: Each installed window design has its own {packageName}_{exportId} directory. Selection is not stored inside this directory.
      worker: worker_config: Contains installed designs for the Worker Window.
      result: result_config: Contains installed designs for the Result Window.
      design: design.ini: Contains the graphical settings of the respective installed window design.
      author: author.json: Contains reference information about the origin or author of the installed window design.
    personality:
      title: Personality
      text_1: The personality area contains personality resources from installed packages. Each installed personality is stored inside its own {packageName}_{exportId} directory.
      text_2: Depending on the contents of the personality, Soul, Rules, and Forbidden can be included. A personality.ini file for selection is not stored inside the package directory.
      author: author.json: Contains reference information about the origin or author of the installed personality.
      soul: soul.md: Contains the fundamental personality and orientation of the installed Personality resource.
      rules: rules.md: Contains additional rules of the installed Personality resource.
      forbidden: forbidden.md: Contains additional prohibitions and restrictions of the installed Personality resource.
    worker_ui:
      title: Worker UI
      text_1: The worker_ui area contains Worker UIs from installed packages. Each installed Worker UI is stored inside its own {packageName}_{exportId} directory.
      text_2: A package Worker UI can contain YAML, XML, as well as additional assets and icons. The resource is managed through the Commander after installation.
      author: author.json: Contains reference information about the origin or author of the installed Worker UI.
      yaml: yaml: Contains the YAML files for the workflows and use of the Worker UI.
      xml: xml: Contains the XML files for the widgets and structure of the Worker UI.
      assets: assets: Contains additional resources required by the Worker UI.
      icons: icons: Contains icons that can be used within the Worker UI.
    result_ui:
      title: Result UI
      text_1: The result_ui area contains Result UIs from installed packages. Each installed Result UI is stored inside its own {packageName}_{exportId} directory.
      text_2: A package Result UI can contain YAML, XML, as well as additional assets and icons. The resource is managed through the Commander after installation.
      author: author.json: Contains reference information about the origin or author of the installed Result UI.
      yaml: yaml: Contains the YAML files for the workflow and use of the Result UI.
      xml: xml: Contains the XML files for the widgets and structure of the Result UI.
      assets: assets: Contains additional resources required by the Result UI.
      icons: icons: Contains icons that can be used within the Result UI.
    separation:
      title: Separation from Horum Main
      text_1: Horum Packages and Horum Main serve different purposes. Horum Main contains Horum's own base configurations and self-created resources, while Horum Packages is exclusively intended for installed package resources.
      text_2: This separation prevents installed packages from being mixed with Horum's own resources. Package components can therefore be installed and managed independently while Horum Main remains Horum's own local area.
    summary:
      title: Summary
      text: Horum Packages is the installation area for package resources. Each component is stored under its type in a {packageName}_{exportId} directory and includes an author.json reference file. Package directories do not contain selection INI files, only the installed content and its respective graphical settings. This keeps Horum Main and Horum Packages clearly separated.

documentation:
  about:
    title: About Horum
    intro: This section contains information about the development of Horum, the responsible company EminentWeb GmbH, and technical information about the application.
    developer:
      title: Development
      text_1: Horum is developed by Rafael Herren and is a software project of EminentWeb GmbH.
      text_2: Development, technical architecture, and continued development of the application are carried out within the company.
      list_1: Developer: Rafael Herren
      list_2: Company: EminentWeb GmbH
    company:
      title: EminentWeb GmbH
      text_1: EminentWeb GmbH is a Swiss technology company based in Grellingen in the canton of Basel-Landschaft. The company develops and operates its own digital products, platforms, and technical infrastructures.
      text_2: Its activities include traditional software and web development as well as interactive systems, cloud and server infrastructures, digital business models, and technology-based financial solutions.
      list_1: Company: EminentWeb GmbH
      list_2: UID / VAT Number: CHE-183.697.143
      list_3: Registered Office: 4203 Grellingen, Basel-Landschaft, Switzerland
      list_4: Operating Location: Switzerland (Remote)
    activities:
      title: Areas of Activity
      text: The corporate purpose of EminentWeb GmbH covers the development, operation, and commercialization of a broad range of digital systems and services.
      list_1: Digital platforms, software, applications, websites, programs, and databases.
      list_2: Server, hosting, and cloud infrastructures and related technical services.
      list_3: Interactive systems and digital applications, including games.
      list_4: Digital payment, wallet, transaction, and processing solutions.
      list_5: Technology-based financial and fintech solutions as well as blockchain and distributed ledger technologies within the applicable legal framework.
      list_6: IT, support, and consulting services in the areas of technology, digitalization, online services, platform economy, and digital business models.
    horum:
      title: Horum as a Product
      text_1: Horum is a software product developed by EminentWeb GmbH and forms part of the company's own digital product and platform development.
      text_2: Information about Horum's functions, capabilities, and fundamental architecture is covered in the dedicated sections of the documentation and is therefore not repeated here.
    application:
      title: Application
      text: The About Horum section also displays technical information about the installed application and its current build.
      list_1: Application: Horum
      list_2: Version: Currently installed Horum version.
      list_3: Build: Current build status of the application.
      list_4: Programming Language: Python
      list_5: Framework: PyQt5
    contact:
      title: Website and Contact
      text: Further information about the company and contact options are available through the official channels of EminentWeb GmbH.
      list_1: Website: eminentweb.ch
      list_2: Contact: horum@eminentweb.ch
    summary:
      title: Summary
      text: Horum is developed by Rafael Herren within EminentWeb GmbH. The Swiss technology company develops and operates digital products, software, platforms, and technical infrastructures, providing the corporate and technical framework for the development of Horum.

documentation:
  account:
    title: Account
    intro: The Account section manages personal information, company data, language, and license information. Horum can be used entirely with a local account or connected to a Horum online account.
    local:
      title: Local Account
      text_1: No login is required to use Horum locally. The stored account data is saved locally and can be edited directly within the application.
      text_2: The local account operates independently of an online profile and provides basic personalization of Horum without requiring a connection to the Horum website.
      list_1: Account data is stored locally in a JSON file.
      list_2: Local profile fields can be edited and saved directly in the settings.
      list_3: Without a login, the license plan is always treated as Free because no server-side plan validation can take place.
    login:
      title: Login and Synchronization
      text_1: The Account section allows users to log in to their Horum online account directly within Horum.
      text_2: After a successful login, the local account is synchronized with the online profile. This provides Horum with the profile and license information associated with the user account.
      list_1: Login is performed directly within the Horum application.
      list_2: After login, the relevant account data is synchronized with the online profile.
      list_3: After logging out, Horum returns to using the local account state.
    profile:
      title: Profile Data
      text: The Account section displays the personal and business profile data available to Horum. When an online account is logged in, the corresponding synchronized input fields are disabled and cannot be changed directly within the application.
      list_1: User: First name and last name.
      list_2: About You: Age, gender, and personal description.
      list_3: Company: Company name, industry, legal form, and commercial register number.
      list_4: Changes to synchronized online profile data are made through the profile on the Horum website.
    name:
      title: What Should Horum Call You?
      text_1: The name Horum uses to address the user is a separate application setting and can be defined independently of synchronized profile data.
      text_2: Any name or individual designation can be used as long as the selected designation complies with the applicable guidelines.
    language:
      title: Language
      text_1: Horum's language is a local setting and remains configurable regardless of whether an online account is logged in.
      text_2: The selection determines which local language files Horum uses for the user interface and corresponding localized content.
      list_1: German: Uses the German locales.
      list_2: English: Uses the English locales. Additional languages can be added in the future.
    license:
      title: License
      text_1: The License section displays the Horum edition available to the user and the current license status.
      text_2: The displayed license information differs depending on whether Horum is being used exclusively locally or with a logged-in online account.
      list_1: Without a login, the edition is locally treated as Free.
      list_2: A higher edition can only be validated and applied after logging in with the online account.
      list_3: For a validated license, the edition, status, and expiration date can be displayed.
    actions:
      title: Save and Log Out
      text: The available account actions depend on the current login state and the locally editable settings.
      list_1: Save applies changes to locally editable account settings.
      list_2: Log Out disconnects the currently connected online account from Horum.
    summary:
      title: Summary
      text: Horum can be used without a login using locally stored account data or synchronized with a Horum online account. Online profile data is protected after login and managed through the website, while Horum-specific settings such as the preferred form of address and local language remain configurable within the application.

documentation:
  appearance:
    title: Appearance
    intro: The Appearance section controls the general Horum user interface. This includes the preferred input mode, the background, and the color schemes of central UI components and their different states.
    scope:
      title: Horum User Interface
      text_1: The settings in this section apply to Horum's general user interface and its controls.
      text_2: The appearance of the Horum Core, Horum Windows, Worker UI, and Result UI is not configured here. These areas have their own settings or presentation rules.
    input_mode:
      title: Preferred Input Mode
      text_1: The input mode determines which input option is preferably displayed when the Horum user interface starts or is initialized.
      text_2: The switch allows the preferred mode to be changed directly between text input and voice input.
      list_1: Text Input: Uses the text field as the preferred input method.
      list_2: Voice Input: Uses microphone input as the preferred input method.
    background:
      title: Horum Background
      text: The background of the main interface can be configured independently of the remaining UI design. Three background types are available.
      list_1: Image: Uses a selected background image from the available background groups.
      list_2: Color: Uses a single color as the background.
      list_3: Gradient: Creates a gradient from two individually selected colors and an adjustable angle.
    gradient:
      title: Gradient
      text_1: A gradient uses two colors between which the background transitions.
      text_2: The gradient angle can also be adjusted. This determines the direction in which the two colors transition across the interface.
      list_1: Color 1 defines the first color of the gradient.
      list_2: Color 2 defines the second color of the gradient.
      list_3: The angle determines the orientation of the gradient.
    images:
      title: Background Images
      text_1: Available background images are automatically loaded by Horum from the designated background area and displayed in groups within the image selector.
      text_2: Additional supported images can therefore be added to the existing background structure and subsequently selected through the user interface.
      list_1: PNG files are supported.
      list_2: JPG files are supported.
      list_3: JPEG files are supported.
      list_4: WebP files are supported.
    ui_design:
      title: UI Design
      text_1: The UI design is divided into several independent color areas. A separate color scheme can be selected for each area.
      text_2: This means Horum does not have to use a single global accent color. Different types of UI components can use their own color schemes.
      list_1: Titles: Defines the accent color used for titles.
      list_2: Interactions: Defines the color schemes of interactive elements such as buttons.
      list_3: Input Controls: Defines the accent and border colors of input fields.
      list_4: Selection Controls: Defines the color schemes of selection and control elements such as dropdowns, checkboxes, radio buttons, switches, and sliders.
      list_5: Navigation: Defines the color schemes of navigation, sidebar, and tab elements.
      list_6: Progress: Defines the color schemes of progress indicators and spinners.
    states:
      title: Colors for Widget States
      text_1: Depending on the UI area, a color scheme consists of several coordinated color shades. These colors are used for different states of the respective widgets.
      text_2: The shade used depends on the individual widget. This allows interactions to be visually distinguished without requiring a completely independent color to be configured for every state.
      list_1: Normal: Basic state of a control.
      list_2: Hover: Appearance when the cursor is positioned over an interactive element.
      list_3: Active: Appearance of a selected or activated element.
      list_4: Focus: Identifies an element that currently has input or interaction focus.
      list_5: Pressed: Appearance while a control is actively being pressed.
    neutral:
      title: Neutral UI States
      text_1: Not every color in the Horum user interface is replaced by the selected color scheme. Certain base colors and neutral states deliberately remain part of the fixed Horum design.
      text_2: Depending on the widget, these include disabled states, neutral backgrounds, and certain text and system colors. The color schemes therefore customize accents and interaction states rather than completely replacing the entire UI design.
    save:
      title: Saving Changes
      text_1: The selected settings are applied using Save. This includes the selected UI color schemes, the preferred input mode, and the Horum background settings.
      text_2: After saving, the appearance configuration is reloaded so that the Horum user interface can apply the changed values.
    summary:
      title: Summary
      text: Appearance provides individual customization of the Horum main interface. Input mode, background, and several separate UI color schemes can be combined, while the different widget states are automatically represented using the corresponding selected color palettes.

documentation:
  audit:
    title: Audit & Logging
    intro: The Audit & Logging section determines which events and changes Horum should log. Individual audit areas can be enabled independently and configured in detail.
    system:
      title: Audit System
      text_1: Audit logs help track Horum's behavior, analyze errors, and document important events.
      text_2: To avoid unnecessarily logging every operation, each area can be configured individually to determine which events should be included.
    activation:
      title: Enabling Audit Areas
      text_1: Each audit card has its own switch. This switch determines whether the entire category is enabled for audit logging.
      text_2: Only when a category switch is enabled are the selected checkboxes within that card taken into account. When the switch is disabled, the entire selection within the card is disabled.
      list_1: Switch enabled: The category is enabled for audit logging.
      list_2: The checkboxes then determine which individual events within the active category are logged.
      list_3: Switch disabled: All selection options within the category are disabled and are not taken into account.
    account:
      title: Account Audit
      text: The Account Audit covers events associated with the Horum account, sign-in, and license-related changes.
      list_1: Sign-ins: Logs sign-in events.
      list_2: Sign-outs: Logs sign-out events.
      list_3: License Changes: Logs changes to the license status.
      list_4: API Keys: Logs events related to API keys.
    ai:
      title: AI Audit
      text: The AI Audit covers operations related to communication with the AI models being used and their usage.
      list_1: User Inputs: Logs inputs passed to AI processing.
      list_2: AI Responses: Logs responses from the AI being used.
      list_3: Model Changes: Logs changes between AI models.
      list_4: Token Usage: Logs token usage associated with AI operation.
    speech:
      title: Speech Audit
      text: The Speech Audit logs selected events related to voice input, voice output, and the audio devices being used.
      list_1: Voice Input: Logs voice input events.
      list_2: Voice Output: Logs voice output events.
      list_3: Microphone Changes: Logs changes to the microphone being used.
      list_4: Audio Devices: Logs events related to audio devices.
    memory:
      title: Memory Audit
      text: The Memory Audit documents selected changes within Horum's memory system.
      list_1: Memory Created: Logs the creation of a memory entry.
      list_2: Memory Changed: Logs changes to existing memory entries.
      list_3: Memory Deleted: Logs the deletion of memory entries.
      list_4: Categories: Logs events related to memory categories.
    rules:
      title: Rules Audit
      text: The Rules Audit documents changes to Horum's personality and behavioral instructions as well as detected rule violations.
      list_1: Soul Changes: Logs changes to the Soul configuration.
      list_2: Rule Changes: Logs changes to rules.
      list_3: Forbidden Changes: Logs changes to forbidden rules.
      list_4: Rule Violations: Logs detected violations of configured rules.
    storage:
      title: Storage Audit
      text: The Storage Audit covers selected operations related to cache, cleanup, and file operations.
      list_1: Cache: Logs selected cache operations.
      list_2: Cleanup: Logs cleanup operations.
      list_3: Files Created: Logs the creation of files.
      list_4: Files Deleted: Logs the deletion of files.
    appearance:
      title: Appearance Audit
      text: The Appearance Audit documents selected changes to Horum's visual configuration.
      list_1: Design: Logs changes to design settings.
      list_2: Language: Logs changes to language settings.
      list_3: Layout: Logs changes to layout settings.
      list_4: Appearance: Logs changes to appearance settings.
    system_audit:
      title: System Audit
      text: The System Audit covers fundamental application events as well as errors and warnings.
      list_1: Application Start: Logs when Horum starts.
      list_2: Application Exit: Logs when Horum is closed.
      list_3: Errors: Logs errors that occur.
      list_4: Warnings: Logs warnings that occur.
    save:
      title: Saving
      text_1: Saving applies the selected audit categories and their individual logging options.
      text_2: Only checkboxes whose parent audit category is enabled through its corresponding switch are taken into account for logging.
    summary:
      title: Summary
      text: The audit system provides targeted logging for different areas of Horum. Each category is first enabled using its own switch. Within an active category, the checkboxes determine which specific events are logged. If the switch is disabled, the entire selection for that category remains disabled and is not taken into account.

documentation:
  cache:
    title: Cache
    intro: The cache stores frequently used data locally on the computer so that Horum can work faster and avoid unnecessary calculations or repeated requests. The different cache areas can be configured independently.
    system:
      title: Cache System
      text_1: Horum separates cached data according to its respective area of use. This makes it possible to individually determine which functions should use a local cache.
      text_2: Internet, media, AI, documents, knowledge, and system each have their own cache area and can be enabled or disabled independently.
    configuration:
      title: Configuring the Cache
      text_1: Each cache area has its own activation setting and storage path. This allows the different types of cached data to be stored separately.
      text_2: If a cache area is not required, it can be disabled. The corresponding cache path is then not used for that area.
      list_1: Active: Enables or disables the respective cache area.
      list_2: Cache Path: Determines the local storage location for the data of this cache area.
      list_3: The individual cache areas can be configured independently.
    internet:
      title: Internet Cache
      text_1: The Internet Cache is intended for cached data generated by Horum's internet-related operations.
      text_2: It can be enabled separately and stored in its own local location.
    media:
      title: Media Cache
      text_1: The Media Cache is intended for data cached during the processing and use of media.
      text_2: Its activation and storage path are configured independently from the other cache areas.
    ai:
      title: AI Cache
      text_1: The AI Cache is intended for data cached in connection with AI processing.
      text_2: This area can be enabled independently and stored using its own cache path.
    documents:
      title: Document Cache
      text_1: The Document Cache is intended for data cached during the processing and use of documents.
      text_2: This allows document-related cache data to be stored separately from other cache types.
    knowledge:
      title: Knowledge Cache
      text_1: The Knowledge Cache is intended for cached data that Horum uses in connection with knowledge processing.
      text_2: This cache can also be enabled separately and stored in its own location.
    system_cache:
      title: System Cache
      text_1: The System Cache is intended for cached data generated by Horum's internal system operations.
      text_2: It is configured independently from the content-related cache areas and can use its own storage path.
    paths:
      title: Cache Paths
      text_1: A separate local storage path can be selected for each cache area. This determines where the respective cached data is stored on the computer.
      text_2: Separate paths make it possible to organize the different cache types independently and use different storage locations when required.
    save:
      title: Saving
      text_1: Saving applies the activation states and storage paths of the individual cache areas.
      text_2: This makes it possible to determine separately for each area whether and where Horum should use a local cache.
    summary:
      title: Summary
      text: The cache system separates local temporary storage into Internet, media, AI, documents, knowledge, and system areas. Each area can be enabled or disabled independently and assigned its own storage path. This provides precise control over which Horum functions use local caching.

documentation:
  core_animation:
    title: Core Animation
    intro: The Core Animation section configures the movement behavior of the individual Horum Core layers. Users can either use and edit their own default configuration or select the animation of an installed Core package.
    source:
      title: Animation Source
      text_1: The animation source selection determines which animation configuration is used by the Horum Core.
      text_2: In addition to the editable default configuration, animation configurations from installed and available packages can be selected.
      list_1: Default: Uses Horum's locally editable animation configuration.
      list_2: Installed Package: Uses the animation configuration of the selected package.
    standard:
      title: Default Configuration
      text_1: The default configuration is Horum's own editable Core animation. When Default is selected, the animation sliders are enabled and the individual values can be adjusted.
      text_2: When saved, the configured animation values are stored in Horum's own animation INI file. This configuration is also available when exporting a custom Core configuration.
      list_1: All available animation controls can be edited.
      list_2: Adjusted values are stored in Horum's own animation INI file.
      list_3: The custom animation configuration can be used for exports.
    packages:
      title: Installed Packages
      text_1: Installed packages containing an available Core animation appear in the selection and can be used as the animation source.
      text_2: When an installed package is selected, the animation sliders are disabled. This prevents the animation values belonging to the package from being changed or overwritten through the settings.
      list_1: Available installed packages are automatically displayed in the selection.
      list_2: The animation from the selected package is used by the Horum Core.
      list_3: Package configurations are read-only and cannot be overwritten through these settings.
    storage:
      title: Selection and Animation Values
      text_1: Horum separates the storage of the selected animation source from the storage of its own animation values. Two separate INI storage areas are used for these purposes.
      text_2: The data written when saving depends on whether Default or an installed package is selected.
      list_1: Default: Both the selection and the editable animation configuration are saved.
      list_2: Installed Package: Only the package selection is saved. The package's animation configuration itself remains unchanged.
    core:
      title: Core
      text: The Core animation settings control the independent movements of the central Core element.
      list_1: Heartbeat: Defines the speed of the recurring heartbeat animation.
      list_2: Heartbeat Strength: Defines the strength of the movement generated by the heartbeat.
      list_3: Eye Speed: Defines the speed of the Core's eye movement.
      list_4: Eye Range: Defines the range of the eye movement.
    inner_wave:
      title: Inner Wave – General
      text: The general Inner Wave settings define the basic movement behavior and visible expression of this wave layer.
      list_1: Speed: Defines the general animation speed of the Inner Wave.
      list_2: Strength: Defines the strength of the wave movement.
      list_3: Intensity: Defines the intensity of the animated wave structure.
    inner_blobs:
      title: Inner Wave – Blobs
      text: The blob settings define the moving formations within the Inner Wave and influence their number, shape, and movement.
      list_1: Blob Count: Defines the number of blobs used.
      list_2: Blob Width: Defines the width of the individual blobs.
      list_3: Blob Strength: Defines the strength of their expression.
      list_4: Blob Speed: Defines the movement speed of the blobs.
      list_5: Blob Pulse: Defines the strength or expression of their pulsing movement.
    inner_noise:
      title: Inner Wave – Noise
      text: The noise parameters add additional dynamic variation to the Inner Wave and prevent an exclusively uniform wave movement.
      list_1: Noise Speed: Defines the speed of the noise movement.
      list_2: Noise Strength: Defines the strength of the noise influence.
      list_3: Noise Frequency 1: Defines the first frequency component of the noise structure.
      list_4: Noise Frequency 2: Defines the second frequency component of the noise structure.
    middle_ring:
      title: Middle Ring
      text: The Middle Ring settings define its fundamental movement and the timing behavior of its animation.
      list_1: Speed: Defines the general animation speed of the Middle Ring.
      list_2: Movement Speed: Defines the speed of its movement.
      list_3: Movement Duration: Defines the duration of a movement.
      list_4: Noise Speed: Defines the speed of the additional noise movement.
    outer_wave:
      title: Outer Wave – General
      text: The general Outer Wave settings define the basic movement behavior and visible expression of this wave layer.
      list_1: Speed: Defines the general animation speed of the Outer Wave.
      list_2: Strength: Defines the strength of the wave movement.
      list_3: Intensity: Defines the intensity of the animated wave structure.
    outer_blobs:
      title: Outer Wave – Blobs
      text: The blob settings define the moving formations within the Outer Wave and influence their number, shape, and movement.
      list_1: Blob Count: Defines the number of blobs used.
      list_2: Blob Width: Defines the width of the individual blobs.
      list_3: Blob Strength: Defines the strength of their expression.
      list_4: Blob Speed: Defines the movement speed of the blobs.
      list_5: Blob Pulse: Defines the strength or expression of their pulsing movement.
    outer_noise:
      title: Outer Wave – Noise
      text: The noise parameters add additional dynamic variation to the Outer Wave and influence the structure of its movement.
      list_1: Noise Speed: Defines the speed of the noise movement.
      list_2: Noise Strength: Defines the strength of the noise influence.
      list_3: Noise Frequency 1: Defines the first frequency component of the noise structure.
      list_4: Noise Frequency 2: Defines the second frequency component of the noise structure.
    export:
      title: Use for Export
      text_1: The editable default configuration represents Horum's own animation configuration and can be used when creating a Core export.
      text_2: Installed package configurations remain unchanged. Selecting one only determines which already installed animation Horum currently uses.
    summary:
      title: Summary
      text: Core Animation separates the editable default configuration from installed package configurations. Default values can be modified, saved, and used for exports. Installed packages can be selected as an animation source but remain read-only and are never overwritten.

documentation:
  core_colors:
    title: Core Colors
    intro: The Core Colors section configures the color design of the individual Horum Core layers. Users can either edit their own default configuration or select the color scheme of an installed Core package.
    source:
      title: Color Scheme
      text_1: The color scheme selection determines which color configuration is used by the Horum Core.
      text_2: In addition to the custom default configuration, color configurations from installed and available packages can be selected.
      list_1: Default: Uses Horum's locally editable color configuration.
      list_2: Installed Package: Uses the color configuration of the selected package.
    standard:
      title: Default Configuration
      text_1: The default configuration is Horum's own editable color scheme. When Default is selected, the color selections are enabled and can be adjusted individually for the different areas of the Core.
      text_2: When saved, the selected color values are stored in Horum's own color INI file. This configuration is also available when exporting a custom Core configuration.
      list_1: All available color areas can be edited individually.
      list_2: The selected colors are stored in Horum's own color INI file.
      list_3: The custom color configuration can be used for exports.
    packages:
      title: Installed Packages
      text_1: Installed packages containing an available Core color configuration appear in the dropdown and can be selected as the color scheme.
      text_2: When an installed package is selected, the color selections are disabled. This prevents the color values belonging to the package from being changed or overwritten through the settings.
      list_1: Available installed packages are automatically displayed in the dropdown.
      list_2: The color configuration of the selected package is used by the Horum Core.
      list_3: Package configurations are read-only and cannot be overwritten through these settings.
    storage:
      title: Selection and Color Values
      text_1: Horum separates the storage of the selected color scheme from the storage of its own color values. Two separate INI storage areas are used for these purposes.
      text_2: The data written when saving depends on whether Default or an installed package is selected.
      list_1: Default: Both the selection and the editable color configuration are saved.
      list_2: Installed Package: Only the package selection is saved. The package's color configuration itself remains unchanged.
    palette:
      title: Color Palette
      text_1: A palette of predefined colors is available for each color area. The color currently in use is highlighted within the respective selection.
      text_2: Color areas are selected independently. This allows the center, rings, waves, and glow effects to use different colors and be combined into an individual Core design.
    core:
      title: Core
      text: The central Core contains several separate color areas for its base elements and glow effects.
      list_1: Outer Glow: Defines the color of the outer glow area.
      list_2: Middle Glow: Defines the color of the middle glow area.
      list_3: Inner Halo: Defines the color of the inner halo area.
      list_4: Ring: Defines the color of the central Core ring.
      list_5: Center: Defines the color of the Core center.
    inner_wave:
      title: Inner Wave
      text: The Inner Wave uses two separate color areas, allowing its visible ring structures to be styled independently.
      list_1: Ring: Defines the color of the Inner Wave ring.
      list_2: Inner Ring: Defines the color of the Inner Wave inner ring.
    middle_ring:
      title: Middle Ring
      text: The Middle Ring has its own color assignment and can therefore be styled independently of the other Core layers.
      list_1: Ring: Defines the color of the Middle Ring.
    outer_wave:
      title: Outer Wave
      text: The Outer Wave uses two separate color areas for its ring structures.
      list_1: Ring: Defines the color of the Outer Wave ring.
      list_2: Inner Ring: Defines the color of the Outer Wave inner ring.
    independent:
      title: Independent Color Assignment
      text_1: The individual Core color areas are configured independently. Selecting a color for one area therefore does not automatically change the colors of the other areas.
      text_2: This allows both uniform color schemes and multicolored Core designs in which the Core, waves, rings, and glow effects are deliberately styled differently.
    export:
      title: Use for Export
      text_1: The editable default configuration represents Horum's own color configuration and can be used when creating a Core export.
      text_2: Installed package configurations remain unchanged. Selecting one only determines which already installed color scheme Horum currently uses for the Core.
    summary:
      title: Summary
      text: Core Colors separates the editable default configuration from installed package configurations. The individual Core color areas can be styled independently, saved, and used for exports. Installed color schemes can be selected but remain read-only and are not overwritten.

documentation:
  core_geometry:
    title: Core Geometry
    intro: The Core Geometry section configures the geometric structure of the individual Horum Core layers. Users can either edit their own default configuration or select the geometry design of an installed Core package.
    source:
      title: Geometry Design
      text_1: The geometry design selection determines which geometry configuration is used by the Horum Core.
      text_2: In addition to Horum Default, geometry configurations from installed and available packages can be selected.
      list_1: Horum Default: Uses Horum's locally editable geometry configuration.
      list_2: Installed Package: Uses the geometry configuration of the selected package.
    standard:
      title: Horum Default
      text_1: Horum Default is the Core's own editable geometry configuration. When selected, the geometry sliders are enabled and the individual values can be adjusted.
      text_2: When saved, the configured geometry values are stored in Horum's own geometry INI file. This configuration is also available when exporting a custom Core configuration.
      list_1: All available geometry sliders can be edited.
      list_2: Adjusted values are stored in Horum's own geometry INI file.
      list_3: The custom geometry configuration can be used for exports.
    packages:
      title: Installed Packages
      text_1: Installed packages containing an available Core geometry configuration appear in the dropdown and can be selected as the geometry design.
      text_2: When an installed package is selected, the geometry sliders are disabled. This prevents the geometry values belonging to the package from being changed or overwritten through the settings.
      list_1: Available installed packages are automatically displayed in the dropdown.
      list_2: The geometry configuration of the selected package is used by the Horum Core.
      list_3: Package configurations are read-only and cannot be overwritten through these settings.
    storage:
      title: Selection and Geometry Values
      text_1: Horum separates the storage of the selected geometry design from the storage of its own geometry values. Two separate INI storage areas are used for these purposes.
      text_2: The data written when saving depends on whether Horum Default or an installed package is selected.
      list_1: Horum Default: Both the selection and the editable geometry configuration are saved.
      list_2: Installed Package: Only the package selection is saved. The package's geometry configuration itself remains unchanged.
    core:
      title: Core
      text: The Core geometry determines the fundamental size of the central Core element.
      list_1: Radius: Defines the radius and therefore the fundamental size of the central Core.
    inner_wave:
      title: Inner Wave
      text: The Inner Wave geometry values determine its position, thickness, and geometric resolution within the Core.
      list_1: Radius: Defines the base radius of the Inner Wave.
      list_2: Thickness: Defines the thickness of the rendered wave structure.
      list_3: Segments: Defines the number of segments used to construct the circular wave structure.
    middle_ring:
      title: Middle Ring
      text: The Middle Ring has its own geometry values for its size, thickness, and the representation of its individual ticks.
      list_1: Radius: Defines the radius of the Middle Ring.
      list_2: Thickness: Defines the thickness of the ring.
      list_3: Tick Length: Defines the length of the individual ring ticks.
      list_4: Tick Count: Defines the number of ticks distributed around the ring.
    outer_wave:
      title: Outer Wave
      text: The Outer Wave geometry values determine its fundamental dimensions and the geometric resolution of the outer wave structure.
      list_1: Radius: Defines the base radius of the Outer Wave.
      list_2: Thickness: Defines the thickness of the rendered wave structure.
      list_3: Segments: Defines the number of segments used to construct the circular wave structure.
    relation:
      title: Interaction with Animation and Colors
      text_1: Core Geometry defines the base shapes and dimensions of the individual Core layers. Animations can move these structures at runtime or dynamically influence their presentation.
      text_2: Core Colors independently determine the coloring of the geometric elements. Geometry, animation, and colors therefore form separate configuration areas that together define the appearance of the Horum Core.
    export:
      title: Use for Export
      text_1: The editable Horum Default configuration represents the custom geometry configuration and can be used when creating a Core export.
      text_2: Installed package configurations remain unchanged. Selecting one only determines which already installed geometry design Horum currently uses for the Core.
    summary:
      title: Summary
      text: Core Geometry separates the editable Horum Default configuration from installed package configurations. Radius, thickness, segments, and Middle Ring properties can be adjusted, saved, and used for exports in the custom configuration. Installed geometry designs remain read-only and are not overwritten.

documentation:
  developer:
    title: Developer
    intro: The Developer section contains advanced system options for Horum. These settings are primarily intended for developers and experienced users who want direct control over search providers and advanced functionality.
    purpose:
      title: Developer Settings
      text_1: The Developer settings provide functions that go beyond Horum's regular configuration. Changes in this area should be made deliberately.
      text_2: Adjusting these settings is not required for normal use of Horum. The available default settings already provide the basic configuration required for supported functions.
    plans:
      title: Availability by License
      text_1: Which functions of the Developer section can be used partially depends on the active Horum plan.
      text_2: Basic settings are already available with the Free plan. This includes, for example, the option to allow Horum to access the internet. More advanced developer functions may require higher plans.
    search:
      title: Search Providers
      text_1: The Search Providers section determines which search services Horum may use for internet-based searches. Each provider has its own activation setting.
      text_2: Depending on the selected search provider, additional credentials may be required. Fields for an API key and Search Engine ID are available for this purpose.
      list_1: Active: Enables or disables the respective search provider.
      list_2: API Key: Allows a required API key to be configured for the respective provider.
      list_3: Search Engine ID: Allows a required search engine ID to be configured.
    providers:
      title: Available Search Providers
      text_1: Horum provides several search providers to choose from. This determines which services are available for search operations.
      text_2: The required configuration may differ depending on the provider.
      list_1: DuckDuckGo
      list_2: Google Search
      list_3: Brave Search
      list_4: Bing Search
      list_5: SearXNG
      list_6: Custom Provider
    advanced:
      title: Advanced Settings
      text_1: In addition to search providers, the Developer section contains additional settings that can enable or disable specific Horum system functions.
      text_2: Some of these functions are intended for regular operation, while others are specifically designed for advanced or experimental use.
      list_1: Enable Experimental Features: Allows functions designated as experimental to be used.
      list_2: Use Hardware Acceleration: Enables the use of hardware acceleration by Horum.
      list_3: Allow Internet Access: Determines whether Horum may use functions that require internet access.
      list_4: Automatic Summaries: Enables automatic summaries by Horum.
      list_5: Enable Memory Limits: Enables the configured memory limits.
    internet:
      title: Internet Access
      text_1: The Allow Internet Access option determines whether Horum may use functions that require access to the internet.
      text_2: Internet access is one of the basic settings and is already available with the Free plan. Individual search providers are configured separately within the Developer section.
    future:
      title: Additional Developer Features
      text_1: The Developer section is intended for additional advanced system functionality and will be expanded with further options.
      text_2: Which functions are available and which of them can be used may depend on the respective Horum plan.
    save:
      title: Saving
      text_1: Saving applies the settings configured in the Developer section.
      text_2: This includes the search provider configuration as well as the selected advanced system settings.
    summary:
      title: Summary
      text: The Developer section gives experienced users and developers access to Horum's search providers and advanced system settings. Individual functions may depend on the active license plan, while basic settings such as allowing internet access are already available with the Free plan. The section will be expanded with additional developer functionality in the future.

documentation:
  forbidden:
    title: Forbidden
    intro: The Forbidden section defines boundaries and instructions that determine what Horum should not do, use, or allow. The personal Forbidden.md always forms the foundation, while additional forbidden files can be activated and arranged according to their priority.
    main:
      title: Main Forbidden File
      text_1: The personal Forbidden.md is the user's central forbidden file. It contains the fundamental boundaries for Horum and always has the highest priority among the active forbidden files.
      text_2: It forms the permanent foundation of the personal restrictions and is taken into account independently of any additionally installed or activated forbidden files.
      list_1: The personal Forbidden.md always forms the foundation of the restrictions.
      list_2: The main forbidden file has the highest priority and precedes all additional restrictions.
      list_3: The personal Forbidden.md can be edited and saved directly in the Markdown editor.
    additional:
      title: Additional Restrictions
      text_1: In addition to the personal Forbidden.md, further forbidden files from installed packages can be used. They extend the fundamental boundaries with additional restrictions for specific behaviors, content, or areas of use.
      text_2: Additional restrictions do not replace the personal Forbidden.md but are processed together with it.
      list_1: Additional forbidden files can be enabled or disabled using the checkbox.
      list_2: Multiple additional forbidden files can be active at the same time.
      list_3: Only active forbidden files are taken into account during processing.
    priority:
      title: Priority and Order
      text_1: The personal Forbidden.md always comes first. A separate order can then be defined for the additionally active forbidden files.
      text_2: Horum processes the active restrictions according to this priority. The order therefore determines the sequence in which the additional boundaries and instructions are taken into account.
      list_1: Forbidden.md always has the highest priority.
      list_2: Additional forbidden files can be moved within their order using the arrows.
      list_3: The displayed numbering indicates the priority of the additional forbidden files.
    behavior:
      title: Influence on Horum
      text_1: While Rules.md defines how Horum should act and work, Forbidden.md defines boundaries for that behavior. It specifies which actions, content, or behaviors Horum should not consider or perform.
      text_2: Horum first considers the personal Forbidden.md and then the additional active forbidden files according to their defined order.
    editor:
      title: Markdown Editor
      text_1: Restrictions are represented as Markdown files. The personal Forbidden.md can be edited directly using the integrated Markdown editor.
      text_2: For forbidden files from installed packages, the editor is used for viewing only. Package files are read-only and cannot be modified within the settings.
      list_1: Personal Forbidden.md: Read, edit, and save.
      list_2: Installed package restrictions: Read without editing.
    markdown:
      title: Forbidden.md Structure
      text_1: Forbidden files use Markdown to organize restrictions and their associated areas. The legend above the editor shows the most important available structural elements.
      text_2: This allows different restriction areas to be separated and individual boundaries to be defined clearly.
      list_1: # MD Title: Defines a main heading within the Markdown file.
      list_2: <!-- Comment -->: Adds a comment that can be used for internal organization of the file.
      list_3: ## Title: Creates a subordinate heading for a separate restriction section.
      list_4: - Forbidden: Defines an individual restriction or boundary as a list item.
    packages:
      title: Restrictions from Packages
      text_1: Installed personality packages can provide additional Forbidden files. These appear in the restriction management area and can be activated and arranged according to their priority.
      text_2: Files belonging to installed packages remain unchanged. They can be viewed and activated for Horum but cannot be overwritten through the settings.
      list_1: Installed package restrictions can be enabled or disabled.
      list_2: Active package restrictions can be prioritized below the personal Forbidden.md.
      list_3: The content of a package forbidden file is read-only.
    save:
      title: Saving
      text_1: Saving applies changes to the personal Forbidden.md as well as the selection and order of the additionally active forbidden files.
      text_2: The contents of installed package restrictions are not modified.
    export:
      title: Use for Export
      text_1: When exporting a custom personality, the personal Forbidden.md is used. It contains the user's own editable restrictions that can become part of the custom export.
      text_2: Additionally activated Forbidden files from installed packages are not included in the export as custom forbidden files. They remain part of their respective installed packages.
    summary:
      title: Summary
      text: The personal Forbidden.md always forms Horum's central forbidden file, has the highest priority, and is used when exporting the user's own personality. Additional package restrictions can be activated and prioritized and complement the personal boundaries, but remain read-only and are not exported as part of the user's own Forbidden.md.

documentation:
  horum_window:
    title: Horum Window
    intro: The Horum Window section configures the fundamental appearance of the Work UI and Result UI. Both interfaces have their own designs and can independently use Horum Default or an installed package.
    interfaces:
      title: Work UI and Result UI
      text_1: The settings are divided into two areas: Work UI and Result UI. Both use the same fundamental styling system but are configured independently.
      text_2: For example, the Work UI can use a custom-designed Horum Default while the Result UI simultaneously uses a design from an installed package.
      list_1: Work UI: Displays the interface Horum works with during an operation.
      list_2: Result UI: Displays the interface used for prepared results.
      list_3: Design selection and configuration are handled independently for both UI types.
    design:
      title: Design Selection
      text_1: The Work UI and Result UI each have their own design selection. Horum Default represents the personal and editable design.
      text_2: Additionally installed designs also appear in the respective selection. As with the Core settings, only the default values can be edited. When a package design is selected, its corresponding settings are disabled for editing.
      list_1: Horum Default can be fully customized.
      list_2: Installed package designs can be selected but cannot be modified.
      list_3: Work UI and Result UI can use different designs.
    states:
      title: Focus and Inactive
      text_1: The window appearance distinguishes between the Focus and Inactive states. This visually indicates whether Horum is currently working actively with an interface or is only using it in the background.
      text_2: Inactive does not mean that the window has been closed or that its associated operation has ended. Horum can continue using the interface operationally in the background, for example for analysis, searches, or other ongoing processes.
      list_1: Focus: Horum is currently working actively with the interface.
      list_2: Inactive: The interface remains available and can continue operating, but is not currently in active focus.
    window:
      title: Window Design
      text_1: The first styling area controls the geometry and fundamental appearance of the respective window. In addition to its size and shape, colors and opacity can be configured separately for Focus and Inactive.
      text_2: Both states provide a start and end color for the background as well as a separate border color. This allows the background to use a color gradient while also visually distinguishing the current window state.
      list_1: Width: Determines the width of the window.
      list_2: Minimum Height: Defines the minimum height of the window.
      list_3: Corner Radius: Determines the rounding of the window corners.
      list_4: Border Width: Determines the thickness of the outer window border.
      list_5: Background: Start color, end color, and opacity can be configured separately for Focus and Inactive.
      list_6: Border: Border color and border opacity can be configured separately for Focus and Inactive.
    widgets:
      title: Widget Styling
      text_1: The second styling area controls the appearance of the widgets within the interface. These settings are independent of the fundamental window geometry and state colors.
      text_2: This allows the contained UI elements to be styled consistently with the selected window design.
      list_1: Corner Radius: Determines the rounding of the widgets.
      list_2: Border Width: Determines the thickness of widget borders.
      list_3: Divider Thickness: Determines the thickness of divider lines within the interface.
      list_4: Background Color: Determines the fundamental background color of the widgets.
      list_5: Border Color: Determines the color of widget borders.
    fonts:
      title: Fonts and Content
      text_1: The third styling area controls the presentation of content within the widgets. Fonts, sizes, and text colors can therefore be configured independently of the window and widget styling.
      text_2: The font dropdowns display the available fonts directly in their respective typeface. This makes it possible to visually evaluate a font while selecting it instead of seeing only its name.
      list_1: Text & Labels: Defines the font used for regular text and labels.
      list_2: Titles: Defines the font used for titles.
      list_3: Text Size: Determines the size of regular text.
      list_4: Label size and title size can be configured separately.
      list_5: Text colors can be configured independently for Focus and Inactive.
    work_ui:
      title: Work UI
      text_1: The Work UI is used by Horum during active operations. Its design can be selected and configured independently of the Result UI.
      text_2: With Horum Default, the window, widgets, and content can be fully customized. If an installed Work UI design is selected instead, its design values remain protected and cannot be edited.
    result_ui:
      title: Result UI
      text_1: The Result UI uses the same fundamental styling system as the Work UI but has its own design selection and settings.
      text_2: Horum Default can also be customized here, or an installed Result UI design can be selected. The Result UI selection is independent of the Work UI selection.
    packages:
      title: Designs from Packages
      text_1: Installed packages can provide additional designs for the Work UI or Result UI. These designs appear in the respective design selection.
      text_2: Package designs are not modified directly. Once a package is selected, its corresponding styling settings are read-only or disabled for editing.
      list_1: Horum Default remains the editable personal design.
      list_2: Package designs can be selected and used but cannot be overwritten.
      list_3: Work UI and Result UI can independently use default or package designs.
    save:
      title: Saving
      text_1: Saving applies the selected designs for the Work UI and Result UI. Changes to styling values are saved only for the respective editable default configuration.
      text_2: If a package design is used for either interface, the design values contained in that package remain unchanged.
    summary:
      title: Summary
      text: The Horum Window can be styled independently for the Work UI and Result UI. Horum Default allows the window, widgets, and content to be customized, while installed package designs remain protected. Focus and Inactive additionally provide different appearances depending on whether Horum is actively working with an interface or using it operationally in the background.

documentation:
  license_plans:
    title: License Plans
    intro: The license overview displays the available Horum plans, their included features, and the currently active plan. Managing or changing a plan is not handled within the application.
    overview:
      title: Available Plans
      text_1: Horum provides a comparison of the Free, Personal, and Premium license plans. Each plan offers different features and limits.
      text_2: The overview is designed to identify the current plan and directly compare it with the other available plans.
      list_1: Free: Free entry plan with fundamental features and limited allowances.
      list_2: Personal: Extended plan for productive everyday use with higher limits and additional features.
      list_3: Premium: Most comprehensive plan with the full available feature set and the highest or unlimited allowances.
    comparison:
      title: Comparing Plans
      text_1: Each plan card displays the currently offered price together with its included features and limits. This makes it possible to directly compare the differences between Free, Personal, and Premium.
      text_2: The displayed prices and included features reflect the current offering and may change with future versions or adjustments to the license models.
      list_1: AI and models: Online AI, local AI models, and local generators.
      list_2: Marketplace and content: Number of available products as well as standard and premium voices and Voice Styles.
      list_3: Personality and behavior: Rules, forbidden rules, and the Soul system.
      list_4: Memory and configuration: Memory categories and paths per category.
      list_5: Additional features: Voice input, voice output, custom form of address, Developer Panel, and export and import.
    active:
      title: Active Plan
      text_1: The plan currently associated with the signed-in Horum account is clearly highlighted within the overview.
      text_2: Because the active plan is already in use, it cannot be selected again. Its corresponding button is therefore disabled and grayed out.
      list_1: The active plan is visually highlighted.
      list_2: The button displays the Active Plan status.
      list_3: The active plan button is disabled and cannot be clicked.
    login:
      title: Sign-In Required
      text_1: The user must be signed in within the Horum application to display the personal license status and active plan.
      text_2: Changing a plan through the Horum website also requires signing in with the corresponding account.
    management:
      title: Upgrade and Downgrade
      text_1: License plan management is not provided within the Horum application. The application displays the available plans and provides direct access to the web-based plan management.
      text_2: Selecting Upgrade or Downgrade for another plan redirects the user to the Horum website. The actual plan change is performed there.
      list_1: Upgrade: Opens the website to switch to a higher plan.
      list_2: Downgrade: Opens the website to switch to a lower plan.
      list_3: Plan changes and plan management are handled exclusively through the website.
    summary:
      title: Summary
      text: The license page within the application is used to display and compare the available Horum plans. The active plan is highlighted and cannot be selected again. Upgrades and downgrades are not performed within the application but are managed through the Horum website.

documentation:
  memory:
    title: Memory
    intro: Memory determines which information Horum may retain permanently and how memories are processed and organized. This provides control over how Horum stores knowledge, recognizes existing information, and uses it in future interactions.
    system:
      title: Memory and Learning Behavior
      text_1: The Memory system forms Horum's long-term memory. Information can be stored as memories and taken into account again during future operations.
      text_2: These settings do not define the content of individual memories. Instead, they determine how Horum manages its memory, recognizes similar information, and organizes stored knowledge.
    general:
      title: General Settings
      text_1: The fundamental functions of the Memory system can be enabled or disabled individually. This determines how independently Horum can store and manage memories.
      text_2: These options affect both the general use of memory and how existing or similar memories are handled.
      list_1: Enable Memory: Enables the Memory system and the use of permanently stored memories.
      list_2: Enable Intelligent Storage: Enables intelligent processing when new memories are stored.
      list_3: Avoid Duplicate Memories: Prevents information that already exists or is sufficiently similar from being stored unnecessarily multiple times.
      list_4: Automatically Merge Memories: Allows Horum to automatically merge related or sufficiently similar memories.
    similarity:
      title: Memory Similarity
      text_1: The Levenshtein distance and a similarity threshold can be configured to recognize information that is already known or similar to existing memories.
      text_2: These settings determine how similar information must be before Horum treats it as already known or related during memory processing.
      list_1: Levenshtein Distance: Defines the maximum character deviation considered when comparing memories.
      list_2: Similarity Threshold: Defines the percentage of similarity required for information to be recognized as an existing or sufficiently similar memory.
    files:
      title: Memory Files
      text_1: A maximum size can be defined for individual Memory files. It is also possible to determine the file size at which a new file is created automatically.
      text_2: This allows long-term memory to be distributed across multiple files instead of growing indefinitely within a single Memory file.
      list_1: Maximum File Size: Defines the intended maximum size of an individual Memory file in MB.
      list_2: Create New File At: Defines the file size at which a new Memory file is created automatically.
    categories:
      title: Categories
      text_1: Categories can be provided to Horum so that its memory and learning behavior can follow a desired structure. They help organize stored information by topic.
      text_2: Categories are not mandatory. If no categories are provided, Horum decides for itself how stored knowledge should be organized.
      list_1: Custom categories can be added dynamically and named individually.
      list_2: Categories can be enabled or disabled individually.
      list_3: Categories that are no longer required can be removed from the configuration.
      list_4: When categories are available, Horum can use them as guidance for organizing its memory and learning behavior.
    learning:
      title: Learning Capability
      text_1: The Memory system allows Horum to retain relevant information beyond individual interactions and take this stored knowledge into account again later.
      text_2: The combination of intelligent storage, similarity detection, duplicate prevention, optional merging, and categories influences how Horum builds and organizes its long-term knowledge.
    export:
      title: Export
      text_1: The configured category structure can be exported. This allows an existing organization of the Memory system to be preserved or reused outside the current configuration.
      text_2: Exporting makes it possible to use the defined categories again later without having to recreate the entire structure manually.
    import:
      title: Import
      text_1: A previously exported category structure can be imported again. This allows existing organizational definitions for the memory system to be restored in Horum.
      text_2: After importing, Horum can once again use the imported categories as guidance for organizing the Memory system.
    save:
      title: Saving
      text_1: Saving applies the configured Memory system settings.
      text_2: This includes the general Memory options, similarity and file-size settings, and the configured category structure.
    summary:
      title: Summary
      text: The Memory system controls Horum's long-term memory and learning behavior. Similarity detection, duplicate prevention, merging, and file limits determine how memories are handled. Categories can additionally provide a desired organizational structure; without such definitions, Horum organizes its memory independently. The category structure can be exported and imported again later.

documentation:
  models_generators:
    title: Models & Generators
    intro: The Models & Generators section determines which AI Horum uses and which local systems are available for media generation. The active AI model can be configured to use either an online API or local models.
    active_model:
      title: Active AI Model
      text_1: Horum can operate either with an online model through an API or with locally installed AI models. These two operating modes are used separately and cannot be combined as the active AI model.
      text_2: The Active AI Model selection determines which option Horum uses for its AI processing.
      list_1: Online Model: Uses an AI model through the API of a supported provider.
      list_2: Local Model: Uses an AI model installed on the local system.
      list_3: Online and local models cannot be combined as the active AI model.
    online:
      title: Online Models
      text_1: The Online section allows a supported API provider to be selected, followed by the desired model offered by that provider.
      text_2: Horum supports different providers and models, including GPT, Claude, Gemini, and DeepSeek. Which models are available depends on the respective provider and its integration.
      list_1: Provider: Determines which online AI provider is used.
      list_2: Model: Determines the specific AI model from the selected provider.
      list_3: The corresponding API key from the provider is used for the connection.
      list_4: Available settings can vary depending on the selected provider and model.
    api:
      title: API Connection
      text_1: Online models are connected through the API of the respective provider. The required API key is stored in the model configuration.
      text_2: The API key allows Horum to access the selected online model. Provision, validity, and usage of the key are determined by the respective provider.
    parameters:
      title: Model Parameters
      text_1: Additional model parameters can be available for online models. The displayed options are adapted to the capabilities and configuration options of the selected model.
      text_2: This means that only parameters intended for the respective model integration are provided. Not every model therefore supports the same settings.
      list_1: Thinking Mode: Determines whether a supported thinking mode is used.
      list_2: Thinking Intensity: Determines the intensity of the thinking mode for supported models.
      list_3: Temperature: Controls the corresponding generation parameter of the model.
      list_4: Top P: Controls the corresponding selection parameter of the model.
      list_5: Maximum Tokens: Defines the configured maximum number of tokens.
    local:
      title: Local AI Models
      text_1: The Local section configures AI models available on the user's own system. Processing is performed through the locally configured models instead of an online model.
      text_2: Depending on the active license plan, one or multiple local models can be available.
      list_1: Local models run on the user's own system.
      list_2: The number of usable local models depends on the license plan.
      list_3: When multiple models are available, their order can be configured.
    local_priority:
      title: Priority of Local Models
      text_1: When multiple local AI models are configured, they can be arranged according to their priority. This allows Horum to consider the available models in a defined order.
      text_2: Users who prioritize speed should preferably select a single suitable model. Querying multiple models can require additional time depending on their number and the performance of the system.
      list_1: Multiple local models can be arranged by priority.
      list_2: The order determines the priority in which the models are considered.
      list_3: A larger number of models to query can increase processing time.
    generators:
      title: Local Generators
      text_1: Generators are organized according to their respective capabilities. This allows the local systems used for different generation tasks to be configured separately.
      text_2: Not every generator supports the same functions. The configuration must therefore take into account which tasks each generator is designed to perform.
      list_1: Create Images: Generators for creating new images.
      list_2: Edit Images: Generators for editing existing images.
      list_3: Create Videos: Generators for creating new videos.
      list_4: Images to Videos: Generators for creating videos based on an image.
    generator_priority:
      title: Generator Priority
      text_1: Within each supported capability, multiple generators can be arranged according to priority. Prioritization is configured separately for each type of generation.
      text_2: This determines which suitable generator should be preferred for a particular task.
      list_1: Priority is configured separately for each capability.
      list_2: A generator can only be considered for capabilities it actually supports.
      list_3: The order determines which suitable generators are considered first.
    generator_api:
      title: Generators through Online Models
      text_1: A separate API connection exclusively for generators is currently not provided. Generators are primarily configured through the locally available systems.
      text_2: If the selected online AI model directly supports corresponding generation requests, these capabilities can be available through its existing model connection.
    license:
      title: License Plan Dependency
      text_1: The number of local AI models and generators that can be used depends on the active Horum license plan. The plans provide different allowances and capabilities for these systems.
      text_2: The systems that can actually be selected therefore depend both on the installed models and generators and on the capabilities of the active plan.
    requirements:
      title: System Requirements
      text_1: Local AI models and especially generators run on the user's own computer and can have different requirements for the available hardware.
      text_2: The respective system requirements must therefore be considered before using a generator. Detailed information about individual generators and their requirements is provided in the Marketplace generator documentation.
    summary:
      title: Summary
      text: Horum can use either an online model through an API or local AI models. Online parameters adapt to the selected model, while multiple local models can be organized by priority. Local generators are additionally configured according to their capabilities and priorities. The availability and number of local systems depend on the license plan, and their use must take the requirements of the user's computer into account.

documentation:
  paths:
    title: Paths
    intro: The path settings determine where Horum finds local AI systems and which applications, games, and media Horum is allowed to access. Multiple folders can be added dynamically and selectively authorized depending on the section.
    storage:
      title: Storage Paths
      text_1: Separate installation paths can be configured for local AI models and generators. These paths apply exclusively to locally installed systems.
      text_2: Horum uses these directories to locate the corresponding local models and generators.
      list_1: Local AI Models: Storage and installation path for locally used AI models.
      list_2: Generators: Storage and installation path for locally used generators.
    access:
      title: Paths and Access Permissions
      text_1: Paths for applications, games, and media do more than determine where Horum searches for content. They also define which content Horum is allowed to read, use, or execute.
      text_2: This provides direct control over which areas of the computer are available to Horum.
    applications:
      title: Applications
      text_1: One or more search paths can be added in the Applications section. Horum searches these paths for executable EXE files and displays discovered applications in a separate list.
      text_2: Because the search is based on executable files, games, utility programs, or other EXE files can also be discovered. Search paths should therefore be selected deliberately.
      list_1: Search paths determine which folders are searched for executable files.
      list_2: Add Folder allows additional search paths to be added dynamically.
      list_3: Discovered EXE files are displayed in the Found Applications list.
      list_4: A discovered file is not automatically authorized for execution by Horum.
    application_list:
      title: Managing Discovered Applications
      text_1: The list of discovered applications also acts as an authorization list for Horum. An entry must be enabled before Horum is allowed to start the corresponding application.
      text_2: Unwanted or unnecessary entries can be hidden using the visibility control. Hidden entries are moved to the bottom and remain separated from the normally visible applications.
      list_1: Enabled: Horum is allowed to use or start the discovered application.
      list_2: Disabled: The application remains in the list but is not authorized for Horum.
      list_3: Hidden: The entry is hidden using the eye icon and moved to the bottom.
      list_4: Refresh searches the configured paths again. All discovered entries can also be selected or deselected together.
    games:
      title: Games
      text_1: The Games section works similarly to the application search. Search paths can be added and discovered games can then be individually enabled, disabled, or hidden.
      text_2: Here as well, authorization in the result list determines which discovered entries Horum is allowed to use or start.
      list_1: Enabled games are authorized for Horum.
      list_2: Disabled games remain registered but cannot be started by Horum.
      list_3: Hidden entries are concealed using the eye icon and moved to the bottom.
    game_libraries:
      title: Steam and Epic Games
      text_1: Additional dedicated search options are available for Steam and Epic Games. These allow the respective library information to be used instead of relying exclusively on a general search for EXE files.
      text_2: This is particularly useful for game libraries where installed games cannot be reliably identified through a general executable-file search alone.
      list_1: Steam: Uses the Steam library to identify installed games.
      list_2: Epic Games: Uses the Epic Games library to identify installed games.
    recursive:
      title: Recursive Search
      text_1: When Recursive Search is enabled, Horum does not search only the selected folder itself. The search is also extended to its subfolders.
      text_2: Large or very general directories can contain a significant number of executable files. Users who want a clean and targeted list should therefore enable recursive searching only for appropriate directories.
      list_1: Disabled: The search remains limited to the specified folder.
      list_2: Enabled: Subfolders below the selected folder are searched as well.
    dynamic:
      title: Multiple Folders
      text_1: Additional folders can be added dynamically to the supported sections. Path configuration is therefore not limited to a single storage location.
      text_2: Additional folders are added to the respective path list and can be used together for searching or access by Horum.
    media:
      title: Media
      text_1: Separate folders can be configured for audio, video, images, and documents. These directories determine which personal media content Horum is allowed to access directly.
      text_2: Media paths can also be extended. Recursive searching can additionally include subfolders within an authorized media folder.
      list_1: Audio: Authorized folders for music and other supported audio files.
      list_2: Video: Authorized folders for supported video files.
      list_3: Images: Authorized folders for images and photos.
      list_4: Documents: Authorized folders for supported document files.
    media_access:
      title: Media Access by Horum
      text_1: Horum provides functions for playing and displaying audio, videos, and images as well as reading documents. The media paths authorized here are used for direct access.
      text_2: Media outside the corresponding authorized paths is not part of Horum's regular media access. This keeps control over which personal files are available to these functions.
    console:
      title: Use by Mini Windows
      text_1: The media paths are also used by the corresponding Console mini windows. When a media list is opened there, it accesses the paths configured for that media type.
      text_2: This means that Horum and its associated interfaces use the same defined media authorization.
      list_1: An audio list uses the configured audio paths.
      list_2: A video list uses the configured video paths.
    permissions:
      title: Permissions and Security
      text_1: Path management also acts as a controlled authorization system. Applications, games, and media must be authorized within their designated sections before Horum is allowed to regularly read, use, or execute them.
      text_2: System files and other protected areas may additionally require special permissions from the operating system.
      list_1: Applications and games must be enabled for Horum after discovery before they can be executed.
      list_2: Media is authorized for direct access through the configured media folders.
      list_3: Operating-system-protected files and locations may require additional permissions.
    summary:
      title: Summary
      text: The path settings combine storage locations, discovery, and access permissions. Local AI models and generators have their own installation paths, applications and games are discovered and then explicitly authorized, while audio, videos, images, and documents become accessible through defined media folders. Multiple folders and optional recursive searching provide flexible configuration without granting Horum unrestricted access to all content on the system.

documentation:
  rules:
    title: Rules
    intro: The Rules section defines instructions that Horum takes into account in its behavior, decisions, and way of working. The personal Rules.md always forms the foundation, while additional rule files can be activated and arranged according to their priority.
    main:
      title: Main Rule File
      text_1: The personal Rules.md is the user's central rule file. It contains the fundamental instructions for Horum and always has the highest priority among the active rule files.
      text_2: It forms the permanent foundation of the personal rules and is taken into account independently of any additionally installed or activated rule files.
      list_1: The personal Rules.md always forms the foundation of the rules.
      list_2: The main rule file has the highest priority and precedes all additional rules.
      list_3: The personal Rules.md can be edited and saved directly in the Markdown editor.
    additional:
      title: Additional Rules
      text_1: In addition to the personal Rules.md, further rule files from installed packages can be used. They extend the fundamental rules with additional instructions for specific behaviors, tasks, or areas of use.
      text_2: Additional rules do not replace the personal Rules.md but are processed together with it.
      list_1: Additional rule files can be enabled or disabled using the checkbox.
      list_2: Multiple additional rule files can be active at the same time.
      list_3: Only active rule files are taken into account during processing.
    priority:
      title: Priority and Order
      text_1: The personal Rules.md always comes first. A separate order can then be defined for the additionally active rule files.
      text_2: Horum processes the active rules according to this priority. The order therefore determines the sequence in which the additional instructions are taken into account.
      list_1: Rules.md always has the highest priority.
      list_2: Additional rule files can be moved within their order using the arrows.
      list_3: The displayed numbering indicates the priority of the additional rule files.
    behavior:
      title: Influence on Horum
      text_1: Active rules provide Horum with specific instructions for its behavior and way of working. They complement its personality with instructions that Horum should take into account when processing and performing tasks.
      text_2: Horum first considers the personal Rules.md and then the additional active rule files according to their defined order.
    editor:
      title: Markdown Editor
      text_1: Rules are represented as Markdown files. The personal Rules.md can be edited directly using the integrated Markdown editor.
      text_2: For rule files from installed packages, the editor is used for viewing only. Package files are read-only and cannot be modified within the settings.
      list_1: Personal Rules.md: Read, edit, and save.
      list_2: Installed package rules: Read without editing.
    markdown:
      title: Rules.md Structure
      text_1: Rules files use Markdown to organize rules and their associated areas. The legend above the editor shows the most important available structural elements.
      text_2: This allows different rule areas to be separated and individual instructions to be defined clearly.
      list_1: # MD Title: Defines a main heading within the Markdown file.
      list_2: <!-- Comment -->: Adds a comment that can be used for internal organization of the file.
      list_3: ## Title: Creates a subordinate heading for a separate rule section.
      list_4: - Rule: Defines an individual rule or instruction as a list item.
    packages:
      title: Rules from Packages
      text_1: Installed personality packages can provide additional Rules files. These appear in the rule management area and can be activated and arranged according to their priority.
      text_2: Files belonging to installed packages remain unchanged. They can be viewed and activated for Horum but cannot be overwritten through the settings.
      list_1: Installed package rules can be enabled or disabled.
      list_2: Active package rules can be prioritized below the personal Rules.md.
      list_3: The content of a package rule file is read-only.
    save:
      title: Saving
      text_1: Saving applies changes to the personal Rules.md as well as the selection and order of the additionally active rule files.
      text_2: The contents of installed package rules are not modified.
    export:
      title: Use for Export
      text_1: When exporting a custom personality, the personal Rules.md is used. It contains the user's own editable rules that can become part of the custom export.
      text_2: Additionally activated Rules files from installed packages are not included in the export as custom rule files. They remain part of their respective installed packages.
    summary:
      title: Summary
      text: The personal Rules.md always forms Horum's central rule file, has the highest priority, and is used when exporting the user's own personality. Additional package rules can be activated and prioritized and complement the personal rules, but remain read-only and are not exported as part of the user's own Rules.md.

documentation:
  soul:
    title: Soul
    intro: The Soul section defines Horum's personality, character, and communication style. The personal Soul.md always forms the foundation, while additional souls can be activated and arranged according to their priority.
    main:
      title: Main Soul
      text_1: The personal Soul.md is Horum's main soul. It represents the user's fundamental personality configuration and always has the highest priority among the active souls.
      text_2: It serves as the permanent foundation for Horum's behavior and communication and is taken into account independently of any additionally installed or activated souls.
      list_1: The personal Soul.md always forms the foundation of the personality.
      list_2: The main soul has the highest priority and precedes all additional souls.
      list_3: The main soul can be edited and saved directly in the Markdown editor.
    additional:
      title: Additional Souls
      text_1: In addition to the main soul, further souls from installed packages can be used. They extend the fundamental personality with additional characteristics, communication styles, or behavioral instructions.
      text_2: Additional souls do not replace the personal main soul but are processed together with it.
      list_1: Additional souls can be enabled or disabled using the checkbox.
      list_2: Multiple additional souls can be active at the same time.
      list_3: Only active souls are taken into account during processing.
    priority:
      title: Priority and Order
      text_1: The main soul always comes first. A separate order can then be defined for the additionally active souls.
      text_2: Horum processes the active souls according to this priority. The order therefore determines the sequence in which the additional personality instructions are taken into account.
      list_1: Soul.md always has the highest priority.
      list_2: Additional souls can be moved within their order using the arrows.
      list_3: The displayed numbering indicates the priority of the additional souls.
    behavior:
      title: Influence on Horum
      text_1: The active souls define how Horum should present itself, communicate, and respond to situations. They therefore form an essential part of its personality and behavior.
      text_2: Horum first considers the personal main soul and then the additional active souls according to their defined order.
    editor:
      title: Markdown Editor
      text_1: Soul content is represented as Markdown files. The personal Soul.md can be edited directly using the integrated Markdown editor.
      text_2: For souls from installed packages, the editor is used for viewing only. Package files are read-only and cannot be modified within the settings.
      list_1: Personal Soul.md: Read, edit, and save.
      list_2: Installed package souls: Read without editing.
    markdown:
      title: Soul.md Structure
      text_1: Soul files use Markdown to organize personality characteristics and instructions. The legend above the editor shows the most important available structural elements.
      text_2: The structure can be used to separate different areas of a personality and clearly define individual characteristics or instructions.
      list_1: # MD Title: Defines a main heading within the Markdown file.
      list_2: <!-- Comment -->: Adds a comment that can be used for internal organization of the file.
      list_3: ## Title: Creates a subordinate heading for a separate section.
      list_4: - Property: Defines an individual characteristic, rule, or instruction as a list item.
    packages:
      title: Souls from Packages
      text_1: Installed personality packages can provide additional Soul files. These appear in the soul management area and can be activated and arranged according to their priority.
      text_2: Files belonging to installed packages remain unchanged. They can be viewed and activated for Horum but cannot be overwritten through the settings.
      list_1: Installed package souls can be enabled or disabled.
      list_2: Active package souls can be prioritized below the main soul.
      list_3: The content of a package soul is read-only.
    save:
      title: Saving
      text_1: Saving applies changes to the personal Soul.md as well as the selection and order of the additionally active souls.
      text_2: The contents of installed package souls are not modified.
    export:
      title: Use for Export
      text_1: When exporting a custom personality, the personal main Soul.md is used. It represents the user's own editable soul and can become part of the custom export.
      text_2: Additional active souls from installed packages are not included in the export as custom Soul files. They remain part of their respective installed packages.
    summary:
      title: Summary
      text: The personal Soul.md always forms Horum's main soul, has the highest priority, and is used when exporting the user's own personality. Additional package souls can be activated and prioritized and influence Horum's behavior together with the main soul, but remain read-only and are not exported as part of the user's own soul.

documentation:
  speech_assistant:
    title: Voice Assistant
    intro: The Voice Assistant section configures Horum's voice output, speech recognition, playback, and noise detection. This allows both Horum's voice and the processing of spoken input to be adapted to the system being used.
    output:
      title: Voice Output
      text_1: Voice output determines how and through which device Horum plays spoken responses. The output device and the desired voice provider can be selected for this purpose.
      text_2: The available voices and additional options depend on the selected provider.
      list_1: Output Device: Determines which audio device is used to play Horum's voice.
      list_2: Provider: Determines the voice system used for voice output.
      list_3: Voice: Determines the voice Horum uses to speak.
      list_4: Style: Determines the available speaking style of the selected voice.
    voice:
      title: Voice
      text_1: One of the available voices from the selected provider can be chosen for voice output. This allows Horum's audible presentation to be adapted to personal requirements.
      text_2: Which voices are available depends on the selected provider and the voices available for that provider.
      list_1: A voice is selected within the currently selected voice provider.
      list_2: Changing the provider can change the available voices.
    style:
      title: Voice Style
      text_1: In addition to the voice, an available voice style can be selected. The style influences the linguistic or acoustic expression in which the selected voice is played.
      text_2: The available styles depend on the respective voice output system and the capabilities it supports.
    recognition:
      title: Speech Recognition
      text_1: Speech recognition processes spoken input from the user. The desired input device and speech recognition provider are selected for this purpose.
      text_2: This determines which microphone or input device Horum uses and which recognition system processes the spoken input.
      list_1: Input Device: Determines the microphone or other audio input device.
      list_2: Provider: Determines the system used for speech recognition.
      list_3: Language: Determines how the language of spoken input should be recognized.
    language:
      title: Speech Recognition Language
      text_1: Speech recognition can use either a fixed language or automatic language recognition.
      text_2: With a fixed selection, recognition is configured for the selected language. With Automatic, the language is not fixed to German or English.
      list_1: Automatic: Uses automatic language recognition.
      list_2: Deutsch: Uses German as the defined recognition language.
      list_3: English: Uses English as the defined recognition language.
    playback:
      title: Playback
      text_1: Playback settings influence Horum's spoken responses. Playback speed and volume can be configured independently.
      text_2: This allows voice output to be adjusted to the desired speaking speed and volume.
      list_1: Speed: Determines the playback speed of voice output.
      list_2: Volume: Determines the volume of voice output.
    noise:
      title: Noise Detection
      text_1: Noise detection can additionally be enabled to adapt audio signal processing to background noise.
      text_2: The sensitivity setting determines how sensitively noise detection responds to the incoming audio signal.
      list_1: Enable: Turns noise detection on or off.
      list_2: Sensitivity: Determines the sensitivity of noise detection.
    save:
      title: Saving
      text_1: Saving applies the configured Voice Assistant settings.
      text_2: This includes the voice output and speech recognition configuration as well as playback and noise detection settings.
    summary:
      title: Summary
      text: The Voice Assistant combines Horum's spoken output with the recognition of spoken input. Output device, provider, voice, and style determine voice output, while input device, recognition provider, and language configure speech recognition. Playback speed, volume, and noise detection provide additional control for the audio system being used.

documentation:
  hps:
    title: HPS
    intro: HPS manages the local state of Horum Packages. The system stores which packages are known to Horum, whether they are downloaded and installed, whether their installation is valid, and whether the current user is authorized to access the respective package.
    purpose:
      title: Purpose of HPS
      text_1: HPS provides the central state management system for Horum Packages. Instead of deriving the state of a package exclusively from the file system every time it is used, Horum can centrally manage the relevant package information and status values.
      text_2: The stored state can then be reconciled with the downloads and installations that actually exist and updated when changes are detected.
    state_file:
      title: horum_state.hps
      text_1: Package states are stored in the horum_state.hps file. This is not a regular text or JSON file but uses Horum's binary HPS format.
      text_2: The file contains registered packages together with their basic information and status values and is read and written through the designated HPS components.
    package_data:
      title: Stored Package Data
      text_1: Each HPS entry is uniquely associated through its export ID and contains additional information about the corresponding package.
      text_2: In addition to its status values, HPS stores the following basic package data:
      list_1: export_id: Unique export ID of the package.
      list_2: product_id: Associated product ID of the Marketplace product.
      list_3: name: Name of the package.
      list_4: type: Type of the package or export.
      list_5: size and date: Stored package size and timestamp of the HPS entry.
    status:
      title: Package Status
      text_1: HPS manages several separate status values for each package. This allows Horum to distinguish whether a package is merely present, actually installed, valid, or authorized for the user.
      text_2: These status values are stored as flags within the binary HPS format.
      list_1: download_status: Indicates whether the package is present as a downloaded package.
      list_2: install_status: Indicates whether the package has been recognized as installed.
      list_3: valid: Indicates whether the verified installation is valid.
      list_4: authorized: Indicates whether access to the package is authorized for the user.
    binary_format:
      title: Binary HPS Format
      text_1: The horum_state.hps file uses its own binary format. The file header identifies the file as HPS and additionally contains the format version and the number of stored package entries.
      text_2: The individual package records then store the required text lengths, package size, status flags, timestamp, and their associated text values.
      list_1: Magic: HPS identifies the file as Horum Package State.
      list_2: Version: The current format uses HPS version 1.
      list_3: Flags: Download, installation, validity, and authorization states are stored together as status flags.
    manager:
      title: HPS Manager
      text_1: The HPS Manager provides the central interface for accessing package state. Other parts of Horum can use it to read package entries and manage their status.
      text_2: Changes are subsequently written back to the horum_state.hps file.
      list_1: Packages can be read in full or individually by their export ID.
      list_2: New package entries can be added to HPS.
      list_3: Existing entries and their permitted status values can be updated.
      list_4: Package entries can be removed, and reconcile and synchronization operations can be triggered.
    reader_writer:
      title: Reader and Writer
      text_1: The HPS Reader reads the binary state file, verifies the HPS header and supported version, and converts the stored records back into package information and status values.
      text_2: The HPS Writer performs the reverse operation. It creates the binary structure from the package data and first writes it to a temporary file before replacing the existing state file.
    reconcile:
      title: Package State Reconciliation
      text_1: The reconcile process compares the stored HPS data with the package state that actually exists. Existing downloads and installations are detected and then verified.
      text_2: The resulting information is written back into the HPS state so that the stored state can be reconciled with the packages and installations actually present.
      list_1: Existing downloads are detected and validated as Horum Packages.
      list_2: Existing installations are detected and compared with the expected installation data.
      list_3: Access authorization and installation validity are verified.
      list_4: Download, installation, validity, and authorization states are updated accordingly.
    validation:
      title: Validation
      text_1: HPS uses multiple checks to validate the package and its installation separately. Both the properties of the HRM file and the files actually installed are taken into account.
      text_2: Integrity verification uses the file information and SHA-256 values stored in the export manifest.
      list_1: Package validation: Checks the .hrm file extension, package format, export format, export ID, name, and supported export type, among other properties.
      list_2: Installation validation: Detects missing files, differing SHA-256 values, and unexpected files within the installation.
      list_3: Path validation: Prevents installation paths from escaping the designated Horum Package area.
    authorization:
      title: Authorization
      text_1: In addition to local package and installation validation, HPS maintains a separate authorization state. The access check uses the package export ID and, when a user is logged in, the user's ID.
      text_2: The result of this check is stored as the authorized state of the HPS entry and can therefore be handled separately from download, installation, and validity status.
    sync:
      title: Synchronization
      text_1: HPS can additionally synchronize package states with the designated package synchronization system. The stored download and installation status of a package are used in this process.
      text_2: During a combined reconcile and synchronization operation, the previous and new states are compared. Synchronization is triggered for packages whose download or installation status has changed.
    summary:
      title: Summary
      text: HPS is the central state management system for Horum Packages. The binary horum_state.hps file stores package data together with download, installation, validity, and authorization states. Reader, Writer, Manager, validation, and reconciliation work together so Horum can manage stored package state and compare it with the packages and installations that actually exist.

documentation:
  hrm:
    title: HRM Package Format
    intro: The HRM format is Horum's own package format. Files using the .hrm extension bundle Horum components, manifests, and accompanying documents into a defined structure that can be processed through Horum's package system.
    format:
      title: The Horum Format
      text_1: An .hrm file is a Horum Package. The format is designed to combine different Horum components within a single structured file.
      text_2: The file extension identifies the package as a Horum file to the user, while Horum uses the contained structure and its manifests for further processing.
      list_1: .hrm is the dedicated file extension for Horum Packages.
      list_2: A package can contain an individual Horum component or multiple different components.
      list_3: The internal structure of a package follows the definitions of the Horum Package format.
    icon:
      title: Dedicated File Icon
      text_1: HRM files have their own Horum file icon. This makes Horum Packages visually recognizable as a distinct file type within the file system.
      text_2: The icon is part of the presentation of the .hrm format and distinguishes Horum Packages from ordinary archive files and other file formats.
    compression:
      title: Compression
      text_1: The HRM package format internally uses 7z compression. The contents of a package are therefore stored together within a compressed file.
      text_2: The .hrm extension provides the Horum-specific file layer. To Horum, the package is not merely a general archive but a defined package structure containing manifests, components, and other associated files.
      list_1: Internal compression is based on 7z.
      list_2: Externally, the package uses Horum's .hrm file extension.
      list_3: The contained files must follow the designated Horum Package structure.
    contents:
      title: Package Contents
      text_1: An HRM Package combines the actual Horum components with the information Horum requires to describe and process the package.
      text_2: Which components are actually included depends on the individual export. The fundamental package files and the specific composition are described through the designated manifests.
      list_1: Manifests describe the structure, package properties, and actual export contents.
      list_2: README.md contains basic information about the package and its use.
      list_3: LICENSE.txt contains the terms of use that apply to the package.
      list_4: Exported Horum components are stored within their designated directories.
    components:
      title: Horum Components
      text_1: The package system provides defined areas for the different types of Horum components. An export does not have to contain every area and can be limited to the content actually being exported.
      text_2: The package structure provides the designated directories and, for certain components, additional subdirectories.
      list_1: Personality: Personalities and their associated personality content.
      list_2: Commands: Commands and their associated command content.
      list_3: Core: Configurations for the Horum Core.
      list_4: Horum Windows: Configurations for Horum windows.
      list_5: Worker UI: Content for the Worker UI, including the designated XML and YAML structures.
      list_6: Result UI: Content for the Result UI, including the designated assets, icons, XML, and YAML structures.
    integrity:
      title: Integrity
      text_1: The Horum Package format provides integrity verification for included files. For this purpose, the export_manifest.json can describe individual files using their path and a SHA-256 value.
      text_2: The package manifest defines SHA-256 as the integrity verification algorithm and provides for verification of both the manifest and the included files. Unlisted files are not permitted under this definition.
    installation:
      title: Processing and Installation
      text_1: HRM files are imported through the designated package management system of the Horum Application. Horum reads the included package information and processes the components through the intended package mechanism.
      text_2: The manifests provide the required information about structure, installation areas, and the files and components actually included.
    structure:
      title: File Structure
      text_1: An HRM Package has a defined internal directory structure. The manifests, README.md, and LICENSE.txt are located in the root directory. The actual Horum components are organized within their respective component directories.
      text_2: The following tree representation shows the structural layout of a Horum Package and the designated areas for its files and components.
    summary:
      title: Summary
      text: HRM is Horum's own package format and uses the .hrm file extension together with its own file icon. Internally, the format is based on 7z compression but extends it with a defined Horum structure containing manifests, documents, integrity information, and component directories. This allows Horum to clearly recognize, verify, and process packages through its designated package mechanism.

documentation:
  interpreter:
    title: Interpreter
    intro: The HPS Interpreter translates the information stored in a binary HPS file into a human-readable text representation. This allows the stored package entries and their states to be displayed clearly.
    purpose:
      title: Purpose of the Interpreter
      text_1: The horum_state.hps file stores its information in a binary format and is therefore not intended to be read directly as a regular text file.
      text_2: The Interpreter presents this data in a readable form without changing the underlying HPS file format.
    source:
      title: Reading HPS Data
      text_1: The Interpreter does not read the specified HPS file at the binary level itself. Instead, it uses the HPS Reader for this purpose.
      text_2: As a result, the interpretation is based on the same package data used by other parts of HPS.
    output:
      title: Displayed Package Data
      text_1: The output begins with the HPS version in use and the number of packages contained in the file. A separate readable block is then generated for each package.
      text_2: The export ID forms the key of the respective package block. The following information is displayed within that block:
      list_1: product_id: Associated product ID of the package.
      list_2: name: Name of the package.
      list_3: type: Type of the package or export.
      list_4: size: Stored size of the package.
      list_5: download_status: Indicates whether the package is stored as downloaded.
      list_6: install_status: Indicates whether the package is stored as installed.
      list_7: valid: Displays the stored validity state of the package.
    status:
      title: Status Representation
      text_1: The status values produced by the Interpreter are displayed as readable Boolean values. This represents the binary states as true or false.
      text_2: The HPS state additionally contains the authorized status. However, the current Interpreter does not include this value in its text representation.
    date:
      title: Date and Time
      text_1: The timestamp stored in HPS is converted into a readable date and time for the output.
      text_2: The representation uses the format DD.MM.YYYY HH:MM:SS. If no timestamp is available, the corresponding date value remains empty.
    empty:
      title: Empty HPS State
      text_1: If the HPS file being read contains no package entries, the Interpreter still produces a valid and unambiguous output.
      text_2: In this case, HPS v1 is displayed together with a package count of 0.
    separation:
      title: Separation from HPS
      text_1: The Interpreter is intentionally separated from the actual HPS state management. Its purpose is to present already-read HPS data in an understandable form.
      text_2: Other package system tasks continue to be handled by their designated HPS components.
      list_1: The Interpreter does not add package entries to HPS or remove existing entries.
      list_2: The Interpreter does not modify download, installation, validity, or authorization states.
      list_3: Validation, reconciliation, synchronization, and package installation are not responsibilities of the Interpreter.
    summary:
      title: Summary
      text: The HPS Interpreter provides the readable representation of the binary HPS state. It uses the HPS Reader, structures the contained package data as text, and presents status values and timestamps in a readable form without modifying the stored package state itself.

documentation:
  manifests:
    title: Manifests
    intro: Horum Packages use multiple manifest files to clearly describe the structure, properties, and contents of a package. Together, they form the technical foundation for the structure, verification, and processing of an .hrm file.
    purpose:
      title: Purpose of the Manifests
      text_1: The manifest files divide different responsibilities between them. This separates the general package structure, the properties of the package format, and the actual exported content.
      text_2: Horum can read and use this information when working with a package without having to derive its structure or included components itself.
    files:
      title: The Three Manifests
      text: A Horum Package uses three different manifest files, each with its own purpose.
      list_1: manifest.json: Describes the fundamental directory and file structure of a Horum Package.
      list_2: package_manifest.json: Describes the package format, installation, integrity verification, compatibility, supported capabilities, extensions, and documents.
      list_3: export_manifest.json: Describes the specific export, its publisher, and the Horum components and files actually included.
    manifest:
      title: manifest.json
      text_1: The manifest.json describes the structural layout of a Horum Package. It defines the files in the root directory and the designated directories for the different Horum components.
      text_2: It therefore provides a fixed description of how content is arranged within a package.
      list_1: Defines the files in the package root, including the three manifests, README.md, and LICENSE.txt.
      list_2: Defines directories for Personality, Commands, Core, Horum Windows, Worker UI, and Result UI.
      list_3: Also describes designated subdirectories for individual components, such as XML, YAML, assets, and icons.
    package_manifest:
      title: package_manifest.json
      text_1: The package_manifest.json describes the technical properties of the Horum Package format. These include the platform, file extension, license, installation, integrity, and compatibility.
      text_2: It also describes which Horum components and extensions are supported by the package system and which accompanying documents belong to the package.
      list_1: Defines Horum as the platform and .hrm as the package file extension.
      list_2: Describes installation and references the export_manifest.json together with the designated installation areas.
      list_3: Defines integrity verification using SHA-256 and verification of both the manifest and included files.
      list_4: Describes supported components, extensions, dependencies, as well as README.md and LICENSE.txt.
    export_manifest:
      title: export_manifest.json
      text_1: The export_manifest.json describes the actual contents of a created export. It contains information about the publisher and the export itself, together with the Horum components actually included.
      text_2: Paths and SHA-256 checksums can be stored for included files. This provides an explicit description of the export contents and allows them to be included in the intended integrity verification.
      list_1: Publisher: Contains information such as user ID, author, country, language, seller status, and optional company information.
      list_2: Export: Contains information including the export ID, name, type, language, creation time, and the Horum Package Exporter used.
      list_3: Components: Describes the actual included areas such as Personality, Commands, Core, Horum Windows, Worker UI, and Result UI.
      list_4: Files: Included files are described using their respective path and SHA-256 value.
    interaction:
      title: How the Manifests Work Together
      text_1: The three manifests serve different purposes and complement each other. The manifest.json describes the structure, the package_manifest.json describes the properties and rules of the package format, and the export_manifest.json describes the actual contents of an export.
      text_2: This separation keeps the general package structure, technical package properties, and export-specific content independent from one another.
    readme:
      title: README.md
      text_1: In addition to the manifests, a Horum Package contains a README.md. It provides basic information about the package and how it is used.
      text_2: The README references the package management system of the Horum Application, the included export_manifest.json, and the LICENSE.txt that applies to the package.
      list_1: Package Details: Contains the package name, type, language, and creation date.
      list_2: Installation: Describes importing the .hrm file through the package management system of the Horum Application.
      list_3: Content and License: References the export_manifest.json for included components and the accompanying LICENSE.txt.
    license:
      title: LICENSE.txt
      text_1: The LICENSE.txt contains the Horum Package License and governs the use of the included packages and components within the Horum Application.
      text_2: The license permits use and the intended import within Horum. Using or importing a package does not transfer copyright, ownership, or other proprietary rights. Resale, redistribution, publication, sublicensing, or other distribution is not permitted without appropriate authorization from the respective rights holder.
    structure:
      title: Manifest Structure
      text_1: The following representations show the structure of the three manifest files and make their different roles within a Horum Package directly comparable.
      text_2: manifest.json, package_manifest.json, and export_manifest.json are displayed separately, but operate together within the package system.
    summary:
      title: Summary
      text: The three Horum manifests separate package structure, technical package properties, and actual export contents. README.md supplements the package with basic usage and installation information, while LICENSE.txt defines the terms of use. Together, these files form the descriptive and organizational foundation of a Horum Package.

documentation:
  md_editor:
    title: MD Editor
    intro: The MD Editor is Horum's integrated editor component for Markdown content. It provides a clear interface for displaying and editing Markdown files and includes features such as line numbers and syntax highlighting.
    purpose:
      title: Purpose of the MD Editor
      text_1: Horum uses Markdown files in different areas of the system. The MD Editor provides a shared interface through which this content can be displayed and, where permitted, edited directly.
      text_2: The editor is integrated as part of the Horum interface and can be used for both editable and read-only Markdown content.
    editor:
      title: Editor
      text_1: The MD Editor is based on a text editor and is specifically adapted for displaying Markdown content within Horum.
      text_2: The interface uses a monospace font and keeps longer Markdown files clearly arranged within the available editor area.
      list_1: Monospace font for consistent and clear text presentation.
      list_2: Automatic line wrapping within the available editor width.
      list_3: Dedicated text cursor for direct content editing.
      list_4: Support for loading, retrieving, and clearing the current Markdown content.
    line_numbers:
      title: Line Numbers
      text_1: The MD Editor includes a dedicated line number area. This makes individual lines within a Markdown file easier to identify and reference.
      text_2: Line numbering follows the visible editor content and automatically adapts to the number of text blocks in the document.
    highlighting:
      title: Syntax Highlighting
      text_1: Integrated Markdown syntax highlighting visually distinguishes specific document structures from regular text.
      text_2: Highlighting is applied directly to the open document, making it easier to navigate the Markdown structure.
      list_1: Headings using # and ## are highlighted.
      list_2: Markdown lists using -, *, or + are recognized.
      list_3: HTML comments are highlighted separately.
    comments:
      title: HTML Comments
      text_1: The MD Editor recognizes HTML comments within a Markdown file. This allows internal notes or content that is not intended to be directly visible to be visually distinguished from the remaining Markdown text.
      text_2: Comment detection supports both comments contained within a single line and comments extending across multiple lines.
    read_only:
      title: Read-Only Mode
      text_1: The MD Editor can be placed into a read-only mode. In this state, the content remains visible but cannot be modified through the editor.
      text_2: Horum also changes the cursor accordingly, making it immediately recognizable that editing the opened content is not permitted.
    scrolling:
      title: Scrolling and Display
      text_1: Long content can be scrolled vertically within the editor. The vertical scrollbar is only displayed when the content exceeds the visible editor area.
      text_2: A horizontal scrollbar is not used. Longer lines are instead automatically wrapped to fit the available width of the editor.
    usage:
      title: Use in Horum
      text_1: The MD Editor is used wherever Horum needs to display or edit Markdown content within its interface. Examples include the Personality files Soul.md, Rules.md, and Forbidden.md.
      text_2: Whether content can be edited depends on the respective area in which it is used. User-owned content can be made editable, while protected package content can be displayed through the same editor in read-only mode.
    summary:
      title: Summary
      text: The MD Editor provides Horum with a shared interface for Markdown files. Line numbers, syntax highlighting, automatic text presentation, and a dedicated read-only mode support both editing user-owned Markdown content and controlled display of protected content.

documentation:
  website_navigation:
    title: Website Navigation
    intro: The navigation of the Horum website consists of the header and the footer. Both areas provide direct access to important pages and features of the platform.
    header:
      title: Header Navigation
      text_1: The header is located at the top of the website and serves as the central starting point for navigation within the Horum platform.
      text_2: In addition to direct page links, the header contains further features that are available depending on whether you are signed in.
    main_navigation:
      title: Main Navigation
      text_1: The main navigation provides access to the most important public areas of the website. These include Home, Marketplace, Plans, Community and Documentation.
      text_2: The navigation remains available throughout the different areas of the website, allowing you to switch between the main sections of the platform at any time.
    account_navigation:
      title: Account and Personal Areas
      text_1: When you are signed in, additional account-related features are available in the header. These include access to your Dashboard and the option to sign out.
      text_2: The header can also display information and features connected to your account, such as your Wallet or available credits.
    language:
      title: Language
      text_1: The language selector in the header allows you to change the language of the website.
      text_2: The selected language is applied to supported areas of the website and remains active as you navigate between pages.
    footer:
      title: Footer Navigation
      text_1: The footer is located at the bottom of the website and complements the navigation provided by the header. It provides additional links without overloading the main navigation with extra entries.
      text_2: This keeps frequently used main areas directly accessible through the header, while additional pages and information remain available through the footer.
    footer_navigation:
      title: Footer Links
      text_1: The footer contains additional links to areas and information related to the Horum platform, as well as legal and organizational pages.
      text_2: The links available there depend on the respective areas of the website and can be extended independently of the main navigation.
    summary:
      title: Navigation at a Glance
      text: The header provides the central navigation and access to personal features. The footer complements it with additional pages and information.

documentation:
  website_overview:
    title: The Horum Website
    intro: The Horum website is the central online platform surrounding Horum. Here you can manage your account, license and products, use the Marketplace and interact with other users in the Community.
    purpose:
      title: More than a product website
      text_1: The website is not only used to introduce or download Horum. It is a central part of the Horum platform and brings different online features together in one place.
      text_2: Public areas can be used without an account. Personal features such as the Dashboard, your own products, purchases or management of your Horum license require you to sign in.
    account:
      title: Your Account
      text_1: Your Horum account provides the foundation for the personal areas of the website. It is used to manage your profile and other account-related information.
      text_2: In addition to a personal profile, a company profile can also be used. The individual account features are described in more detail in the Account section of this documentation.
    dashboard:
      title: The Dashboard
      text_1: The Dashboard is where you manage the areas directly associated with your Horum account. These include your profile, My Horum, your license, your Wallet and your published products.
      text_2: You can also create new Marketplace products and manage settings for your account and use of the platform.
    marketplace:
      title: The Marketplace
      text_1: The Marketplace allows extensions and packages for Horum to be published, discovered and acquired. It supports different product types that can modify or extend Horum.
      text_2: Products can be searched, filtered, rated and added to the shopping cart. Free and paid products are provided through the same Marketplace.
    community:
      title: The Community
      text_1: The Community is the area for interaction between Horum users. Topics can be created in different categories and discussed with other users.
      text_2: Posts can be commented on and rated. Alongside the Marketplace, this creates a dedicated space for questions, ideas, experiences and discussions about Horum.
    connection:
      title: Website and Application
      text_1: The website and the Horum application serve different purposes, but they are part of the same platform. The website primarily handles account, license, Marketplace and Community features.
      text_2: The Windows application is Horum's actual working environment. Through the shared account and platform, both areas can be connected.
    summary:
      title: One central access point for Horum
      text: The Horum website brings together the platform's online features. From your account and license to the Marketplace and Community, this is where you can access everything that complements Horum outside the application itself.