"ogDescription":"Erwartungen an die Verantwortung für eingereichten Code, die Meldung von Sicherheitslücken und den Umfang von Pull Requests im ProxMenux-Projekt."
},
"errors":{
"notFound":"Fehler: Die Datei CODE_OF_CONDUCT.md wurde nicht gefunden.",
"loadFailed":"Fehler: Der Inhalt des Verhaltenskodex kann nicht geladen werden."
},
"contentMarkdown":"# 📝 Verhaltenskodex und bewährte Vorgehensweisen\n\nDieses Dokument legt die **Grundsätze und Richtlinien** für die Nutzung von **ProxMenux** fest. Es soll **Respekt, Zusammenarbeit und Sicherheit** bei der Entwicklung fördern.\n\n## 📌 1. Urheberangaben und Anerkennung\n\n- Werden **Skripte, Codeausschnitte oder Ideen** anderer Repositorys oder Entwickler verwendet, wird der ursprüngliche Urheber immer genannt.\n- Ein Kommentar im Code oder in der Dokumentation nennt die Quelle und verlinkt möglichst auf das ursprüngliche Repository.\n- Bei Code mit einer bestimmten **Lizenz** müssen deren Bedingungen eingehalten werden.\n\n### ✅ Beispiel für eine korrekte Quellenangabe im Code:\n\n```bash\n# Skript auf Grundlage der Arbeit von [Autor] unter [Repository-Link]\n```\n\n## 🔒 2. Sicherheit und Verantwortung für den Code\n\n- Der gesamte Code in diesem Repository folgt bewährten Vorgehensweisen für sichere Entwicklung.\n- Beiträge mit absichtlich eingebauten Schwachstellen oder unsicheren Vorgehensweisen sind nicht erlaubt.\n- Skripte dürfen niemals die Systemsicherheit oder Benutzerdaten gefährden.\n- Beiträge sollen vor der Implementierung auf Sicherheit und Stabilität geprüft werden.\n\n### ⚠️ Verantwortungsvolle Meldung von Sicherheitslücken\n\nEntdecken Sie eine Sicherheitslücke, melden Sie diese NICHT in öffentlichen Issues oder Foren.\n\nMelden Sie sie stattdessen vertraulich per E-Mail:\n\n📧 proxmenux@macrimi.pro\n\nWeitere Informationen zu Sicherheitslücken und deren Meldung finden Sie in unserer [Sicherheitsrichtlinie](./SECURITY.md).\n\n## 🤝 3. Regeln für die Community\n\nFür ein respektvolles und professionelles Umfeld müssen alle Benutzer diese Regeln beachten:\n\n- ✅ Bleiben Sie in Diskussionen respektvoll und konstruktiv.\n- ❌ Belästigung, Hassrede und beleidigendes Verhalten werden nicht toleriert.\n- ✅ Geben Sie Rückmeldungen sachlich und ohne persönliche Angriffe.\n- ❌ Verstöße können je nach Schwere zu Verwarnungen oder Ausschlüssen führen.\n\n##\n\nDieses Dokument fördert den ethischen Umgang mit Code, Sicherheitsbewusstsein und eine respektvolle Community.\n\n📢 Lassen Sie uns gemeinsam etwas Großartiges schaffen!\n"
"description":"Zu ProxMenux beitragen: Branch-Modell (main / develop / feature/*), Pull-Request-Ablauf, Skript-Header mit Autorenangabe und optionalem Sponsoring-Link, zweiphasige UI-Richtlinie, Nachrichtenfunktionen und der Weg vom Feature-Branch zur stabilen Version.",
"ogTitle":"Zu ProxMenux beitragen",
"ogDescription":"Branch-Modell, Arbeitsablauf, Autorenangabe im Skript-Header und zweiphasige UI-Richtlinie für Mitwirkende."
},
"header":{
"title":"Zu ProxMenux beitragen",
"description":"ProxMenux ist offen für Community-Beiträge - neue Skripte, Fixes für bestehende, Dialogverbesserungen, Übersetzungen, Integrationen. Diese Seite ist die formale Tür: wie das Repository strukturiert ist, das Verzweigungsmodell und der Pull-Request-Workflow, der Skript-Header mit Autorzuweisung und optionalem Sponsor-Link und die Design-Konventionen, denen jeder Beitrag folgen muss.",
"section":"Über"
},
"twoPagesCallout":{
"title":"Zwei verwandte Seiten, ein Projekt",
"body":"Verwechseln Sie diese Seite nicht mit <contributorsLink>Mitwirkende</contributorsLink>, die bisherige Beiträge von Testern, Reviewern und Entwicklern würdigt. Diese Seite richtet sich an <em>Sie</em> als künftigen Mitwirkenden und erklärt, wie Sie einen Pull Request zur Aufnahme vorbereiten."
},
"branching":{
"heading":"Verzweigungsmodell",
"intro":"ProxMenux verwendet ein dreistufiges Verzweigungsmodell:",
"headerBranch":"Branch",
"headerPurpose":"Zweck",
"rows":[
{
"branch":"main",
"purposeRich":"Stabiler, produktionsreifer Code. Hier werden nur veröffentlichungsreife Änderungen aufgenommen. Diese Version erhalten Endnutzer bei einer normalen ProxMenux-Installation."
},
{
"branch":"develop",
"purposeRich":"Aktiver Entwicklungsbranch. Neue Arbeiten werden zuerst hier aufgenommen; dies ist der Beta-Kanal. Ist eine stabile Version bereit, wird sie von hier nach <code>main</code> übernommen."
},
{
"branch":"feature/*",
"purposeRich":"Kurzlebige Branchs pro Feature, Fix oder Verbesserung. Erstellt aus <code>develop</code>, nach Überprüfung über einen Pull Request wieder in <code>develop</code> zusammengeführt."
}
],
"calloutTitle":"Was das für die Nutzer bedeutet",
"calloutBody":"Endbenutzer, die <code>main</code> verfolgen, erhalten getestete Releases. Benutzer, die die neuesten Funktionen frühzeitig wünschen - und gelegentliche raue Kanten nicht stören - können <code>develop</code> folgen. Neue Funktionen passieren immer zuerst <code>develop</code>; nichts erreicht <code>main</code>, ohne diesen Zyklus zu durchlaufen."
},
"workflow":{
"heading":"Pull Request Workflow",
"intro":"Von der Idee zum fusionierten Release in fünf Schritten:",
"step1Lead":"<strong>Erstellen Sie einen Feature Branch aus <code>develop</code></strong>:",
"step1Trail":"Verwenden Sie einen beschreibenden Zweignamen: <code>feature/zfs-arc-tuning</code>, <code>feature/fix-iommu-detection</code>, <code>feature/add-tailscale-script</code>.",
"step2Lead":"<strong>Arbeiten Sie an Ihren Änderungen und schieben Sie den Branch: </strong>",
"step2Code":"# Make your changes, then:\ngit add scripts/...\ngit commit -m \"Add ZFS ARC tuning script\"\ngit push -u origin feature/your-feature-name",
"step3":"<strong>Öffnen Sie einen Pull Request für <code>develop</code></strong>, nicht für <code>main</code>. Prüfen Sie auf GitHub, dass der Basisbranch auf <code>develop</code> steht. Beschreiben Sie, was das Skript tut und ändert und auf welchen Proxmox-VE-Versionen es getestet wurde.",
"step4":"<strong>Nach der Prüfung werden Änderungen in <code>develop</code> zusammengeführt.</strong> Ein Maintainer prüft Codequalität, Header-Konventionen und die zweiphasige UI-Richtlinie. Falls Änderungen nötig sind, pushen Sie weitere Commits in denselben Branch; der PR aktualisiert sich automatisch.",
"step5":"<strong>Stabile Versionen werden von <code>develop</code> nach <code>main</code> übernommen.</strong> Bei der Veröffentlichung wird <code>main</code> per Fast-Forward auf <code>develop</code> gebracht und mit einem Tag versehen. Ihr Beitrag wird Teil der nächsten stabilen Version."
},
"scriptHeader":{
"heading":"Skript-Header — Metadaten und Beschreibung",
"intro":"Jedes Skript in ProxMenux wird mit zwei benachbarten Kommentarblöcken geöffnet, die zusammen den Header bilden. Sie sind <strong>beide erforderlich</strong> - zusammen lassen sie jeden Leser wissen, wer das Skript geschrieben hat und was es tut, alles ohne den Code selbst zu öffnen.",
"bullets":[
"<strong>Oberer Block: Metadaten.</strong> Autor, optionale GitHub-/Sponsoring-Links, Maintainer, Copyright, Lizenz, Version und Aktualisierungsdatum. Hier erfolgt auch die <em>Würdigung der Mitwirkenden</em>: Bei einem neuen Skript tragen Sie Ihren Namen und optional Links zur persönlichen GitHub-Seite und einem Unterstützungsprofil ein, etwa Ko-fi, GitHub Sponsors oder Buy Me a Coffee.",
"<strong>Unterer Block: Beschreibung.</strong> Ein kurzer Absatz in einfachem Englisch erklärt die Funktion. Nutzer lesen ihn <em>vor</em> dem Code. Er muss für sich allein Zweck, Hauptaktionen, betroffene Ressourcen und Voraussetzungen verständlich machen."
],
"licenseCalloutTitle":"Die Lizenzlinie ist festgelegt — GPL-3.0",
"licenseCalloutBody":"ProxMenux wird unter der <strong>GNU General Public License v3.0</strong> veröffentlicht. Jedes Skript im Projekt wird unter derselben Lizenz ausgeliefert; die <code>License</code>-Zeile im Header ist immer die GPL-3.0-Referenz, die im folgenden Beispiel gezeigt wird - es ist keine Per-Script-Wahl. Indem Sie ein Skript beisteuern, erklären Sie sich damit einverstanden, es unter GPL-3.0 zu veröffentlichen, was bedeutet, dass jeder es lesen, ändern und weiterverteilen kann (einschließlich Änderungen), solange er es unter der gleichen Lizenz behält. Der vollständige Text befindet sich unter <licenseLink>MacRimi/ProxMenux/LICENSE</licenseLink>.",
"templateCode":"#!/bin/bash\n\n# ==========================================================\n# ProxMenux - A menu-driven script for Proxmox VE management\n# ==========================================================\n# Author : Your Name\n# GitHub : github.com/yourhandle\n# Sponsor : ko-fi.com/yourhandle\n# Maintainer : MacRimi\n# Copyright : (c) 2026 MacRimi & contributors\n# License : (GPL-3.0) (https://github.com/MacRimi/ProxMenux/blob/main/LICENSE)\n# Version : 1.0\n# Last Updated: DD/MM/YYYY\n# ==========================================================\n# Description:\n# Short paragraph explaining what the script does.\n# Mention the main actions (e.g. \"creates a ZFS pool\",\n# \"configures IOMMU and reboots\", \"imports an ISO into a VM\"),\n# the resources it touches, and any prerequisites the user\n# should be aware of before running it.\n# ==========================================================",
"optionalNote":"Die Linien <code>GitHub</code> und <code>Sponsor</code> sind optional - lassen Sie sie aus, wenn Sie sie nicht veröffentlichen möchten. Alles andere ist erforderlich.",
"whyCalloutTitle":"Warum das wichtig ist",
"whyCalloutBody":"Open-Source-Beiträge sind freiwillige Arbeit. Name und optionaler Sponsoring-Link im Quellcode machen die Urheberschaft bei jedem Lesen sichtbar, statt sie hinter dem Projektnamen zu verbergen. Der Beschreibungsblock ist aus einem anderen Grund wichtig: Er ist der erste Anlaufpunkt künftiger Maintainer und neugieriger Nutzer. Eine klare Erklärung entscheidet oft darüber, ob sie einem Skript vertrauen oder es meiden."
},
"structure":{
"heading":"Projektstruktur",
"intro":"Wo jede Art von Skript im Repository lebt:",
"treeCode":"scripts/\n├── menus/ # Top-level menu scripts (entry points)\n├── storage/ # Disk, storage and passthrough scripts\n├── share/ # NFS, Samba, local share scripts\n├── vm/ # VM creation and configuration scripts\n├── gpu_tpu/ # GPU / TPU passthrough scripts\n├── post_install/ # Post-install automation scripts\n├── backup_restore/ # Backup and restore scripts\n├── utilities/ # System utility scripts\n├── global/ # Shared helper libraries (sourced by other scripts)\n├── utils.sh # Shared utility functions and message helpers\n└── help_info_menu.sh # Interactive help and command reference",
"outro":"Jedes Skript lädt <code>utils.sh</code> beim Start per source, um Nachrichtenfunktionen, Spinner, Farbvariablen und Übersetzungssystem einzubinden. Gemeinsame Hilfsbibliotheken in <code>scripts/global/</code> werden ausdrücklich von den Skripten geladen, die sie benötigen."
},
"twoPhase":{
"heading":"Die zweiphasige UI Design Policy",
"intro":"Dies ist die wichtigste Konvention in ProxMenux und die PRs werden am häufigsten gebeten, sie zu beheben. Jedes Skript ist in <strong> genau zwei Phasen</strong> unterteilt:",
"headerPhase":"Phase",
"headerPurpose":"Zweck",
"headerScreen":"Bildschirmzustand",
"rows":[
{
"phaseRich":"<strong>Phase 1 — Auswahl</strong>",
"purposeRich":"Sammeln Sie jede Benutzerentscheidung. Führen Sie alle erforderlichen Vorbereitungsarbeiten durch (Sonden, Scans, Überprüfungen).",
"screenRich":"<code>dialog</code>-Overlays. Wenn eine Suche zwischen zwei Menüs länger als ein oder zwei Sekunden dauert, zeigen Sie einen <code>msg_info</code>-Spinner an, damit der Benutzer weiß, dass das Skript nicht eingefroren ist, und rufen Sie dann <code>stop_spinner</code> direkt vor dem nächsten Dialog auf."
"principle":"Das Prinzip: <strong>Sammeln Sie zuerst alles und führen Sie dann alles</strong> aus. Der Benutzer sieht ein sauberes dialoggesteuertes Menü (Phase 1), dann eine saubere Ausführungsansicht im Protokollstil (Phase 2). Kein Mischen — kein Dialog erscheint mitten in der Ausführung, kein Fortschrittsrauschen während der Auswahl.",
"phase1Heading":"Phase 1 — typisches Muster",
"phase1Code":"# Silent preparatory work between dialogs\nmsg_info \"$(translate \"Checking disk assignments...\")\"\nASSIGNED_TO=$(check_assignments \"$DISK\")\nstop_spinner # ← clears line silently, result saved in variable\n\n# Next dialog can now use ASSIGNED_TO\nif [ -n \"$ASSIGNED_TO\" ]; then\n dialog --yesno \"$(translate \"Disk already assigned. Continue?\")\" $UI_YESNO_H $UI_YESNO_W\nfi\n\n# Collect multiple decisions per item with parallel arrays\ndeclare -a DISK_LIST=()\ndeclare -a DISK_FORMAT_TYPES=()\ndeclare -a DISK_MOUNT_POINTS=()\nfor DISK in $SELECTED; do\n msg_info \"$(translate \"Analyzing disk...\")\"\n CURRENT_FS=$(lsblk -no FSTYPE \"$DISK\" | xargs)\n stop_spinner\n\n FORMAT=$(dialog --backtitle \"$BACKTITLE\" \\\n --title \"$(translate \"Select Filesystem\")\" \\\n --menu \"...\" $UI_SHORT_MENU_H $UI_SHORT_MENU_W $UI_SHORT_MENU_LIST_H \\\n \"ext4\" \"...\" \"xfs\" \"...\" \"btrfs\" \"...\" \\\n 2>&1 >/dev/tty)\n [ -z \"$FORMAT\" ] && continue\n\n DISK_LIST+=(\"$DISK\")\n DISK_FORMAT_TYPES+=(\"$FORMAT\")\ndone",
"phase1RulesIntro":"<strong>Regeln für Phase 1:</strong>",
"phase1Rules":[
"Läuft gerade ein <code>msg_info</code>-Spinner und soll ein Menü mit <code>dialog</code> oder <code>whiptail</code> geöffnet werden, rufen Sie zuerst <code>stop_spinner</code> auf. Der Spinner verträgt sich nicht mit deren Bildschirmüberlagerung. Ohne aktiven Spinner ist der Aufruf nicht nötig.",
"Verwenden Sie <code>show_proxmenux_logo</code> + <code>msg_title</code> + <code>msg_info</code>, um in Phase 1 einen längeren Vorgang sichtbar einzuordnen, etwa eine Prüfung ab fünf Sekunden. Die Funktion leert bereits den Bildschirm; rufen Sie davor nicht <code>clear</code> auf.",
"Rufen Sie <code>show_proxmenux_logo</code> nicht zwischen Dialogmenüs auf, in denen nichts angezeigt werden kann - das Löschen des Bildschirms für ein leeres Terminal ist nur visuelles Rauschen.",
"Speichern Sie alle Entscheidungen und Sondenergebnisse in Variablen oder parallelen Arrays. Die sichtbare Zusammenfassung erfolgt zu Beginn der Phase 2, nicht in Phase 1."
],
"phase2Heading":"Phase 2 — typisches Muster",
"phase2Code":"# ── PHASE 2 — EXECUTION ─────────────────────────────\nshow_proxmenux_logo\nmsg_title \"$(translate \"My Script Title\")\"\n\n# Recap Phase 1 preparatory results — show what was already done\nmsg_ok \"$(translate \"CT $CTID selected.\")\"\nmsg_ok \"$(translate \"Repositories verified.\")\"\nmsg_ok \"$(translate \"Disks to process: ${#DISK_LIST[@]}\")\"\n\n# Now execute operations\nfor i in \"${!DISK_LIST[@]}\"; do\n DISK=\"${DISK_LIST[$i]}\"\n FORMAT=\"${DISK_FORMAT_TYPES[$i]}\"\n\n msg_info \"$(translate \"Formatting\") $DISK $(translate \"as\") $FORMAT...\"\n mkfs.\"$FORMAT\" \"$DISK\" >/dev/null 2>&1\n msg_ok \"$(translate \"Formatted.\")\"\ndone\n\nmsg_ok \"$(translate \"Completed. ${#DISK_LIST[@]} disk(s) processed.\")\"\nmsg_success \"$(translate \"Press Enter to return to menu...\")\"\nread -r",
"phase2Rules":"<strong>Regeln für Phase 2:</strong> Beginnen Sie mit <code>show_proxmenux_logo + msg_title</code> und fassen Sie Phase 1 sofort in <code>msg_ok</code>-Zeilen zusammen. Rufen Sie <code>show_proxmenux_logo</code> nicht erneut auf, da dies den bisherigen Verlauf löscht. Verwenden Sie kein <code>dialog</code>; ist eine Entscheidung zur Laufzeit unvermeidbar, nutzen Sie <code>whiptail</code> wie im nächsten Abschnitt."
},
"dialogVsWhiptail":{
"headingRich":"Wann <code>dialog</code> vs <code>whiptail</code> zu verwenden",
"intro":"Beide Tools zeichnen Benutzeroberflächen im Textmodus, aber sie verhalten sich auf dem Bildschirm sehr unterschiedlich - und ProxMenux verwendet sie aus einem bestimmten Grund in zwei verschiedenen Phasen.",
"whenRich":"<strong>Immer in Phase 1.</strong> Jede interaktive Auswahl – Auswahl einer VM, einer Festplatte, eines Dateisystems, das eine Aktion bestätigt – verwendet <code>dialog</code>. Dies ist das Standard-UI-Tool von ProxMenux.",
"effectRich":"Übernimmt das Terminal: löscht den Bildschirm, zieht sein Overlay und bringt das Terminal beim Schließen in seinen vorherigen Zustand zurück. Fein in Phase 1, weil sich noch nichts Nützliches zeigt."
"whenRich":"<strong>Nur in Phase 2, nur wenn unvermeidlich.</strong> Der typische Fall ist eine Neustartaufforderung am Ende der Ausführung. Greifen Sie nicht zu <code>whiptail</code>, um \"Weiter?\" mitten in der Ausführung zu fragen - diese Entscheidung hätte in Phase 1 getroffen werden sollen.",
"effectRich":"Leichteres Overlay, das den Terminalkontext <em>nicht</em> löscht. Der akkumulierte <code>msg_ok</code> / <code>msg_info</code>-Verlauf der Phase 2 bleibt hinter dem Dialogfeld sichtbar. Deshalb ist es die richtige Wahl, wenn der Fortschritt bereits auf dem Bildschirm zu sehen ist."
}
],
"calloutTitle":"Warum die Trennung wichtig ist",
"calloutBody":"Wenn Sie <code>dialog</code> in der Mitte der Phase 2 anrufen, verschwindet jede <code>msg_ok</code>-Zeile, die der Benutzer beobachtet hat. Sie wischen den Audit-Trail. <code>whiptail</code> vermeidet das. Die Regel ist also nicht willkürlich - es geht darum, die Sicht des Benutzers auf das, was das Skript bisher getan hat, zu bewahren.",
"rebootHeading":"Neustartabfrage: das typische whiptail in Phase 2",
"rebootIntro":"Wenn ein Skript endet und ein Neustart erforderlich ist (z.B.) IOMMU aktiviert, Kernelparameter geändert), die Aufforderung am Ende der Phase 2 verwendet <code>whiptail</code>. Fügen Sie immer einen \"Nein\"-Zweig hinzu, der den Benutzer warnt, die betroffene Ressource nicht zu verwenden, bis er neu startet:",
"rebootCode":"if [[ \"$HOST_REBOOT_REQUIRED\" == \"yes\" ]]; then\n echo \"\"\n if whiptail --title \"$(translate \"Reboot Required\")\" --yesno \\\n \"\\n$(translate \"A host reboot is required before starting the VM. Reboot now?\")\" \\\n 13 78; then\n msg_warn \"$(translate \"Rebooting the system...\")\"\n reboot\n else\n echo \"\"\n msg_info2 \"$(translate \"Do not start the VM until the system has been rebooted.\")\"\n fi\nfi\n\nmsg_success \"$(translate \"Press Enter to return to menu...\")\"\nread -r"
},
"messageFunctions":{
"heading":"Referenz der Nachrichtenfunktionen",
"intro":"Alle definiert in <code>utils.sh</code>. Verwenden Sie sie als Standard für jede benutzersichtliche Ausgabe - konsistente Visuals über Skripte hinweg ist der springende Punkt. Wenn Ihr Skript eine neue Funktion benötigt, die nicht zum vorhandenen Set passt (ein neuer Schweregrad, ein neuer Layout-Helfer usw.), schlagen Sie es in Ihrem Pull Request vor - es wird überprüft und zu <code>utils.sh</code> hinzugefügt, wenn es allgemein nützlich ist.",
"headerFunction":"Funktion",
"headerWhen":"Wann zu verwenden",
"headerSpinner":"Fortschrittsanzeige",
"rows":[
{
"function":"msg_info \"text\"",
"whenRich":"Operation in Arbeit.",
"spinner":"Startet"
},
{
"function":"stop_spinner",
"whenRich":"Ende der stillen Vorbereitungsarbeiten in Phase 1 — tötet Spinner, löscht die Linie.",
"spinner":"Stoppt"
},
{
"function":"msg_ok \"text\"",
"whenRich":"Vorgang erfolgreich. Auch für „Funktion aktiviert“ verwenden, wenn noch ein Neustart erforderlich ist.",
"spinner":"Stoppt"
},
{
"function":"msg_warn \"text\"",
"whenRich":"Tatsächliche Warnung oder gestörter Zustand.",
"whenRich":"Abschließende Aufforderung „Enter zum Zurückkehren“ am Ende von Phase 2.",
"spinner":"Stoppt"
},
{
"function":"msg_title \"text\"",
"whenRich":"Fetter Titel mit eingebautem Abstand. Wird zu Beginn der Phase 2 verwendet.",
"spinner":"—"
},
{
"function":"show_proxmenux_logo",
"whenRich":"Leert den Bildschirm und zeigt das Logo. Zu Beginn von Phase 2 <em>einmal</em> aufrufen.",
"spinner":"—"
}
]
},
"dialogConventions":{
"heading":"Dialogkonventionen",
"bullets":[
"Geben Sie <code>--backtitle \"$BACKTITLE\"</code> immer an jeden <code>dialog</code>- und <code>whiptail</code>-Aufruf weiter. <code>$BACKTITLE</code> ist immer <code>\"ProxMenux\"</code> - einmal im Skript-Header gesetzt und nie außer Kraft gesetzt. Der Benutzer muss den Projektnamen immer als Framing-Kontext sehen, niemals den eigenen Titel des Skripts.",
"Verpacken Sie Titel und Nachrichten immer mit <code>$(translate \"...\")</code>.",
"Immer <code>dialog</code> Ausgabe mit <code>2>&1 >/dev/tty</code> umleiten — die erfasste stdout wird die Auswahl des Benutzers, während der Dialog selbst auf das Terminal zieht.",
"Verwenden Sie die Standard-UI-Dimensionsvariablen (<code>$UI_MENU_H</code>, <code>$UI_MSG_W</code>, usw.) für eine konsistente Dimensionierung über Skripte hinweg.",
"Prüfen Sie immer auf leere oder abgebrochene Auswahlen und behandeln Sie diese sauber."
],
"exampleIntro":"Vollständiges Beispiel — Erstellung eines VM-Auswahlmenüs und Bearbeitung der Stornierung:",
"exampleCode":"# 1) Build the list of VMs as alternating \"ID NAME\" pairs.\n# dialog --menu expects this exact shape: tag1 description1 tag2 description2 ...\nVM_LIST=\"\"\nfor vmid in $(qm list | awk 'NR>1 {print $1}'); do\n vm_name=$(qm config \"$vmid\" | awk -F': ' '/^name:/ {print $2}')\n VM_LIST=\"$VM_LIST $vmid \\\"$vm_name\\\"\"\ndone\n\n# 2) Show the dialog. Captured stdout is the user's selection (the VMID).\nVMID=$(eval \"dialog --backtitle \\\"\\$BACKTITLE\\\" \\\n --title \\\"\\$(translate \\\"Select VM\\\")\\\" \\\n --menu \\\"\\$(translate \\\"Choose a VM from the list:\\\")\\\" \\\n \\$UI_MENU_H \\$UI_MENU_W \\$UI_MENU_LIST_H \\\n $VM_LIST \\\n 2>&1 >/dev/tty\")\n\n# 3) Empty result means the user pressed Cancel or Esc — exit silently.\nif [ -z \"$VMID\" ]; then\n exit 0\nfi\n\n# 4) Continue with the rest of Phase 1, knowing VMID is now set.\necho \"User selected VMID=$VMID\""
},
"translation":{
"heading":"Übersetzungspolitik",
"intro":"Alle vom Benutzer sichtbaren Zeichenfolgen müssen mit der <code>translate</code>-Funktion gewickelt sein. ProxMenux übersetzt sie automatisch in alle unterstützten Sprachen - Sie schreiben Englisch, der Benutzer liest seine Muttersprache.",
"Schreibe Strings in Englisch – die Übersetzung wird automatisch vom Build bearbeitet.",
"Halten Sie Strings kurz. Vermeiden Sie das Einbetten von Variablen in lange Sätze, wenn möglich.",
"Variablennamen, Pfade oder technische Bezeichner <strong>nicht</strong>übersetzen."
]
},
"variableStyle":{
"heading":"Variable und Stilkonventionen",
"bullets":[
"Verwenden Sie <code>UPPER_CASE</code> für Variablen auf Skriptebene.",
"Verwenden Sie <code>lower_case</code> für lokale Funktionsvariablen (mit <code>local</code> deklarieren).",
"Setzen Sie alle Variablenexpansionen in Anführungszeichen: <code>\"$VAR\"</code> statt <code>$VAR</code>.",
"Verwenden Sie <code>[[ ]]</code> für Konditionale, nicht <code>[ ]</code> (außer wenn POSIX erforderlich ist).",
"<code>show_proxmenux_logo</code> ist der geeignete Weg, um den Bildschirm zu löschen - er enthält das Clear und zeigt das Projektlogo, so dass der Benutzer immer einen visuellen Kontext hat. Rufen Sie es einmal zu Beginn der Phase 2 (und optional vor einem langen Phase 1-Spinnerblock) auf."
],
"standardNamesIntro":"Standardvariablennamen im gesamten Projekt:",
"redirectHeading":"Umleitung der Werkzeugausgabe während der Phase 2",
"redirectIntro":"Phase 2 zeigt ein sauberes Protokoll der <code>msg_info → msg_ok</code>-Zeilen an, die sich auf dem Bildschirm ansammeln. Wenn ein Tool, das Sie aufrufen (apt, mkfs, qm, pct, dd, etc.), seine eigene Ausgabe in stdout/stderr schreibt, scrollt es an Ihren Nachrichten vorbei und unterbricht den visuellen Fluss - Sie haben ein chaotisches Terminal, in dem der Benutzer die eigenen Fortschrittslinien des Skripts nicht vom Rauschen des zugrunde liegenden Tools unterscheiden kann.",
"withoutRedirectIntro":"<strong>Ohne Umleitung</strong>: die Ausgabe für Nutzer, wenn zusätzliche Werkzeugausgaben nicht abgefangen werden.",
"withoutRedirectCode":"ℹ Installing kernel package...\nReading package lists... Done\nBuilding dependency tree... Done\nReading state information... Done\nThe following NEW packages will be installed:\n proxmox-kernel-6.5\n0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.\nNeed to get 12.5 MB of archives.\nAfter this operation, 47.2 MB of additional disk space will be used.\nGet:1 http://download.proxmox.com/debian/pve trixie/pve-no-subscription amd64 ...\n... [200+ more lines of dpkg output] ...\n✓ Kernel installed.",
"withRedirectIntro":"<strong>Mit Umleitung</strong>: dieselbe Aktion, wenn zusätzliche Ausgaben an anderer Stelle landen.",
"logLead":"<strong>Ausgabe in eine Protokolldatei schreiben</strong>, wenn Sie sie später prüfen möchten, etwa zur Fehlersuche bei einer Installation oder um dpkg-Aktionen nachzuvollziehen. Dies ist das bevorzugte Muster für apt-Aufrufe:",
"referenceOutro":"<code>scripts/global/update-pve9_2.sh</code> dient als Referenz: Jeder <code>apt-get</code>-Aufruf schreibt in eine Protokolldatei. Nutzer sehen nur den Ablauf <code>msg_info → msg_ok</code>, während die Datei bei Fehlern genau zeigt, was apt getan hat."
},
"dosAndDonts":{
"heading":"Do's und Don'ts",
"doHeading":"✅ Empfohlen",
"doBullets":[
"<code>stop_spinner</code> vor einem <code>dialog</code> in Phase 1 nur dann, wenn ein <code>msg_info</code> Spinner gerade läuft.",
"Phase 2 beginnt mit <code>show_proxmenux_logo + msg_title + msg_ok</code> als Zusammenfassung der Ergebnisse von Phase 1.",
"Verwenden Sie <code>msg_ok</code> für erfolgreich aktivierte Funktionen – auch wenn ein Neustart erforderlich ist.",
"Verwenden Sie <code>whiptail</code> (nicht <code>dialog</code>) für jede Aufforderung nach der Ausführung, die in Phase 2 erscheinen muss.",
"Fügen Sie immer einen \"Nein\" -Zweig in Reboot-Dialoge ein, der den Benutzer warnt, die betroffene Ressource bis zum Neustart nicht zu starten.",
"Schützen Sie die reine VM-Logik, indem Sie <code>[[ -f \"/etc/pve/qemu-server/$'{'vmid'}'.conf\" ]]</code> überprüfen - Controller und NVMe PCIe können nicht zu LXC-Containern hinzugefügt werden.",
"Verwenden Sie <code>ensure_repositories</code> von <code>utils-install-functions.sh</code> anstelle von bedingungslosem <code>apt-get update</code>.",
"Verwenden Sie parallele Arrays in Phase 1, wenn jedes Element mehrere Dialoge benötigt."
],
"dontHeading":"❌ Vermeiden",
"dontBullets":[
"Rufen Sie <code>dialog</code> an, während ein Spinner aktiv ist.",
"Überspringen Sie die Phase 1 Zusammenfassung zu Beginn der Phase 2.",
"Rufen Sie <code>show_proxmenux_logo</code> ein zweites Mal an - es löscht alles, was Phase 2 gedruckt hat.",
"Verwenden Sie <code>dialog</code> in Phase 2 (verwenden Sie <code>whiptail</code> für den seltenen unvermeidlichen Fall).",
"Verwenden Sie reine <code>clear</code>.",
"<code>msg_title</code> mit Leerzeilen aus <code>echo \"\"</code> umgeben; die Abstände sind bereits enthalten.",
"Verwenden Sie <code>msg_warn</code>, um eine erfolgreich aktivierte Funktion zu melden - das ist ein <code>msg_ok</code>.",
"Führen Sie bedingungslos <code>apt-get update</code> aus - verwenden Sie <code>ensure_repositories</code>."
]
},
"submitting":{
"heading":"Einreichen Ihres Beitrags",
"steps":[
"Fork <code>MacRimi/ProxMenux</code> auf GitHub und klonen Sie Ihre Fork.",
"Erstellen Sie einen <code>feature/*</code>-Zweig aus <code>develop</code> (siehe <em>Branching-Modell</em> oben).",
"Befolgen Sie diese Anleitung für neue oder geänderte Skripte. Schreiben Sie den Header mit Ihrem Namen; fügen Sie die optionale Sponsorenzeile hinzu, wenn Sie möchten.",
"Testen Sie Ihr Skript auf einer echten Proxmox VE-Instanz - sowohl Phase 1 (jeder Dialogzweig) als auch Phase 2 (jede Operation ist erfolgreich und wird bei Fehlern sauber zurückgesetzt).",
"Öffnen Sie eine Pull Request <strong> gegen <code>develop</code></strong> mit einer klaren Beschreibung: was das Skript macht, was sich geändert hat, auf welcher Proxmox VE-Version es getestet wurde.",
"Stellen Sie sicher, dass Ihr Beitrag den <cocLink>Code of Conduct</cocLink> respektiert."
],
"securityOutro":"Befolgen Sie bei sicherheitsrelevanten Problemen den Offenlegungsfluss in <securityLink>SECURITY.md</securityLink>, anstatt ein öffentliches Problem zu öffnen."
"ogDescription":"Treffen Sie die Mitwirkenden hinter ProxMenux."
},
"header":{
"title":"Mitwirkende",
"description":"Das ProxMenux-Projekt wächst dank seiner Mitwirkenden. Diese Seite würdigt ihre Arbeit: Versionen vor der Veröffentlichung testen, Regressionen erkennen, PRs prüfen und die Entwicklung neuer Funktionen mitgestalten.",
"section":"Über"
},
"beyond":{
"title":"Weitere Mitwirkende",
"body":"Viele weitere Menschen helfen mit Fehlermeldungen, Funktionsideen in Discussions, Beta-Tests und Übersetzungen. Die vollständige Liste der Code-Mitwirkenden steht im <extlink>GitHub-Mitwirkendendiagramm</extlink>. Diese Seite hebt diejenigen hervor, die besonders aktiv ProxMenux-Versionen testen und prüfen."
},
"testers":{
"heading":"Tester & Reviewer",
"intro":"Diese Personen gehörten zu den ersten Mitwirkenden. Mit Tests, Fehlermeldungen und Verbesserungsvorschlägen halfen sie ProxMenux dabei, zu dem zu werden, was es heute ist.",
"roles":{
"testing":"Testen",
"testingReviewer":"Tests und Review"
},
"youtube":"YouTube"
},
"contribute":{
"heading":"Möchten Sie dazu beitragen?",
"intro":"Jeder Beitrag ist willkommen - Code, Testen, Design, Dokumentation oder einfach nur das Teilen Ihrer Ideen:",
"tester":"<strong>Tester</strong> — probieren Sie den <beta>Beta-Kanal</beta> aus und melden Sie vor der stabilen Veröffentlichung, was funktioniert und was nicht.",
"developer":"<strong>Entwickler</strong> — Bash, Next.js (TypeScript) und etwas Python für die virtuelle Übersetzungsumgebung (venv). PRs auf <gh>GitHub</gh> sind willkommen.",
"designer":"<strong>Designer</strong> — Verbesserungen der Benutzeroberfläche, Icons, Screenshots zur Dokumentation.",
"ideas":"<strong>Ideen</strong> — eröffnen Sie zuerst ein Thema in <disc>GitHub Discussions</disc>, bevor Sie einen Funktionswunsch als Issue einreichen."
},
"coc":{
"title":"Lesen Sie zuerst den Verhaltenskodex",
"body":"Lesen Sie vor dem Einreichen von Code oder Fehlermeldungen kurz den <coclink>Verhaltenskodex und die bewährten Vorgehensweisen</coclink>. Darin werden die Verantwortung für Code, die Meldung von Sicherheitslücken und der Umfang von PRs erläutert."
"ogDescription":"Häufige Fragen zu Installation, Kompatibilität, Sicherheit und Beiträgen zu ProxMenux."
},
"header":{
"title":"Häufig gestellte Fragen",
"description":"Häufige Fragen zu ProxMenux: Funktionsumfang, Zielgruppe, Installation, Updates, Deinstallation, Kompatibilität, Anpassung, Sicherheit und Beiträge. Fehlt Ihre Frage, sehen Sie in GitHub Discussions nach oder erstellen Sie ein Issue.",
"section":"Über"
},
"quickLinks":{
"title":"Schnelle Links",
"installationLabel":"Installation",
"installationSuffix":"— der One-Line-Installationsbefehl + Abhängigkeiten.",
"introductionLabel":"Einleitung",
"introductionSuffix":"— was ProxMenux tut, in 5 Minuten.",
"uninstallLabel":"Deinstallieren",
"uninstallSuffix":"— sauberes Entfernen.",
"issuesLabel":"GitHub Issues",
"discussionsLabel":"Diskussionen"
},
"q1":{
"question":"Was ist ProxMenux und wofür wird es verwendet?",
"p1Rich":"<strong>ProxMenux</strong> ist ein interaktives menügesteuertes Tool, das <strong>Proxmox VE</strong> für alle Benutzer unabhängig von ihrer technischen Erfahrung zugänglich macht. Es vereinfacht die Befehlsausführung und ermöglicht es Benutzern, Aktionen auf ihrem System durchzuführen, ohne dass fortgeschrittene Linux-Kenntnisse erforderlich sind.",
"p2":"Weniger erfahrene Benutzer können Befehle über übersichtliche Menüs ausführen und müssen seltener selbst im Terminal tippen. Erfahrenen Administratoren erspart ProxMenux Eingaben bei wiederkehrenden Aufgaben wie der Absicherung nach der Installation, GPU-Passthrough, OVF-VM-Importen und der Rotation von ZFS-Snapshots.",
"p3":"Proxmox VE ist weit verbreitet für:",
"items":[
"Virtualisierung auf Unternehmensebene",
"HomeLab und persönliche Cloud-Lösungen",
"Multimedia-Server, Automatisierung und mehr"
]
},
"q2":{
"question":"Wie installiere ich ProxMenux?",
"p1Rich":"Folgen Sie der <installlink>Installationsanleitung</installlink>. Kurz zusammengefasst:",
"p2":"Einmal installiert, starten Sie es einfach mit:",
"menuCmd":"menu"
},
"q3":{
"question":"Ist ProxMenux mit allen Proxmox-Versionen kompatibel?",
"bodyRich":"<strong>Nein — ProxMenux benötigt Proxmox VE 8 oder neuer.</strong> PVE 7 und ältere Versionen werden nicht unterstützt. Aktualisieren Sie PVE 7 zunächst nach der offiziellen Proxmox-Anleitung auf 8.x. Den anschließenden Wechsel von 8 auf 9 können Sie über <upgradelink>Werkzeuge → PVE 8 auf PVE 9 aktualisieren</upgradelink> in ProxMenux durchführen."
},
"q4":{
"question":"Kann ich ProxMenux anpassen?",
"p1Rich":"Lokale Änderungen an den Hauptskripten können beim Aktualisieren überschrieben werden. Bearbeiten Sie diese Dateien daher möglichst nicht direkt. Folgendes <em>können</em> Sie anpassen:",
"items":[
"Das Konsolenbanner über das <strong>FastFetch</strong> Tool in den Post-Install-Optionen.",
"Welche optionalen Komponenten installiert werden (Monitor, Fail2Ban, Lynis...) – wählen Sie während der Installation oder später über das entsprechende Menü aus."
]
},
"q5":{
"question":"Wie aktualisiere ich ProxMenux?",
"p1Rich":"Wenn eine neue Version verfügbar ist, erkennt ProxMenux sie beim nächsten Aufruf von <code>menu</code> und bietet ein Update an. Stimmen Sie zu, werden die Dateien und die Konfiguration des Werkzeugs in der bestehenden Installation ersetzt. Ein manueller Download ist nicht nötig.",
"p2Rich":"Benutzer der stabilen Version erhalten stabile Updates, Beta-Benutzer die Beta-Updates. Sobald eine stabile Version erscheint, informiert die Beta beim nächsten Menüstart darüber und bietet den automatischen Wechsel an. Weitere Informationen finden Sie im <betalink>Beta-Programm</betalink>."
},
"q6":{
"question":"Wo kann ich Probleme melden?",
"p1Rich":"Melden Sie Fehler über <issueslink>GitHub Issues</issueslink>. Beschreiben Sie die Schritte zum Reproduzieren, den Fehlertext und gegebenenfalls die Monitor-Ausgabe von <code>journalctl -u proxmenux-monitor -n 50</code>.",
"p2Rich":"Bei <strong>Sicherheitsproblemen</strong>: <strong>Veröffentlichen Sie keine Details</strong>. Folgen Sie dem Verfahren zur verantwortungsvollen Meldung im <coclink>Verhaltenskodex und den bewährten Vorgehensweisen</coclink>."
},
"q7":{
"question":"Kann ich zu ProxMenux beitragen?",
"p1Rich":"<strong>Unbedingt.</strong> ProxMenux ist ein gemeinschaftliches Open-Source-Projekt. Beiträge sind als Code (Bash, Next.js/TypeScript und Python-Übersetzungswerkzeuge), Tests, Dokumentation, Design oder Ideen willkommen.",
"item1Rich":"Besprechen Sie Ideen in <discusslink>GitHub Discussions</discusslink>, bevor Sie eine Feature Request öffnen.",
"item2Rich":"Lesen Sie vor einem Pull Request den <coclink>Verhaltenskodex und die bewährten Vorgehensweisen</coclink>.",
"item3Rich":"Auf der <contriblink>Mitwirkendenseite</contriblink> finden Sie die aktuellen Tester und Reviewer."
"p1Rich":"<strong>Bei der Installation von ProxMenux werden folgende Komponenten hinzugefügt.</strong>",
"item1Rich":"Abhängigkeiten über apt: <code>dialog</code>, <code>curl</code>, <code>jq</code> und <code>git</code>. Die Übersetzungen verwenden vorgefertigte JSON-Kataloge. Der Installer legt auf dem Host keine virtuelle Python-Umgebung für Übersetzungen an.",
"item2Rich":"Der Skriptbaum bei <code>/usr/local/share/proxmenux/</code>.",
"item3Rich":"Das Startskript unter <code>/usr/local/bin/menu</code>.",
"item4Rich":"Optional: der systemd-Dienst von Monitor unter <code>proxmenux-monitor.service</code>.",
"p2Rich":"ProxMenux verändert die zentrale Proxmox-Konfiguration <em>nicht</em>, es sei denn, Sie fordern dies ausdrücklich über ein entsprechendes Menü an. Die Netzwerkreparatur bearbeitet beispielsweise <code>/etc/network/interfaces</code>, jedoch erst nach Ihrer Bestätigung und dem Anlegen einer Sicherung."
},
"q9":{
"question":"Ist es sicher, ProxMenux in der Produktion zu verwenden?",
"bodyRich":"<strong>Ja.</strong> Da ProxMenux die zentralen Proxmox-Dateien nur auf ausdrücklichen Wunsch verändert, kann es in Produktionsumgebungen eingesetzt werden. Testen Sie automatisierte Abläufe zunächst in einer kontrollierten Umgebung und erstellen Sie Sicherungen, bevor Sie destruktive Vorgänge ausführen, etwa das Upgrade von PVE 8 auf 9, das Formatieren eines Datenträgers oder das Löschen einer VM."
},
"q10":{
"question":"Wie deinstalliere ich ProxMenux?",
"p1Rich":"In ProxMenux: <strong>Einstellungen → ProxMenux deinstallieren</strong>. Die Deinstallation entfernt den Skriptbaum, das Startskript und den Monitor-Dienst sowie auf Wunsch ausgewählte Abhängigkeiten. <code>/root/.bashrc</code> und <code>/etc/motd</code> werden aus den bei der Installation angelegten Sicherungen wiederhergestellt, sofern diese vorhanden sind.",
"p2Rich":"Die vollständige Anleitung finden Sie unter <uninstalllink>ProxMenux deinstallieren</uninstalllink>."
},
"q11":{
"question":"VirusTotal markiert die Installations-URL - ist es sicher?",
"p1Rich":"Der in Issue #162 gemeldete Treffer von <em>Chong Lua Dao</em> bei 1 von 95 Prüfungen wurde vom Maintainer als Fehlalarm eingestuft. Der Installer verwendet das Muster <code>curl | bash</code> und kann <code>jq</code> aus dessen offizieller GitHub-Veröffentlichung herunterladen. Dieses <em>Verhalten</em> kann heuristische Scanner auslösen. Der damalige Bericht ist keine Bewertung aller künftigen Downloads.",
"p2Rich":"ProxMenux ist vollständig quelloffen. Sie können das Installationsskript Zeile für Zeile prüfen: <scriptlink>install_proxmenux.sh</scriptlink>. Weitere Hintergründe finden Sie in <issuelink>Issue #162</issuelink>."
"title":"Über das Projekt | ProxMenux-Dokumentation",
"description":"Über ProxMenux: Projektziele, Mitwirkende, FAQ und Verhaltenskodex. Open-Source-Menümanagement-Tool für Proxmox VE 8+, erstellt und gepflegt von MacRimi mit einem kleinen Team von Testern und Mitwirkenden.",
"ogTitle":"Über das Projekt | ProxMenux-Dokumentation",
"ogDescription":"Über ProxMenux — ein menügesteuertes Open-Source-Werkzeug zur Verwaltung von Proxmox VE 8+."
},
"header":{
"title":"Über",
"description":"Projektinformationen, FAQ, Mitwirkende und Verhaltenskodex. ProxMenux ist ein Open-Source-Menümanagement-Tool für Proxmox VE 8+, das von MacRimi mit Hilfe eines kleinen Teams von Testern und Mitwirkenden entwickelt und gewartet wird.",
"section":"Über"
},
"callout":{
"title":"Open Source, von der Community getragen",
"body":"ProxMenux steht unter der GPL-3.0-Lizenz und wird öffentlich auf GitHub entwickelt. Jedes Skript lässt sich prüfen, jede Änderung nachvollziehen. Beiträge in Form von Fehlermeldungen, Ideen, Code und Tests sind willkommen."
},
"section":{
"heading":"In diesem Abschnitt",
"options":[
{
"icon":"HelpCircle",
"href":"/docs/about/faq",
"title":"FAQ",
"description":"Häufig gestellte Fragen: Was ist ProxMenux, Installation, Kompatibilität, Anpassung, Updates, Sicherheit, Produktionsnutzung, Deinstallation."
},
{
"icon":"Users",
"href":"/docs/about/contributors",
"title":"Mitwirkende",
"description":"Anerkennung für die Menschen, die ProxMenux möglich machen: Tester, Reviewer und Entwickler, die jede Version mitgestalten."
},
{
"icon":"ScrollText",
"href":"/docs/about/code-of-conduct",
"title":"Verhaltenskodex",
"description":"Projektwerte, Verantwortung für eingereichten Code und Beitragsrichtlinien. Pflichtlektüre vor dem Einreichen eines PR oder einer Fehlermeldung."
}
]
},
"involved":{
"heading":"Beteiligen Sie sich",
"intro":"Drei Orte, um sich mit dem Projekt zu beschäftigen:",
"description":"GitHub Pull Requests – lesen Sie zuerst den Verhaltenskodex."
}
]
},
"support":{
"heading":"Unterstützung des Projekts",
"introRich":"Wenn ProxMenux Ihnen Zeit spart, ist der einfachste Weg, anderen zu helfen, es zu entdecken, <starlink> dem Repo ein ⭐ auf GitHub</starlink> zu geben. Wenn Sie weiter gehen wollen:",
"kofiLabel":"Auf Ko-fi unterstützen",
"kofiOutro":"- kauft dem Betreuer einen Kaffee und hält die Entwicklung am Laufen."
}
}
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Jonatan