Update keyboards/subatomic/config.h

Co-Authored-By: James Young <18669334+noroadsleft@users.noreply.github.com>

.gitignore

@@ -60,8 +60,8 @@ util/Win_Check_Output.txt
 
 # ignore image files
 *.png
-*.jpg
 *.gif
+*.jpg
 
 # Do not ignore MiniDox left/right hand eeprom files
 !keyboards/minidox/*.eep

common_features.mk

@@ -112,7 +112,7 @@ ifeq ($(strip $(RGBLIGHT_ENABLE)), yes)
     ifeq ($(strip $(RGBLIGHT_CUSTOM_DRIVER)), yes)
         OPT_DEFS += -DRGBLIGHT_CUSTOM_DRIVER
     else
-        SRC += ws2812.c
+        WS2812_DRIVER_REQUIRED = yes
     endif
 endif
 
@@ -176,7 +176,7 @@ endif
 
 ifeq ($(strip $(RGB_MATRIX_ENABLE)), WS2812)
     OPT_DEFS += -DWS2812
-    SRC += ws2812.c
+    WS2812_DRIVER_REQUIRED = yes
 endif
 
 ifeq ($(strip $(RGB_MATRIX_CUSTOM_KB)), yes)
@@ -262,6 +262,26 @@ ifneq ($(strip $(BACKLIGHT_ENABLE)), no)
     endif
 endif
 
+VALID_WS2812_DRIVER_TYPES := bitbang pwm spi i2c
+
+WS2812_DRIVER ?= bitbang
+ifeq ($(strip $(WS2812_DRIVER_REQUIRED)), yes)
+    ifeq ($(filter $(WS2812_DRIVER),$(VALID_WS2812_DRIVER_TYPES)),)
+        $(error WS2812_DRIVER="$(WS2812_DRIVER)" is not a valid WS2812 driver)
+    endif
+
+    ifeq ($(strip $(WS2812_DRIVER)), bitbang)
+        SRC += ws2812.c
+    else
+        SRC += ws2812_$(strip $(WS2812_DRIVER)).c
+    endif
+
+    # add extra deps
+    ifeq ($(strip $(WS2812_DRIVER)), i2c)
+        QUANTUM_LIB_SRC += i2c_master.c
+    endif
+endif
+
 ifeq ($(strip $(CIE1931_CURVE)), yes)
     OPT_DEFS += -DUSE_CIE1931_CURVE
     LED_TABLES = yes

docs/_langs.md

@@ -2,3 +2,4 @@
   - [:uk: English](/)
   - [:cn: 中文](/zh-cn/)
   - [:fr: Français](/fr-fr/)
+  - [:ru: Русский](/ru-ru/)

docs/_summary.md

@@ -98,6 +98,7 @@
   * [ISP Flashing Guide](isp_flashing_guide.md)
   * [ARM Debugging Guide](arm_debugging.md)
   * [I2C Driver](i2c_driver.md)
+  * [WS2812 Driver](ws2812_driver.md)
   * [GPIO Controls](internals_gpio_control.md)
   * [Proton C Conversion](proton_c_conversion.md)
 

docs/cli.md

@@ -69,6 +69,16 @@ There are some limitations to the local CLI compared to the global CLI:
 
 # CLI Commands
 
+## `qmk cformat`
+
+This command formats C code using clang-format. Run it with no arguments to format all core code, or pass filenames on the command line to run it on specific files.
+
+**Usage**:
+
+```
+qmk cformat [file1] [file2] [...] [fileN]
+```
+
 ## `qmk compile`
 
 This command allows you to compile firmware from any directory. You can compile JSON exports from <https://config.qmk.fm> or compile keymaps in the repo.
@@ -85,16 +95,6 @@ qmk compile <configuratorExport.json>
 qmk compile -kb <keyboard_name> -km <keymap_name>
 ```
 
-## `qmk cformat`
-
-This command formats C code using clang-format. Run it with no arguments to format all core code, or pass filenames on the command line to run it on specific files.
-
-**Usage**:
-
-```
-qmk cformat [file1] [file2] [...] [fileN]
-```
-
 ## `qmk config`
 
 This command lets you configure the behavior of QMK. For the full `qmk config` documentation see [CLI Configuration](cli_configuration.md).
@@ -125,14 +125,24 @@ This command examines your environment and alerts you to potential build or flas
 qmk doctor
 ```
 
-## `qmk list_keyboards`
+## `qmk json-keymap`
+
+Creates a keymap.c from a QMK Configurator export.
+
+**Usage**:
+
+```
+qmk json-keymap [-o OUTPUT] filename
+```
+
+## `qmk list-keyboards`
 
 This command lists all the keyboards currently defined in `qmk_firmware`
 
 **Usage**:
 
 ```
-qmk list_keyboards
+qmk list-keyboards
 ```
 
 ## `qmk new-keymap`

docs/coding_conventions_c.md

@@ -31,17 +31,17 @@ Here is an example for easy reference:
 ```c
 /* Enums for foo */
 enum foo_state {
-  FOO_BAR,
-  FOO_BAZ,
+    FOO_BAR,
+    FOO_BAZ,
 };
 
 /* Returns a value */
 int foo(void) {
-  if (some_condition) {
-    return FOO_BAR;
-  } else {
-    return -1;
-  }
+    if (some_condition) {
+        return FOO_BAR;
+    } else {
+        return -1;
+    }
 }
 ```
 

docs/config_options.md

@@ -310,13 +310,13 @@ This is a [make](https://www.gnu.org/software/make/manual/make.html) file that i
 Use these to enable or disable building certain features. The more you have enabled the bigger your firmware will be, and you run the risk of building a firmware too large for your MCU.
 
 * `BOOTMAGIC_ENABLE`
-  * Virtual DIP switch configuration(+1000)
+  * Virtual DIP switch configuration
 * `MOUSEKEY_ENABLE`
-  * Mouse keys(+4700)
+  * Mouse keys
 * `EXTRAKEY_ENABLE`
-  * Audio control and System control(+450)
+  * Audio control and System control
 * `CONSOLE_ENABLE`
-  * Console for debug(+400)
+  * Console for debug
 * `COMMAND_ENABLE`
   * Commands for debug and configuration
 * `COMBO_ENABLE`
@@ -348,7 +348,7 @@ Use these to enable or disable building certain features. The more you have enab
 * `NO_USB_STARTUP_CHECK`
   * Disables usb suspend check after keyboard startup. Usually the keyboard waits for the host to wake it up before any tasks are performed. This is useful for split keyboards as one half will not get a wakeup call but must send commands to the master.
 * `LINK_TIME_OPTIMIZATION_ENABLE`
-  = Enables Link Time Optimization (`LTO`) when compiling the keyboard.  This makes the process take longer, but can significantly reduce the compiled size (and since the firmware is small, the added time is not noticable).  However, this will automatically disable the old Macros and Functions features automatically, as these break when `LTO` is enabled.  It does this by automatically defining `NO_ACTION_MACRO` and `NO_ACTION_FUNCTION` 
+  = Enables Link Time Optimization (`LTO`) when compiling the keyboard.  This makes the process take longer, but can significantly reduce the compiled size (and since the firmware is small, the added time is not noticable).  However, this will automatically disable the old Macros and Functions features automatically, as these break when `LTO` is enabled.  It does this by automatically defining `NO_ACTION_MACRO` and `NO_ACTION_FUNCTION`
 
 ## USB Endpoint Limitations
 

docs/de/cli.md

@@ -0,0 +1,169 @@
+# QMK CLI (Kommandozeile)
+
+Diese Seite beschreibt die Einrichtung und den Umgang mit dem QMK CLI (Kommandozeile).
+
+# Übersicht
+
+Die QMK CLI vereinfacht das Zusammenbauen und Arbeiten mit QMK Tastaturen. Hier findest Du wichtige Befehle, um beispielsweise das Herunterladen und Kompilieren der QMK Firmware oder das Erstellen von Tastaturbelegungen (und vieles mehr) zu erleichtern.
+
+* [Globale CLI](#globale-cli)
+* [Lokale CLI](#lokale-cli)
+* [CLI-Befehle](#cli-befehle)
+
+# System-Anforderungen
+
+Die CLI benötigt Python 3.5 oder höher. Außerdem ist es nötig, die Packages laut [`requirements.txt`](https://github.com/qmk/qmk_firmware/blob/master/requirements.txt) zu installieren.
+
+# Globale CLI
+
+QMK bietet ein installierbares CLI, das Du zum Einrichten Deiner QMK Build-Umgebung verwenden kannst. Dieses ermöglicht Dir das Arbeiten mit QMK, und erleichtert das Arbeiten mit mehreren Kopien der `qmk_firmware`. Wir empfehlen, dieses CLI zu installieren und regelmäßig upzudaten.
+
+## Installation mit Homebrew (macOS, manche Linux)
+
+Solltest Du [Homebrew](https://brew.sh) installiert haben, kannst Du QMK per tap installieren:
+
+```
+brew tap qmk/qmk
+brew install qmk
+export QMK_HOME='~/qmk_firmware' # Optional: setzt den Installationsort für `qmk_firmware`
+qmk setup  # Dies klont `qmk/qmk_firmware` und richtet optional auch Deine Build-Umgebung ein
+```
+
+## Installation mit easy_install oder pip
+
+Falls Du kein Homebrew hast, kannst Du QMK auch manuell installieren. Zuerst musst Du sicherstellen, dass Python 3.5 (oder höher) und pip installiert ist. Dann installiere QMK mit diesem Befehl:
+
+```
+pip3 install qmk
+export QMK_HOME='~/qmk_firmware' # Optional: setzt den Installationsort für `qmk_firmware`
+qmk setup  # Dies klont `qmk/qmk_firmware` und richtet optional auch Deine Build-Umgebung ein
+```
+## Installation mit git Repo
+
+`git clone https://github.com/qmk/qmk_cli.git && cd qmk_cli && python3 setup.py install`
+
+## Packaging für andere Betriebssysteme
+
+Wir suchen nach Freiwilligen, die ein `qmk`-Package für weitere Betriebssysteme erstellen und pflegen. Falls Du ein Package für Dein OS erstellen möchtest, bitte befolge diese Richtlinien:
+
+* Verwende "Best Practices" für Dein OS, sollten sie mit diesen Richtlinien in Konflikt stehen.
+    * Dokumentiere den Grund in einem Kommentar, wenn Du abweichen musstest.
+* Installiere mit einem [virtualenv](https://virtualenv.pypa.io/en/latest/).
+* Weise den User an, die Umgebungs-Variable `QMK_HOME` zu setzen, um die Firmware-Quelle anders einzustellen als `~/qmk_firmware`.
+
+# Lokale CLI
+
+Wenn Du die globale CLI nicht verwenden möchtest, beinhaltet `qmk_firmware` auch eine lokale CLI. Du kannst sie hier finden: `qmk_firmware/bin/qmk`. Du kannst den `qmk`-Befehl aus irgendeinem Datei-Verzeichnis ausführen und es wird immer auf dieser Kopie von `qmk_firmware` arbeiten.
+
+**Beispiel**:
+
+```
+$ ~/qmk_firmware/bin/qmk hello
+Ψ Hello, World!
+```
+
+## Einschränkungen der lokalen CLI
+
+Hier ein Vergleich mit der globalen CLI:
+
+* Die lokale CLI unterstützt kein `qmk setup` oder `qmk clone`.
+* Die lokale CLI arbeitet immer innerhalb der selben `qmk_firmware`-Verzeichnisstruktur, auch wenn Du mehrere Repositories geklont hast.
+* Die lokale CLI läuft nicht in einer virtualenv. Daher ist es möglich, dass Abhängigkeiten (dependencies) miteinander in Konflikt kommen/stehen.
+
+# CLI-Befehle
+
+## `qmk compile`
+
+Dieser Befehl erlaubt es dir, die Firmware - aus egal welchem Datei-Verzeichnis - zu compilen. Du kannst JSON-Exporte von <https://config.qmk.fm> oder Keymaps in der Repo kompilen.
+
+**Anwendung für Konfigurations-Exports**:
+
+```
+qmk compile <configuratorExport.json>
+```
+
+**Anwendung für Keymaps**:
+
+```
+qmk compile -kb <keyboard_name> -km <keymap_name>
+```
+
+## `qmk cformat`
+
+Dieser Befehl formatiert C-Code im clang-Format. Benutze ihn ohne Argumente, um den core-Code zu formatieren, oder benutze Namen von Dateien in der CLI, um den Befehl auf bestimmte Dateien anzuwenden.
+
+**Anwendung**:
+
+```
+qmk cformat [file1] [file2] [...] [fileN]
+```
+
+## `qmk config`
+
+Dieser Befehl konfiguriert das Verhalten von QMK. Für die volle `qmk config`-Dokumentation gehe zu [CLI-Konfiguration](cli_configuration.md).
+
+**Anwendung**:
+
+```
+qmk config [-ro] [config_token1] [config_token2] [...] [config_tokenN]
+```
+
+## `qmk docs`
+
+Dieser Befehl startet einen lokalen HTTP-Server, den Du zum Browsen oder Verbessern der Dokumentation verwenden kannst. Der Default-Port ist 8936.
+
+**Anwendung**:
+
+```
+qmk docs [-p PORT]
+```
+
+## `qmk doctor`
+
+Dieser Befehl untersucht Deine Umgebung und warnt Dich vor potentiellen Build- oder Flash-Problemen.
+
+**Anwendung**:
+
+```
+qmk doctor
+```
+
+## `qmk list-keyboards`
+
+Dieser Befehl listet alle zurzeit in `qmk_firmware` definierten Tastaturen/Keyboards auf.
+
+**Anwendung**:
+
+```
+qmk list-keyboards
+```
+
+## `qmk new-keymap`
+
+Dieser Befehl erstellt eine neue Keymap basierend auf einer existierenden Standard-Keymap eines bestimmten Keyboards.
+
+**Anwendung**:
+
+```
+qmk new-keymap [-kb KEYBOARD] [-km KEYMAP]
+```
+
+## `qmk pyformat`
+
+Dieser Befehl formatiert Python-Code in `qmk_firmware`.
+
+**Anwendung**:
+
+```
+qmk pyformat
+```
+
+## `qmk pytest`
+
+Dieser Befehl führt die Python Test Suite aus. Wenn Du Python-Code veränderst, solltest Du sicherstellen, dass der Test erfolgreich ausgeführt wurde.
+
+**Anwendung**:
+
+```
+qmk pytest
+```

docs/driver_installation_zadig.md

@@ -2,9 +2,9 @@
 
 QMK presents itself to the host as a regular HID keyboard device, and as such requires no special drivers. However, in order to flash your keyboard on Windows, the bootloader device that appears when you reset the board often *does*.
 
-There are two notable exceptions: the Caterina bootloader, usually seen on Pro Micros, and the Halfkay bootloader shipped with PJRC Teensys, appear as a serial port and a generic HID device respectively, and so do not require a driver.
+There are two notable exceptions: the Caterina bootloader, usually seen on Pro Micros, and the HalfKay bootloader shipped with PJRC Teensys, appear as a serial port and a generic HID device respectively, and so do not require a driver.
 
-We recommend the use of the [Zadig](https://zadig.akeo.ie/) utility. If you have set up the development environment with Msys2 or WSL, the `qmk_install.sh` script will have asked if you want it to install the drivers for you.
+We recommend the use of the [Zadig](https://zadig.akeo.ie/) utility. If you have set up the development environment with MSYS2 or WSL, the `qmk_install.sh` script will have asked if you want it to install the drivers for you.
 
 ## Installation
 
@@ -31,7 +31,7 @@ Finally, unplug and replug the keyboard to make sure the new driver has been loa
 
 ## Recovering from Installation to Wrong Device
 
-If you find that you can no longer type with the keyboard, you may have installed the driver onto the keyboard itself instead of the bootloader. You can easily confirm this in Zadig - a healthy keyboard has the `HidUsb` driver installed on all of its interfaces:
+If you find that you can no longer type with the keyboard, you may have accidentally replaced the driver for the keyboard itself instead of for the bootloader. This can happen when the keyboard is not in the bootloader mode. You can easily confirm this in Zadig - a healthy keyboard has the `HidUsb` driver installed on all of its interfaces:
 
 ![A healthy keyboard as seen by Zadig](https://i.imgur.com/Hx0E5kC.png)
 
@@ -44,3 +44,5 @@ Right-click it and hit **Uninstall device**. Make sure to tick **Delete the driv
 ![The Device Uninstall dialog, with the "delete driver" checkbox ticked](https://i.imgur.com/aEs2RuA.png)
 
 Click **Action → Scan for hardware changes**. At this point, you should be able to type again. Double check in Zadig that the keyboard device(s) are using the `HidUsb` driver. If so, you're all done, and your board should be functional again!
+
+?> A full reboot of your computer may sometimes be necessary at this point, to get Windows to pick up the new driver.

docs/faq_keymap.md

@@ -95,13 +95,6 @@ Even worse, it is not recognized unless the keyboard's VID and PID match that of
 
 See [this issue](https://github.com/qmk/qmk_firmware/issues/2179) for detailed information.
 
-
-## Media Control Keys in Mac OSX
-#### KC_MNXT and KC_MPRV Does Not Work on Mac
-Use `KC_MFFD`(`KC_MEDIA_FAST_FORWARD`) and `KC_MRWD`(`KC_MEDIA_REWIND`) instead of `KC_MNXT` and `KC_MPRV`.
-See https://github.com/tmk/tmk_keyboard/issues/195
-
-
 ## Keys Supported in Mac OSX?
 You can know which keycodes are supported in OSX from this source code.
 

docs/feature_bluetooth.md

@@ -2,18 +2,18 @@
 
 ## Bluetooth Known Supported Hardware
 
-Currently Bluetooth support is limited to AVR based chips. For Bluetooth 2.1 Qmk has support for RN-42 HID Firmware and Bluefruit EZ Key the later of which is not produced anymore. For more recent BLE protocols currently only the Adafruit Bluefruit SPI friend is directly supported. BLE is needed to connect to iOS devices. Note iOS does not support Mouse Input.
+Currently Bluetooth support is limited to AVR based chips. For Bluetooth 2.1, QMK has support for RN-42 modules and the Bluefruit EZ-Key, the latter of which is not produced anymore. For more recent BLE protocols, currently only the Adafruit Bluefruit SPI Friend is directly supported. BLE is needed to connect to iOS devices. Note iOS does not support mouse input.
 
-|Board                                                           |Bluetooth Protocol          |Connection Type |Rules.mk                   |Bluetooth Chip|
+|Board                                                           |Bluetooth Protocol          |Connection Type |rules.mk                   |Bluetooth Chip|
 |----------------------------------------------------------------|----------------------------|----------------|---------------------------|--------------|
-|[Adafruit EzKey HID]("https://www.adafruit.com/product/1535")   |Bluetooth Classic           | UART           | BLUETOOTH = AdafruitEZKey |              |
-|Rover Networks RN-42 (Sparkfun Bluesmirf)                       |Bluetooth Classic           | UART           | BLUETOOTH = RN42          | RN-42        |
-|[Bluefruit LE SPI Friend](https://www.adafruit.com/product/2633)|Bluetooth Low Energy        | SPI            | BLUETOOTH = AdafruitBLE   | nRF5182      |
+|[Adafruit EZ-Key HID](https://www.adafruit.com/product/1535)   |Bluetooth Classic           | UART           |`BLUETOOTH = AdafruitEZKey` |              |
+|Roving Networks RN-42 (Sparkfun Bluesmirf)                       |Bluetooth Classic           | UART           |`BLUETOOTH = RN42`          | RN-42        |
+|[Bluefruit LE SPI Friend](https://www.adafruit.com/product/2633)|Bluetooth Low Energy        | SPI            |`BLUETOOTH = AdafruitBLE`   | nRF51822      |
 
 Not Supported Yet but possible:
 * [Bluefruit LE UART Friend](https://www.adafruit.com/product/2479). [Possible tmk implementation found in](https://github.com/tmk/tmk_keyboard/issues/514)
 * HC-05 boards flashed with RN-42 firmware. They apparently both use the CSR BC417 Chip. Flashing it with RN-42 firmware gives it HID capability.
-* [Sparkfun Bluetooth mate](https://www.sparkfun.com/products/14839)
+* Sparkfun Bluetooth Mate
 * HM-13 based boards
 
 ### Adafruit BLE SPI Friend

docs/feature_encoders.md

@@ -58,3 +58,11 @@ or `keymap.c`:
 ## Hardware
 
 The A an B lines of the encoders should be wired directly to the MCU, and the C/common lines should be wired to ground.
+
+## Encoder matrix
+
+You can also wire the C/common line through a diode (arrow towards the row) to each of the rows (or reading pin) in your matrix, and use as many encoders as you have rows (multiplied by the number of A/B lines you have hooked up). To do this, you can add this line to your `config.h` with all of the pins you use:
+
+```c
+#define ENCODERS_PAD_C { encoder1c, encoder2c }
+```

docs/feature_hd44780.md

@@ -2,7 +2,7 @@
 
 This is an integration of Peter Fleury's LCD library. This page will explain the basics. [For in depth documentation visit his page.](http://homepage.hispeed.ch/peterfleury/doxygen/avr-gcc-libraries/group__pfleury__lcd.html)
 
-You can enable support for HD44780 Displays by setting the `HD44780_ENABLE` flag in your keyboards `rules.mk` to yes. This will use about 400 KB of extra space.
+You can enable support for HD44780 Displays by setting the `HD44780_ENABLE` flag in your keyboards `rules.mk` to yes.
 
 ## Configuration
 
@@ -26,7 +26,7 @@ Uncomment the section labled HD44780 and change the parameters as needed.
 #define LCD_DATA3_PORT   LCD_PORT     //< port for 4bit data bit 3
 #define LCD_DATA0_PIN    4            //< pin for 4bit data bit 0
 #define LCD_DATA1_PIN    5            //< pin for 4bit data bit 1
-#define LCD_DATA2_PIN    6            //< pin for 4bit data bit 2 
+#define LCD_DATA2_PIN    6            //< pin for 4bit data bit 2
 #define LCD_DATA3_PIN    7            //< pin for 4bit data bit 3
 #define LCD_RS_PORT      LCD_PORT     //< port for RS line        
 #define LCD_RS_PIN       3            //< pin  for RS line        
@@ -39,14 +39,14 @@ Uncomment the section labled HD44780 and change the parameters as needed.
 
 Should you need to configure other properties you can copy them from `quantum/hd44780.h` and set them in your `config.h`
 
-## Usage 
+## Usage
 
 To initialize your display, call `lcd_init()` with one of these parameters:
 ````
 LCD_DISP_OFF             : display off
 LCD_DISP_ON              : display on, cursor off
 LCD_DISP_ON_CURSOR       : display on, cursor on
-LCD_DISP_ON_CURSOR_BLINK : display on, cursor on flashing 
+LCD_DISP_ON_CURSOR_BLINK : display on, cursor on flashing
 ````
 This is best done in your keyboards `matrix_init_kb` or your keymaps `matrix_init_user`.  
 It is advised to clear the display before use.  

docs/feature_split_keyboard.md

@@ -47,7 +47,7 @@ The 3 wires of the TRS/TRRS cable need to connect GND, VCC, and D0 (aka PDO or p
 
 The 4 wires of the TRRS cable need to connect GND, VCC, and SCL and SDA (aka PD0/pin 3 and PD1/pin 2, respectively) between the two Pro Micros. 
 
-The pull-up resistors may be placed on either half. It is also possible to use 4 resistors and have the pull-ups in both halves, but this is unnecessary in simple use cases.
+The pull-up resistors may be placed on either half. If you wish to use the halves independently, it is also possible to use 4 resistors and have the pull-ups in both halves.
 
 ![I2C wiring](https://i.imgur.com/Hbzhc6E.png)
 

docs/feature_terminal.md

@@ -1,6 +1,6 @@
 # Terminal
 
-> This feature is currently *huge* at 4400 bytes, and should probably only be put on boards with a lot of memory, or for fun.
+> This feature is currently *huge*, and should probably only be put on boards with a lot of memory, or for fun.
 
 The terminal feature is a command-line-like interface designed to communicate through a text editor with keystrokes. It's beneficial to turn off auto-indent features in your editor.
 
@@ -56,7 +56,7 @@ Outputs the last 5 commands entered
 1. help
 2. about
 3. keymap 0
-4. help 
+4. help
 5. flush-buffer
 ```
 

docs/feature_userspace.md

@@ -211,15 +211,7 @@ bool process_record_user(uint16_t keycode, keyrecord_t *record) {
             if ( (temp_mod | temp_osm) & MOD_MASK_SHIFT ) 
     #endif
             { // 
-                #if defined(__arm__)  // only run for ARM boards
-                    SEND_STRING(":dfu-util");
-                #elif defined(BOOTLOADER_DFU) // only run for DFU boards
-                    SEND_STRING(":dfu");
-                #elif defined(BOOTLOADER_HALFKAY) // only run for teensy boards
-                    SEND_STRING(":teensy");
-                #elif defined(BOOTLOADER_CATERINA) // only run for Pro Micros
-                    SEND_STRING(":avrdude");
-                #endif // bootloader options
+                SEND_STRING(":flash");
             }
             if ( (temp_mod | temp_osm) & MOD_MASK_CTRL) { 
                 SEND_STRING(" -j8 --output-sync"); 
@@ -244,7 +236,7 @@ endif
 
 This will add a new `KC_MAKE` keycode that can be used in any of your keymaps.  And this keycode will output `make <keyboard>:<keymap>`, making frequent compiling easier.  And this will work with any keyboard and any keymap as it will output the current boards info, so that you don't have to type this out every time.
 
-Also, holding `shift` will add the appropriate flashing command (`:dfu`, `:teensy`, `:avrdude`, `:dfu-util`) for a majority of keyboards.  Holding `control` will add some commands that will speed up compiling time by processing multiple files at once. 
+Also, holding Shift will add the flash target (`:flash`) to the command.  Holding Control will add some commands that will speed up compiling time by processing multiple files at once. 
 
 And for the boards that lack a shift key, or that you want to always attempt the flashing part, you can add `FLASH_BOOTLOADER = yes` to the `rules.mk` of that keymap.
 

docs/flashing.md

@@ -99,11 +99,16 @@ or
 
     make <keyboard>:<keymap>:avrdude
 
-or if you want to flash multiple boards, use the following command
 
-    make <keyboard>:<keymap>:avrdude-loop
+#### Caterina commands
+
+There are a number of DFU commands that you can use to flash firmware to a DFU device:
+
+* `:avrdude` - This is the normal option which waits until a Caterina device is available (by detecting a new COM port), and then flashes the firmware.
+* `:avrdude-loop` - This runs the same command as `:avrdude`, but after each device is flashed, it will attempt to flash again.  This is useful for bulk flashing. _This requires you to manually escape the loop by hitting Ctrl+C._
+* `:avrdude-split-left` - This flashes the normal firmware, just like the default option (`:avrdude`). However, this also flashes the "Left Side" EEPROM file for split keyboards. _This is ideal for Pro Micro based split keyboards._
+* `:avrdude-split-right` - This flashes the normal firmware, just like the default option (`:avrdude`). However, this also flashes the "Right Side" EEPROM file for split keyboards. _This is ideal for Pro Micro based split keyboards._
 
-When you're done flashing boards, you'll need to hit Ctrl + C or whatever the correct keystroke is for your operating system to break the loop.
 
 
 ## Halfkay
@@ -231,7 +236,7 @@ Flashing sequence:
 
 There are a number of DFU commands that you can use to flash firmware to a STM32 device:
 
-* `:dfu-util` - The default command for flashing to STM32 devices.
+* `:dfu-util` - The default command for flashing to STM32 devices, and will wait until an STM32 bootloader device is present.
 * `:dfu-util-split-left` - This flashes the normal firmware, just like the default option (`:dfu-util`). However, this also configures the "Left Side" EEPROM setting for split keyboards.
 * `:dfu-util-split-right` - This flashes the normal firmware, just like the default option (`:dfu-util`). However, this also configures the "Right Side" EEPROM setting for split keyboards.
 * `:st-link-cli` - This allows you to flash the firmware via ST-LINK's CLI utility, rather than dfu-util. 

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
 

docs/fr-FR/README.md

@@ -7,7 +7,7 @@
 [![Contributeurs Github](https://img.shields.io/github/contributors/qmk/qmk_firmware.svg)](https://github.com/qmk/qmk_firmware/pulse/monthly)
 [![Forks Github](https://img.shields.io/github/forks/qmk/qmk_firmware.svg?style=social&label=Fork)](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
 

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é.
 

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**:
 

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

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.

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 : 
@@ -99,11 +99,14 @@ ou, utilisez :
 
     make <keyboard>:<keymap>:avrdude
 
-ou, si vous vous voulez flasher plusieurs claviers, utilisez la commande suivante :
+#### Commandes Caterina 
 
-    make <keyboard>:<keymap>:avrdude-loop
+Il existe un certain nombre de commandes DFU que vous pouvez utiliser pour mettre à jour le firmware sur un périphérique DFU:
 
-Quand vous avez fini de flasher vos claviers, vous aurez besoin d'utiliser Ctrl + C ou alors la touche ayant la fonction similaire sur votre OS pour sortir de la boucle.
+* `: avrdude` - Il s’agit de l’option normale. Le script va attendre qu’un appareil Caterina soit disponible. Dès que c’est le cas, il flash le firmware. Il attendra de détecter un nouveau port COM pour le flasher.
+* `: avrdude-loop` - Cela fonctionne de la même manière que`: avrdude`, mais une fois que chaque périphérique est flashé, il tentera de flasher à nouveau. Cela peut être utile pour flasher plusieurs claviers à la suite. _Cela implique de sortir manuellement de la boucle en appuyant sur Ctrl + C, Cmd + C ou un raccourci équivalent selon votre OS_
+* `: avrdude-split-left` - Cela fonctionne de la même manière que la fonction (`: avrdude`). Toutefois, cela permet aussi de flasher le coté gauche de l'EEPROM des claviers splittés / divisés. C'est donc la méthode recommandée pour les claviers splittés avec Pro Micro.
+* `: avrdude-split-right` - Cela fonctionne de la même manière que la fonction (`: avrdude`). Toutefois, cela permet aussi de flasher le coté droite de l'EEPROM des claviers splittés / divisés. C'est donc la méthode recommandée pour les claviers splittés avec Pro Micro.
 
 ## Halfkay
 
@@ -169,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` : 
 
@@ -194,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.
@@ -224,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` - La commande par défaut pour flasher un appareil STM32.
-* `: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` - 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é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.

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.

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
 
 ![Fork on Github](http://i.imgur.com/8Toomz4.jpg)
 
-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":
 
 ![Download from Github](http://i.imgur.com/N1NYcSz.jpg)
 
-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:
 
 ![HTTPS link](http://i.imgur.com/eGO0ohO.jpg)
 
@@ -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:
 
 ![New Pull Request](http://i.imgur.com/DxMHpJ8.jpg)
 

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

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

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
 

docs/fr-FR/newbs_flashing.md

@@ -78,7 +78,23 @@ Appuyez sur le boutton `Flash` dans QMK Toolbox. Vous verrez un résultat simila
 
 ## Flashez votre clavier à l'aide de la ligne de commande
 
-La première chose que vous devez savoir c'est quel bootloader utilise votre clavier. Il y a quatre bootloaders principaux. Pro-Micro et les clones, utilisent CATERINA, les Teensy utilisent Halfkay, les OLKB utilisent QMK-DFU et les autres chips atmega32u4 utilisent DFU.
+C'est désormais relativement simple. Lorsque vous êtes prêt à compiler et à flasher votre firmware, ouvrez la fenêtre de votre terminal et exécutez la commande de build :
+
+    make <my_keyboard>:<my_keymap>:flash
+
+Par exemple, si votre keymap s'appelle "xyverz" et que vous fabriquez une keymap pour un clavier `planck` de version `rev5` vous devrez utiliser cette commande:
+
+    make planck/rev5:xyverz:flash
+
+La commande va vérifier la configuration du clavier, puis tentera de le flasher en fonction du bootloader (chargeur d’amorçage) spécifié. Cela signifie que vous n'avez pas besoin de savoir quel bootloader votre clavier utilise. Exécutez simplement la commande et laissez-le faire le gros du travail.
+
+Cependant, tout dépend du bootloader qui est installé sur le clavier. Si cette information n’est pas configurée ou si vous tentez de flasher un clavier qui ne permet pas d’être flashé alors vous obtiendrez cette erreur :
+
+    WARNING: This board's bootloader is not specified or is not supported by the ":flash" target at this time.
+
+Dans ce cas, vous devrez choisir le bootloader.
+
+Il y a cinq bootloaders principaux. Les Pro-Micro et les clones utilisent Caterina, les Teensy utilisent Halfkay, les claviers AVR d’OLKB utilisent QMK-DFU, certains controleurs atmega32u4 utilisent DFU et la plupart des controlleurs ARM utilisent ARM DFU.
 
 Vous pouvez trouver plus d'information à propos des bootloaders sur la page [Instructions de flash et information sur le Bootloader](flashing.md).
 
@@ -104,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.
@@ -127,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
 
@@ -158,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
@@ -203,15 +219,18 @@ 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
 
-En addition, si vous voulez flasher plusieurs boards, utilisez la commande suivante:
+#### Commandes Caterina 
 
-    make <keyboard>:<keymap>:avrdude-loop
+Il existe un certain nombre de commandes DFU que vous pouvez utiliser pour mettre à jour le firmware sur un périphérique DFU:
 
-Une fois que vous avez terminé de flasher des boards, vous devrez appuyer sur Ctrl + C, ou les touches correspondantes pour votre système d'exploitation pour arrêter la boucle.
+* `: avrdude` - Il s’agit de l’option normale. Elle attend qu’un appareil Caterina soit disponible, puis tente de flasher le firmware. Il attendra de détecter un autre port COM, puis il flashera à nouveau.
+* `: avrdude-loop` - Cela fonctionne de la même manière que `: avrdude`, mais une fois que chaque périphérique est flashé, il tentera de flasher à nouveau. Cela peut être utile pour flasher plusieurs claviers à la suite. _Cela implique de sortir manuellement de la boucle en appuyant sur Ctrl + C, Cmd + C ou un raccourci équivalent selon votre OS_
+* `: avrdude-split-left` - Cela fonctionne de la même manière que la fonction (`: avrdude`). Toutefois, cela permet aussi de flasher le coté gauche de l'EEPROM des claviers splittés / divisés. C'est donc la méthode recommandée pour les claviers splittés avec Pro Micro.
+* `: avrdude-split-right` - Cela fonctionne de la même manière que la fonction (`: avrdude`). Toutefois, cela permet aussi de flasher le coté droite de l'EEPROM des claviers splittés / divisés. C'est donc la méthode recommandée pour les claviers splittés avec Pro Micro.
 
 ### HalfKay
 
@@ -246,45 +265,9 @@ Programming.....................................................................
 Booting
 ```
 
-### BootloadHID
-
-Pour les boards basée sur Bootmapper Client(BMC)/bootloadHID/ATmega32A, une fois prêt à compiler et flasher le firmware, ouvrez votre fenêtre de terminal et lancez la commande suivante:
-
-    make <my_keyboard>:<my_keymap>:bootloaderHID
-
-Par exemple, si votre keymap s'appelle "xyverz" et que vous compilez une keymap pour un jj40, vous utilisez cette commande:
-
-    make jj40:xyverz:bootloaderHID
-
-Une fois le firmware compilé, vous aurez cette sortie:
-
-```
-Linking: .build/jj40_default.elf                                                                   [OK]
-Creating load file for flashing: .build/jj40_default.hex                                           [OK]
-Copying jj40_default.hex to qmk_firmware folder                                                    [OK]
-Checking file size of jj40_default.hex                                                             [OK]
- * The firmware size is fine - 21920/28672 (6752 bytes free)
-```
-
-A ce stade, le script de build va chercher le bootloader DFU toutes les 5 secondes. Il va répéter la sortie suivante jusqu'à ce que le dispositif soit trouvé ou que vous l'annuliez.
-
-```
-Error opening HIDBoot device: The specified device was not found
-Trying again in 5s.
-```
-
-Une fois ce résultat atteint, réinitialisez le contrôleur. Il devrait afficher le résultat suivant:
-
-```
-Page size   = 128 (0x80)
-Device size = 32768 (0x8000); 30720 bytes remaining
-Uploading 22016 (0x5600) bytes starting at 0 (0x0)
-0x05580 ... 0x05600
-```
-
 ### 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
 
@@ -336,10 +319,46 @@ Transitioning to dfuMANIFEST state
 
 Il y  aun certain nombre de commandes du DFU que vous pouvez utiliser pour flasher un firmware sur un device STM32:
 
-* `:dfu-util` - C'est l'option standard pour flasher un appareil STM32.
-* `:dfu-util-wait` - Ceci fonctionne comme la commande standard, mais permet de d'avoir une pause (configurable( de 10 secondes avant de flasher le fimrware. Vous pouvez utiliser `TIME_DELAY=20` à la ligne de commande pour changer le délai.
+* `:dfu-util` - C'est l'option standard pour flasher un appareil STM32. Elle attendra qu'un bootloader STM32 soit présent et tentera de l’utiliser.
 * `:dfu-util-left` - Ceci flasher le firmware standard, comme la commande standard (`:dfu-util`). Toutefois, elle flasher aussi les fichiers EEPROM du "côté gauche" pour les claviers scindés.
 * `:dfu-util-right` - Ceci flash le firmware standard, comme la commande standard (`:dfu-util`). Toutefois, elle flash aussi les fichiers EEPROM du "côté droit" pour les claviers scindés.
+* `: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.
+
+### BootloadHID
+
+Pour les claviers basés sur Bootmapper Client(BMC)/bootloadHID/ATmega32A, si vous êtes prêts à compiler et flasher le firmware, ouvrez votre fenêtre de terminal et lancez la commande suivante :
+
+    make <my_keyboard>:<my_keymap>:bootloaderHID
+
+Par exemple, si votre keymap s'appelle "xyverz" et que vous compilez une keymap pour un jj40, utilisez cette commande:
+
+    make jj40:xyverz:bootloaderHID
+
+Une fois le firmware compilé, vous aurez cette sortie:
+
+```
+Linking: .build/jj40_default.elf                                                                   [OK]
+Creating load file for flashing: .build/jj40_default.hex                                           [OK]
+Copying jj40_default.hex to qmk_firmware folder                                                    [OK]
+Checking file size of jj40_default.hex                                                             [OK]
+ * The firmware size is fine - 21920/28672 (6752 bytes free)
+```
+
+A ce stade, le script de build va chercher le bootloader DFU toutes les 5 secondes. Il répétera l ’affichage de ce message jusqu'à ce que l’appareil soit trouvé ou que vous annuliez l'opération```
+
+```
+Error opening HIDBoot device: The specified device was not found
+Trying again in 5s.
+```
+
+Une fois ce résultat obtenu, réinitialisez le contrôleur. Le résultat suivant devrait s’afficher :
+
+```
+Page size   = 128 (0x80)
+Device size = 32768 (0x8000); 30720 bytes remaining
+Uploading 22016 (0x5600) bytes starting at 0 (0x0)
+0x05580 ... 0x05600
+```
 
 ## Faites l'essai!