19 files changed, 1024 insertions, 58 deletions
diff --git a/docs/feature_debounce_type.md b/docs/feature_debounce_type.md
index 65b4ea1e53..83ebafe60e 100644
--- a/docs/feature_debounce_type.md
+++ b/docs/feature_debounce_type.md
@@ -1,43 +1,151 @@
-# Debounce algorithm
+# Contact bounce / contact chatter
 
-QMK supports multiple debounce algorithms through its debounce API.
+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
 
-The logic for which debounce method called is below. It checks various defines that you have set in rules.mk
+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 eager algorithm
+        * ```asym_*_defer_*```: key-up is using eager 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```
 
 ```
 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
 
diff --git a/docs/ja/api_development_environment.md b/docs/ja/api_development_environment.md
new file mode 100644
index 0000000000..8dce1ba2fd
--- /dev/null
+++ b/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) に行ってください。
diff --git a/docs/ja/api_development_overview.md b/docs/ja/api_development_overview.md
new file mode 100644
index 0000000000..0612507b4d
--- /dev/null
+++ b/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'])
+
+このメソッドによりユーザはファームウェアのソースをダウンロードすることができます。
diff --git a/docs/ja/api_docs.md b/docs/ja/api_docs.md
new file mode 100644
index 0000000000..b483c045e6
--- /dev/null
+++ b/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。エラーはここで見つけることができます。
diff --git a/docs/ja/api_overview.md b/docs/ja/api_overview.md
new file mode 100644
index 0000000000..18b8eae10f
--- /dev/null
+++ b/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) を調べるべきです。
diff --git a/docs/ja/faq_build.md b/docs/ja/faq_build.md
index 97e1bd8cf7..62c36f2497 100644
--- a/docs/ja/faq_build.md
+++ b/docs/ja/faq_build.md
@@ -145,4 +145,4 @@ ARM ベースのチップ上での 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)とキーボード情報を見てください)。
diff --git a/docs/ja/faq_general.md b/docs/ja/faq_general.md
index a365e380b3..83d1a557bd 100644
--- a/docs/ja/faq_general.md
+++ b/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 チームも支援します。
 
diff --git a/docs/ja/faq_keymap.md b/docs/ja/faq_keymap.md
index 2726e18728..311ebe0e42 100644
--- a/docs/ja/faq_keymap.md
+++ b/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
diff --git a/docs/ja/feature_split_keyboard.md b/docs/ja/feature_split_keyboard.md
index 74b62310fb..1efc98e40f 100644
--- a/docs/ja/feature_split_keyboard.md
+++ b/docs/ja/feature_split_keyboard.md
@@ -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)の中で説明されます。
 
 ## ハードウェア設定
 
diff --git a/docs/ja/how_a_matrix_works.md b/docs/ja/how_a_matrix_works.md
index ff4fbb115d..b6ded186ba 100644
--- a/docs/ja/how_a_matrix_works.md
+++ b/docs/ja/how_a_matrix_works.md
@@ -101,4 +101,4 @@
 - [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 ドキュメント](how_keyboards_work.md)
+- [キーボードの仕組み - QMK ドキュメント](ja/how_keyboards_work.md)
diff --git a/docs/ja/quantum_keycodes.md b/docs/ja/quantum_keycodes.md
new file mode 100644
index 0000000000..ffcc494460
--- /dev/null
+++ b/docs/ja/quantum_keycodes.md
@@ -0,0 +1,20 @@
+# Quantum キーコード
+
+<!---
+  original document: 0.9.55:docs/quantum_keycodes.md
+  git diff 0.9.55 HEAD -- docs/quantum_keycodes.md | cat
+-->
+
+Quantum キーコードにより、カスタムアクションを定義することなく、基本的なものが提供するものより簡単にキーマップをカスタマイズすることができます。
+
+quantum 内の全てのキーコードは `0x0000` と `0xFFFF` の間の数値です。`keymap.c` の中では、関数やその他の特別な場合があるように見えますが、最終的には C プリプロセッサによってそれらは単一の4バイト整数に変換されます。QMK は標準的なキーコードのために `0x0000` から `0x00FF` を予約しています。これらは、`KC_A`、`KC_1` および `KC_LCTL` のようなキーコードで、USB HID 仕様で定義された基本的なキーです。
+
+このページでは、高度な quantum 機能を実装するために使われる `0x00FF` と `0xFFFF` の間のキーコードを説明します。独自のカスタムキーコードを定義する場合は、それらもこの範囲に配置されます。
+
+## QMK キーコード :id=qmk-keycodes
+
+| キー           | エイリアス | 説明                                                   |
+|----------------|------------|--------------------------------------------------------|
+| `RESET`        |            | 書き込みのために、キーボードを bootloader モードにする |
+| `DEBUG`        |            | デバッグモードの切り替え                               |
+| `EEPROM_RESET` | `EEP_RST`  | キーボードの EEPROM (永続化メモリ) を再初期化する      |
diff --git a/docs/ja/reference_configurator_support.md b/docs/ja/reference_configurator_support.md
new file mode 100644
index 0000000000..0151731e99
--- /dev/null
+++ b/docs/ja/reference_configurator_support.md
@@ -0,0 +1,202 @@
+# QMK Configurator でのキーボードのサポート
+
+<!---
+  original document: 0.9.46:docs/reference_configurator_support.md
+  git diff 0.9.46 HEAD -- docs/reference_configurator_support.md | cat
+-->
+
+このページは [QMK Configurator](https://config.qmk.fm/) でキーボードを適切にサポートする方法について説明します。
+
+
+## Configurator がキーボードを理解する方法
+
+Configurator がキーボードをどのように理解するかを理解するには、最初にレイアウトマクロを理解する必要があります。この演習では、17キーのテンキー PCB を想定します。これを `numpad` と呼びます。
+
+```
+|---------------|
+|NLk| / | * | - |
+|---+---+---+---|
+|7  |8  |9  | + |
+|---+---+---|   |
+|4  |5  |6  |   |
+|---+---+---+---|
+|1  |2  |3  |Ent|
+|-------+---|   |
+|0      | . |   |
+|---------------|
+```
+
+?> レイアウトマクロの詳細については、[QMK の理解: マトリックススキャン](ja/understanding_qmk.md?id=matrix-scanning) と [QMK の理解: マトリックスから物理レイアウトへのマップ](ja/understanding_qmk.md?id=matrix-to-physical-layout-map) を見てください。
+
+Configurator の API はキーボードの `.h` ファイルを `qmk_firmware/keyboards/<keyboard>/<keyboard>.h` から読み取ります。numpad の場合、このファイルは `qmk_firmware/keyboards/numpad/numpad.h` です:
+
+```c
+#pragma once
+
+#define LAYOUT( \
+    k00, k01, k02, k03, \
+    k10, k11, k12, k13, \
+    k20, k21, k22,      \
+    k30, k31, k32, k33, \
+    k40,      k42       \
+  ) { \
+    { k00, k01,   k02, k03   }, \
+    { k10, k11,   k12, k13   }, \
+    { k20, k21,   k22, KC_NO }, \
+    { k30, k31,   k32, k33   }, \
+    { k40, KC_NO, k42, KC_NO }  \
+}
+```
+
+QMK は `KC_NO` を使って、スイッチマトリックス内のスイッチがない場所を指定します。デバッグが必要な場合に、このセクションを読みやすくするために、`XXX`、`___`、`____` を略記として使うこともあります。通常は `.h` ファイルの先頭近くで定義されます:
+
+```c
+#pragma once
+
+#define XXX KC_NO
+
+#define LAYOUT( \
+    k00, k01, k02, k03, \
+    k10, k11, k12, k13, \
+    k20, k21, k22,      \
+    k30, k31, k32, k33, \
+    k40,      k42       \
+  ) { \
+    { k00, k01, k02, k03 }, \
+    { k10, k11, k12, k13 }, \
+    { k20, k21, k22, XXX }, \
+    { k30, k31, k32, k33 }, \
+    { k40, XXX, k42, XXX }  \
+}
+```
+
+!> この使用方法はキーマップマクロと異なります。キーマップマクロはほとんど常に`KC_NO`については`XXXXXXX` (7つの大文字の X) を、`KC_TRNS` については `_______` (7つのアンダースコア)を使います。
+
+!> ユーザの混乱を防ぐために、`KC_NO` を使うことをお勧めします。
+
+レイアウトマクロは、キーボードに17個のキーがあり、4列それぞれが5行に配置されていることを Configurator に伝えます。スイッチの位置は、0から始まる `k<row><column>` という名前が付けられています。キーマップからキーコードを受け取る上部セクションと、マトリックス内の各キーの位置を指定する下部セクションとが一致する限り、名前自体は実際には問題ではありません。
+
+物理的なキーボードに似た形でキーボードを表示するには、それぞれのキーの物理的な位置とサイズをスイッチマトリックスに結びつけることを Configurator に伝える JSON ファイルを作成する必要があります。
+
+## JSON ファイルのビルド
+
+JSON ファイルをビルドする最も簡単な方法は、[Keyboard Layout Editor](http://www.keyboard-layout-editor.com/) ("KLE") でレイアウトを作成することです。この Raw Data を QMK tool に入れて、Configurator が読み出して使用する JSON ファイルに変換します。KLE は numpad レイアウトをデフォルトで開くため、Getting Started の説明を削除し、残りを使います。
+
+レイアウトが望み通りのものになったら、KLE の Raw Data タブに移動し、内容をコピーします:
+
+```
+["Num Lock","/","*","-"],
+["7\nHome","8\n↑","9\nPgUp",{h:2},"+"],
+["4\n←","5","6\n→"],
+["1\nEnd","2\n↓","3\nPgDn",{h:2},"Enter"],
+[{w:2},"0\nIns",".\nDel"]
+```
+
+このデータを JSON に変換するには、[QMK KLE-JSON Converter](https://qmk.fm/converter/) に移動し、Raw Data を Input フィールド に貼り付け、Convert ボタンをクリックします。しばらくすると、JSON データが Output フィールドに表示されます。内容を新しいテキストドキュメントにコピーし、ドキュメントに `info.json` という名前を付け、`numpad.h` を含む同じフォルダに保存します。
+
+`keyboard_name` オブジェクトを使ってキーボードの名前を設定します。説明のために、各キーのオブジェクトを各行に配置します。これはファイルを人間が読みやすいものにするためのもので、Configurator の機能には影響しません。
+
+```json
+{
+    "keyboard_name": "Numpad",
+    "url": "",
+    "maintainer": "qmk",
+    "tags": {
+        "form_factor": "numpad"
+    },
+    "width": 4,
+    "height": 5,
+    "layouts": {
+        "LAYOUT": {
+            "layout": [
+                {"label":"Num Lock", "x":0, "y":0},
+                {"label":"/", "x":1, "y":0},
+                {"label":"*", "x":2, "y":0},
+                {"label":"-", "x":3, "y":0},
+                {"label":"7", "x":0, "y":1},
+                {"label":"8", "x":1, "y":1},
+                {"label":"9", "x":2, "y":1},
+                {"label":"+", "x":3, "y":1, "h":2},
+                {"label":"4", "x":0, "y":2},
+                {"label":"5", "x":1, "y":2},
+                {"label":"6", "x":2, "y":2},
+                {"label":"1", "x":0, "y":3},
+                {"label":"2", "x":1, "y":3},
+                {"label":"3", "x":2, "y":3},
+                {"label":"Enter", "x":3, "y":3, "h":2},
+                {"label":"0", "x":0, "y":4, "w":2},
+                {"label":".", "x":2, "y":4}
+            ]
+        }
+    }
+}
+```
+
+`layouts` オブジェクトにはキーボードの物理レイアウトを表すデータが含まれます。このオブジェクトには `LAYOUT` という名前のオブジェクトがあり、このオブジェクト名は `numpad.h` のレイアウトマクロの名前と一致する必要があります。`LAYOUT` オブジェクト自体には `layout` という名前のオブジェクトがあります。このオブジェクトにはキーボードの物理キーごとに 1つの JSON オブジェクトが以下の形式で含まれています: