diff options
Diffstat (limited to 'docs/fr-FR')
| -rw-r--r-- | docs/fr-FR/ChangeLog/20190830.md | 4 | ||||
| -rw-r--r-- | docs/fr-FR/README.md | 4 | ||||
| -rw-r--r-- | docs/fr-FR/breaking_changes.md | 2 | ||||
| -rw-r--r-- | docs/fr-FR/cli.md | 6 | ||||
| -rw-r--r-- | docs/fr-FR/cli_configuration.md | 4 | ||||
| -rw-r--r-- | docs/fr-FR/contributing.md | 18 | ||||
| -rw-r--r-- | docs/fr-FR/flashing.md | 20 | ||||
| -rw-r--r-- | docs/fr-FR/getting_started_getting_help.md | 4 | ||||
| -rw-r--r-- | docs/fr-FR/getting_started_github.md | 6 | ||||
| -rw-r--r-- | docs/fr-FR/getting_started_introduction.md | 4 | ||||
| -rw-r--r-- | docs/fr-FR/newbs_best_practices.md | 16 | ||||
| -rw-r--r-- | docs/fr-FR/newbs_building_firmware_configurator.md | 4 | ||||
| -rw-r--r-- | docs/fr-FR/newbs_flashing.md | 10 | ||||
| -rw-r--r-- | docs/fr-FR/newbs_getting_started.md | 10 | ||||
| -rw-r--r-- | docs/fr-FR/newbs_testing_debugging.md | 8 |
15 files changed, 60 insertions, 60 deletions
diff --git a/docs/fr-FR/ChangeLog/20190830.md b/docs/fr-FR/ChangeLog/20190830.md index 4ce1b08631..cb223be31a 100644 --- a/docs/fr-FR/ChangeLog/20190830.md +++ b/docs/fr-FR/ChangeLog/20190830.md @@ -6,9 +6,9 @@ Ce document présente les fusions de Breaking Change. Voici la liste des changem ## Formattage de code Core avec clang-format -* Tous les fichiers core (`drivers/`, `quantum/`, `tests/`, et `tmk_core/`) seront formattés avec clang-format +* Tous les fichiers core (`drivers/`, `quantum/`, `tests/`, et `tmk_core/`) seront formatés avec clang-format * Un processus travis pour reformatter les PRs lors de la fusion a été mis en place -* Vous pouvez utiliser la nouvelle commande CLI `qmk cformat` afin de formatter avant de soumettre votre PR si vous le souhaitez. +* Vous pouvez utiliser la nouvelle commande CLI `qmk cformat` afin de formater avant de soumettre votre PR si vous le souhaitez. ## Nettoyage des descripteurs LUFA USB diff --git a/docs/fr-FR/README.md b/docs/fr-FR/README.md index 5bbe353b48..d3591554b0 100644 --- a/docs/fr-FR/README.md +++ b/docs/fr-FR/README.md @@ -7,7 +7,7 @@ [](https://github.com/qmk/qmk_firmware/pulse/monthly) [](https://github.com/qmk/qmk_firmware/) -## Qu'est ce que QMK Firmware ? +## Qu'est-ce que QMK Firmware ? QMK (*Quantum Mechanical Keyboard*) est une communauté open source qui maintient le firmware QMK, la QMK Toolbox (*Boite à outil*), qmk.fm et leurs documentations. QMK Firmware est un firmware dédié aux claviers qui est basé sur [tmk\_keyboard](http://github.com/tmk/tmk_keyboard). Il offre des fonctionnalités très utiles pour les contrôleurs Atmel AVR, et, plus spécifiquement pour [les produits d'OLKB](http://olkb.com), le clavier [ErgoDox EZ](http://www.ergodox-ez.com), et pour les [produits Clueboard](http://clueboard.co/). Il prend désormais aussi en charge les processeurs ARM qui utilisent ChibiOS. Vous pouvez l'utiliser pour contrôler un clavier personnalisé soudé à la main ou alors sur un clavier avec un PCB personnalisé. @@ -23,7 +23,7 @@ Avant d'être prêt à compiler vous allez devoir [installer un environnement](g make planck/rev4:default -Cette commande compilera la révision `rev4` du clavier `planck` avec la disposition `default`. Notez que tous les claviers n'ont pas forcément de révisions (aussi appelées sous-projects ou dossiers, ou en en Anglais « subprojects » ou « folder »). Cette option peut donc être omise : +Cette commande compilera la révision `rev4` du clavier `planck` avec la disposition `default`. Notez que tous les claviers n'ont pas forcément de révisions (aussi appelées sous-projects ou dossiers, ou en anglais « subprojects » ou « folder »). Cette option peut donc être omise : make preonic:default diff --git a/docs/fr-FR/breaking_changes.md b/docs/fr-FR/breaking_changes.md index 6913dbd3f1..53bbb2212a 100644 --- a/docs/fr-FR/breaking_changes.md +++ b/docs/fr-FR/breaking_changes.md @@ -23,7 +23,7 @@ Le prochain Breaking Change est planifié pour le 29 novembre. ## Quels changements seront inclus? -Pour voir une liste de candidats de breaking changes, vous pouvez regardez la liste des [labels `breaking_change`](https://github.com/qmk/qmk_firmware/pulls?q=is%3Aopen+label%3Abreaking_change+is%3Apr). De nouveaux changements peuvent être ajoutés entre maintenant et lorsque `future` est fermée, et un PR avec ce label n'est pas garanti d'être fusionné. +Pour voir une liste de candidats de breaking changes, vous pouvez regarder la liste des [labels `breaking_change`](https://github.com/qmk/qmk_firmware/pulls?q=is%3Aopen+label%3Abreaking_change+is%3Apr). De nouveaux changements peuvent être ajoutés entre maintenant et lorsque `future` est fermée, et un PR avec ce label n'est pas garanti d'être fusionné. Si vous souhaitez que votre breaking change soit inclus dans ce tour, vous devez créer un PR avec le label `breaking_change` et faire en sorte qu'il soit accepté avant que `future` ne soit fermé. Une fois `future` fermé, aucun nouveau breaking change sera accepté. diff --git a/docs/fr-FR/cli.md b/docs/fr-FR/cli.md index 176ee90da4..4281536458 100644 --- a/docs/fr-FR/cli.md +++ b/docs/fr-FR/cli.md @@ -4,7 +4,7 @@ Cette page décrit comment configurer et utiliser la CLI QMK. # Vue d'ensemble -La CLI de QMK permet de simplifier la compilation et l'intéraction avec les clavier QMK. Nous avons définis plusieurs commandes pour simplifier et rationaliser les tâches telles qu'obtenir et compiler le firmware QMK, créer de nouvelles keymaps, et plus. +La CLI de QMK permet de simplifier la compilation et l'interaction avec les claviers QMK. Nous avons défini plusieurs commandes pour simplifier et rationaliser les tâches telles qu'obtenir et compiler le firmware QMK, créer de nouvelles keymaps, et plus. * [CLI globale](#global-cli) * [CLI locale](#local-cli) @@ -127,7 +127,7 @@ qmk new-keymap [-kb KEYBOARD] [-km KEYMAP] ## `qmk pyformat` -Cette commande formatte le code python dans `qmk_firmware`. +Cette commande formate le code python dans `qmk_firmware`. **Utilisation**: @@ -137,7 +137,7 @@ qmk pyformat ## `qmk pytest` -Cette commande démarre la suite de test python. Si vous faites des changements dans le code Python, assurez vous que les tests se lancent avec succès. +Cette commande démarre la suite de test python. Si vous faites des changements dans le code Python, assurez-vous que les tests se lancent avec succès. **Utilisation**: diff --git a/docs/fr-FR/cli_configuration.md b/docs/fr-FR/cli_configuration.md index dcd197f852..3eed1e0e95 100644 --- a/docs/fr-FR/cli_configuration.md +++ b/docs/fr-FR/cli_configuration.md @@ -41,7 +41,7 @@ user.keymap: None -> default # CLI Documentation (`qmk config`) -La commande `qmk config` est utilisée pour intéragir avec la configuration sous-jacente. Lancée sans argument, elle affiche la configuration courante. Lorsque des arguments sont définis, ils sont considérés comme étant des jetons de configuration, qui sont des chaînes de caractère ne contenant aucun espace avec le format suivant: +La commande `qmk config` est utilisée pour interagir avec la configuration sous-jacente. Lancée sans argument, elle affiche la configuration courante. Lorsque des arguments sont définis, ils sont considérés comme étant des jetons de configuration, qui sont des chaînes de caractère ne contenant aucun espace avec le format suivant: <subcommand|general|default>[.<key>][=<value>] @@ -91,7 +91,7 @@ default.keymap: default -> None ## Plusieurs opérations -Vous pouvez combiner plusieures opérations d'écriture et de lecture en une seule commande. Elle seront exécutées et affichées dans l'ordre: +Vous pouvez combiner plusieurs opérations d'écriture et de lecture en une seule commande. Elles seront exécutées et affichées dans l'ordre: ``` $ qmk config compile default.keymap=default compile.keymap=None diff --git a/docs/fr-FR/contributing.md b/docs/fr-FR/contributing.md index 6d6889b018..0092d664ef 100644 --- a/docs/fr-FR/contributing.md +++ b/docs/fr-FR/contributing.md @@ -2,7 +2,7 @@ 👍🎉 Premièrement, merci de prendre le temps de lire ceci et de contribuer! 🎉👍 -Les contributions de tiers nous aide à améliorer et faire grandir QMK. Nous voulons rendre les pull requests et le processus de contribution utile et simple à la fois pour les contributeurs et les mainteneurs. C'est pourquoi nous avons mis en places des directives pour les contibuteurs afin que votre pull request puisse être accepté sans changement majeur. +Les contributions de tiers nous aide à améliorer et faire grandir QMK. Nous voulons rendre les pull requests et le processus de contribution utile et simple à la fois pour les contributeurs et les mainteneurs. C'est pourquoi nous avons mis en places des directives pour les contributeurs afin que votre pull request puisse être accepté sans changement majeur. * [Aperçu du projet](#project-overview) * [Conventions de codage](#coding-conventions) @@ -38,7 +38,7 @@ Vous n'avez encore jamais contribué à un projet open source? Vous vous demande 0. Enregistrez-vous sur [GitHub](https://github.com). 1. Définissez une keymap à contribuer, [trouvez une issue](https://github.com/qmk/qmk_firmware/issues) que vous souhaitez corriger, ou [une fonction](https://github.com/qmk/qmk_firmware/issues?q=is%3Aopen+is%3Aissue+label%3Afeature) que vous voulez ajouter. 2. Créez un fork sur le dépôt associé avec une issue sur votre compte GitHub. Cela veut dire que vous allez avoir une copie du dépôt sous `votre-login-GitHub/qmk_firmware`. -3. Clonez le dépôt sur votre macine locale en utilisant `git clone https://github.com/login-github/repository-name.git`. +3. Clonez le dépôt sur votre machine locale en utilisant `git clone https://github.com/login-github/repository-name.git`. 4. Si vous travaillez sur une nouvelle fonctionnalité, pensez à ouvrir une issue pour parler avec nous du travail que vous souhaitez démarrer. 5. Créez une nouvelle branche pour votre correctif en utilisant `git checkout -b nom-de-branche`. 6. Faites les changements nécessaires pour corriger le problème ou ajouter la fonctionnalité. @@ -69,7 +69,7 @@ Nous avons un certain nombre de type de changements dans QMK, chacun nécessitan * Keymaps: Assurez-vous que `make keyboard:your_new_keymap` ne renvoie pas d'erreur. * Claviers: Assurez-vous que `make keyboard:all` ne renvoie pas d'erreur. * Core: Assurez-vous que `make all` ne renvoie pas d'erreur. -* Assurez-vous que les messages de commit soient compréhensibles d'eux-même. Vous devriez écrire une description simple (pas plus de 70 caractères) sur la première ligne, suivi d'une ligne vide, suivi d'un détail de votre commit, si nécessaire. Exemple: +* Assurez-vous que les messages de commit soient compréhensibles d'eux-mêmes. Vous devriez écrire une description simple (pas plus de 70 caractères) sur la première ligne, suivi d'une ligne vide, suivi d'un détail de votre commit, si nécessaire. Exemple: ``` Adjust the fronzlebop for the kerpleplork @@ -81,11 +81,11 @@ Limited experimentation on the devices I have available shows that 7 is high eno ## Documentation -La documentation est l'une des manière les plus simples de démarrer la contribution sur QMK. Il est simple de trouver des endroits où la documentation est fausse ou incomplète, et il est tout aussi simple de la corriger! Nous avons aussi grandement besoin de quelqu'un pour éditer notre documentation, donc si vous avez des compétences en édition mais que vous n'êtes pas sûr de savoir où aller, n'hésitez pas [demandez de l'aide](#where-can-i-go-for-help)! +La documentation est l'une des manières les plus simples de démarrer la contribution sur QMK. Il est simple de trouver des endroits où la documentation est fausse ou incomplète, et il est tout aussi simple de la corriger! Nous avons aussi grandement besoin de quelqu'un pour éditer notre documentation, donc si vous avez des compétences en édition mais que vous n'êtes pas sûr de savoir où aller, n'hésitez pas [demandez de l'aide](#where-can-i-go-for-help)! Vous trouverez toute notre documentation dans le répertoire `qmk_firmware/docs`, ou si vous préférez utiliser des outils web, vous pouvez cliquer sur le bouton "Suggest An Edit" en haut de chaque page sur http://docs.qmk.fm/. -Lorsque vous donnez des exemples de code dans la documentation, essayez de suivre les conventions de nommage utilisées ailleurs dnas la documentation. Par exemple, standardisez les enums en utilisant `my_layers` ou `my_keycodes` afin de garder une consistance: +Lorsque vous donnez des exemples de code dans la documentation, essayez de suivre les conventions de nommage utilisées ailleurs dans la documentation. Par exemple, standardisez les enums en utilisant `my_layers` ou `my_keycodes` afin de garder une consistance: ```c enum my_layers { @@ -129,16 +129,16 @@ Faites attention d'être sûr d'implémenter votre nouvelle fonctionnalité de l * [Chat sur Discord](https://discord.gg/Uq7gcHh) * [Ouvrir une Issue](https://github.com/qmk/qmk_firmware/issues/new) -Les PR de nouvelles fonctionnalités de de correction de bug affectent tous les claviers. Nous sommes aussi dans un processus de restructuration de QMK. Pour cette raison, il est absolument nécessaire que tout changement important ou significatif soit discuté avant que l'implémentation soit faite. Si vous ouvrez un PR sans nous avoir parlé, préparez vous à faire des refontes significatives si vous changements ne sont pas compatibles avec ce que nous avons planifié. +Les PR de nouvelles fonctionnalités de de correction de bug affectent tous les claviers. Nous sommes aussi dans un processus de restructuration de QMK. Pour cette raison, il est absolument nécessaire que tout changement important ou significatif soit discuté avant que l'implémentation soit faite. Si vous ouvrez un PR sans nous avoir parlé, préparez-vous à faire des refontes significatives si vos changements ne sont pas compatibles avec ce que nous avons planifié. Voici quelques choses à garder en tête lorsque vous travaillez sur une fonctionnalité ou un bug fix. -* **Désactivé par défaut** - la mémoire est plutôt limitée sur la plupart des puces que QMK supporte, et il est important que les keymaps courantes ne soient pas cassées. S'il vous plaît faites que vos features doivent être **activées** plutôt que désactivées. Si vous pensez qu'elle devrait être activée par défaut, ou que cela réduit la taille du code, parlez-nous en. +* **Désactivé par défaut** - la mémoire est plutôt limitée sur la plupart des puces que QMK supporte, et il est important que les keymaps courantes ne soient pas cassées. S'il vous plaît faites que vos features doivent être **activées** plutôt que désactivées. Si vous pensez qu'elle devrait être activée par défaut, ou que cela réduit la taille du code, parlez-nous-en. * **Compilez localement avant de soumettre** - Cela devrait aller sans dire, mais votre code doit compiler! Notre système Travis devrait relever les problèmes, mais il est généralement plus rapide de compiler quelques claviers en local plutôt que d'attendre le retour des résultats * **Faites attention aux révisions et différentes bases de puces** - beaucoup de claviers ont des révisions qui permettent des changements de configuration mineurs, voir des bases de chip différentes. Essayez de faire que votre fonctionnalité soit supportée à la fois sur ARM et AVR, ou désactivez-là automatiquement sur les plateformes non supportées. * **Expliquez votre fonctionnalité** - Documentez-là dans `docs/`, soit dans un nouveau fichier, ou dans une partie d'un fichier existant. Si vous ne la documentez pas, personne ne pourra bénéficier de votre dur labeur. -Nous vous demandons aussi de suivre ces ces directives: +Nous vous demandons aussi de suivre ces directives: * Gardez un nombre de commits raisonnable, ou nous squasherons votre PR. * Ne regroupez pas des claviers ou des keymaps avec des changements core. Soumettez vos changements core en premier. @@ -151,4 +151,4 @@ Afin de maintenir une vision claire sur comment les choses sont architectuées d # Que veut dire le code de conduite pour moi? -Note [Code De Conduite](https://github.com/qmk/qmk_firmware/blob/master/CODE_OF_CONDUCT.md) veut dire que vous avez la responsabilité de traiter tout le monde dans le projet avec respect et courtoisie, peut importe leur identité. Si vous êtes victime d'une attitude ou de commentaires inapropriés, tels que décrit dans notre Code de Conduite, nous sommes là pour vous et nous ferons de notre mieux pour nous assurer que le fautif soit réprimandé, tel que décrit dans notre code. +Note [Code De Conduite](https://github.com/qmk/qmk_firmware/blob/master/CODE_OF_CONDUCT.md) veut dire que vous avez la responsabilité de traiter tout le monde dans le projet avec respect et courtoisie, peu importe leur identité. Si vous êtes victime d'une attitude ou de commentaires inappropriés, tels que décrit dans notre Code de Conduite, nous sommes là pour vous et nous ferons de notre mieux pour nous assurer que le fautif soit réprimandé, tel que décrit dans notre code. diff --git a/docs/fr-FR/flashing.md b/docs/fr-FR/flashing.md index 1aa04af5ff..c380614a5d 100644 --- a/docs/fr-FR/flashing.md +++ b/docs/fr-FR/flashing.md @@ -1,6 +1,6 @@ # Instructions pour flasher et informations sur les bootloader -Les claviers utilisent différents types de bootloaders et certains doivent être flashés différement. Heureusement, certains projets comme la [QMK Toolbox](https://github.com/qmk/qmk_toolbox/releases) ont pour objectifs de permettre de flasher les différents bootloader sans trop se faire de soucis et ça peut importe les manières de les flasher. +Les claviers utilisent différents types de bootloaders et certains doivent être flashés différement. Heureusement, certains projets comme la [QMK Toolbox](https://github.com/qmk/qmk_toolbox/releases) ont pour objectifs de permettre de flasher les différents bootloader sans trop se faire de soucis et ça peu importe les manières de les flasher. Si vous avez un bootloader sélectionné avec la variable `BOOTLOADER` dans votre fichier `rules.mk` alors QMK vas automatiquement calculer si votre fichier .hex n'est pas trop grand pour être flashé sur votre appareil, et il affichera la taille finale du firmware. Pour vérifier la taille manuellement, vous pouvez aussi compiler le firmware avec l'option `check-size`. Exemple : `make planck/rev4:default:check-size`. @@ -49,7 +49,7 @@ QMK a un fork du bootloader LUFA DFU qui vous permet de faire un simple scan de #define QMK_LED E6 #define QMK_SPEAKER C6 -Le fabriquant et le nom du produit proviennent de vos définitions dans fichier `config.h`, et la chaîne de caractère « bootloader » est ajoutée au nom du prodruit. +Le fabricant et le nom du produit proviennent de vos définitions dans fichier `config.h`, et la chaîne de caractère « bootloader » est ajoutée au nom du produit. Pour génerer le bootloader, utilisez la cible `bootloader`. Exemple : `make planck/rev4:default:bootloader`. @@ -66,7 +66,7 @@ Il y a plusieurs commandes DFU que vous pouvez utiliser pour flasher le firmware ## Caterina -Les cartes arduinos et leurs clones utilisent le [bootloader Caterina](https://github.com/arduino/ArduinoCore-avr/tree/master/bootloaders/caterina) (tous les claviers utilisant un Pro Micro, ou un clone). Ils utilisent aussi le protocole avr109 pour communiquer en virtuellement en série (serial en Anglais). Les bootloaders comme le [A-Star](https://www.pololu.com/docs/0J61/9) sont basés sur Caterina. +Les cartes arduinos et leurs clones utilisent le [bootloader Caterina](https://github.com/arduino/ArduinoCore-avr/tree/master/bootloaders/caterina) (tous les claviers utilisant un Pro Micro, ou un clone). Ils utilisent aussi le protocole avr109 pour communiquer en virtuellement en série (serial en anglais). Les bootloaders comme le [A-Star](https://www.pololu.com/docs/0J61/9) sont basés sur Caterina. Pour vérifier la compatibilité avec un bootloader Caterina, vérifiez que ce bloc est présent dans votre fichier `rules.mk` : @@ -84,8 +84,8 @@ BOOTLOADER = caterina Flashers compatibles : -* [QMK Toolbox](https://github.com/qmk/qmk_toolbox/releases) (Interface graphique recomandée) -* [avrdude](http://www.nongnu.org/avrdude/) avec avr109 / `:avrdude` (Outil en ligne de commande recomandé) +* [QMK Toolbox](https://github.com/qmk/qmk_toolbox/releases) (Interface graphique recommandée) +* [avrdude](http://www.nongnu.org/avrdude/) avec avr109 / `:avrdude` (Outil en ligne de commande recommandé) * [AVRDUDESS](https://github.com/zkemble/AVRDUDESS) Séquence de flash : @@ -172,7 +172,7 @@ Séquence de flash : ## BootloadHID -BootloadHID est un bootloader pour les microcontroleurs AVR. L'utilitaire de téleversement ne demande pas de drivers au niveau du kernel et peut être lancé sans installer aucune DLLs. +BootloadHID est un bootloader pour les microcontrôleurs AVR. L'utilitaire de téleversement ne demande pas de drivers au niveau du kernel et peut être lancé sans installer aucune DLLs. Pour vérifier la compatibilité avec le bootloader bootloadHID, vérifiez que ce bloc existe dans votre fichier `rules.mk` : @@ -197,7 +197,7 @@ Séquence de flash 1. Entrez dans le bootloader en utilisant l'une de ces méthodes : * Pressez la touche du keycode `RESET` (Cela ne fonctionnera pas sur certains appareils). - * Verouillez la touche « Salt » tout en branchant le clavier (Géneralement ce principe est documenté dans le fichier readme du clavier) + * Verrouillez la touche « Salt » tout en branchant le clavier (Généralement ce principe est documenté dans le fichier readme du clavier) 2. Attendez que l'OS détecte l'appareil. 3. Flasher le fichier .hex. 4. Redémarrez l'appareil en mode « application ». Cela peut être fait automatiquement. @@ -227,13 +227,13 @@ Séquence pour flasher: 3. Flasher un fichier `.bin`.h * Vous allez recevoir un avertissement à propos de la signature DFU. Ignorez-la. 4. Réinitialisez l'appareil en mode « application ». Cela peut être fait automatiquement. - * Si vous êtes en train de travailler en ligne de commande, par exemple avec un `make planck/rev6:default:dfu-util` alors soyez bien sur que l'argument `:leave` est passé aux argument DFU grâce à la variable `DFU_ARGS` à l'intérieur de votre fichier `rules.mk` (Ex : `DFU_ARGS = -d 0483:df11 -a 0 -s 0x08000000:leave`) afin que votre appareil redémarre après avoir été flashé. + * Si vous êtes en train de travailler en ligne de commande, par exemple avec un `make planck/rev6:default:dfu-util` alors soyez bien sur que l'argument `:leave` est passé aux arguments DFU grâce à la variable `DFU_ARGS` à l'intérieur de votre fichier `rules.mk` (Ex : `DFU_ARGS = -d 0483:df11 -a 0 -s 0x08000000:leave`) afin que votre appareil redémarre après avoir été flashé. ### Commandes STM32 Il y a différentes commandes que vous pouvez utiliser pour flasher un firmware dans un appareil STM32 : * `:dfu-util` - C'est l'option standard pour flasher un appareil STM32. Le script attendra qu'un bootloader STM32 soit présent. -* `:dfu-util-split-left` - Permet de flasher un firmware normalement, tout comme l'option précedente mais permet de configurer le coté gauche des paramètres EEPROM sur un clavier scindé. -* `:dfu-util-split-right` - Permet de flasher un firmware normalement, tout comme l'option précedente mais permet de configurer le coté droit des paramètres EEPROM sur un clavier scindé. +* `:dfu-util-split-left` - Permet de flasher un firmware normalement, tout comme l'option précédente mais permet de configurer le côté gauche des paramètres EEPROM sur un clavier scindé. +* `:dfu-util-split-right` - Permet de flasher un firmware normalement, tout comme l'option précédente mais permet de configurer le côté droit des paramètres EEPROM sur un clavier scindé. * `:st-link-cli` - Cela permet de flasher le firmware avec l'utilitaire en ligne de commande ST-LINK's plutôt que d'utiliser dfu-util. diff --git a/docs/fr-FR/getting_started_getting_help.md b/docs/fr-FR/getting_started_getting_help.md index 5eaf519751..fedb18c76c 100644 --- a/docs/fr-FR/getting_started_getting_help.md +++ b/docs/fr-FR/getting_started_getting_help.md @@ -4,7 +4,7 @@ Il y a beaucoup de ressources pour trouver de l'aide avec QMK. ## Chat temps-réel -Vous trouverez des développeurs QMK et des utilisateurs sur notre [Serveur Discord](https://discord.gg/Uq7gcHh) principal. Il y a des canaux spécifiques dans le serveurs pour discuter des firmware, toolbox, hardware et configurateurs. +Vous trouverez des développeurs QMK et des utilisateurs sur notre [Serveur Discord](https://discord.gg/Uq7gcHh) principal. Il y a des canaux spécifiques dans le serveur pour discuter des firmwares, toolbox, hardware et configurateurs. ## Sous-Reddit OLKB @@ -12,4 +12,4 @@ Le forum officiel de QMK est [/r/olkb](https://reddit.com/r/olkb) sur [reddit.co ## Tickets GitHub -Vous pouvez ouvrir un [ticket sur GitHub](https://github.com/qmk/qmk_firmware/issues). Ceci est spécialement pratique lorsque votre problème demande une discussion long terme ou un débugage. +Vous pouvez ouvrir un [ticket sur GitHub](https://github.com/qmk/qmk_firmware/issues). Ceci est spécialement pratique lorsque votre problème demande une discussion sur le long terme ou un débugage. diff --git a/docs/fr-FR/getting_started_github.md b/docs/fr-FR/getting_started_github.md index 32a68d0cab..22c6ee749b 100644 --- a/docs/fr-FR/getting_started_github.md +++ b/docs/fr-FR/getting_started_github.md @@ -8,11 +8,11 @@ Commencez par la [page GitHub de QMK](https://github.com/qmk/qmk_firmware), et v  -Si vous faites partie d'une organisation, vous aurez besoin de savoir quel compte utiliser pour le fork. Dans la plupart des cas, vous voudrez créer le fork dans votre compte personnel. Une fois le fork complet (cela peut quelque fois prendre un peu de temps), appuyez sur le bouton "Clone or download": +Si vous faites partie d'une organisation, vous aurez besoin de savoir quel compte utiliser pour le fork. Dans la plupart des cas, vous voudrez créer le fork dans votre compte personnel. Une fois le fork complet (cela peut quelques fois prendre un peu de temps), appuyez sur le bouton "Clone or download":  -Faites attention à sélectionner "HTTPS", et sélectionnez le liens et copiez-le: +Faites attention à sélectionner "HTTPS", et sélectionnez le lien et copiez-le:  @@ -48,7 +48,7 @@ To https://github.com/whoeveryouare/qmk_firmware.git + 20043e64...7da94ac5 master -> master ``` -Vos changements existent maintenant dans votre fork sur GitHub. Si vous allez à cete adresse (`https://github.com/<whoeveryouare>/qmk_firmware`), vous pouvez créer un nouveau "Pull Request" en cliquant sur ce bouton: +Vos changements existent maintenant dans votre fork sur GitHub. Si vous allez à cette adresse (`https://github.com/<whoeveryouare>/qmk_firmware`), vous pouvez créer un nouveau "Pull Request" en cliquant sur ce bouton:  diff --git a/docs/fr-FR/getting_started_introduction.md b/docs/fr-FR/getting_started_introduction.md index b64a7728f6..a7f0ff96af 100644 --- a/docs/fr-FR/getting_started_introduction.md +++ b/docs/fr-FR/getting_started_introduction.md @@ -43,7 +43,7 @@ Le fichier `config.h` peut être mis à 3 endroits: * userspace (`/users/<user>/config.h`) * keymap (`/keyboards/<keyboard>/keymaps/<keymap>/config.h`) -Le système de compilation cherche automatiquement les fichiers de configuration dans l'ordre au dessus. Si vous souhaitez surcharger une configuration définie par un `config.h` précédent, vous devrez d'abord ajouter le code suivant. +Le système de compilation cherche automatiquement les fichiers de configuration dans l'ordre au-dessus. Si vous souhaitez surcharger une configuration définie par un `config.h` précédent, vous devrez d'abord ajouter le code suivant. ``` #pragma once @@ -51,7 +51,7 @@ Le système de compilation cherche automatiquement les fichiers de configuration Ensuite, pour surcharger l'option du fichier `config.h` précédent, vous devez `#undef` puis `#define` l'option à nouveau. -Voici à quoi l'ensemble du code resemble une fois regroupé: +Voici à quoi l'ensemble du code ressemble une fois regroupé: ``` #pragma once diff --git a/docs/fr-FR/newbs_best_practices.md b/docs/fr-FR/newbs_best_practices.md index c0e76b1c96..1491013147 100644 --- a/docs/fr-FR/newbs_best_practices.md +++ b/docs/fr-FR/newbs_best_practices.md @@ -11,7 +11,7 @@ Ce document suppose les choses suivantes: ## La branche master de votre fork: Mettre à jour souvent, ne jamais commit -Il est hautement recommandé pour le développement de QMK, peu importe ce qui est fait ou où, de garder votre branche `master` à jour, mais de ne ***jamais*** commit dessus. A la place, faites tous vos changement dans une branche de développement et crééz des "pull requests" de votre branche lorsque vous développez. +Il est hautement recommandé pour le développement de QMK, peu importe ce qui est fait ou où, de garder votre branche `master` à jour, mais de ne ***jamais*** commit dessus. A la place, faites tous vos changements dans une branche de développement et crééz des "pull requests" de votre branche lorsque vous développez. Pour réduire les chances de conflits de fusion (merge) — des cas où deux ou plus d'utilisateurs ont édité la même section d'un fichier en parallèle — gardez votre branche `master` relativement à jour et démarrez chaque nouveau développement en créant une nouvelle branche. @@ -44,7 +44,7 @@ git pull upstream master git push origin master ``` -Cela vous change la branche courante en master, synchronise les données de réferences du dépôt QMK vers votre ordinateur. La commande pull tire les données de réferences vers votre branche courante puis les y téleverse. La commande push permet de pousser la branche courante (master) vers votre fork github. +Cela vous change la branche courante en master, synchronise les données de références du dépôt QMK vers votre ordinateur. La commande pull tire les données de références vers votre branche courante puis les y téleverse. La commande push permet de pousser la branche courante (master) vers votre fork github. ### Faire des changements @@ -55,11 +55,11 @@ git checkout -b dev_branch git push --set-upstream origin dev_branch ``` -Ceci crée une branche nommée `dev_branch`, bascule vers cette branche, et ensuite sauvegarde cette nouvelle branche vers votre fork. L'argument `--set-upstream` demande à git d'utiliser votre fork et la branche `dev_branch` à chaque fois que vous utilisez `git push` ou `git pull` depuis cette branche. Vous ne devez l'utiliser que pour le premier "push", après celà, vous pouvez utiliser simplement `git push` ou `git pull`, sans le reste des arguments. +Ceci crée une branche nommée `dev_branch`, bascule vers cette branche, et ensuite sauvegarde cette nouvelle branche vers votre fork. L'argument `--set-upstream` demande à git d'utiliser votre fork et la branche `dev_branch` à chaque fois que vous utilisez `git push` ou `git pull` depuis cette branche. Vous ne devez l'utiliser que pour le premier "push", après cela, vous pouvez utiliser simplement `git push` ou `git pull`, sans le reste des arguments. !> Avec `git push`, vous pouvez utiliser `-u` à la place de `--set-upstream` — `-u` est un alias pour `--set-upstream`. -Vous pouvez appeler votre branche à peu prêt comme vous voulez, toutefois il est recommandé d'utiliser un nom qui est lié aux changements que vous allez faire. +Vous pouvez appeler votre branche à peu près comme vous voulez, toutefois il est recommandé d'utiliser un nom qui est lié aux changements que vous allez faire. Par défaut, `git checkout -b` va faire de la branche actuelle la branche de base de votre nouvelle branche. Vous pouvez définir la base de votre nouvelle branche comme étant n'importe quelle branche existante qui n'est pas la courante en utilisant la commande: @@ -76,11 +76,11 @@ git commit -m "My commit message." `git add` ajoute les fichiers qui ont été changés dans la *zone de staging* de Git, qui est sa "zone de chargement". Elle contient tous les changements qui vont être *validés* (committed) par `git commit`, qui sauvegarde les changements vers le dépôt. Utilisez des messages de validation descriptifs afin que vous puissiez savoir ce qui a changé d'un coup d'oeil. -!> Si vous changez beaucoup de fichiers, mais tous les fichiers font partie du même changement, vous pouvez utiliser `git add .` pour ajouter tous les fichiers changés dans le répertoire courant, plutôt que d'avoir à ajouter chaque fichiers individuellement. +!> Si vous changez beaucoup de fichiers, mais tous les fichiers font partie du même changement, vous pouvez utiliser `git add .` pour ajouter tous les fichiers changés dans le répertoire courant, plutôt que d'avoir à ajouter chaque fichier individuellement. ### Publier Vos Changements -La dernière étape est de pousser vos changements vers votre fork. pour se faire, entrez `git push`. Git publie maintenant l'état courant de `dev_branch` vers votre fork. +La dernière étape est de pousser vos changements vers votre fork. Pour ce faire, entrez `git push`. Git publie maintenant l'état courant de `dev_branch` vers votre fork. ## Résoudre Les Conflits De Merge @@ -112,7 +112,7 @@ Maintenant que l'état actuel de la branche courante et la branche upstream sont git rebase upstream/master ``` -Ceci dit à Git d'annuler les commits de la branche courrante puis de les réappliquer sur la branche master de QMK. +Ceci dit à Git d'annuler les commits de la branche courante puis de les réappliquer sur la branche master de QMK. ```bash $ git rebase upstream/master @@ -133,7 +133,7 @@ You can instead skip this commit: run "git rebase --skip". To abort and get back to the state before "git rebase", run "git rebase --abort". ``` -Ceci nous dit que nous avons un conflit de merge, et nous donne le nom du fichier en conflit. Ouvez le fichier conflictuel dans votre éditeur de texte et, quelque part dans le fichier, vous trouverez quelque chose comme ça: +Ceci nous dit que nous avons un conflit de merge, et nous donne le nom du fichier en conflit. Ouvrez le fichier conflictuel dans votre éditeur de texte et, quelque part dans le fichier, vous trouverez quelque chose comme ça: ```bash <<<<<<< HEAD diff --git a/docs/fr-FR/newbs_building_firmware_configurator.md b/docs/fr-FR/newbs_building_firmware_configurator.md index ea284c5059..577e5c80e9 100644 --- a/docs/fr-FR/newbs_building_firmware_configurator.md +++ b/docs/fr-FR/newbs_building_firmware_configurator.md @@ -20,11 +20,11 @@ Je vais le répéter, parce que c'est important !> **FAITES ATTENTION A UTILISER LA BONNE VERSION !** -Si votre clavier est annoncé comme fonctionnant grâce à QMK mais n'est pas dans la liste, il y a des chances que le développeur ne l'ait pas encore fait, ou que nous n'avons pas encore eu le temps de le merger. Ajoutez un problème (issue) sur [qmk_firmware](https://github.com/qmk/qmk_firmware/issues) demandant le support de votre clavier, s'il n'y a pas de [Pull Request](https://github.com/qmk/qmk_firmware/pulls?q=is%3Aopen+is%3Apr+label%3Akeyboard) ouvert pour lui. Il y a aussi des clavier alimentés par QMK qui sont sur le compte GitHub du fabriquant, il est bon de le vérifier aussi. +Si votre clavier est annoncé comme fonctionnant grâce à QMK mais n'est pas dans la liste, il y a des chances que le développeur ne l'ait pas encore fait, ou que nous n'avons pas encore eu le temps de le merger. Ajoutez un problème (issue) sur [qmk_firmware](https://github.com/qmk/qmk_firmware/issues) demandant le support de votre clavier, s'il n'y a pas de [Pull Request](https://github.com/qmk/qmk_firmware/pulls?q=is%3Aopen+is%3Apr+label%3Akeyboard) ouvert pour lui. Il y a aussi des claviers alimentés par QMK qui sont sur le compte GitHub du fabricant, il est bon de le vérifier aussi. ## Sélectionner la disposition de votre clavier -Choisissez la disposition (layout) qui représente le mieux la keymap que vous voulez créer. Certains clavier n'ont pas encore assez de dispositions ou des dispositions incorrectes. Ils seront supportés dans le future. +Choisissez la disposition (layout) qui représente le mieux la keymap que vous voulez créer. Certains claviers n'ont pas encore assez de dispositions ou des dispositions incorrectes. Ils seront supportés dans le future. ## Nom de la Keymap diff --git a/docs/fr-FR/newbs_flashing.md b/docs/fr-FR/newbs_flashing.md index 267cf3add9..c9849eb104 100644 --- a/docs/fr-FR/newbs_flashing.md +++ b/docs/fr-FR/newbs_flashing.md @@ -120,7 +120,7 @@ Checking file size of planck_rev5_xyverz.hex * File size is fine - 18574/28672 ``` -Une fois arrivé à ce stade, le script de compilation va checher le bootloader DFU toutes les 5 secondes. Il va répéter les messages suivants jusqu'à ce que l'appareil soit trouvé ou que vous l'annuliez. +Une fois arrivé à ce stade, le script de compilation va chercher le bootloader DFU toutes les 5 secondes. Il va répéter les messages suivants jusqu'à ce que l'appareil soit trouvé ou que vous l'annuliez. dfu-programmer: no device present. Error: Bootloader not found. Trying again in 5s. @@ -143,7 +143,7 @@ Une fois terminé, vous devrez mettre à zéro le contrôleur. Vous allez voir u >>> dfu-programmer atmega32u4 reset ``` -?> Si vous avez des soucis concerant ceci - comme par exemple `dfu-programmer: no device present` - merci de regarder [Foires Aux Questions de Compilation](faq_build.md). +?> Si vous avez des soucis concernant ceci - par exemple `dfu-programmer: no device present` - merci de regarder [Foires Aux Questions de Compilation](faq_build.md). #### Commandes DFU @@ -174,7 +174,7 @@ Checking file size of lets_split_rev2_xyverz.hex Detecting USB port, reset your controller now.............. ``` -Une fois ceci fait, réinitialisez votre board et le script va détecter et flasher le firmware. La sortie devrait ressember à quelque chose comme ça: +Une fois ceci fait, réinitialisez votre board et le script va détecter et flasher le firmware. La sortie devrait ressembler à quelque chose comme ça: ``` Detected controller on USB port at /dev/ttyS15 @@ -219,7 +219,7 @@ avrdude.exe: safemode: Fuses OK (E:CB, H:D8, L:FF) avrdude.exe done. Thank you. ``` -Si vous avez un soucis, essayez de faire ceci: +Si vous avez un souci, essayez de faire ceci: sudo make <my_keyboard>:<my_keymap>:avrdude @@ -267,7 +267,7 @@ Booting ### STM32 (ARM) -Pour la majorité des boards ARM (incluant les Proton C, Planck Rev 6, et Preonic Rev 3), lorsque vous êtes prêt à compiler et flasher votre firmware,ouvrez la fenêtre de terminal et lancez la commande de compilation: +Pour la majorité des boards ARM (incluant les Proton C, Planck Rev 6, et Preonic Rev 3), lorsque vous êtes prêt à compiler et flasher votre firmware, ouvrez la fenêtre de terminal et lancez la commande de compilation: make <my_keyboard>:<my_keymap>:dfu-util diff --git a/docs/fr-FR/newbs_getting_started.md b/docs/fr-FR/newbs_getting_started.md index 751fd0563a..8a8029fd14 100644 --- a/docs/fr-FR/newbs_getting_started.md +++ b/docs/fr-FR/newbs_getting_started.md @@ -2,19 +2,19 @@ Votre clavier d'ordinateur contient un processeur, proche de celui dans votre ordinateur. Ce processeur exécute un logiciel responsable de détecter les touches appuyées et envoie des rapports à propos de l'état du clavier lorsque les touches sont appuyées et relâchées. QMK prend le rôle de ce logiciel, détectant les appuis des boutons et passant cette information à l'ordinateur hôte. Lorsque vous construisez votre keymap customisée, vous créez l'équivalent d'un programme exécutable pour votre clavier. -QMK essaie de rendre les choses simples faciles, et les choses difficiles possibles. Vous n'avez pas à savoir programmer pour créer des keymaps puissantes - vous devez seulement suivre quelques rêgles de syntaxe simples. +QMK essaie de rendre les choses simples faciles, et les choses difficiles possibles. Vous n'avez pas à savoir programmer pour créer des keymaps puissantes - vous devez seulement suivre quelques règles de syntaxe simples. # Guide de démarrage Avant de pouvoir construire des keymaps, vous devez installer quelques logiciels et configurer votre environnement de compilation. Ceci n'a besoin d'être fait seulement une fois, peu importe le nombre de clavier pour lesquels vous compter compiler un firmware. -Si vous préférez une approche plus proche d'une interface graphique, considérez utiliser l'outil en ligne [QMK Configurator](https://config.qmk.fm). Référez vous à [Construire votre premier firmware en utilisant l'interface graphique en ligne](newbs_building_firmware_configurator.md). +Si vous préférez une approche plus proche d'une interface graphique, considérez utiliser l'outil en ligne [QMK Configurator](https://config.qmk.fm). Référez-vous à [Construire votre premier firmware en utilisant l'interface graphique en ligne](newbs_building_firmware_configurator.md). ## Logiciels à télécharger ### Editeur de texte -Vous allez avoir besoin d'un programme qui peut éditer et sauvegarder des fichier **plain text**. Si vous êtes sur Windows, vous pouvez utiliser notepad et sur Linux vous pouvez utiliser gedit. Ces deux options sont des éditeurs de texte simples mais fonctionnels. Sur macOS, faites attention avec l'application par défaut TextEdit: elle ne sauvegardera pas les fichiers en mode "plain text" sauf si vous sélectionnez explicitement _Make Plain Text_ à partir du menu _Format_. +Vous allez avoir besoin d'un programme qui peut éditer et sauvegarder des fichiers **plain text**. Si vous êtes sur Windows, vous pouvez utiliser notepad et sur Linux vous pouvez utiliser gedit. Ces deux options sont des éditeurs de texte simples mais fonctionnels. Sur macOS, faites attention avec l'application par défaut TextEdit: elle ne sauvegardera pas les fichiers en mode "plain text" sauf si vous sélectionnez explicitement _Make Plain Text_ à partir du menu _Format_. Vous pouvez aussi télécharger et installer un éditeur de texte dédié comme [Sublime Text](https://www.sublimetext.com/) ou [VS Code](https://code.visualstudio.com/). C'est probablement la meilleure solution peu importe la plateforme car ce sont des programmes conçus spécifiquement pour éditer du code. @@ -33,7 +33,7 @@ QMK Toolbox est un programme graphique optionnel pour Windows et macOS qui perme Nous avons essayé de rendre QMK aussi simple que possible à configurer. Vous avez uniquement à préparer votre environnment Linux ou Unix et laisser QMK installer le reste. -?> Si vous n'avez jamais travailé avec la lignde commande Linux/Unix, il y a un certain nombre de concepts basiques et de commandes que vous devriez apprendre. Ces ressources vous apprendrons suffisemment pour travailler avec QMK:<br> +?> Si vous n'avez jamais travaillé avec la ligne de commande Linux/Unix, il y a un certain nombre de concepts basiques et de commandes que vous devriez apprendre. Ces ressources vous apprendrons suffisemment pour travailler avec QMK:<br> [Commandes Linux à savoir](https://www.guru99.com/must-know-linux-commands.html)<br> [Commandes Unix de base](https://www.tjhsst.edu/~dhyatt/superap/unixcmd.html) @@ -49,7 +49,7 @@ Vous devez installer MSYS2 et Git. Vous devez installer Homebew. Suivez les instructions sur la [page de Homebrew](https://brew.sh). -Une fois Homebrew installé, continuez avec _Configurer QMK_. Dans cete étape, nous lancerons un script qui va installer d'autres paquets. +Une fois Homebrew installé, continuez avec _Configurer QMK_. Dans cette étape, nous lancerons un script qui va installer d'autres paquets. ### Linux diff --git a/docs/fr-FR/newbs_testing_debugging.md b/docs/fr-FR/newbs_testing_debugging.md index bc6aec668d..680d7644ed 100644 --- a/docs/fr-FR/newbs_testing_debugging.md +++ b/docs/fr-FR/newbs_testing_debugging.md @@ -4,7 +4,7 @@ Une fois votre clavier configuré avec un firmware custom, vous êtes prêt à l ## Tester -Tester votre clavier est normalement assez simple. Appuyez chaque touche de votre clavier et assurez vous qu'il envoie les touches auquel vous vous attendiez. Il existe même des programmes qui vous aideront à vérifier qu'aucune touche ne soit oubliée. +Tester votre clavier est normalement assez simple. Appuyez chaque touche de votre clavier et assurez-vous qu'il envoie les touches auquel vous vous attendiez. Il existe même des programmes qui vous aideront à vérifier qu'aucune touche ne soit oubliée. Note: ces programmes ne sont ni fournis ni approuvés par QMK. @@ -30,7 +30,7 @@ void keyboard_post_init_user(void) { ### Débuguer avec QMK Toolbox -Pour les plateformes compatibles, [QMK Toolbox](https://github.com/qmk/qmk_toolbox) peut être utilisé pour afficher les message de débugage pour votre clavier. +Pour les plateformes compatibles, [QMK Toolbox](https://github.com/qmk/qmk_toolbox) peut être utilisé pour afficher les messages de débugage pour votre clavier. ### Débuguer avec hid_listen @@ -47,9 +47,9 @@ Parfois, il est utile d'afficher des messages de débugage depuis votre [code cu Une fois fait, vous pouvez utiliser les fonctions print suivantes: * `print("string")`: Affiche une simple chaîne de caractères. -* `uprintf("%s string", var)`: Affiche une chaîne de caractères formattée. +* `uprintf("%s string", var)`: Affiche une chaîne de caractères formatée. * `dprint("string")` Affiche une chaîne de caractère simple, mais uniquement lorsque le mode debug est activé. -* `dprintf("%s string", var)`: Affiche une chaîne de caractère formattée, mais uniquement lorsque le mode debug est activé. +* `dprintf("%s string", var)`: Affiche une chaîne de caractère formatée, mais uniquement lorsque le mode debug est activé. ## Exemples de debugage |