"loadFailed":"Erreur : Impossible de charger le contenu du Code de conduite."
},
"contentMarkdown":"# 📝 Code de conduite et bonnes pratiques\n\nCe document définit les **principes et les consignes** d’utilisation de **ProxMenux**, afin de promouvoir le **respect, la collaboration et la sécurité** dans le développement.\n\n## 📌 1. Attribution du code et reconnaissance\n\n- Si des **scripts, extraits de code ou idées** proviennent d’autres dépôts ou développeurs, leur auteur d’origine sera toujours cité.\n- Un commentaire dans le code ou la documentation indiquera la source et, si possible, un lien vers le dépôt original.\n- Lors de l’utilisation de code soumis à une **licence** particulière, ses conditions doivent être respectées.\n\n### ✅ Exemple d’attribution correcte dans le code :\n\n```bash\n# Script fondé sur le travail de [Auteur] dans [Lien du dépôt]\n```\n\n## 🔒 2. Sécurité et responsabilité du code\n\n- Tout le code de ce dépôt suit les bonnes pratiques de développement sécurisé.\n- Les contributions introduisant volontairement des vulnérabilités ou des pratiques dangereuses sont interdites.\n- Les scripts ne doivent jamais compromettre la sécurité du système ni les données des utilisateurs.\n- Avant leur mise en œuvre, les contributions doivent être examinées pour vérifier leur sécurité et leur stabilité.\n\n### ⚠️ Divulgation responsable des vulnérabilités\n\nSi vous découvrez une vulnérabilité de sécurité, ne la signalez PAS dans des issues ou forums publics.\n\nSignalez-la plutôt en privé par e-mail :\n\n📧 proxmenux@macrimi.pro\n\nPour en savoir plus sur les vulnérabilités et leur signalement, consultez notre [politique de sécurité](./SECURITY.md).\n\n## 🤝 3. Règles de la communauté\n\nPour maintenir un cadre respectueux et professionnel, tous les utilisateurs doivent suivre ces règles :\n\n- ✅ Restez respectueux et constructifs dans les discussions.\n- ❌ Le harcèlement, les propos haineux et les comportements offensants ne seront pas tolérés.\n- ✅ Formulez vos retours de manière professionnelle, sans attaques personnelles.\n- ❌ Les manquements peuvent entraîner des avertissements ou des exclusions selon leur gravité.\n\n##\n\nCe document encourage un usage éthique du code, la vigilance en matière de sécurité et une communauté respectueuse.\n\n📢 Construisons ensemble quelque chose de remarquable !\n"
"title":"Contribution à ProxMenux | ProxMenux Documentation",
"description":"Comment contribuer à ProxMenux : modèle de branches (main / develop / feature/*), processus de pull request, en-tête de script avec attribution et lien de soutien facultatif, interface en deux phases, fonctions de message et passage d’une branche de fonctionnalité à une version stable.",
"ogTitle":"Contribuer à ProxMenux",
"ogDescription":"Modèle de branches, processus, attribution dans l’en-tête et règle d’interface en deux phases à respecter pour contribuer."
},
"header":{
"title":"Contribuer à ProxMenux",
"description":"ProxMenux accueille les contributions de la communauté : nouveaux scripts, corrections, amélioration des dialogues, traductions et intégrations. Cette page présente la structure du dépôt, le modèle de branches, le processus de pull request, l’en-tête avec attribution et lien de soutien facultatif, ainsi que les conventions à respecter.",
"section":"À propos"
},
"twoPagesCallout":{
"title":"Deux pages connexes, un projet",
"body":"Ne confondez pas cette page avec <contributorsLink>Contributeurs</contributorsLink>, qui met à l’honneur les testeurs, relecteurs et développeurs déjà impliqués. Cette page s’adresse à <em>vous</em>, futur contributeur, et explique comment préparer une pull request en vue de son intégration."
},
"branching":{
"heading":"Modèle de branchement",
"intro":"ProxMenux utilise un modèle de branchement à trois niveaux :",
"headerBranch":"Branche",
"headerPurpose":"Objet",
"rows":[
{
"branch":"main",
"purposeRich":"Code stable, prêt pour la production. Seules les modifications prêtes à être publiées sont intégrées ici. C’est la version obtenue lors d’une installation normale de ProxMenux."
},
{
"branch":"develop",
"purposeRich":"Branche de développement actif : tous les nouveaux changements y sont intégrés en premier. Elle correspond au canal « bêta ». Lorsqu’une version stable est prête, elle est publiée dans <code>main</code> à partir de cette branche."
},
{
"branch":"feature/*",
"purposeRich":"Branches temporaires pour une fonctionnalité, une correction ou une amélioration. Créées à partir de <code>develop</code>, puis fusionnées dans <code>develop</code> par pull request après relecture."
}
],
"calloutTitle":"Ce que cela signifie pour les utilisateurs",
"calloutBody":"Les utilisateurs qui suivent <code>main</code> reçoivent des versions testées. Ceux qui souhaitent les nouveautés plus tôt et acceptent quelques imperfections peuvent suivre <code>develop</code>. Les nouvelles fonctions passent toujours d’abord par <code>develop</code> ; rien n’arrive dans <code>main</code> sans ce cycle."
},
"workflow":{
"heading":"Processus de pull request",
"intro":"De l'idée à la version fusionnée en cinq étapes:",
"step1Lead":"<strong>Créer une branche de fonction à partir de <code>develop</code></strong>:",
"step1Trail":"Utilisez un nom descriptif de branche : <code>feature/zfs-arc-tuning</code>, <code>feature/fix-iommu-detection</code>, <code>feature/add-tailscale-script</code>.",
"step2Lead":"<strong>Travailler sur vos changements et pousser la branche:</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>Ouvrez une pull request vers <code>develop</code></strong>, pas vers <code>main</code>. Vérifiez sur GitHub que la branche de base est <code>develop</code>. Décrivez le rôle du script, ses modifications et les versions de Proxmox VE utilisées pour les tests.",
"step4":"<strong>Après relecture, les modifications sont fusionnées dans <code>develop</code>.</strong> Un responsable vérifie le code, les conventions d’en-tête et la règle d’interface en deux phases. S’il demande des corrections, envoyez de nouveaux commits dans la même branche : la PR se met à jour automatiquement.",
"step5":"<strong>Les versions stables passent de <code>develop</code> à <code>main</code>.</strong> Lors d’une publication, <code>main</code> est avancée jusqu’à <code>develop</code> par fast-forward, puis étiquetée. Votre contribution entre dans la prochaine version stable."
},
"scriptHeader":{
"heading":"En-tête de script — métadonnées et description",
"intro":"Chaque script de ProxMenux s'ouvre avec deux blocs de commentaires adjacents qui forment ensemble l'en-tête. Ils sont <strong>tous les deux requis</strong> — ensemble, ils font savoir à tout lecteur qui a écrit le script et ce qu'il fait, le tout sans ouvrir le code lui-même.",
"bullets":[
"<strong>Bloc supérieur : métadonnées.</strong> Auteur, liens GitHub/de soutien facultatifs, responsable, copyright, licence, version et date de mise à jour. C’est aussi la <em>reconnaissance des contributeurs</em> : pour un nouveau script, ajoutez votre nom et, si vous le souhaitez, votre page GitHub et un profil de soutien tel que Ko-fi, GitHub Sponsors ou Buy Me a Coffee.",
"<strong>Bloc inférieur : description.</strong> Un court paragraphe en anglais simple explique le rôle du script. Il se lit <em>avant</em> le code et doit se suffire à lui-même : objectif, actions principales, ressources concernées et prérequis."
],
"licenseCalloutTitle":"La ligne de licence est fixe — GPL-3.0",
"licenseCalloutBody":"ProxMenux est publié sous la licence publique générale <strong>GNU v3.0</strong>. Chaque script du projet est livré sous cette même licence; la ligne <code>License</code> dans l'en-tête est toujours la référence GPL-3.0 montrée dans l'exemple ci-dessous — ce n'est pas un choix par script. En contribuant un script, vous acceptez de le publier sous GPL-3.0, ce qui signifie que n'importe qui peut le lire, le modifier et le redistribuer (y compris les modifications) tant qu'ils le conservent sous la même licence. Le texte entier vit à <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":"Les lignes <code>GitHub</code> et <code>Sponsor</code> sont optionnelles — laissez-les dehors si vous ne voulez pas les publier. Tout le reste est nécessaire.",
"whyCalloutTitle":"Pourquoi cela est important",
"whyCalloutBody":"Contribuer à l’open source est un travail bénévole. Le nom et le lien de soutien éventuel dans le code rendent l’auteur visible à chaque lecture, au lieu de le cacher derrière le projet. La description a un autre rôle : c’est la première chose qu’un futur responsable ou utilisateur curieux lit. Sa clarté détermine souvent si le script inspire confiance ou est évité."
},
"structure":{
"heading":"Structure du projet",
"intro":"Où chaque type de script vit dans le dépôt :",
"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":"Chaque script charge <code>utils.sh</code> au démarrage avec source pour obtenir les fonctions de message, l’indicateur d’attente, les couleurs et le système de traduction. Les bibliothèques communes dans <code>scripts/global/</code> sont chargées explicitement par les scripts qui les utilisent."
},
"twoPhase":{
"heading":"La règle de conception de l’interface en deux phases",
"intro":"C’est la convention la plus importante de ProxMenux et celle qui entraîne le plus souvent des demandes de correction dans les PR. Chaque script est divisé en <strong>exactement deux phases</strong> :",
"purposeRich":"Recueillir chaque décision de l'utilisateur. Effectuer tout travail préparatoire nécessaire (sondes, scans, vérifications).",
"screenRich":"<code>dialog</code> superpositions. Si une sonde entre deux menus prend plus d'une seconde ou deux, montrez un spinner <code>msg_info</code> afin que l'utilisateur sache que le script n'a pas gelé, puis appelez <code>stop_spinner</code> juste avant la boîte de dialogue suivante."
"purposeRich":"Exécutez toutes les opérations. Affichez l'historique complet des progrès accumulés à l'écran.",
"screenRich":"Messages visibles <code>msg_info</code> / <code>msg_ok</code>; jamais <code>dialog</code>."
}
],
"principle":"Le principe: <strong> collecte tout d'abord, puis exécute tout</strong>. L'utilisateur voit un menu de dialogue propre (phase 1), puis une vue d'exécution propre (phase 2). Pas de mélange — pas de dialogue apparaissant au milieu de l'exécution, pas de bruit de progression pendant la sélection.",
"phase1Heading":"Phase 1 — modèle typique",
"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":"Règles <strong> pour la phase 1:</strong>",
"phase1Rules":[
"Si un spinner <code>msg_info</code> est en cours d'exécution et que vous devez ouvrir un menu <code>dialog</code> ou <code>whiptail</code>, appelez d'abord <code>stop_spinner</code> — le spinner ne peut pas coexister avec la superposition dessinée par l'un ou l'autre des outils. Si aucun spinner n'est actif, vous n'avez pas besoin de l'appeler.",
"Utilisez <code>show_proxmenux_logo</code> + <code>msg_title</code> + <code>msg_info</code> pour donner un contexte visuel à une opération longue en phase 1, par exemple une vérification de plus de cinq secondes. La fonction efface déjà l’écran : n’appelez pas <code>clear</code> avant.",
"N'appelez pas <code>show_proxmenux_logo</code> entre les menus de dialogue où il n'y a rien à afficher — le nettoyage de l'écran pour un terminal vide n'est que du bruit visuel.",
"Conservez toutes les décisions et les résultats de la sonde dans des variables ou des tableaux parallèles. La récapitulation visible se produit au début de la phase 2, pas dans la phase 1."
],
"phase2Heading":"Phase 2 — modèle typique",
"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>Règles pour la phase 2:</strong> toujours commencer avec <code>show_proxmenux_logo + msg_title</code>; récapituler immédiatement les résultats de la phase 1 sous la forme de lignes <code>msg_ok</code>; n'appelez plus jamais <code>show_proxmenux_logo</code> (il effacerait les progrès accumulés); n'appelez jamais <code>dialog</code> dans la phase 2 — si une décision d'exécution est vraiment inévitable, utilisez <code>whiptail</code> (voir la section suivante)."
},
"dialogVsWhiptail":{
"headingRich":"Quand utiliser <code>dialog</code> vs <code>whiptail</code>",
"intro":"Les deux outils dessinent des interfaces utilisateur en mode texte, mais ils se comportent très différemment à l'écran — et ProxMenux les utilise en deux phases distinctes pour une raison.",
"whenRich":"<strong>Toujours dans la phase 1.</strong> Chaque sélection interactive — choisir un VM, un disque, un système de fichiers, confirmer une action — utilise <code>dialog</code>. C'est l'outil d'interface utilisateur par défaut de ProxMenux.",
"effectRich":"Prend le contrôle du terminal : efface l’écran, dessine son interface et rétablit l’état précédent à la fermeture. Cela convient à la phase 1, où aucun résultat utile n’est encore affiché."
"whenRich":"<strong>Seulement en phase 2, en cas de nécessité.</strong> Le cas typique est la proposition de redémarrage en fin d’exécution. N’utilisez pas <code>whiptail</code> pour demander « continuer ? » en cours d’exécution : cette décision devait être prise en phase 1.",
"effectRich":"Interface plus légère qui <em>n’efface pas</em> le contexte du terminal. L’historique <code>msg_ok</code>/<code>msg_info</code> de la phase 2 reste visible derrière la boîte de dialogue. Elle convient donc lorsque la progression est déjà affichée."
}
],
"calloutTitle":"Pourquoi la scission est importante",
"calloutBody":"Si vous appelez <code>dialog</code> au milieu de la phase 2, chaque ligne <code>msg_ok</code> que l'utilisateur regarde disparaît. Vous effacez la piste de vérification. <code>whiptail</code> évite cela. Donc la règle n'est pas arbitraire — il s'agit de préserver la vision de l'utilisateur de ce que le script a fait jusqu'ici.",
"rebootHeading":"Proposition de redémarrage : le cas type de whiptail en phase 2",
"rebootIntro":"Si un script peut nécessiter un redémarrage après l’activation d’IOMMU ou la modification du noyau, la question de fin de phase 2 utilise <code>whiptail</code>. Prévoyez toujours une branche « Non » avertissant de ne pas utiliser la ressource concernée avant le redémarrage :",
"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":"Référence des fonctions du message",
"intro":"Toutes sont définies dans <code>utils.sh</code>. Utilisez-les par défaut pour les sorties visibles afin de garder une présentation cohérente entre scripts. Si une fonction manque, par exemple un niveau de sévérité ou un outil de mise en page, proposez-la dans votre pull request. Elle sera examinée et ajoutée à <code>utils.sh</code> si elle est utile à plusieurs scripts.",
"headerFunction":"Fonction",
"headerWhen":"Quand utiliser",
"headerSpinner":"Indicateur de progression",
"rows":[
{
"function":"msg_info \"text\"",
"whenRich":"Opération en cours.",
"spinner":"Démarre"
},
{
"function":"stop_spinner",
"whenRich":"Fin des travaux préparatoires silencieux dans la phase 1 — tue spinner, efface la ligne.",
"spinner":"Arrête"
},
{
"function":"msg_ok \"text\"",
"whenRich":"Opération réussie. À utiliser aussi pour une fonction activée, même si un redémarrage reste nécessaire.",
"spinner":"Arrête"
},
{
"function":"msg_warn \"text\"",
"whenRich":"Avertissement réel ou état dégradé.",
"spinner":"Arrête"
},
{
"function":"msg_error \"text\"",
"whenRich":"Erreur fatale.",
"spinner":"Arrête"
},
{
"function":"msg_info2 \"text\"",
"whenRich":"Conseil sans blocage, dans une ligne d’information cyan.",
"spinner":"Arrête"
},
{
"function":"msg_success \"text\"",
"whenRich":"Message final « Appuyez sur Entrée pour revenir » en fin de phase 2.",
"spinner":"Arrête"
},
{
"function":"msg_title \"text\"",
"whenRich":"Titre gras avec espacement intégré. Utilisé au début de la phase 2.",
"spinner":"—"
},
{
"function":"show_proxmenux_logo",
"whenRich":"Efface l’écran et affiche le logo. À appeler <em>une seule fois</em> au début de la phase 2.",
"spinner":"—"
}
]
},
"dialogConventions":{
"heading":"conventions de dialogue",
"bullets":[
"Passez toujours <code>--backtitle \"$BACKTITLE\"</code> à chaque appel <code>dialog</code> et <code>whiptail</code>. <code>$BACKTITLE</code> est toujours <code>\"ProxMenux\"</code> — réglé une fois à l'en-tête du script et jamais dépassé. L'utilisateur doit toujours voir le nom du projet comme le contexte de cadrage, jamais le propre titre du script.",
"Enveloppez toujours les titres et les messages avec <code>$(translate \"...\")</code>.",
"Redirige toujours la sortie <code>dialog</code> avec <code>2>&1 >/dev/tty</code> — le stdout capturé devient la sélection de l'utilisateur, tandis que la boîte de dialogue elle-même s'appuie sur le terminal.",
"Utilisez les variables standard de dimension UI (<code>$UI_MENU_H</code>, <code>$UI_MSG_W</code>, etc.) pour un calibrage cohérent entre les scripts.",
"Vérifiez toujours les choix vides ou annulés et gérez-les proprement."
],
"exampleIntro":"Exemple complet — construire un menu de sélection VM et gérer l'annulation:",
"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":"Politique de traduction",
"intro":"Toutes les chaînes visibles par l'utilisateur doivent être enveloppées avec la fonction <code>translate</code>. ProxMenux les traduit automatiquement dans toutes les langues prises en charge — vous écrivez l'anglais, l'utilisateur lit leur langue maternelle.",
"Écrivez les chaînes en anglais : la traduction est gérée automatiquement lors du build.",
"Rédigez des chaînes concises. Évitez si possible les variables dans de longues phrases.",
"Ne traduisez <strong>pas</strong> les noms de variables, chemins ou identifiants techniques."
]
},
"variableStyle":{
"heading":"Conventions de variables et de style",
"bullets":[
"Utilisez <code>UPPER_CASE</code> pour les variables de niveau script.",
"Utiliser <code>lower_case</code> pour les variables de fonction locales (déclarer avec <code>local</code>).",
"Entourez les expansions de variables de guillemets : <code>\"$VAR\"</code>, pas <code>$VAR</code>.",
"Utiliser <code>[[ ]]</code> pour les conditions, et non <code>[ ]</code> (sauf lorsque POSIX est nécessaire).",
"<code>show_proxmenux_logo</code> est le moyen prévu pour effacer l’écran : il le nettoie et affiche le logo du projet pour conserver un contexte visuel. Appelez-le une fois au début de la phase 2, et éventuellement avant une longue attente en phase 1."
],
"standardNamesIntro":"Noms de variables standard dans l'ensemble du projet :",
"redirectHeading":"Réorienter la sortie de l'outil pendant la phase 2",
"redirectIntro":"La phase 2 affiche un journal de lignes <code>msg_info → msg_ok</code>. Si un outil appelé, comme apt, mkfs, qm, pct ou dd, écrit sur stdout/stderr, sa sortie fait défiler les messages et brouille la présentation. L’utilisateur ne distingue plus la progression du script des détails produits par l’outil.",
"withoutRedirectIntro":"<strong>Sans redirection</strong> — ce que l'utilisateur voit si vous ne manipulez pas le bruit:",
"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>Avec redirection</strong> — à quoi ressemble la même opération lorsque le bruit est envoyé ailleurs:",
"logLead":"<strong>Envoyez la sortie à un fichier journal</strong> lorsque vous voudrez peut-être l'inspecter plus tard (débogage d'une installation échouée, vérification de ce que dpkg a fait réellement). C'est le modèle préféré pour toute opération apt:",
"referenceOutro":"Le script <code>scripts/global/update-pve9_2.sh</code> est une implémentation de référence — chaque appel <code>apt-get</code> envoie une sortie vers un fichier journal de sorte que l'utilisateur ne voit que le flux propre <code>msg_info → msg_ok</code>, tandis que le journal sur le disque vous permet de reconstruire exactement ce qu'apt a fait si quelque chose tourne mal."
},
"dosAndDonts":{
"heading":"Faites et ne faites pas",
"doHeading":"✅ À faire",
"doBullets":[
"<code>stop_spinner</code> avant un <code>dialog</code> dans la phase 1 seulement quand un spinner <code>msg_info</code> est en cours d'exécution.",
"La phase 2 commence par <code>show_proxmenux_logo + msg_title + msg_ok</code> pour récapituler les résultats de la phase 1.",
"Utilisez <code>msg_ok</code> pour des fonctionnalités activées avec succès, même si un redémarrage est nécessaire.",
"Utilisez le <code>whiptail</code> (et non le <code>dialog</code>) pour toute invitation après exécution qui doit apparaître dans la phase 2.",
"Prévoyez toujours une branche « Non » dans les dialogues de redémarrage pour avertir de ne pas démarrer la ressource concernée avant le redémarrage.",
"Protégez la logique VM uniquement en vérifiant <code>[[ -f \"/etc/pve/qemu-server/$'{'vmid'}'.conf\" ]]</code> — les contrôleurs et NVMe PCIe ne peuvent pas être ajoutés aux conteneurs LXC.",
"Utiliser <code>ensure_repositories</code> de <code>utils-install-functions.sh</code> au lieu de <code>apt-get update</code> inconditionnel.",
"Utiliser des tableaux parallèles dans la phase 1 lorsque chaque élément nécessite plusieurs dialogues."
],
"dontHeading":"❌ À éviter",
"dontBullets":[
"Appelez <code>dialog</code> alors qu'un spinner est actif.",
"Passez la récapitulation de la phase 1 au début de la phase 2.",
"Appelez <code>show_proxmenux_logo</code> une deuxième fois — il efface tout ce que la phase 2 a imprimé.",
"Utiliser <code>dialog</code> dans la phase 2 (utiliser <code>whiptail</code> pour le cas inévitable rare).",
"Utiliser <code>clear</code> seul.",
"Enveloppez <code>msg_title</code> dans des lignes vierges <code>echo \"\"</code> — il inclut déjà l'espacement.",
"Utilisez <code>msg_warn</code> pour signaler une fonctionnalité activée avec succès — c'est un <code>msg_ok</code>.",
"Exécuter sans condition <code>apt-get update</code> — utiliser <code>ensure_repositories</code>."
]
},
"submitting":{
"heading":"Soumettre votre contribution",
"steps":[
"Créez un fork de <code>MacRimi/ProxMenux</code> sur GitHub, puis clonez votre fork.",
"Créer une branche <code>feature/*</code> à partir de <code>develop</code> (voir <em>Modèle de branchage</em> ci-dessus).",
"Suivez ce guide pour tout script nouveau ou modifié. Écrivez l'en-tête avec votre nom; ajoutez la ligne de sponsor optionnelle si vous voulez.",
"Testez le script sur une véritable instance Proxmox VE : phase 1 avec toutes les branches de dialogue, et phase 2 avec chaque opération et son retour arrière propre en cas d’erreur.",
"Ouvrez une pull request <strong>vers <code>develop</code></strong> avec une description claire : rôle du script, changements et version Proxmox VE utilisée pour les tests.",
"Assurez-vous que votre contribution respecte le <cocLink>Code de conduite</cocLink>."
],
"securityOutro":"Pour les questions sensibles à la sécurité, suivez le flux de divulgation dans <securityLink>SECURITY.md</securityLink> plutôt que d'ouvrir une question publique."
"tail":"— demander avant de construire si vous n'êtes pas sûr si une idée correspond, ou de trouver des collaborateurs sur une fonctionnalité plus grande."
"ogDescription":"Rencontrez les contributeurs derrière ProxMenux."
},
"header":{
"title":"Contributeurs",
"description":"Le projet ProxMenux grandit grâce à ses contributeurs. Cette page reconnaît leur travail : tester les versions avant leur publication, détecter les régressions, examiner les PR et orienter les nouvelles fonctionnalités.",
"section":"À propos"
},
"beyond":{
"title":"Au-delà de cette liste",
"body":"De nombreuses autres personnes contribuent en signalant des bugs, en proposant des fonctionnalités dans Discussions, en testant les versions bêta ou en traduisant le projet. La liste complète des contributeurs au code figure dans le <extlink>graphique des contributeurs GitHub</extlink>. La page ci-dessous met en avant les personnes les plus actives dans les tests et la vérification des versions de ProxMenux."
},
"testers":{
"heading":"Testeurs et évaluateurs",
"intro":"Ces personnes ont été parmi les premières à contribuer au projet. Leurs tests, signalements de problèmes et suggestions ont aidé ProxMenux à devenir ce qu’il est aujourd’hui.",
"roles":{
"testing":"Tests",
"testingReviewer":"Tests et relecture"
},
"youtube":"YouTube"
},
"contribute":{
"heading":"Vous voulez contribuer ?",
"intro":"Toute contribution est la bienvenue — code, test, conception, documentation, ou tout simplement partager vos idées:",
"tester":"<strong>Testeur</strong> — essayez le <beta>canal bêta</beta> et signalez ce qui fonctionne ou non avant la publication des versions stables.",
"developer":"<strong>Développeur</strong> — Bash, Next.js (TypeScript) et un peu de Python pour l’environnement virtuel de traduction (venv). Les PR sont les bienvenues sur <gh>GitHub</gh>.",
"designer":"<strong>Designer</strong> — Améliorations de l'interface utilisateur, icônes, captures d'écran pour la documentation.",
"ideas":"<strong>Idées</strong> — ouvrez un sujet dans <disc>GitHub Discussions</disc> avant de créer une issue pour demander une fonctionnalité."
},
"coc":{
"title":"Lisez d'abord le Code de conduite",
"body":"Avant de proposer du code ou de signaler un problème, lisez le <coclink>Code de conduite et les bonnes pratiques</coclink>. Il précise les attentes sur la responsabilité du code, le signalement des vulnérabilités et le périmètre des PR."
"description":"Questions fréquentes sur ProxMenux : présentation, installation, compatibilité à partir de PVE 8, personnalisation, mises à jour, sécurité, utilisation en production, fichiers système, contributions et désinstallation.",
"ogDescription":"Questions fréquentes sur l’installation de ProxMenux, sa compatibilité, sa sécurité et les façons de contribuer."
},
"header":{
"title":"Foire aux questions",
"description":"Questions courantes sur ProxMenux : présentation, public visé, installation, mise à jour, désinstallation, compatibilité, personnalisation, sécurité et contributions. Si votre question n’est pas ici, consultez GitHub Discussions ou ouvrez une issue.",
"section":"À propos"
},
"quickLinks":{
"title":"Liens rapides",
"installationLabel":"Installation",
"installationSuffix":"— la commande d'installation en une seule ligne + dépendances.",
"introductionLabel":"Présentation",
"introductionSuffix":" — ce que fait ProxMenux, en cinq minutes.",
"uninstallLabel":"Désinstaller",
"uninstallSuffix":" — désinstallation propre.",
"issuesLabel":"GitHub Issues",
"discussionsLabel":"Discussions"
},
"q1":{
"question":"Qu'est-ce que ProxMenux et dans quel cas est-il utilisé?",
"p1Rich":"<strong>ProxMenux</strong> est un outil interactif à menus qui rend <strong>Proxmox VE</strong> accessible à tous, quel que soit le niveau technique. Il simplifie l’exécution des commandes et permet d’agir sur le système sans connaissances avancées de Linux.",
"p2":"Les utilisateurs moins expérimentés exécutent les commandes depuis des menus structurés, avec moins de saisie manuelle dans le terminal. Les administrateurs expérimentés gagnent du temps sur les tâches répétitives : sécurisation après installation, passthrough GPU, importation de VM OVF et rotation des instantanés ZFS.",
"p3":"Proxmox VE est largement utilisé pour:",
"items":[
"Virtualisation de qualité entreprise",
"HomeLab et solutions cloud personnelles",
"Serveurs multimédias, automatisation et plus encore"
]
},
"q2":{
"question":"Comment installer ProxMenux ?",
"p1Rich":"Suivez le <installlink>guide d’installation</installlink>. En résumé :",
"p2":"Une fois l’installation terminée, lancez simplement :",
"menuCmd":"menu"
},
"q3":{
"question":"ProxMenux est-il compatible avec toutes les versions Proxmox ?",
"bodyRich":"<strong>Non — ProxMenux nécessite Proxmox VE 8 ou une version ultérieure.</strong> PVE 7 et les versions antérieures ne sont pas pris en charge. Passez d’abord de PVE 7 à 8.x en suivant la procédure officielle Proxmox. ProxMenux peut ensuite gérer le passage de 8 à 9 via <upgradelink>Utilitaires → Mettre à niveau PVE 8 vers PVE 9</upgradelink>."
},
"q4":{
"question":"Puis-je personnaliser ProxMenux ?",
"p1Rich":"Les mises à jour peuvent écraser les modifications locales des scripts principaux. Évitez donc de modifier directement ces fichiers. Voici ce que vous <em>pouvez</em> personnaliser :",
"items":[
"La bannière console via l'outil <strong>FastFetch</strong> dans les options Post-Install.",
"Quels composants optionnels sont installés (Monitor, Fail2Ban, Lynis...) — choisissez lors de l'installation ou via le menu correspondant plus tard."
]
},
"q5":{
"question":"Comment mettre à jour ProxMenux?",
"p1Rich":"Lorsqu’une nouvelle version est disponible, ProxMenux la détecte au prochain lancement de <code>menu</code> et propose la mise à jour. Si vous acceptez, les fichiers et la configuration de l’outil sont remplacés dans l’installation existante ; aucun téléchargement manuel n’est nécessaire.",
"p2Rich":"Les utilisateurs de la version stable reçoivent les mises à jour stables, et ceux de la bêta, les mises à jour bêta. Lorsqu’une version stable est publiée, la bêta le signale à la prochaine ouverture du menu et propose de basculer automatiquement. Consultez le <betalink>programme bêta</betalink>."
},
"q6":{
"question":"Où puis-je signaler les problèmes?",
"p1Rich":"Signalez les bogues sur <issueslink>GitHub Issues</issueslink>. Indiquez les étapes pour les reproduire, le message d’erreur et, si nécessaire, la sortie de Monitor obtenue avec <code>journalctl -u proxmenux-monitor -n 50</code>.",
"p2Rich":"Pour les problèmes de <strong>sécurité</strong>, <strong>ne les divulguez pas publiquement</strong>. Suivez la procédure de signalement responsable du <coclink>code de conduite et des bonnes pratiques</coclink>."
},
"q7":{
"question":"Puis-je contribuer au ProxMenux?",
"p1Rich":"<strong>Bien sûr.</strong> ProxMenux est un projet libre et collaboratif. Vous pouvez contribuer au code (Bash, Next.js/TypeScript et outils de traduction en Python), aux tests, à la documentation, au design ou proposer des idées.",
"item1Rich":"Discutez des idées dans <discusslink>GitHub Discussions</discusslink> avant d'ouvrir une demande de fonctionnalité.",
"item2Rich":"Avant de soumettre une pull request, lisez le <coclink>code de conduite et les bonnes pratiques</coclink>.",
"item3Rich":"Consultez la <contriblink>page des contributeurs</contriblink> pour connaître les personnes qui participent actuellement aux tests et aux revues."
},
"q8":{
"question":"Est-ce que ProxMenux modifie les fichiers système critiques?",
"p1Rich":"<strong>L’installation de ProxMenux ajoute les composants suivants.</strong>",
"item1Rich":"Dépendances via apt : <code>dialog</code>, <code>curl</code>, <code>jq</code> et <code>git</code>. Les traductions utilisent des catalogues JSON préconstruits ; l’installateur n’ajoute aucun environnement virtuel de traduction à l’hôte.",
"item2Rich":"L'arborescence des scripts à <code>/usr/local/share/proxmenux/</code>.",
"item3Rich":"Le lanceur situé dans <code>/usr/local/bin/menu</code>.",
"item4Rich":"En option : le service systemd de Monitor, <code>proxmenux-monitor.service</code>.",
"p2Rich":"ProxMenux ne modifie <em>pas</em> la configuration principale de Proxmox, sauf si vous le demandez explicitement depuis un menu dédié. Par exemple, la réparation du réseau modifie <code>/etc/network/interfaces</code>, mais seulement après votre confirmation et la création d’une sauvegarde."
},
"q9":{
"question":"Est-il sûr d'utiliser ProxMenux en production?",
"bodyRich":"<strong>Oui.</strong> ProxMenux ne modifie les fichiers principaux de Proxmox que sur demande explicite et peut donc être utilisé en production. Comme pour toute automatisation, testez d’abord dans un environnement contrôlé et prévoyez des sauvegardes avant les opérations destructives : mise à niveau de PVE 8 vers 9, formatage d’un disque, suppression d’une VM, etc."
},
"q10":{
"question":"Comment désinstaller ProxMenux ?",
"p1Rich":"Dans ProxMenux : <strong>Paramètres → Désinstaller ProxMenux</strong>. La désinstallation supprime l’arborescence des scripts, le lanceur et le service Monitor, ainsi que les dépendances sélectionnées si vous le souhaitez. Elle restaure <code>/root/.bashrc</code> et <code>/etc/motd</code> depuis les sauvegardes de l’installation, si elles existent.",
"p2Rich":"Étape par étape : <uninstalllink>Désinstaller ProxMenux</uninstalllink>."
"p1Rich":"Le résultat de 1/95 attribué à <em>Chong Lua Dao</em> et signalé dans l’issue #162 a été identifié par le mainteneur comme un faux positif. L’installateur utilise le modèle <code>curl | bash</code> et peut télécharger <code>jq</code> depuis sa version officielle sur GitHub. Ce <em>comportement</em> peut déclencher des analyses heuristiques ; ce rapport historique ne préjuge pas de tous les téléchargements futurs.",
"p2Rich":"ProxMenux est entièrement open source. Vous pouvez examiner le script d’installation ligne par ligne : <scriptlink>install_proxmenux.sh</scriptlink>. Plus de contexte dans l’<issuelink>issue #162</issuelink>."
"description":"À propos de ProxMenux : objectifs du projet, contributeurs, FAQ et code de conduite. Cet outil de gestion open source à menus pour Proxmox VE 8+ est développé et maintenu par MacRimi avec une petite équipe de testeurs et de contributeurs.",
"ogTitle":"À propos | Documentation ProxMenux",
"ogDescription":"À propos de ProxMenux — un outil de gestion open source à menus pour Proxmox VE 8+."
},
"header":{
"title":"À propos",
"description":"Informations sur le projet, FAQ, contributeurs et code de conduite. ProxMenux est un outil de gestion open source à menus pour Proxmox VE 8+, développé et maintenu par MacRimi avec l’aide d’une petite équipe de testeurs et de contributeurs.",
"section":"À propos"
},
"callout":{
"title":"Open source, porté par la communauté",
"body":"ProxMenux est distribué sous licence GPL-3.0 et développé publiquement sur GitHub. Chaque script peut être examiné et chaque modification retracée. Les contributions sont les bienvenues : signalements de bugs, idées, code et tests."
},
"section":{
"heading":"Dans cette section",
"options":[
{
"icon":"HelpCircle",
"href":"/docs/about/faq",
"title":"FAQ",
"description":"Questions fréquentes : présentation de ProxMenux, installation, compatibilité, personnalisation, mises à jour, sécurité, utilisation en production et désinstallation."
},
{
"icon":"Users",
"href":"/docs/about/contributors",
"title":"Contributeurs",
"description":"Un hommage aux personnes qui rendent ProxMenux possible : testeurs, relecteurs et développeurs qui contribuent à chaque version."
},
{
"icon":"ScrollText",
"href":"/docs/about/code-of-conduct",
"title":"Code de conduite",
"description":"Valeurs du projet, attentes en matière de responsabilité du code et lignes directrices en matière de contribution. Lecture obligatoire avant d'ouvrir un PR ou un rapport."
}
]
},
"involved":{
"heading":"Participer",
"intro":"Trois endroits pour participer au projet :",
"description":"GitHub Pull Requests — lisez d’abord le code de conduite."
}
]
},
"support":{
"heading":"Soutenir le projet",
"introRich":"Si ProxMenux vous fait gagner du temps, le moyen le plus simple de le faire découvrir est de <starlink>donner une ⭐ au dépôt sur GitHub</starlink>. Pour aller plus loin :",
"kofiLabel":"Soutien sur Ko-fi",
"kofiOutro":"— achète au responsable un café et continue le développement."
}
}
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.
MacRimi
