Add layout: 65_iso_blocker_split_bs (#10733)

* Add layout: 65_iso_blocker_split_bs

* Add layout to readme

.github/PULL_REQUEST_TEMPLATE.md

@@ -26,7 +26,8 @@
 
 <!--- Go over all the following points, and put an `x` in all the boxes that apply. -->
 <!--- If you're unsure about any of these, don't hesitate to ask. We're here to help! -->
-- [ ] My code follows the code style of this project.
+- [ ] My code follows the code style of this project: [**C**](https://docs.qmk.fm/#/coding_conventions_c), [**Python**](https://docs.qmk.fm/#/coding_conventions_python)
+- [ ] I have read the [**PR Checklist** document](https://docs.qmk.fm/#/pr_checklist) and have made the appropriate changes.
 - [ ] My change requires a change to the documentation.
 - [ ] I have updated the documentation accordingly.
 - [ ] I have read the [**CONTRIBUTING** document](https://docs.qmk.fm/#/contributing).

.github/labeler.yml

@@ -0,0 +1,42 @@
+core:
+  - quantum/**/*
+  - tmk_core/**/*
+  - drivers/**/*
+  - tests/**/*
+  - util/**/*
+  - platforms/**/*
+  - Makefile
+  - '*.mk'
+dependencies:
+  - any:
+    - 'lib/**/*'
+    - '!lib/python/**/*'
+keyboard:
+  - any:
+    - 'keyboards/**/*'
+    - '!keyboards/**/keymaps/**/*'
+keymap:
+  - users/**/*
+  - layouts/**/*
+  - keyboards/**/keymaps/**/*
+via:
+  - keyboards/**/keymaps/via/*
+cli:
+  - bin/qmk
+  - requirements.txt
+  - lib/python/**/*
+python:
+  - '**/*.py'
+documentation:
+  - docs/**/*
+translation:
+  - docs/fr-fr/**/*
+  - docs/es/**/*
+  - docs/ja/**/*
+  - docs/he-il/**/*
+  - docs/pt-br/**/*
+  - docs/zh-cn/**/*
+  - docs/de/**/*
+  - docs/ru-ru/**/*
+CI:
+  - .github/**/*

.github/workflows/api.yml

@@ -0,0 +1,35 @@
+name: Update API Data
+
+on:
+  push:
+    branches:
+    - master
+    paths:
+    - 'keyboards/**'
+    - 'layouts/community/**'
+
+jobs:
+  api_data:
+    runs-on: ubuntu-latest
+    container: qmkfm/base_container
+
+    steps:
+    - uses: actions/checkout@v2
+      with:
+        fetch-depth: 1
+        persist-credentials: false
+
+    - name: Generate API Data
+      run: qmk generate-api
+
+    - name: Upload API Data
+      uses: JamesIves/github-pages-deploy-action@3.7.1
+      with:
+        ACCESS_TOKEN: ${{ secrets.API_TOKEN_GITHUB }}
+        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+        BRANCH: main
+        FOLDER: api_data/v1
+        CLEAN: true
+        GIT_CONFIG_EMAIL: hello@qmk.fm
+        REPOSITORY_NAME: qmk/qmk_keyboards
+        TARGET_FOLDER: v1

.github/workflows/info.yml

@@ -16,16 +16,21 @@ jobs:
       with:
         fetch-depth: 0
 
+    - uses: trilom/file-changes-action@v1.2.4
+      id: file_changes
+      with:
+        output: '\n'
+
     - name: Print info
       run: |
         git rev-parse --short HEAD
         echo ${{ github.event.pull_request.base.sha }}
-        git diff --name-only ${{ github.event.pull_request.base.sha }}...
+        echo '${{ steps.file_changes.outputs.files}}'
 
     - name: Run qmk info
       shell: 'bash {0}'
       run: |
-        QMK_CHANGES=$(git diff --name-only ${{ github.event.pull_request.base.sha }}...)
+        QMK_CHANGES=$(echo -e '${{ steps.file_changes.outputs.files}}')
         QMK_KEYBOARDS=$(qmk list-keyboards)
 
         exit_code=0
@@ -41,7 +46,7 @@ jobs:
             echo "linting ${KB}"
 
             # TODO: info info always returns 0 - right now the only way to know failure is to inspect log lines
-            qmk info -kb ${KB} 2>&1 | tee /tmp/$$
+            qmk info -l -kb ${KB} 2>&1 | tee /tmp/$$
             !(grep -cq ☒ /tmp/$$)
             : $((exit_code = $exit_code + $?))
           fi

.github/workflows/labeler.yml

@@ -0,0 +1,14 @@
+name: "Pull Request Labeler"
+
+on:
+  pull_request_target:
+    types: [opened, synchronize, reopened, ready_for_review, locked]
+
+jobs:
+  triage:
+    runs-on: ubuntu-latest
+    steps:
+    - uses: actions/labeler@main
+      with:
+        repo-token: "${{ secrets.GITHUB_TOKEN }}"
+        configuration-path: '.github/labeler.yml'

.gitignore

@@ -16,6 +16,7 @@
 *.swp
 tags
 *~
+api_data/v1
 build/
 .build/
 *.bak
@@ -73,3 +74,6 @@ __pycache__
 
 # prerequisites for updating ChibiOS
 /util/fmpp*
+
+# Allow to exist but don't include it in the repo
+user_song_list.h

.travis.yml

@@ -27,6 +27,7 @@ addons:
 install:
   - npm install -g moxygen
 script:
+  - git fetch --depth=50 origin $TRAVIS_BRANCH:$TRAVIS_BRANCH
   - git rev-parse --short HEAD
   - git diff --name-only HEAD $TRAVIS_BRANCH
   - bash util/travis_test.sh

.vscode/settings.json

@@ -16,7 +16,8 @@
         "*.hpp": "cpp",
         "xstddef": "c",
         "type_traits": "c",
-        "utility": "c"
+        "utility": "c",
+        "ranges": "c"
     },
     "[markdown]": {
         "editor.trimAutoWhitespace": false,

api_data/_config.yml

@@ -0,0 +1 @@
+theme: jekyll-theme-cayman

api_data/readme.md

@@ -0,0 +1,5 @@
+# QMK Keyboard Metadata
+
+This directory contains machine parsable data about keyboards supported by QMK. The latest version is always available online at <https://keyboards.qmk.fm>.
+
+Do not edit anything here by hand. It is generated with the `qmk generate-api` command.

bootloader.mk

@@ -27,6 +27,8 @@
 # qmk-dfu        QMK DFU (LUFA + blinkenlight)
 # bootloadHID    HIDBootFlash compatible (ATmega32A)
 # USBasp         USBaspLoader (ATmega328P)
+# kiibohd        Input:Club Kiibohd bootloader (only used on their boards)
+# stm32duino     STM32Duino (STM32F103x8)
 #
 # BOOTLOADER_SIZE can still be defined manually, but it's recommended
 # you add any possible configuration to this list
@@ -34,30 +36,30 @@
 ifeq ($(strip $(BOOTLOADER)), atmel-dfu)
     OPT_DEFS += -DBOOTLOADER_ATMEL_DFU
     OPT_DEFS += -DBOOTLOADER_DFU
-    ifneq (,$(filter $(MCU), at90usb646 atmega16u2 atmega16u4 atmega32u2 atmega32u4))
+    ifneq (,$(filter $(MCU), atmega16u2 atmega32u2 atmega16u4 atmega32u4 at90usb646 at90usb647))
         BOOTLOADER_SIZE = 4096
     endif
-    ifeq ($(strip $(MCU)), at90usb1286)
+    ifneq (,$(filter $(MCU), at90usb1286 at90usb1287))
         BOOTLOADER_SIZE = 8192
     endif
 endif
 ifeq ($(strip $(BOOTLOADER)), lufa-dfu)
     OPT_DEFS += -DBOOTLOADER_LUFA_DFU
     OPT_DEFS += -DBOOTLOADER_DFU
-    ifneq (,$(filter $(MCU), at90usb646 atmega16u2 atmega16u4 atmega32u2 atmega32u4))
+    ifneq (,$(filter $(MCU), atmega16u2 atmega32u2 atmega16u4 atmega32u4 at90usb646 at90usb647))
         BOOTLOADER_SIZE = 4096
     endif
-    ifeq ($(strip $(MCU)), at90usb1286)
+    ifneq (,$(filter $(MCU), at90usb1286 at90usb1287))
         BOOTLOADER_SIZE = 8192
     endif
 endif
 ifeq ($(strip $(BOOTLOADER)), qmk-dfu)
     OPT_DEFS += -DBOOTLOADER_QMK_DFU
     OPT_DEFS += -DBOOTLOADER_DFU
-    ifneq (,$(filter $(MCU), at90usb646 atmega16u2 atmega16u4 atmega32u2 atmega32u4))
+    ifneq (,$(filter $(MCU), atmega16u2 atmega32u2 atmega16u4 atmega32u4 at90usb646 at90usb647))
         BOOTLOADER_SIZE = 4096
     endif
-    ifeq ($(strip $(MCU)), at90usb1286)
+    ifneq (,$(filter $(MCU), at90usb1286 at90usb1287))
         BOOTLOADER_SIZE = 8192
     endif
 endif
@@ -89,7 +91,30 @@ ifeq ($(strip $(BOOTLOADER)), lufa-ms)
     BOOTLOADER_SIZE = 6144
     FIRMWARE_FORMAT = bin
 endif
-
 ifdef BOOTLOADER_SIZE
     OPT_DEFS += -DBOOTLOADER_SIZE=$(strip $(BOOTLOADER_SIZE))
 endif
+
+ifeq ($(strip $(BOOTLOADER)), kiibohd)
+    OPT_DEFS += -DBOOTLOADER_KIIBOHD
+    ifeq ($(strip $(MCU_ORIG)), MK20DX128)
+        MCU_LDSCRIPT = MK20DX128BLDR4
+    endif
+    ifeq ($(strip $(MCU_ORIG)), MK20DX256)
+        MCU_LDSCRIPT = MK20DX256BLDR8
+    endif
+
+    DFU_ARGS = -d 1C11:B007
+    DFU_SUFFIX_ARGS = -v 1C11 -p B007
+endif
+
+ifeq ($(strip $(BOOTLOADER)), stm32duino)
+    OPT_DEFS += -DBOOTLOADER_STM32DUINO
+    MCU_LDSCRIPT = STM32F103x8_stm32duino_bootloader
+    BOARD = STM32_F103_STM32DUINO
+    # STM32F103 does NOT have an USB bootloader in ROM (only serial), so setting anything here does not make much sense
+    STM32_BOOTLOADER_ADDRESS = 0x80000000
+
+    DFU_ARGS = -d 1EAF:0003 -a2 -R
+    DFU_SUFFIX_ARGS = -v 1EAF -p 0003
+endif

build_keyboard.mk

@@ -16,7 +16,6 @@ include common.mk
 KEYBOARD_FILESAFE := $(subst /,_,$(KEYBOARD))
 TARGET ?= $(KEYBOARD_FILESAFE)_$(KEYMAP)
 KEYBOARD_OUTPUT := $(BUILD_DIR)/obj_$(KEYBOARD_FILESAFE)
-STM32_PATH := quantum/stm32
 
 # Force expansion
 TARGET := $(TARGET)
@@ -138,7 +137,7 @@ endif
 
 ifeq ($(strip $(CONVERT_TO_PROTON_C)), yes)
     TARGET := $(TARGET)_proton_c
-    include $(STM32_PATH)/proton_c.mk
+    include platforms/chibios/GENERIC_STM32_F303XC/configs/proton_c.mk
     OPT_DEFS += -DCONVERT_TO_PROTON_C
 endif
 
@@ -148,12 +147,6 @@ endif
 
 include quantum/mcu_selection.mk
 
-ifdef MCU_FAMILY
-    OPT_DEFS += -DQMK_STM32
-    KEYBOARD_PATHS += $(STM32_PATH)
-endif
-
-
 # Find all the C source files to be compiled in subfolders.
 KEYBOARD_SRC :=
 

build_layout.mk

@@ -3,8 +3,14 @@ LAYOUTS_REPOS := $(patsubst %/,%,$(sort $(dir $(wildcard $(LAYOUTS_PATH)/*/))))
 
 define SEARCH_LAYOUTS_REPO
     LAYOUT_KEYMAP_PATH := $$(LAYOUTS_REPO)/$$(LAYOUT)/$$(KEYMAP)
+    LAYOUT_KEYMAP_JSON := $$(LAYOUT_KEYMAP_PATH)/keymap.json
     LAYOUT_KEYMAP_C := $$(LAYOUT_KEYMAP_PATH)/keymap.c
-    ifneq ("$$(wildcard $$(LAYOUT_KEYMAP_C))","")
+    ifneq ("$$(wildcard $$(LAYOUT_KEYMAP_JSON))","")
+        -include $$(LAYOUT_KEYMAP_PATH)/rules.mk
+        KEYMAP_C := $(KEYBOARD_OUTPUT)/src/keymap.c
+        KEYMAP_JSON := $$(LAYOUT_KEYMAP_JSON)
+        KEYMAP_PATH := $$(LAYOUT_KEYMAP_PATH)
+    else ifneq ("$$(wildcard $$(LAYOUT_KEYMAP_C))","")
         -include $$(LAYOUT_KEYMAP_PATH)/rules.mk
         KEYMAP_C := $$(LAYOUT_KEYMAP_C)
         KEYMAP_PATH := $$(LAYOUT_KEYMAP_PATH)
@@ -24,4 +30,7 @@ ifneq ($(FORCE_LAYOUT),)
     endif
 endif
 
-$(foreach LAYOUT,$(LAYOUTS),$(eval $(call SEARCH_LAYOUTS)))
+$(foreach LAYOUT,$(LAYOUTS),$(eval $(call SEARCH_LAYOUTS)))
+
+# Use rule from build_json.mk, but update prerequisite in case KEYMAP_JSON was updated
+$(KEYBOARD_OUTPUT)/src/keymap.c: $(KEYMAP_JSON)

common_features.mk

@@ -114,6 +114,17 @@ else
         SRC += $(PLATFORM_COMMON_DIR)/flash_stm32.c
         OPT_DEFS += -DEEPROM_EMU_STM32F072xB
         OPT_DEFS += -DSTM32_EEPROM_ENABLE
+      else ifeq ($(MCU_SERIES)_$(MCU_LDSCRIPT), STM32F0xx_STM32F042x6)
+
+        # Stack sizes: Since this chip has limited RAM capacity, the stack area needs to be reduced.
+        # This ensures that the EEPROM page buffer fits into RAM
+        USE_PROCESS_STACKSIZE = 0x600
+        USE_EXCEPTIONS_STACKSIZE = 0x300
+        
+        SRC += $(PLATFORM_COMMON_DIR)/eeprom_stm32.c
+        SRC += $(PLATFORM_COMMON_DIR)/flash_stm32.c
+        OPT_DEFS += -DEEPROM_EMU_STM32F042x6
+        OPT_DEFS += -DSTM32_EEPROM_ENABLE
       else ifneq ($(filter $(MCU_SERIES),STM32L0xx STM32L1xx),)
         OPT_DEFS += -DEEPROM_DRIVER
         COMMON_VPATH += $(DRIVER_PATH)/eeprom
@@ -173,6 +184,10 @@ ifeq ($(filter $(RGB_MATRIX_ENABLE),$(VALID_MATRIX_TYPES)),)
     $(error RGB_MATRIX_ENABLE="$(RGB_MATRIX_ENABLE)" is not a valid matrix type)
 endif
     OPT_DEFS += -DRGB_MATRIX_ENABLE
+ifneq (,$(filter $(MCU), atmega16u2 atmega32u2))
+    # ATmegaxxU2 does not have hardware MUL instruction - lib8tion must be told to use software multiplication routines
+    OPT_DEFS += -DLIB8_ATTINY
+endif
     SRC += $(QUANTUM_DIR)/color.c
     SRC += $(QUANTUM_DIR)/rgb_matrix.c
     SRC += $(QUANTUM_DIR)/rgb_matrix_drivers.c
@@ -246,12 +261,13 @@ ifeq ($(strip $(SERIAL_LINK_ENABLE)), yes)
     VAPTH += $(SERIAL_PATH)
 endif
 
-ifneq ($(strip $(VARIABLE_TRACE)),)
+VARIABLE_TRACE ?= no
+ifneq ($(strip $(VARIABLE_TRACE)),no)
     SRC += $(QUANTUM_DIR)/variable_trace.c
     OPT_DEFS += -DNUM_TRACED_VARIABLES=$(strip $(VARIABLE_TRACE))
-ifneq ($(strip $(MAX_VARIABLE_TRACE_SIZE)),)
-    OPT_DEFS += -DMAX_VARIABLE_TRACE_SIZE=$(strip $(MAX_VARIABLE_TRACE_SIZE))
-endif
+    ifneq ($(strip $(MAX_VARIABLE_TRACE_SIZE)),)
+        OPT_DEFS += -DMAX_VARIABLE_TRACE_SIZE=$(strip $(MAX_VARIABLE_TRACE_SIZE))
+    endif
 endif
 
 ifeq ($(strip $(LCD_ENABLE)), yes)
@@ -263,7 +279,7 @@ ifeq ($(strip $(BACKLIGHT_CUSTOM_DRIVER)), yes)
     BACKLIGHT_DRIVER := custom
 endif
 
-VALID_BACKLIGHT_TYPES := pwm software custom
+VALID_BACKLIGHT_TYPES := pwm timer software custom
 
 BACKLIGHT_ENABLE ?= no
 BACKLIGHT_DRIVER ?= pwm
@@ -303,6 +319,12 @@ ifeq ($(strip $(WS2812_DRIVER_REQUIRED)), yes)
         SRC += ws2812.c
     else
         SRC += ws2812_$(strip $(WS2812_DRIVER)).c
+
+        ifeq ($(strip $(PLATFORM)), CHIBIOS)
+            ifeq ($(strip $(WS2812_DRIVER)), pwm)
+                OPT_DEFS += -DSTM32_DMA_REQUIRED=TRUE
+            endif
+        endif
     endif
 
     # add extra deps
@@ -390,9 +412,20 @@ ifneq ($(strip $(CUSTOM_MATRIX)), yes)
     endif
 endif
 
+# Support for translating old names to new names:
+ifeq ($(strip $(DEBOUNCE_TYPE)),sym_g)
+    DEBOUNCE_TYPE:=sym_defer_g
+else ifeq ($(strip $(DEBOUNCE_TYPE)),eager_pk)
+    DEBOUNCE_TYPE:=sym_eager_pk
+else ifeq ($(strip $(DEBOUNCE_TYPE)),sym_pk)
+    DEBOUNCE_TYPE:=sym_defer_pk
+else ifeq ($(strip $(DEBOUNCE_TYPE)),eager_pr)
+    DEBOUNCE_TYPE:=sym_eager_pr
+endif
+
 DEBOUNCE_DIR:= $(QUANTUM_DIR)/debounce
 # Debounce Modules. Set DEBOUNCE_TYPE=custom if including one manually.
-DEBOUNCE_TYPE?= sym_g
+DEBOUNCE_TYPE?= sym_defer_g
 ifneq ($(strip $(DEBOUNCE_TYPE)), custom)
     QUANTUM_SRC += $(DEBOUNCE_DIR)/$(strip $(DEBOUNCE_TYPE)).c
 endif
@@ -528,3 +561,19 @@ ifeq ($(strip $(AUTO_SHIFT_ENABLE)), yes)
         OPT_DEFS += -DAUTO_SHIFT_MODIFIERS
     endif
 endif
+
+JOYSTICK_ENABLE ?= no
+ifneq ($(strip $(JOYSTICK_ENABLE)), no)
+    OPT_DEFS += -DJOYSTICK_ENABLE
+    SRC += $(QUANTUM_DIR)/process_keycode/process_joystick.c
+    SRC += $(QUANTUM_DIR)/joystick.c
+endif
+
+ifeq ($(strip $(JOYSTICK_ENABLE)), analog)
+    OPT_DEFS += -DANALOG_JOYSTICK_ENABLE
+    SRC += analog.c
+endif
+
+ifeq ($(strip $(JOYSTICK_ENABLE)), digital)
+    OPT_DEFS += -DDIGITAL_JOYSTICK_ENABLE
+endif

docs/ChangeLog/20200829.md

@@ -0,0 +1,148 @@
+# QMK Breaking Change - 2020 Aug 29 Changelog
+
+Four times a year QMK runs a process for merging Breaking Changes. A Breaking Change is any change which modifies how QMK behaves in a way that is incompatible or potentially dangerous. We limit these changes to 4 times per year so that users can have confidence that updating their QMK tree will not break their keymaps.
+
+
+## Changes Requiring User Action :id=changes-requiring-user-action
+
+### Relocated Keyboards :id-relocated-keyboards
+
+#### The Key Company project consolidation ([#9547](https://github.com/qmk/qmk_firmware/pull/9547))
+#### relocating boards by flehrad to flehrad/ folder ([#9635](https://github.com/qmk/qmk_firmware/pull/9635))
+
+Keyboards released by The Key Company and keyboards designed by flehrad have moved to vendor folders. If you own any of the keyboards listed below, please use the new names to compile your firmware moving forward.
+
+Old Name               | New Name
+:--------------------- | :------------------
+candybar/lefty         | tkc/candybar/lefty
+candybar/righty        | tkc/candybar/righty
+m0lly                  | tkc/m0lly
+tkc1800                | tkc/tkc1800
+bigswitch              | flehrad/bigswitch
+handwired/downbubble   | flehrad/downbubble
+handwired/numbrero     | flehrad/numbrero
+snagpad                | flehrad/snagpad
+handwired/tradestation | flehrad/tradestation
+
+### Updated Keyboard Codebases :id=keyboard-updates
+
+#### Keebio RGB wiring update ([#7754](https://github.com/qmk/qmk_firmware/pull/7754))
+
+This pull request changes the configuration for Keebio split boards to use the same RGB strip wiring for each half, which provides the following improvements:
+
+* Easier wiring due to one fewer wire needed (the wire between left DOut to extra data pin) and the fact that wiring is the same for both halves.
+* RGB LEDs can be controlled by each half now instead of just master half.
+* Extra data line is freed up to allow for I2C usage instead of serial.
+
+If you have customized the value of `RGBLED_SPLIT` for your keymap, you will need to undefine it using `#undef RGBLED_SPLIT` before defining it to your customized value.
+
+This change affects:
+
+* BFO-9000
+* Fourier
+* Iris rev2
+* Levinson, revs. 1 and 2
+* Nyquist, revs. 1 and 2
+* Quefrency rev1
+* Viterbi, revs. 1 and 2
+
+### Changes to Core Functionality :id=core-updates
+
+* Bigger Combo index ([#9318](https://github.com/qmk/qmk_firmware/pull/9318))
+
+Allows the Combo feature to support more than 256 combos.
+
+Any fork that uses `process_combo_event` needs to update the function's first argument to `uint16_t`:
+
+* Old function: `void process_combo_event(uint8_t combo_index, bool pressed)`
+* New function: `void process_combo_event(uint16_t combo_index, bool pressed)`
+
+
+## Core Changes :id=core-changes
+
+### Fixes :id=core-fixes
+
+* Mousekeys: scrolling acceleration is no longer coupled to mouse movement acceleration ([#9174](https://github.com/qmk/qmk_firmware/pull/9174))
+* Keymap Extras: correctly assign Question Mark in Czech layout ([#9987](https://github.com/qmk/qmk_firmware/pull/9987))
+
+### Additions and Enhancements :id=core-additions
+
+* allow for WS2812 PWM to work on DMAMUX-capable devices ([#9471](https://github.com/qmk/qmk_firmware/pull/9471))
+  * Newer STM32 MCUs have a DMAMUX peripheral, which allows mapping of DMAs to different DMA streams, rather than hard-defining the target streams in silicon.
+  * Affects STM32L4+ devices, as well as the soon-to-be-supported-by-QMK STM32G4/H7 families.
+  * Tested on F303/Proton C (ChibiOS v19, non-DMAMUX), G474 (ChibiOS v20, with DMAMUX).
+* dual-bank STM32 bootloader support ([#8778](https://github.com/qmk/qmk_firmware/pull/8778) and [#9738](https://github.com/qmk/qmk_firmware/pull/9738))
+  * Adds support for STM32 dual-bank flash bootloaders, by toggling a GPIO during early init in order to charge an RC circuit attached to `BOOT0`.
+  * The main rationale behind this is that dual-bank STM32 devices unconditionally execute user-mode code, regardless of whether or not the user-mode code jumps to the bootloader. If either flash bank is valid (and `BOOT0` is low), then the built-in bootloader will skip any sort of DFU.
+  * This PR allows for the initialisation sequencing to charge the RC circuit based on the example circuit posted on Discord, effectively pulling `BOOT0` high before issuing the system reset. As the RC circuit takes a while to discharge, the system reset executes the ROM bootloader which subsequently sees `BOOT0` high, and starts executing the DFU routines.
+  * Tested with STM32L082 (with current QMK+current ChibiOS), and STM32G474 (against ChibiOS 20.x).
+* update Space Cadet and Tap Dance features to use Custom Tapping Term when appropriate ([#6259](https://github.com/qmk/qmk_firmware/pull/6259))
+  * For the Tap Dance feature, this completely removes the need for the `ACTION_TAP_DANCE_FN_ADVANCED_TIME` dance.
+* HID Joystick Interface ([#4226](https://github.com/qmk/qmk_firmware/pull/4226) and [#9949](https://github.com/qmk/qmk_firmware/pull/9949 "Fix Joystick Compile Issues"))
+  * This implements a joystick feature, including a joystick_task function called from TMK, specific keycodes for joystick buttons and a USB HID interface.
+  * Tested on V-USB backend and Proton C; compiles but untested on LUFA.
+  * In order to test, you have to add `JOYSTICK_ENABLE = yes` to your `rules.mk` and
+    ```c
+    #define JOYSTICK_BUTTON_COUNT 8
+    #define JOYSTICK_AXES_COUNT 2
+    ```
+    in your config.h.
+* Christmas RGB Underglow animation now fades between green and red ([#7648](https://github.com/qmk/qmk_firmware/pull/7648))
+  * `RGBLIGHT_EFFECT_CHRISTMAS_INTERVAL` has been greatly decreased; please check your animation if you have customized this value.
+* layer state now initializes on startup ([#8318](https://github.com/qmk/qmk_firmware/pull/8318))
+  * This should produce more consistent behavior between the two functions and layer masks.
+* added support for HSV->RGB conversion without using CIE curve ([#9856](https://github.com/qmk/qmk_firmware/pull/9856))
+* added NOEEPROM functions for RGB Matrix ([#9487](https://github.com/qmk/qmk_firmware/pull/9487))
+  * Added eeprom_helpers for toggle, mode, sethsv, speed, similar to rgblight versions.
+  * Added set_speed function.
+  * Added helper functions, similar to those in rgblight, in order to add NOEEPROM versions of toggle, step, hue, sat, val, and speed.
+  * Minor: spelling correction for EEPROM in a debug message.
+* flashing firmware using `st-flash` utility from [STLink Tools](https://github.com/stlink-org/stlink) is now supported ([#9964](https://github.com/qmk/qmk_firmware/pull/9964))
+* add ability to dump all makefile variables for the specified target ([#8256](https://github.com/qmk/qmk_firmware/pull/8256))
+  * Adds a new subtarget to builds, `dump_vars`, which allows for printing out all the variables that make knows about, after all substitutions occur.
+  * Example: `make handwired/onekey/proton_c:default:dump_vars`
+* add ability to change the Auto Shift timeout in real time ([#8441](https://github.com/qmk/qmk_firmware/pull/8441))
+* added a timer implementation for backlight on ChibiOS ([#8291](https://github.com/qmk/qmk_firmware/pull/8291))
+* added a third endpoint to V-USB keyboards ([#9020](https://github.com/qmk/qmk_firmware/pull/9020))
+* added a method to read the OLED display buffer from user space ([#8777](https://github.com/qmk/qmk_firmware/pull/8777))
+* K-Type refactor ([#9864](https://github.com/qmk/qmk_firmware/pull/9864))
+  * The K-Type has been refactored to use QMK's native matrix scanning routine, and now has partial support for the RGB Matrix feature.
+* Joysticks can now be used without defining analog pins ([#10169](https://github.com/qmk/qmk_firmware/pull/10169))
+
+### Clean-ups and Optimizations :id=core-optimizations
+
+* iWRAP protocol removed ([#9284](https://github.com/qmk/qmk_firmware/pull/9284))
+* work begun for consolidation of ChibiOS platform files ([#8327](https://github.com/qmk/qmk_firmware/pull/8327) and [#9315](https://github.com/qmk/qmk_firmware/pull/9315))
+  * Start of the consolidation work to move the ChibiOS board definitions as well as the default set of configuration files for existing board definitions used by keyboards.
+    * Uses `/platforms/chibios` as previously discussed on discord.
+    * Consolidates the Proton C configs into the generic F303 definitions.
+    * Allows for defining a default set of `chconf.h`, `halconf.h`, and `mcuconf.h` files within the platform definition, which is able to be overridden by the keyboard directly, though include path ordering.
+    * Adds template `chconf.h`, `halconf.h`, `mcuconf.h`, and `board.h` that can be dropped into a keyboard directory, in order to override rather than replace the entire contents of the respective files.
+    * Removed Proton C QMK board definitions, falling back to ChibiOS board definitions with QMK overrides.
+* Various tidy-ups for USB descriptor code ([#9005](https://github.com/qmk/qmk_firmware/pull/9005))
+  * Renamed `keyboard_led_stats` in lufa.c and ChibiOS usb_main.c to `keyboard_led_state`, as well as `vusb_keyboard_leds`, for consistency
+  * Formatted CDC and MIDI descriptors better
+  * Removed `ENDPOINT_CONFIG` macro, it seems pointless and removes the need for endpoint address defines in the middle of the endpoint numbering enum
+  * Fixed (possibly?) V-USB `GET_REPORT` request handling. Not sure about this one, but the existing code appears to always return an empty report - now `send_keyboard` sets this variable to the current report, matching what the LUFA code does.
+* converted `CONSUMER2BLUEFRUIT()` and `CONSUMER2RN42()` macros to static inline functions ([#9055](https://github.com/qmk/qmk_firmware/pull/9055))
+* Additional cleanups for V-USB code ([#9310](https://github.com/qmk/qmk_firmware/pull/9310))
+  * Removing the UART stuff entirely, now that we have Console support. Also fixing up various other things; switching some `debug()` calls to `dprintf()`, moved `raw_hid_report` out of the way so that we can implement the shared endpoint stuff.
+* removed inclusion of `adafruit_ble.h` from `ssd1306.c` ([#9355](https://github.com/qmk/qmk_firmware/pull/9355))
+* `outputselect.c` is no longer compiled if Bluetooth is disabled ([#9356](https://github.com/qmk/qmk_firmware/pull/9356))
+* `analogRead()` deprecated in favor of `analogReadPin()` ([#9023](https://github.com/qmk/qmk_firmware/pull/9023))
+* forcibly disable NKRO on V-USB controllers ([#9054](https://github.com/qmk/qmk_firmware/pull/9054))
+* removed warning if running backlight on STM32F072 ([#10040](https://github.com/qmk/qmk_firmware/pull/10040))
+* removed unused CORTEX_VTOR_INIT rules.mk option ([#10053](https://github.com/qmk/qmk_firmware/pull/10053))
+* improved handling for enabling Link Time Optimization ([#9832](https://github.com/qmk/qmk_firmware/pull/9832))
+* streamline rules for supporting Kiibohd bootloader ([#10129](https://github.com/qmk/qmk_firmware/pull/10129))
+* Define `STM32_DMA_REQUIRED` when using DMA-based WS2812 driver on STM32 ([#10127](https://github.com/qmk/qmk_firmware/pull/10127))
+* fix DMA stream ID calculation in ws2812_pwm ([#10008](https://github.com/qmk/qmk_firmware/pull/10008))
+* remove support for Adafruit EZ Key Bluetooth controller ([#10103](https://github.com/qmk/qmk_firmware/pull/10103))
+
+
+## QMK Infrastructure and Internals :id=qmk-internals
+
+* Attempt to fix CI for non-master branches. ([#9308](https://github.com/qmk/qmk_firmware/pull/9308))
+  * Actually fetch the branch we're attempting to compare against.
+* Run `qmk cformat` on `develop` branch ([#9501](https://github.com/qmk/qmk_firmware/pull/9501))
+* minor refactor of Bluetooth API ([#9905](https://github.com/qmk/qmk_firmware/pull/9905))

docs/_summary.md

@@ -23,6 +23,7 @@
     * [Overview](api_overview.md)
     * [API Documentation](api_docs.md)
     * [Keyboard Support](reference_configurator_support.md)
+    * [Adding Default Keymaps](configurator_default_keymaps.md)
 
 * CLI
     * [Overview](cli.md)
@@ -103,6 +104,7 @@
     * [DIP Switch](feature_dip_switch.md)
     * [Encoders](feature_encoders.md)
     * [Haptic Feedback](feature_haptic_feedback.md)
+    * [Joystick](feature_joystick.md)
     * [Proton C Conversion](proton_c_conversion.md)
     * [PS/2 Mouse](feature_ps2_mouse.md)
     * [Split Keyboard](feature_split_keyboard.md)
@@ -111,10 +113,12 @@
     * [Velocikey](feature_velocikey.md)
 
 * Developing QMK
+  * [PR Checklist](pr_checklist.md)
   * Breaking Changes
     * [Overview](breaking_changes.md)
     * [My Pull Request Was Flagged](breaking_changes_instructions.md)
     * History
+      * [2020 Aug 29](ChangeLog/20200829.md)
       * [2020 May 30](ChangeLog/20200530.md)
       * [2020 Feb 29](ChangeLog/20200229.md)
       * [2019 Aug 30](ChangeLog/20190830.md)

docs/adc_driver.md

@@ -45,9 +45,9 @@ Then place this include at the top of your code:
 
 Note that some of these pins are doubled-up on ADCs with the same channel. This is because the pins can be used for either ADC.
 
-Also note that the F0 and F3 use different numbering schemes. The F0 has a single ADC and the channels are 0-based, whereas the F3 has 4 ADCs and the channels are 1 based. This is because the F0 uses the `ADCv1` implementation of the ADC, whereas the F3 uses the `ADCv3` implementation.
+Also note that the F0 and F3 use different numbering schemes. The F0 has a single ADC and the channels are 0-indexed, whereas the F3 has 4 ADCs and the channels are 1-indexed. This is because the F0 uses the `ADCv1` implementation of the ADC, whereas the F3 uses the `ADCv3` implementation.
 
-|ADC|Channel|STM32F0XX|STM32F3XX|
+|ADC|Channel|STM32F0xx|STM32F3xx|
 |---|-------|---------|---------|
 |1  |0      |`A0`     |         |
 |1  |1      |`A1`     |`A0`     |
@@ -122,32 +122,29 @@ Also note that the F0 and F3 use different numbering schemes. The F0 has a singl
 |Function                    |Description                                                                                                        |
 |----------------------------|-------------------------------------------------------------------------------------------------------------------|
 |`analogReference(mode)`     |Sets the analog voltage reference source. Must be one of `ADC_REF_EXTERNAL`, `ADC_REF_POWER` or `ADC_REF_INTERNAL`.|
-|`analogRead(pin)`           |Reads the value from the specified Arduino pin, eg. `4` for ADC6 on the ATmega32U4.                                |
-|`analogReadPin(pin)`        |Reads the value from the specified QMK pin, eg. `F6` for ADC6 on the ATmega32U4.                                   |
-|`pinToMux(pin)`             |Translates a given QMK pin to a mux value. If an unsupported pin is given, returns the mux value for "0V (GND)".   |
+|`analogReadPin(pin)`        |Reads the value from the specified pin, eg. `F6` for ADC6 on the ATmega32U4.                                       |
+|`pinToMux(pin)`             |Translates a given pin to a mux value. If an unsupported pin is given, returns the mux value for "0V (GND)".       |
 |`adc_read(mux)`             |Reads the value from the ADC according to the specified mux. See your MCU's datasheet for more information.        |
 
 ### ARM
 
-Note that care was taken to match all of the functions used for AVR devices, however complications in the ARM platform prevent that from always being possible. For example, the `STM32` chips do not have assigned Arduino pins. We could use the default pin numbers, but those numbers change based on the package type of the device. For this reason, please specify your target pins with their identifiers (`A0`, `F3`, etc.). Also note that there are some variants of functions that accept the target ADC for the pin. Some pins can be used for multiple ADCs, and this specified can help you pick which ADC will be used to interact with that pin.
-
-|Function                    |Description                                                                                                         |
-|----------------------------|--------------------------------------------------------------------------------------------------------------------|
-|`analogReadPin(pin)`        |Reads the value from the specified QMK pin, eg. `A0` for channel 0 on the STM32F0 and ADC1 channel 1 on the STM32F3. Note that if a pin can be used for multiple ADCs, it will pick the lower numbered ADC for this function. eg. `C0` will be channel 6 of ADC 1 when it could be used for ADC 2 as well.|
-|`analogReadPinAdc(pin, adc)`|Reads the value from the specified QMK pin and ADC, eg. `C0, 1` will read from channel 6, ADC 2 instead of ADC 1. Note that the ADCs are 0-indexed for this function.|
-|`pinToMux(pin)`             |Translates a given QMK pin to a channel and ADC combination. If an unsupported pin is given, returns the mux value for "0V (GND)".|
-|`adc_read(mux)`             |Reads the value from the ADC according to the specified pin and adc combination. See your MCU's datasheet for more information.|
+|Function                    |Description                                                                                                                                                                                                                                                                                           |
+|----------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+|`analogReadPin(pin)`        |Reads the value from the specified pin, eg. `A0` for channel 0 on the STM32F0 and ADC1 channel 1 on the STM32F3. Note that if a pin can be used for multiple ADCs, it will pick the lower numbered ADC for this function. eg. `C0` will be channel 6 of ADC 1 when it could be used for ADC 2 as well.|
+|`analogReadPinAdc(pin, adc)`|Reads the value from the specified pin and ADC, eg. `C0, 1` will read from channel 6, ADC 2 instead of ADC 1. Note that the ADCs are 0-indexed for this function.                                                                                                                                     |
+|`pinToMux(pin)`             |Translates a given pin to a channel and ADC combination. If an unsupported pin is given, returns the mux value for "0V (GND)".                                                                                                                                                                        |
+|`adc_read(mux)`             |Reads the value from the ADC according to the specified pin and ADC combination. See your MCU's datasheet for more information.                                                                                                                                                                       |
 
 ## Configuration
 
 ## ARM
 
-The ARM implementation of the ADC has a few additional options that you can override in your own keyboards and keymaps to change how it operates.
+The ARM implementation of the ADC has a few additional options that you can override in your own keyboards and keymaps to change how it operates. Please consult the corresponding `hal_adc_lld.h` in ChibiOS for your specific microcontroller for further documentation on your available options.
 
-|`#define`          |Type  |Default              |Description|
-|-------------------|------|---------------------|-----------|
-|ADC_CIRCULAR_BUFFER|`bool`|`false`              |If `TRUE`, then the implementation will use a circular buffer.|
-|ADC_NUM_CHANNELS   |`int` |`1`                  |Sets the number of channels that will be scanned as part of an ADC operation. The current implementation only supports `1`.|
-|ADC_BUFFER_DEPTH   |`int` |`2`                  |Sets the depth of each result. Since we are only getting a 12-bit result by default, we set this to `2` bytes so we can contain our one value. This could be set to 1 if you opt for a 8-bit or lower result.|
-|ADC_SAMPLING_RATE  |`int` |`ADC_SMPR_SMP_1P5`   |Sets the sampling rate of the ADC. By default, it is set to the fastest setting. Please consult the corresponding `hal_adc_lld.h` in ChibiOS for your specific microcontroller for further documentation on your available options.|
-|ADC_RESOLUTION     |`int` |`ADC_CFGR1_RES_12BIT`|The resolution of your result. We choose 12 bit by default, but you can opt for 12, 10, 8, or 6 bit. Please consult the corresponding `hal_adc_lld.h` in ChibiOS for your specific microcontroller for further documentation on your available options.|
+|`#define`            |Type  |Default              |Description                                                                                                                                                                                                 |
+|---------------------|------|---------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+|`ADC_CIRCULAR_BUFFER`|`bool`|`false`              |If `true`, then the implementation will use a circular buffer.                                                                                                                                              |
+|`ADC_NUM_CHANNELS`   |`int` |`1`                  |Sets the number of channels that will be scanned as part of an ADC operation. The current implementation only supports `1`.                                                                                 |
+|`ADC_BUFFER_DEPTH`   |`int` |`2`                  |Sets the depth of each result. Since we are only getting a 12-bit result by default, we set this to 2 bytes so we can contain our one value. This could be set to 1 if you opt for an 8-bit or lower result.|
+|`ADC_SAMPLING_RATE`  |`int` |`ADC_SMPR_SMP_1P5`   |Sets the sampling rate of the ADC. By default, it is set to the fastest setting.                                                                                                                            |
+|`ADC_RESOLUTION`     |`int` |`ADC_CFGR1_RES_12BIT`|The resolution of your result. We choose 12 bit by default, but you can opt for 12, 10, 8, or 6 bit.                                                                                                        |

docs/breaking_changes.md

@@ -6,22 +6,23 @@ The breaking change period is when we will merge PR's that change QMK in dangero
 
 ## What has been included in past Breaking Changes?
 
+* [2020 Aug 29](ChangeLog/20200829.md)
 * [2020 May 30](ChangeLog/20200530.md)
 * [2020 Feb 29](ChangeLog/20200229.md)
 * [2019 Aug 30](ChangeLog/20190830.md)
 
 ## When is the next Breaking Change?
 
-The next Breaking Change is scheduled for Aug 29, 2020.
+The next Breaking Change is scheduled for November 28, 2020.
 
 ### Important Dates
 
-* [x] 2020 May 30 - `develop` is created. It will be rebased weekly.
-* [ ] 2020 Aug 1 - `develop` closed to new PR's.
-* [ ] 2020 Aug 1 - Call for testers.
-* [ ] 2020 Aug 27 - `master` is locked, no PR's merged.
-* [ ] 2020 Aug 29 - Merge `develop` to `master`.
-* [ ] 2020 Aug 29 - `master` is unlocked. PR's can be merged again.
+* [x] 2020 Aug 29 - `develop` is created. It will be rebased weekly.
+* [ ] 2020 Oct 31 - `develop` closed to new PR's.
+* [ ] 2020 Oct 31 - Call for testers.
+* [ ] 2020 Nov 26 - `master` is locked, no PR's merged.
+* [ ] 2020 Nov 28 - Merge `develop` to `master`.
+* [ ] 2020 Nov 28 - `master` is unlocked. PR's can be merged again.
 
 ## What changes will be included?
 

docs/cli_commands.md

@@ -167,6 +167,17 @@ Creates a keymap.c from a QMK Configurator export.
 qmk json2c [-o OUTPUT] filename
 ```
 
+## `qmk c2json`
+
+Creates a keymap.json from a keymap.c.  
+**Note:** Parsing C source files is not easy, therefore this subcommand may not work your keymap. In some cases not using the C pre-processor helps.
+
+**Usage**:
+
+```
+qmk c2json [--no-cpp] [-o OUTPUT] filename
+```
+
 ## `qmk list-keyboards`
 
 This command lists all the keyboards currently defined in `qmk_firmware`

docs/config_options.md

@@ -43,8 +43,6 @@ This is a C header file that is one of the first things included, and will persi
   * generally who/whatever brand produced the board
 * `#define PRODUCT Board`
   * the name of the keyboard
-* `#define DESCRIPTION a keyboard`
-  * a short description of what the keyboard is
 * `#define MATRIX_ROWS 5`
   * the number of rows in your keyboard's matrix
 * `#define MATRIX_COLS 15`
@@ -250,7 +248,10 @@ There are a few different ways to set handedness for split keyboards (listed in
 * `#define SPLIT_HAND_PIN B7`
   * For using high/low pin to determine handedness, low = right hand, high = left hand. Replace `B7` with the pin you are using. This is optional, and if you leave `SPLIT_HAND_PIN` undefined, then you can still use the EE_HANDS method or MASTER_LEFT / MASTER_RIGHT defines like the stock Let's Split uses.
 
-* `#define EE_HANDS` (only works if `SPLIT_HAND_PIN` is not defined)
+* `#define SPLIT_HAND_MATRIX_GRID <out_pin>,<in_pin>`
+  * The handedness is determined by using the intersection of the keyswitches in the key matrix, which does not exist. Normally, when this intersection is shorted (level low), it is considered left. If you define `#define SPLIT_HAND_MATRIX_GRID_LOW_IS_RIGHT`, it is determined to be right when the level is low.
+
+* `#define EE_HANDS` (only works if `SPLIT_HAND_PIN` and `SPLIT_HAND_MATRIX_GRID` are not defined)
   * Reads the handedness value stored in the EEPROM after `eeprom-lefthand.eep`/`eeprom-righthand.eep` has been flashed to their respective halves.
 
 * `#define MASTER_RIGHT`
@@ -323,11 +324,9 @@ This is a [make](https://www.gnu.org/software/make/manual/make.html) file that i
     ```
 * `LAYOUTS`
   * A list of [layouts](feature_layouts.md) this keyboard supports.
-* `LINK_TIME_OPTIMIZATION_ENABLE`
+* `LTO_ENABLE`
   * Enables Link Time Optimization (LTO) when compiling the keyboard.  This makes the process take longer, but it can significantly reduce the compiled size (and since the firmware is small, the added time is not noticeable).
 However, this will automatically disable the legacy TMK Macros and Functions features, as these break when LTO is enabled.  It does this by automatically defining `NO_ACTION_MACRO` and `NO_ACTION_FUNCTION`.  (Note: This does not affect QMK [Macros](feature_macros.md) and [Layers](feature_layers.md).)
-* `LTO_ENABLE`
-  * Has the same meaning as `LINK_TIME_OPTIMIZATION_ENABLE`.  You can use `LTO_ENABLE` instead of `LINK_TIME_OPTIMIZATION_ENABLE`.
 
 ## AVR MCU Options
 * `MCU = atmega32u4`
@@ -372,10 +371,8 @@ Use these to enable or disable building certain features. The more you have enab
   * MIDI controls
 * `UNICODE_ENABLE`
   * Unicode
-* `BLUETOOTH_ENABLE`
-  * Legacy option to Enable Bluetooth with the Adafruit EZ-Key HID. See BLUETOOTH
 * `BLUETOOTH`
-  * Current options are AdafruitEzKey, AdafruitBLE, RN42
+  * Current options are AdafruitBLE, RN42
 * `SPLIT_KEYBOARD`
   * Enables split keyboard support (dual MCU like the let's split and bakingpy's boards) and includes all necessary files located at quantum/split_common
 * `CUSTOM_MATRIX`

docs/configurator_default_keymaps.md

@@ -0,0 +1,193 @@
+# Adding Default Keymaps to QMK Configurator :id=adding-default-keymaps
+
+This page covers how to add a default keymap for a keyboard to QMK Configurator.
+
+
+## Technical Information :id=technical-information
+
+QMK Configurator uses JSON as its native file format for keymaps. As much as possible, these should be kept such that they behave the same as running `make <keyboard>:default` from `qmk_firmware`.
+
+Keymaps in this directory require four key-value pairs:
+
+* `keyboard` (string)
+  * This is the name of the keyboard, the same as would be used when running a compile job through `make` (e.g. `make 1upkeyboards/1up60rgb:default`).
+* `keymap` (string)
+  * Should be set to `default`.
+* `layout` (string)
+  * This is the layout macro used by the default keymap.
+* `layers` (array)
+  * The keymap itself. This key should contain one array per layer, which themselves should contain the keycodes that make up that layer.
+
+Additionally, most keymaps contain a `commit` key. This key is not consumed by the API that back-stops QMK Configurator, but is used by Configurator's maintainers to tell which version of a keymap was used to create the JSON keymap in this repository. The value is the SHA of the last commit to modify a board's default `keymap.c` in the `qmk_firmware` repository. The SHA is found by checking out [the `master` branch of the `qmk/qmk_firmware` repository](https://github.com/qmk/qmk_firmware/tree/master/) and running `git log -1 --pretty=oneline -- keyboards/<keyboard>/keymaps/default/keymap.c` (use `keymap.json` if the keyboard in question has this file instead), which should return something similar to:
+
+```shell
+f14629ed1cd7c7ec9089604d64f29a99981558e8 Remove/migrate action_get_macro()s from default keymaps (#5625)
+```
+
+In this example, `f14629ed1cd7c7ec9089604d64f29a99981558e8` is the value that should be used for `commit`.
+
+
+## Example :id=example
+
+If one wished to add a default keymap for the H87a by Hineybush, one would run the `git log` command above against the H87a's default keymap in `qmk_firmware`:
+
+```shell
+user ~/qmk_firmware (master)
+$ git log -1 --pretty=oneline master -- keyboards/hineybush/h87a/keymaps/default/keymap.c
+ef8878fba5d3786e3f9c66436da63a560cd36ac9 Hineybush h87a lock indicators (#8237)
+```
+
+Now that we have the commit hash, we need the keymap (edited for readability):
+
+```c
+...
+#include QMK_KEYBOARD_H
+
+const uint16_t PROGMEM keymaps[][MATRIX_ROWS][MATRIX_COLS] = {
+
+  [0] = LAYOUT_all(
+    KC_ESC,           KC_F1,   KC_F2,   KC_F3,   KC_F4,   KC_F5,   KC_F6,   KC_F7,   KC_F8,   KC_F9,   KC_F10,  KC_F11,  KC_F12,              KC_PSCR, KC_SLCK, KC_PAUS,
+    KC_GRV,  KC_1,    KC_2,    KC_3,    KC_4,    KC_5,    KC_6,    KC_7,    KC_8,    KC_9,    KC_0,    KC_MINS, KC_EQL,  KC_BSPC, KC_BSPC,    KC_INS,  KC_HOME, KC_PGUP,
+    KC_TAB,  KC_Q,    KC_W,    KC_E,    KC_R,    KC_T,    KC_Y,    KC_U,    KC_I,    KC_O,    KC_P,    KC_LBRC, KC_RBRC, KC_BSLS,             KC_DEL,  KC_END,  KC_PGDN,
+    KC_CAPS, KC_A,    KC_S,    KC_D,    KC_F,    KC_G,    KC_H,    KC_J,    KC_K,    KC_L,    KC_SCLN, KC_QUOT, KC_NUHS, KC_ENT,
+    KC_LSFT, KC_NUBS, KC_Z,    KC_X,    KC_C,    KC_V,    KC_B,    KC_N,    KC_M,    KC_COMM, KC_DOT,  KC_SLSH, KC_RSFT, KC_TRNS,                      KC_UP,
+    KC_LCTL, KC_LGUI, KC_LALT,                            KC_SPC,                             KC_RALT, MO(1),   KC_RGUI, KC_RCTL,             KC_LEFT, KC_DOWN, KC_RGHT),
+
+  [1] = LAYOUT_all(
+    KC_TRNS,          KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, RGB_TOG, RGB_MOD, RGB_HUD, RGB_HUI, RGB_SAD, RGB_SAI, RGB_VAD, RGB_VAI,             BL_TOGG, BL_DEC,  BL_INC,
+    KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS,    KC_TRNS, KC_TRNS, KC_VOLU,
+    KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, RESET,   KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS,             KC_MPLY, KC_MNXT, KC_VOLD,
+    KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS,
+    KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS,                      KC_TRNS,
+    KC_TRNS, KC_TRNS, KC_TRNS,                            KC_TRNS,                            KC_TRNS, KC_TRNS, KC_TRNS, KC_TRNS,             KC_TRNS, KC_TRNS, KC_TRNS),
+
+};
+```
+
+The default keymap uses the `LAYOUT_all` macro, so that will be the value of the `layout` key. Compiled to a QMK Configurator JSON keymap, our resulting file should be:
+
+```json
+{
+  "keyboard": "hineybush/h87a",
+  "keymap": "default",
+  "commit": "ef8878fba5d3786e3f9c66436da63a560cd36ac9",
+  "layout": "LAYOUT_all",
+  "layers": [
+    [
+      "KC_ESC",             "KC_F1",   "KC_F2",   "KC_F3",   "KC_F4",   "KC_F5",   "KC_F6",   "KC_F7",   "KC_F8",   "KC_F9",   "KC_F10",  "KC_F11",  "KC_F12",                "KC_PSCR", "KC_SLCK", "KC_PAUS",
+      "KC_GRV",  "KC_1",    "KC_2",    "KC_3",    "KC_4",    "KC_5",    "KC_6",    "KC_7",    "KC_8",    "KC_9",    "KC_0",    "KC_MINS", "KC_EQL",  "KC_BSPC", "KC_BSPC",    "KC_INS",  "KC_HOME", "KC_PGUP",
+      "KC_TAB",  "KC_Q",    "KC_W",    "KC_E",    "KC_R",    "KC_T",    "KC_Y",    "KC_U",    "KC_I",    "KC_O",    "KC_P",    "KC_LBRC", "KC_RBRC", "KC_BSLS",               "KC_DEL",  "KC_END",  "KC_PGDN",
+      "KC_CAPS", "KC_A",    "KC_S",    "KC_D",    "KC_F",    "KC_G",    "KC_H",    "KC_J",    "KC_K",    "KC_L",    "KC_SCLN", "KC_QUOT", "KC_NUHS", "KC_ENT",
+      "KC_LSFT", "KC_NUBS", "KC_Z",    "KC_X",    "KC_C",    "KC_V",    "KC_B",    "KC_N",    "KC_M",    "KC_COMM", "KC_DOT",  "KC_SLSH", "KC_RSFT", "KC_TRNS",                          "KC_UP",
+      "KC_LCTL", "KC_LGUI", "KC_LALT",                                  "KC_SPC",                                   "KC_RALT", "MO(1)",   "KC_RGUI", "KC_RCTL",               "KC_LEFT", "KC_DOWN", "KC_RGHT"
+    ],
+    [
+      "KC_TRNS",            "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "RGB_TOG", "RGB_MOD", "RGB_HUD", "RGB_HUI", "RGB_SAD", "RGB_SAI", "RGB_VAD", "RGB_VAI",               "BL_TOGG", "BL_DEC",  "BL_INC",
+      "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS",    "KC_TRNS", "KC_TRNS", "KC_VOLU",
+      "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "RESET",   "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS",               "KC_MPLY", "KC_MNXT", "KC_VOLD",
+      "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS",
+      "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS",                          "KC_TRNS",
+      "KC_TRNS", "KC_TRNS", "KC_TRNS",                                  "KC_TRNS",                                  "KC_TRNS", "KC_TRNS", "KC_TRNS", "KC_TRNS",               "KC_TRNS", "KC_TRNS", "KC_TRNS"
+    ]
+  ]
+}
+```
+
+The white space in the `layers` arrays have no effect on the functionality of the keymap, but are used to make these files easier for humans to read.
+
+
+## Caveats :id=caveats
+
+### Layers can only be referenced by number :id=layer-references
+
+A common QMK convention is to name layers using a series of `#define`s, or an `enum` statement:
+
+```c
+enum layer_names {
+    _BASE,
+    _MEDIA,
+    _FN
+};
+```
+
+This works in C, but for Configurator, you *must* use the layer's numeric index – `MO(_FN)` would need to be `MO(2)` in the above example.
+
+### No support for custom code of any kind :id=custom-code
+
+Features that require adding functions to the keymap.c file, such as Tap Dance or Unicode, can not be compiled in Configurator **at all**. Even setting `TAP_DANCE_ENABLE = yes` in the `qmk_firmware` repository at the keyboard level will prevent Configurator from compiling **any** firmware for that keyboard. This is limited both by the API and the current spec of our JSON keymap format.
+
+### Limited Support for Custom keycodes :id=custom-keycodes
+
+There is a way to support custom keycodes: if the logic for a custom keycode is implemented at the keyboard level instead of the keymap level in qmk_firmware, that keycode *can* be used in Configurator and it *will* compile and work. Instead of using the following in your `keymap.c`:
+
+```c
+enum custom_keycodes {
+    MACRO_1 = SAFE_RANGE,
+    MACRO_2,
+    MACRO_3
+};
+...
+bool process_record_user(uint16_t keycode, keyrecord_t *record) {
+    switch(keycode) {
+        case MACRO_1:
+            if (record->event.pressed) {
+                SEND_STRING("This is macro #1.");
+            }
+            return false;
+        case MACRO_2:
+            if (record->event.pressed) {
+                SEND_STRING("This is macro #2.");
+            }
+            return false;
+        case MACRO_3:
+            if (record->event.pressed) {
+                SEND_STRING("This is macro #3.");
+            }
+            return false;
+    }
+    return true;
+};
+```
+
+... add the keycode `enum` block to your keyboard's header file (`<keyboard>.h`) as follows (note that the `enum` is named `keyboard_keycodes` here):
+
+```c
+enum keyboard_keycodes {
+    MACRO_1 = SAFE_RANGE,
+    MACRO_2,
+    MACRO_3,
+    NEW_SAFE_RANGE  // Important!
+};
+```
+
+... then the logic to your `<keyboard>.c` through `process_record_kb()`:
+
+```c
+bool process_record_kb(uint16_t keycode, keyrecord_t *record) {
+    switch(keycode) {
+        case MACRO_1:
+            if (record->event.pressed) {
+                SEND_STRING("This is macro #1.");
+            }
+            return false;
+        case MACRO_2:
+            if (record->event.pressed) {
+                SEND_STRING("This is macro #2.");
+            }
+            return false;
+        case MACRO_3:
+            if (record->event.pressed) {
+                SEND_STRING("This is macro #3.");
+            }
+            return false;
+    }
+    return process_record_user(keycode, record);
+};
+```
+
+Note the call to `process_record_user()` at the end. Additionally, users of the keyboard will need to use `NEW_SAFE_RANGE` instead of `SAFE_RANGE` if they wish to add their own custom keycodes at keymap level, beyond what is provided by the keyboard.
+
+
+## Additional Reading :id=additional-reading
+
+For QMK Configurator to support your keyboard, your keyboard must be present in the `master` branch of the `qmk_firmware` repository. For instructions on this, please see [Supporting Your Keyboard in QMK Configurator](reference_configurator_support.md).

docs/custom_quantum_functions.md

@@ -319,7 +319,7 @@ This runs code every time that the layers get changed.  This can be useful for l
 
 ### Example `layer_state_set_*` Implementation
 
-This example shows how to set the [RGB Underglow](feature_rgblight.md) lights based on the layer, using the Planck as an example
+This example shows how to set the [RGB Underglow](feature_rgblight.md) lights based on the layer, using the Planck as an example.
 
 ```c
 layer_state_t layer_state_set_user(layer_state_t state) {
@@ -343,6 +343,11 @@ layer_state_t layer_state_set_user(layer_state_t state) {
   return state;
 }
 ```
+
+Use the `IS_LAYER_ON_STATE(state, layer)` and `IS_LAYER_OFF_STATE(state, layer)` macros to check the status of a particular layer.
+
+Outside of `layer_state_set_*` functions, you can use the `IS_LAYER_ON(layer)` and `IS_LAYER_OFF(layer)` macros to check global layer state.
+
 ### `layer_state_set_*` Function Documentation
 
 * Keyboard/Revision: `layer_state_t layer_state_set_kb(layer_state_t state)`
@@ -449,7 +454,7 @@ bool process_record_user(uint16_t keycode, keyrecord_t *record) {
                 layer_state_set(layer_state);   // then immediately update the layer color
             }
         }
-        return false; break;
+        return false;
     case RGB_MODE_FORWARD ... RGB_MODE_GRADIENT: // For any of the RGB codes (see quantum_keycodes.h, L400 for reference)
         if (record->event.pressed) { //This disables layer indication, as it's assumed that if you're changing this ... you want that disabled
             if (user_config.rgb_layer_change) {        // only if this is enabled

docs/driver_installation_zadig.md

@@ -4,7 +4,7 @@ QMK presents itself to the host as a regular HID keyboard device, and as such re
 
 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, the `qmk_install.sh` script will have already installed the drivers for you.
 
 ## Installation
 
@@ -23,7 +23,7 @@ Zadig will automatically detect the bootloader device. You may sometimes need to
 
 !> If Zadig lists one or more devices with the `HidUsb` driver, your keyboard is probably not in bootloader mode. The arrow will be colored orange and you will be asked to confirm modifying a system driver. **Do not** proceed if this is the case!
 
-If the arrow appears green, select the driver, and click **Install Driver**. The `libusb-win32` driver will usually work for AVR, and `WinUSB` for ARM, but if you still cannot flash the board, try installing a different driver from the list. For flashing a USBaspLoader device via command line with msys2, the `libusbk` driver is recommended, otherwise `libusb-win32` will work fine if you are using QMK Toolbox for flashing.
+If the arrow appears green, select the driver, and click **Install Driver**. The `libusb-win32` driver will usually work for AVR, and `WinUSB` for ARM, but if you still cannot flash the board, try installing a different driver from the list. USBAspLoader devices must use the `libusbK` driver.
 
 ![Zadig with a bootloader driver correctly installed](https://i.imgur.com/b8VgXzx.png)
 

docs/es/hardware_avr.md

@@ -67,7 +67,7 @@ El archivo `config.h` es donde configuras el hardware y el conjunto de caracter
 
 En la parte superior de `config.h` encontrarás ajustes relacionados con USB. Estos controlan la apariencia de tu teclado en el Sistema Operativo. Si no tienes una buena razón para cambiar debes dejar el `VENDOR_ID` como `0xFEED`. Para el `PRODUCT_ID` debes seleccionar un número que todavía no esté en uso.
 
-Cambia las líneas de `MANUFACTURER`, `PRODUCT`, y `DESCRIPTION` para reflejar con precisión tu teclado.
+Cambia las líneas de `MANUFACTURER` y `PRODUCT` para reflejar con precisión tu teclado.
 
 ```c
 #define VENDOR_ID       0xFEED
@@ -75,7 +75,6 @@ Cambia las líneas de `MANUFACTURER`, `PRODUCT`, y `DESCRIPTION` para reflejar c
 #define DEVICE_VER      0x0001
 #define MANUFACTURER    Tú
 #define PRODUCT         mi_teclado_fantastico
-#define DESCRIPTION     Un teclado personalizado
 ```
 
 ?> Windows y macOS mostrarán el `MANUFACTURER` y `PRODUCT` en la lista de dispositivos USB. `lsusb` en Linux toma estos de la lista mantenida por el [Repositorio de ID USB](http://www.linux-usb.org/usb-ids.html) por defecto. `lsusb -v` mostrará los valores reportados por el dispositivo, y también están presentes en los registros del núcleo después de conectarlo.

docs/faq_build.md

@@ -13,65 +13,29 @@ An example of using `sudo`, when your controller is ATMega32u4:
 
 or just:
 
-    $ sudo make <keyboard>:<keymap>:dfu
+    $ sudo make <keyboard>:<keymap>:flash
 
 Note that running `make` with `sudo` is generally ***not*** a good idea, and you should use one of the former methods, if possible.
 
 ### Linux `udev` Rules
-On Linux, you'll need proper privileges to access the MCU. You can either use
-`sudo` when flashing firmware, or place these files in `/etc/udev/rules.d/`. Once added run the following:
-```console
+
+On Linux, you'll need proper privileges to communicate with the bootloader device. You can either use `sudo` when flashing firmware (not recommended), or place [this file](https://github.com/qmk/qmk_firmware/tree/master/util/udev/50-qmk.rules) into `/etc/udev/rules.d/`.
+
+Once added, run the following:
+
+```
 sudo udevadm control --reload-rules
 sudo udevadm trigger
 ```
 
-**/etc/udev/rules.d/50-atmel-dfu.rules:**
-```
-# Atmel ATMega32U4
-SUBSYSTEMS=="usb", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="2ff4", TAG+="uaccess", RUN{builtin}+="uaccess"
-# Atmel USBKEY AT90USB1287
-SUBSYSTEMS=="usb", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="2ffb", TAG+="uaccess", RUN{builtin}+="uaccess"
-# Atmel ATMega32U2
-SUBSYSTEMS=="usb", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="2ff0", TAG+="uaccess", RUN{builtin}+="uaccess"
-```
-
-**/etc/udev/rules.d/54-input-club-keyboard.rules:**
+**Note:** With older versions of ModemManager (< 1.12), filtering only works when not in strict mode. The following commands can update that setting:
 
 ```
-# Input Club keyboard bootloader
-SUBSYSTEMS=="usb", ATTRS{idVendor}=="1c11", ATTRS{idProduct}=="b007", TAG+="uaccess", RUN{builtin}+="uaccess"
-```
-
-**/etc/udev/rules.d/55-caterina.rules:**
-```
-# ModemManager should ignore the following devices
-SUBSYSTEMS=="usb", ATTRS{idVendor}=="2a03", ATTRS{idProduct}=="0036", TAG+="uaccess", RUN{builtin}+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1"
-SUBSYSTEMS=="usb", ATTRS{idVendor}=="2341", ATTRS{idProduct}=="0036", TAG+="uaccess", RUN{builtin}+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1"
-SUBSYSTEMS=="usb", ATTRS{idVendor}=="1b4f", ATTRS{idProduct}=="9205", TAG+="uaccess", RUN{builtin}+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1"
-SUBSYSTEMS=="usb", ATTRS{idVendor}=="1b4f", ATTRS{idProduct}=="9203", TAG+="uaccess", RUN{builtin}+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1"
-```
-
-**Note:** With older (before 1.12) ModemManager, filtering only works when not in strict mode, the following commands can update that settings:
-```console
-sudo sed -i 's/--filter-policy=strict/--filter-policy=default/' /lib/systemd/system/ModemManager.service
+printf '[Service]\nExecStart=\nExecStart=/usr/sbin/ModemManager --filter-policy=default' | sudo tee /etc/systemd/system/ModemManager.service.d/policy.conf
 sudo systemctl daemon-reload
 sudo systemctl restart ModemManager
 ```
 
-**/etc/udev/rules.d/56-dfu-util.rules:**
-```
-# stm32duino
-SUBSYSTEMS=="usb", ATTRS{idVendor}=="1eaf", ATTRS{idProduct}=="0003", TAG+="uaccess", RUN{builtin}+="uaccess"
-# Generic stm32
-SUBSYSTEMS=="usb", ATTRS{idVendor}=="0483", ATTRS{idProduct}=="df11", TAG+="uaccess", RUN{builtin}+="uaccess"
-```
-
-**/etc/udev/rules.d/57-bootloadhid.rules:**
-```
-# bootloadHID
-SUBSYSTEMS=="usb", ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="05df", TAG+="uaccess", RUN{builtin}+="uaccess"
-```
-
 ### Serial device is not detected in bootloader mode on Linux
 Make sure your kernel has appropriate support for your device. If your device uses USB ACM, such as
 Pro Micro (Atmega32u4), make sure to include `CONFIG_USB_ACM=y`. Other devices may require `USB_SERIAL` and any of its sub options.
@@ -96,46 +60,6 @@ You can buy a really unique VID:PID here. I don't think you need this for person
 - http://www.obdev.at/products/vusb/license.html
 - http://www.mcselec.com/index.php?page=shop.product_details&flypage=shop.flypage&product_id=92&option=com_phpshop&Itemid=1
 
-## BOOTLOADER_SIZE for AVR
-Note that Teensy2.0++ bootloader size is 2048byte. Some Makefiles may have wrong comment.
-
-```
-# Boot Section Size in *bytes*
-#   Teensy halfKay   512
-#   Teensy++ halfKay 2048
-#   Atmel DFU loader 4096       (TMK Alt Controller)
-#   LUFA bootloader  4096
-#   USBaspLoader     2048
-OPT_DEFS += -DBOOTLOADER_SIZE=2048
-```
-
-## `avr-gcc: internal compiler error: Abort trap: 6 (program cc1)` on MacOS
-
-This is an issue with updating on brew, causing symlinks that avr-gcc depend on getting mangled.
-
-The solution is to remove and reinstall all affected modules.
-
-```
-brew rm avr-gcc avr-gcc@8 dfu-programmer dfu-util gcc-arm-none-eabi arm-gcc-bin@8 avrdude qmk
-brew install qmk/qmk/qmk
-brew link --force avr-gcc@8
-brew link --force arm-gcc-bin@8
-```
-
-### `avr-gcc` and LUFA
-
-If you updated your `avr-gcc` and you see errors involving LUFA, for example:
-
-`lib/lufa/LUFA/Drivers/USB/Class/Device/AudioClassDevice.h:380:5: error: 'const' attribute on function returning 'void'`
-
-For now, you need to rollback `avr-gcc` to 8 in Homebrew.
-
-```
-brew uninstall --force avr-gcc
-brew install avr-gcc@8
-brew link --force avr-gcc@8
-```
-
 ### I just flashed my keyboard and it does nothing/keypresses don't register - it's also ARM (rev6 planck, clueboard 60, hs60v2, etc...) (Feb 2019)
 Due to how EEPROM works on ARM based chips, saved settings may no longer be valid.  This affects the default layers, and *may*, under certain circumstances we are still figuring out, make the keyboard unusable.  Resetting the EEPROM will correct this.
 

docs/faq_debug.md

@@ -31,20 +31,6 @@ Check:
 - try using 'print' function instead of debug print. See **common/print.h**.
 - disconnect other devices with console function. See [Issue #97](https://github.com/tmk/tmk_keyboard/issues/97).
 
-## Linux or UNIX Like System Requires Super User Privilege
-Just use 'sudo' to execute *hid_listen* with privilege.
-```
-$ sudo hid_listen
-```
-
-Or add an *udev rule* for TMK devices with placing a file in rules directory. The directory may vary on each system.
-
-File: /etc/udev/rules.d/52-tmk-keyboard.rules(in case of Ubuntu)
-```
-# tmk keyboard products     https://github.com/tmk/tmk_keyboard
-SUBSYSTEMS=="usb", ATTRS{idVendor}=="feed", MODE:="0666"
-```
-
 ***
 
 # Miscellaneous

docs/feature_advanced_keycodes.md

@@ -2,21 +2,24 @@
 
 These allow you to combine a modifier with a keycode. When pressed, the keydown event for the modifier, then `kc` will be sent. On release, the keyup event for `kc`, then the modifier will be sent.
 
-|Key       |Aliases                        |Description                                         |
-|----------|-------------------------------|----------------------------------------------------|
-|`LCTL(kc)`|`C(kc)`                        |Hold Left Control and press `kc`                    |
-|`LSFT(kc)`|`S(kc)`                        |Hold Left Shift and press `kc`                      |
-|`LALT(kc)`|`A(kc)`, `LOPT(kc)`            |Hold Left Alt and press `kc`                        |
-|`LGUI(kc)`|`G(kc)`, `LCMD(kc)`, `LWIN(kc)`|Hold Left GUI and press `kc`                        |
-|`RCTL(kc)`|                               |Hold Right Control and press `kc`                   |
-|`RSFT(kc)`|                               |Hold Right Shift and press `kc`                     |
-|`RALT(kc)`|`ROPT(kc)`, `ALGR(kc)`         |Hold Right Alt and press `kc`                       |
-|`RGUI(kc)`|`RCMD(kc)`, `LWIN(kc)`         |Hold Right GUI and press `kc`                       |
-|`SGUI(kc)`|`SCMD(kc)`, `SWIN(kc)`         |Hold Left Shift and GUI and press `kc`              |
-|`LCA(kc)` |                               |Hold Left Control and Alt and press `kc`            |
-|`LCAG(kc)`|                               |Hold Left Control, Alt and GUI and press `kc`       |
-|`MEH(kc)` |                               |Hold Left Control, Shift and Alt and press `kc`     |
-|`HYPR(kc)`|                               |Hold Left Control, Shift, Alt and GUI and press `kc`|
+|Key       |Aliases                        |Description                                           |
+|----------|-------------------------------|------------------------------------------------------|
+|`LCTL(kc)`|`C(kc)`                        |Hold Left Control and press `kc`                      |
+|`LSFT(kc)`|`S(kc)`                        |Hold Left Shift and press `kc`                        |
+|`LALT(kc)`|`A(kc)`, `LOPT(kc)`            |Hold Left Alt and press `kc`                          |
+|`LGUI(kc)`|`G(kc)`, `LCMD(kc)`, `LWIN(kc)`|Hold Left GUI and press `kc`                          |
+|`RCTL(kc)`|                               |Hold Right Control and press `kc`                     |
+|`RSFT(kc)`|                               |Hold Right Shift and press `kc`                       |
+|`RALT(kc)`|`ROPT(kc)`, `ALGR(kc)`         |Hold Right Alt and press `kc`                         |
+|`RGUI(kc)`|`RCMD(kc)`, `LWIN(kc)`         |Hold Right GUI and press `kc`                         |
+|`SGUI(kc)`|`SCMD(kc)`, `SWIN(kc)`         |Hold Left Shift and GUI and press `kc`                |
+|`LCA(kc)` |                               |Hold Left Control and Alt and press `kc`              |
+|`LSA(kc)` |                               |Hold Left Shift and Left Alt and press `kc`           |
+|`RSA(kc)` |`SAGR(kc)`                     |Hold Right Shift and Right Alt (AltGr) and press `kc` |
+|`RCS(kc)` |                               |Hold Right Control and Right Shift and press `kc`     |
+|`LCAG(kc)`|                               |Hold Left Control, Alt and GUI and press `kc`         |
+|`MEH(kc)` |                               |Hold Left Control, Shift and Alt and press `kc`       |
+|`HYPR(kc)`|                               |Hold Left Control, Shift, Alt and GUI and press `kc`  |
 
 You can also chain them, for example `LCTL(LALT(KC_DEL))` or `C(A(KC_DEL))` makes a key that sends Control+Alt+Delete with a single keypress.
 

docs/feature_auto_shift.md

@@ -139,7 +139,7 @@ completely normal and with no intention of shifted keys.
    `KC_ASRP`. The keyboard will type by itself the value of your
    `AUTO_SHIFT_TIMEOUT`.
 7. Update `AUTO_SHIFT_TIMEOUT` in your `config.h` with the value reported.
-8. Remove `AUTO_SHIFT_SETUP` from your `config.h`.
+8. Add `AUTO_SHIFT_NO_SETUP` to your `config.h`.
 9. Remove the key bindings `KC_ASDN`, `KC_ASUP` and `KC_ASRP`.
 10. Compile and upload your new firmware.
 

docs/feature_backlight.md

@@ -1,4 +1,4 @@
-# Backlighting
+# Backlighting :id=backlighting
 
 Many keyboards support backlit keys by way of individual LEDs placed through or underneath the keyswitches. This feature is distinct from both the [RGB underglow](feature_rgblight.md) and [RGB matrix](feature_rgb_matrix.md) features as it usually allows for only a single colour per switch, though you can obviously install multiple different single coloured LEDs on a keyboard.
 
@@ -6,103 +6,106 @@ QMK is able to control the brightness of these LEDs by switching them on and off
 
 The MCU can only supply so much current to its GPIO pins. Instead of powering the backlight directly from the MCU, the backlight pin is connected to a transistor or MOSFET that switches the power to the LEDs.
 
-## Feature Configuration
-
 Most keyboards have backlighting enabled by default if they support it, but if it is not working for you, check that your `rules.mk` includes the following:
 
 ```makefile
 BACKLIGHT_ENABLE = yes
 ```
 
-## Keycodes
-Once enabled the following keycodes below can be used to change the backlight level.
+## Keycodes :id=keycodes
 
-|Key      |Description                               |
-|---------|------------------------------------------|
-|`BL_TOGG`|Turn the backlight on or off              |
-|`BL_STEP`|Cycle through backlight levels            |
-|`BL_ON`  |Set the backlight to max brightness       |
-|`BL_OFF` |Turn the backlight off                    |
-|`BL_INC` |Increase the backlight level              |
-|`BL_DEC` |Decrease the backlight level              |
-|`BL_BRTG`|Toggle backlight breathing                |
+Once enabled, the following keycodes below can be used to change the backlight level.
 
-## Backlight Functions
+|Key      |Description                        |
+|---------|-----------------------------------|
+|`BL_TOGG`|Turn the backlight on or off       |
+|`BL_STEP`|Cycle through backlight levels     |
+|`BL_ON`  |Set the backlight to max brightness|
+|`BL_OFF` |Turn the backlight off             |
+|`BL_INC` |Increase the backlight level       |
+|`BL_DEC` |Decrease the backlight level       |
+|`BL_BRTG`|Toggle backlight breathing         |
 
-|Function  |Description                                                |
-|----------|-----------------------------------------------------------|
-|`backlight_toggle()`    |Turn the backlight on or off                 |
-|`backlight_enable()`    |Turn the backlight on                        |
-|`backlight_disable()`   |Turn the backlight off                       |
-|`backlight_step()`      |Cycle through backlight levels               |
-|`backlight_increase()`  |Increase the backlight level                 |
-|`backlight_decrease()`  |Decrease the backlight level                 |
-|`backlight_level(x)`    |Sets the backlight level to specified level  |
-|`get_backlight_level()` |Return the current backlight level           |
-|`is_backlight_enabled()`|Return whether the backlight is currently on |
+## Functions :id=functions
 
-### Backlight Breathing Functions
+These functions can be used to change the backlighting in custom code:
 
-|Function  |Description                                        |
-|----------|---------------------------------------------------|
-|`breathing_toggle()`  |Turn the backlight breathing on or off |
-|`breathing_enable()`  |Turns on backlight breathing           |
-|`breathing_disable()` |Turns off backlight breathing          |
+|Function                |Description                                 |
+|------------------------|--------------------------------------------|
+|`backlight_toggle()`    |Turn the backlight on or off                |
+|`backlight_enable()`    |Turn the backlight on                       |
+|`backlight_disable()`   |Turn the backlight off                      |
+|`backlight_step()`      |Cycle through backlight levels              |
+|`backlight_increase()`  |Increase the backlight level                |
+|`backlight_decrease()`  |Decrease the backlight level                |
+|`backlight_level(x)`    |Sets the backlight level to specified level |
+|`get_backlight_level()` |Return the current backlight level          |
+|`is_backlight_enabled()`|Return whether the backlight is currently on|
 
-## Driver Configuration
+If backlight breathing is enabled (see below), the following functions are also available:
+
+|Function             |Description                           |
+|---------------------|--------------------------------------|
+|`breathing_toggle()` |Turn the backlight breathing on or off|
+|`breathing_enable()` |Turns on backlight breathing          |
+|`breathing_disable()`|Turns off backlight breathing         |
+
+## Configuration :id=configuration
 
 To select which driver to use, configure your `rules.mk` with the following:
 
 ```makefile
-BACKLIGHT_DRIVER = software # Valid driver values are 'pwm,software,no'
+BACKLIGHT_DRIVER = software
 ```
 
-See below for help on individual drivers.
+Valid driver values are `pwm`, `software`, `custom` or `no`. See below for help on individual drivers.
 
-## Common Driver Configuration
+To configure the backlighting, `#define` these in your `config.h`:
 
-To change the behavior of the backlighting, `#define` these in your `config.h`:
+|Define               |Default      |Description                                                                          |
+|---------------------|-------------|-------------------------------------------------------------------------------------|
+|`BACKLIGHT_PIN`      |*Not defined*|The pin that controls the LED(s)                                                     |
+|`BACKLIGHT_LEVELS`   |`3`          |The number of brightness levels (maximum 31 excluding off)                           |
+|`BACKLIGHT_CAPS_LOCK`|*Not defined*|Enable Caps Lock indicator using backlight (for keyboards without dedicated LED)     |
+|`BACKLIGHT_BREATHING`|*Not defined*|Enable backlight breathing, if supported                                             |
+|`BREATHING_PERIOD`   |`6`          |The length of one backlight "breath" in seconds                                      |
+|`BACKLIGHT_ON_STATE` |`1`          |The state of the backlight pin when the backlight is "on" - `1` for high, `0` for low|
 
-|Define               |Default      |Description                                                                           |
-|---------------------|-------------|--------------------------------------------------------------------------------------|
-|`BACKLIGHT_LEVELS`   |`3`          |The number of brightness levels (maximum 31 excluding off)                            |
-|`BACKLIGHT_CAPS_LOCK`|*Not defined*|Enable Caps Lock indicator using backlight (for keyboards without dedicated LED)      |
-|`BACKLIGHT_BREATHING`|*Not defined*|Enable backlight breathing, if supported                                              |
-|`BREATHING_PERIOD`   |`6`          |The length of one backlight "breath" in seconds                                       |
-|`BACKLIGHT_ON_STATE` |`0`          |The state of the backlight pin when the backlight is "on" - `1` for high, `0` for low |
+Unless you are designing your own keyboard, you generally should not need to change the `BACKLIGHT_PIN` or `BACKLIGHT_ON_STATE`.
 
-### Backlight On State
+### Backlight On State :id=backlight-on-state
 
 Most backlight circuits are driven by an N-channel MOSFET or NPN transistor. This means that to turn the transistor *on* and light the LEDs, you must drive the backlight pin, connected to the gate or base, *high*.
 Sometimes, however, a P-channel MOSFET, or a PNP transistor is used. In this case, when the transistor is on, the pin is driven *low* instead.
 
 This functionality is configured at the keyboard level with the `BACKLIGHT_ON_STATE` define.
 
-## AVR driver
+### AVR Driver :id=avr-driver
+
+The `pwm` driver is configured by default, however the equivalent setting within `rules.mk` would be:
 
-On AVR boards, the default driver currently sniffs the configuration to pick the best scenario. The driver is configured by default, however the equivalent setting within rules.mk would be:
 ```makefile
 BACKLIGHT_DRIVER = pwm
 ```
 
-### Caveats
+#### Caveats :id=avr-caveats
 
-Hardware PWM is supported according to the following table:
+On AVR boards, QMK automatically decides which driver to use according to the following table:
 
 |Backlight Pin|AT90USB64/128|ATmega16/32U4|ATmega16/32U2|ATmega32A|ATmega328/P|
-|-------------|-------------|-------------|-------------|---------|----------|
-|`B1`         |             |             |             |         |Timer 1   |
-|`B2`         |             |             |             |         |Timer 1   |
-|`B5`         |Timer 1      |Timer 1      |             |         |          |
-|`B6`         |Timer 1      |Timer 1      |             |         |          |
-|`B7`         |Timer 1      |Timer 1      |Timer 1      |         |          |
-|`C4`         |Timer 3      |             |             |         |          |
-|`C5`         |Timer 3      |             |Timer 1      |         |          |
-|`C6`         |Timer 3      |Timer 3      |Timer 1      |         |          |
-|`D4`         |             |             |             |Timer 1  |          |
-|`D5`         |             |             |             |Timer 1  |          |
+|-------------|-------------|-------------|-------------|---------|-----------|
+|`B1`         |             |             |             |         |Timer 1    |
+|`B2`         |             |             |             |         |Timer 1    |
+|`B5`         |Timer 1      |Timer 1      |             |         |           |
+|`B6`         |Timer 1      |Timer 1      |             |         |           |
+|`B7`         |Timer 1      |Timer 1      |Timer 1      |         |           |
+|`C4`         |Timer 3      |             |             |         |           |
+|`C5`         |Timer 3      |             |Timer 1      |         |           |
+|`C6`         |Timer 3      |Timer 3      |Timer 1      |         |           |
+|`D4`         |             |             |             |Timer 1  |           |
+|`D5`         |             |             |             |Timer 1  |           |
 
-All other pins will use software PWM. If the [Audio](feature_audio.md) feature is disabled or only using one timer, the backlight PWM can be triggered by a hardware timer:
+All other pins will use timer-assisted software PWM:
 
 |Audio Pin|Audio Timer|Software PWM Timer|
 |---------|-----------|------------------|
@@ -113,44 +116,9 @@ All other pins will use software PWM. If the [Audio](feature_audio.md) feature i
 |`B6`     |Timer 1    |Timer 3           |
 |`B7`     |Timer 1    |Timer 3           |
 
-When both timers are in use for Audio, the backlight PWM will not use a hardware timer, but will instead be triggered during the matrix scan. In this case, breathing is not supported, and the backlight might flicker, because the PWM computation may not be called with enough timing precision.
+When both timers are in use for Audio, the backlight PWM cannot use a hardware timer, and will instead be triggered during the matrix scan. In this case, breathing is not supported, and the backlight might flicker, because the PWM computation may not be called with enough timing precision.
 
-### AVR Configuration
-
-To change the behavior of the backlighting, `#define` these in your `config.h`:
-
-|Define               |Default      |Description                                                                                                  |
-|---------------------|-------------|-------------------------------------------------------------------------------------------------------------|
-|`BACKLIGHT_PIN`      |`B7`         |The pin that controls the LEDs. Unless you are designing your own keyboard, you shouldn't need to change this|
-|`BACKLIGHT_PINS`     |*Not defined*|experimental: see below for more information                                                                 |
-|`BACKLIGHT_LEVELS`   |`3`          |The number of brightness levels (maximum 31 excluding off)                                                   |
-|`BACKLIGHT_CAPS_LOCK`|*Not defined*|Enable Caps Lock indicator using backlight (for keyboards without dedicated LED)                             |
-|`BACKLIGHT_BREATHING`|*Not defined*|Enable backlight breathing, if supported                                                                     |
-|`BREATHING_PERIOD`   |`6`          |The length of one backlight "breath" in seconds                                                              |
-|`BACKLIGHT_ON_STATE` |`1`          |The state of the backlight pin when the backlight is "on" - `1` for high, `0` for low                        |
-
-### Backlight On State
-
-Most backlight circuits are driven by an N-channel MOSFET or NPN transistor. This means that to turn the transistor *on* and light the LEDs, you must drive the backlight pin, connected to the gate or base, *high*.
-Sometimes, however, a P-channel MOSFET, or a PNP transistor is used. In this case, when the transistor is on, the pin is driven *low* instead.
-
-This functionality is configured at the keyboard level with the `BACKLIGHT_ON_STATE` define.
-
-### Multiple backlight pins
-
-Most keyboards have only one backlight pin which control all backlight LEDs (especially if the backlight is connected to an hardware PWM pin).
-In software PWM, it is possible to define multiple backlight pins. All those pins will be turned on and off at the same time during the PWM duty cycle.
-This feature allows to set for instance the Caps Lock LED (or any other controllable LED) brightness at the same level as the other LEDs of the backlight. This is useful if you have mapped LCTRL in place of Caps Lock and you need the Caps Lock LED to be part of the backlight instead of being activated when Caps Lock is on.
-
-To activate multiple backlight pins, you need to add something like this to your user `config.h`:
-
-```c
-#define BACKLIGHT_LED_COUNT 2
-#undef BACKLIGHT_PIN
-#define BACKLIGHT_PINS { F5, B2 }
-```
-
-### Hardware PWM Implementation
+#### Hardware PWM Implementation :id=hardware-pwm-implementation
 
 When using the supported pins for backlighting, QMK will use a hardware timer configured to output a PWM signal. This timer will count up to `ICRx` (by default `0xFFFF`) before resetting to 0.
 The desired brightness is calculated and stored in the `OCRxx` register. When the counter reaches this value, the backlight pin will go low, and is pulled high again when the counter resets.
@@ -159,7 +127,7 @@ In this way `OCRxx` essentially controls the duty cycle of the LEDs, and thus th
 The breathing effect is achieved by registering an interrupt handler for `TIMER1_OVF_vect` that is called whenever the counter resets, roughly 244 times per second.
 In this handler, the value of an incrementing counter is mapped onto a precomputed brightness curve. To turn off breathing, the interrupt handler is simply disabled, and the brightness reset to the level stored in EEPROM.
 
-### Timer Assisted PWM Implementation
+#### Timer Assisted PWM Implementation :id=timer-assisted-implementation
 
 When `BACKLIGHT_PIN` is not set to a hardware backlight pin, QMK will use a hardware timer configured to trigger software interrupts. This time will count up to `ICRx` (by default `0xFFFF`) before resetting to 0.
 When resetting to 0, the CPU will fire an OVF (overflow) interrupt that will turn the LEDs on, starting the duty cycle.
@@ -168,81 +136,82 @@ In this way `OCRxx` essentially controls the duty cycle of the LEDs, and thus th
 
 The breathing effect is the same as in the hardware PWM implementation.
 
-## ARM Driver
+### ARM Driver :id=arm-configuration
+
+While still in its early stages, ARM backlight support aims to eventually have feature parity with AVR. The `pwm` driver is configured by default, however the equivalent setting within `rules.mk` would be:
 
-While still in its early stages, ARM backlight support aims to eventually have feature parity with AVR. The driver is configured by default, however the equivalent setting within rules.mk would be:
 ```makefile
 BACKLIGHT_DRIVER = pwm
 ```
 
-### Caveats
+#### ChibiOS Configuration :id=arm-configuration
+
+The following `#define`s apply only to ARM-based keyboards:
+
+|Define                 |Default|Description                        |
+|-----------------------|-------|-----------------------------------|
+|`BACKLIGHT_PWM_DRIVER` |`PWMD4`|The PWM driver to use              |
+|`BACKLIGHT_PWM_CHANNEL`|`3`    |The PWM channel to use             |
+|`BACKLIGHT_PAL_MODE`   |`2`    |The pin alternative function to use|
+
+See the ST datasheet for your particular MCU to determine these values. Unless you are designing your own keyboard, you generally should not need to change them.
+
+#### Caveats :id=arm-caveats
 
 Currently only hardware PWM is supported, not timer assisted, and does not provide automatic configuration.
 
-?> Backlight support for STMF072 has had limited testing, YMMV. If unsure, set `BACKLIGHT_ENABLE = no` in your rules.mk.
+### Software PWM Driver :id=software-pwm-driver
 
-### ARM Configuration
+In this mode, PWM is "emulated" while running other keyboard tasks. It offers maximum hardware compatibility without extra platform configuration. The tradeoff is the backlight might jitter when the keyboard is busy. To enable, add this to your `rules.mk`:
 
-To change the behavior of the backlighting, `#define` these in your `config.h`:
-
-|Define                  |Default      |Description                                                                                                  |
-|------------------------|-------------|-------------------------------------------------------------------------------------------------------------|
-|`BACKLIGHT_PIN`         |`B7`         |The pin that controls the LEDs. Unless you are designing your own keyboard, you shouldn't need to change this|
-|`BACKLIGHT_PWM_DRIVER`  |`PWMD4`      |The PWM driver to use, see ST datasheets for pin to PWM timer mapping. Unless you are designing your own keyboard, you shouldn't need to change this|
-|`BACKLIGHT_PWM_CHANNEL` |`3`          |The PWM channel to use, see ST datasheets for pin to PWM channel mapping. Unless you are designing your own keyboard, you shouldn't need to change this|
-|`BACKLIGHT_PAL_MODE`    |`2`          |The pin alternative function to use, see ST datasheets for pin AF mapping. Unless you are designing your own keyboard, you shouldn't need to change this|
-
-## Software PWM Driver :id=software-pwm-driver
-
-Emulation of PWM while running other keyboard tasks, it offers maximum hardware compatibility without extra platform configuration. The tradeoff is the backlight might jitter when the keyboard is busy. To enable, add this to your rules.mk:
 ```makefile
 BACKLIGHT_DRIVER = software
 ```
 
-### Software PWM Configuration
-
-To change the behavior of the backlighting, `#define` these in your `config.h`:
-
-|Define           |Default      |Description                                                                                                  |
-|-----------------|-------------|-------------------------------------------------------------------------------------------------------------|
-|`BACKLIGHT_PIN`  |`B7`         |The pin that controls the LEDs. Unless you are designing your own keyboard, you shouldn't need to change this|
-|`BACKLIGHT_PINS` |*Not defined*|experimental: see below for more information                                                                 |
-
-### Multiple backlight pins
+#### Multiple Backlight Pins :id=multiple-backlight-pins
 
 Most keyboards have only one backlight pin which control all backlight LEDs (especially if the backlight is connected to an hardware PWM pin).
-In software PWM, it is possible to define multiple backlight pins. All those pins will be turned on and off at the same time during the PWM duty cycle.
-This feature allows to set for instance the Caps Lock LED (or any other controllable LED) brightness at the same level as the other LEDs of the backlight. This is useful if you have mapped LCTRL in place of Caps Lock and you need the Caps Lock LED to be part of the backlight instead of being activated when Caps Lock is on.
+In software PWM, it is possible to define multiple backlight pins, which will be turned on and off at the same time during the PWM duty cycle.
 
-To activate multiple backlight pins, you need to add something like this to your user `config.h`:
+This feature allows to set, for instance, the Caps Lock LED's (or any other controllable LED) brightness at the same level as the other LEDs of the backlight. This is useful if you have mapped Control in place of Caps Lock and you need the Caps Lock LED to be part of the backlight instead of being activated when Caps Lock is on, as it is usually wired to a separate pin from the backlight.
+
+To activate multiple backlight pins, add something like this to your `config.h`, instead of `BACKLIGHT_PIN`:
 
 ```c
-#undef BACKLIGHT_PIN
 #define BACKLIGHT_PINS { F5, B2 }
 ```
 
-## Custom Driver
+### Custom Driver :id=custom-driver
 
-To enable, add this to your rules.mk:
+If none of the above drivers apply to your board (for example, you are using a separate IC to control the backlight), you can implement a custom backlight driver using this simple API provided by QMK. To enable, add this to your `rules.mk`:
 
 ```makefile
 BACKLIGHT_DRIVER = custom
 ```
 
-When implementing the custom driver API, the provided keyboard hooks are as follows:
+Then implement any of these hooks:
 
 ```c
 void backlight_init_ports(void) {
-    // Optional - Run on startup
-    //          - usually you want to configure pins here
+    // Optional - runs on startup
+    //   Usually you want to configure pins here
 }
 void backlight_set(uint8_t level) {
-    // Optional - Run on level change
-    //          - usually you want to respond to the new value
+    // Optional - runs on level change
+    //   Usually you want to respond to the new value
 }
 
 void backlight_task(void) {
-    // Optional - Run periodically
-    //          - long running actions here can cause performance issues
+    // Optional - runs periodically
+    //   Note that this is called in the main keyboard loop,
+    //   so long running actions here can cause performance issues
 }
 ```
+
+## Example Schematic
+
+In this typical example, the backlight LEDs are all connected in parallel towards an N-channel MOSFET. Its gate pin is wired to one of the microcontroller's GPIO pins through a 470Ω resistor to avoid ringing.
+A pulldown resistor is also placed between the gate pin and ground to keep it at a defined state when it is not otherwise being driven by the MCU.
+The values of these resistors are not critical - see [this Electronics StackExchange question](https://electronics.stackexchange.com/q/68748) for more information.
+
+![Backlight example circuit](https://i.imgur.com/BmAvoUC.png)

docs/feature_bluetooth.md

@@ -2,11 +2,10 @@
 
 ## Bluetooth Known Supported Hardware
 
-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.
+Currently Bluetooth support is limited to AVR based chips. For Bluetooth 2.1, QMK has support for RN-42 modules. 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|
 |----------------------------------------------------------------|----------------------------|----------------|---------------------------|--------------|
-|[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      |
 
@@ -24,16 +23,15 @@ Currently The only bluetooth chipset supported by QMK is the Adafruit Bluefruit
 
 A Bluefruit UART friend can be converted to an SPI friend, however this [requires](https://github.com/qmk/qmk_firmware/issues/2274) some reflashing and soldering directly to the MDBT40 chip.
 
-## Adafruit EZ-Key hid
-This requires [some hardware changes](https://www.reddit.com/r/MechanicalKeyboards/comments/3psx0q/the_planck_keyboard_with_bluetooth_guide_and/?ref=search_posts), but can be enabled via the Makefile. The firmware will still output characters via USB, so be aware of this when charging via a computer. It would make sense to have a switch on the Bluefruit to turn it off at will.
-
 
 <!-- FIXME: Document bluetooth support more completely. -->
 ## Bluetooth Rules.mk Options
-Use only one of these
+
+The currently supported Bluetooth chipsets do not support [N-Key Rollover (NKRO)](reference_glossary.md#n-key-rollover-nkro), so `rules.mk` must contain `NKRO_ENABLE = no`.
+
+Use only one of these to enable Bluetooth:
 * BLUETOOTH_ENABLE = yes (Legacy Option)
 * BLUETOOTH = RN42
-* BLUETOOTH = AdafruitEZKey
 * BLUETOOTH = AdafruitBLE
 
 ## Bluetooth Keycodes

docs/feature_combo.md

@@ -55,7 +55,7 @@ combo_t key_combos[COMBO_COUNT] = {
   [XV_PASTE] = COMBO_ACTION(paste_combo),
 };
 
-void process_combo_event(uint8_t combo_index, bool pressed) {
+void process_combo_event(uint16_t combo_index, bool pressed) {
   switch(combo_index) {
     case ZC_COPY:
       if (pressed) {

docs/feature_debounce_type.md

@@ -1,43 +1,151 @@
-# Debounce algorithm
+# Contact bounce / contact chatter
+
+Mechanical switches often don't have a clean single transition between pressed and unpressed states.
+
+In an ideal world, when you press a switch, you would expect the digital pin to see something like this:
+(X axis showing time
+```
+voltage                   +----------------------
+ ^                        |
+ |                        |
+ |      ------------------+
+          ----> time
+```
+
+However in the real world you will actually see contact bounce, which will look like multiple 1->0 and 0->1 transitions,
+until the value finally settles.
+```
+                  +-+ +--+ +-------------
+                  | | |  | |
+                  | | |  | |
++-----------------+ +-+  +-+
+```
+The time it takes for the switch to settle might vary with switch type, age, and even pressing technique.
+
+If the device chooses not to mitigate contact bounce, then often actions that happen when the switch is pressed are repeated
+multiple times.
+
+There are many ways to handle contact bounce ("Debouncing"). Some include employing additional hardware, for example an RC filter,
+while there are various ways to do debouncing in software too, often called debounce algorithms. This page discusses software
+debouncing methods available in QMK.
+
+While technically not considered contact bounce/contact chatter, some switch technologies are susceptible to noise, meaning,
+while the key is not changing state, sometimes short random 0->1 or 1->0 transitions might be read by the digital circuit, for example:
+```
+                  +-+
+                  | |
+                  | |
++-----------------+ +--------------------
+```
+
+Many debounce methods (but not all) will also make the device resistant to noise. If you are working with a technology that is
+susceptible to noise, you must choose a debounce method that will also mitigate noise for you.
+
+## Types of debounce algorithms
+
+1) Unit of time: Timestamp (milliseconds) vs Cycles (scans)
+   * Debounce algorithms often have a 'debounce time' parameter, that specifies the maximum settling time of the switch contacts.
+     This time might be measured in various units:
+     * Cycles-based debouncing waits n cycles (scans), decreasing count by one each matrix_scan
+     * Timestamp-based debouncing stores the millisecond timestamp a change occurred, and does substraction to figure out time elapsed.
+   * Timestamp-based debouncing is usually superior, especially in the case of noise-resistant devices because settling times of physical
+     switches is specified in units of time, and should not depend on the matrix scan-rate of the keyboard.
+   * Cycles-based debouncing is sometimes considered inferior, because the settling time that it is able to compensate for depends on the
+     performance of the matrix scanning code. If you use cycles-based debouncing, and you significantly improve the performance of your scanning
+     code, you might end up with less effective debouncing. A situation in which cycles-based debouncing might be preferable is when
+     noise is present, and the scanning algorithm is slow, or variable speed. Even if your debounce algorithm is fundamentally noise-resistant,
+     if the scanning is slow, and you are using a timestamp-based algorithm, you might end up making a debouncing decision based on only two
+     sampled values, which will limit the noise-resistance of the algorithm.
+   * Currently all built-in debounce algorithms support timestamp-based debouncing only. In the future we might
+     implement cycles-based debouncing, and it will be selectable via a ```config.h``` macro.
+
+2) Symmetric vs Asymmetric
+   * Symmetric - apply the same debouncing algorithm, to both key-up and key-down events.
+     * Recommended naming convention: ```sym_*```
+   * Asymmetric - apply different debouncing algorithms to key-down and key-up events. E.g. Eager key-down, Defer key-up.
+     * Recommended naming convention: ```asym_*``` followed by details of the type of algorithm in use, in order, for key-down and then key-up
+
+3) Eager vs Defer
+   * Eager - any key change is reported immediately. All further inputs for DEBOUNCE ms are ignored.
+     * Eager algorithms are not noise-resistant.
+     * Recommended naming conventions:
+        * ```sym_eager_*```
+        * ```asym_eager_*_*```: key-down is using eager algorithm
+        * ```asym_*_eager_*```: key-up is using eager algorithm
+   * Defer - wait for no changes for DEBOUNCE ms before reporting change.
+     * Defer algorithms are noise-resistant
+     * Recommended naming conventions:
+        * ```sym_defer_*```
+        * ```asym_defer_*_*```: key-down is using defer algorithm
+        * ```asym_*_defer_*```: key-up is using defer algorithm
+
+4) Global vs Per-Key vs Per-Row
+   * Global - one timer for all keys. Any key change state affects global timer
+     * Recommended naming convention: ```*_g```
+   * Per-key - one timer per key
+     * Recommended naming convention: ```*_pk```
+   * Per-row - one timer per row
+     * Recommended naming convention: ```*_pr```
+   * Per-key and per-row algorithms consume more resources (in terms of performance,
+     and ram usage), but fast typists might prefer them over global.
+
+## Debounce algorithms supported by QMK
 
 QMK supports multiple debounce algorithms through its debounce API.
-
-The logic for which debounce method called is below. It checks various defines that you have set in rules.mk
+The logic for which debounce method called is below. It checks various defines that you have set in ```rules.mk```
 
 ```
 DEBOUNCE_DIR:= $(QUANTUM_DIR)/debounce
-DEBOUNCE_TYPE?= sym_g
+DEBOUNCE_TYPE?= sym_defer_g
 ifneq ($(strip $(DEBOUNCE_TYPE)), custom)
     QUANTUM_SRC += $(DEBOUNCE_DIR)/$(strip $(DEBOUNCE_TYPE)).c
 endif
 ```
 
-# Debounce selection
+### Debounce selection
 
 | DEBOUNCE_TYPE    | Description                                          | What else is needed           |
 | -------------    | ---------------------------------------------------  | ----------------------------- |
-| Not defined      | Use the default algorithm, currently sym_g           | Nothing                       |
+| Not defined      | Use the default algorithm, currently sym_defer_g     | Nothing                       |
 | custom           | Use your own debounce code                           | ```SRC += debounce.c``` add your own debounce.c and implement necessary functions |
-| anything_else    | Use another algorithm from quantum/debounce/*        | Nothing                       |
+| Anything Else    | Use another algorithm from quantum/debounce/*        | Nothing                       |
 
 **Regarding split keyboards**:
 The debounce code is compatible with split keyboards.
 
-# Use your own debouncing code
-* Set ```DEBOUNCE_TYPE = custom```.
-* Add ```SRC += debounce.c```
+### Selecting an included debouncing method
+Keyboards may select one of the already implemented debounce methods, by adding to ```rules.mk``` the following line:
+```
+DEBOUNCE_TYPE = <name of algorithm>
+```
+Where name of algorithm is one of:
+* ```sym_defer_g``` - debouncing per keyboard. On any state change, a global timer is set. When ```DEBOUNCE``` milliseconds of no changes has occurred, all input changes are pushed.
+  * This is the current default algorithm. This is the highest performance algorithm with lowest memory usage, and it's also noise-resistant.
+* ```sym_eager_pr``` - debouncing per row. On any state change, response is immediate, followed by locking the row ```DEBOUNCE``` milliseconds of no further input for that row. 
+For use in keyboards where refreshing ```NUM_KEYS``` 8-bit counters is computationally expensive / low scan rate, and fingers usually only hit one row at a time. This could be
+appropriate for the ErgoDox models; the matrix is rotated 90°, and hence its "rows" are really columns, and each finger only hits a single "row" at a time in normal use.
+* ```sym_eager_pk``` - debouncing per key. On any state change, response is immediate, followed by ```DEBOUNCE``` milliseconds of no further input for that key
+* ```sym_defer_pk``` - debouncing per key. On any state change, a per-key timer is set. When ```DEBOUNCE``` milliseconds of no changes have occurred on that key, the key status change is pushed.
+
+### A couple algorithms that could be implemented in the future:
+* ```sym_defer_pr```
+* ```sym_eager_g```
+* ```asym_eager_defer_pk```
+
+### Use your own debouncing code
+You have the option to implement you own debouncing algorithm. To do this:
+* Set ```DEBOUNCE_TYPE = custom``` in ```rules.mk```.
+* Add ```SRC += debounce.c``` in ```rules.mk```
 * Add your own ```debounce.c```. Look at current implementations in ```quantum/debounce``` for examples.
 * Debouncing occurs after every raw matrix scan.
 * Use num_rows rather than MATRIX_ROWS, so that split keyboards are supported correctly.
+* If the algorithm might be applicable to other keyboards, please consider adding it to ```quantum/debounce```
 
-# Changing between included debouncing methods
-You can either use your own code, by including your own debounce.c, or switch to another included one.
-Included debounce methods are:
-* eager_pr - debouncing per row. On any state change, response is immediate, followed by locking the row ```DEBOUNCE``` milliseconds of no further input for that row. 
-For use in keyboards where refreshing ```NUM_KEYS``` 8-bit counters is computationally expensive / low scan rate, and fingers usually only hit one row at a time. This could be
-appropriate for the ErgoDox models; the matrix is rotated 90°, and hence its "rows" are really columns, and each finger only hits a single "row" at a time in normal use.
-* eager_pk - debouncing per key. On any state change, response is immediate, followed by ```DEBOUNCE``` milliseconds of no further input for that key
-* sym_g - debouncing per keyboard. On any state change, a global timer is set. When ```DEBOUNCE``` milliseconds of no changes has occured, all input changes are pushed.
-* sym_pk - debouncing per key. On any state change, a per-key timer is set. When ```DEBOUNCE``` milliseconds of no changes have occured on that key, the key status change is pushed.
+### Old names
+The following old names for existing algorithms will continue to be supported, however it is recommended to use the new names instead.
 
+* sym_g - old name for sym_defer_g
+* eager_pk - old name for sym_eager_pk
+* sym_pk - old name for sym_defer_pk
+* eager_pr - old name for sym_eager_pr
 

docs/feature_dip_switch.md

@@ -7,9 +7,17 @@ DIP switches are supported by adding this to your `rules.mk`:
 and this to your `config.h`:
 
 ```c
+// Connects each switch in the dip switch to the GPIO pin of the MCU
 #define DIP_SWITCH_PINS { B14, A15, A10, B9 }
 ```
 
+or
+
+```c
+// Connect each switch in the DIP switch to an unused intersections in the key matrix.
+#define DIP_SWITCH_MATRIX_GRID { {0,6}, {1,6}, {2,6} } // List of row and col pairs
+```
+
 ## Callbacks
 
 The callback functions can be inserted into your `<keyboard>.c`:
@@ -87,4 +95,10 @@ void dip_switch_update_mask_user(uint32_t state) {
 
 ## Hardware
 
+### Connects each switch in the dip switch to the GPIO pin of the MCU
+
 One side of the DIP switch should be wired directly to the pin on the MCU, and the other side to ground.  It should not matter which side is connected to which, as it should be functionally the same. 
+
+### Connect each switch in the DIP switch to an unused intersections in the key matrix.
+
+As with the keyswitch, a diode and DIP switch connect the ROW line to the COL line.

docs/feature_dynamic_macros.md

@@ -18,11 +18,11 @@ That should be everything necessary.
 
 To start recording the macro, press either `DYN_REC_START1` or `DYN_REC_START2`. 
 
-To finish the recording, press the `DYN_REC_STOP` layer button. 
+To finish the recording, press the `DYN_REC_STOP` layer button. You can also press `DYN_REC_START1` or `DYN_REC_START2` again to stop the recording.
 
 To replay the macro, press either `DYN_MACRO_PLAY1` or `DYN_MACRO_PLAY2`.
 
-It is possible to replay a macro as part of a macro. It's ok to replay macro 2 while recording macro 1 and vice versa but never create recursive macros i.e. macro 1 that replays macro 1. If you do so and the keyboard will get unresponsive, unplug the keyboard and plug it again.  You can disable this completly by defining `DYNAMIC_MACRO_NO_NESTING`  in your `config.h` file.
+It is possible to replay a macro as part of a macro. It's ok to replay macro 2 while recording macro 1 and vice versa but never create recursive macros i.e. macro 1 that replays macro 1. If you do so and the keyboard will get unresponsive, unplug the keyboard and plug it again.  You can disable this completely by defining `DYNAMIC_MACRO_NO_NESTING`  in your `config.h` file.
 
 ?> For the details about the internals of the dynamic macros, please read the comments in the `process_dynamic_macro.h` and `process_dynamic_macro.c` files.
 

docs/feature_joystick.md

@@ -0,0 +1,147 @@
+## Joystick
+
+The keyboard can be made to be recognized as a joystick HID device by the operating system.
+
+This is enabled by adding `JOYSTICK_ENABLE` to `rules.mk`. You can set this value to `analog`, `digital`, or `no`.
+
+!> Joystick support is not currently available on V-USB devices.
+
+The joystick feature provides two services:
+ * reading analog input devices (eg. potentiometers)
+ * sending gamepad HID reports
+
+Both services can be used without the other, depending on whether you just want to read a device but not send gamepad reports (for volume control for instance)
+or send gamepad reports based on values computed by the keyboard.
+
+### Analog Input
+
+To use analog input you must first enable it in `rules.mk`:
+
+```makefile
+JOYSTICK_ENABLE = analog
+```
+
+An analog device such as a potentiometer found on a gamepad's analog axes is based on a [voltage divider](https://en.wikipedia.org/wiki/Voltage_divider).
+It is composed of three connectors linked to the ground, the power input and power output (usually the middle one). The power output holds the voltage that varies based on the position of the cursor,
+which value will be read using your MCU's [ADC](https://en.wikipedia.org/wiki/Analog-to-digital_converter).
+Depending on which pins are already used by your keyboard's matrix, the rest of the circuit can get a little bit more complicated,
+feeding the power input and ground connection through pins and using diodes to avoid bad interactions with the matrix scanning procedures.
+
+### Configuring the Joystick
+
+By default, two axes and eight buttons are defined. This can be changed in your `config.h`:
+
+```c
+// Max 32
+#define JOYSTICK_BUTTON_COUNT 16
+// Max 6: X, Y, Z, Rx, Ry, Rz
+#define JOYSTICK_AXES_COUNT 3
+```
+
+When defining axes for your joystick, you have to provide a definition array. You can do this from your keymap.c file.
+A joystick will either be read from an input pin that allows the use of the ADC, or can be virtual, so that its value is provided by your code.
+You have to define an array of type ''joystick_config_t'' and of proper size.
+
+There are three ways for your circuit to work with the ADC, that relies on the use of 1, 2 or 3 pins of the MCU:
+ * 1 pin: your analog device is directly connected to your device GND and VCC. The only pin used is the ADC pin of your choice.
+ * 2 pins: your analog device is powered through a pin that allows toggling it on or off. The other pin is used to read the input value through the ADC.
+ * 3 pins: both the power input and ground are connected to pins that must be set to a proper state before reading and restored afterwards.
+
+The configuration of each axis is performed using one of four macros:
+ * `JOYSTICK_AXIS_VIRTUAL`: no ADC reading must be performed, that value will be provided by keyboard/keymap-level code
+ * `JOYSTICK_AXIS_IN(INPUT_PIN, LOW, REST, HIGH)`: a voltage will be read on the provided pin, which must be an ADC-capable pin.
+ * `JOYSTICK_AXIS_IN_OUT(INPUT_PIN, OUTPUT_PIN, LOW, REST, HIGH)`: the provided `OUTPUT_PIN` will be set high before `INPUT_PIN` is read.
+ * `JOYSTICK_AXIS_IN_OUT_GROUND(INPUT_PIN, OUTPUT_PIN, GROUND_PIN, LOW, REST, HIGH)`: the `OUTPUT_PIN` will be set high and `GROUND_PIN` will be set low before reading from `INPUT_PIN`.
+
+In any case where an ADC reading takes place (when `INPUT_PIN` is provided), additional `LOW`, `REST` and `HIGH` parameters are used.
+These implement the calibration of the analog device by defining the range of read values that will be mapped to the lowest, resting position and highest possible value for the axis (-127 to 127).
+In practice, you have to provide the lowest/highest raw ADC reading, and the raw reading at resting position, when no deflection is applied. You can provide inverted `LOW` and `HIGH` to invert the axis.
+
+For instance, an axes configuration can be defined in the following way:
+
+```c
+//joystick config
+joystick_config_t joystick_axes[JOYSTICK_AXES_COUNT] = {
+    [0] = JOYSTICK_AXIS_IN_OUT_GROUND(A4, B0, A7, 900, 575, 285),
+    [1] = JOYSTICK_AXIS_VIRTUAL
+};
+```
+
+When the ADC reads 900 or higher, the returned axis value will be -127, whereas it will be 127 when the ADC reads 285 or lower. Zero is returned when 575 is read.
+
+In this example, the first axis will be read from the `A4` pin while `B0` is set high and `A7` is set low, using `analogReadPin()`, whereas the second axis will not be read.
+
+In order to give a value to the second axis, you can do so in any customizable entry point: as an action, in `process_record_user()` or in `matrix_scan_user()`, or even in `joystick_task()` which is called even when no key has been pressed.
+You assign a value by writing to `joystick_status.axes[axis_index]` a signed 8-bit value (ranging from -127 to 127). Then it is necessary to assign the flag `JS_UPDATED` to `joystick_status.status` in order for an updated HID report to be sent.
+
+The following example writes two axes based on keypad presses, with `KC_P5` as a precision modifier:
+
+```c
+#ifdef ANALOG_JOYSTICK_ENABLE
+static uint8_t precision_val = 70;
+static uint8_t axesFlags = 0;
+enum axes {
+    Precision = 1,
+    Axis1High = 2,
+    Axis1Low = 4,
+    Axis2High = 8,
+    Axis2Low = 16
+};
+#endif
+
+bool process_record_user(uint16_t keycode, keyrecord_t *record) {
+    switch(keycode) {
+#ifdef ANALOG_JOYSTICK_ENABLE
+        // virtual joystick
+#    if JOYSTICK_AXES_COUNT > 1
+        case KC_P8:
+            if (record->event.pressed) {
+                axesFlags |= Axis2Low;
+            } else {
+                axesFlags &= ~Axis2Low;
+            }
+            joystick_status.status |= JS_UPDATED;
+            break;
+        case KC_P2:
+            if (record->event.pressed) {
+                axesFlags |= Axis2High;
+            } else {
+                axesFlags &= ~Axis2High;
+            }
+            joystick_status.status |= JS_UPDATED;
+            break;
+#    endif
+        case KC_P4:
+            if (record->event.pressed) {
+                axesFlags |= Axis1Low;
+            } else {
+                axesFlags &= ~Axis1Low;
+            }
+            joystick_status.status |= JS_UPDATED;
+            break;
+        case KC_P6:
+            if (record->event.pressed) {
+                axesFlags |= Axis1High;
+            } else {
+                axesFlags &= ~Axis1High;
+            }
+            joystick_status.status |= JS_UPDATED;
+            break;
+        case KC_P5:
+            if (record->event.pressed) {
+                axesFlags |= Precision;
+            } else {
+                axesFlags &= ~Precision;
+            }
+            joystick_status.status |= JS_UPDATED;
+            break;
+#endif
+    }
+    return true;
+}
+```
+
+### Triggering Joystick Buttons
+
+Joystick buttons are normal Quantum keycodes, defined as `JS_BUTTON0` to `JS_BUTTON31`, depending on the number of buttons you have configured.
+To trigger a joystick button, just add the corresponding keycode to your keymap.

docs/feature_layers.md

@@ -74,10 +74,9 @@ There are a number of functions (and variables) related to how you can use or ma
 | [`update_tri_layer(x, y, z)`](ref_functions.md#update_tri_layerx-y-z) | Checks if layers `x` and `y` are both on, and sets `z` based on that (on if both on, otherwise off). |
 | [`update_tri_layer_state(state, x, y, z)`](ref_functions.md#update_tri_layer_statestate-x-y-z) | Does the same as `update_tri_layer(x, y, z)`, but from `layer_state_set_*` functions. |
 
+In addition to the functions that you can call, there are a number of callback functions that get called every time the layer changes. This passes the layer state to the function, where it can be read or modified.
 
-In additional to the functions that you can call, there are a number of callback functions that get called every time the layer changes. This passed the layer state to the function, which can be read or modified.
-
-|Callbacks                                     |Description                                                                                    |
+|Callback                                             |Description                                                                             |
 |-----------------------------------------------------|----------------------------------------------------------------------------------------|
 | `layer_state_set_kb(layer_state_t state)`           | Callback for layer functions, for keyboard.                                            |
 | `layer_state_set_user(layer_state_t state)`         | Callback for layer functions, for users.                                               |
@@ -86,9 +85,9 @@ In additional to the functions that you can call, there are a number of callback
 
 ?> For additional details on how you can use these callbacks, check out the [Layer Change Code](custom_quantum_functions.md#layer-change-code) document.
 
-|Check functions                                                  |Description                                                                   |
-|-------------------------------------------|------------------------------------------------------------------------------|
-| `layer_state_cmp(cmp_layer_state, layer)` | This checks the `cmp_layer_state` to see if the specific `layer` is enabled. This is meant for use with the layer callbacks. |
-| `layer_state_is(layer)`                   | This checks the layer state to see if the specific `layer` is enabled. (calls `layer_state_cmp` for the global layer state). |
+It is also possible to check the state of a particular layer using the following functions and macros.
 
-!> There is `IS_LAYER_ON(layer)` as well, however the `layer_state_cmp` function has some additional handling to ensure that on layer 0 that it returns the correct value. Otherwise, if you check to see if layer 0 is on, you may get an incorrect value returned. 
+|Function                         |Description                                                                                      |Aliases
+|---------------------------------|-------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------|
+| `layer_state_is(layer)`         | Checks if the specified `layer` is enabled globally.                                            | `IS_LAYER_ON(layer)`, `IS_LAYER_OFF(layer)`                           |
+| `layer_state_cmp(state, layer)` | Checks `state` to see if the specified `layer` is enabled. Intended for use in layer callbacks. | `IS_LAYER_ON_STATE(state, layer)`, `IS_LAYER_OFF_STATE(state, layer)` |

docs/feature_mouse_keys.md

@@ -39,10 +39,11 @@ In your keymap you can use the following keycodes to map key presses to mouse ac
 
 ## Configuring mouse keys
 
-Mouse keys supports two different modes to move the cursor:
+Mouse keys supports three different modes to move the cursor:
 
 * **Accelerated (default):** Holding movement keys accelerates the cursor until it reaches its maximum speed.
 * **Constant:** Holding movement keys moves the cursor at constant speeds.
+* **Combined:** Holding movement keys accelerates the cursor until it reaches its maximum speed, but holding acceleration and movement keys simultaneously moves the cursor at constant speeds.
 
 The same principle applies to scrolling.
 
@@ -120,3 +121,22 @@ Use the following settings if you want to adjust cursor movement or scrolling:
 |`MK_W_INTERVAL_1`    |120          |Time between scroll steps (`KC_ACL1`)      |
 |`MK_W_OFFSET_2`      |1            |Scroll steps per scroll action (`KC_ACL2`) |
 |`MK_W_INTERVAL_2`    |20           |Time between scroll steps (`KC_ACL2`)      |
+
+### Combined mode
+
+This mode functions like **Accelerated** mode, however, you can hold `KC_ACL0`, `KC_ACL1` and `KC_ACL2`
+to momentarily (while held) set the cursor and scroll speeds to constant speeds. When no acceleration
+keys are held, this mode is identical to **Accelerated** mode, and can be modified using all of the
+relevant settings.
+
+* **KC_ACL0:** This acceleration sets your cursor to the slowest possible speed. This is useful for very
+small and detailed movements of the cursor.
+* **KC_ACL1:** This acceleration sets your cursor to half the maximum (user defined) speed.
+* **KC_ACL2:** This acceleration sets your cursor to the maximum (computer defined) speed. This is
+useful for moving the cursor large distances without much accuracy.
+
+To use constant speed mode, you must at least define `MK_COMBINED` in your keymap’s `config.h` file:
+
+```c
+#define MK_COMBINED
+```

docs/feature_oled_driver.md

@@ -72,6 +72,43 @@ static void render_logo(void) {
 }
 ```
 
+## Buffer Read Example
+For some purposes, you may need to read the current state of the OLED display
+buffer. The `oled_read_raw` function can be used to safely read bytes from the
+buffer.
+
+In this example, calling `fade_display` in the `oled_task_user` function will
+slowly fade away whatever is on the screen by turning random pixels black over
+time.
+```c
+//Setup some mask which can be or'd with bytes to turn off pixels
+const uint8_t single_bit_masks[8] = {127, 191, 223, 239, 247, 251, 253, 254};
+
+static void fade_display(void) {
+    //Define the reader structure
+    oled_buffer_reader_t reader;
+    uint8_t buff_char;
+    if (random() % 30 == 0) {
+        srand(timer_read());
+        // Fetch a pointer for the buffer byte at index 0. The return structure
+        // will have the pointer and the number of bytes remaining from this
+        // index position if we want to perform a sequential read by
+        // incrementing the buffer pointer
+        reader = oled_read_raw(0);
+        //Loop over the remaining buffer and erase pixels as we go
+        for (uint16_t i = 0; i < reader.remaining_element_count; i++) {
+            //Get the actual byte in the buffer by dereferencing the pointer
+            buff_char = *reader.current_element;
+            if (buff_char != 0) {
+                oled_write_raw_byte(buff_char & single_bit_masks[rand() % 8], i);
+            }
+            //increment the pointer to fetch a new byte during the next loop
+            reader.current_element++;
+        }
+    }
+}
+```
+
 ## Other Examples
 
 In split keyboards, it is very common to have two OLED displays that each render different content and are oriented or flipped differently. You can do this by switching which content to render by using the return value from `is_keyboard_master()` or `is_keyboard_left()` found in `split_util.h`, e.g:
@@ -238,6 +275,10 @@ void oled_write_P(const char *data, bool invert);
 // Remapped to call 'void oled_write_ln(const char *data, bool invert);' on ARM
 void oled_write_ln_P(const char *data, bool invert);
 
+// Returns a pointer to the requested start index in the buffer plus remaining
+// buffer length as struct
+oled_buffer_reader_t oled_read_raw(uint16_t start_index);
+
 // Writes a string to the buffer at current cursor position
 void oled_write_raw(const char *data, uint16_t size);
 
@@ -247,6 +288,10 @@ void oled_write_raw_byte(const char data, uint16_t index);
 // Writes a PROGMEM string to the buffer at current cursor position
 void oled_write_raw_P(const char *data, uint16_t size);
 
+// Sets a specific pixel on or off
+// Coordinates start at top-left and go right and down for positive x and y
+void oled_write_pixel(uint8_t x, uint8_t y, bool on);
+
 // Can be used to manually turn on the screen if it is off
 // Returns true if the screen was on or turns on
 bool oled_on(void);
@@ -255,6 +300,10 @@ bool oled_on(void);
 // Returns true if the screen was off or turns off
 bool oled_off(void);
 
+// Returns true if the oled is currently on, false if it is
+// not
+bool is_oled_on(void);
+
 // Basically it's oled_render, but with timeout management and oled_task_user calling!
 void oled_task(void);
 

docs/feature_ps2_mouse.md

@@ -294,3 +294,13 @@ To debug the mouse, add `debug_mouse = true` or enable via bootmagic.
 #define PS2_MOUSE_DEBUG_HID
 #define PS2_MOUSE_DEBUG_RAW
 ```
+
+### Movement Hook :id=movement-hook
+
+Process mouse movement in the keymap before it is sent to the host.  Example
+uses include filtering noise, adding acceleration, and automatically activating
+a layer.  To use, define the following function in your keymap:
+
+```c
+void ps2_mouse_moved_user(report_mouse_t *mouse_report);
+```

docs/feature_rgb_matrix.md

@@ -129,7 +129,7 @@ Configure the hardware via your `config.h`:
 From this point forward the configuration is the same for all the drivers. The `led_config_t` struct provides a key electrical matrix to led index lookup table, what the physical position of each LED is on the board, and what type of key or usage the LED if the LED represents. Here is a brief example:
 
 ```c
-const led_config_t g_led_config = { {
+led_config_t g_led_config = { {
   // Key Matrix to LED Index
   {   5, NO_LED, NO_LED,   0 },
   { NO_LED, NO_LED, NO_LED, NO_LED },
@@ -159,15 +159,16 @@ As mentioned earlier, the center of the keyboard by default is expected to be `{
 
 ## Flags :id=flags
 
-|Define                              |Description                                |
-|------------------------------------|-------------------------------------------|
-|`#define HAS_FLAGS(bits, flags)`    |Returns true if `bits` has all `flags` set.|
-|`#define HAS_ANY_FLAGS(bits, flags)`|Returns true if `bits` has any `flags` set.|
-|`#define LED_FLAG_NONE      0x00`   |If this LED has no flags.                  |
-|`#define LED_FLAG_ALL       0xFF`   |If this LED has all flags.                 |
-|`#define LED_FLAG_MODIFIER  0x01`   |If the Key for this LED is a modifier.     |
-|`#define LED_FLAG_UNDERGLOW 0x02`   |If the LED is for underglow.               |
-|`#define LED_FLAG_KEYLIGHT  0x04`   |If the LED is for key backlight.           |
+|Define                      |Value |Description                                      |
+|----------------------------|------|-------------------------------------------------|
+|`HAS_FLAGS(bits, flags)`    |*n/a* |Evaluates to `true` if `bits` has all `flags` set|
+|`HAS_ANY_FLAGS(bits, flags)`|*n/a* |Evaluates to `true` if `bits` has any `flags` set|
+|`LED_FLAG_NONE`             |`0x00`|If this LED has no flags                         |
+|`LED_FLAG_ALL`              |`0xFF`|If this LED has all flags                        |
+|`LED_FLAG_MODIFIER`         |`0x01`|If the LED is on a modifier key                  |
+|`LED_FLAG_UNDERGLOW`        |`0x02`|If the LED is for underglow                      |
+|`LED_FLAG_KEYLIGHT`         |`0x04`|If the LED is for key backlight                  |
+|`LED_FLAG_INDICATOR`        |`0x08`|If the LED is for keyboard state indication      |
 
 ## Keycodes :id=keycodes
 
@@ -421,8 +422,8 @@ Where `28` is an unused index from `eeconfig.h`.
 |`rgb_matrix_toggle_noeeprom()`              |Toggle effect range LEDs between on and off (not written to EEPROM) |
 |`rgb_matrix_enable()`                       |Turn effect range LEDs on, based on their previous state |
 |`rgb_matrix_enable_noeeprom()`              |Turn effect range LEDs on, based on their previous state (not written to EEPROM) |
-|`rgb_matrix_disable()`                      |Turn effect range LEDs off |
-|`rgb_matrix_disable_noeeprom()`             |Turn effect range LEDs off (not written to EEPROM) |
+|`rgb_matrix_disable()`                      |Turn effect range LEDs off, based on their previous state |
+|`rgb_matrix_disable_noeeprom()`             |Turn effect range LEDs off, based on their previous state (not written to EEPROM) |
 
 ### Change Effect Mode :id=change-effect-mode
 |Function                                    |Description  |
@@ -430,19 +431,31 @@ Where `28` is an unused index from `eeconfig.h`.
 |`rgb_matrix_mode(mode)`                     |Set the mode, if RGB animations are enabled |
 |`rgb_matrix_mode_noeeprom(mode)`            |Set the mode, if RGB animations are enabled (not written to EEPROM) |
 |`rgb_matrix_step()`                         |Change the mode to the next RGB animation in the list of enabled RGB animations |
+|`rgb_matrix_step_noeeprom()`                |Change the mode to the next RGB animation in the list of enabled RGB animations (not written to EEPROM) |
 |`rgb_matrix_step_reverse()`                 |Change the mode to the previous RGB animation in the list of enabled RGB animations |
-|`rgb_matrix_increase_speed()`               |Increases the speed of the animations |
-|`rgb_matrix_decrease_speed()`               |Decreases the speed of the animations |
+|`rgb_matrix_step_reverse_noeeprom()`        |Change the mode to the previous RGB animation in the list of enabled RGB animations (not written to EEPROM) |
+|`rgb_matrix_increase_speed()`               |Increase the speed of the animations |
+|`rgb_matrix_increase_speed_noeeprom()`      |Increase the speed of the animations (not written to EEPROM) |
+|`rgb_matrix_decrease_speed()`               |Decrease the speed of the animations |
+|`rgb_matrix_decrease_speed_noeeprom()`      |Decrease the speed of the animations (not written to EEPROM) |
+|`rgb_matrix_set_speed(speed)`               |Set the speed of the animations to the given value where `speed` is between 0 and 255 |
+|`rgb_matrix_set_speed_noeeprom(speed)`      |Set the speed of the animations to the given value where `speed` is between 0 and 255 (not written to EEPROM) |
 
 ### Change Color :id=change-color
 |Function                                    |Description  |
 |--------------------------------------------|-------------|
 |`rgb_matrix_increase_hue()`                 |Increase the hue for effect range LEDs. This wraps around at maximum hue |
+|`rgb_matrix_increase_hue_noeeprom()`        |Increase the hue for effect range LEDs. This wraps around at maximum hue (not written to EEPROM) |
 |`rgb_matrix_decrease_hue()`                 |Decrease the hue for effect range LEDs. This wraps around at minimum hue |
+|`rgb_matrix_decrease_hue_noeeprom()`        |Decrease the hue for effect range LEDs. This wraps around at minimum hue (not written to EEPROM) |
 |`rgb_matrix_increase_sat()`                 |Increase the saturation for effect range LEDs. This wraps around at maximum saturation |
+|`rgb_matrix_increase_sat_noeeprom()`        |Increase the saturation for effect range LEDs. This wraps around at maximum saturation (not written to EEPROM) |
 |`rgb_matrix_decrease_sat()`                 |Decrease the saturation for effect range LEDs. This wraps around at minimum saturation |
+|`rgb_matrix_decrease_sat_noeeprom()`        |Decrease the saturation for effect range LEDs. This wraps around at minimum saturation (not written to EEPROM) |
 |`rgb_matrix_increase_val()`                 |Increase the value for effect range LEDs. This wraps around at maximum value |
+|`rgb_matrix_increase_val_noeeprom()`        |Increase the value for effect range LEDs. This wraps around at maximum value (not written to EEPROM) |
 |`rgb_matrix_decrease_val()`                 |Decrease the value for effect range LEDs. This wraps around at minimum value |
+|`rgb_matrix_decrease_val_noeeprom()`        |Decrease the value for effect range LEDs. This wraps around at minimum value (not written to EEPROM) |
 |`rgb_matrix_sethsv(h, s, v)`                |Set LEDs to the given HSV value where `h`/`s`/`v` are between 0 and 255 |
 |`rgb_matrix_sethsv_noeeprom(h, s, v)`       |Set LEDs to the given HSV value where `h`/`s`/`v` are between 0 and 255 (not written to EEPROM) |
 

docs/feature_rgblight.md

@@ -126,19 +126,19 @@ Use these defines to add or remove animations from the firmware. When you are ru
 
 The following options are used to tweak the various animations:
 
-|Define                              |Default      |Description                                                                          |
-|------------------------------------|-------------|-------------------------------------------------------------------------------------|
+|Define                              |Default      |Description                                                                                    |
+|------------------------------------|-------------|-----------------------------------------------------------------------------------------------|
 |`RGBLIGHT_EFFECT_BREATHE_CENTER`    |*Not defined*|If defined, used to calculate the curve for the breathing animation. Valid values are 1.0 to 2.7 |
-|`RGBLIGHT_EFFECT_BREATHE_MAX`       |`255`        |The maximum brightness for the breathing mode. Valid values are 1 to 255             |
-|`RGBLIGHT_EFFECT_CHRISTMAS_INTERVAL`|`1000`       |How long to wait between light changes for the "Christmas" animation, in milliseconds|
-|`RGBLIGHT_EFFECT_CHRISTMAS_STEP`    |`2`          |The number of LEDs to group the red/green colors by for the "Christmas" animation    |
-|`RGBLIGHT_EFFECT_KNIGHT_LED_NUM`    |`RGBLED_NUM` |The number of LEDs to have the "Knight" animation travel                             |
-|`RGBLIGHT_EFFECT_KNIGHT_LENGTH`     |`3`          |The number of LEDs to light up for the "Knight" animation                            |
-|`RGBLIGHT_EFFECT_KNIGHT_OFFSET`     |`0`          |The number of LEDs to start the "Knight" animation from the start of the strip by    |
-|`RGBLIGHT_RAINBOW_SWIRL_RANGE`      |`255`        |Range adjustment for the rainbow swirl effect to get different swirls                |
-|`RGBLIGHT_EFFECT_SNAKE_LENGTH`      |`4`          |The number of LEDs to light up for the "Snake" animation                             |
-|`RGBLIGHT_EFFECT_TWINKLE_LIFE`      |`75`         |Adjusts how quickly each LED brightens and dims when twinkling (in animation steps)  |
-|`RGBLIGHT_EFFECT_TWINKLE_PROBABILITY`|`1/127`     |Adjusts how likely each LED is to twinkle (on each animation step)                   |
+|`RGBLIGHT_EFFECT_BREATHE_MAX`       |`255`        |The maximum brightness for the breathing mode. Valid values are 1 to 255                       |
+|`RGBLIGHT_EFFECT_CHRISTMAS_INTERVAL`|`40`         |How long (in milliseconds) to wait between animation steps for the "Christmas" animation       |
+|`RGBLIGHT_EFFECT_CHRISTMAS_STEP`    |`2`          |The number of LEDs to group the red/green colors by for the "Christmas" animation              |
+|`RGBLIGHT_EFFECT_KNIGHT_LED_NUM`    |`RGBLED_NUM` |The number of LEDs to have the "Knight" animation travel                                       |
+|`RGBLIGHT_EFFECT_KNIGHT_LENGTH`     |`3`          |The number of LEDs to light up for the "Knight" animation                                      |
+|`RGBLIGHT_EFFECT_KNIGHT_OFFSET`     |`0`          |The number of LEDs to start the "Knight" animation from the start of the strip by              |
+|`RGBLIGHT_RAINBOW_SWIRL_RANGE`      |`255`        |Range adjustment for the rainbow swirl effect to get different swirls                          |
+|`RGBLIGHT_EFFECT_SNAKE_LENGTH`      |`4`          |The number of LEDs to light up for the "Snake" animation                                       |
+|`RGBLIGHT_EFFECT_TWINKLE_LIFE`      |`75`         |Adjusts how quickly each LED brightens and dims when twinkling (in animation steps)            |
+|`RGBLIGHT_EFFECT_TWINKLE_PROBABILITY`|`1/127`     |Adjusts how likely each LED is to twinkle (on each animation step)                             |
 
 ### Example Usage to Reduce Memory Footprint
   1. Remove `RGBLIGHT_ANIMATIONS` from `config.h`.
@@ -377,6 +377,17 @@ rgblight_sethsv(HSV_GREEN, 2); // led 2
 |`rgblight_sethsv(h, s, v)`                  |Set effect range LEDs to the given HSV value where `h`/`s`/`v` are between 0 and 255 |
 |`rgblight_sethsv_noeeprom(h, s, v)`         |Set effect range LEDs to the given HSV value where `h`/`s`/`v` are between 0 and 255 (not written to EEPROM) |
 
+#### Speed functions
+|Function                                    |Description  |
+|--------------------------------------------|-------------|
+|`rgblight_increase_speed()`                 |Increases the animation speed |
+|`rgblight_increase_speed_noeeprom()`        |Increases the animation speed (not written to EEPROM) |
+|`rgblight_decrease_speed()`                 |Decreases the animation speed |
+|`rgblight_decrease_speed_noeeprom()`        |Decreases the animation speed (not written to EEPROM) |
+|`rgblight_set_speed()`                      |Sets the speed. Value is between 0 and 255 |
+|`rgblight_set_speed_noeeprom()`             |Sets the speed. Value is between 0 and 255 (not written to EEPROM) |
+
+
 #### layer functions
 |Function                                    |Description  |
 |--------------------------------------------|-------------|

docs/feature_split_keyboard.md

@@ -48,11 +48,12 @@ However, USB cables, SATA cables, and even just 4 wires have been known to be us
 
 ### Serial Wiring
 
-The 3 wires of the TRS/TRRS cable need to connect GND, VCC, and D0 (aka PDO or pin 3) between the two Pro Micros. 
+The 3 wires of the TRS/TRRS cable need to connect GND, VCC, and D0/D1/D2/D3 (aka PD0/PD1/PD2/PD3) between the two Pro Micros. 
 
 ?> Note that the pin used here is actually set by `SOFT_SERIAL_PIN` below.
 
-![serial wiring](https://i.imgur.com/C3D1GAQ.png)
+<img alt="sk-pd0-connection-mono" src="https://user-images.githubusercontent.com/2170248/92296488-28e9ad80-ef70-11ea-98be-c40cb48a0319.JPG" width="48%"/>
+<img alt="sk-pd2-connection-mono" src="https://user-images.githubusercontent.com/2170248/92296490-2d15cb00-ef70-11ea-801f-5ace313013e6.JPG" width="48%"/>
 
 ### I<sup>2</sup>C Wiring
 
@@ -60,7 +61,7 @@ The 4 wires of the TRRS cable need to connect GND, VCC, and SCL and SDA (aka PD0
 
 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)
+<img alt="sk-i2c-connection-mono" src="https://user-images.githubusercontent.com/2170248/92297182-92b98580-ef77-11ea-9d7d-d6033914af43.JPG" width="50%"/>
 
 ## Firmware Configuration
 
@@ -90,6 +91,24 @@ You can configure the firmware to read a pin on the controller to determine hand
 
 This will read the specified pin. If it's high, then the controller assumes it is the left hand, and if it's low, it's assumed to be the right side. 
 
+#### Handedness by Matrix Pin
+
+You can configure the firmware to read key matrix pins on the controller to determine handedness.  To do this, add the following to your `config.h` file:
+
+```c
+#define SPLIT_HAND_MATRIX_GRID D0, F1
+```
+
+The first pin is the output pin and the second is the input pin.
+
+Some keyboards have unused intersections in the key matrix. This setting uses one of these unused intersections to determine the handness.
+
+Normally, when a diode is connected to an intersection, it is judged to be left. If you add the following definition, it will be judged to be right.
+
+```c
+#define SPLIT_HAND_MATRIX_GRID_LOW_IS_RIGHT
+```
+
 #### Handedness by EEPROM
 
 This method sets the keyboard's handedness by setting a flag in the persistent storage (`EEPROM`).  This is checked when the controller first starts up, and determines what half the keyboard is, and how to orient the keyboard layout. 

docs/feature_stenography.md

@@ -58,7 +58,7 @@ On the display tab click 'Open stroke display'. With Plover disabled you should
 
 ## Interfacing with the code :id=interfacing-with-the-code
 
-The steno code has three interceptible hooks. If you define these functions, they will be called at certain points in processing; if they return true, processing continues, otherwise it's assumed you handled things.
+The steno code has three interceptable hooks. If you define these functions, they will be called at certain points in processing; if they return true, processing continues, otherwise it's assumed you handled things.
 
 ```c
 bool send_steno_chord_user(steno_mode_t mode, uint8_t chord[6]);

docs/feature_tap_dance.md

@@ -28,7 +28,9 @@ After this, you'll want to use the `tap_dance_actions` array to specify what act
 * `ACTION_TAP_DANCE_LAYER_TOGGLE(kc, layer)`: Sends the `kc` keycode when tapped once, or toggles the state of `layer`. (this functions like the `TG` layer keycode).
 * `ACTION_TAP_DANCE_FN(fn)`: Calls the specified function - defined in the user keymap - with the final tap count of the tap dance action.
 * `ACTION_TAP_DANCE_FN_ADVANCED(on_each_tap_fn, on_dance_finished_fn, on_dance_reset_fn)`: Calls the first specified function - defined in the user keymap - on every tap, the second function when the dance action finishes (like the previous option), and the last function when the tap dance action resets.
-* `ACTION_TAP_DANCE_FN_ADVANCED_TIME(on_each_tap_fn, on_dance_finished_fn, on_dance_reset_fn, tap_specific_tapping_term)`: This functions identically to the `ACTION_TAP_DANCE_FN_ADVANCED` function, but uses a custom tapping term for it, instead of the predefined `TAPPING_TERM`.
+* ~~`ACTION_TAP_DANCE_FN_ADVANCED_TIME(on_each_tap_fn, on_dance_finished_fn, on_dance_reset_fn, tap_specific_tapping_term)`~~: This functions identically to the `ACTION_TAP_DANCE_FN_ADVANCED` function, but uses a custom tapping term for it, instead of the predefined `TAPPING_TERM`.
+    * This is deprecated in favor of the Per Key Tapping Term functionality, as outlined [here](custom_quantum_functions.md#Custom_Tapping_Term). You'd want to check for the specific `TD()` macro that you want to use (such as `TD(TD_ESC_CAPS)`) instead of using this specific Tap Dance function.
+
 
 The first option is enough for a lot of cases, that just want dual roles. For example, `ACTION_TAP_DANCE_DOUBLE(KC_SPC, KC_ENT)` will result in `Space` being sent on single-tap, `Enter` otherwise. 
 

docs/flashing.md

@@ -239,3 +239,4 @@ There are a number of DFU commands that you can use to flash firmware to a STM32
 * `: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. 
+* `:st-flash` - This allows you to flash the firmware via the `st-flash` utility from [STLink Tools](https://github.com/stlink-org/stlink), rather than dfu-util.

docs/getting_started_make_guide.md

@@ -101,10 +101,6 @@ This allows you to send Unicode characters by inputting a mnemonic corresponding
 
 For further details, as well as limitations, see the [Unicode page](feature_unicode.md).
 
-`BLUETOOTH_ENABLE`
-
-This allows you to interface with a Bluefruit EZ-key to send keycodes wirelessly. It uses the D2 and D3 pins.
-
 `AUDIO_ENABLE`
 
 This allows you output audio on the C6 pin (needs abstracting). See the [audio page](feature_audio.md) for more information.

docs/hardware_avr.md

@@ -67,7 +67,7 @@ The `config.h` file is where you configure the hardware and feature set for your
 
 At the top of the `config.h` you'll find USB related settings. These control how your keyboard appears to the Operating System. If you don't have a good reason to change you should leave the `VENDOR_ID` as `0xFEED`. For the `PRODUCT_ID` you should pick a number that is not yet in use.
 
-Do change the `MANUFACTURER`, `PRODUCT`, and `DESCRIPTION` lines to accurately reflect your keyboard.
+Do change the `MANUFACTURER` and `PRODUCT` lines to accurately reflect your keyboard.
 
 ```c
 #define VENDOR_ID       0xFEED
@@ -75,7 +75,6 @@ Do change the `MANUFACTURER`, `PRODUCT`, and `DESCRIPTION` lines to accurately r
 #define DEVICE_VER      0x0001
 #define MANUFACTURER    You
 #define PRODUCT         my_awesome_keyboard
-#define DESCRIPTION     A custom keyboard
 ```
 
 ?> Windows and macOS will display the `MANUFACTURER` and `PRODUCT` in the list of USB devices. `lsusb` on Linux instead takes these from the list maintained by the [USB ID Repository](http://www.linux-usb.org/usb-ids.html) by default. `lsusb -v` will show the values reported by the device, and they are also present in kernel logs after plugging it in.

docs/hardware_keyboard_guidelines.md

@@ -192,7 +192,7 @@ When developing your keyboard, keep in mind that all warnings will be treated as
 
 ## Copyright Blurb
 
-If you're adapting your keyboard's setup from another project, but not using the same code, but sure to update the copyright header at the top of the files to show your name, in this format:
+If you're adapting your keyboard's setup from another project, but not using the same code, be sure to update the copyright header at the top of the files to show your name, in this format:
 
     Copyright 2017 Your Name <your@email.com>
 

docs/i2c_driver.md

@@ -81,8 +81,8 @@ STM32 MCUs allows a variety of pins to be configured as I2C pins depending on th
 |--------------------------|----------------------------------------------------------------------------------------------|---------|
 | `I2C1_SCL_BANK`          | The bank of pins (`GPIOA`, `GPIOB`, `GPIOC`) to use for SCL                                  | `GPIOB` |
 | `I2C1_SDA_BANK`          | The bank of pins (`GPIOA`, `GPIOB`, `GPIOC`) to use for SDA                                  | `GPIOB` |
-| `I2C1_SCL`               | The pin number for the SCL pin (0-9)                                                         | `6`     |
-| `I2C1_SDA`               | The pin number for the SDA pin (0-9)                                                         | `7`     |
+| `I2C1_SCL`               | The pin number for the SCL pin (0-15)                                                        | `6`     |
+| `I2C1_SDA`               | The pin number for the SDA pin (0-15)                                                        | `7`     |
 | `I2C1_BANK` (deprecated) | The bank of pins (`GPIOA`, `GPIOB`, `GPIOC`), superceded by `I2C1_SCL_BANK`, `I2C1_SDA_BANK` | `GPIOB` |
 
 The ChibiOS I2C driver configuration depends on STM32 MCU:

docs/isp_flashing_guide.md

@@ -141,7 +141,9 @@ To do this manually:
 
 ?> It's possible to use other bootloaders here in the same way, but __you need a bootloader__, otherwise you'll have to use ISP again to write new firmware to your keyboard.
 
-To do this the easy way, you can flash the board using the `:production` target when compiling.  This compiles the firmware, then compiles the QMK DFU bootloader, and then creates a combined image.  Once this is done, you'll see three files: 
+#### Create QMK DFU Bootloader and Production images
+
+You can create the firmware, the QMK DFU Bootloader and the production firmware images for the board using the `:production` target when compiling.  Once this is done, you'll see three files: 
 * `<keyboard>_<keymap>.hex`
 * `<keyboard>_<keymap>_bootloader.hex`
 * `<keyboard>_<keymap>_production.hex`
@@ -236,12 +238,12 @@ For Caterina on the `atmega32u4`, these are the fuse settings that you want:
 | Fuse     | Setting|
 |----------|--------|
 | Low      | `0xFF` |
-| High     | `0xD9` |
-| Extended | `0xC3` |
+| High     | `0xD8` |
+| Extended | `0xCB` |
 
-To set this add `-U lfuse:w:0xFF:m -U hfuse:w:0xD8:m -U efuse:w:0xC3:m` to your command.  So the final command should look something like: 
+To set this add `-U lfuse:w:0xFF:m -U hfuse:w:0xD8:m -U efuse:w:0xCB:m` to your command.  So the final command should look something like: 
 
-    avrdude -c avrisp -P COM3 -p atmega32u4 -U flash:w:main.hex:i -U lfuse:w:0xFF:m -U hfuse:w:0xD8:m -U efuse:w:0xC3:m
+    avrdude -c avrisp -P COM3 -p atmega32u4 -U flash:w:main.hex:i -U lfuse:w:0xFF:m -U hfuse:w:0xD8:m -U efuse:w:0xCB:m
 
 
 If you are using a different controller or want different configuration, you can use [this AVR Fuse Calculator](http://www.engbedded.com/fusecalc/) to find a better value for you.

docs/ja/_summary.md

@@ -6,6 +6,7 @@
   * [テストとデバッグ](ja/newbs_testing_debugging.md)
   * [手助けを得る/サポート](ja/support.md)
   * [他のリソース](ja/newbs_learn_more_resources.md)
+  * [シラバス](ja/syllabus.md)
 
 * FAQ
   * [一般的な FAQ](ja/faq_general.md)
@@ -33,7 +34,9 @@
     * [機能のカスタマイズ](ja/custom_quantum_functions.md)
     * [Zadig を使ったドライバのインストール](ja/driver_installation_zadig.md)
     * [キーマップの概要](ja/keymap.md)
-    * [Vagrant のガイド](ja/getting_started_vagrant.md)
+    * 開発環境
+      * [Docker のガイド](ja/getting_started_docker.md)
+      * [Vagrant のガイド](ja/getting_started_vagrant.md)
     * 書き込み
       * [書き込み](ja/flashing.md)
       * [ATmega32A の書き込み (ps2avrgb)](ja/flashing_bootloadhid.md)
@@ -52,6 +55,7 @@
   * 単純なキーコード
     * [完全なリスト](ja/keycodes.md)
     * [基本的なキーコード](ja/keycodes_basic.md)
+    * [言語固有のキーコード](ja/reference_keymap_extras.md)
     * [修飾キー](ja/feature_advanced_keycodes.md)
     * [Quantum キーコード](ja/quantum_keycodes.md)
 
@@ -72,9 +76,10 @@
     * [デバウンス API](ja/feature_debounce_type.md)
     * [キーロック](ja/feature_key_lock.md)
     * [レイヤー](ja/feature_layers.md)
-    * [One Shot Keys](ja/one_shot_keys.md)
+    * [ワンショットキー](ja/one_shot_keys.md)
     * [ポインティング デバイス](ja/feature_pointing_device.md)
-    * [Swap Hands](ja/feature_swap_hands.md)
+    * [ロー HID](ja/feature_rawhid.md)
+    * [スワップハンド](ja/feature_swap_hands.md)
     * [タップダンス](ja/feature_tap_dance.md)
     * [タップホールド設定](ja/tap_hold.md)
     * [ターミナル](ja/feature_terminal.md)
@@ -98,18 +103,21 @@
     * [DIP スイッチ](ja/feature_dip_switch.md)
     * [エンコーダ](ja/feature_encoders.md)
     * [触覚フィードバック](ja/feature_haptic_feedback.md)
-    * [Proton C 規約](ja/proton_c_conversion.md)
+    * [Proton C 変換](ja/proton_c_conversion.md)
     * [PS/2 マウス](ja/feature_ps2_mouse.md)
     * [分割キーボード](ja/feature_split_keyboard.md)
-    * [Stenography](ja/feature_stenography.md)
+    * [速記](ja/feature_stenography.md)
     * [感熱式プリンタ](ja/feature_thermal_printer.md)
     * [Velocikey](ja/feature_velocikey.md)
 
 * QMK の開発
+  * [PR チェックリスト](ja/pr_checklist.md)
   * 互換性を破る変更/Breaking changes
     * [概要](ja/breaking_changes.md)
     * [プルリクエストにフラグが付けられた](ja/breaking_changes_instructions.md)
     * 履歴
+      * [2020年8月29日](ja/ChangeLog/20200829.md)
+      * [2020年5月30日](ja/ChangeLog/20200530.md)
       * [2020年2月29日](ja/ChangeLog/20200229.md)
       * [2019年8月30日](ja/ChangeLog/20190830.md)
 
@@ -124,7 +132,8 @@
       * [SPI ドライバ](ja/spi_driver.md)
       * [WS2812 ドライバ](ja/ws2812_driver.md)
       * [EEPROM ドライバ](ja/eeprom_driver.md)
-    * [GPIO コントロール](ja/internals_gpio_control.md)
+      * [シリアル ドライバ](ja/serial_driver.md)
+    * [GPIO 制御](ja/internals_gpio_control.md)
     * [キーボード ガイドライン](ja/hardware_keyboard_guidelines.md)
 
   * Python 開発
@@ -136,6 +145,11 @@
       * [開発環境](ja/api_development_environment.md)
       * [アーキテクチャの概要](ja/api_development_overview.md)
 
+  * ハードウェアプラットフォーム開発
+    * Arm/ChibiOS
+      * [MCU の選択](ja/platformdev_selecting_arm_mcu.md)
+      * [早期初期化](ja/platformdev_chibios_earlyinit.md)
+
   * QMK Reference
     * [QMK への貢献](ja/contributing.md)
     * [QMK ドキュメントの翻訳](ja/translating.md)
@@ -155,9 +169,9 @@
 
   * QMK の内部詳細(作成中)
     * [定義](ja/internals_defines.md)
-    * [Input Callback Reg](ja/internals_input_callback_reg.md)
+    * [入力コールバック登録](ja/internals_input_callback_reg.md)
     * [Midi デバイス](ja/internals_midi_device.md)
     * [Midi デバイスのセットアップ手順](ja/internals_midi_device_setup_process.md)
     * [Midi ユーティリティ](ja/internals_midi_util.md)
-    * [Send Functions](ja/internals_send_functions.md)
+    * [Midi 送信関数](ja/internals_send_functions.md)
     * [Sysex Tools](ja/internals_sysex_tools.md)

docs/ja/api_development_environment.md

@@ -0,0 +1,8 @@
+# 開発環境のセットアップ
+
+<!---
+  original document: 0.9.50:docs/api_development_environment.md
+  git diff 0.9.50 HEAD -- docs/api_development_environment.md | cat
+-->
+
+開発環境をセットアップするには、[qmk_web_stack](https://github.com/qmk/qmk_web_stack) に行ってください。

docs/ja/api_development_overview.md

@@ -0,0 +1,49 @@
+# QMK コンパイラ開発ガイド	 
+
+<!---
+  original document: 0.9.50:docs/api_development_overview.md
+  git diff 0.9.50 HEAD -- docs/api_development_overview.md | cat
+-->
+
+このページでは、開発者に QMK コンパイラを紹介しようと思います。コードを読まなければならないような核心となる詳細に立ち入って調べることはしません。ここで得られるものは、コードを読んで理解を深めるためのフレームワークです。
+
+# 概要
+
+QMK Compile API は、いくつかの可動部分からできています:
+
+![構造図](https://raw.githubusercontent.com/qmk/qmk_api/master/docs/architecture.svg)
+
+API クライアントは API サービスと排他的にやりとりをします。ここでジョブをサブミットし、状態を調べ、結果をダウンロードします。API サービスはコンパイルジョブを [Redis Queue](https://python-rq.org) に挿入し、それらのジョブの結果について RQ と S3 の両方を調べます。
+
+ワーカーは RQ から新しいコンパイルジョブを取り出し、ソースとバイナリを S3 互換のストレージエンジンにアップロードします。
+
+# ワーカー
+
+QMK コンパイラワーカーは実際のビルド作業に責任を持ちます。ワーカーは RQ からジョブを取り出し、ジョブを完了するためにいくつかの事を行います:
+
+* 新しい qmk_firmware のチェックアウトを作成する
+* 指定されたレイヤーとキーボードメタデータを使って `keymap.c` をビルドする
+* ファームウェアをビルドする
+* ソースのコピーを zip 形式で圧縮する
+* ファームウェア、ソースの zip ファイル、メタデータファイルを S3 にアップロードする
+* ジョブの状態を RQ に送信する
+
+# API サービス
+
+API サービスは比較的単純な Flask アプリケーションです。理解しておくべきことが幾つかあります。
+
+## @app.route('/v1/compile', methods=['POST'])
+
+これは API の主なエントリーポイントです。クライアントとのやりとりはここから開始されます。クライアントはキーボードを表す JSON ドキュメントを POST し、API はコンパイルジョブをサブミットする前にいくらかの(とても)基本的な検証を行います。
+
+## @app.route('/v1/compile/&lt;string:job_id&gt;', methods=['GET'])
+
+これは最もよく呼ばれるエンドポイントです。ジョブの詳細が redis から利用可能であればそれを取り出し、そうでなければ S3 からキャッシュされたジョブの詳細を取り出します。
+
+## @app.route('/v1/compile/&lt;string:job_id&gt;/download', methods=['GET'])
+
+このメソッドによりユーザはコンパイルされたファームウェアファイルをダウンロードすることができます。
+
+## @app.route('/v1/compile/&lt;string:job_id&gt;/source', methods=['GET'])
+
+このメソッドによりユーザはファームウェアのソースをダウンロードすることができます。

docs/ja/api_docs.md

@@ -0,0 +1,73 @@
+# QMK API
+
+<!---
+  original document: 0.9.50:docs/api_docs.md
+  git diff 0.9.50 HEAD -- docs/api_docs.md | cat
+-->
+
+このページは QMK API の使い方を説明します。もしあなたがアプリケーション開発者であれば、全ての [QMK](https://qmk.fm) キーボードのファームウェアをコンパイルするために、この API を使うことができます。
+
+## 概要
+
+このサービスは、カスタムキーマップをコンパイルするための非同期 API です。API に 何らかの JSON を POST し、定期的に状態をチェックし、ファームウェアのコンパイルが完了していれば、結果のファームウェアと(もし希望すれば)そのファームウェアのソースコードをダウンロードすることができます。
+
+#### JSON ペイロードの例:
+
+```json
+{
+  "keyboard": "clueboard/66/rev2",
+  "keymap": "my_awesome_keymap",
+  "layout": "LAYOUT_all",
+  "layers": [
+    ["KC_GRV","KC_1","KC_2","KC_3","KC_4","KC_5","KC_6","KC_7","KC_8","KC_9","KC_0","KC_MINS","KC_EQL","KC_GRV","KC_BSPC","KC_PGUP","KC_TAB","KC_Q","KC_W","KC_E","KC_R","KC_T","KC_Y","KC_U","KC_I","KC_O","KC_P","KC_LBRC","KC_RBRC","KC_BSLS","KC_PGDN","KC_CAPS","KC_A","KC_S","KC_D","KC_F","KC_G","KC_H","KC_J","KC_K","KC_L","KC_SCLN","KC_QUOT","KC_NUHS","KC_ENT","KC_LSFT","KC_NUBS","KC_Z","KC_X","KC_C","KC_V","KC_B","KC_N","KC_M","KC_COMM","KC_DOT","KC_SLSH","KC_RO","KC_RSFT","KC_UP","KC_LCTL","KC_LGUI","KC_LALT","KC_MHEN","KC_SPC","KC_SPC","KC_HENK","KC_RALT","KC_RCTL","MO(1)","KC_LEFT","KC_DOWN","KC_RIGHT"],
+    ["KC_ESC","KC_F1","KC_F2","KC_F3","KC_F4","KC_F5","KC_F6","KC_F7","KC_F8","KC_F9","KC_F10","KC_F11","KC_F12","KC_TRNS","KC_DEL","BL_STEP","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","_______","KC_TRNS","KC_PSCR","KC_SLCK","KC_PAUS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","MO(2)","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_PGUP","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","MO(1)","KC_LEFT","KC_PGDN","KC_RGHT"],
+    ["KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","RESET","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","MO(2)","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","KC_TRNS","MO(1)","KC_TRNS","KC_TRNS","KC_TRNS"]
+  ]
+}
+```
+
+ご覧のとおり、ペイロードにはファームウェアを作成および生成するために必要なキーボードの全ての側面を記述します。各レイヤーは QMK キーコードの1つのリストで、キーボードの `LAYOUT` マクロと同じ長さです。もしキーボードが複数の `LAYOUT` マクロをサポートする場合、どのマクロを使うかを指定することができます。
+
+## コンパイルジョブのサブミット
+
+キーマップをファームウェアにコンパイルするには、単純に JSON を `/v1/compile` エンドポイントに POST します。以下の例では、JSON ペイロードを `json_data` という名前のファイルに配置しています。
+
+```
+$ curl -H "Content-Type: application/json" -X POST -d "$(< json_data)" http://api.qmk.fm/v1/compile
+{
+  "enqueued": true,
+  "job_id": "ea1514b3-bdfc-4a7b-9b5c-08752684f7f6"
+}
+```
+
+## 状態のチェック
+
+キーマップをサブミットした後で、簡単な HTTP GET 呼び出しを使って状態をチェックすることができます:
+
+```
+$ curl http://api.qmk.fm/v1/compile/ea1514b3-bdfc-4a7b-9b5c-08752684f7f6
+{
+  "created_at": "Sat, 19 Aug 2017 21:39:12 GMT",
+  "enqueued_at": "Sat, 19 Aug 2017 21:39:12 GMT",
+  "id": "f5f9b992-73b4-479b-8236-df1deb37c163",
+  "status": "running",
+  "result": null
+}
+```
+
+これは、ジョブをキューに入れることに成功し、現在実行中であることを示しています。5つの状態がありえます:
+
+* **failed**: なんらかの理由でコンパイルサービスが失敗しました。
+* **finished**: コンパイルが完了し、結果を見るには `result` をチェックする必要があります。
+* **queued**: キーマップはコンパイルサーバが利用可能になるのを待っています。
+* **running**: コンパイルが進行中で、まもなく完了するはずです。
+* **unknown**: 深刻なエラーが発生し、[バグを報告](https://github.com/qmk/qmk_compiler/issues)する必要があります。
+
+## 完了した結果を検証
+
+コンパイルジョブが完了したら、`result` キーをチェックします。このキーの値は幾つかの情報を含むハッシュです:
+
+* `firmware_binary_url`: 書き込み可能なファームウェアの URL のリスト
+* `firmware_keymap_url`: `keymap.c` の URL のリスト
+* `firmware_source_url`: ファームウェアの完全なソースコードの URL のリスト
+* `output`: このコンパイルジョブの stdout と stderr。エラーはここで見つけることができます。

docs/ja/api_overview.md

@@ -0,0 +1,20 @@
+# QMK API
+
+<!---
+  original document: 0.9.50:docs/api_overview.md
+  git diff 0.9.50 HEAD -- docs/api_overview.md | cat
+-->
+
+QMK API は、Web と GUI ツールが [QMK](http://qmk.fm/) によってサポートされるキーボード用の任意のキーマップをコンパイルするために使うことができる、非同期 API を提供します。標準のキーマップテンプレートは、C コードのサポートを必要としない全ての QMK キーコードをサポートします。キーボードのメンテナは独自のカスタムテンプレートを提供して、より多くの機能を実現することができます。
+
+## アプリケーション開発者
+
+もしあなたがアプリケーションでこの API を使うことに興味があるアプリケーション開発者であれば、[API の使用](ja/api_docs.md) に行くべきです。
+
+## キーボードのメンテナ
+
+もし QMK Compiler API でのあなたのキーボードのサポートを強化したい場合は、[キーボードサポート](ja/reference_configurator_support.md) の節に行くべきです。
+
+## バックエンド開発者
+
+もし API 自体に取り組むことに興味がある場合は、[開発環境](ja/api_development_environment.md)のセットアップから始め、それから [API のハッキング](ja/api_development_overview.md) を調べるべきです。

docs/ja/breaking_changes.md

@@ -2,8 +2,8 @@
 
 <!---
   grep --no-filename "^[ ]*git diff" docs/ja/*.md | sh
-  original document: 0.9.0:docs/breaking_changes.md
-  git diff 0.9.0 HEAD -- docs/breaking_changes.md | cat
+  original document: 0.10.33:docs/breaking_changes.md
+  git diff 0.10.33 HEAD -- docs/breaking_changes.md | cat
 -->
 
 このドキュメントは QMK の互換性を破る変更(Breaking change) のプロセスについて説明します。
@@ -15,22 +15,23 @@ Breaking change ピリオドとは、危険な変更、または予想外の変
 
 ## 過去の Breaking change には何が含まれますか？
 
+* [2020年8月29日](ja/ChangeLog/20200829.md)
 * [2020年5月30日](ja/ChangeLog/20200530.md)
 * [2020年2月29日](ja/ChangeLog/20200229.md)
 * [2019年8月30日](ja/ChangeLog/20190830.md)
 
 ## 次の Breaking change はいつですか？
 
-次の Breaking change は2020年8月29日に予定されています。
+次の Breaking change は2020年11月28日に予定されています。
 
 ### 重要な日付
 
-* [x] 2020年 5月30日 - `develop` が作成されました。毎週リベースされます。
-* [ ] 2020年 8月 1日 - `develop` は新しいPRを取り込みません。
-* [ ] 2020年 8月 1日 - テスターの募集。
-* [ ] 2020年 8月27日 - `master`がロックされ、PR はマージされません。
-* [ ] 2020年 8月29日 - `develop` を `master` にマージします。
-* [ ] 2020年 8月29日 - `master` のロックが解除されます。PR を再びマージすることができます。
+* [x] 2020年 8月29日 - `develop` が作成されました。毎週リベースされます。
+* [ ] 2020年10月31日 - `develop` は新しいPRを取り込みません。
+* [ ] 2020年10月31日 - テスターの募集。
+* [ ] 2020年11月26日 - `master`がロックされ、PR はマージされません。
+* [ ] 2020年11月28日 - `develop` を `master` にマージします。
+* [ ] 2020年11月28日 - `master` のロックが解除されます。PR を再びマージすることができます。
 
 ## どのような変更が含まれますか？
 

docs/ja/cli_development.md

@@ -0,0 +1,223 @@
+# QMK CLI 開発
+
+<!---
+  original document: 0.9.19:docs/cli_development.md
+  git diff 0.9.19 HEAD -- docs/cli_development.md | cat
+-->
+
+このドキュメントは、新しい `qmk`  サブコマンドを書きたい開発者に役立つ情報が含まれています。
+
+# 概要
+
+QMK CLI は git で有名になったサブコマンドパターンを使って動作します。メインの `qmk` スクリプトは単に環境をセットアップし、実行する正しいエントリポイントを選択するためにあります。各サブコマンドは、何らかのアクションを実行しシェルのリターンコード、または None を返すエントリーポイント (`@cli.subcommand()` で修飾されます)を備えた自己完結型のモジュールです。
+
+## 開発者モード:
+
+キーボードを保守、あるいは QMK に貢献したい場合は、CLI の「開発者」モードを有効にすることができます:
+
+`qmk config user.developer=True`
+
+これにより利用可能な全てのサブコマンドが表示されます。
+**注意:** 追加で必要なものをインストールする必要があります:
+```bash
+python3 -m pip install -r requirements-dev.txt
+```
+
+# サブコマンド
+
+[MILC](https://github.com/clueboard/milc) は、`qmk` が引数の解析、設定、ログ、およびほかの多くの機能を処理するために使用する CLI フレームワークです。グルーコードを書くために時間を無駄にすることなく、ツールの作成に集中できます。
+
+ローカル CLI 内のサブコマンドは、常に `qmk_firmware/lib/python/qmk/cli` で見つかります。
+
+サブコマンドの例を見てみましょう。これは `lib/python/qmk/cli/hello.py` です:
+
+```python
+"""QMK Python Hello World
+
+This is an example QMK CLI script.
+"""
+from milc import cli
+
+
+@cli.argument('-n', '--name', default='World', help='Name to greet.')
+@cli.subcommand('QMK Hello World.')
+def hello(cli):
+    """Log a friendly greeting.
+    """
+    cli.log.info('Hello, %s!', cli.config.hello.name)
+```
+
+最初に `milc` から `cli` をインポートします。これが、ユーザとやり取りをし、スクリプトの挙動を制御する方法です。`@cli.argument()` を使って、コマンドラインフラグ `--name` を定義します。これは、ユーザが設定できる `hello.name` (そして対応する `user.name`) という名前の設定変数も作成し、引数を指定する必要が無くなります。`cli.subcommand()` デコレータは、この関数をサブコマンドとして指定します。サブコマンドの名前は関数の名前から取られます。
+
+関数の中に入ると、典型的な "Hello, World!" プログラムが見つかります。`cli.log` を使って、基礎となる [ロガーオブジェクト](https://docs.python.org/3.6/library/logging.html#logger-objects) にアクセスし、その挙動はユーザが制御できます。またユーザが指定した名前の値に `cli.config.hello.name` でアクセスします。`cli.config.hello.name` の値は、ユーザが指定した `--name` 引数を調べることで決定されます。指定されていない場合、`qmk.ini` 設定ファイルの中の値が使われ、どちらも指定されていない場合は `cli.argument()`  デコレータで指定されたデフォルトが代用されます。
+
+# ユーザとの対話処理
+
+MILC と QMK CLI にはユーザとやり取りするための幾つかの便利なツールがあります。これらの標準ツールを使うと、テキストに色を付けて対話し易くし、ユーザはその情報をいつどのように表示および保存するかを制御することができます。
+
+## テキストの表示
+
+サブコマンド内でテキストを出力するための2つの主な方法があります- `cli.log` と `cli.echo()`。それらは似た方法で動作しますが、ほとんどの一般的な目的の出力には `cli.log.info()` を使うことをお勧めします。
+
+特別なトークンを使用してテキストを色付けし、プログラムの出力を理解しやすくすることができます。以下の[テキストの色付け](#colorizing-text)を見てください。
+
+これらの両方の方法は python の [printf 形式の文字列書式化](https://docs.python.org/3.6/library/stdtypes.html#old-string-formatting) を使った組み込みの文字列書式化をサポートします。テキスト文字列内で`%s` と `%d` のようなトークンを使い、引数で値を渡すことができます。例として、上記の Hello、World プログラムを見てください。
+
+書式演算子 (`%`) を直接使わないでください、常に引数で値を渡します。
+
+### ログ (`cli.log`)
+
+`cli.log` オブジェクトは[ロガーオブジェクト](https://docs.python.org/3.6/library/logging.html#logger-objects)へのアクセスを与えます。ログ出力を設定し、ユーザに各ログレベルの素敵な絵文字(またはターミナルが unicode をサポートしない場合はログレベル名)を表示します。このようにして、ユーザは何か問題が発生した時に最も重要なメッセージを一目で確認することができます。
+
+デフォルトのログレベルは `INFO` です。ユーザが `qmk -v <subcommand>` を実行すると、デフォルトのログレベルは `DEBUG` に設定されます。
+
+| 関数 | 絵文字 |
+|----------|-------|
+| cli.log.critical | `{bg_red}{fg_white}¬_¬{style_reset_all}` |
+| cli.log.error | `{fg_red}☒{style_reset_all}` |
+| cli.log.warning | `{fg_yellow}⚠{style_reset_all}` |
+| cli.log.info | `{fg_blue}Ψ{style_reset_all}` |
+| cli.log.debug | `{fg_cyan}☐{style_reset_all}` |
+| cli.log.notset | `{style_reset_all}¯\\_(o_o)_/¯` |
+
+### 出力 (`cli.echo`)
+
+場合によっては単にログシステムの外部でテキストを出力する必要があります。これは、固定データを出力したり、ログに記録してはいけない何かを書きだす場合に適しています。ほとんどの場合、`cli.echo` よりも `cli.log.info()` を選ぶべきです。
+
+### テキストの色付け
+
+テキスト内に色トークンを含めることで、テキストの出力を色付けすることができます。情報を伝えるためではなく、強調するために色を使います。ユーザは色を無効にできることを覚えておいてください。色を無効にした場合でもサブコマンドは引き続き使えるようにしてください。
+
+背景色を設定するのは、あなたがやっていることに不可欠ではない限り、通常は避けるべきです。ユーザは、ターミナルの色に関しては多くの好みを持つため、あなたは黒と白のどちらの背景に対してもうまく機能する色を選択する必要があることを覚えておいてください。
+
+'fg' という接頭辞の付いた色は、前景(テキスト)色に影響します。'bg' という接頭辞の付いた色は、背景色に影響します。
+
+| 色 | 背景 | 拡張背景 | 前景 | 拡張前景 |
+|-------|------------|---------------------|------------|--------------------|
+| 黒 | {bg_black} | {bg_lightblack_ex} | {fg_black} | {fg_lightblack_ex} |
+| 青 | {bg_blue} | {bg_lightblue_ex} | {fg_blue} | {fg_lightblue_ex} |
+| シアン | {bg_cyan} | {bg_lightcyan_ex} | {fg_cyan} | {fg_lightcyan_ex} |
+| 緑 | {bg_green} | {bg_lightgreen_ex} | {fg_green} | {fg_lightgreen_ex} |
+| マゼンタ | {bg_magenta} | {bg_lightmagenta_ex} | {fg_magenta} | {fg_lightmagenta_ex} |
+| 赤 | {bg_red} | {bg_lightred_ex} | {fg_red} | {fg_lightred_ex} |
+| 白 | {bg_white} | {bg_lightwhite_ex} | {fg_white} | {fg_lightwhite_ex} |
+| 黄 | {bg_yellow} | {bg_lightyellow_ex} | {fg_yellow} | {fg_lightyellow_ex} |
+
+ANSI 出力の挙動を変更するために使うことができる制御シーケンスもあります。
+
+| 制御シーケンス | 説明 |
+|-------------------|-------------|
+| {style_bright} | テキストを明るくする |
+| {style_dim} | テキストを暗くする |
+| {style_normal} | テキストを通常にする (`{style_bright}` または `{style_dim}` のどちらでもない) |
+| {style_reset_all} | 全てのテキストの属性をデフォルトに再設定する(これは自動的に全ての文字列の最後に自動的に追加されます。) |
+| {bg_reset} | 背景色をユーザのデフォルトに再設定します。 |
+| {fg_reset} | 背景色をユーザのデフォルトに再設定します。 |
+
+# 引数と設定
+
+QMK は引数の解析と設定の詳細をあなたの代わりに処理します。新しい引数を追加すると、サブコマンドの名前と引数の長い名前に基づいて設定ツリーに自動的に組み込まれます。属性形式のアクセス (`cli.config.<subcommand>.<argument>`) あるいは辞書形式のアクセス (`cli.config['<subcommand>']['<argument>']`) を使って、`cli.config` 内のこの設定にアクセスすることができます。
+
+内部では、QMK は [設定ファイルのパーサ](https://docs.python.org/3/library/configparser.html) を使って設定を格納します。これにより、人間が編集可能な方法で設定を表す簡単で分かり易い方法を提供します。この設定へのアクセスをラップして、設定ファイルのパーサーが通常持たない幾つかの機能を提供しています。
+
+## 設定値の読み込み
+
+通常期待される全ての方法で `cli.config` とやり取りすることができます。例えば、`qmk compile` コマンドは `cli.config.compile.keyboard` からキーボード名を取得します。値がコマンドライン、環境変数あるいは設定ファイルからきたものであるかどうかを知る必要はありません。
+
+繰り返しもサポートされます:
+
+```
+for section in cli.config:
+    for key in cli.config[section]:
+        cli.log.info('%s.%s: %s', section, key, cli.config[section][key])
+```
+
+## 設定値の設定
+
+通常の方法で設定値を設定することができます。
+
+辞書形式:
+
+```
+cli.config['<section>']['<key>'] = <value>
+```
+
+属性形式:
+
+```
+cli.config.<section>.<key> = <value>
+```
+
+## 設定値の削除
+
+通常の方法で設定値を削除することができます。
+
+辞書形式:
+
+```
+del(cli.config['<section>']['<key>'])
+```
+
+属性形式:
+
+```
+del(cli.config.<section>.<key>)
+```
+
+## 設定ファイルの書き方
+
+設定は変更しても書き出されません。ほとんどのコマンドでこれをする必要はありません。ユーザに `qmk config` を使って設定を慎重に変更させることをお勧めします。
+
+設定を書き出すために `cli.save_config()` を使うことができます。
+
+## 設定からの引数の除外
+
+一部の引数は設定ファイルに反映すべきではありません。これらは引数を作成する時に `arg_only=True` を追加することで除外することができます。
+
+例:
+
+```
+@cli.argument('-o', '--output', arg_only=True, help='File to write to')
+@cli.argument('filename', arg_only=True, help='Configurator JSON file')
+@cli.subcommand('Create a keymap.c from a QMK Configurator export.')
+def json_keymap(cli):
+    pass
+```
+
+`cli.args` を使ってのみこれらの引数にアクセスすることができます。例えば:
+
+```
+cli.log.info('Reading from %s and writing to %s', cli.args.filename, cli.args.output)
+```
+
+# テスト、リントおよびフォーマット
+
+nose2、flake8 および yapf を使ってコードをテスト、リントおよびフォーマットします。これらのテストを実行するために `pytest` と `pyformat` サブコマンドを使うことができます。
+
+### テストとリント
+
+    qmk pytest
+
+### フォーマット
+
+    qmk pyformat
+
+## フォーマットの詳細
+
+[yapf](https://github.com/google/yapf) を使ってコードを自動的にフォーマットします。フォーマットの設定は `setup.cfg` の `[yapf]` セクションにあります。
+
+?> ヒント- 多くのエディタは yapf をプラグインとして使って、入力したコードを自動的にフォーマットすることができます。
+
+## テストの詳細
+
+テストは `lib/python/qmk/tests/` にあります。このディレクトリに単体テストと統合テストの両方があります。コードの単体テストと統合テストの両方を書いてほしいですが、一方のみ書く場合は統合テストを優先してください。
+
+PR にテストの包括的なセットが含まれない場合は、次のようなコメントをコードに追加して、他の人が手助けできるようにしてください:
+
+    # TODO(unassigned/<your_github_username>): Write <unit|integration> tests
+
+[nose2](https://nose2.readthedocs.io/en/latest/getting_started.html) を使ってテストを実行します。テスト関数でできることの詳細については、nose2  のドキュメントを参照してください。
+
+## リントの詳細
+
+flake8 を使ってコードをリントします。PR を開く前に、コードは flake8 をパスしなければなりません。これは `qmk pytest` を実行するときにチェックされ、PR を登録したときに CI によってチェックされます。

docs/ja/coding_conventions_c.md

@@ -0,0 +1,63 @@
+# コーディング規約 (C)
+
+<!---
+  original document: 0.9.19:docs/coding_conventions_c.md
+  git diff 0.9.19 HEAD -- docs/coding_conventions_c.md | cat
+-->
+
+私たちのスタイルのほとんどはかなり理解しやすいですが、現時点では完全に一貫しているわけではありません。変更箇所周辺のコードのスタイルと一致させる必要がありますが、そのコードに一貫性が無い場合や不明瞭な場合は以下のガイドラインに従ってください:
+
+* 4つのスペース (ソフトタブ) を使ってインデントします。
+* 修正版 One True Brace Style を使います。
+   * 開き括弧: ブロックを開始する文と同じ行の最後
+   * 閉じ括弧: ブロックを開始した文と同じ字下げ
+   * Else If: 行の先頭に閉じ括弧を置き、次の開き括弧を同じ行の最後に置きます。
+   * 省略可能な括弧: 常に括弧を付け加えます。
+      * 良い: if (condition) { return false; }
+      * 悪い: if (condition) return false;
+* C 形式のコメントの使用を推奨します: `/* */`
+   * コメントを機能を説明するストーリーと考えて下さい。
+   * 特定の決定がなされた理由を充分なコメントで説明してください。
+   * 分かり切ったコメントは書かないでください。
+   * 分かり切ったコメントであるか確信できない場合は、コメントを含めてください。
+* 一般的に、行を折り返さないで、必要なだけ長くすることができます。行を折り返すことを選択した場合は、76列を超えて折り返さないでください。
+* 古い形式のインクルードガード (`#ifndef THIS_FILE_H`、`#define THIS_FILE_H`、...、`#endif`) ではなく、ヘッダファイルの先頭で `#pragma once` を使います。
+* プリプロセッサ if の両方の形式を受け付けます: `#ifdef DEFINED` と `#if defined(DEFINED)`
+   * どちらがいいかわからない場合は、`#if defined(DEFINED)` 形式を使ってください。
+   * 複数の条件 `#if` に移行する場合を除き、既存のコードを別のスタイルに変更しないでください。
+* プリプロセッサディレクティブをインデントする方法(あるいはするかどうか)を決定する時は、以下の事に留意してください:
+   * 一貫性よりも読みやすさが重要です。
+   * ファイルの既存のスタイルに従ってください。ファイルのスタイルが混在している場合は、修正しようとしているセクションに適したスタイルに従ってください。
+   * インデントする時は、ハッシュを行の先頭に置き、`#` と `if` の間に空白を追加します。`#` の後ろに4つスペースを入れて開始します。
+   * 周りの C コードのインデントレベルに従うか、プリプロセッサのディレクティブに独自のインデントレベルを設定することができます。コードの意図を最もよく伝えるスタイルを選択してください。
+
+わかりやすいように例を示します:
+
+```c
+/* Enums for foo */
+enum foo_state {
+    FOO_BAR,
+    FOO_BAZ,
+};
+
+/* Returns a value */
+int foo(void) {
+    if (some_condition) {
+        return FOO_BAR;
+    } else {
+        return -1;
+    }
+}
+```
+
+# clang-format を使った自動整形
+
+[Clang-format](https://clang.llvm.org/docs/ClangFormat.html) は LLVM の一部で、誰もが手動で整形するほど暇ではないため、コードを自動整形することができます。私たちは、上記のコーディング規約のほとんどを適用する設定ファイルを提供しています。空白と改行のみを変更するため、省略可能な括弧は自分で付け加えることを忘れないでください。
+
+Windows で clang-format を入手するには [full LLVM インストーラ](http://llvm.org/builds/)を使い、Ubuntu では `sudo apt install clang-format` を使ってください。
+
+コマンドラインから実行する場合、オプションとして `-style=file` を渡すと、QMK ルートディレクトリ内の .clang-format 設定ファイルを自動的に見つけます。
+
+VSCode を使う場合は、標準の C/C++ プラグインが clang-format をサポートしますが、その他にも [独立した拡張機能](https://marketplace.visualstudio.com/items?itemName=LLVMExtensions.ClangFormat) があります。
+
+幾つかのコード (LAYOUT マクロのような)が clang-format によって破壊されるため、これらのファイルで clang-format を実行しないか、整形したくないコードを `// clang-format off` と `// clang-format on` で囲みます。

docs/ja/coding_conventions_python.md

@@ -0,0 +1,331 @@
+# コーディング規約 (Python)
+
+<!---
+  original document: 0.9.19:docs/coding_conventions_python.md
+  git diff 0.9.19 HEAD -- docs/coding_conventions_python.md | cat
+-->
+
+私たちのスタイルの大部分は PEP8 に従いますが、神経質にならないように幾つかのローカルな変更を加えています。
+
+* サポートされる全てのプラットフォームとの互換性のために、Python 3.6 を対象にしています。
+* 4つのスペース (ソフトタブ) を使ってインデントします
+* 充分なコメントを書くことを推奨します
+   * コメントを機能を説明するストーリーと考えて下さい
+   * 特定の決定がなされた理由を充分なコメントで説明してください。
+   * 分かり切ったコメントは書かないでください
+   * 分かり切ったコメントであるか確信できない場合は、コメントを含めてください。
+* 全ての関数について、役に立つ docstring を必要とします。
+* 一般的に、行を折り返さないで、必要なだけ長くすることができます。行を折り返すことを選択した場合は、76列を超えて折り返さないでください。
+* 私たちの慣習の幾つかは、Python 使いでは無い人にコードベースをより身近にするために、python コミュニティに広まっているものとは競合しています。
+
+# YAPF
+
+コードを整形するために [yapf](https://github.com/google/yapf) を使うことができます。[setup.cfg](setup.cfg) で設定を提供しています。
+
+# インポート
+
+`import ...` や `from ... import ...` をいつ使うかについての厳密なルールはありません。理解しやすさと保守性が究極の目的です。
+
+一般的に、コードを短く理解しやすくするためにモジュールから特定の関数とクラス名をインポートする方が望ましいです。これにより、名前が曖昧になることがあります。代わりにモジュールをインポートするようにします。互換性のあるモジュールをインポートする時を除いて、インポートする時は "as" キーワードを避けるべきです。
+
+インポートは各モジュール1行にする必要があります。標準的な python ルールに従って、インポート文をシステム、サードパーティ、ローカルにグループ化します。
+
+`from foo import *` を使わないでください。代わりにインポートしたいオブジェクトのリストを指定するか、モジュール全体をインポートします。
+
+## インポートの例
+
+良い:
+
+```
+from qmk import effects
+
+effects.echo()
+```
+
+悪い:
+
+```
+from qmk.effects import echo
+
+echo()  # echoがどこから来たのかが不明瞭です
+```
+
+良い:
+
+```
+from qmk.keymap import compile_firmware
+
+compile_firmware()
+```
+
+良いですが、上の方がより良いです:
+
+```
+import qmk.keymap
+
+qmk.keymap.compile_firmware()
+```
+
+# 命令文
+
+各行1文としてください。
+
+可能な場合(例えば `if foo: bar`)でも、2つの文を1行にまとめないでください。
+
+# 命名
+
+`module_name`, `package_name`, `ClassName`, `method_name`, `ExceptionName`, `function_name`, `GLOBAL_CONSTANT_NAME`, `global_var_name`, `instance_var_name`, `function_parameter_name`, `local_var_name`.
+
+関数名、変数名 およびファイル名は説明的でなければなりません; 略語を避けます。特に、プロジェクト外の読み手に曖昧あるいは馴染みのない略語を使わず、単語内の文字を削除して略さないでください。
+
+常に .py のファイル名の拡張子を使います。ダッシュを使わないでください。
+
+## 避けるべき名前
+
+* カウンタあるいはイテレータ以外の1文字の名前。try/except 文では例外の識別子として `e` を使うことができます。
+* パッケージ/モジュール名内のダッシュ (`-`)
+* `__double_leading_and_trailing_underscore__` (2つのアンダースコアで始まる名前と終わる名前、Python で予約済み)
+
+# Docstring
+
+docstring の一貫性を維持するために、以下のガイドラインを設定しました。
+
+* マークダウン(Markdown)形式の使用
+* 常に少なくとも1つの改行を含む3つのダブルクォートの docstring を使ってください: `"""\n"""`
+* 最初の行は、関数が行うことの短い (70文字未満) 説明です。
+* docstring が更に必要な場合は、説明と残りの間に空白行を入れます。
+* 開始の3つのダブルクォートと同じインデントレベルでインデント行を始めます
+* 以下で説明する形式を使って全ての関数の引数について記述します
+* Args:、Returns: および Raises: が存在する場合、それらは docstring の最後の3つの要素で、それぞれ空白行で区切られなければなりません。
+
+## 簡単な docstring の例
+
+```
+def my_awesome_function():
+    """1970 Jan 1 00:00 UTC からの秒数を返します。
+    """
+    return int(time.time())
+```
+
+## 複雑な docstring の例
+
+```
+def my_awesome_function():
+    """1970 Jan 1 00:00 UTC からの秒数を返します。
+
+    この関数は常に整数の秒数を返します。
+    """
+    return int(time.time())
+```
+
+## 関数の引数の docstring の例
+
+```
+def my_awesome_function(start=None, offset=0):
+    """1970 Jan 1 00:00 UTC からの秒数を返します。
+
+    この関数は常に整数の秒数を返します。
+
+
+    Args:
+        start
+            1970 Jan 1 00:00 UTC の代わりの開始時間
+
+        offset
+            最初の引数からこの秒数が引かれた答えを返します
+
+    Returns:
+        秒数を表す整数。
+
+    Raises:
+        ValueError
+            `start` あるいは `offset` が正の数ではない場合
+    """
+    if start < 0 or offset < 0:
+        raise ValueError('start and offset must be positive numbers.')
+
+    if not start:
+        start = time.time()
+
+    return int(start - offset)
+```
+
+# 例外
+
+例外は例外的な状況を処理するために使われます。フローの制御のために使われるべきではありません。これは Python の「許しを請う」という規範からの逸脱です。例外をキャッチする場合、異常な状況を処理する必要があります。
+
+何らかの理由で全ての例外のキャッチを使う場合は、cli.log を使って例外とスタックトレースを記録する必要があります。
+
+try/except ブロックをできるだけ短くします。多数の try 文が必要な場合は、コードを再構成する必要があるかもしれません。
+
+# タプル
+
+1項目のタプルを定義する場合、タプルを使用していることが明らかになるように、常に末尾のカンマを含めます。暗黙的な1項目のタプルのアンパックに頼らないでください。明確なリストを使う方が良いです。
+
+これはよく使用される printf 形式の書式文字列を使う場合に、特に重要です。
+
+# リストと辞書
+
+シーケンス形式と末尾のカンマとを区別するように YAPF を設定しました。末尾のカンマが省略されると、YAPF はシーケンスを1つの行として整形します。末尾のカンマがある場合、YAPF はシーケンスを1行1項目で整形します。
+
+一般的に1行が短い定義になるようにすべきです。読みやすさと保守性を向上させるために、後からではなく早めに複数の行を分割してください。
+
+# 括弧
+
+過度な括弧は避けますが、括弧を使ってコードを理解しやすくします。タプルを明示的に返すか、あるいは数式の一部である場合を除き、return 文で括弧を使わないでください。
+
+# 書式文字列
+
+一般的に printf 形式の書式文字列を用います。例:
+
+```
+name = 'World'
+print('Hello, %s!' % (name,))
+```
+
+このスタイルはログモジュールで使われており、私たちはそれを広範囲で利用しており、一貫性を保つために他の場所でも採用しています。これは、私たちの気まぐれな読者の大部分である C プログラマにもおなじみのスタイルです。
+
+付属の CLI モジュールは、パーセント (%) 演算子を使わずにこれらを使うことをサポートしています。詳細は、`cli.echo()` と様々な `cli.log` 関数 (例えば、`cli.log.info()`) を見てください。
+
+# 内包表記とジェネレータ表記
+
+内包表記とジェネレータの自由な使用を推奨しますが、あまりに複雑にしないでください。複雑になる場合は、理解しやすい for ループで代替します。
+
+# ラムダ
+
+使っても問題ありませんが、おそらく避けるべきです。内包表記とジェネレータを使えば、ラムダの必要性は以前ほど強くありません。
+
+# 条件式
+
+変数の割り当てでは問題ありませんが、そうでなければ避けるべきです。
+
+条件式はコードに続く if 文です。例えば:
+
+```
+x = 1 if cond else 2
+```
+
+一般にこれらを関数の引数、シーケンス項目などとして使用することはお勧めできません。見落としやすくなります。
+
+# デフォルト引数
+
+推奨されていますが、値は不変オブジェクトでなければなりません。
+
+デフォルト値に引数リストを指定する場合は、その場で変更できないオブジェクトを指定するように常に注意してください。可変オブジェクトを使うと変更は呼び出しの間で持続しますが、これは通常あなたの望むものではありませんそれがあなたのやろうとしていることであっても、他の人にとっては混乱するもので理解を妨げます。
+
+悪い:
+
+```
+def my_func(foo={}):
+    pass
+```
+
+良い:
+
+```
+def my_func(foo=None):
+    if not foo:
+        foo = {}
+```
+
+# プロパティ
+
+getter および setter 関数の代わりにプロパティを常に使います。
+
+```
+class Foo(object):
+    def __init__(self):
+        self._bar = None
+
+    @property
+    def bar(self):
+        return self._bar
+
+    @bar.setter
+    def bar(self, bar):
+        self._bar = bar
+```
+
+# True/False の評価
+
+一般的に、if 文で等価性を調べるのではなく、暗黙的な True/False 評価を行うべきです。
+
+悪い:
+
+```
+if foo == True:
+    pass
+
+if bar == False:
+    pass
+```
+
+良い:
+
+```
+if foo:
+    pass
+
+if not bar:
+    pass
+```
+
+# デコレータ
+
+適切な時に使ってください。理解に役立つ時を除き、魔法の(ように見える技巧の)使いすぎは避けるようにしてください。
+
+# スレッドとマルチプロセス
+
+避けるべきです。これが必要な場合は、私たちがコードをマージする前に十分な理由を述べる必要があります。
+
+# 強力な機能
+
+Python は非常に柔軟な言語で、独自のメタクラス、バイトコードへのアクセス、実行中コンパイル、動的な継承、オブジェクトの親の変更、インポートハック、リフレクション、システム内部の変更など、多くの素晴らしい機能を提供します。
+
+これらを使わないでください。
+
+パフォーマンスは私たちにとって重要な関心ごとではなく、コードのわかりやすさに関心があります。私たちは、コードベースを1日か2日しかいじっていない人が利用できるようにしたいです。これらの機能は一般的に理解のしやすさを犠牲にするため、より高速あるいはよりコンパクトなコードよりも、容易に理解できるコードの方が望ましいです。
+
+一部の標準ライブラリモジュールはこれらの手法を使っており、これらのモジュールを利用しても問題ありません。ただし、それらを使う時には、読みやすさと理解のしやすさを忘れないでください。
+
+# 型アノテーション付きコード
+
+今のところ型アノテーションシステムを使っていないため、コードにアノテーションをつけないようにしてください。将来的にはこれを再検討する可能性があります。
+
+# 関数の長さ
+
+小さくて焦点のあった関数にしてください。
+
+長い関数が時には適切であることを理解しているので、関数の長さには厳密な制限はありません。関数が約40行を超える場合は、プログラムの構造を損なわずに分割できるかどうかを検討してください。
+
+今のところ長い関数が完全に機能するとしても、数か月でそれを変更する人が新しい挙動を追加するかもしれません。これにより見つけにくいバグが発生するかもしれません。関数を短くかつシンプルにすることで、他の人がコードを読んで修正しやすくします。
+
+幾つかのコードで作業をすると、長く複雑な関数を見つけるかもしれません。既存コードを変更することを怖がらないでください: もし、難しいことが判明したり、エラーがデバッグしづらいとわかったり、いくつかの異なるコンテキストで一部を使いたいような関数を扱っている場合、関数を小さくてより扱いやすい単位に分割することを検討してください。
+
+# FIXME
+
+FIXME をコードに残しても構いません。なぜでしょうか？このコードを文章化しないままにするよりも、少なくとも考え抜く必要がある(あるいは混乱している)コードの一部を文章化するように奨励する方が、このコードを文章化しないままにするよりも良いです。
+
+全ての FIXME は以下のように書式化されるべきです:
+
+```
+FIXME(username): 何々機能が完了したらこのコードを再検討する。
+```
+
+...username はあなたの GitHub のユーザ名です。
+
+# テスト
+
+統合テストと単体テストの組み合わせを使ってコードが可能な限りバグが無いようにします。全てのテストは `lib/python/qmk/tests/` にあります。`qmk pytest` を使って全てのテストを実行することができます。
+
+これを書いている時点では、テストは全く完全なものではありません。現在のテストを見て、テストされていない状況のための新しいテストケースを書くことは、コードベースに精通し、QMK に貢献するという両方の点で素晴らしい方法です。
+
+## 統合テスト
+
+統合テストは `lib/python/qmk/tests/test_cli_commands.py` にあります。ここで実際に CLI コマンドが実行され、全体的な動作が検証されます。[`subprocess`](https://docs.python.org/3.6/library/subprocess.html#module-subprocess) を使って各 CLI コマンドを起動し、正しく動作するかを判断するために出力とリターンコードの組み合わせを使います。
+
+## ユニットテスト
+
+`lib/python/qmk/tests/` 内の他の `test_*.py` ファイルはユニットテストを含みます。`lib/python/qmk/` 内の個々の関数のテストをここに書くことができます。一般的にこれらのファイルはモジュールに基づいて名前を付けられ、ドットはアンダースコアで置き換えられます。
+
+これを書いている時点では、テストのためのモックを作っていません。これを変更する手伝いをしたい場合は、[issue を開く](https://github.com/qmk/qmk_firmware/issues/new?assignees=&labels=cli%2C+python&template=other_issues.md&title=) か [Discord の #cli に参加](https://discord.gg/heQPAgy)し、そこで会話を開始してください。

docs/ja/config_options.md

@@ -1,8 +1,8 @@
 # QMK の設定
 
 <!---
-  original document: 0.8.62:docs/config_options.md
-  git diff 0.8.62 HEAD -- docs/config_options.md | cat
+  original document: 0.10.33:docs/config_options.md
+  git diff 0.10.33 HEAD -- docs/config_options.md | cat
 -->
 
 QMK はほぼ無制限に設定可能です。可能なところはいかなるところでも、やりすぎな程、ユーザーがコードサイズを犠牲にしてでも彼らのキーボードをカスタマイズをすることを許しています。ただし、このレベルの柔軟性により設定が困難になります。
@@ -48,8 +48,6 @@ QMK での全ての利用可能な設定にはデフォルトがあります。
   * 一般的に、誰もしくはどのブランドがボードを作成したか
 * `#define PRODUCT Board`
   * キーボードの名前
-* `#define DESCRIPTION a keyboard`
-  * キーボードの簡単な説明
 * `#define MATRIX_ROWS 5`
   * キーボードのマトリックスの行の数
 * `#define MATRIX_COLS 15`
@@ -120,9 +118,9 @@ QMK での全ての利用可能な設定にはデフォルトがあります。
 * `#define NO_ACTION_ONESHOT`
   * ワンショットモディファイアを無効にします
 * `#define NO_ACTION_MACRO`
-  * 古い形式のマクロ処理を無効にします: MACRO() & action_get_macro
+  * `MACRO()`、`action_get_macro()` _(非推奨)_ を使う古い形式のマクロ処理を無効にします
 * `#define NO_ACTION_FUNCTION`
-  * fn_actions 配列(非推奨)からの action_function() の呼び出しを無効にします 
+  * `fn_actions`、`action_function()` _(非推奨)_ を使う古い形式の関数処理を無効にします
 
 ## 有効にできる機能
 
@@ -189,7 +187,14 @@ QMK での全ての利用可能な設定にはデフォルトがあります。
 * `#define RGBLIGHT_ANIMATIONS`
   * RGB アニメーションを実行します
 * `#define RGBLIGHT_LAYERS`
-  * オンとオフを切り替えることができる [ライトレイヤー](ja/feature_rgblight.md) を定義できます。現在のキーボードレイヤーまたは Caps Lock 状態を表示するのに最適です。
+  * オンとオフを切り替えることができる [ライトレイヤー](ja/feature_rgblight.md?id=lighting-layers) を定義できます。現在のキーボードレイヤーまたは Caps Lock 状態を表示するのに最適です。
+* `#define RGBLIGHT_MAX_LAYERS`
+  * デフォルトは8です。もしさらに [ライトレイヤー](ja/feature_rgblight.md?id=lighting-layers) が必要であれば、32まで拡張できます。
+  * メモ: 最大値を大きくするとファームウェアサイズが大きくなり、分割キーボードで同期が遅くなります。
+* `#define RGBLIGHT_LAYER_BLINK`
+  * 指定されたミリ秒の間、ライトレイヤーを [点滅](ja/feature_rgblight.md?id=lighting-layer-blink) する機能を追加します(例えば、アクションを確認するため)。
+* `#define RGBLIGHT_LAYERS_OVERRIDE_RGB_OFF`
+  * 定義されている場合、RGB ライトがオフになっている場合でも [ライトレイヤー](ja/feature_rgblight?id=overriding-rgb-lighting-onoff-status) が表示されます。
 * `#define RGBLED_NUM 12`
   * LED の数
 * `#define RGBLIGHT_SPLIT`
@@ -241,7 +246,10 @@ QMK での全ての利用可能な設定にはデフォルトがあります。
 * `#define SPLIT_HAND_PIN B7`
   * high/low ピンを使って左右を決定します。low = 右手、high = 左手。`B7` を使っているピンに置き換えます。これはオプションで、`SPLIT_HAND_PIN` が未定義のままである場合、EE_HANDS メソッドまたは標準の Let's Splitが使っている MASTER_LEFT / MASTER_RIGHT 定義をまだ使うことができます。
 
-* `#define EE_HANDS` (`SPLIT_HAND_PIN` が定義されていない場合のみ動作します)
+* `#define SPLIT_HAND_MATRIX_GRID <out_pin>,<in_pin>`
+  * 左右はキーマトリックスのキースイッチが存在しない交点を使って決定されます。通常、この交点が短絡している(ローレベル)のときに左側と見なされます。もし `#define SPLIT_HAND_MATRIX_GRID_LOW_IS_RIGHT` が定義されている場合は、ローレベルの時に右側と決定されます。
+
+* `#define EE_HANDS` (`SPLIT_HAND_PIN` と `SPLIT_HAND_MATRIX_GRID` が定義されていない場合のみ動作します)
   * `eeprom-lefthand.eep`/`eeprom-righthand.eep` がそれぞれの半分に書き込まれた後で、EEPROM 内に格納されている左右の設定の値を読み込みます。
 
 * `#define MASTER_RIGHT`
@@ -314,10 +322,9 @@ QMK での全ての利用可能な設定にはデフォルトがあります。
     ```
 * `LAYOUTS`
   * このキーボードがサポートする[レイアウト](ja/feature_layouts.md)のリスト
-* `LINK_TIME_OPTIMIZATION_ENABLE`
-  * キーボードをコンパイルする時に、Link Time Optimization (`LTO`) を有効にします。これは処理に時間が掛かりますが、コンパイルされたサイズを大幅に減らします (そして、ファームウェアが小さいため、追加の時間は分からないくらいです)。ただし、`LTO` が有効な場合、古いマクロと関数の機能が壊れるため、自動的にこれらの機能を無効にします。これは `NO_ACTION_MACRO` と `NO_ACTION_FUNCTION` を自動的に定義することで行われます。
 * `LTO_ENABLE`
-  * LINK_TIME_OPTIMIZATION_ENABLE と同じ意味です。`LINK_TIME_OPTIMIZATION_ENABLE` の代わりに `LTO_ENABLE` を使うことができます。
+  * キーボードをコンパイルする時に、Link Time Optimization (LTO) を有効にします。これは処理に時間が掛かりますが、コンパイルされたサイズを大幅に減らします (そして、ファームウェアが小さいため、追加の時間は分からないくらいです)。
+ただし、LTO が有効な場合、古い TMK のマクロと関数の機能が壊れるため、自動的にこれらの機能を無効にします。これは `NO_ACTION_MACRO` と `NO_ACTION_FUNCTION` を自動的に定義することで行われます。(メモ: これは QMK の [マクロ](ja/feature_macros.md) と [レイヤー](ja/feature_layers.md) には影響を与えません。)
 
 ## AVR MCU オプション
 * `MCU = atmega32u4`
@@ -362,10 +369,8 @@ QMK での全ての利用可能な設定にはデフォルトがあります。
   * MIDI 制御
 * `UNICODE_ENABLE`
   * Unicode
-* `BLUETOOTH_ENABLE`
-  * Adafruit EZ-Key HID で Bluetooth を有効にするレガシーオプション。BLUETOOTH を見てください
 * `BLUETOOTH`
-  * 現在のオプションは、AdafruitEzKey、AdafruitBLE、RN42
+  * 現在のオプションは、AdafruitBLE、RN42
 * `SPLIT_KEYBOARD`
   * 分割キーボード (let's split や bakingpy のキーボードのようなデュアル MCU) のサポートを有効にし、quantum/split_common にある全ての必要なファイルをインクルードします
 * `CUSTOM_MATRIX`

docs/ja/custom_matrix.md

@@ -31,7 +31,7 @@ keyboards/<keyboard>/matrix.c
 SRC += matrix.c
 ```
 
-## マトリックスコードの部分置き換え
+## マトリックスコードの部分置き換え :id=lite
 
 カスタムマトリックスを実装する際、定型コードを書かなくてすむように、さまざまなスキャン関数のデフォルト実装を提供しています。
 

docs/ja/custom_quantum_functions.md

@@ -1,8 +1,8 @@
 # キーボードの挙動をカスタマイズする方法
 
 <!---
-  original document: 0.8.62:docs/custom_quantum_functions.md
-  git diff 0.8.62 HEAD -- docs/custom_quantum_functions.md | cat
+  original document: 0.10.33:docs/custom_quantum_functions.md
+  git diff 0.10.33 HEAD -- docs/custom_quantum_functions.md | cat
 -->
 
 多くの人にとって、カスタムキーボードはボタンの押下をコンピュータに送信するだけではありません。単純なボタンの押下やマクロよりも複雑なことを実行できるようにしたいでしょう。QMK にはコードを挿入したり、機能を上書きしたり、様々な状況でキーボードの挙動をカスタマイズできるフックがあります。
@@ -232,7 +232,7 @@ void keyboard_pre_init_user(void) {
 }
 ```
 
-### `keyboard_pre_init_*` 関数のドキュメント
+### `keyboard_pre_init_*` 関数のドキュメント :id=keyboard_pre_init_-function-documentation
 
 * キーボード/リビジョン: `void keyboard_pre_init_kb(void)`
 * キーマップ: `void keyboard_pre_init_user(void)`
@@ -346,6 +346,11 @@ layer_state_t layer_state_set_user(layer_state_t state) {
   return state;
 }
 ```
+
+特定のレイヤーの状態を確認するには、 `IS_LAYER_ON_STATE(state, layer)` と `IS_LAYER_OFF_STATE(state, layer)` マクロを使います。
+
+`layer_state_set_*` 関数の外では、グローバルなレイヤー状態を確認するために `IS_LAYER_ON(layer)` と `IS_LAYER_OFF(layer)` マクロを使えます。
+
 ### `layer_state_set_*` 関数のドキュメント
 
 * キーボード/リビジョン: `layer_state_t layer_state_set_kb(layer_state_t state)`
@@ -451,7 +456,7 @@ bool process_record_user(uint16_t keycode, keyrecord_t *record) {
                 layer_state_set(layer_state);   // すぐにレイヤーの色を更新します
             }
         }
-        return false; break;
+        return false;
     case RGB_MODE_FORWARD ... RGB_MODE_GRADIENT: // 任意の RGB コード に対して(quantum_keycodes.h を見てください。400行目参照)
         if (record->event.pressed) { // これはレイヤー表示を無効にします。これを変更する場合は、無効にしたいだろうため。
             if (user_config.rgb_layer_change) {        // 有効な場合のみ
@@ -488,56 +493,3 @@ void eeconfig_init_user(void) {  // EEPROM がリセットされます！
 * キーマップ: `void eeconfig_init_user(void)`、`uint32_t eeconfig_read_user(void)` および `void eeconfig_update_user(uint32_t val)`
 
 `val` は EEPROM に書き込みたいデータの値です。`eeconfig_read_*` 関数は EEPROM から32ビット(DWORD) 値を返します。
-
-# カスタムタッピング期間
-
-デフォルトでは、タッピング期間と(`IGNORE_MOD_TAP_INTERRUPT` のような)関連オプションはグローバルに設定されていて、キーでは設定することができません。ほとんどのユーザにとって、これは全然問題ありません。しかし、場合によっては、`LT` キーとは異なるタイムアウトによって、デュアルファンクションキーが大幅に改善されます。なぜなら、一部のキーは他のキーよりも押し続けやすいためです。それぞれにカスタムキーコードを使う代わりに、キーごとに設定可能なタイムアウトの挙動を設定できます。
-
-キーごとのタイムアウトの挙動を制御するための2つの設定可能なオプションがあります:
-
-- `TAPPING_TERM_PER_KEY`
-- `IGNORE_MOD_TAP_INTERRUPT_PER_KEY`
-
-必要な機能ごとに、`config.h` に `#define` 行を追加する必要があります。
-
-```
-#define TAPPING_TERM_PER_KEY
-#define IGNORE_MOD_TAP_INTERRUPT_PER_KEY
-```
-
-
-## `get_tapping_term` の実装例
-
-キーコードに基づいて `TAPPING_TERM` を変更するには、次のようなものを `keymap.c` ファイルに追加します:
-
-```c
-uint16_t get_tapping_term(uint16_t keycode, keyrecord_t *record) {
-  switch (keycode) {
-    case SFT_T(KC_SPC):
-      return TAPPING_TERM + 1250;
-    case LT(1, KC_GRV):
-      return 130;
-    default:
-      return TAPPING_TERM;
-  }
-}
-```
-
-## `get_ignore_mod_tap_interrupt` の実装例
-
-キーコードに基づいて `IGNORE_MOD_TAP_INTERRUPT` の値を変更するには、次のようなものを `keymap.c` ファイルに追加します:
-
-```c
-bool get_ignore_mod_tap_interrupt(uint16_t keycode, keyrecord_t *record) {
-  switch (keycode) {
-    case SFT_T(KC_SPC):
-      return true;
-    default:
-      return false;
-  }
-}
-```
-
-## `get_tapping_term` / `get_ignore_mod_tap_interrupt` 関数のドキュメント
-
-ここにある他の多くの関数とは異なり、quantum あるいはキーボードレベルの関数を持つ必要はありません (または理由さえありません)。ここではユーザレベルの関数だけが有用なため、そのようにマークする必要はありません。

docs/ja/documentation_best_practices.md

@@ -1,8 +1,8 @@
 # ドキュメントベストプラクティス
 
 <!---
-  original document: 0.9.19:docs/documentation_best_practices.md
-  git diff 0.9.19 HEAD -- docs/documentation_best_practices.md | cat
+  original document: 0.10.33:docs/documentation_best_practices.md
+  git diff 0.10.33 HEAD -- docs/documentation_best_practices.md | cat
 -->
 
 このページは QMK のためのドキュメントを作成する時のベストプラクティスを文章化するためのものです。これらのガイドラインに従うことで、一貫したトーンとスタイルを維持することでき、他の人が QMK をより理解しやすくすることができます。

docs/ja/driver_installation_zadig.md

@@ -1,8 +1,8 @@
 # Zadig を使ったブートローダドライバのインストール
 
 <!---
-  original document: 0.9.0:docs/driver_installation_zadig.md
-  git diff 0.9.0 HEAD -- docs/driver_installation_zadig.md | cat
+  original document: 0.9.43:docs/driver_installation_zadig.md
+  git diff 0.9.43 HEAD -- docs/driver_installation_zadig.md | cat
 -->
 
 QMK はホストにたいして通常の HID キーボードデバイスとして振る舞うため特別なドライバは必要ありません。しかし、Windows でのキーボードへの書き込みは、多くの場合、キーボードをリセットした時に現れるブートローダデバイスで*行います*。
@@ -28,7 +28,7 @@ Zadig は自動的にブートローダデバイスを検知します。**Option
 
 !> Zadig が `HidUsb` ドライバを使用する1つ以上のデバイスを表示する場合、キーボードはおそらくブートローダモードではありません。矢印はオレンジ色になり、システムドライバの変更を確認するように求められます。この場合、続行**しないでください**！
 
-矢印が緑色で表示されたら、ドライバを選択し、**Install Driver** をクリックします。`libusb-win32` ドライバは通常 AVR で動作し、`WinUSB`は ARM で動作しますが、それでもキーボードに書き込みできない場合は、リストから異なるドライバをインストールしてみてください。msys2 を使ってコマンドライン経由で USBaspLoader デバイスに書き込むには、`libusbk` ドライバがお勧めです。そうではなく書き込みに QMK Toolbox を使っている場合は `libusb-win32` がうまく動作します。
+矢印が緑色で表示されたら、ドライバを選択し、**Install Driver** をクリックします。`libusb-win32` ドライバは通常 AVR で動作し、`WinUSB`は ARM で動作しますが、それでもキーボードに書き込みできない場合は、リストから異なるドライバをインストールしてみてください。USBAspLoader デバイスは `libusbK` ドライバを使わなければなりません。
 
 ![ブートローダドライバが正常にインストールされた Zadig](https://i.imgur.com/b8VgXzx.png)
 

docs/ja/faq_build.md

@@ -1,8 +1,8 @@
 # よくあるビルドの質問
 
 <!---
-  original document: 0.9.10:docs/faq_build.md
-  git diff 0.9.10 HEAD -- docs/faq_build.md | cat
+  original document: 0.10.33:docs/faq_build.md
+  git diff 0.10.33 HEAD -- docs/faq_build.md | cat
 -->
 
 このページは QMK のビルドに関する質問を説明します。まだビルドをしていない場合は、[ビルド環境のセットアップ](ja/getting_started_build_tools.md) および [Make 手順](ja/getting_started_make_guide.md)ガイドを読むべきです。
@@ -18,64 +18,93 @@
 
 あるいは、単純に:
 
-    $ sudo make <keyboard>:<keymap>:dfu
+    $ sudo make <keyboard>:<keymap>:flash
 
 `make` を `sudo` で実行することは一般的には良い考えでは***なく***、可能であれば前者の方法のいずれかを使うべきです。
 
 ### Linux の `udev` ルール
-Linux では、MCU にアクセスするには適切な権限が必要です。ファームウェアを書き込む時に `sudo` を使うか、`/etc/udev/rules.d/` にこれらのファイルを配置することで、アクセスすることができます。権限の追加が完了したら、以下を実行します:
-```console
+
+Linux では、ブートローダデバイスと通信するには適切な権限が必要です。ファームウェアを書き込む時に `sudo` を使うか、`/etc/udev/rules.d/` にこのファイルを配置することで、通信することができます。
+
+**/etc/udev/rules.d/50-qmk.rules:**
+```
+# Atmel DFU
+### ATmega16U2
+SUBSYSTEMS=="usb", ATTRS{idVendor}=="03EB", ATTRS{idProduct}=="2FEF", TAG+="uaccess", RUN{builtin}+="uaccess"
+### ATmega32U2
+SUBSYSTEMS=="usb", ATTRS{idVendor}=="03EB", ATTRS{idProduct}=="2FF0", TAG+="uaccess", RUN{builtin}+="uaccess"
+### ATmega16U4
+SUBSYSTEMS=="usb", ATTRS{idVendor}=="03EB", ATTRS{idProduct}=="2FF3", TAG+="uaccess", RUN{builtin}+="uaccess"
+### ATmega32U4
+SUBSYSTEMS=="usb", ATTRS{idVendor}=="03EB", ATTRS{idProduct}=="2FF4", TAG+="uaccess", RUN{builtin}+="uaccess"
+### AT90USB64
+SUBSYSTEMS=="usb", ATTRS{idVendor}=="03EB", ATTRS{idProduct}=="2FF9", TAG+="uaccess", RUN{builtin}+="uaccess"
+### AT90USB128
+SUBSYSTEMS=="usb", ATTRS{idVendor}=="03EB", ATTRS{idProduct}=="2FFB", TAG+="uaccess", RUN{builtin}+="uaccess"
+
+# Input Club
+SUBSYSTEMS=="usb", ATTRS{idVendor}=="1C11", ATTRS{idProduct}=="B007", TAG+="uaccess", RUN{builtin}+="uaccess"
+
+# STM32duino
+SUBSYSTEMS=="usb", ATTRS{idVendor}=="1EAF", ATTRS{idProduct}=="0003", TAG+="uaccess", RUN{builtin}+="uaccess"
+# STM32 DFU
+SUBSYSTEMS=="usb", ATTRS{idVendor}=="0483", ATTRS{idProduct}=="DF11", TAG+="uaccess", RUN{builtin}+="uaccess"
+
+# BootloadHID
+SUBSYSTEMS=="usb", ATTRS{idVendor}=="16C0", ATTRS{idProduct}=="05DF", TAG+="uaccess", RUN{builtin}+="uaccess"
+
+# USBAspLoader
+SUBSYSTEMS=="usb", ATTRS{idVendor}=="16C0", ATTRS{idProduct}=="05DC", TAG+="uaccess", RUN{builtin}+="uaccess"
+
+# ModemManager should ignore the following devices
+# Atmel SAM-BA (Massdrop)
+SUBSYSTEMS=="usb", ATTRS{idVendor}=="03EB", ATTRS{idProduct}=="6124", TAG+="uaccess", RUN{builtin}+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1"
+
+# Caterina (Pro Micro)
+## Spark Fun Electronics
+### Pro Micro 3V3/8MHz
+SUBSYSTEMS=="usb", ATTRS{idVendor}=="1B4F", ATTRS{idProduct}=="9203", TAG+="uaccess", RUN{builtin}+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1"
+### Pro Micro 5V/16MHz
+SUBSYSTEMS=="usb", ATTRS{idVendor}=="1B4F", ATTRS{idProduct}=="9205", TAG+="uaccess", RUN{builtin}+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1"
+### LilyPad 3V3/8MHz (and some Pro Micro clones)
+SUBSYSTEMS=="usb", ATTRS{idVendor}=="1B4F", ATTRS{idProduct}=="9207", TAG+="uaccess", RUN{builtin}+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1"
+## Pololu Electronics
+### A-Star 32U4
+SUBSYSTEMS=="usb", ATTRS{idVendor}=="1FFB", ATTRS{idProduct}=="0101", TAG+="uaccess", RUN{builtin}+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1"
+## Arduino SA
+### Leonardo
+SUBSYSTEMS=="usb", ATTRS{idVendor}=="2341", ATTRS{idProduct}=="0036", TAG+="uaccess", RUN{builtin}+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1"
+### Micro
+SUBSYSTEMS=="usb", ATTRS{idVendor}=="2341", ATTRS{idProduct}=="0037", TAG+="uaccess", RUN{builtin}+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1"
+## Adafruit Industries LLC
+### Feather 32U4
+SUBSYSTEMS=="usb", ATTRS{idVendor}=="239A", ATTRS{idProduct}=="000C", TAG+="uaccess", RUN{builtin}+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1"
+### ItsyBitsy 32U4 3V3/8MHz
+SUBSYSTEMS=="usb", ATTRS{idVendor}=="239A", ATTRS{idProduct}=="000D", TAG+="uaccess", RUN{builtin}+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1"
+### ItsyBitsy 32U4 5V/16MHz
+SUBSYSTEMS=="usb", ATTRS{idVendor}=="239A", ATTRS{idProduct}=="000E", TAG+="uaccess", RUN{builtin}+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1"
+## dog hunter AG
+### Leonardo
+SUBSYSTEMS=="usb", ATTRS{idVendor}=="2A03", ATTRS{idProduct}=="0036", TAG+="uaccess", RUN{builtin}+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1"
+### Micro
+SUBSYSTEMS=="usb", ATTRS{idVendor}=="2A03", ATTRS{idProduct}=="0037", TAG+="uaccess", RUN{builtin}+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1"
+```
+
+追加が完了したら、以下を実行します:
+
+```
 sudo udevadm control --reload-rules
 sudo udevadm trigger
 ```
 
-**/etc/udev/rules.d/50-atmel-dfu.rules:**
-```
-# Atmel ATMega32U4
-SUBSYSTEMS=="usb", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="2ff4", TAG+="uaccess", RUN{builtin}+="uaccess"
-# Atmel USBKEY AT90USB1287
-SUBSYSTEMS=="usb", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="2ffb", TAG+="uaccess", RUN{builtin}+="uaccess"
-# Atmel ATMega32U2
-SUBSYSTEMS=="usb", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="2ff0", TAG+="uaccess", RUN{builtin}+="uaccess"
-```
-
-**/etc/udev/rules.d/54-input-club-keyboard.rules:**
-
-```
-# Input Club keyboard bootloader
-SUBSYSTEMS=="usb", ATTRS{idVendor}=="1c11", ATTRS{idProduct}=="b007", TAG+="uaccess", RUN{builtin}+="uaccess"
-```
-
-**/etc/udev/rules.d/55-caterina.rules:**
-```
-# ModemManager should ignore the following devices
-SUBSYSTEMS=="usb", ATTRS{idVendor}=="2a03", ATTRS{idProduct}=="0036", TAG+="uaccess", RUN{builtin}+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1"
-SUBSYSTEMS=="usb", ATTRS{idVendor}=="2341", ATTRS{idProduct}=="0036", TAG+="uaccess", RUN{builtin}+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1"
-SUBSYSTEMS=="usb", ATTRS{idVendor}=="1b4f", ATTRS{idProduct}=="9205", TAG+="uaccess", RUN{builtin}+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1"
-SUBSYSTEMS=="usb", ATTRS{idVendor}=="1b4f", ATTRS{idProduct}=="9203", TAG+="uaccess", RUN{builtin}+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1"
-```
-
 **注意:** 古い(1.12以前の) ModemManager では、フィルタリングは厳密なモードではない場合にのみ動作し、以下のコマンドはその設定を更新することができます。
-```console
-sudo sed -i 's/--filter-policy=strict/--filter-policy=default/' /lib/systemd/system/ModemManager.service
+
+```
+printf '[Service]\nExecStart=\nExecStart=/usr/sbin/ModemManager --filter-policy=default' | sudo tee /etc/systemd/system/ModemManager.service.d/policy.conf
 sudo systemctl daemon-reload
 sudo systemctl restart ModemManager
 ```
 
-**/etc/udev/rules.d/56-dfu-util.rules:**
-```
-# stm32duino
-SUBSYSTEMS=="usb", ATTRS{idVendor}=="1eaf", ATTRS{idProduct}=="0003", TAG+="uaccess", RUN{builtin}+="uaccess"
-# Generic stm32
-SUBSYSTEMS=="usb", ATTRS{idVendor}=="0483", ATTRS{idProduct}=="df11", TAG+="uaccess", RUN{builtin}+="uaccess"
-```
-
-**/etc/udev/rules.d/57-bootloadhid.rules:**
-```
-# bootloadHID
-SUBSYSTEMS=="usb", ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="05df", TAG+="uaccess", RUN{builtin}+="uaccess"
-```
-
 ### Linux のブートローダモードで Serial デバイスが検知されない
 カーネルがデバイスを適切にサポートしていることを確認してください。デバイスが、Pro Micro (Atmega32u4) のように USB ACM を使う場合、`CONFIG_USB_ACM=y` を含めるようにしてください。他のデバイスは `USB_SERIAL` およびそのサブオプションを必要とするかもしれません。
 
@@ -99,50 +128,10 @@ https://github.com/tmk/tmk_keyboard/issues/150
 - http://www.obdev.at/products/vusb/license.html
 - http://www.mcselec.com/index.php?page=shop.product_details&flypage=shop.flypage&product_id=92&option=com_phpshop&Itemid=1
 
-## AVR のための BOOTLOADER_SIZE
-Teensy2.0++ ブートローダのサイズは 2048 バイトであることに注意してください。一部の Makefile には間違ったコメントがあります。
-
-```
-# Boot Section Size in *bytes*
-#   Teensy halfKay   512
-#   Teensy++ halfKay 2048
-#   Atmel DFU loader 4096       (TMK Alt Controller)
-#   LUFA bootloader  4096
-#   USBaspLoader     2048
-OPT_DEFS += -DBOOTLOADER_SIZE=2048
-```
-
-## MacOS での `avr-gcc: internal compiler error: Abort trap: 6 (program cc1)` 
-
-これは brew での更新に関する問題で、avr-gcc が依存するシンボリックリンクを壊します。
-
-解決法は全ての影響を受けたモジュールを削除し再インストールすることです。
-
-```
-brew rm avr-gcc avr-gcc@8 dfu-programmer dfu-util gcc-arm-none-eabi arm-gcc-bin@8 avrdude qmk
-brew install qmk/qmk/qmk
-brew link --force avr-gcc@8
-brew link --force arm-gcc-bin@8
-```
-
-### `avr-gcc` と LUFA
-
-`avr-gcc` を更新し、LUFA に関連するエラーが表示された場合、例えば:
-
-`lib/lufa/LUFA/Drivers/USB/Class/Device/AudioClassDevice.h:380:5: error: 'const' attribute on function returning 'void'`
-
-今のところ、Homebrew で `avr-gcc` を 8 にロールバックする必要があります。
-
-```
-brew uninstall --force avr-gcc
-brew install avr-gcc@8
-brew link --force avr-gcc@8
-```
-
 ### キーボードに書き込んだが何も起こらない、あるいはキーの押下が登録されない - ARM (rev6 planck、clueboard 60、hs60v2 など) でも同じ (Feb 2019)
 ARM ベースのチップ上での EEPROM の動作によって、保存された設定が無効になる場合があります。これはデフォルトレイヤに影響し、まだ調査中の特定の環境下でキーボードが使えなくなる*しれません*。EEPROM のリセットでこれが修正されます。
 
 [Planck rev6 reset EEPROM](https://cdn.discordapp.com/attachments/473506116718952450/539284620861243409/planck_rev6_default.bin) を使って eeprom のリセットを強制することができます。このイメージを書き込んだ後で、通常のファームウェアを書き込むと、キーボードが_通常_ の動作順序に復元されます。
 [Preonic rev3 reset EEPROM](https://cdn.discordapp.com/attachments/473506116718952450/537849497313738762/preonic_rev3_default.bin)
 
-いずれかの形式でブートマジックが有効になっている場合は、これも実行できるはずです (実行方法の詳細については、[ブートマジックドキュメント](feature_bootmagic.md)とキーボード情報を見てください)。
+いずれかの形式でブートマジックが有効になっている場合は、これも実行できるはずです (実行方法の詳細については、[ブートマジックドキュメント](ja/feature_bootmagic.md)とキーボード情報を見てください)。

docs/ja/faq_debug.md

@@ -1,8 +1,8 @@
 # デバッグの FAQ
 
 <!---
-  original document: 0.9.10:docs/faq_debug.md
-  git diff 0.9.10 HEAD -- docs/faq_debug.md | cat
+  original document: 0.10.33:docs/faq_debug.md
+  git diff 0.10.33 HEAD -- docs/faq_debug.md | cat
 -->
 
 このページは、キーボードのトラブルシューティングについての様々な一般的な質問を説明します。
@@ -36,20 +36,6 @@ Linux のような OS でデバイスにアクセスするには、権限が必
 - デバッグ print の代わりに 'print' 関数を使ってみてください。**common/print.h** を見てください。
 - コンソール機能を持つ他のデバイスを切断します。[Issue #97](https://github.com/tmk/tmk_keyboard/issues/97) を見てください。
 
-## Linux あるいは UNIX のようなシステムはスーパーユーザ権限を必要とします
-権限付きで *hid_listen* を実行するために 'sudo' を使ってください。
-```
-$ sudo hid_listen
-```
-
-または rules ディレクトリにファイルを置いて、TMK デバイスのための *udev rule* を追加します。ディレクトリは各システムで異なるかもしれません。
-
-File: /etc/udev/rules.d/52-tmk-keyboard.rules (Ubuntu の場合)
-```
-# tmk keyboard products     https://github.com/tmk/tmk_keyboard
-SUBSYSTEMS=="usb", ATTRS{idVendor}=="feed", MODE:="0666"
-```
-
 ***
 
 # 雑多なこと

docs/ja/faq_general.md

@@ -51,7 +51,7 @@ OK、問題ありません。[GitHub で issue を開く](https://github.com/qmk
 
 TMK は [Jun Wako](https://github.com/tmk) によって設計され実装されました。QMK は [Jack Humbert](https://github.com/jackhumbert) の Planck 用 TMK のフォークとして始まりました。しばらくして、Jack のフォークは TMK からかなり分岐し、2015年に Jack はフォークを QMK に名前を変えることにしました。
 
-技術的な観点から、QMK は幾つかの新しい機能を追加した TMK に基づいています。最も注目すべきことは、QMK は利用可能なキーコードの数を増やし、`S()`、`LCTL()` および `MO()` などの高度な機能を実装するためにこれらを使っています。[キーコード](keycodes.md)でこれらのキーコードの完全なリストを見ることができます。
+技術的な観点から、QMK は幾つかの新しい機能を追加した TMK に基づいています。最も注目すべきことは、QMK は利用可能なキーコードの数を増やし、`S()`、`LCTL()` および `MO()` などの高度な機能を実装するためにこれらを使っています。[キーコード](ja/keycodes.md)でこれらのキーコードの完全なリストを見ることができます。
 
 プロジェクトとコミュニティの管理の観点から、TMK は公式にサポートされている全てのキーボードを自分で管理しており、コミュニティのサポートも少し受けています。他のキーボード用に別個のコミュニティが維持するフォークが存在するか、作成できます。デフォルトでは少数のキーマップのみが提供されるため、ユーザは一般的にお互いにキーマップを共有しません。QMK は集中管理されたリポジトリを介して、キーボードとキーマップの両方を共有することを奨励しており、品質基準に準拠する全てのプルリクエストを受け付けます。これらはほとんどコミュニティで管理されますが、必要な場合は QMK チームも支援します。
 

docs/ja/faq_keymap.md

@@ -128,7 +128,7 @@ https://github.com/tekezo/Karabiner/issues/403
 
 ## 単一のキーでの Esc と<code>&#96;</code>
 
-[Grave Escape](feature_grave_esc.md) 機能を見てください。
+[Grave Escape](ja/feature_grave_esc.md) 機能を見てください。
 
 ## Mac OSX での Eject
 `KC_EJCT` キーコードは OSX で動作します。https://github.com/tmk/tmk_keyboard/issues/250

docs/ja/feature_auto_shift.md

@@ -1,8 +1,8 @@
 # 自動シフト: なぜシフトキーが必要ですか？
 
 <!---
-  original document: 0.9.0:docs/feature_auto_shift.md
-  git diff 0.9.0 HEAD -- docs/feature_auto_shift.md | cat
+  original document: 0.10.33:docs/feature_auto_shift.md
+  git diff 0.10.33 HEAD -- docs/feature_auto_shift.md | cat
 -->
 
 キーをタップすると、その文字を取得します。キーをタップするが、*わずかに*長く押し続けると、シフト状態になります。ほら！シフトキーは必要ありません！
@@ -109,7 +109,7 @@ AからZを含むアルファベット文字を自動シフトしません。
 5. タイムアウトを増やすことに決めた場合は、`KC_ASUP` にマップしたキーを押し、ステップ1に戻ります。
 6. 結果に満足したら、`KC_ASRP` にマップしたキーを押します。キーボードは `AUTO_SHIFT_TIMEOUT` の値を自動的に入力します。
 7. 報告された値で `config.h` の `AUTO_SHIFT_TIMEOUT` を更新します。
-8. `config.h` から `AUTO_SHIFT_SETUP` を削除します。
+8. `config.h` に `AUTO_SHIFT_NO_SETUP` を追加します。
 9. `KC_ASDN`、`KC_ASUP` および `KC_ASRP` のキーバインディングを削除します。
 10. 新しいファームウェアをコンパイルしてアップロードします。
 

docs/ja/feature_backlight.md

@@ -1,253 +1,222 @@
-# バックライト
+# バックライト :id=backlighting
 
 <!---
-  original document: 0.9.10:docs/feature_backlight.md
-  git diff 0.9.10 HEAD -- docs/feature_backlight.md | cat
+  original document: 0.10.33:docs/feature_backlight.md
+  git diff 0.10.33 HEAD -- docs/feature_backlight.md | cat
 -->
 
 多くのキーボードは、キースイッチを貫通して配置されたり、キースイッチの下に配置された個々の LED によって、バックライトキーをサポートします。この機能は通常スイッチごとに単一の色しか使用できないため、[RGB アンダーグロー](ja/feature_rgblight.md)および [RGB マトリックス](ja/feature_rgb_matrix.md)機能のどちらとも異なりますが、キーボードに複数の異なる単一色の LED を取り付けることは当然可能です。
 
-QMK は *パルス幅変調*(*Pulse Width Modulation*) すなわち PWM として知られている技術で急速にオンおよびオフを切り替えることで、これらの LED の輝度を制御できます。PWM 信号のデューティサイクルを変えることで、調光の錯覚を起こすことができます。
+QMK は *パルス幅変調* (*Pulse Width Modulation*) すなわち PWM として知られている技術で、一定の比率で素早くオンおよびオフを切り替えることで、これらの LED の輝度を制御できます。PWM 信号のデューティサイクルを変えることで、調光の錯覚を起こすことができます。
 
 MCU は、GPIO ピンにはそんなに電流を供給できません。MCU から直接バックライトに給電せずに、バックライトピンは LED への電力を切り替えるトランジスタあるいは MOSFET に接続されます。
 
-## 機能の設定
-
 ほとんどのキーボードではバックライトをサポートしている場合にデフォルトで有効になっていますが、もし機能しない場合は `rules.mk` が以下を含んでいることを確認してください:
 
 ```makefile
 BACKLIGHT_ENABLE = yes
 ```
 
-## キーコード
+## キーコード :id=keycodes
+
 有効にすると、以下のキーコードを使ってバックライトレベルを変更することができます。
 
-| キー | 説明 |
-|---------|------------------------------------------|
+| キー      | 説明                                 |
+| --------- | ------------------------------------ |
 | `BL_TOGG` | バックライトをオンあるいはオフにする |
-| `BL_STEP` | バックライトレベルを循環する |
-| `BL_ON` | バックライトを最大輝度に設定する |
-| `BL_OFF` | バックライトをオフにする |
-| `BL_INC` | バックライトレベルを上げる |
-| `BL_DEC` | バックライトレベルを下げる |
-| `BL_BRTG` | バックライトの明滅動作を切り替える |
+| `BL_STEP` | バックライトレベルを循環する         |
+| `BL_ON`   | バックライトを最大輝度に設定する     |
+| `BL_OFF`  | バックライトをオフにする             |
+| `BL_INC`  | バックライトレベルを上げる           |
+| `BL_DEC`  | バックライトレベルを下げる           |
+| `BL_BRTG` | バックライトの明滅動作を切り替える   |
 
-## バックライト関数群
+## 関数群 :id=functions
 
-| 関数 | 説明 |
-|----------|-----------------------------------------------------------|
-| `backlight_toggle()` | バックライトをオンあるいはオフにする |
-| `backlight_enable()` | バックライトをオンにする |
-| `backlight_disable()` | バックライトをオフにする |
-| `backlight_step()` | バックライトレベルを循環する |
-| `backlight_increase()` | バックライトレベルを上げる |
-| `backlight_decrease()` | バックライトレベルを下げる |
-| `backlight_level(x)` | バックライトのレベルを特定のレベルに設定する |
-| `get_backlight_level()` | 現在のバックライトレベルを返す |
-| `is_backlight_enabled()` | バックライトが現在オンかどうかを返す |
+次の関数を使って、カスタムコードでバックライトを変更することができます:
 
-### バックライトの明滅動作の関数群
+| 関数                     | 説明                                         |
+| ------------------------ | -------------------------------------------- |
+| `backlight_toggle()`     | バックライトをオンあるいはオフにする         |
+| `backlight_enable()`     | バックライトをオンにする                     |
+| `backlight_disable()`    | バックライトをオフにする                     |
+| `backlight_step()`       | バックライトレベルを循環する                 |
+| `backlight_increase()`   | バックライトレベルを上げる                   |
+| `backlight_decrease()`   | バックライトレベルを下げる                   |
+| `backlight_level(x)`     | バックライトのレベルを特定のレベルに設定する |
+| `get_backlight_level()`  | 現在のバックライトレベルを返す               |
+| `is_backlight_enabled()` | バックライトが現在オンかどうかを返す         |
 
-| 関数 | 説明 |
-|----------|---------------------------------------------------|
-| `breathing_toggle()` | バックライトの明滅動作をオンまたはオフにする |
-| `breathing_enable()` | バックライトの明滅動作をオンにする |
-| `breathing_disable()` | バックライトの明滅動作をオフにする |
+バックライトの明滅が有効の場合(以下を参照)、以下の関数も利用できます:
 
-## ドライバの設定
+| 関数                  | 説明                                         |
+|-----------------------|----------------------------------------------|
+| `breathing_toggle()`  | バックライトの明滅動作をオンまたはオフにする |
+| `breathing_enable()`  | バックライトの明滅動作をオンにする           |
+| `breathing_disable()` | バックライトの明滅動作をオフにする           |
+
+## 設定 :id=configuration
 
 どのドライバを使うかを選択するには、以下を使って `rules.mk` を設定します:
 
 ```makefile
-BACKLIGHT_DRIVER = software # 有効なドライバの値は 'pwm,software,no' です
+BACKLIGHT_DRIVER = software
 ```
 
-各ドライバについてのヘルプは以下を見てください。
+有効なドライバの値は `pwm`, `software`, `custom`, `no` です。各ドライバについてのヘルプは以下を見てください。
 
-## 共通のドライバ設定
+バックライトを設定するには、`config.h` の中で以下の `#define` をします:
 
-バックライトの挙動を変更するには、`config.h` の中で以下の `#define` をします:
-
-| 定義 | デフォルト | 説明 |
-|---------------------|-------------|--------------------------------------------------------------------------------------|
-| `BACKLIGHT_LEVELS` | `3` | 輝度のレベルの数 (オフを除いて最大 31) |
+| 定義                  | デフォルト | 説明                                                                                        |
+| --------------------- | ---------- | ------------------------------------------------------------------------------------------- |
+| `BACKLIGHT_PIN`       | *定義なし* | LED を制御するピン                                                                          |
+| `BACKLIGHT_LEVELS`    | `3`        | 輝度のレベルの数 (オフを除いて最大 31)                                                      |
 | `BACKLIGHT_CAPS_LOCK` | *定義なし* | バックライトを使って Caps Lock のインジケータを有効にする (専用 LED の無いキーボードのため) |
-| `BACKLIGHT_BREATHING` | *定義なし* | サポートされる場合は、バックライトの明滅動作を有効にする |
-| `BREATHING_PERIOD` | `6` | 各バックライトの "明滅" の長さ（秒） |
-| `BACKLIGHT_ON_STATE` | `0` | バックライトが "オン" の時のバックライトピンの状態 - high の場合は `1`、low の場合は `0` |
+| `BACKLIGHT_BREATHING` | *定義なし* | サポートされる場合は、バックライトの明滅動作を有効にする                                    |
+| `BREATHING_PERIOD`    | `6`        | 各バックライトの "明滅" の長さ（秒）                                                        |
+| `BACKLIGHT_ON_STATE`  | `1`        | バックライトが "オン" の時のバックライトピンの状態 - high の場合は `1`、low の場合は `0`    |
 
-### バックライトオン状態
+独自のキーボードを設計しているわけではない限り、通常は `BACKLIGHT_PIN` または `BACKLIGHT_ON_STATE` を変更する必要はありません。
 
-ほとんどのバックライトの回路は N チャンネルの MOSFET あるいは NPN トランジスタによって駆動されます。これは、トランジスタを*オン*にして LED を点灯させるには、ゲートまたはベースに接続されているバックライトピンを *high* に駆動する必要があることを意味します。
+### バックライトオン状態 :id=backlight-on-state
+
+ほとんどのバックライトの回路は N チャンネルの MOSFET あるいは NPN トランジスタによって駆動されます。これは、トランジスタを *オン* にして LED を点灯させるには、ゲートまたはベースに接続されているバックライトピンを *high* に駆動する必要があることを意味します。
 ただし、P チャンネルの MOSFET あるいは PNP トランジスタが使われる場合があります。この場合、トランジスタがオンの時、ピンは代わりに *low* で駆動されます。
 
-この機能は `BACKLIGHT_ON_STATE` 定義することでキーボードレベルで設定されます。
+この機能は `BACKLIGHT_ON_STATE` を定義することでキーボードレベルで設定されます。
 
-## AVR ドライバ
+### AVR ドライバ :id=avr-driver
+
+`pwm` ドライバはデフォルトで設定されますが、`rules.mk` 内での同等の設定は以下の通りです:
 
-AVR ボードでは、デフォルトのドライバは現在のところ最善のシナリオを選択するために構成を探っています。ドライバはデフォルトで設定されますが、rules.mk 内の同等の設定は以下の通りです:
 ```makefile
 BACKLIGHT_DRIVER = pwm
 ```
 
-### 注意事項
+#### 注意事項 :id=avr-caveats
 
-ハードウェア PWM は以下の表に従ってサポートされます:
+AVR ボードでは、QMK はどのドライバを使うかを以下の表に従って自動的に決定します:
 
 | バックライトピン | AT90USB64/128 | ATmega16/32U4 | ATmega16/32U2 | ATmega32A | ATmega328/P |
-|-------------|-------------|-------------|-------------|---------|----------|
-| `B1`        |             |             |             |         | Timer 1  |
-| `B2`        |             |             |             |         | Timer 1  |
-| `B5`        | Timer 1     | Timer 1     |             |         |          |
-| `B6`        | Timer 1     | Timer 1     |             |         |          |
-| `B7`        | Timer 1     | Timer 1     | Timer 1     |         |          |
-| `C4`        | Timer 3     |             |             |         |          |
-| `C5`        | Timer 3     |             | Timer 1     |         |          |
-| `C6`        | Timer 3     | Timer 3     | Timer 1     |         |          |
-| `D4`        |             |             |             | Timer 1 |          |
-| `D5`        |             |             |             | Timer 1 |          |
+| ---------------- | ------------- | ------------- | ------------- | --------- | ----------- |
+| `B1`             |               |               |               |           | Timer 1     |
+| `B2`             |               |               |               |           | Timer 1     |
+| `B5`             | Timer 1       | Timer 1       |               |           |             |
+| `B6`             | Timer 1       | Timer 1       |               |           |             |
+| `B7`             | Timer 1       | Timer 1       | Timer 1       |           |             |
+| `C4`             | Timer 3       |               |               |           |             |
+| `C5`             | Timer 3       |               | Timer 1       |           |             |
+| `C6`             | Timer 3       | Timer 3       | Timer 1       |           |             |
+| `D4`             |               |               |               | Timer 1   |             |
+| `D5`             |               |               |               | Timer 1   |             |
 
-他の全てのピンはソフトウェア PWM を使います。[オーディオ](ja/feature_audio.md)機能が無効あるいは1つのタイマだけを使っている場合は、ハードウェアタイマによってバックライト PWM を引き起こすことができます:
+他の全てのピンはタイマー支援ソフトウェア PWM を使います。
 
 | オーディオピン | オーディオタイマ | ソフトウェア PWM タイマ |
-|---------|-----------|------------------|
-| `C4`    | Timer 3 | Timer 1 |
-| `C5`    | Timer 3 | Timer 1 |
-| `C6`    | Timer 3 | Timer 1 |
-| `B5`    | Timer 1 | Timer 3 |
-| `B6`    | Timer 1 | Timer 3 |
-| `B7`    | Timer 1 | Timer 3 |
+| -------------- | ---------------- | ----------------------- |
+| `C4`           | Timer 3          | Timer 1                 |
+| `C5`           | Timer 3          | Timer 1                 |
+| `C6`           | Timer 3          | Timer 1                 |
+| `B5`           | Timer 1          | Timer 3                 |
+| `B6`           | Timer 1          | Timer 3                 |
+| `B7`           | Timer 1          | Timer 3                 |
 
-両方のタイマーがオーディオのために使われている場合、バックライト PWM はハードウェアタイマを使いませんが、代わりにマトリックススキャンの間に引き起こされます。この場合、PWM の計算は十分なタイミングの精度で呼ばれないかもしれないため、バックライトの明滅はサポートされず、バックライトもちらつくかもしれません。
+両方のタイマーがオーディオのために使われている場合、バックライト PWM はハードウェアタイマを使うことができず、代わりにマトリックススキャンの間に引き起こされます。この場合、PWM の計算は十分なタイミングの精度で呼ばれない可能性があるため、バックライトの明滅はサポートされず、バックライトもちらつくかもしれません。
 
-### AVR 設定
-
-バックライトの挙動を変更するには、`config.h` の中で以下の `#define` をします:
-
-| 定義 | デフォルト | 説明 |
-|---------------------|-------------|--------------------------------------------------------------------------------------------------------------|
-| `BACKLIGHT_PIN`       | `B7`      | LED を制御するピン。自身のキーボードを設計している場合を除き、これを変更する必要はないはずです |
-| `BACKLIGHT_PINS`      | *定義なし* | 実験的: 詳細は以下を見てください |
-| `BACKLIGHT_LEVELS`    | `3`       | 輝度のレベルの数 (オフを除いて最大 31) |
-| `BACKLIGHT_CAPS_LOCK` | *定義なし* | バックライトを使って Caps Lock のインジケータを有効にする (専用 LED の無いキーボードのため) |
-| `BACKLIGHT_BREATHING` | *定義なし* | サポートされる場合は、バックライトの明滅動作を有効にする |
-| `BREATHING_PERIOD`    | `6`       | 各バックライトの "明滅" の長さ（秒） |
-| `BACKLIGHT_ON_STATE`  | `1`       | バックライトが "オン" の時のバックライトピンの状態 - high の場合は `1`、low の場合は `0` |
-
-### バックライトオン状態
-
-ほとんどのバックライトの回路は N チャンネルの MOSFET あるいは NPN トランジスタによって駆動されます。これは、トランジスタを*オン*にして LED を点灯させるには、ゲートまたはベースに接続されているバックライトピンを *high* に駆動する必要があることを意味します。
-ただし、P チャンネルの MOSFET あるいは PNP トランジスタが使われる場合があります。この場合、トランジスタがオンの時、ピンは代わりに *low* で駆動されます。
-
-この機能は `BACKLIGHT_ON_STATE` 定義することでキーボードレベルで設定されます。
-
-### 複数のバックライトピン
-
-ほとんどのキーボードは、全てのバックライト LED を制御するたった1つのバックライトピンを持ちます (特にバックライトがハードウェア PWM ピンに接続されている場合)。
-ソフトウェア PWM では、複数のバックライトピンを定義することができます。これらすべてのピンは PWM デューティサイクル時に同時にオンおよびオフになります。
-この機能により、例えば Caps Lock LED (またはその他の制御可能な LED) の輝度を、バックライトの他の LED と同じレベルに設定することができます。Caps Lock の代わりに LCTRL をマップしていて、Caps Lock がオンの時に Caps Lock LED をアクティブにする代わりにバックライトの一部にする必要がある場合に便利です。
-
-複数のバックライトピンをアクティブにするには、`config.h` に次のようなものを追加する必要があります:
-
-```c
-#define BACKLIGHT_LED_COUNT 2
-#undef BACKLIGHT_PIN
-#define BACKLIGHT_PINS { F5, B2 }
-```
-
-### ハードウェア PWM 実装
+#### ハードウェア PWM 実装 :id=hardware-pwm-implementation
 
 バックライト用にサポートされているピンを使う場合、QMK は PWM 信号を出力するように設定されたハードウェアタイマを使います。タイマーは 0 にリセットする前に `ICRx` (デフォルトでは `0xFFFF`) までカウントします。
-希望の輝度が計算され、`OCRxx` レジスタ内に格納されます。カウンタがこの値まで達すると、バックライトピンは low になり、カウンタがリセットされると再び high になります。
+希望の輝度が計算され、`OCRxx` レジスタに格納されます。カウンタがこの値まで達すると、バックライトピンは low になり、カウンタがリセットされると再び high になります。
 このように `OCRxx` は基本的に LED のデューティサイクル、従って輝度を制御します。`0x0000` は完全にオフで、 `0xFFFF` は完全にオンです。
 
 明滅動作の効果はカウンタがリセットされる(秒間あたりおよそ244回)たびに呼び出される `TIMER1_OVF_vect` の割り込みハンドラを登録することで可能になります。
-このハンドラ内で、増分カウンタの値が事前に計算された輝度曲線にマップされます。明滅動作をオフにするには、割り込みを単純に禁止し、輝度を EEPROM に格納されているレベルに再設定します。
+このハンドラで、増分カウンタの値が事前に計算された輝度曲線にマップされます。明滅動作をオフにするには、割り込みを単純に禁止し、輝度を EEPROM に格納されているレベルに再設定します。
 
-### タイマーにアシストされた PWM 実装
+#### タイマー支援 PWM 実装 :id=timer-assisted-implementation
 
 `BACKLIGHT_PIN` がハードウェアバックライトピンに設定されていない場合、QMK はソフトウェア割り込みを引き起こすように設定されているハードウェアタイマを使います。タイマーは 0 にリセットする前に `ICRx` (デフォルトでは `0xFFFF`) までカウントします。
 0 に再設定すると、CPU は LED をオンにする OVF (オーバーフロー)割り込みを発火し、デューティサイクルを開始します。
-希望の輝度が計算され、`OCRxx` レジスタ内に格納されます。カウンタがこの値に達すると、CPU は比較出力一致割り込みを発火し、LED をオフにします。
+希望の輝度が計算され、`OCRxx` レジスタに格納されます。カウンタがこの値に達すると、CPU は比較出力一致割り込みを発火し、LED をオフにします。
 このように `OCRxx` は基本的に LED のデューティサイクル、従って輝度を制御します。 `0x0000` は完全にオフで、 `0xFFFF` は完全にオンです。
 
 明滅の効果はハードウェア PWM 実装と同じです。
 
-## ARM ドライバ
+### ARM ドライバ :id=arm-configuration
+
+まだ初期段階ですが、ARM バックライトサポートは最終的に AVR と同等の機能を持つことを目指しています。`pwm` ドライバはデフォルトで設定されますが、`rules.mk` 内での同等の設定は以下の通りです:
 
-まだ初期段階ですが、ARM バックライトサポートは最終的に AVR と同等の機能を持つことを目指しています。ドライバはデフォルトで設定されますが、rules.mk 内の同等の設定は以下の通りです:
 ```makefile
 BACKLIGHT_DRIVER = pwm
 ```
 
-### 注意事項
+#### ChibiOS の設定 :id=arm-configuration
 
-現在のところ、ハードウェア PWM のみがサポートされ、タイマーはアシストされず、自動設定は提供されません。
+以下の `#define` は ARM ベースのキーボードにのみ適用されます:
 
-?> STMF072 のバックライトサポートのテストは制限されています。人によって違うかもしれません。不明な場合は、rules.mk で `BACKLIGHT_ENABLE = no` を設定します。
+| 定義                    | デフォルト | 説明                    |
+| ----------------------- | ---------- | ----------------------- |
+| `BACKLIGHT_PWM_DRIVER`  | `PWMD4`    | 使用する PWM ドライバ   |
+| `BACKLIGHT_PWM_CHANNEL` | `3`        | 使用する PWM チャンネル |
+| `BACKLIGHT_PAL_MODE`    | `2`        | 使用するピン代替関数    |
 
-### ARM 設定
+これらの値を決定するには、特定の MCU の ST データシートを参照してください。独自のキーボードを設計しているわけではない場合、通常はこれらを変更する必要はありません。
 
-バックライトの挙動を変更するには、`config.h` の中で以下の `#define` をします:
+#### 注意事項 :id=arm-caveats
 
-| 定義 | デフォルト | 説明 |
-|------------------------|-------------|-------------------------------------------------------------------------------------------------------------|
-| `BACKLIGHT_PIN`         | `B7`    | LED を制御するピン。自身のキーボードを設計している場合を除き、これを変更する必要はないはずです |
-| `BACKLIGHT_PWM_DRIVER`  | `PWMD4` | 使用する PWM ドライバ。ピンから PWM タイマへのマッピングについては、ST データシートを見てください。自身のキーボードを設計している場合を除き、これを変更する必要はないはずです |
-| `BACKLIGHT_PWM_CHANNEL` | `3`     | 使用する PWM チャンネル。ピンから PWM チャンネルへのマッピングについては、ST データシートを見てください。自身のキーボードを設計している場合を除き、これを変更する必要はないはずです |
-| `BACKLIGHT_PAL_MODE`    | `2`     | 使用するピンの代替機能。ピンの AF マッピングについては ST データシートを見てください。自身のキーボードを設計している場合を除き、これを変更する必要はないはずです |
+現在のところ、ハードウェア PWM のみがサポートされ、タイマー支援はなく、自動設定は提供されません。
 
-## Software PWM Driver :id=software-pwm-driver
+### ソフトウェア PWM ドライバ :id=software-pwm-driver
+
+このモードでは、他のキーボードのタスクを実行中に PWM は「エミュレート」されます。追加のプラットフォーム設定なしで最大のハードウェア互換性を提供します。トレードオフは、キーボードが忙しい時にバックライトが揺れる可能性があることです。有効にするには、`rules.mk` に以下を追加します:
 
-他のキーボードのタスクを実行中に PWM をエミュレートすることにより、追加のプラットフォーム設定なしで最大のハードウェア互換性を提供します。トレードオフは、キーボードが忙しい時にバックライトが揺れる可能性があることです。有効にするには、rules.mk に以下を追加します:
 ```makefile
 BACKLIGHT_DRIVER = software
 ```
 
-### ソフトウェア PWM 設定
-
-バックライトの挙動を変更するには、`config.h` の中で以下の `#define` をします:
-
-| 定義 | デフォルト | 説明 |
-|-----------------|-------------|-------------------------------------------------------------------------------------------------------------|
-| `BACKLIGHT_PIN`  | `B7`      | LED を制御するピン。自身のキーボードを設計している場合を除き、これを変更する必要はないはずです |
-| `BACKLIGHT_PINS` | *定義なし* | 実験的: 詳細は以下を見てください |
-
-### 複数のバックライトピン
+#### 複数のバックライトピン :id=multiple-backlight-pins
 
 ほとんどのキーボードは、全てのバックライト LED を制御するたった1つのバックライトピンを持ちます (特にバックライトがハードウェア PWM ピンに接続されている場合)。
-ソフトウェア PWM では、複数のバックライトピンを定義することができます。これらすべてのピンは PWM デューティサイクル時に同時にオンおよびオフになります。
-この機能により、例えば Caps Lock LED (またはその他の制御可能な LED) の輝度を、バックライトの他の LED と同じレベルに設定することができます。Caps Lock の代わりに LCTRL をマップしていて、Caps Lock がオンの時に Caps Lock LED をアクティブにする代わりにバックライトの一部にする必要がある場合に便利です。
+ソフトウェア PWM では、複数のバックライトピンを定義することができます。これらのピンは PWM デューティサイクル時に同時にオンおよびオフになります。
 
-複数のバックライトピンをアクティブにするには、`config.h` に次のようなものを追加する必要があります:
+この機能により、例えば Caps Lock LED (またはその他の制御可能な LED) の輝度を、バックライトの他の LED と同じレベルに設定することができます。Caps Lock LED は通常バックライトとは別のピンに配線されるため、Caps Lock の代わりに Control をマップしていて、Caps Lock がオンの時に Caps Lock LED ではなくバックライトの一部をアクティブにする必要がある場合に便利です。
+
+複数のバックライトピンをアクティブにするには、`config.h` に `BACKLIGHT_PIN` の代わりに次のようなものを追加します:
 
 ```c
-#undef BACKLIGHT_PIN
 #define BACKLIGHT_PINS { F5, B2 }
 ```
 
-## カスタムドライバ
+### カスタムドライバ :id=custom-driver
 
-有効にするには、rules.mk に以下を追加します:
+上記ドライバのいずれもキーボードに適用されていない場合(例えば、バックライトを制御するのに別の IC を使用している場合)、QMK が提供しているこの簡単な API を使ってカスタムバックライトドライバを実装することができます。有効にするには、`rules.mk` に以下を追加します:
 
 ```makefile
 BACKLIGHT_DRIVER = custom
 ```
 
-カスタムドライバ API を実装する場合、提供されるキーボードフックは以下の通りです:
+それから次のフックのいずれかを実装します:
 
 ```c
 void backlight_init_ports(void) {
     // オプション - 起動時に実行されます
-    //          - 通常、ここでピンを設定します
+    //   通常、ここでピンを設定します
 }
 void backlight_set(uint8_t level) {
     // オプション - レベルの変更時に実行されます
-    //          - 通常、ここで新しい値に応答します
+    //   通常、ここで新しい値に応答します
 }
 
 void backlight_task(void) {
     // オプション - 定期的に実行されます
-    //          - ここで長時間実行されるアクションはパフォーマンスの問題を引き起こします
+    //   これはメインキーボードループで呼び出されることに注意してください
+    //   そのため、ここで長時間実行されるアクションはパフォーマンスの問題を引き起こします
 }
 ```
+
+## 回路図の例
+
+この一般的な例では、バックライト LED は全て N チャンネル MOSFET に向かって並列に接続されています。そのゲートピンは、リンギングを回避するため 470Ωの抵抗を介してマイクロコントローラの GPIO ピンの1つに接続されています。
+プルダウン抵抗もゲートピンとグランドの間に配置されており、MCU によって駆動されていない場合にプルダウン抵抗を定義された状態に保ちます。
+これらの抵抗値は重要ではありません。詳細については、[this Electronics StackExchange question](https://electronics.stackexchange.com/q/68748) を参照してください。
+
+![バックライトの回路例](https://i.imgur.com/BmAvoUC.png)

docs/ja/feature_bluetooth.md

@@ -1,19 +1,18 @@
 # Bluetooth
 
 <!---
-  original document: 0.9.0:docs/feature_bluetooth.md
-  git diff 0.9.0 HEAD -- docs/feature_bluetooth.md | cat
+  original document: 0.10.33:docs/feature_bluetooth.md
+  git diff 0.10.33 HEAD -- docs/feature_bluetooth.md | cat
 -->
 
 ## Bluetooth の既知のサポートハードウェア
 
-現在のところ Bluetooth のサポートは AVR ベースのチップに限られます。Bluetooth 2.1 については、QMK は RN-42 モジュールと、Bluefruit EZ-Key をサポートしますが、後者はもう生産されていません。より最近の BLE プロトコルについては、現在のところ Adafruit Bluefruit SPI Friend のみが直接サポートされています。iOS デバイスに接続するには、BLE が必要です。iOS はマウス入力をサポートしないことに注意してください。
+現在のところ Bluetooth のサポートは AVR ベースのチップに限られます。Bluetooth 2.1 については、QMK は RN-42 モジュールをサポートします。より最近の BLE プロトコルについては、現在のところ Adafruit Bluefruit SPI Friend のみが直接サポートされています。iOS デバイスに接続するには、BLE が必要です。iOS はマウス入力をサポートしないことに注意してください。
 
-| ボード | Bluetooth プロトコル | 接続タイプ | rules.mk | Bluetooth チップ |
-|----------------------------------------------------------------|----------------------------|----------------|---------------------------|--------------|
-| [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 |
+| ボード                                                           | Bluetooth プロトコル | 接続タイプ | rules.mk                  | Bluetooth チップ |
+| ---------------------------------------------------------------- | -------------------- | ---------- | ------------------------- | ---------------- |
+| 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         |
 
 まだサポートされていませんが、可能性のあるもの:
 * [Bluefruit LE UART Friend](https://www.adafruit.com/product/2479)。[tmk 実装がおそらく見つかります](https://github.com/tmk/tmk_keyboard/issues/514)
@@ -29,24 +28,22 @@
 
 Bluefruit UART friend は SPI friend に変換することができますが、これにはMDBT40 チップへの直接の再書き込みとはんだ付けが[必要です](https://github.com/qmk/qmk_firmware/issues/2274)。
 
-## Adafruit EZ-Key hid
-これには[ハードウェアの変更](https://www.reddit.com/r/MechanicalKeyboards/comments/3psx0q/the_planck_keyboard_with_bluetooth_guide_and/?ref=search_posts)が必要ですが、Makefile を使って有効にすることができます。ファームウェアは引き続き USB 経由で文字を出力するため、コンピュータ経由で充電する場合は注意してください。任意にオフにするために Bluefruit 上にスイッチを持つことは理にかなっています。
-
-
 <!-- FIXME: Document bluetooth support more completely. -->
 ## Bluetooth の Rules.mk オプション
-これらのうちの1つだけを使ってください
+
+現在サポートされている Bluetooth チップセットは [N-キーロールオーバー (NKRO)](ja/reference_glossary.md#n-key-rollover-nkro) をサポートしていません。そのため、`rules.mk` に `NKRO_ENABLE = no` を含めなければなりません。
+
+Bluetooth を有効にするには、以下のうちの1つだけを使ってください:
 * BLUETOOTH_ENABLE = yes (レガシーオプション)
 * BLUETOOTH = RN42
-* BLUETOOTH = AdafruitEZKey
 * BLUETOOTH = AdafruitBLE
 
 ## Bluetooth キーコード
 
 これは複数のキーボードの出力が選択できる場合に使われます。現在のところ、これは USB と Bluetooth の両方をサポートするキーボードで、それらの間の切り替えのみが可能です。
 
-| 名前 | 説明 |
-|----------|----------------------------------------------|
+| 名前       | 説明                                  |
+| ---------- | ------------------------------------- |
 | `OUT_AUTO` | USB と Bluetooth を自動的に切り替える |
-| `OUT_USB` | USB のみ |
-| `OUT_BT` | Bluetooth のみ |
+| `OUT_USB`  | USB のみ                              |
+| `OUT_BT`   | Bluetooth のみ                        |

docs/ja/feature_combo.md

@@ -1,8 +1,8 @@
 # コンボ
 
 <!---
-  original document: 0.8.94:docs/feature_combo.md
-  git diff 0.8.94 HEAD -- docs/feature_combo.md | cat
+  original document: 0.10.36:docs/feature_combo.md
+  git diff 0.10.36 HEAD -- docs/feature_combo.md | cat
 -->
 
 コンボ機能は、同時押し方式でのカスタムアクション追加機能です。同時に複数のキーを押して、異なる効果を生み出すことができます。例えば、タッピング時間内で `A` と `S` を押すと、代わりに `ESC` が押されます。もっと複雑なタスクを実行させることもできます。
@@ -60,7 +60,7 @@ combo_t key_combos[COMBO_COUNT] = {
   [XV_PASTE] = COMBO_ACTION(paste_combo),
 };
 
-void process_combo_event(uint8_t combo_index, bool pressed) {
+void process_combo_event(uint16_t combo_index, bool pressed) {
   switch(combo_index) {
     case ZC_COPY:
       if (pressed) {

docs/ja/feature_debounce_type.md

@@ -0,0 +1,47 @@
+# デバウンスアルゴリズム
+
+<!---
+  original document: 0.9.19:docs/feature_debounce_type.md
+  git diff 0.9.19 HEAD -- docs/feature_debounce_type.md | cat
+-->
+
+QMK はデバウンス API を介して複数のデバウンスアルゴリズムをサポートします。
+
+どのデバウンスメソッドが呼ばれるかのロジックは下記のとおりです。rules.mk で設定された様々な定義をチェックします。
+
+```
+DEBOUNCE_DIR:= $(QUANTUM_DIR)/debounce
+DEBOUNCE_TYPE?= sym_g
+ifneq ($(strip $(DEBOUNCE_TYPE)), custom)
+    QUANTUM_SRC += $(DEBOUNCE_DIR)/$(strip $(DEBOUNCE_TYPE)).c
+endif
+```
+
+# デバウンスの選択
+
+| DEBOUNCE_TYPE | 説明 | 他に必要なもの |
+| -------------    | ---------------------------------------------------  | ----------------------------- |
+| 未定義 | デフォルトのアルゴリズム、現在のところ sym_g を使います | 無し |
+| custom | 独自のデバウンスコードを使います | ```SRC += debounce.c``` で独自の debounce.c を追加し、必要な関数を実装します |
+| anything_else | quantum/debounce/* から他のアルゴリズムを使います | 無し |
+
+**分割キーボードについて**:
+デバウンスコードは分割キーボードと互換性があります。
+
+# 独自のデバウンスコードの使用
+* ```DEBOUNCE_TYPE = custom``` を設定します。
+* ```SRC += debounce.c``` を追加します。
+* 独自の ```debounce.c``` を追加します。例については、```quantum/debounce``` にある現在の実装をみてください。
+* 毎回のマトリクススキャンの結果はその度デバウンスによって処理されます。
+* MATRIX_ROWS ではなく num_rows を使って、分割キーボードが正しくサポートされるようにします。
+
+# インクルードされているデバウンスメソッド間での切り替え
+独自の debounce.c をインクルードすることで独自のコードを使うか、またはインクルードされている他のコードに切り替えることができます。
+含まれるデバウンスメソッドは以下の通りです:
+* eager_pr - 行ごとにデバウンスします。状態が変化すると、応答は即座に行われ、その後その行は ```DEBOUNCE``` ミリ秒の間入力されません。
+```NUM_KEYS``` の 8ビットカウンタの更新に高い計算コストがかかる、もしくは低スキャンレートのキーボード用で、各指は通常一度に1行しか叩かないようになっています。これは ErgoDox モデルに適しています; マトリックスは90度回転しているため、その「行」は実際には「列」であり、通常の使用では各指は一度に1つの「行」にしか当たりません。
+* eager_pk - キーごとにデバウンスします。状態が変化すると、応答は即座に行われ、その後そのキーは ```DEBOUNCE``` ミリ秒の間入力されません。
+* sym_g - キーボードごとにデバウンスします。状態が変化すると、グローバルタイマが設定されます。```DEBOUNCE``` ミリ秒の間何も変化がなければ、全ての入力の変更がプッシュされます。
+* sym_pk - キーごとにデバウンスします。状態が変化すると、キーごとのタイマーが設定されます。```DEBOUNCE``` ミリ秒の間そのキーに変化がなければ、キーの状態の変更がプッシュされます。
+
+

docs/ja/feature_dip_switch.md

@@ -1,8 +1,8 @@
 # DIP スイッチ
 
 <!---
-  original document: 0.8.94:docs/feature_dip_switch.md
-  git diff 0.8.94 HEAD -- docs/feature_dip_switch.md | cat
+  original document: 0.9.43:docs/feature_dip_switch.md
+  git diff 0.9.43 HEAD -- docs/feature_dip_switch.md | cat
 -->
 
 DIP スイッチは、以下を `rules.mk` に追加することでサポートされます:
@@ -12,9 +12,17 @@ DIP スイッチは、以下を `rules.mk` に追加することでサポート
 さらに、以下を `config.h` に追加します:
 
 ```c
+// Connects each switch in the dip switch to the GPIO pin of the MCU
 #define DIP_SWITCH_PINS { B14, A15, A10, B9 }
 ```
 
+あるいは
+
+```c
+// Connect each switch in the DIP switch to an unused intersections in the key matrix.
+#define DIP_SWITCH_MATRIX_GRID { {0,6}, {1,6}, {2,6} } // List of row and col pairs
+```
+
 ## コールバック
 
 コールバック関数を `<keyboard>.c` に記述することができます:
@@ -92,4 +100,10 @@ void dip_switch_update_mask_user(uint32_t state) {
 
 ## ハードウェア
 
+### DIP スイッチの各スイッチを MCU の GPIO ピンに接続する
+
 DIP スイッチの片側は MCU のピンへ直接配線し、もう一方の側はグラウンドに配線する必要があります。機能的に同じであるため、どちら側がどちらに接続されているかは問題にはならないはずです。
+
+### DIP スイッチの各スイッチをキーマトリクスの未使用の交点に接続する
+
+キースイッチと同じように、ダイオードと DIP スイッチが ROW 線と COL 線に接続します。

docs/ja/feature_dynamic_macros.md

@@ -1,8 +1,8 @@
 # 動的マクロ: ランタイムでのマクロの記録および再生
 
 <!---
-  original document: 0.8.123:docs/feature_dynamic_macros.md
-  git diff 0.8.123 HEAD -- docs/feature_dynamic_macros.md | cat
+  original document: 0.10.33:docs/feature_dynamic_macros.md
+  git diff 0.10.33 HEAD -- docs/feature_dynamic_macros.md | cat
 -->
 
 QMK はその場で作られた一時的なマクロをサポートします。これらを動的マクロと呼びます。それらはユーザがキーボードから定義し、キーボードのプラグを抜くか再起動すると失われます。
@@ -23,7 +23,7 @@ QMK はその場で作られた一時的なマクロをサポートします。
 
 マクロの記録を開始するには、`DYN_REC_START1` または `DYN_REC_START2` のどちらかを押します。
 
-記録を終了するには、`DYN_REC_STOP` レイヤーボタンを押します。
+記録を終了するには、`DYN_REC_STOP` レイヤーボタンを押します。`DYN_REC_START1` または `DYN_REC_START2` をもう一度押すことでも記録を終了することができます。
 
 マクロを再生するには、`DYN_MACRO_PLAY1` あるいは `DYN_MACRO_PLAY2` のどちらかを押します。
 

docs/ja/feature_encoders.md

@@ -1,8 +1,8 @@
 # エンコーダ
 
 <!---
-  original document: 0.8.123:docs/feature_encoders.md
-  git diff 0.8.123 HEAD -- docs/feature_encoders.md | cat
+  original document: 0.9.43:docs/feature_encoders.md
+  git diff 0.9.43 HEAD -- docs/feature_encoders.md | cat
 -->
 
 以下を `rules.mk` に追加することで基本的なエンコーダがサポートされます:
@@ -31,7 +31,7 @@ ENCODER_ENABLE = yes
 #define ENCODER_DIRECTION_FLIP
 ```
 
-さらに、解像度を同じファイルで指定することができます (デフォルトかつお勧めは4):
+さらに、エンコーダが各戻り止め(デテント)間に登録するパルス数を定義する解像度は、次のように定義できます:
 
 ```c
 #define ENCODER_RESOLUTION 4

docs/ja/feature_hd44780.md

@@ -1,11 +1,11 @@
 # HD44780 LCD ディスプレイ
 
 <!---
-  original document: 0.8.123:docs/feature_hd44780.md
-  git diff 0.8.123 HEAD -- docs/feature_hd44780.md | cat
+  original document: 0.9.43:docs/feature_hd44780.md
+  git diff 0.9.43 HEAD -- docs/feature_hd44780.md | cat
 -->
 
-これは Peter Fleury の LCD ライブラリの統合です。このページは基本について説明します。[詳細なドキュメントについてはこのページをご覧ください](http://homepage.hispeed.ch/peterfleury/doxygen/avr-gcc-libraries/group__pfleury__lcd.html) (訳注）原文のリンク先のページは、サービスの終了に伴って削除されています。移行先は (http://www.peterfleury.epizy.com/doxygen/avr-gcc-libraries/group__pfleury__lcd.html) と思われます。
+これは Peter Fleury の LCD ライブラリの統合です。このページは基本について説明します。[詳細なドキュメントについてはこのページをご覧ください](http://www.peterfleury.epizy.com/doxygen/avr-gcc-libraries/group__pfleury__lcd.html)
 
 HD44780 ディスプレイのサポートを有効にするには、キーボードの `rules.mk` の `HD44780_ENABLE` フラグを yes に設定します。
 
@@ -59,4 +59,4 @@ LCD_DISP_ON_CURSOR_BLINK : ディスプレイオン、点滅カーソル
 
 ディスプレイに何かを表示するには、最初に `lcd_gotoxy(column, line)` を呼びます。最初の行の先頭に移動するには、`lcd_gotoxy(0, 0)` を呼び出し、その後 `lcd_puts("example string")` を使って文字列を出力します。
 
-ディスプレイを制御することができる、より多くのメソッドがあります。[詳細なドキュメントについてはリンクされたページをご覧ください](http://homepage.hispeed.ch/peterfleury/doxygen/avr-gcc-libraries/group__pfleury__lcd.html) (訳注）原文のリンク先のページは、サービスの終了に伴って削除されています。移行先は (http://www.peterfleury.epizy.com/doxygen/avr-gcc-libraries/group__pfleury__lcd.html) と思われます。
+ディスプレイを制御することができる、より多くのメソッドがあります。[詳細なドキュメントについてはリンクされたページをご覧ください](http://www.peterfleury.epizy.com/doxygen/avr-gcc-libraries/group__pfleury__lcd.html)

docs/ja/feature_layers.md

@@ -1,8 +1,8 @@
 # レイヤー :id=layers
 
 <!---
-  original document: 0.9.20:docs/feature_layers.md
-  git diff 0.9.20 HEAD -- docs/feature_layers.md | cat
+  original document: 0.9.43:docs/feature_layers.md
+  git diff 0.9.43 HEAD -- docs/feature_layers.md | cat
 -->
 
 QMK ファームウェアの最も強力で良く使われている機能の一つは、レイヤーを使う機能です。ほとんどの人にとって、これはラップトップやタブレットキーボードにあるのと同じように、様々なキーを可能にするファンクションキーに相当します。
@@ -58,42 +58,42 @@ QMK を使い始めたばかりの場合は、全てを単純にしたいでし
 
 レイヤーの使用あるいは操作に関係する多くの関数(と変数)があります。
 
-| 関数 | 説明 |
-|----------------------------------------------|---------------------------------------------------------------------------------------------------------|
-| `layer_state_set(layer_mask)` | 直接レイヤーの状態を設定する (推奨。何をしているのか分かっていない場合は使わないでください)。 |
-| `layer_clear()` | 全てのレイヤーを消去する (全てをオフにします)。 |
-| `layer_move(layer)` | 指定されたレイヤーをオンにし、それ以外をオフにする。 |
-| `layer_on(layer)` | 指定されたレイヤーをオンにし、それ以外を既存の状態のままにする。 |
-| `layer_off(layer)` | 指定されたレイヤーをオフにし、それ以外を既存の状態のままにする。 |
-| `layer_invert(layer)` | 指定されたレイヤーの状態を反転/トグルする。 |
-| `layer_or(layer_mask)` | 指定されたレイヤーと既存のレイヤー状態の間で一致するビットに基づいてレイヤーをオンにする。 |
-| `layer_and(layer_mask)` | 指定されたレイヤーと既存のレイヤー状態の間で有効なビットに基づいてレイヤーをオンにする。 |
-| `layer_xor(layer_mask)` | 指定されたレイヤーと既存のレイヤー状態の間で一致しないビットに基づいてレイヤーをオンにする。 |
-| `layer_debug(layer_mask)` | デバッガのコンソールに現在のビットマスクと最も高いレイヤーを出力する。 |
-| `default_layer_set(layer_mask)` | 直接デフォルトレイヤーの状態を設定する (推奨。何をしているのか分かっていない場合は使わないでください)。 |
-| `default_layer_or(layer_mask)` | 指定されたレイヤーと既存のデフォルトレイヤー状態の間で一致するビットに基づいてレイヤーをオンにする。 |
-| `default_layer_and(layer_mask)` | 指定されたレイヤーと既存のデフォルトレイヤー状態の間で一致する有効なビットに基づいてレイヤーをオンにする。 |
-| `default_layer_xor(layer_mask)` | 指定されたレイヤーと既存のデフォルトレイヤー状態の間で一致しないビットに基づいてレイヤーをオンにする。 |
-| `default_layer_debug(layer_mask)` | デバッガのコンソールに現在のビットマスクと最も高いアクティブなレイヤーを出力する。 |
-| [`set_single_persistent_default_layer(layer)`](ja/ref_functions.md#setting-the-persistent-default-layer) | デフォルトレイヤーを設定し、それを永続化メモリ (EEPROM) に書き込む。 |
-| [`update_tri_layer(x, y, z)`](ja/ref_functions.md#update_tri_layerx-y-z) | レイヤー `x` と `y` の両方がオンであるかを調べ、それに基づいて `z` を設定する(両方がオンの場合オン、そうでなければオフ)。 |
-| [`update_tri_layer_state(state, x, y, z)`](ja/ref_functions.md#update_tri_layer_statestate-x-y-z) | `update_tri_layer(x, y, z)` と同じことをするが、`layer_state_set_*` 関数から呼ばれる。 |
+| 関数                                         | 説明                                                                                                       |
+| -------------------------------------------- | ---------------------------------------------------------------------------------------------------------- |
+| `layer_state_set(layer_mask)`                | 直接レイヤーの状態を設定する (推奨。何をしているのか分かっていない場合は使わないでください)。              |
+| `layer_clear()`                              | 全てのレイヤーを消去する (全てをオフにします)。                                                            |
+| `layer_move(layer)`                          | 指定されたレイヤーをオンにし、それ以外をオフにする。                                                       |
+| `layer_on(layer)`                            | 指定されたレイヤーをオンにし、それ以外を既存の状態のままにする。                                           |
+| `layer_off(layer)`                           | 指定されたレイヤーをオフにし、それ以外を既存の状態のままにする。                                           |
+| `layer_invert(layer)`                        | 指定されたレイヤーの状態を反転/トグルする。                                                                |
+| `layer_or(layer_mask)`                       | 指定されたレイヤーと既存のレイヤー状態の間で一致するビットに基づいてレイヤーをオンにする。                 |
+| `layer_and(layer_mask)`                      | 指定されたレイヤーと既存のレイヤー状態の間で有効なビットに基づいてレイヤーをオンにする。                   |
+| `layer_xor(layer_mask)`                      | 指定されたレイヤーと既存のレイヤー状態の間で一致しないビットに基づいてレイヤーをオンにする。               |
+| `layer_debug(layer_mask)`                    | デバッガのコンソールに現在のビットマスクと最も高いレイヤーを出力する。                                     |
+| `default_layer_set(layer_mask)`              | 直接デフォルトレイヤーの状態を設定する (推奨。何をしているのか分かっていない場合は使わないでください)。    |
+| `default_layer_or(layer_mask)`               | 指定されたレイヤーと既存のデフォルトレイヤー状態の間で一致するビットに基づいてレイヤーをオンにする。       |
+| `default_layer_and(layer_mask)`              | 指定されたレイヤーと既存のデフォルトレイヤー状態の間で一致する有効なビットに基づいてレイヤーをオンにする。 |
+| `default_layer_xor(layer_mask)`              | 指定されたレイヤーと既存のデフォルトレイヤー状態の間で一致しないビットに基づいてレイヤーをオンにする。     |
+| `default_layer_debug(layer_mask)`            | デバッガのコンソールに現在のビットマスクと最も高いアクティブなレイヤーを出力する。                         |
+| [`set_single_persistent_default_layer(layer)`](ja/ref_functions.md#setting-the-persistent-default-layer) | デフォルトレイヤーを設定し、それを永続化メモリ (EEPROM) に書き込む。                                                      |
+| [`update_tri_layer(x, y, z)`](ja/ref_functions.md#update_tri_layerx-y-z)                                 | レイヤー `x` と `y` の両方がオンであるかを調べ、それに基づいて `z` を設定する(両方がオンの場合オン、そうでなければオフ)。 |
+| [`update_tri_layer_state(state, x, y, z)`](ja/ref_functions.md#update_tri_layer_statestate-x-y-z)        | `update_tri_layer(x, y, z)` と同じことをするが、`layer_state_set_*` 関数から呼ばれる。                                    |
 
 
 呼び出すことができる関数に加えて、レイヤーが変更されるたびに呼び出されるコールバック関数が幾つかあります。これはレイヤー状態を関数に渡し、読み取りや変更することができます。
 
-| コールバック | 説明 |
-|-----------------------------------------------------|----------------------------------------------------------------------------------------|
-| `layer_state_set_kb(layer_state_t state)` | キーボードレベルのレイヤー関数のためのコールバック。 |
-| `layer_state_set_user(layer_state_t state)` | ユーザレベルのレイヤー関数のためのコールバック。 |
-| `default_layer_state_set_kb(layer_state_t state)` | キーボードレベルのデフォルトレイヤー関数のためのコールバック。キーボードの初期化時に呼ばれます。 |
-| `default_layer_state_set_user(layer_state_t state)` | ユーザレベルのデフォルトレイヤー関数のためのコールバック。キーボードの初期化時に呼ばれます。 |
+| コールバック                                        | 説明                                                                                             |
+| --------------------------------------------------- | ------------------------------------------------------------------------------------------------ |
+| `layer_state_set_kb(layer_state_t state)`           | キーボードレベルのレイヤー関数のためのコールバック。                                             |
+| `layer_state_set_user(layer_state_t state)`         | ユーザレベルのレイヤー関数のためのコールバック。                                                 |
+| `default_layer_state_set_kb(layer_state_t state)`   | キーボードレベルのデフォルトレイヤー関数のためのコールバック。キーボードの初期化時に呼ばれます。 |
+| `default_layer_state_set_user(layer_state_t state)` | ユーザレベルのデフォルトレイヤー関数のためのコールバック。キーボードの初期化時に呼ばれます。     |
 
 ?> これらのコールバックを使うための追加の情報については、[レイヤー変換コード](ja/custom_quantum_functions.md#layer-change-code)のドキュメントを調べてください。
 
-| チェック関数 | 説明 |
-|-------------------------------------------|------------------------------------------------------------------------------|
-| `layer_state_cmp(cmp_layer_state, layer)` | これは `cmp_layer_state` を調べて、指定された `layer` が有効かどうかを確認します。これは、レイヤーコールバックで使うためのものです。 |
-| `layer_state_is(layer)` | これはレイヤーの状態を調べて、指定された `layer` が有効かどうかを確認します。(グローバルレイヤー状態については、`layer_state_cmp` を呼びます)。 |
+次の関数やマクロを使って、特定のレイヤーの状態を確認することもできます。
 
-!> `IS_LAYER_ON(layer)` もありますが、`layer_state_cmp` 関数には、レイヤー0で正しい値を返すようにするために追加の処理があります。さもないと、レイヤー0がオンになっているかどうかを確認する時に誤った値が返されることがあります。
+| 関数                            | 説明                                                                                                          | 別名                                                                  |
+| ------------------------------- | ------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------- |
+| `layer_state_is(layer)`         | 指定された `layer` がグローバルに有効かどうかを確認する。                                                     | `IS_LAYER_ON(layer)`, `IS_LAYER_OFF(layer)`                           |
+| `layer_state_cmp(state, layer)` | `state` を確認して指定された `layer` が有効かどうかを確認する。レイヤーのコールバックで使うことを目的とする。 | `IS_LAYER_ON_STATE(state, layer)`, `IS_LAYER_OFF_STATE(state, layer)` |

docs/ja/feature_leader_key.md

@@ -1,8 +1,8 @@
 # リーダーキー: 新しい種類のモディファイア
 
 <!---
-  original document: 0.8.134:docs/feature_leader_key.md
-  git diff 0.8.134 HEAD -- docs/feature_leader_key.md | cat
+  original document: 0.10.33:docs/feature_leader_key.md
+  git diff 0.10.33 HEAD -- docs/feature_leader_key.md | cat
 -->
 
 もしあなたが Vim を使ったことがある場合、リーダーキーは何であるかを知っています。そうでなければ、素晴らしい概念を発見しようとしています。:) 例えば、Alt+Shift+W を押す(3つのキーを同時に押す)代わりに、キーの_シーケンス_を押すことができたらどうでしょう？つまり、特別なモディファイア (リーダーキー)を押して、続けて W と C を押すと (単純にキーを高速に繋げます)、何かが起こります。

docs/ja/feature_macros.md

@@ -1,8 +1,8 @@
 # マクロ
 
 <!---
-  original document: 0.8.169:docs/feature_macros.md
-  git diff 0.8.169 HEAD -- docs/feature_macros.md | cat
+  original document: 0.9.43:docs/feature_macros.md
+  git diff 0.9.43 HEAD -- docs/feature_macros.md | cat
 -->
 
 マクロにより、1つのキーを押すだけで複数のキーストロークを送信することができます。QMK にはマクロを定義し使う方法が幾つかあります。これらはなんでもすることができます: よく使うフレーズの入力、コピーペースト、反復的なゲームの動き、あるいはコードを書くことさえ手助けします。
@@ -11,34 +11,34 @@
 
 ## 新しい方法: `SEND_STRING()` と `process_record_user`
 
-単語またはフレーズを入力するキーが欲しい時があります。最も一般的な状況のために `SEND_STRING()` を提供しています。これは文字列(つまり、文字のシーケンス)を入力します。簡単にキーコードに変換することができる全ての ASCII 文字がサポートされています (例えば、`\n\t`)。
+単語またはフレーズを入力するキーが欲しい時があります。最も一般的な状況のために `SEND_STRING()` を提供しています。これは文字列(つまり、文字のシーケンス)を入力します。簡単にキーコードに変換することができる全ての ASCII 文字がサポートされています (例えば、`qmk 123\n\t`)。
 
 以下は2キーのキーボードのための `keymap.c` の例です:
 
 ```c
 enum custom_keycodes {
-  QMKBEST = SAFE_RANGE,
+    QMKBEST = SAFE_RANGE,
 };
 
 bool process_record_user(uint16_t keycode, keyrecord_t *record) {
-  switch (keycode) {
+    switch (keycode) {
     case QMKBEST:
-      if (record->event.pressed) {
-        // キーコード QMKBEST が押された時
-        SEND_STRING("QMK is the best thing ever!");
-      } else {
-        // キーコード QMKBEST が放された時
-      }
-      break;
-
-  }
-  return true;
+        if (record->event.pressed) {
+            // キーコード QMKBEST が押された時
+            SEND_STRING("QMK is the best thing ever!");
+        } else {
+            // キーコード QMKBEST が放された時
+        }
+        break;
+    }
+    return true;
 };
 
 const uint16_t PROGMEM keymaps[][MATRIX_ROWS][MATRIX_COLS] = {
-  [0] = {
-    {QMKBEST, KC_ESC}
-  }
+    [0] = {
+        {QMKBEST, KC_ESC},
+        // ...
+    },
 };
 ```
 
@@ -54,42 +54,45 @@ const uint16_t PROGMEM keymaps[][MATRIX_ROWS][MATRIX_COLS] = {
 
 ```c
 enum custom_keycodes {
-  QMKBEST = SAFE_RANGE,
-  QMKURL,
-  MY_OTHER_MACRO
+    QMKBEST = SAFE_RANGE,
+    QMKURL,
+    MY_OTHER_MACRO,
 };
 
 bool process_record_user(uint16_t keycode, keyrecord_t *record) {
-  switch (keycode) {
+    switch (keycode) {
     case QMKBEST:
-      if (record->event.pressed) {
-        // キーコード QMKBEST が押された時
-        SEND_STRING("QMK is the best thing ever!");
-      } else {
-        // キーコード QMKBEST が放された時
-      }
-      break;
+        if (record->event.pressed) {
+            // キーコード QMKBEST が押された時
+            SEND_STRING("QMK is the best thing ever!");
+        } else {
+            // キーコード QMKBEST が放された時
+        }
+        break;
+
     case QMKURL:
-      if (record->event.pressed) {
-        // キーコード QMKURL が押された場合
-        SEND_STRING("https://qmk.fm/\n");
-      } else {
-        // キーコード QMKURL が放された場合
-      }
-      break;
+        if (record->event.pressed) {
+            // キーコード QMKURL が押された場合
+            SEND_STRING("https://qmk.fm/\n");
+        } else {
+            // キーコード QMKURL が放された場合
+        }
+        break;
+
     case MY_OTHER_MACRO:
-      if (record->event.pressed) {
-                SEND_STRING(SS_LCTL("ac")); // 全てを選択しコピーします
-      }
-      break;
-  }
-  return true;
+        if (record->event.pressed) {
+           SEND_STRING(SS_LCTL("ac")); // 全てを選択しコピーします
+        }
+        break;
+    }
+    return true;
 };
 
 const uint16_t PROGMEM keymaps[][MATRIX_ROWS][MATRIX_COLS] = {
-  [0] = {
-    {MY_CUSTOM_MACRO, MY_OTHER_MACRO}
-  }
+    [0] = {
+        {MY_CUSTOM_MACRO, MY_OTHER_MACRO},
+        // ...
+    },
 };
 ```
 

docs/ja/feature_mouse_keys.md

@@ -1,8 +1,8 @@
 # マウスキー
 
 <!---
-  original document: 0.8.141:docs/feature_mouse_keys.md
-  git diff 0.8.141 HEAD -- docs/feature_mouse_keys.md | cat
+  original document: 0.9.44:docs/feature_mouse_keys.md
+  git diff 0.9.44 HEAD -- docs/feature_mouse_keys.md | cat
 -->
 
 マウスキーは、キーボードを使ってマウスをエミュレートできる機能です。様々な速度でポインタを移動し、5つのボタンを押し、8方向にスクロールすることができます。
@@ -44,10 +44,11 @@ MOUSEKEY_ENABLE = yes
 
 ## マウスキーの設定
 
-マウスキーはカーソルを移動するための2つの異なるモードをサポートします:
+マウスキーはカーソルを移動するための3つの異なるモードをサポートします:
 
 * **加速 (デフォルト):** 移動キーを押したままにすると、カーソルが最大速度に達するまでカーソルを加速します。
 * **定速:** 移動キーを押したままにすると、カーソルを一定の速度で移動します。
+* **混合:** 移動キーを押したままにすると、カーソルが最大速度に達するまでカーソルを加速し、加速キーと移動キーを同時に押すとカーソルは一定の速度で移動します。
 
 同じ原則がスクロールにも適用されます。
 
@@ -125,3 +126,19 @@ MOUSEKEY_ENABLE = yes
 | `MK_W_INTERVAL_1` | 120 | スクロールステップ間の時間 (`KC_ACL1`) |
 | `MK_W_OFFSET_2` | 1 | スクロールアクションごとのスクロールステップ (`KC_ACL2`) |
 | `MK_W_INTERVAL_2` | 20 | スクロールステップ間の時間 (`KC_ACL2`) |
+
+### 混合モード
+
+このモードは **加速** モードのように機能しますが、`KC_ACL0`、`KC_ACL1`、`KC_ACL2` を押したままにすることで
+一時的(押している間)にカーソルとスクロール速度を定速に設定できます。
+加速キーが押されていない場合、このモードは **加速** モードと同じで、関連する全ての設定を使って変更できます。
+
+* **KC_ACL0:** この加速はカーソルをできるだけ遅い速度に設定します。これはカーソルを非常に小さく詳細に移動する場合に便利です。
+* **KC_ACL1:** この加速はカーソルを最大(ユーザ定義)速度の半分に設定します。
+* **KC_ACL2:** この加速はカーソルを最大(コンピュータ定義)速度に設定します。これは、正確性を多少犠牲にしてカーソルを大きく移動する場合に便利です。
+
+混合モードを使うには、キーマップの `config.h` ファイルに少なくとも `MK_COMBINED` を定義しなければなりません:
+
+```c
+#define MK_COMBINED
+```

docs/ja/feature_pointing_device.md

@@ -1,8 +1,8 @@
 # ポインティングデバイス :id=pointing-device
 
 <!---
-  original document: 0.8.182:docs/feature_pointing_device.md
-  git diff 0.8.182 HEAD -- docs/feature_pointing_device.md | cat
+  original document: 0.9.43:docs/feature_pointing_device.md
+  git diff 0.9.43 HEAD -- docs/feature_pointing_device.md | cat
 -->
 
 ポインティングデバイスは汎用的な機能の総称です: システムポインタを移動します。マウスキーのような他のオプションも確かにありますが、これは簡単に変更可能で軽量であることを目指しています。機能を制御するためにカスタムキーを実装したり、他の周辺機器から情報を収集してここに直接挿入したりできます - QMK に処理を任せてください。
@@ -26,7 +26,11 @@ report_mouse_t (ここでは "mouseReport") が以下のプロパティを持つ
 * `mouseReport.h` - これは、水平スクロール(+ 右へ、- 左へ)を表す -127 から 127 (128ではなく、USB HID 仕様で定義されています)の符号付き整数です。
 * `mouseReport.buttons` - これは uint8_t で、上位の5ビットを使っています。これらのビットはマウスボタンの状態を表します - ビット 3 はマウスボタン 5、ビット 7 はマウスボタン 1 です。
 
-マウスレポートが送信されると、x、y、v、h のいずれの値も 0 に設定されます (これは "pointing_device_send()" で行われます。この挙動を回避するためにオーバーライドすることができます)。このように、ボタンの状態は持続しますが、動きは1度だけ起こります。さらにカスタマイズするために、`pointing_device_init` と `pointing_device_task` のどちらもオーバーライドすることができます。
+マウスレポートに必要な変更を行ったら、それを送信する必要があります:
+
+* `pointing_device_send()` - マウスレポートをホストに送信し、レポートをゼロにします。
+
+マウスレポートが送信されると、x、y、v、h のいずれの値も 0 に設定されます (これは `pointing_device_send()` で行われます。この挙動を回避するためにオーバーライドすることができます)。このように、ボタンの状態は持続しますが、動きは1度だけ起こります。さらにカスタマイズするために、`pointing_device_init` と `pointing_device_task` のどちらもオーバーライドすることができます。
 
 以下の例では、カスタムキーを使ってマウスをクリックし垂直および水平方向に127単位スクロールし、リリースされた時にそれを全て元に戻します - なぜならこれは完全に便利な機能だからです。いいですか、以下はひとつの例です:
 
@@ -43,6 +47,7 @@ case MS_SPECIAL:
         currentReport.buttons &= ~MOUSE_BTN1;
     }
     pointing_device_set_report(currentReport);
+    pointing_device_send();
     break;
 ```
 

docs/ja/feature_ps2_mouse.md

@@ -1,8 +1,8 @@
 # PS/2 マウスサポート :id=ps2-mouse-support
 
 <!---
-  original document: 0.8.147:docs/feature_ps2_mouse.md
-  git diff 0.8.147 HEAD -- docs/feature_ps2_mouse.md | cat
+  original document: 0.9.44:docs/feature_ps2_mouse.md
+  git diff 0.9.44 HEAD -- docs/feature_ps2_mouse.md | cat
 -->
 
 PS/2 マウス (例えばタッチパッドあるいはトラックポイント)を複合デバイスとしてキーボードに接続することができます。
@@ -291,3 +291,13 @@ X 軸と Y 軸を反転するには、以下を config.h に配置します:
 #define PS2_MOUSE_DEBUG_HID
 #define PS2_MOUSE_DEBUG_RAW
 ```
+
+### 動作フック :id=movement-hook
+
+ホストに送信される前にキーマップでマウスの動作を処理します。使用例として、
+ノイズのフィルタリング、加速の追加、レイヤーの自動アクティブ化が含まれます。
+使用するには、キーマップで次の関数を定義します:
+
+```c
+void ps2_mouse_moved_user(report_mouse_t *mouse_report);
+```

docs/ja/feature_split_keyboard.md

@@ -1,8 +1,8 @@
 # 分割キーボード
 
 <!---
-  original document:0.9.5:docs/feature_split_keyboard.md
-  git diff 0.9.5 HEAD -- docs/feature_split_keyboard.md | cat
+  original document:0.10.8:docs/feature_split_keyboard.md
+  git diff 0.10.8 HEAD -- docs/feature_split_keyboard.md | cat
 -->
 
 QMK ファームウェアリポジトリの多くのキーボードは、"分割"キーボードです。それらは2つのコントローラを使います — 1つは USB に接続し、もう1つは TRRS または同様のケーブルを介してシリアルまたは I<sup>2</sup>C 接続で接続します。
@@ -20,12 +20,12 @@ QMK ファームウェアには、任意のキーボードで使用可能な一
 
 | Transport | AVR | ARM |
 |------------------------------|--------------------|--------------------|
-| ['serial'](serial_driver.md) | :heavy_check_mark: | :white_check_mark: <sup>1</sup> |
+| ['serial'](ja/serial_driver.md) | :heavy_check_mark: | :white_check_mark: <sup>1</sup> |
 | I2C | :heavy_check_mark: |  |
 
 注意:
 
-1. ハードウェアとソフトウェアの両方の制限は、[ドライバーのドキュメント](serial_driver.md)の中で説明されます。
+1. ハードウェアとソフトウェアの両方の制限は、[ドライバーのドキュメント](ja/serial_driver.md)の中で説明されます。
 
 ## ハードウェア設定
 
@@ -53,11 +53,12 @@ QMK ファームウェアには、任意のキーボードで使用可能な一
 
 ### シリアル配線
 
-2つの Pro Micro 間で GND、Vcc、D0 (別名 PDO あるいは pin 3) を TRS/TRRS ケーブルの3本のワイヤで接続します。
+2つの Pro Micro 間で GND、Vcc、D0/D1/D2/D3 (別名 PD0/PD1/PD2/PD3) を TRS/TRRS ケーブルの3本のワイヤで接続します。
 
 ?> ここで使われるピンは実際には以下の `SOFT_SERIAL_PIN` によって設定されることに注意してください。
 
-![シリアル配線](https://i.imgur.com/C3D1GAQ.png)
+<img alt="sk-pd0-connection-mono" src="https://user-images.githubusercontent.com/2170248/92296488-28e9ad80-ef70-11ea-98be-c40cb48a0319.JPG" width="48%"/>
+<img alt="sk-pd2-connection-mono" src="https://user-images.githubusercontent.com/2170248/92296490-2d15cb00-ef70-11ea-801f-5ace313013e6.JPG" width="48%"/>
 
 ### I<sup>2</sup>C 配線
 
@@ -65,7 +66,7 @@ QMK ファームウェアには、任意のキーボードで使用可能な一
 
 プルアップ抵抗はキーボードの左右どちら側にも配置することができます。もし各側を単独で使いたい場合は、4つの抵抗を使い、両側にプルアップ抵抗を配置することもできます。
 
-![I2C 配線](https://i.imgur.com/Hbzhc6E.png)
+<img alt="sk-i2c-connection-mono" src="https://user-images.githubusercontent.com/2170248/92297182-92b98580-ef77-11ea-9d7d-d6033914af43.JPG" width="50%"/>
 
 ## ファームウェア設定
 
@@ -95,6 +96,24 @@ SPLIT_TRANSPORT = custom
 
 これは指定されたピンを読み込みます。high の場合、コントローラはそれを左側だと仮定し、low の場合、それは右側であると仮定します。
 
+#### マトリックスピンによる左右の設定
+
+左右を決定するためにコントローラのキーマトリックスピンを読むようにファームウェアを設定することができます。これを行うには、以下を `config.h` ファイルに追加します:
+
+```c
+#define SPLIT_HAND_MATRIX_GRID D0, F1
+```
+
+最初のピンは出力ピンで、2つ目は入力ピンです。
+
+キーマトリックスに未使用の交点があるキーボードがあります。この設定は、左右の決定にこれらの未使用の交点の1つを使用します。
+
+通常、ダイオードが交点に接続されている場合、左側と判断されます。次の定義を追加すると、右側と判断されます。
+
+```c
+#define SPLIT_HAND_MATRIX_GRID_LOW_IS_RIGHT
+```
+
 #### EEPROM による左右の設定
 
 このメソッドは永続ストレージ(`EEPROM`)のフラグを設定することで、キーボードの左右を設定します。これはコントローラが最初に起動する時にチェックされ、キーボードのどちら側であるかとキーボードのレイアウトの向きを決定します。

docs/ja/feature_stenography.md

@@ -0,0 +1,136 @@
+# QMK での速記 :id=stenography-in-qmk
+
+<!---
+  original document: 0.10.33:docs/feature_stenography.md
+  git diff 0.10.33 HEAD -- docs/feature_stenography.md | cat
+-->
+
+[速記](https://en.wikipedia.org/wiki/Stenotype)は裁判所のレポート、字幕および耳が不自由な人のためのリアルタイムの文字起こしで最もよく使われる記述方法です。速記では単語はスペル、音声およびショートカット(短い)ストロークが混在する音節ごとに音節化されます。プロの速記者は、標準的なタイピングで通常見られる負担を掛けずに、はるかに少ないエラー(99.9%より高い精度)で、200-300 WPM に到達できます。
+
+[Open Steno Project](http://www.openstenoproject.org/)は、速記ストロークを単語とコマンドにリアルタイムに変換する Plover と呼ばれるオープンソースプログラムを構築しました。確立された辞書とサポートがあります。
+
+## QWERTY キーボードを使った Plover :id=plover-with-qwerty-keyboard
+
+Plover は全ての標準的な QWERTY キーボードで動作しますが、キーボードが NKRO (n-キーロールオーバー)をサポートする場合は Plover は一度に押された全てのキーが分かるためより効率的です。Plover 用のキーマップの例は `planck/keymaps/default` で見つかります。`PLOVER` レイヤーに切り替えると、数字バーをサポートするためにキーボードの位置が調整されます。
+
+QMK で Plover を使うには、NKRO を有効にし、標準レイアウト以外のレイアウトの場合はオプションでレイアウトを調整します。複数のキーを押しやすくするために、なんらかの速記フレンドリなキーキャップを購入することもできます。
+
+## 速記プロトコルを使った Plover :id=plover-with-steno-protocol
+
+Plover は幾つかの速記マシンの言語も理解します。QMK はこれらの言語の内2つの言語、TX Bolt と GeminiPR を話すことができます。レイアウトの例は `planck/keymaps/steno` で見つけることができます。
+
+QMKが steno プロトコルを使って Plover と話す場合は、Plover は入力としてキーボードを使いません。標準のキーボードと速記キーボードを行き来したり、あるいは Plover をアクティブ/非アクティブにする必要なく Plover と標準のレイヤーを行き来することができることを意味します。
+
+このモードでは、Plover はシリアルポートを介して速記マシンと通信すると想定しているため、QMK はオペレーティングシステムに対してキーボードに加えて仮想シリアルポートとして存在しています。デフォルトでは、QMK は TX Bolt プロトコルを話しますが、GeminiPR に切り替えることができます; 最後に使われたプロトコルが不揮発性メモリに格納されるため QMK は再起動時に同じプロトコルを使います。
+
+> 注意: ハードウェアの制限により、仮想シリアルポートとマウスエミュレーションの両方を同時に実行することができないかもしれません。
+
+### TX Bolt :id=tx-bolt
+
+TX Bolt は可変サイズ(1-5バイト)のパケットで非常に単純なプロトコルを介して24個のキーのステータスを通信します。
+
+### GeminiPR :id=geminipr
+
+GeminiPR は42個のキーを6バイトのパケットにエンコードします。TX Bolt は標準的な速記に必要な全てを含んでいますが、GeminiPR は英語以外の速記法のサポートを含む、より多くのオプションにも開け放たれています。
+
+## 速記のための QMK の設定 :id=configuring-qmk-for-steno
+
+最初にキーマップの Makefile で速記を有効にします。競合を避けるために、マウスキー、追加キーあるいはその他の USB エンドポイントを無効にする必要もあります。幾つかのプロセッサの内蔵の USB スタックは一定数の USB エンドポイントと仮想シリアルポートのみをサポートし、速記はそれらのうちの3つを使います。
+
+```makefile
+STENO_ENABLE = yes
+MOUSEKEY_ENABLE = no
+```
+
+キーマップで Plover 用の新しいレイヤーを作成します。`keymap_steno.h` をインクルードする必要があります。例については `planck/keymaps/steno/keymap.c` を見てください。レイヤーに切り替えるためのキーとレイヤーから抜けるためのキーを作成することを忘れないでください。その場でモードを切り替えたい場合は、キーコード `QK_STENO_BOLT` および `QK_STENO_GEMINI` を使うことができます。プロトコルのうちの1つのみを使う場合は、初期化関数の中でそれをセットアップすることができます:
+
+```c
+void matrix_init_user() {
+  steno_set_mode(STENO_MODE_GEMINI); // あるいは STENO_MODE_BOLT
+}
+```
+
+キーボードを書き込んだら、Plover を起動します。'Configure...' ボタンをクリックします。'Machine' タブの中で目的のプロトコルに対応する速記マシンを選択します。このタブの 'Configure...' ボタンをクリックし、シリアルポートを入力するか 'Scan' をクリックします。ボーレートは 9600 で問題ありません (ただし、115200まで問題無く設定することができるはずです)。それ以外はデフォルトの設定(データビット長: 8、ストップビット長: 1、パリティチェック: なし、フロー制御なし)を使います。
+
+ディスプレイタブで 'Open stroke display' をクリックします。Plover を無効にすると、キーボードのキーを押すとストローク表示ウィンドウにそれらが表示されるはずです。これを使ってキーマップが正しくセットアップされたことを確認してください。これで速記をする準備ができました！
+
+## 速記の学習 :id=learning-stenography
+
+* [Learn Plover!](https://sites.google.com/site/learnplover/)
+* [QWERTY Steno](http://qwertysteno.com/Home/)
+* [Steno Jig](https://joshuagrams.github.io/steno-jig/)
+* Plover [Learning Stenography](https://github.com/openstenoproject/plover/wiki/Learning-Stenography) wiki のより多くのリソース
+
+## コードとのインターフェイス :id=interfacing-with-the-code
+
+速記コードには3つの捕捉可能なフックがあります。これらの関数を定義した場合、処理の特定のポイントでそれらが呼び出されます; それらが true を返す場合処理が継続され、そうでなければあなたが物事を処理すると想定します。
+
+```c
+bool send_steno_chord_user(steno_mode_t mode, uint8_t chord[6]);
+```
+
+この関数はコードが送信されようとしている時に呼ばれます。モードは `STENO_MODE_BOLT` あるいは `STENO_MODE_GEMINI` のいずれかです。これはいずれかのプロトコルを介して送信される実際のコードを表します。提供されるコードを修正して送信されるものを変更することができます。通常の送信プロセスにしたい場合は true を返すのを忘れないでください。
+
+```c
+bool process_steno_user(uint16_t keycode, keyrecord_t *record) { return true; }
+```
+
+この関数はキーが押されるとキーが処理される前に呼び出されます。キーコードは `QK_STENO_BOLT`、`QK_STENO_GEMINI` あるいは `STN_*` キー値のいずれかでなければなりません。
+
+```c
+bool postprocess_steno_user(uint16_t keycode, keyrecord_t *record, steno_mode_t mode, uint8_t chord[6], int8_t pressed);
+```
+
+この関数はキーが処理された後、ただしコードを送信するかどうかを決める前に呼び出されます。`IS_PRESSED(record->event)` が false で、`pressed` が 0 または 1 の場合は、コードはまもなく送信されますが、まだ送信されてはいません。ここが速記コードあるいはキーのライブ表示などのフックを配置する場所です。
+
+
+## キーコードリファレンス :id=keycode-reference
+
+`keymap_steno.h` で定義されています。
+
+> 注意: TX Bolt はキーの完全なセットをサポートしません。QMK での TX Bolt の実装は、GeminiPR キーを最も近い TX Bolt キーにマップします。そのため1つのキーマップが両方で動作します。
+
+| GeminiPR | TX Bolt | Steno Key |
+|--------|-------|-----------|
+| `STN_N1` | `STN_NUM` | Number bar #1 |
+| `STN_N2` | `STN_NUM` | Number bar #2 |
+| `STN_N3` | `STN_NUM` | Number bar #3 |
+| `STN_N4` | `STN_NUM` | Number bar #4 |
+| `STN_N5` | `STN_NUM` | Number bar #5 |
+| `STN_N6` | `STN_NUM` | Number bar #6 |
+| `STN_N7` | `STN_NUM` | Number bar #7 |
+| `STN_N8` | `STN_NUM` | Number bar #8 |
+| `STN_N9` | `STN_NUM` | Number bar #9 |
+| `STN_NA` | `STN_NUM` | Number bar #A |
+| `STN_NB` | `STN_NUM` | Number bar #B |
+| `STN_NC` | `STN_NUM` | Number bar #C |
+| `STN_S1` | `STN_SL` | `S-` upper |
+| `STN_S2` | `STN_SL` | `S-` lower |
+| `STN_TL` | `STN_TL` | `T-` |
+| `STN_KL` | `STN_KL` | `K-` |
+| `STN_PL` | `STN_PL` | `P-` |
+| `STN_WL` | `STN_WL` | `W-` |
+| `STN_HL` | `STN_HL` | `H-` |
+| `STN_RL` | `STN_RL` | `R-` |
+| `STN_A` | `STN_A` | `A` vowel |
+| `STN_O` | `STN_O` | `O` vowel |
+| `STN_ST1` | `STN_STR` | `*` upper-left |
+| `STN_ST2` | `STN_STR` | `*` lower-left |
+| `STN_ST3` | `STN_STR` | `*` upper-right |
+| `STN_ST4` | `STN_STR` | `*` lower-right |
+| `STN_E` | `STN_E` | `E` vowel |
+| `STN_U` | `STN_U` | `U` vowel |
+| `STN_FR` | `STN_FR` | `-F` |
+| `STN_PR` | `STN_PR` | `-P` |
+| `STN_RR` | `STN_RR` | `-R` |
+| `STN_BR` | `STN_BR` | `-B` |
+| `STN_LR` | `STN_LR` | `-L` |
+| `STN_GR` | `STN_GR` | `-G` |
+| `STN_TR` | `STN_TR` | `-T` |
+| `STN_SR` | `STN_SR` | `-S` |
+| `STN_DR` | `STN_DR` | `-D` |
+| `STN_ZR` | `STN_ZR` | `-Z` |
+| `STN_FN` | (GeminiPR のみ) |
+| `STN_RES1` | (GeminiPR のみ) |
+| `STN_RES2` | (GeminiPR のみ) |
+| `STN_PWR` | (GeminiPR のみ) |

docs/ja/feature_tap_dance.md

@@ -1,39 +1,28 @@
 # タップダンス: 1つのキーが3つ、5つまたは100の異なる動作をします
 
 <!---
-  original document: 0.9.0:docs/feature_tap_dance.md
-  git diff 0.9.0 HEAD -- docs/feature_tap_dance.md | cat
---> 
+  original document: 0.10.33:docs/feature_tap_dance.md
+  git diff 0.10.33 HEAD -- docs/feature_tap_dance.md | cat
+-->
 
-## イントロダクション
+## イントロダクション :id=introduction
 
 セミコロンキーを1回叩くと、セミコロンが送信されます。2回素早く叩くと、コロンが送信されます。3回叩くと、あなたのキーボードのLEDが激しく踊るように明滅します。これは、タップダンスでできることの一例です。それは、コミュニティが提案したとても素敵なファームウェアの機能の1つで、[algernon](https://github.com/algernon) がプルリクエスト [#451](https://github.com/qmk/qmk_firmware/pull/451) で考えて作ったものです。algernon が述べる機能は次の通りです:
 
 この機能を使うと、特定のキーが、タップした回数に基づいて異なる振る舞いをします。そして、割り込みがあった時は、割り込み前に上手く処理されます。
 
-## `ACTION_FUNCTION_TAP` との比較について
-
-`ACTION_FUNCTION_TAP` はタップダンスに似た機能を提供しますが、注目すべきいくつかの重要な違いがあります。違いを確認するため、いくつかの設定を調べてみましょう。1つのキーを1回タップすると `Space` キーが送信され、2回タップすると `Enter` キーが送信されるよう設定します。
-
-`ACTION_FUNCTION_TAP` では、これを設定するのはかなり大変で、キーの順番が割り込まれた時に割り込んだキーが最初に送られるという問題に直面します。例えば、`SPC a` は、もし `SPC` と `a` が `TAPPING_TERM` で設定した時間内に両方とも入力された場合、結果として `a SPC` が送信されます。タップダンス機能を使う場合、正しく `SPC a` が送信されます（`TAPPING_TERM` で設定した時間内に `SPC` と `a` を入力した場合であっても）。
-
-割り込みを正しくハンドリングして目的を達成するため、タップダンスの実装ではシステムの2つの部分をフックします: `process_record_quantum()` とマトリックススキャンです。この2つの部分については以下で説明しますが、今注意すべき点は、マトリックススキャンでは、キーが押されていない時でもタップのシーケンスをタイムアウトにできる必要があるということです。そうすれば、`TAPPING_TERM` の時間が経過した後、`SPC` だけがタイムアウトになって登録されます。
-
-## タップダンスの使い方
-
-一般論は十分です。タップダンスの実際の使い方を見てみましょう！
-
-最初に、あなたの `rules.mk` ファイルで `TAP_DANCE_ENABLE=yes` と設定する必要があります。なぜならば、デフォルトでは無効になっているからです。これでファームウェアのサイズが1キロバイトほど増加します。
+## タップダンスの使い方 :id=how-to-use
+最初に、あなたの `rules.mk` ファイルで `TAP_DANCE_ENABLE = yes` と設定する必要があります。なぜならば、デフォルトでは無効になっているからです。これでファームウェアのサイズが1キロバイトほど増加します。
 
 オプションで、あなたの `config.h` ファイルに次のような設定を追加して、`TAPPING_TERM` の時間をカスタマイズしたほうが良いです。
 
-```
+```c
 #define TAPPING_TERM 175
 ```
 
 `TAPPING_TERM` の時間は、あなたのタップダンスのキーのタップとタップの間の時間として許可された最大の時間で、ミリ秒単位で計測されます。例えば、もし、あなたがこの上にある `#define` ステートメントを使い、1回タップすると `Space` が送信され、2回タップすると `Enter` が送信されるタップダンスキーをセットアップした場合、175ミリ秒以内に2回キーをタップすれば `ENT` だけが送信されるでしょう。もし、1回タップしてから175ミリ秒以上待ってからもう一度タップすると、`SPC SPC` が送信されます。
 
-次に、いくつかのタップダンスのキーを定義するためには、`TD()` マクロ — `F()` マクロに似ています — を使うのが最も簡単です。これは数字を受け取り、この数字は後で `tap_dance-actions` 配列のインデックスとして使われます。
+次に、いくつかのタップダンスのキーを定義するためには、`TD()` マクロを使うのが最も簡単です。これは数字を受け取り、この数字は後で `tap_dance-actions` 配列のインデックスとして使われます。
 
 その後、`tap_dance_actions` 配列を使って、タップダンスキーを押した時のアクションを定義します。現在は、5つの可能なオプションがあります:
 
@@ -43,7 +32,9 @@
 * `ACTION_TAP_DANCE_LAYER_TOGGLE(kc, layer)`: 1回タップすると `kc` キーコードが送信され、2回タップすると `layer` の状態をトグルします(これは `TG` レイヤーキーコードのように機能します)。
 * `ACTION_TAP_DANCE_FN(fn)`: ユーザーキーマップに定義した指定の関数が呼び出されます。タップダンス実行の回数分タップすると、最後の時点で呼び出されます。
 * `ACTION_TAP_DANCE_FN_ADVANCED(on_each_tap_fn, on_dance_finished_fn, on_dance_reset_fn)`: タップする度にユーザーキーマップに定義した最初の関数が呼び出されます。タップダンスの実行が終わった時点で2番目の関数が呼び出され、タップダンスの実行をリセットするときに最後の関数が呼び出されます。
-* `ACTION_TAP_DANCE_FN_ADVANCED_TIME(on_each_tap_fn, on_dance_finished_fn, on_dance_reset_fn, tap_specific_tapping_term)`: これは `ACTION_TAP_DANCE_FN_ADVANCED` と同じように機能します。しかし、`TAPPING_TERM` で事前に定義した時間に代えて、カスタマイズしたタップ時間を使えます。
+* ~~`ACTION_TAP_DANCE_FN_ADVANCED_TIME(on_each_tap_fn, on_dance_finished_fn, on_dance_reset_fn, tap_specific_tapping_term)`~~: これは `ACTION_TAP_DANCE_FN_ADVANCED` 関数と同じように機能します。しかし、`TAPPING_TERM` で事前に定義した時間の代わりに、カスタマイズしたタップ時間を使います。
+    * [ここ](ja/custom_quantum_functions.md#Custom_Tapping_Term)で概説するように、これはキーごとのタッピング時間機能を優先して非推奨になりました。この特定のタップダンス機能を使う代わりに、使いたい特定の `TD()` マクロ(`TD(TD_ESC_CAPS)` のような)を確認する必要があります。
+
 
 最初のオプションで、1つのキーに2つの役割を持たせる大抵のケースには十分です。例えば、`ACTION_TAP_DANCE_DOUBLE(KC_SPC, KC_ENT)` は、1回タップすると `Space` を送信し、2回タップすると `Enter` を送信します。
 
@@ -56,7 +47,7 @@
 最後に、5番目のオプションは、もし、タップダンスキーをコードに追加した後、非タップダンスキーが奇妙な振る舞いを始めた時に特に役に立ちます。ありうる問題は、あなたがタップダンスキーを使いやすくするために `TAPPING_TERM` の時間を変更した結果、その他のキーが割り込みを処理する方法が変わってしまったというものです。
 
 
-## 実装の詳細
+## 実装の詳細 :id=implementation
 
 さて、説明の大部分はここまでです！ 以下に挙げているいくつかの例に取り組むことができるようになり、あなた自身のタップダンスの機能を開発できるようになります。しかし、もし、あなたが裏側で起きていることをより深く理解したいのであれば、続けてそれが全てどのように機能するかの説明を読みましょう！
 
@@ -66,15 +57,15 @@
 異なる場合、まず、古いタップダンスを処理し、続いて新しいタップダンスを登録します。
 同じ場合、カウンタの値を増やし、タイマーをリセットします。
 
-このことは、あなたは再びキーをタップするまでの時間として `TAPPING_TERM` の時間を持っていることを意味します。そのため、あなたは1つの `TAPPING_TERM` の時間内に全てのタップを行う必要はありません。これにより、キーの反応への影響を最小限に抑えながら、より長いタップ回数を可能にします。 
+このことは、あなたは再びキーをタップするまでの時間として `TAPPING_TERM` の時間を持っていることを意味します。そのため、あなたは1つの `TAPPING_TERM` の時間内に全てのタップを行う必要はありません。これにより、キーの反応への影響を最小限に抑えながら、より長いタップ回数を可能にします。
 
 次は `matrix_scan_tap_dance()` です。この関数はタップダンスキーのタイムアウトを制御します。
 
 柔軟性のために、タップダンスは、キーコードの組み合わせにも、ユーザー関数にもなることができます。後者は、より高度なタップ回数の制御や、LED を点滅させたり、バックライトをいじったり、等々の制御を可能にします。これは、1つの共用体と、いくつかの賢いマクロによって成し遂げられています。
 
-# 実装例
+## 実装例 :id=examples
 
-## シンプルな実装例
+### シンプルな実装例 :id=simple-example
 
 ここに1つの定義のための簡単な例があります。
 
@@ -85,21 +76,24 @@
 ```c
 // タップダンスの宣言
 enum {
-  TD_ESC_CAPS = 0
+    TD_ESC_CAPS,
 };
 
 // タップダンスの定義
 qk_tap_dance_action_t tap_dance_actions[] = {
-  // 1回タップすると Escape キー、2回タップすると Caps Lock。
-  [TD_ESC_CAPS]  = ACTION_TAP_DANCE_DOUBLE(KC_ESC, KC_CAPS)
-// ほかの宣言もカンマで区切ってここに記述します
+    // 1回タップすると Escape キー、2回タップすると Caps Lock。
+    [TD_ESC_CAPS]  = ACTION_TAP_DANCE_DOUBLE(KC_ESC, KC_CAPS),
 };
 
-// レイヤー定義で、キーコードの代わりにタップダンスキーを追加します
-TD(TD_ESC_CAPS)
+// キーコードの代わりにタップダンスキーを追加します
+const uint16_t PROGMEM keymaps[][MATRIX_ROWS][MATRIX_COLS] = {
+    // ...
+    TD(TD_ESC_CAPS)
+    // ...
+};
 ```
 
-## 複雑な実装例
+### 複雑な実装例 :id=complex-examples
 
 このセクションでは、いくつかの複雑なタップダンスの例を詳しく説明します。
 例で使われている全ての列挙型はこのように宣言します。
@@ -107,107 +101,104 @@ TD(TD_ESC_CAPS)
 ```c
 // 全ての例のための列挙型定義
 enum {
- CT_SE = 0,
- CT_CLN,
- CT_EGG,
- CT_FLSH,
- X_TAP_DANCE
+    CT_SE,
+    CT_CLN,
+    CT_EGG,
+    CT_FLSH,
+    X_TAP_DANCE
 };
 ```
-### 例1: 1回タップすると `:` を送信し、2回タップすると `;` を送信する
+#### 例1: 1回タップすると `:` を送信し、2回タップすると `;` を送信する :id=example-1
 
 ```c
-void dance_cln_finished (qk_tap_dance_state_t *state, void *user_data) {
-  if (state->count == 1) {
-    register_code (KC_RSFT);
-    register_code (KC_SCLN);
-  } else {
-    register_code (KC_SCLN);
-  }
+void dance_cln_finished(qk_tap_dance_state_t *state, void *user_data) {
+    if (state->count == 1) {
+        register_code16(KC_COLN);
+    } else {
+        register_code(KC_SCLN);
+    }
 }
 
-void dance_cln_reset (qk_tap_dance_state_t *state, void *user_data) {
-  if (state->count == 1) {
-    unregister_code (KC_RSFT);
-    unregister_code (KC_SCLN);
-  } else {
-    unregister_code (KC_SCLN);
-  }
+void dance_cln_reset(qk_tap_dance_state_t *state, void *user_data) {
+    if (state->count == 1) {
+        unregister_code16(KC_COLN);
+    } else {
+        unregister_code(KC_SCLN);
+    }
 }
 
 // 全てのタップダンス関数はここに定義します。ここでは1つだけ示します。
 qk_tap_dance_action_t tap_dance_actions[] = {
- [CT_CLN] = ACTION_TAP_DANCE_FN_ADVANCED (NULL, dance_cln_finished, dance_cln_reset)
+    [CT_CLN] = ACTION_TAP_DANCE_FN_ADVANCED(NULL, dance_cln_finished, dance_cln_reset),
 };
 ```
 
-### 例2: 100回タップした後に "Safety Dance!" を送信します
+#### 例2: 100回タップした後に "Safety Dance!" を送信します :id=example-2
 
 ```c
-void dance_egg (qk_tap_dance_state_t *state, void *user_data) {
-  if (state->count >= 100) {
-    SEND_STRING ("Safety dance!");
-    reset_tap_dance (state);
-  }
+void dance_egg(qk_tap_dance_state_t *state, void *user_data) {
+    if (state->count >= 100) {
+        SEND_STRING("Safety dance!");
+        reset_tap_dance(state);
+    }
 }
 
 qk_tap_dance_action_t tap_dance_actions[] = {
- [CT_EGG] = ACTION_TAP_DANCE_FN (dance_egg)
+    [CT_EGG] = ACTION_TAP_DANCE_FN(dance_egg),
 };
 ```
 
-### 例3: 1つずつ LED を点灯させてから消灯する
+#### 例3: 1つずつ LED を点灯させてから消灯する :id=example-3
 
 ```c
 // タップする毎に、LED を右から左に点灯します。
 // 4回目のタップで、右から左に消灯します。
 void dance_flsh_each(qk_tap_dance_state_t *state, void *user_data) {
-  switch (state->count) {
-  case 1:
-    ergodox_right_led_3_on();
-    break;
-  case 2:
-    ergodox_right_led_2_on();
-    break;
-  case 3:
-    ergodox_right_led_1_on();
-    break;
-  case 4:
-    ergodox_right_led_3_off();
-    _delay_ms(50);
-    ergodox_right_led_2_off();
-    _delay_ms(50);
-    ergodox_right_led_1_off();
-  }
+    switch (state->count) {
+        case 1:
+            ergodox_right_led_3_on();
+            break;
+        case 2:
+            ergodox_right_led_2_on();
+            break;
+        case 3:
+            ergodox_right_led_1_on();
+            break;
+        case 4:
+            ergodox_right_led_3_off();
+            wait_ms(50);
+            ergodox_right_led_2_off();
+            wait_ms(50);
+            ergodox_right_led_1_off();
+    }
 }
 
 // 4回目のタップで、キーボードをフラッシュ状態にセットします。
 void dance_flsh_finished(qk_tap_dance_state_t *state, void *user_data) {
-  if (state->count >= 4) {
-    reset_keyboard();
-    reset_tap_dance(state);
-  }
+    if (state->count >= 4) {
+        reset_keyboard();
+    }
 }
 
 // もしフラッシュ状態にならない場合、LED を左から右に消灯します。
 void dance_flsh_reset(qk_tap_dance_state_t *state, void *user_data) {
-  ergodox_right_led_1_off();
-  _delay_ms(50);
-  ergodox_right_led_2_off();
-  _delay_ms(50);
-  ergodox_right_led_3_off();
+    ergodox_right_led_1_off();
+    wait_ms(50);
+    ergodox_right_led_2_off();
+    wait_ms(50);
+    ergodox_right_led_3_off();
 }
 
 // 全てのタップダンス関数を一緒に表示しています。この例3は "CT_FLASH" です。
 qk_tap_dance_action_t tap_dance_actions[] = {
-  [CT_SE]  = ACTION_TAP_DANCE_DOUBLE (KC_SPC, KC_ENT)
- ,[CT_CLN] = ACTION_TAP_DANCE_FN_ADVANCED (NULL, dance_cln_finished, dance_cln_reset)
- ,[CT_EGG] = ACTION_TAP_DANCE_FN (dance_egg)
- ,[CT_FLSH] = ACTION_TAP_DANCE_FN_ADVANCED (dance_flsh_each, dance_flsh_finished, dance_flsh_reset)
+    [CT_SE] = ACTION_TAP_DANCE_DOUBLE(KC_SPC, KC_ENT),
+    [CT_CLN] = ACTION_TAP_DANCE_FN_ADVANCED(NULL, dance_cln_finished, dance_cln_reset),
+    [CT_EGG] = ACTION_TAP_DANCE_FN(dance_egg),
+    [CT_FLSH] = ACTION_TAP_DANCE_FN_ADVANCED(dance_flsh_each, dance_flsh_finished, dance_flsh_reset)
 };
 ```
 
-### 例4: クアッドファンクションのタップダンス
+#### 例4: クアッドファンクションのタップダンス :id=example-4
 
 [DanielGGordon](https://github.com/danielggordon) によるもの
 
@@ -219,40 +210,37 @@ qk_tap_dance_action_t tap_dance_actions[] = {
 *  2回タップ = `Escape` を送信
 *  2回タップして押し続ける = `Alt` を送信
 
-## 準備
-
 'クアッドファンクションのタップダンス' を利用できるようにするには、いくつかのものが必要になります。
 
 `keymap.c` ファイルの先頭、つまりキーマップの前に、以下のコードを追加します。
 
 ```c
 typedef struct {
-  bool is_press_action;
-  int state;
+    bool is_press_action;
+    uint8_t state;
 } tap;
 
 enum {
-  SINGLE_TAP = 1,
-  SINGLE_HOLD = 2,
-  DOUBLE_TAP = 3,
-  DOUBLE_HOLD = 4,
-  DOUBLE_SINGLE_TAP = 5, //シングルタップを2回送信
-  TRIPLE_TAP = 6,
-  TRIPLE_HOLD = 7
+    SINGLE_TAP = 1,
+    SINGLE_HOLD,
+    DOUBLE_TAP,
+    DOUBLE_HOLD,
+    DOUBLE_SINGLE_TAP, // シングルタップを2回送信
+    TRIPLE_TAP,
+    TRIPLE_HOLD
 };
 
 // タップダンスの列挙型
 enum {
-  X_CTL = 0,
-  SOME_OTHER_DANCE
+    X_CTL,
+    SOME_OTHER_DANCE
 };
 
-int cur_dance (qk_tap_dance_state_t *state);
-
-//xタップダンスのための関数。キーマップで利用できるようにするため、ここに置きます。
-void x_finished (qk_tap_dance_state_t *state, void *user_data);
-void x_reset (qk_tap_dance_state_t *state, void *user_data);
+uint8_t cur_dance(qk_tap_dance_state_t *state);
 
+// xタップダンスのための関数。キーマップで利用できるようにするため、ここに置きます。
+void x_finished(qk_tap_dance_state_t *state, void *user_data);
+void x_reset(qk_tap_dance_state_t *state, void *user_data);
 ```
 
 次に、`keymap.c` ファイルの末尾に、次のコードを追加する必要があります。
@@ -288,68 +276,64 @@ void x_reset (qk_tap_dance_state_t *state, void *user_data);
  * 3つ目の点については、'DOUBLE_SINGLE_TAP' が存在しますが、これは完全にはテストされていません
  *
  */
-int cur_dance (qk_tap_dance_state_t *state) {
-  if (state->count == 1) {
-    if (state->interrupted || !state->pressed)  return SINGLE_TAP;
-    //キーは割り込まれていませんが、まだ押し続けられています。'HOLD' を送信することを意味します。
-    else return SINGLE_HOLD;
-  }
-  else if (state->count == 2) {
-    /*
-     * DOUBLE_SINGLE_TAP は "pepper" と入力することと、'pp' と入力したときに実際に
-     * ダブルタップしたい場合とを区別するためのものです。
-     * この戻り値の推奨されるユースケースは、'ダブルタップ' 動作やマクロではなく、
-     * そのキーの2つのキー入力を送信したい場合です。
-    */
-    if (state->interrupted) return DOUBLE_SINGLE_TAP;
-    else if (state->pressed) return DOUBLE_HOLD;
-    else return DOUBLE_TAP;
-  }
-  //誰も同じ文字を3回入力しようとしていないと仮定します(少なくとも高速には)。
-  //タップダンスキーが 'KC_W' で、"www." と高速に入力したい場合、ここに例外を追加して
-  //'TRIPLE_SINGLE_TAP' を返し、'DOUBLE_SINGLE_TAP' のようにその列挙型を定義する
-  //必要があります。
-  if (state->count == 3) {
-    if (state->interrupted || !state->pressed)  return TRIPLE_TAP;
-    else return TRIPLE_HOLD;
-  }
-  else return 8; //マジックナンバー。いつかこのメソッドはより多くの押下に対して機能するよう拡張されるでしょう
+uint8_t cur_dance(qk_tap_dance_state_t *state) {
+    if (state->count == 1) {
+        if (state->interrupted || !state->pressed) return SINGLE_TAP;
+        // キーは割り込まれていませんが、まだ押し続けられています。'HOLD' を送信することを意味します。
+        else return SINGLE_HOLD;
+    } else if (state->count == 2) {
+        // DOUBLE_SINGLE_TAP は "pepper" と入力することと、'pp' と入力したときに実際に
+        // ダブルタップしたい場合とを区別するためのものです。
+        // この戻り値の推奨されるユースケースは、'ダブルタップ' 動作やマクロではなく、
+        // そのキーの2つのキー入力を送信したい場合です。
+        if (state->interrupted) return DOUBLE_SINGLE_TAP;
+        else if (state->pressed) return DOUBLE_HOLD;
+        else return DOUBLE_TAP;
+    }
+
+    // 誰も同じ文字を3回入力しようとしていないと仮定します(少なくとも高速には)。
+    // タップダンスキーが 'KC_W' で、"www." と高速に入力したい場合、ここに例外を追加して
+    // 'TRIPLE_SINGLE_TAP' を返し、'DOUBLE_SINGLE_TAP' のようにその列挙型を定義する必要があります。
+    if (state->count == 3) {
+        if (state->interrupted || !state->pressed) return TRIPLE_TAP;
+        else return TRIPLE_HOLD;
+    } else return 8; // マジックナンバー。いつかこのメソッドはより多くの押下に対して機能するよう拡張されるでしょう
 }
 
-//'x' タップダンスの 'tap' のインスタンスをインスタンス化します
+//'x' タップダンスの 'tap' のインスタンスを生成します。
 static tap xtap_state = {
-  .is_press_action = true,
-  .state = 0
+    .is_press_action = true,
+    .state = 0
 };
 
-void x_finished (qk_tap_dance_state_t *state, void *user_data) {
-  xtap_state.state = cur_dance(state);
-  switch (xtap_state.state) {
-    case SINGLE_TAP: register_code(KC_X); break;
-    case SINGLE_HOLD: register_code(KC_LCTRL); break;
-    case DOUBLE_TAP: register_code(KC_ESC); break;
-    case DOUBLE_HOLD: register_code(KC_LALT); break;
-    case DOUBLE_SINGLE_TAP: register_code(KC_X); unregister_code(KC_X); register_code(KC_X);
-    //最後の case は高速入力用です。キーが `f` であると仮定します:
-    //例えば、`buffer` という単語を入力するとき、`Esc` ではなく `ff` を送信するようにします。
-    //高速入力時に `ff` と入力するには、次の文字は `TAPPING_TERM` 以内に入力する必要があります。
-    //`TAPPING_TERM` はデフォルトでは 200ms です。
-  }
+void x_finished(qk_tap_dance_state_t *state, void *user_data) {
+    xtap_state.state = cur_dance(state);
+    switch (xtap_state.state) {
+        case SINGLE_TAP: register_code(KC_X); break;
+        case SINGLE_HOLD: register_code(KC_LCTRL); break;
+        case DOUBLE_TAP: register_code(KC_ESC); break;
+        case DOUBLE_HOLD: register_code(KC_LALT); break;
+        // 最後の case は高速入力用です。キーが `f` であると仮定します:
+        // 例えば、`buffer` という単語を入力するとき、`Esc` ではなく `ff` を送信するようにします。
+        // 高速入力時に `ff` と入力するには、次の文字は `TAPPING_TERM` 以内に入力する必要があります。
+        // `TAPPING_TERM` はデフォルトでは 200ms です。
+        case DOUBLE_SINGLE_TAP: tap_code(KC_X); register_code(KC_X);
+    }
 }
 
-void x_reset (qk_tap_dance_state_t *state, void *user_data) {
-  switch (xtap_state.state) {
-    case SINGLE_TAP: unregister_code(KC_X); break;
-    case SINGLE_HOLD: unregister_code(KC_LCTRL); break;
-    case DOUBLE_TAP: unregister_code(KC_ESC); break;
-    case DOUBLE_HOLD: unregister_code(KC_LALT);
-    case DOUBLE_SINGLE_TAP: unregister_code(KC_X);
-  }
-  xtap_state.state = 0;
+void x_reset(qk_tap_dance_state_t *state, void *user_data) {
+    switch (xtap_state.state) {
+        case SINGLE_TAP: unregister_code(KC_X); break;
+        case SINGLE_HOLD: unregister_code(KC_LCTRL); break;
+        case DOUBLE_TAP: unregister_code(KC_ESC); break;
+        case DOUBLE_HOLD: unregister_code(KC_LALT);
+        case DOUBLE_SINGLE_TAP: unregister_code(KC_X);
+    }
+    xtap_state.state = 0;
 }
 
 qk_tap_dance_action_t tap_dance_actions[] = {
-  [X_CTL]     = ACTION_TAP_DANCE_FN_ADVANCED(NULL,x_finished, x_reset)
+    [X_CTL] = ACTION_TAP_DANCE_FN_ADVANCED(NULL, x_finished, x_reset)
 };
 ```
 
@@ -359,90 +343,91 @@ qk_tap_dance_action_t tap_dance_actions[] = {
 
 > この設定の "hold" は、タップダンスのタイムアウト（`ACTION_TAP_DANCE_FN_ADVANCED_TIME` 参照）の **後** に起こります。即座に "hold" を得るためには、条件から `state->interrupted` の確認を除きます。結果として、複数回のタップのための時間をより多く持つことで快適な長いタップの期限を使うことができ、そして、"hold" のために長く待たないようにすることができます(2倍の `TAPPING TERM` で開始してみてください)。
 
-### 例5: タップダンスを高度なモッドタップとレイヤータップキーに使う :id=example-5-using-tap-dance-for-advanced-mod-tap-and-layer-tap-keys
+#### 例5: タップダンスを高度なモッドタップとレイヤータップキーに使う :id=example-5
 
 タップダンスは、タップされたコードが基本的なキーコード以外の場合に、 `MT()` と `LT()` マクロをエミュレートするのに利用できます。これは、通常 `Shift` を必要とする '(' や '{' のようなキーや、`Control + X` のように他の修飾されたキーコードをタップされたキーコードとして送信することに役立ちます。
 
 あなたのレイヤーとカスタムキーコードの下に、以下のコードを追加します。
 
 ```c
-//タップダンスのキーコード
-enum td_keycodes { 
-  ALT_LP //例: 押していると `LALT`、タップすると `(`。それぞれのタップダンスの追加のキーコードを追加します
+// タップダンスのキーコード
+enum td_keycodes {
+    ALT_LP // 例: 押していると `LALT`、タップすると `(`。それぞれのタップダンスの追加のキーコードを追加します
 };
 
-//必要な数のタップダンス状態を含むタイプを定義します
+// 必要な数のタップダンス状態を含むタイプを定義します
 typedef enum {
-  SINGLE_TAP,
-  SINGLE_HOLD,
-  DOUBLE_SINGLE_TAP
+    SINGLE_TAP,
+    SINGLE_HOLD,
+    DOUBLE_SINGLE_TAP
 } td_state_t;
 
-//タップダンスの状態の型のグローバルインスタンスを作ります
+// タップダンスの状態の型のグローバルインスタンスを作ります
 static td_state_t td_state;
 
-//タップダンス関数を宣言します:
+// タップダンス関数を宣言します:
 
-//現在のタップダンスの状態を特定するための関数
-int cur_dance (qk_tap_dance_state_t *state);
+// 現在のタップダンスの状態を特定するための関数
+uint8_t cur_dance(qk_tap_dance_state_t *state);
 
-//それぞれのタップダンスキーコードに適用する `finished` と `reset` 関数
-void altlp_finished (qk_tap_dance_state_t *state, void *user_data);
-void altlp_reset (qk_tap_dance_state_t *state, void *user_data);
+// それぞれのタップダンスキーコードに適用する `finished` と `reset` 関数
+void altlp_finished(qk_tap_dance_state_t *state, void *user_data);
+void altlp_reset(qk_tap_dance_state_t *state, void *user_data);
 ```
 
 キーレイアウト（`LAYOUT`）の下に、タップダンスの関数を定義します。
 
 ```c
 // 返却するタップダンス状態を特定します
-int cur_dance (qk_tap_dance_state_t *state) {
-  if (state->count == 1) {
-    if (state->interrupted || !state->pressed) { return SINGLE_TAP; }
-    else { return SINGLE_HOLD; }
-  }
-  if (state->count == 2) { return DOUBLE_SINGLE_TAP; }
-  else { return 3; } // 上記で返却する最大の状態の値より大きい任意の数
+uint8_t cur_dance(qk_tap_dance_state_t *state) {
+    if (state->count == 1) {
+        if (state->interrupted || !state->pressed) return SINGLE_TAP;
+        else return SINGLE_HOLD;
+    }
+
+    if (state->count == 2) return DOUBLE_SINGLE_TAP;
+    else return 3; // 上記で返却する最大の状態の値より大きい任意の数
 }
- 
+
 // 定義する各タップダンスキーコードのとりうる状態を制御します:
 
-void altlp_finished (qk_tap_dance_state_t *state, void *user_data) {
-  td_state = cur_dance(state);
-  switch (td_state) {
-    case SINGLE_TAP:
-      register_code16(KC_LPRN);
-      break;
-    case SINGLE_HOLD:
-      register_mods(MOD_BIT(KC_LALT)); // レイヤータップキーの場合、ここでは `layer_on(_MY_LAYER)` を使います
-      break;
-    case DOUBLE_SINGLE_TAP: // タップ時間内に2つの括弧 `((` の入れ子を可能にします
-      tap_code16(KC_LPRN);
-      register_code16(KC_LPRN);
-  }
+void altlp_finished(qk_tap_dance_state_t *state, void *user_data) {
+    td_state = cur_dance(state);
+    switch (td_state) {
+        case SINGLE_TAP:
+            register_code16(KC_LPRN);
+            break;
+        case SINGLE_HOLD:
+            register_mods(MOD_BIT(KC_LALT)); // レイヤータップキーの場合、ここでは `layer_on(_MY_LAYER)` を使います
+            break;
+        case DOUBLE_SINGLE_TAP: // タップ時間内に2つの括弧 `((` の入れ子を可能にします
+            tap_code16(KC_LPRN);
+            register_code16(KC_LPRN);
+    }
 }
 
-void altlp_reset (qk_tap_dance_state_t *state, void *user_data) {
-  switch (td_state) {
-    case SINGLE_TAP:
-      unregister_code16(KC_LPRN);
-      break;
-    case SINGLE_HOLD:
-      unregister_mods(MOD_BIT(KC_LALT)); // レイヤータップキーの場合、ここでは `layer_off(_MY_LAYER)` を使います
-      break;
-    case DOUBLE_SINGLE_TAP:
-      unregister_code16(KC_LPRN);
-  }
+void altlp_reset(qk_tap_dance_state_t *state, void *user_data) {
+    switch (td_state) {
+        case SINGLE_TAP:
+            unregister_code16(KC_LPRN);
+            break;
+        case SINGLE_HOLD:
+            unregister_mods(MOD_BIT(KC_LALT)); // レイヤータップキーの場合、ここでは `layer_off(_MY_LAYER)` を使います
+            break;
+        case DOUBLE_SINGLE_TAP:
+            unregister_code16(KC_LPRN);
+    }
 }
 
 // 各タップダンスキーコードの `ACTION_TAP_DANCE_FN_ADVANCED()` を定義し、`finished` と `reset` 関数を渡します
 qk_tap_dance_action_t tap_dance_actions[] = {
-  [ALT_LP] = ACTION_TAP_DANCE_FN_ADVANCED(NULL, altlp_finished, altlp_reset)
+    [ALT_LP] = ACTION_TAP_DANCE_FN_ADVANCED(NULL, altlp_finished, altlp_reset)
 };
 ```
 
 それぞれのタップダンスキーコードをキーマップに含めるときは、`TD()` マクロでキーコードをラップします。例: `TD(ALT_LP)`
 
-### 例6: タップダンスを一時的なレイヤー切り替えとレイヤートグルキーに使う
+#### 例6: タップダンスを一時的なレイヤー切り替えとレイヤートグルキーに使う :id=example-6
 
 タップダンスは、MO(layer) と TG(layer) 機能を模倣することにも使用できます。この例では、1回タップすると `KC_QUOT` 、1回押してそのまま押し続けたら `MO(_MY_LAYER)` 、2回タップしたときは `TG(_MY_LAYER)` として機能するキーを設定します。
 
@@ -450,98 +435,93 @@ qk_tap_dance_action_t tap_dance_actions[] = {
 
 ```c
 typedef struct {
-  bool is_press_action;
-  int state;
+    bool is_press_action;
+    uint8_t state;
 } tap;
 
-//必要な数のタップダンス状態のタイプを定義します
+// 必要な数のタップダンス状態のタイプを定義します
 enum {
-  SINGLE_TAP = 1,
-  SINGLE_HOLD = 2,
-  DOUBLE_TAP = 3
+    SINGLE_TAP = 1,
+    SINGLE_HOLD,
+    DOUBLE_TAP
 };
 
 enum {
-  QUOT_LAYR = 0  //カスタムタップダンスキー。他のタップダンスキーはこの列挙型に追加します
+    QUOT_LAYR, // カスタムタップダンスキー。他のタップダンスキーはこの列挙型に追加します
 };
 
-//タップダンスキーで使われる関数を宣言します
+// タップダンスキーで使われる関数を宣言します
 
-//全てのタップダンスに関連する関数
-int cur_dance (qk_tap_dance_state_t *state);
+// 全てのタップダンスに関連する関数
+uint8_t cur_dance(qk_tap_dance_state_t *state);
 
-//個別のタップダンスに関連する関数
-void ql_finished (qk_tap_dance_state_t *state, void *user_data);
-void ql_reset (qk_tap_dance_state_t *state, void *user_data);
+// 個別のタップダンスに関連する関数
+void ql_finished(qk_tap_dance_state_t *state, void *user_data);
+void ql_reset(qk_tap_dance_state_t *state, void *user_data);
 ```
 
 あなたの `keymap.c` ファイルの最後の方に以下のコードを追加します。
 
 ```c
-//現在のタップダンスの状態を決定します
-int cur_dance (qk_tap_dance_state_t *state) {
-  if (state->count == 1) {
-    if (!state->pressed) {
-      return SINGLE_TAP;
-    } else {
-      return SINGLE_HOLD;
-    }
-  } else if (state->count == 2) {
-    return DOUBLE_TAP;
-  }
-  else return 8;
+// 現在のタップダンスの状態を決定します
+uint8_t cur_dance(qk_tap_dance_state_t *state) {
+    if (state->count == 1) {
+        if (!state->pressed) return SINGLE_TAP;
+        else return SINGLE_HOLD;
+    } else if (state->count == 2) return DOUBLE_TAP;
+    else return 8;
 }
 
-//この例のタップダンスキーに関連付けられた "tap" 構造体を初期化します
+// この例のタップダンスキーに関連付けられた "tap" 構造体を初期化します
 static tap ql_tap_state = {
-  .is_press_action = true,
-  .state = 0
+    .is_press_action = true,
+    .state = 0
 };
 
-//タップダンスキーの動作をコントロールする関数
-void ql_finished (qk_tap_dance_state_t *state, void *user_data) {
-  ql_tap_state.state = cur_dance(state);
-  switch (ql_tap_state.state) {
-    case SINGLE_TAP: 
-      tap_code(KC_QUOT); 
-      break;
-    case SINGLE_HOLD: 
-      layer_on(_MY_LAYER); 
-      break;
-    case DOUBLE_TAP: 
-      //レイヤーが既にセットされているか確認します
-      if (layer_state_is(_MY_LAYER)) {
-        //レイヤーが既にセットされていたら、オフにします。
+// タップダンスキーの動作をコントロールする関数
+void ql_finished(qk_tap_dance_state_t *state, void *user_data) {
+    ql_tap_state.state = cur_dance(state);
+    switch (ql_tap_state.state) {
+        case SINGLE_TAP:
+            tap_code(KC_QUOT);
+            break;
+        case SINGLE_HOLD:
+            layer_on(_MY_LAYER);
+            break;
+        case DOUBLE_TAP:
+            // レイヤーが既にセットされているか確認します
+            if (layer_state_is(_MY_LAYER)) {
+                // レイヤーが既にセットされていたら、オフにします。
+                layer_off(_MY_LAYER);
+            } else {
+                // レイヤーがセットされていなかったら、オンにします。
+                layer_on(_MY_LAYER);
+            }
+            break;
+    }
+}
+
+void ql_reset(qk_tap_dance_state_t *state, void *user_data) {
+    // キーを押し続けていて今離したら、レイヤーをオフに切り替えます。
+    if (ql_tap_state.state == SINGLE_HOLD) {
         layer_off(_MY_LAYER);
-      } else { 
-        //レイヤーがセットされていなかったら、オンにします。
-        layer_on(_MY_LAYER);
-      }
-      break;
-  }
+    }
+    ql_tap_state.state = 0;
 }
 
-void ql_reset (qk_tap_dance_state_t *state, void *user_data) {
-  //キーを押し続けていて今離したら、レイヤーをオフに切り替えます。
-  if (ql_tap_state.state==SINGLE_HOLD) {
-    layer_off(_MY_LAYER);
-  }
-  ql_tap_state.state = 0;
-}
-
-//タップダンスキーを機能に関連付けます
+// タップダンスキーを機能に関連付けます
 qk_tap_dance_action_t tap_dance_actions[] = {
-  [QUOT_LAYR] = ACTION_TAP_DANCE_FN_ADVANCED_TIME(NULL, ql_finished, ql_reset, 275)
+    [QUOT_LAYR] = ACTION_TAP_DANCE_FN_ADVANCED_TIME(NULL, ql_finished, ql_reset, 275)
 };
 ```
 
-上記のコードは、前の例で使われたコードに似ています。注意する1つのポイントは、必要に応じてレイヤーを切り替えられるように、どのレイヤーがアクティブになっているかいつでも確認できる必要があることです。これを実現するために、引数で与えられた `layer` がアクティブなら `true` を返す `layer_state_is( layer )`  を使います。
+上記のコードは、前の例で使われたコードに似ています。注意する1つのポイントは、必要に応じてレイヤーを切り替えられるように、どのレイヤーがアクティブになっているかいつでも確認できる必要があることです。これを実現するために、引数で与えられた `layer` がアクティブなら `true` を返す `layer_state_is(layer)` を使います。
 
 `cur_dance()` と `ql_tap_state` の使い方は、上の例と似ています。
 
-`ql_finished` 関数における `case:SINGLE_TAP` は、上の例と似ています。`case:SINGLE_HOLD` は、`ql_reset()` と連動してタップダンスキーを押している間 `_MY_LAYER` に切り替わり、キーを離した時に `_MY_LAYER` から離れます。これは、`MO(_MY_LAYER)` に似ています。`case:DOUBLE_TAP` は、`_MY_LAYER` がアクティブレイヤーかどうかを確認することによって動きます。そして、その結果に基づいてレイヤーのオン・オフをトグルします。これは `TG(_MY_LAYER)` に似ています。
+`ql_finished` 関数における `case:SINGLE_TAP` は、上の例と似ています。`SINGLE_HOLD` の case では、`ql_reset()` と連動してタップダンスキーを押している間 `_MY_LAYER` に切り替わり、キーを離した時に `_MY_LAYER` から離れます。これは、`MO(_MY_LAYER)` に似ています。`DOUBLE_TAP` の case では、`_MY_LAYER` がアクティブレイヤーかどうかを確認することによって動きます。そして、その結果に基づいてレイヤーのオン・オフをトグルします。これは `TG(_MY_LAYER)` に似ています。
 
 `tap_dance_actions[]` は、上の例に似ています。 `ACTION_TAP_DANCE_FN_ADVANCED()` の代わりに `ACTION_TAP_DANCE_FN_ADVANCED_TIME()` を使ったことに注意してください。
 この理由は、私は、非タップダンスキーを使うにあたり `TAPPING_TERM` が短い(175ミリ秒以内)方が好きなのですが、タップダンスのアクションを確実に完了させるには短すぎるとわかったからです——そのため、ここでは時間を275ミリ秒に増やしています。
 
-最後に、このタップダンスキーを動かすため、忘れずに `TD(QUOT_LAYR)` を `keymaps[]` に加えてください。 
+最後に、このタップダンスキーを動かすため、忘れずに `TD(QUOT_LAYR)` を `keymaps[]` に加えてください。

docs/ja/feature_userspace.md

@@ -1,8 +1,8 @@
 # ユーザスペース: キーマップ間でのコードの共有
 
 <!---
-  original document: 0.9.0:docs/feature_userspace.md
-  git diff 0.9.0 HEAD -- docs/feature_userspace.md | cat
+  original document: 0.9.43:docs/feature_userspace.md
+  git diff 0.9.43 HEAD -- docs/feature_userspace.md | cat
 -->
 
 似たキーマップを複数のキーボードで使う場合、それらの間でコードを共有できるという利点が得られることがあります。`users/`に以下の構造でキーマップ(理想的には GitHub のユーザ名、`<name>`)と同じ名前の独自のフォルダを作成します:
@@ -116,7 +116,7 @@ along with this program.  If not, see <http://www.gnu.org/licenses/>.
 
 ## 例
 
-簡単な例については、[`/users/_example/`](https://github.com/qmk/qmk_firmware/tree/master/users/drashna) を調べてください。
+簡単な例については、[`/users/_example/`](https://github.com/qmk/qmk_firmware/tree/master/users/_example) を調べてください。
 より複雑な例については、[`/users/drashna/`](https://github.com/qmk/qmk_firmware/tree/master/users/drashna) のユーザスペースを調べてください。
 
 

docs/ja/flashing.md

@@ -1,8 +1,8 @@
 # 書き込みの手順とブートローダ情報
 
 <!---
-  original document: 0.9.10:docs/flashing.md
-  git diff 0.9.10 HEAD -- docs/flashing.md | cat
+  original document: 0.10.33:docs/flashing.md
+  git diff 0.10.33 HEAD -- docs/flashing.md | cat
 -->
 
 キーボードが使用するブートローダにはかなり多くの種類があり、ほぼ全てが異なる書き込みの方法を使います。幸いなことに、[QMK Toolbox](https://github.com/qmk/qmk_toolbox/releases) のようなプロジェクトは、あまり深く考える必要無しに様々なタイプと互換性を持つことを目指していますが、この文章では様々なタイプのブートローダとそれらを書き込むために利用可能な方法について説明します。
@@ -244,3 +244,4 @@ BOOTLOADER = bootloadHID
 * `:dfu-util-split-left` - デフォルトのオプション (`:dfu-util`) と同様に、通常のファームウェアが書き込まれます。ただし、分割キーボードの「左側の」 EEPROM の設定も行われます。
 * `:dfu-util-split-right` - デフォルトのオプション (`:dfu-util`) と同様に、通常のファームウェアが書き込まれます。ただし、分割キーボードの「右側の」 EEPROM の設定も行われます。
 * `:st-link-cli` - dfu-util ではなく、ST-LINK の CLI ユーティリティを介してファームウェアを書き込めます。
+* `:st-flash` - dfu-util ではなく、[STLink Tools](https://github.com/stlink-org/stlink) の `st-flash` ユーティリティを介してファームウェアを書き込めます。

docs/ja/flashing_bootloadhid.md

@@ -0,0 +1,75 @@
+# BootloadHID の書き込み手順とブートローダの情報
+
+<!---
+  original document: 0.9.32:docs/flashing_bootloadhid.md
+  git diff 0.9.32 HEAD -- docs/flashing_bootloadhid.md | cat
+-->
+
+ps2avr(GB) キーボードは ATmega32A マイクロコントローラを使い、異なるブートローダを使います。それは通常の QMK の方法を使って書き込むことができません。
+
+一般的な書き込みシーケンス:
+
+1. 以下のいずれかの方法を使ってブートローダに入ります:
+   * `RESET` キーコードをタップします (全てのデバイスでは動作しないかもしれません)
+   * ソルトキーを押し続けながらキーボードを接続します (通常はキーボードの readme に書かれています)
+2. OS がデバイスを検知するのを待ちます。
+3. .hex ファイルを書き込みます
+4. デバイスをアプリケーションモードにリセットします(自動的に実行されるかもしれません)
+
+## bootloadHID の書き込みターゲット
+
+?> [こちら](ja/newbs_getting_started.md)で詳しく説明されている QMK インストールスクリプトを使うと、必要な bootloadHID ツールが自動的にインストールされます。
+
+コマンドライン経由で書き込むには、以下のコマンドを実行してターゲット `:bootloadHID` を使います:
+
+    make <keyboard>:<keymap>:bootloadHID
+
+## GUI 書き込み
+
+### Windows
+1. [HIDBootFlash](http://vusb.wikidot.com/project:hidbootflash) をダウンロードします。
+2. キーボードをリセットします。
+3. 設定された VendorID が `16c0` で、ProductID が `05df` であることを確認します
+4. `Find Device` ボタンを押し、キーボードが見つかることを確認します。
+5. `Open .hex File` ボタンを押し、作成した `.hex` ファイルを見つけます。
+6. `Flash Device` ボタンを押し、処理が完了するまで待ちます。
+
+## コマンドライン書き込み
+
+1. キーボードをリセットします。
+2. `bootloadHID -r` に続けて `.hex` ファイルへのパスを入力し、キーボードに書き込みます。
+
+### Windows 手動インストール
+MSYS2の場合:
+1. https://www.obdev.at/downloads/vusb/bootloadHID.2012-12-08.tar.gz から BootloadHID ファームウェアパッケージをダウンロードします。
+2. 互換性のあるツール、例えば 7-Zip を使って内容を抽出します。
+3. 解凍された書庫から MSYS2 インストール先、通常 `C:\msys64\usr\bin` に `commandline/bootloadHID.exe` をコピーして、MSYS パスに追加します。
+
+ネイティブの Windows 書き込みの場合、MSYS2 環境の外部で `bootloadHID.exe` を使うことができます。
+
+### Linux 手動インストール
+1. libusb development の依存関係をインストールします:
+   ```bash
+   # これは OS に依存します - Debian については以下で動作します
+sudo apt-get install libusb-dev
+   ```
+2. BootloadHID ファームウェアパッケージをダウンロードします:
+   ```
+   wget https://www.obdev.at/downloads/vusb/bootloadHID.2012-12-08.tar.gz -O - | tar -xz -C /tmp
+   ```
+3. bootloadHID 実行可能ファイルをビルドします:
+   ```
+   cd /tmp/bootloadHID.2012-12-08/commandline/
+make
+sudo cp bootloadHID /usr/local/bin
+   ```
+
+### MacOS 手動インストール
+1. 以下を入力して Homebrew をインストールします:
+   ```
+   /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
+   ```
+2. 以下のパッケージをインストールします:
+   ```
+   brew install --HEAD https://raw.githubusercontent.com/robertgzr/homebrew-tap/master/bootloadhid.rb
+   ```

docs/ja/getting_started_docker.md

@@ -0,0 +1,52 @@
+# Docker クイックスタート
+
+<!---
+  original document: 0.9.32:docs/getting_started_docker.md
+  git diff 0.9.32 HEAD -- docs/getting_started_docker.md | cat
+-->
+
+このプロジェクトは、プライマリオペレーティングシステムに大きな変更を加えることなくキーボードの新しいファームウェアを非常に簡単に構築することができる Docker ワークフローを含みます。これは、あなたがプロジェクトをクローンしビルドを実行した時に、他の人とまったく同じ環境と QMK ビルド基盤を持つことも保証します。これにより、人々はあなたが遭遇した問題の解決をより簡単に行えるようになります。
+
+## 必要事項
+
+主な前提条件は動作する `docker` がインストールされていることです。
+* [Docker CE](https://docs.docker.com/install/#supported-platforms)
+
+## 使い方
+
+(サブモジュールを含む) QMK のレポジトリのローカルコピーを取得する:
+
+```bash
+git clone --recurse-submodules https://github.com/qmk/qmk_firmware.git
+cd qmk_firmware
+```
+
+キーマップをビルドするために以下のコマンドを実行します:
+```bash
+util/docker_build.sh <keyboard>:<keymap>
+# 例えば: util/docker_build.sh planck/rev6:default
+```
+
+これは目的のキーボード/キーマップをコンパイルし、結果として書き込み用に `.hex` あるいは `.bin` ファイルを QMK ディレクトリの中に残します。`:keymap` が省略された場合は全てのキーマップが使われます。パラメータの形式は、`make` を使ってビルドする時と同じであることに注意してください。
+
+`target` を指定して Docker から直接キーボードをビルドし、_かつ_書き込むためのサポートもあります。
+
+```bash
+util/docker_build.sh keyboard:keymap:target
+# 例えば: util/docker_build.sh planck/rev6:default:flash
+```
+
+スクリプトをパラメータ無しで開始することもできます。この場合、1つずつビルドパラメータを入力するように求められます。これが使いやすいと思うかもしれません:
+
+```bash
+util/docker_build.sh
+# パラメータを入力として読み込みます (空白にすると全てのキーボード/キーマップ)
+```
+
+## FAQ
+
+### なぜ Windows/macOS 上で書き込めないのですか？
+
+Windows と macOS では、実行するために [Docker Machine](http://gw.tnode.com/docker/docker-machine-with-usb-support-on-windows-macos/) が必要です。これはセットアップが面倒なので、お勧めではありません: 代わりに [QMK Toolbox](https://github.com/qmk/qmk_toolbox) を使ってください。
+
+!> Docker for Windows は[Hyper-V](https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/quick-start/enable-hyper-v) を有効にする必要があります。これは、Windows 7、Windows 8 および **Windows 10 Home** のような Hyper-V を搭載していない Windows のバージョンでは機能しないことを意味します。

docs/ja/getting_started_github.md

@@ -1,8 +1,8 @@
 # QMK で GitHub を使う方法
 
 <!---
-  original document: 0.8.82:docs/getting_started_github.md
-  git diff 0.8.82 HEAD -- docs/getting_started_github.md | cat
+  original document: 0.9.43:docs/getting_started_github.md
+  git diff 0.9.43 HEAD -- docs/getting_started_github.md | cat
 -->
 
 GitHub は慣れていない人には少し注意が必要です - このガイドは、QMK におけるフォーク、クローン、プルリクエストのサブミットの各ステップについて説明します。
@@ -11,11 +11,11 @@ GitHub は慣れていない人には少し注意が必要です - このガイ
 
 [QMK GitHub ページ](https://github.com/qmk/qmk_firmware)を開くと、右上に "Fork" というボタンが見えます:
 
-![Git でのフォーク](http://i.imgur.com/8Toomz4.jpg)
+![GitHub でのフォーク](http://i.imgur.com/8Toomz4.jpg)
 
 あなたが組織の一員である場合は、どのアカウントにフォークするかを選択する必要があります。ほとんどの場合、あなたの個人のアカウントにフォークしたいでしょう。フォークが完了したら(しばらく時間が掛かる場合があります)、"Clone or Download" ボタンをクリックします:
 
-![Git からダウンロード](http://i.imgur.com/N1NYcSz.jpg)
+![GitHub からダウンロード](http://i.imgur.com/N1NYcSz.jpg)
 
 必ず "HTTPS" を選択し、リンクを選択してコピーします:
 

docs/ja/getting_started_make_guide.md

@@ -1,8 +1,8 @@
 # より詳細な `make` 手順
 
 <!---
-  original document: 0.9.0:docs/getting_started_make_guide.md
-  git diff 0.9.0 HEAD -- docs/getting_started_make_guide.md | cat
+  original document: 0.10.33:docs/getting_started_make_guide.md
+  git diff 0.10.33 HEAD -- docs/getting_started_make_guide.md | cat
 -->
 
 `make` コマンドの完全な構文は `<keyboard_folder>:<keymap>:<target>` です:
@@ -106,10 +106,6 @@ make コマンド自体にもいくつかの追加オプションがあります
 
 詳細と制限については、[Unicode ページ](ja/feature_unicode.md) を見てください。
 
-`BLUETOOTH_ENABLE`
-
-これによりキーコードをワイヤレスで送信するために Bluefruit EZ-key と連動することができます。D2 と D3 ピンを使います。
-
 `AUDIO_ENABLE`
 
 C6 ピン(抽象化が必要)でオーディオ出力できます。詳細は[オーディオページ](ja/feature_audio.md)を見てください。

docs/ja/hardware_avr.md

@@ -2,8 +2,8 @@
 
 <!---
   grep --no-filename "^[ ]*git diff" docs/ja/*.md | sh
-  original document: 0.9.0:docs/hardware_avr.md
-  git diff 0.9.0 HEAD -- docs/hardware_avr.md | cat
+  original document: 0.10.33:docs/hardware_avr.md
+  git diff 0.10.33 HEAD -- docs/hardware_avr.md | cat
 -->
 
 このページでは QMK における AVR マイコンのサポートについて説明します。AVR マイコンには、Atmel 社製の atmega32u4、atmega32u2、at90usb1286 やその他のマイコンを含みます。AVR マイコンは、簡単に動かせるよう設計された8ビットの MCU です。キーボードでよく使用される AVR マイコンには USB 機能や大きなキーボードマトリックスのためのたくさんの GPIO を搭載しています。これらは、現在、キーボードで使われる最も一般的な MCU です。
@@ -73,7 +73,7 @@ or open the directory in your favourite text editor.
 
 `config.h` の先頭には USB に関する設定があります。これらはキーボードが OS からどのように見えるかを制御しています。変更する理由がない場合は、`VENDOR_ID` を `0xFEED` のままにしておく必要があります。`PRODUCT_ID` にはまだ使用されていない番号を選ばなければいけません。
 
-`MANUFACTURER`、 `PRODUCT`、 `DESCRIPTION` をキーボードにあった設定に変更します。
+`MANUFACTURER`、 `PRODUCT` をキーボードにあった設定に変更します。
 
 ```c
 #define VENDOR_ID       0xFEED
@@ -81,7 +81,6 @@ or open the directory in your favourite text editor.
 #define DEVICE_VER      0x0001
 #define MANUFACTURER    You
 #define PRODUCT         my_awesome_keyboard
-#define DESCRIPTION     A custom keyboard
 ```
 
 ?> Windows や macOS では、`MANUFACTURER` と `PRODUCT` が USBデバイスのリストに表示されます。Linux 上の `lsusb` では、代わりにデフォルトで [USB ID Repository](http://www.linux-usb.org/usb-ids.html) によって維持されているリストからこれらを取得します。`lsusb -v` を使用するとデバイスから示された値を表示します。また、接続したときのカーネルログにも表示されます。

docs/ja/hardware_keyboard_guidelines.md

@@ -2,8 +2,8 @@
 
 <!---
   grep --no-filename "^[ ]*git diff" docs/ja/*.md | sh
-  original document: 0.9.0:docs/hardware_keyboard_guidelines.md
-  git diff 0.9.0 HEAD -- docs/hardware_keyboard_guidelines.md | cat
+  original document: 0.10.33:docs/hardware_keyboard_guidelines.md
+  git diff 0.10.33 HEAD -- docs/hardware_keyboard_guidelines.md | cat
 -->
 
 QMK は開始以来、コミュニティにおけるキーボードの作成や保守に貢献しているあなたのような人たちのおかげで飛躍的に成長しました。私たちが成長するにつれて、うまくやるためのいくつかのパターンを発見しました。他の人たちがあなたの苦労の恩恵を受けやすくするため、それにあわせてもらえるようお願いします。

docs/ja/how_a_matrix_works.md

@@ -0,0 +1,104 @@
+# キーボードマトリックスの仕組み
+
+<!---
+  original document: 0.9.32:docs/how_a_matrix_works.md
+  git diff 0.9.32 HEAD -- docs/how_a_matrix_works.md | cat
+-->
+
+キーボードスイッチのマトリックスは行と列に配置されます。マトリックス回路がなければ、各スイッチはコントローラに直接配線する必要があります。
+
+回路が行と列に配置されている場合、キーが押されると、列ワイヤが行ワイヤと接触し、回路が完成します。キーボードコントローラはこの閉回路を検知し、キー押下として登録します。
+
+マイクロコントローラはファームウェアを介してセットアップされ、論理1を一度に1つずつ列に送信し、行から一度に全てを読み取ります - このプロセスはマトリックススキャンと呼ばれます。マトリックスはデフォルトでは電流の通過を許可しないたくさんの開いたスイッチです - ファームウェアはキーが押されていないものとしてこれを読み取ります。1つのキーを押すとすぐに、キースイッチが接続されている列から来ていた論理1がスイッチを通過して対応する行に渡されます - 以下の 2x2 の例を確認してください:
+
+        Column 0 being scanned     Column 1 being scanned
+                  x                                   x
+                 col0     col1              col0     col1
+                  |        |                 |        |
+        row0 ---(key0)---(key1)    row0 ---(key0)---(key1)
+                  |        |                 |        |
+        row1 ---(key2)---(key3)    row1 ---(key2)---(key3)
+
+`x` は関連付けられた列と行の値が1であるか、HIGH であることを表します。ここでは、キーが押されていないことが分かります。そのため `x` を取得する行はありません。1つのキースイッチの二つの接点はそのスイッチのある行と列にそれぞれ接続されていることに注意してください。
+
+`key0` を押すと、`col0` は `row0` に接続されるため、ファームウェアがその行に対して受け取る値は `0b01` です (ここで `0b` はこれがビット値であることを意味します。つまり次の数字は全てビット(0または1)であり、その列のキーを表します)。この表記を使用して、キースイッチが押されたことを示し、列と行が接続されていることを示します:
+
+        Column 0 being scanned     Column 1 being scanned
+                  x                                   x
+                 col0     col1              col0     col1
+                  |        |                 |        |
+      x row0 ---(-+-0)---(key1)    row0 ---(-+-0)---(key1)
+                  |        |                 |        |
+        row1 ---(key2)---(key3)    row1 ---(key2)---(key3)
+
+`row0` には `x` があるため、値が1であることがわかります。全体として、`key0` が押された時にファームウェアが受信するデータは、
+
+    col0: 0b01
+    col1: 0b00
+            │└row0
+            └row1
+
+一度に複数のキーを押し始めると問題が発生します。マトリックスをもう一度見ると、かなり明白になっているはずです:
+
+        Column 0 being scanned     Column 1 being scanned
+                  x                                   x
+                 col0     col1              col0     col1
+                  |        |                 |        |
+      x row0 ---(-+-0)---(-+-1)  x row0 ---(-+-0)---(-+-1)
+                  |        |                 |        |
+      x row1 ---(key2)---(-+-3)  x row1 ---(key2)---(-+-3)
+
+      Remember that this ^ is still connected to row1
+
+これから取得されるデータは以下の通りです:
+
+    col0: 0b11
+    col1: 0b11
+            │└row0
+            └row1
+
+4つ全てではなく、3つのキーしか押されていないため、これは正確ではありません。この挙動はゴーストと呼ばれ、このような奇妙なシナリオでのみ発生しますが、より大きなキーボードではより一般的です。これを回避する方法は、キースイッチの後に、行に接続する前にダイオードを配置することです。ダイオードは、電流が一方向にのみ流れるようにします。これにより、前の例で他の列と行がアクティブにならないようにします。ダイオードマトリックスをこのように表します;
+
+        Column 0 being scanned     Column 1 being scanned
+                    x                                   x
+                  col0      col1              col0     col1
+                    │        │                 |        │
+                 (key0)   (key1)            (key0)   (key1)
+                  ! │      ! │               ! |      ! │
+        row0 ─────┴────────┘ │     row0 ─────┴────────┘ │
+                    │        │                 |        │
+                 (key2)   (key3)            (key2)   (key3)
+                  !        !                 !        !
+        row1 ─────┴────────┘       row1 ─────┴────────┘
+
+実際の用途では、ダイオードの黒い線が行に面するように、キースイッチから離れるように配置されます - この場合の `!` はダイオードで、隙間は黒い線を表します。これを覚える良い方法は、以下のシンボルを考えることです: `>|`
+
+次に、3つのキーを押して、ゴーストシナリオとなるものを実施します:
+
+        Column 0 being scanned     Column 1 being scanned
+                    x                                   x
+                  col0      col1              col0     col1
+                    │        │                 │        │
+                 (┌─┤0)   (┌─┤1)            (┌─┤0)   (┌─┤1)
+                  ! │      ! │               ! │      ! │
+      x row0 ─────┴────────┘ │   x row0 ─────┴────────┘ │
+                    │        │                 │        │
+                 (key2)   (┌─┘3)            (key2)   (┌─┘3)
+                  !        !                 !        !
+        row1 ─────┴────────┘     x row1 ─────┴────────┘
+
+全てが期待通りに動きます！これにより、以下のデータが取得されます:
+
+    col0: 0b01
+    col1: 0b11
+            │└row0
+            └row1
+
+ファームウェアはこの正しいデータを使って、何をすべきかを、最終的には OS に送信する必要のある信号を検出できます。
+
+参考文献:
+- [Wikipedia の記事](https://en.wikipedia.org/wiki/Keyboard_matrix_circuit)
+- [Deskthority の記事](https://deskthority.net/wiki/Keyboard_matrix)
+- [Dave Dribin による Keyboard Matrix Help (2000)](https://www.dribin.org/dave/keyboard/one_html/)
+- [PCBheaven による How Key Matrices Works](http://pcbheaven.com/wikipages/How_Key_Matrices_Works/) (アニメーションの例)
+- [キーボードの仕組み - QMK ドキュメント](ja/how_keyboards_work.md)

docs/ja/how_keyboards_work.md

@@ -0,0 +1,74 @@
+# キーが登録され、コンピュータで解釈される仕組み
+
+<!---
+  original document: 0.9.32:docs/how_keyboards_work.md
+  git diff 0.9.32 HEAD -- docs/how_keyboards_work.md | cat
+-->
+
+このファイルでは、USB を介してキーボードがどのように動作するかの概念を学習できます。ファームウェアを直接変更することで何が期待できるかをより良く理解することができます。
+
+## 概略図
+
+特定のキーを1つ入力するたびに、このような一連のアクションが発生します:
+
+```text
++------+         +-----+       +----------+      +----------+     +----+
+| User |-------->| Key |------>| Firmware |----->| USB wire |---->| OS |
++------+         +-----+       +----------+      +----------+     +----+
+```
+
+この図は何が起こっているかを非常に単純に示したものです。詳細については次のセクションで説明します。
+
+## 1. キーを押す
+
+キーを押すたびに、キーボードのファームウェアはこのイベントを登録することができます。
+キーが押され、保持され、放された時に登録することができます。
+
+これは通常キー押下の定期的な走査で発生します。多くの場合、キーの機械的な応答時間、キー押下情報を転送するプロトコル(ここでは USB HID)、あるいは使用されるソフトウェアによって、この速度は制限されます。
+
+## 2. ファームウェアが送信するもの
+
+[HID 仕様](https://www.usb.org/sites/default/files/documents/hut1_12v2.pdf)では、適切に認識されるためにキーボードが USB 経由で実際に送信できるものを規定しています。これには、`0x00` から `0xE7` までの単純な数字であるスキャンコードの定義済リストが含まれます。ファームウェアはスキャンコードをキーボードのそれぞれのキーに割り当てます。
+
+ファームウェアは実際の文字を送信せず、スキャンコードだけを送信します。
+従って、ファームウェアを変更することで、特定のキーにたいして USB を介してどのスキャンコードが送信されるかだけを変更することができます。
+
+## 3. イベント入力やカーネルが行うこと
+
+*スキャンコード*は、[マスターブランチの 60-keyboard.hwdb](https://github.com/systemd/systemd/blob/master/hwdb.d/60-keyboard.hwdb) キーボードに依存する*キーコード*にマップされます。このマッピングが無いと、オペレーティングシステムは有効なキーコードを受信せず、キー押下で何も有用なことができません。
+
+## 4. オペレーティングシステムがすること
+
+キーコードがオペレーティングシステムに到達すると、ソフトウェアの一部はキーボードのレイアウトによって、実際の文字と照合しなければなりません。例えば、レイアウトが QWERTY に設定されている場合、照合テーブルの例は以下の通りです:
+
+| キーコード | 文字 |
+|---------|-----------|
+| 0x04 | a/A |
+| 0x05 | b/B |
+| 0x06 | c/C |
+| ... | ... |
+| 0x1C | y/Y |
+| 0x1D | z/Z |
+| ... | ... |
+
+## 説明をファームウェアに戻して
+
+(独自のものを作成していない限り)レイアウトは一般的に固定されているため、ファームウェアは実際には作業を簡単するためレイアウト名で直接キーコードを記述できます。これが、`KC_A` が実際に QWERTY で `0x04` を表す場合に行われることです。完全なリストは[キーコード](ja/keycodes.md)にあります。
+
+## 送信できる文字のリスト
+
+ショートカットを別として、限られたキーコードのセットが限られたレイアウトにマップされていることは、**指定されたキーに割り当てることができる文字のリストは、レイアウト内に存在するものだけである**ことを意味します。
+
+例えば、QWERTY US レイアウトがあり、1つのキーを `€` (ユーロ通貨記号)を生成するように割り当てたい場合、そうすることができないことを意味します。なぜなら、QWERTY US レイアウトはそのようなマッピングを持たないためです。QWERTY UK レイアウト、あるいは QWERTY US International を使うことでそれを修正することができます。
+
+全ての Unicode を含むキーボードレイアウトがなぜ考案されていないのか疑問に思うかもしれません。USB を介して利用可能なキーコードの数の制限により、このようなことは許可されません。
+
+## (おそらく) Unicode 文字を入力する方法
+
+ファームウェアに *一連のキー* を送信させて、目的のオペレーティングシステムの[ソフトウェア Unicode インプットメソッド](https://en.wikipedia.org/wiki/Unicode_input#Hexadecimal_input)を使うことができます。このようにして、OS で定義されたレイアウトとは無関係に文字を効率的に入力することができます。
+
+ただし、以下のような複数の欠点があります:
+
+- 一度に、一つの特定の OS に縛られます (OS を変更する時に再コンパイルする必要があります);
+- 特定の OS では、全てのソフトウェアが動作するわけではありません;
+- 一部のシステムでは Unicode のサブセットに制限されます。

docs/ja/i2c_driver.md

@@ -2,8 +2,8 @@
 
 <!---
   grep --no-filename "^[ ]*git diff" docs/ja/*.md | sh
-  original document: 0.8.62:docs/i2c_driver.md
-  git diff 0.8.62 HEAD -- docs/i2c_driver.md | cat
+  original document: 0.10.33:docs/i2c_driver.md
+  git diff 0.10.33 HEAD -- docs/i2c_driver.md | cat
 -->
 
 QMK で使われる I2C マスタドライバには、MCU 間のポータビリティを提供するための一連の関数が用意されています。
@@ -83,8 +83,8 @@ STM32 MCU では、使用するハードウェアドライバにより、さま
 |-----------------------|--------------------------------------------------------------------------------------------------|---------|
 | `I2C1_SCL_BANK`       | SCL に使うピンのバンク (`GPIOA`, `GPIOB`, `GPIOC`)                                               | `GPIOB` |
 | `I2C1_SDA_BANK`       | SDA に使うピンのバンク (`GPIOA`, `GPIOB`, `GPIOC`)                                               | `GPIOB` |
-| `I2C1_SCL`            | SCL のピン番号 (0-9)                                                                             | `6`     |
-| `I2C1_SDA`            | SDA のピン番号 (0-9)                                                                             | `7`     |
+| `I2C1_SCL`            | SCL のピン番号 (0-15)                                                                            | `6`     |
+| `I2C1_SDA`            | SDA のピン番号 (0-15)                                                                            | `7`     |
 | `I2C1_BANK`（非推奨） | 使用するピンのバンク (`GPIOA`, `GPIOB`, `GPIOC`)。後継は `I2C1_SCL_BANK`, `I2C1_SDA_BANK` です。 | `GPIOB` |
 
 ChibiOS I2C ドライバの設定項目は STM32 MCU の種類に依存します。

docs/ja/internals_gpio_control.md

@@ -0,0 +1,28 @@
+# GPIO 制御 :id=gpio-control
+
+<!---
+  original document: 0.9.34:docs/internals_gpio_control.md
+  git diff 0.9.34 HEAD -- docs/internals_gpio_control.md | cat
+-->
+
+QMK には、マイクロコントローラに依存しない GPIO 制御抽象レイヤーがあります。これは異なるプラットフォーム間でピン制御に簡単にアクセスできるようにするためのものです。
+
+## 関数 :id=functions
+
+以下の関数は GPIO の基本的な制御を提供し、`quantum/quantum.h` にあります。
+
+| 関数 | 説明 | 古い AVR の例 | 古い ChibiOS/ARM の例 |
+|------------------------|--------------------------------------------------|-------------------------------------------------|-------------------------------------------------|
+| `setPinInput(pin)` | ピンを高インピーダンス(High-Z)の入力として設定 | `DDRB &= ~(1<<2)` | `palSetLineMode(pin, PAL_MODE_INPUT)` |
+| `setPinInputHigh(pin)` | ピンを組み込みのプルアップ抵抗付きの入力として設定 | `DDRB &= ~(1<<2); PORTB \|= (1<<2)` | `palSetLineMode(pin, PAL_MODE_INPUT_PULLUP)` |
+| `setPinInputLow(pin)` | ピンを組み込みのプルダウン抵抗付きの入力として設定 | N/A (AVR ではサポートされません) | `palSetLineMode(pin, PAL_MODE_INPUT_PULLDOWN)` |
+| `setPinOutput(pin)` | ピンを出力として設定 | `DDRB \|= (1<<2)` | `palSetLineMode(pin, PAL_MODE_OUTPUT_PUSHPULL)` |
+| `writePinHigh(pin)` | ピンレベルを high に設定 (ピンを出力として設定してあると仮定) | `PORTB \|= (1<<2)` | `palSetLine(pin)` |
+| `writePinLow(pin)` | ピンレベルを low に設定 (ピンを出力として設定してあると仮定) | `PORTB &= ~(1<<2)` | `palClearLine(pin)` |
+| `writePin(pin, level)` | ピンレベルを設定 (ピンを出力として設定してあると仮定) | `(level) ? PORTB \|= (1<<2) : PORTB &= ~(1<<2)` | `(level) ? palSetLine(pin) : palClearLine(pin)` |
+| `readPin(pin)` | ピンのレベルを返す | `_SFR_IO8(pin >> 4) & _BV(pin & 0xF)` | `palReadLine(pin)` |
+| `togglePin(pin)` | ピンレベルを反転 (ピンを出力として設定してあると仮定) | `PORTB ^= (1<<2)` | `palToggleLine(pin)` |
+
+## 高度な設定 :id=advanced-settings
+
+各マイクロコントローラは GPIO に関して複数の高度な設定を持つことができます。この抽象レイヤーは、アーキテクチャー固有の機能の使用法を制限しません。上級ユーザは、目的のデバイスのデータシートを参照し、必要なライブラリを含めてください。AVR については、標準 avr/io.h ライブラリが使われます; STM32 については ChibiOS [PAL ライブラリ](http://chibios.sourceforge.net/docs3/hal/group___p_a_l.html)が使われます。

docs/ja/internals_input_callback_reg.md

@@ -0,0 +1,174 @@
+# group `input_callback_reg` {#group__input__callback__reg}
+
+<!---
+  original document: 0.9.34:docs/internals_input_callback_reg.md
+  git diff 0.9.34 HEAD -- docs/internals_input_callback_reg.md | cat
+-->
+
+これらは受信コールバックを登録するために使用する関数です。
+
+関数は、適切な midi メッセージが関連するデバイスの入力と一致した場合に呼び出されます。
+
+## 概要
+
+| メンバー | 説明 |
+--------------------------------|---------------------------------------------
+| `public void `[`midi_register_cc_callback`](#group__input__callback__reg_1ga64ab672abbbe393c9c4a83110c8df718)`(`[`MidiDevice`](#struct__midi__device)` * device,midi_three_byte_func_t func)` | コントロールチェンジメッセージ受信コールバックを登録する。 |
+| `public void `[`midi_register_noteon_callback`](#group__input__callback__reg_1ga3962f276c17618923f1152779552103e)`(`[`MidiDevice`](#struct__midi__device)` * device,midi_three_byte_func_t func)` | ノートオン受信コールバックを登録する。 |
+| `public void `[`midi_register_noteoff_callback`](#group__input__callback__reg_1gac847b66051bd6d53b762958be0ec4c6d)`(`[`MidiDevice`](#struct__midi__device)` * device,midi_three_byte_func_t func)` | ノートオフ受信コールバックを登録する。 |
+| `public void `[`midi_register_aftertouch_callback`](#group__input__callback__reg_1gaa95bc901bd9edff956a667c9a69dd01f)`(`[`MidiDevice`](#struct__midi__device)` * device,midi_three_byte_func_t func)` | アフタータッチ受信コールバックを登録する。 |
+| `public void `[`midi_register_pitchbend_callback`](#group__input__callback__reg_1ga071a28f02ba14f53de219be70ebd9a48)`(`[`MidiDevice`](#struct__midi__device)` * device,midi_three_byte_func_t func)` | ピッチベンド受信コールバックを登録する。 |
+| `public void `[`midi_register_songposition_callback`](#group__input__callback__reg_1gaf2adfd79637f3553d8f26deb1ca22ed6)`(`[`MidiDevice`](#struct__midi__device)` * device,midi_three_byte_func_t func)` | ソングポジション受信コールバックを登録する。 |
+| `public void `[`midi_register_progchange_callback`](#group__input__callback__reg_1gae6ba1a35a4cde9bd15dd42f87401d127)`(`[`MidiDevice`](#struct__midi__device)` * device,midi_two_byte_func_t func)` | プログラムチェンジ受信コールバックを登録する。 |
+| `public void `[`midi_register_chanpressure_callback`](#group__input__callback__reg_1ga39b31f1f4fb93917ce039b958f21b4f5)`(`[`MidiDevice`](#struct__midi__device)` * device,midi_two_byte_func_t func)` | チャンネルプレッシャー受信コールバックを登録する。 |
+| `public void `[`midi_register_songselect_callback`](#group__input__callback__reg_1gaf9aafc76a2dc4b9fdbb4106cbda6ce72)`(`[`MidiDevice`](#struct__midi__device)` * device,midi_two_byte_func_t func)` | ソングセレクト受信コールバックを登録する。 |
+| `public void `[`midi_register_tc_quarterframe_callback`](#group__input__callback__reg_1ga0a119fada2becc628cb15d753b257e6e)`(`[`MidiDevice`](#struct__midi__device)` * device,midi_two_byte_func_t func)` | タイムコードクォータフレーム受信コールバックを登録する。 |
+| `public void `[`midi_register_realtime_callback`](#group__input__callback__reg_1ga764f440e857b89084b1a07f9da2ff93a)`(`[`MidiDevice`](#struct__midi__device)` * device,midi_one_byte_func_t func)` | リアルタイム受信コールバックを登録する。 |
+| `public void `[`midi_register_tunerequest_callback`](#group__input__callback__reg_1gae40ff3ce20bda79fef87da24b8321cb1)`(`[`MidiDevice`](#struct__midi__device)` * device,midi_one_byte_func_t func)` | チューンリクエスト受信コールバックを登録する。 |
+| `public void `[`midi_register_sysex_callback`](#group__input__callback__reg_1ga63ce9631b025785c1848d0122d4c4c48)`(`[`MidiDevice`](#struct__midi__device)` * device,midi_sysex_func_t func)` | システムエクスクルーシブ受信コールバックを登録する。 |
+| `public void `[`midi_register_fallthrough_callback`](#group__input__callback__reg_1ga7ed189164aa9682862b3181153afbd94)`(`[`MidiDevice`](#struct__midi__device)` * device,midi_var_byte_func_t func)` | フォールスルー受信コールバックを登録する。 |
+| `public void `[`midi_register_catchall_callback`](#group__input__callback__reg_1ga9dbfed568d047a6cd05708f11fe39e99)`(`[`MidiDevice`](#struct__midi__device)` * device,midi_var_byte_func_t func)` | キャッチオール受信コールバックを登録する。 |
+
+## メンバー
+
+#### `public void `[`midi_register_cc_callback`](#group__input__callback__reg_1ga64ab672abbbe393c9c4a83110c8df718)`(`[`MidiDevice`](#struct__midi__device)` * device,midi_three_byte_func_t func)` {#group__input__callback__reg_1ga64ab672abbbe393c9c4a83110c8df718}
+
+コントロールチェンジメッセージ受信コールバックを登録する。
+
+#### パラメータ
+* `device` 関連するデバイス
+
+* `func` 登録するコールバック関数
+
+#### `public void `[`midi_register_noteon_callback`](#group__input__callback__reg_1ga3962f276c17618923f1152779552103e)`(`[`MidiDevice`](#struct__midi__device)` * device,midi_three_byte_func_t func)` {#group__input__callback__reg_1ga3962f276c17618923f1152779552103e}
+
+ノートオン受信コールバックを登録する。
+
+#### パラメータ
+* `device` 関連するデバイス
+
+* `func` 登録するコールバック関数
+
+#### `public void `[`midi_register_noteoff_callback`](#group__input__callback__reg_1gac847b66051bd6d53b762958be0ec4c6d)`(`[`MidiDevice`](#struct__midi__device)` * device,midi_three_byte_func_t func)` {#group__input__callback__reg_1gac847b66051bd6d53b762958be0ec4c6d}
+
+ノートオフ受信コールバックを登録する。
+
+#### パラメータ
+* `device` 関連するデバイス
+
+* `func` 登録するコールバック関数
+
+#### `public void `[`midi_register_aftertouch_callback`](#group__input__callback__reg_1gaa95bc901bd9edff956a667c9a69dd01f)`(`[`MidiDevice`](#struct__midi__device)` * device,midi_three_byte_func_t func)` {#group__input__callback__reg_1gaa95bc901bd9edff956a667c9a69dd01f}
+
+アフタータッチ受信コールバックを登録する。
+
+#### パラメータ
+* `device` 関連するデバイス
+
+* `func` 登録するコールバック関数
+
+#### `public void `[`midi_register_pitchbend_callback`](#group__input__callback__reg_1ga071a28f02ba14f53de219be70ebd9a48)`(`[`MidiDevice`](#struct__midi__device)` * device,midi_three_byte_func_t func)` {#group__input__callback__reg_1ga071a28f02ba14f53de219be70ebd9a48}
+
+ピッチベンド受信コールバックを登録する。
+
+#### パラメータ
+* `device` 関連するデバイス
+
+* `func` 登録するコールバック関数
+
+#### `public void `[`midi_register_songposition_callback`](#group__input__callback__reg_1gaf2adfd79637f3553d8f26deb1ca22ed6)`(`[`MidiDevice`](#struct__midi__device)` * device,midi_three_byte_func_t func)` {#group__input__callback__reg_1gaf2adfd79637f3553d8f26deb1ca22ed6}
+
+ソングポジション受信コールバックを登録する。
+
+#### パラメータ
+* `device` 関連するデバイス
+
+* `func` 登録するコールバック関数
+
+#### `public void `[`midi_register_progchange_callback`](#group__input__callback__reg_1gae6ba1a35a4cde9bd15dd42f87401d127)`(`[`MidiDevice`](#struct__midi__device)` * device,midi_two_byte_func_t func)` {#group__input__callback__reg_1gae6ba1a35a4cde9bd15dd42f87401d127}
+
+プログラムチェンジ受信コールバックを登録する。
+
+#### パラメータ
+* `device` 関連するデバイス
+
+* `func` 登録するコールバック関数
+
+#### `public void `[`midi_register_chanpressure_callback`](#group__input__callback__reg_1ga39b31f1f4fb93917ce039b958f21b4f5)`(`[`MidiDevice`](#struct__midi__device)` * device,midi_two_byte_func_t func)` {#group__input__callback__reg_1ga39b31f1f4fb93917ce039b958f21b4f5}
+
+チャンネルプレッシャー受信コールバックを登録する。
+
+#### パラメータ
+* `device` 関連するデバイス
+
+* `func` 登録するコールバック関数
+
+#### `public void `[`midi_register_songselect_callback`](#group__input__callback__reg_1gaf9aafc76a2dc4b9fdbb4106cbda6ce72)`(`[`MidiDevice`](#struct__midi__device)` * device,midi_two_byte_func_t func)` {#group__input__callback__reg_1gaf9aafc76a2dc4b9fdbb4106cbda6ce72}
+
+ソングセレクト受信コールバックを登録する。
+
+#### パラメータ
+* `device` 関連するデバイス
+
+* `func` 登録するコールバック関数
+
+#### `public void `[`midi_register_tc_quarterframe_callback`](#group__input__callback__reg_1ga0a119fada2becc628cb15d753b257e6e)`(`[`MidiDevice`](#struct__midi__device)` * device,midi_two_byte_func_t func)` {#group__input__callback__reg_1ga0a119fada2becc628cb15d753b257e6e}
+
+タイムコードクォータフレーム受信コールバックを登録する。
+
+#### パラメータ
+* `device` 関連するデバイス
+
+* `func` 登録するコールバック関数
+
+#### `public void `[`midi_register_realtime_callback`](#group__input__callback__reg_1ga764f440e857b89084b1a07f9da2ff93a)`(`[`MidiDevice`](#struct__midi__device)` * device,midi_one_byte_func_t func)` {#group__input__callback__reg_1ga764f440e857b89084b1a07f9da2ff93a}
+
+リアルタイム受信コールバックを登録する。
+
+全てのリアルタイムメッセージ型に対してコールバックが呼ばれます。
+
+#### パラメータ
+* `device` 関連するデバイス
+
+* `func` 登録するコールバック関数
+
+#### `public void `[`midi_register_tunerequest_callback`](#group__input__callback__reg_1gae40ff3ce20bda79fef87da24b8321cb1)`(`[`MidiDevice`](#struct__midi__device)` * device,midi_one_byte_func_t func)` {#group__input__callback__reg_1gae40ff3ce20bda79fef87da24b8321cb1}
+
+チューンリクエスト受信コールバックを登録する。
+
+#### パラメータ
+* `device` 関連するデバイス
+
+* `func` 登録するコールバック関数
+
+#### `public void `[`midi_register_sysex_callback`](#group__input__callback__reg_1ga63ce9631b025785c1848d0122d4c4c48)`(`[`MidiDevice`](#struct__midi__device)` * device,midi_sysex_func_t func)` {#group__input__callback__reg_1ga63ce9631b025785c1848d0122d4c4c48}
+
+システムエクスクルーシブ受信コールバックを登録する。
+
+#### パラメータ
+* `device` 関連するデバイス
+
+* `func` 登録するコールバック関数
+
+#### `public void `[`midi_register_fallthrough_callback`](#group__input__callback__reg_1ga7ed189164aa9682862b3181153afbd94)`(`[`MidiDevice`](#struct__midi__device)` * device,midi_var_byte_func_t func)` {#group__input__callback__reg_1ga7ed189164aa9682862b3181153afbd94}
+
+フォールスルー受信コールバックを登録する。
+
+より具体的なコールバックが見つからない場合にのみ呼ばれます。例えば、ノートオン受信コールバックを登録していないがノートオンメッセージを受け取った場合、フォールスルー受信コールバックが登録されている場合はそれが呼ばれます。
+
+#### パラメータ
+* `device` 関連するデバイス
+
+* `func` 登録するコールバック関数
+
+#### `public void `[`midi_register_catchall_callback`](#group__input__callback__reg_1ga9dbfed568d047a6cd05708f11fe39e99)`(`[`MidiDevice`](#struct__midi__device)` * device,midi_var_byte_func_t func)` {#group__input__callback__reg_1ga9dbfed568d047a6cd05708f11fe39e99}
+
+キャッチオール受信コールバックを登録する。
+
+登録されている場合は、より具体的なコールバックあるいはフォールスルー受信コールバックが登録されている場合でも、一致する全てのメッセージに対してキャッチオール受信コールバックが呼ばれます。
+
+#### パラメータ
+* `device` 関連するデバイス
+
+* `func` 登録するコールバック関数
+

docs/ja/isp_flashing_guide.md

@@ -0,0 +1,284 @@
+# ISP 書き込みガイド
+
+<!---
+  grep --no-filename "^[ ]*git diff" docs/ja/*.md | sh
+  original document: 0.9.46:docs/isp_flashing_guide.md
+  git diff 0.9.46 HEAD -- docs/isp_flashing_guide.md | cat
+-->
+
+ISP 書き込み(ICSP 書き込みと呼ぶ場合もあります)とは、マイクロコントローラーを直接プログラミングするプロセスです。
+これにより、ブートローダを交換したり、コントローラの「ヒューズ」を変更することができ、コントローラの速度や起動方法、その他のオプションなど、多くのハードウェアおよびソフトウェア関連の機能を制御します。
+
+QMK の ISP 書き込みの主な用途は、AVRベースのコントローラ（Pro Micro、または V-USB チップ）のブートローダの書き込みまたは交換です。
+
+?> これは Pro Micro や他の ATmega コントローラなどの AVR ベースのボードをプログラミングするためだけのものです。 Proton C などの Arm コントローラには使用できません。
+
+## 破損したブートローダーの取り扱い
+
+ボードの書き込み/消去で問題が発生し、DFU ベースのコントローラで次のような不可解なエラーメッセージが表示される場合：
+
+    libusb: warning [darwin_transfer_status] transfer error: timed out
+    dfu.c:844: -ETIMEDOUT: Transfer timed out, NAK 0xffffffc4 (-60)
+    atmel.c:1627: atmel_flash: flash data dfu_download failed.
+    atmel.c:1629: Expected message length of 1072, got -60.
+    atmel.c:1434: Error flashing the block: err -2.
+    ERROR
+    Memory write error, use debug for more info.
+    commands.c:360: Error writing memory data. (err -4)
+
+    dfu.c:844: -EPIPE: a) Babble detect or b) Endpoint stalled 0xffffffe0 (-32)
+    Device is write protected.
+    dfu.c:252: dfu_clear_status( 0x7fff4fc2ea80 )
+    atmel.c:1434: Error flashing the block: err -2.
+    ERROR
+    Memory write error, use debug for more info.
+    commands.c:360: Error writing memory data. (err -4)
+
+または、Pro Micro ベースのコントローラに対して次のようなメッセージが表示された場合:
+
+    avrdude: butterfly_recv(): programmer is not responding
+    avrdude: butterfly_recv(): programmer is not responding
+    avrdude: verification error, first mismatch at byte 0x002a
+            0x2b != 0x75
+    avrdude: verification error; content mismatch
+    avrdude: verification error; content mismatch
+
+
+あなたのボード/デバイスを再び動作させるには、ISP 書き込みが必要になるかもしれません。
+
+## 必要なハードウェア
+
+実際に ISP の書き込みを行うには、以下のいずれか（その後に使用するプロトコルが続きます）が必要になります。
+
+* [SparkFun PocketAVR](https://www.sparkfun.com/products/9825) - (USB Tiny)
+* [USBtinyISP AVR Programmer Kit](https://www.adafruit.com/product/46) - (USB Tiny)
+* [Teensy 2.0](https://www.pjrc.com/store/teensy.html) - (avrisp)
+* [Pro Micro](https://www.sparkfun.com/products/12640)  - (avrisp)
+* [Bus Pirate](https://www.adafruit.com/product/237) - (buspirate)
+
+ISP 書き込みに使用できるデバイスは他にもありますが、これらが主なものです。
+また、すべての製品リンクは公式バージョンへのものです。他の場所で入手することもできます。
+
+また、「ISP プログラマ」をプログラミングするデバイスに配線するためのものも必要になります。
+PCB の中には直接使用できる ISP ヘッダがあるものもありますが、そうではない場合が多いので、コントローラ自体にハンダ付けするか、別のスイッチや他のコンポーネントにハンダ付けする必要があるでしょう。
+
+### ISP ファームウェア
+
+Teensy と Pro Micro のコントローラを ISP プログラマとして使用するには、コントローラに ISP ファームウェアを書き込む必要があります。
+それ以外のハードウェアは、あらかじめプログラムされているはずです。
+そのため、これらのコントローラの場合は、正しい hex ファイルをダウンロードしてから書き込んでください。
+
+* Teensy 2.0: [`util/teensy_2.0_ISP_B0.hex`](https://github.com/qmk/qmk_firmware/blob/master/util/teensy_2.0_ISP_B0.hex) (`B0`)
+* Pro Micro: [`util/pro_micro_ISP_B6_10.hex`](https://github.com/qmk/qmk_firmware/blob/master/util/pro_micro_ISP_B6_10.hex) (`10/B6`)
+
+コントローラに書き込んだら、この hex ファイルはもう必要ありません。
+
+## 必要なソフトウェア
+
+QMK ツールボックスは、このほとんど（すべて）に使用することができます。
+
+ただし、Teensy 2.0 ボードを使っている場合は、[Teensy Loader](https:/www.pjrc.comteensyloader.html) を使えば、Teensy 2.0 ボードに書き込むことができます。
+あるいは、`avrdude` (`qmk_install.sh` の一部としてインストールされています) や、[AVRDUDESS](https:/blog.zakkemble.netavrdudess-a-gui-for-avrdude)(Windows 用) を使って、Pro Micro に書き込んだり、ISP を書き込んだりすることができます。
+
+## 配線
+
+これは非常に簡単です。次のようにして、相互に対応するものを接続します。
+
+### SparkFun Pocket AVR
+
+    PocketAVR RST  <-> Keyboard RESET
+    PocketAVR SCLK <-> Keyboard B1 (SCLK)
+    PocketAVR MOSI <-> Keyboard B2 (MOSI)
+    PocketAVR MISO <-> Keyboard B3 (MISO)
+    PocketAVR VCC  <-> Keyboard VCC
+    PocketAVR GND  <-> Keyboard GND
+
+### Teensy 2.0
+
+    Teensy B0  <-> Keyboard RESET
+    Teensy B1  <-> Keyboard B1 (SCLK)
+    Teensy B2  <-> Keyboard B2 (MOSI)
+    Teensy B3  <-> Keyboard B3 (MISO)
+    Teensy VCC <-> Keyboard VCC
+    Teensy GND <-> Keyboard GND
+    
+!> Teensy の B0 ピンはキーボードのコントローラの RESET/RST ピンと配線されています。 Teensy の RESET ピンをキーボードの RESET に配線しないでください。
+
+### Pro Micro
+
+    Pro Micro 10 (B6)  <-> Keyboard RESET
+    Pro Micro 15 (B1)  <-> Keyboard B1 (SCLK)
+    Pro Micro 16 (B2)  <-> Keyboard B2 (MOSI)
+    Pro Micro 14 (B3)  <-> Keyboard B3 (MISO)
+    Pro Micro VCC      <-> Keyboard VCC
+    Pro Micro GND      <-> Keyboard GND
+
+!> Pro Micro の 10/B6 ピンはキーボードのコントローラの RESET/RST ピンに配線されています。 Pro Micro の RESET ピンをキーボードの RESET に配線 ***しないでください***。
+
+## キーボードへの書き込み
+
+ISP プログラマをセットアップして、キーボードに接続したら、キーボードに書き込みをします。
+
+### ブートローダファイル
+
+普通の状態に戻す一番簡単で手っ取り早い方法は、キーボードにブートローダだけ書き込むことです。
+これが終れば、普通にキーボードを接続して、普通にキーボードに書き込みできるようになります。
+
+標準のブートローダは[`util/` フォルダー](https://github.com/qmk/qmk_firmware/tree/master/util) にあります。
+チップの正しいブートローダを書き込んでください:
+
+* **Atmel DFU**
+  * [ATmega16U4](https://github.com/qmk/qmk_firmware/blob/master/util/bootloader_atmega16u4_1.0.1.hex)
+  * [ATmega32U4](https://github.com/qmk/qmk_firmware/blob/master/util/bootloader_atmega32u4_1.0.0.hex)
+  * [AT90USB64](https://github.com/qmk/qmk_firmware/blob/master/util/bootloader_at90usb64_1.0.0.hex)
+  * [AT90USB128](https://github.com/qmk/qmk_firmware/blob/master/util/bootloader_at90usb128_1.0.1.hex)
+* **Caterina**
+  * [Pro Micro (5V/16MHz)](https://github.com/sparkfun/Arduino_Boards/blob/master/sparkfun/avr/bootloaders/caterina/Caterina-promicro16.hex)
+  * [Pro Micro (3.3V/8MHz)](https://github.com/sparkfun/Arduino_Boards/blob/master/sparkfun/avr/bootloaders/caterina/Caterina-promicro8.hex)
+* **BootloadHID (PS2AVRGB)**
+  * [ATmega32A](https://github.com/qmk/qmk_firmware/blob/master/util/bootloader_ps2avrgb_bootloadhid_1.0.1.hex)
+
+お使いのボードが何を使っているかわからない場合は、QMK のキーボード用の `rules.mk` ファイルを見てください。
+`MCU` と `BOOTLOADER` の行には必要な値が書かれています。これはボードのバージョンによって異なるかもしれません。
+
+### 製造手法
+
+ブートローダと通常のファームウェアを同時に書き込みたい場合、2つの方法があります。
+手動で行うか、コンパイル時に `:production` ターゲットを使って行うかです。
+
+手動で行うには:
+
+1. オリジナルのファームウェアの .hex ファイルをテキストエディタで開きます
+2. 最後の行を削除してください。(`:00000001FF`になっているはずです - これは EOF メッセージです)
+3. ブートローダの内容全体を新しい行にコピーして(行間に空行を入れないように)、元のファイルの最後に貼り付けてください。
+4. これを新しいファイルとして `<keyboard>_<keymap>_production.hex` という名前で保存します。
+
+?> ここでは他のブートローダも同じように使うことができますが、__ブートローダが必要で__、そうしないとまた ISP を使ってキーボードに新しいファームウェアを書き込まなければならなくなります。
+
+#### QMK DFU ブートローダとプロダクションイメージの作成
+
+コンパイル時に `:production` ターゲットを使用して、ボード用のファームウェア、QMK DFU ブートローダ、プロダクションファームウェアイメージを作成することができます。
+これが完了すると、3つのファイルが表示されます:
+
+* `<keyboard>_<keymap>.hex`
+* `<keyboard>_<keymap>_bootloader.hex`
+* `<keyboard>_<keymap>_production.hex`
+
+QMK DFU ブートローダは `atmega32u4` コントローラ (AVR ベースの Planck ボードや Pro Micro など) でしかテストされておらず、他のコントローラではテストされていません。
+しかし、`atmega32a` や `atmega328p` のような V-USB コントローラでは間違いなく動作しません。
+
+ブートローダかプロダクションファームウェアファイルのどちらかを書き込むことができます。
+プロダクションファームウェアファイルの方が、より多くのデータを書き込むので、書き込みに時間がかかります。
+
+?> 注意：同じブートローダを使用しつづけるべきです。すでに DFU を使用している場合は、QMK DFU に切り替えても問題ありません。しかし、例えば Pro Micro に QMK DFU を書き込むには、追加の手順が必要になります。
+
+## ブートローダ/プロダクションファイルの書き込み
+
+キーボードがどのデバイスにも接続されていないことを確認し、ISP プログラマを接続してください。
+
+ブートローダの種類を変更したい場合は、コマンドラインを使用する必要があります。
+
+### QMK Toolbox
+
+1. 'AVRISP device connected' または `USB Tiny device connected` が黄色で表示されます。
+2. `Open` ダイアログで正しいブートローダー/プロダクションの .hex ファイルを選択します（パスにスペースを含めることはできません）
+3. 書きこもうとしているキーボード（ISP プログラマではなく）のための正しい `Microcontroller` オプションが選択されていることを確認してください。
+4. `Flash` を押します
+5. 特にプロダクションファイルの場合、しばらくは何も出力されませんが、待ちましょう。
+
+検証とヒューズのチェックに問題がなければ、完了です。
+ボードが自動的に再起動する場合があります。
+それ以外の場合は、Teensy のプラグを抜いて、キーボードを接続します。
+テスト中は、Teensy をキーボードに接続したままにすることができますが、すべてが正常に機能することを確認したら、はんだを外すか、配線を外すことをお勧めします。
+
+### コマンドライン
+
+ターミナル（Windows の場合は `cmd`）を開いて、修正した .hex ファイルがある場所に移動します。
+ここでは、このファイルを `main.hex` と呼び、Teensy 2.0 が `COM3` ポートに接続されていると仮定します。
+よくわからない場合は、デバイスマネージャを開いて、`Ports > USB Serial Device` を探してください。ここにある COM ポートを使ってください。
+あなたはそれが正しいポートであることを確認することができます：
+
+    avrdude -c avrisp -P COM3 -p atmega32u4
+
+次のような出力が得られるはずです:
+
+    avrdude: AVR device initialized and ready to accept instructions
+
+    Reading | ################################################## | 100% 0.02s
+
+    avrdude: Device signature = 0x1e9587
+
+    avrdude: safemode: Fuses OK
+
+    avrdude done.  Thank you.
+
+私たちのキーボードは `atmega32u4`（共通）を使用しているので、これが指定するチップです。
+以下が完全なコマンドです：
+
+    avrdude -c avrisp -P COM3 -p atmega32u4 -U flash:w:main.hex:i
+
+ボードが `atmega32a`（jj40 など）を使用している場合、コマンドは次のとおりです（最後の追加コードによりヒューズが正しく設定されます）。
+
+	avrdude -c avrisp -P COM3 -p atmega32 -U flash:w:main.hex:i -U hfuse:w:0xD0:m -U lfuse:w:0x0F:m
+
+プログレスバーが表示されてから、以下が表示されるはずです。
+
+    avrdude: verifying ...
+    avrdude: 32768 bytes of flash verified
+
+    avrdude: safemode: Fuses OK
+
+    avrdude done.  Thank you.
+
+これは全てうまく動作したことを示しています。
+ボードが自動的に再起動する場合もありますが、そうでない場合は、Teensy のプラグを抜いてキーボードを接続してください。
+テスト中は、Teensy をキーボードに接続したままにすることができますが、すべてが正常に機能することを確認したら、はんだを外すか、配線を外すことをお勧めします。
+
+SparkFun PocketAVR Programmer や、他の USB Tiny ベースの ISP プログラマを使用している場合は、次のようなものを使用すると良いでしょう。
+
+    avrdude -c usbtiny -P usb -p atmega32u4
+
+#### 上級者向け: ヒューズの変更
+
+Pro Micro に QMK DFU を書き込むなど、ブートローダを切り替える場合は、ブートローダの hex ファイルの書き込みに加えて、ヒューズを変更する必要があります。
+これは、`caterina` (Pro Micro ブートローダ) と `dfu` では起動ルーチンの扱いが異なり、その動作はヒューズによって制御されるからです。
+
+!> これは、ヒューズを変更することは、永久にあなたのコントローラをレンガ化(訳注:日本では文鎮化と呼ぶことが多い、コントローラがまったく無反応になる状態)することができる方法の1つであるため、それは非常に注意が必要な1つの領域です。 
+
+以下は、`atmega32u4`の 5V 16MHz 版（5V Pro Micro など）を想定しています。
+
+`atmega32u4`の DFU の場合、必要なヒューズ設定は次のとおりです:
+
+| ヒューズ | 設定             |
+|----------|------------------|
+| Low      | `0x5E`           |
+| High     | `0xD9` or `0x99` |
+| Extended | `0xC3`           |
+
+High ヒューズは 0xD9 か 0x99 のどちらかになります。
+違いは、0xD9 は QMK Firmware がソフトウェアでも無効化している JTAG を無効化しているのに対し、0x99 は JTAG を無効化していないことです。
+
+これを設定するには、`-U lfuse:w:0x5E:m -U hfuse:w:0xD9:m -U efuse:w:0xC3:m` をコマンドに追加します。
+そうすると、最終的なコマンドは次のようになります。
+
+    avrdude -c avrisp -P COM3 -p atmega32u4 -U flash:w:main.hex:i -U lfuse:w:0x5E:m -U hfuse:w:0xD9:m -U efuse:w:0xC3:m
+
+`atmega32u4`の Caterina では、以下があなたに必要なヒューズの設定です。
+
+| ヒューズ | 設定   |
+|----------|--------|
+| Low      | `0xFF` |
+| High     | `0xD8` |
+| Extended | `0xCB` |
+
+これを設定するには、コマンドに `-U lfuse:w:0xFF:m -U hfuse:w:0xD8:m -U efuse:w:0xCB:m` を追加します。
+これで、最終的なコマンドは次のようになるはずです。
+
+    avrdude -c avrisp -P COM3 -p atmega32u4 -U flash:w:main.hex:i -U lfuse:w:0xFF:m -U hfuse:w:0xD8:m -U efuse:w:0xCB:m
+
+
+別のコントローラーを使用している場合や、別の設定を希望する場合は、この[AVR ヒューズ計算機](http:/www.engbedded.comfusecalc)を使用して、より適切な値を見つけることができます。
+
+## ヘルプ
+
+ご質問・ご不明な点がありましたら、お気軽に[issue を開いてください](https://github.com/qmk/qmk_firmware/issues/new)！