Japanese translation of newbs.md and related documents. (qmk#7300)

* add docs/ja/newbs.md

* Update docs/ja/newbs.md

* Updated newbs.md

* Updated newbs.md

* add docs/ja/newbs_learn_more_resources.md

* Update docs/ja/newbs.md

* update link info

他人まかせ :-)

* add docs/ja/newbs_testing_debugging.md

* Update docs/ja/newbs_testing_debugging.md

* Update docs/ja/newbs_testing_debugging.md

* add docs/ja/newbs_building_firmware.md

* update docs/ja/newbs_building_firmware.md

* Update docs/ja/newbs_testing_debugging.md

* Update docs/ja/newbs_building_firmware.md

* Update docs/ja/newbs_building_firmware.md

* Japanese translation of docs/newbs_getting_started.md

* renamed: docs/QMK入門.md -> docs/ja/newbs_getting_started.md

* update docs/ja/newbs_getting_started.md

* add ja/newbs_best_practices.md

There are no plans to translate this file.
With the completion of qmk#7231, I will open a new PR.

* Update docs/ja/newbs_getting_started.md

* Update docs/ja/newbs_getting_started.md

* Update docs/ja/newbs_getting_started.md

* Update docs/ja/newbs_getting_started.md

* Update docs/ja/newbs_getting_started.md

* Update docs/ja/newbs_getting_started.md

* Update docs/ja/newbs_getting_started.md

* Update docs/ja/newbs_getting_started.md

* Update docs/ja/newbs_getting_started.md

* Update docs/ja/newbs_getting_started.md

* Update docs/ja/newbs_getting_started.md

* Update docs/ja/newbs_getting_started.md

* Update docs/ja/newbs_getting_started.md

* Update docs/ja/newbs_getting_started.md

* Update docs/ja/newbs_getting_started.md

* Update docs/ja/newbs_getting_started.md

* Update docs/ja/newbs_getting_started.md

* Update docs/ja/newbs_getting_started.md

* Update docs/ja/newbs_getting_started.md

* Update docs/ja/newbs_getting_started.md

* Update docs/ja/newbs_getting_started.md

* Update docs/ja/newbs_getting_started.md

* Update docs/ja/newbs_getting_started.md

* add docs/ja/newbs_flashing.md

* add docs/ja/newbs_building_firmware_configurator.md

* Update docs/ja/newbs_getting_started.md

* Update docs/ja/newbs_getting_started.md

* Update docs/ja/newbs_building_firmware_configurator.md

* Update docs/ja/newbs_building_firmware_configurator.md

* Update docs/ja/newbs_building_firmware_configurator.md

* Update docs/ja/newbs_building_firmware_configurator.md

* Update docs/ja/newbs_building_firmware_configurator.md

* Update docs/ja/newbs_building_firmware_configurator.md

* Update docs/ja/newbs_flashing.md

* Update docs/ja/newbs_building_firmware_configurator.md

* Update docs/ja/newbs_building_firmware_configurator.md

* Update docs/ja/newbs_building_firmware_configurator.md

* Update docs/ja/newbs_building_firmware_configurator.md

* Update docs/ja/newbs_building_firmware_configurator.md

* Update docs/ja/newbs_building_firmware_configurator.md

* Update docs/ja/newbs_building_firmware_configurator.md

* Update docs/ja/newbs_building_firmware_configurator.md

* Update docs/ja/newbs_building_firmware_configurator.md

* Update docs/ja/newbs_building_firmware_configurator.md

* Update docs/ja/newbs_building_firmware_configurator.md

* Update docs/ja/newbs_building_firmware_configurator.md

* Update docs/ja/newbs_flashing.md

* Update docs/ja/newbs_flashing.md

* Update docs/ja/newbs_flashing.md

* Update docs/ja/newbs_flashing.md

* Update docs/ja/newbs_flashing.md

* Update docs/ja/newbs_flashing.md

* Update docs/ja/newbs_flashing.md

* Update docs/ja/newbs_flashing.md

* Update docs/ja/newbs_flashing.md

* Update docs/ja/newbs_flashing.md

* update docs/ja/newbs_flashing.md

* change original log format

* update docs/ja/newbs_flashing.md

* Update docs/ja/newbs_getting_started.md

* Update docs/ja/newbs_building_firmware_configurator.md

* Update docs/ja/newbs_building_firmware_configurator.md

* Update docs/ja/newbs_flashing.md

* Update docs/ja/newbs_flashing.md

* Update docs/ja/newbs_flashing.md

* Update docs/ja/newbs_flashing.md

* Update docs/ja/newbs_flashing.md

* Update docs/ja/newbs_flashing.md

* Update docs/ja/newbs_flashing.md

* Update docs/ja/newbs_flashing.md

* Update docs/ja/newbs_flashing.md

* Update docs/ja/newbs_flashing.md

* Update docs/ja/newbs_flashing.md

* Update docs/ja/newbs_flashing.md

* Update docs/ja/newbs_flashing.md

* Update docs/ja/newbs_flashing.md

* Update docs/ja/newbs_flashing.md

* Update docs/ja/newbs_flashing.md

* Update docs/ja/newbs_flashing.md

* Update docs/ja/newbs_flashing.md

* copy docs/_langs.md and docs/index.html from qmk#7248

Co-Authored-By: shela <[email protected]>
Co-Authored-By: takashiski <[email protected]>
Co-Authored-By: Takuya Urakawa <[email protected]>

docs/_langs.md

@@ -5,3 +5,4 @@
   - [:fr: Français](/fr-fr/)
   - [:he: עברית](/he-il/)
   - [:ru: Русский](/ru-ru/)
+  - [:ja: 日本語](/ja/)

docs/index.html

@@ -41,11 +41,13 @@
         placeholder: {
           '/es/': 'Buscar',
           '/zh-cn/': '搜索',
+          '/ja/': '検索',
           '/': 'Search'
         },
         noData: {
           '/es/': '¡Ningún resultado!',
           '/zh-cn/': '没有结果!',
+          '/ja/': '見つかりません!',
           '/': 'No results!'
         },
         depth: 6

docs/ja/newbs.md

@@ -0,0 +1,40 @@
+# QMK 初心者ガイド
+
+<!---
+  original document: ed0575fc8:docs/newbs.md
+  $ git diff ed0575fc8 HEAD docs/newbs.md
+-->
+
+QMK は、メカニカルキーボード用の強力なオープンソースファームウェアです。
+QMK を使用して、シンプルかつ強力な方法でキーボードをカスタマイズできます。
+完全な初心者からプログラマーに至るまで、あらゆるスキルレベルの人々が QMK を使用してキーボードをカスタマイズしています。
+このガイドは、あなたのスキルにかかわらず、同じことを行う手助けをします。
+
+お使いのキーボードで QMK を実行できるかどうか不明ですか？
+もし作成したキーボードがメカニカルキーボードの場合、実行できる可能性が高いです。
+QMK は[多くの趣味のキーボード](http://qmk.fm/keyboards/)をサポートしているため、もし現在のキーボードで QMK を実行できない場合でも、ニーズに合ったキーボードを見つけるのに問題はないはずです。
+
+## 概要
+
+このガイドには7つの主要なセクションがあります。
+
+* [はじめに](newbs_getting_started.md)
+* [コマンドラインを使用して初めてのファームウェアを構築する](newbs_building_firmware.md)
+* [オンライン GUI を使用して初めてのファームウェアを構築する](newbs_building_firmware_configurator.md)
+* [ファームウェアを書きこむ](newbs_flashing.md)
+* [テストとデバッグ](newbs_testing_debugging.md)
+* [Git の最良の慣行](newbs_best_practices.md)
+* [さらに学ぶための学習リソース](newbs_learn_more_resources.md)
+
+このガイドは、これまでソフトウェアをコンパイルしたことがない人を支援することに特化しています。
+その観点から選択と推奨を行います。
+これらの手順の多くには代替方法があり、これらの代替方法のほとんどをサポートしています。
+タスクを達成する方法について疑問がある場合は、[案内を求めることができます](getting_started_getting_help.md)。
+
+## 追加のリソース(英語)
+
+* [Thomas Baart's QMK Basics Blog](https://thomasbaart.nl/category/mechanical-keyboards/firmware/qmk/qmk-basics/) – 新規ユーザ視点から見た QMK ファームウェアの基本的な使用方法をカバーしたユーザ作成のブログ。
+
+## 追加のリソース(日本語)
+
+_日本語のリソース情報を募集中です。_

docs/ja/newbs_best_practices.md

@@ -0,0 +1,168 @@
+# Best Practices
+
+<!---
+  original document: ed0575fc8:docs/newbs_best_practices.md
+  $ git diff ed0575fc8 HEAD docs/newbs_best_practices.md
+-->
+
+## Or, "How I Learned to Stop Worrying and Love Git."
+
+This document aims to instruct novices in the best ways to have a smooth experience in contributing to QMK. We will walk through the process of contributing to QMK, detailing some ways to make this task easier, and then later we'll break some things in order to teach you how to fix them.
+
+This document assumes a few things:
+
+1. You have a GitHub account, and have [forked the qmk_firmware repository](getting_started_github.md) to your account.
+2. You've [set up your build environment](newbs_getting_started.md?id=environment-setup).
+
+
+## Your fork's master: Update Often, Commit Never
+
+It is highly recommended for QMK development, regardless of what is being done or where, to keep your `master` branch updated, but ***never*** commit to it. Instead, do all your changes in a development branch and issue pull requests from your branches when you're developing.
+
+To reduce the chances of merge conflicts &mdash; instances where two or more users have edited the same part of a file concurrently &mdash; keep your `master` branch relatively up-to-date, and start any new developments by creating a new branch.
+
+### Updating your master branch
+
+To keep your `master` branch updated, it is recommended to add the QMK Firmware repository ("repo") as a remote repository in git. To do this, open your Git command line interface and enter:
+
+```
+git remote add upstream https://github.com/qmk/qmk_firmware.git
+```
+
+To verify that the repository has been added, run `git remote -v`, which should return the following:
+
+```
+$ git remote -v
+origin  https://github.com/<your_username>/qmk_firmware.git (fetch)
+origin  https://github.com/<your_username>/qmk_firmware.git (push)
+upstream        https://github.com/qmk/qmk_firmware.git (fetch)
+upstream        https://github.com/qmk/qmk_firmware.git (push)
+```
+
+Now that this is done, you can check for updates to the repo by running `git fetch upstream`. This retrieves the branches and tags &mdash; collectively referred to as "refs" &mdash; from the QMK repo, which now has the nickname `upstream`. We can now compare the data on our fork `origin` to that held by QMK.
+
+To update your fork's master, run the following, hitting the Enter key after each line:
+
+```
+git checkout master
+git fetch upstream
+git pull upstream master
+git push origin master
+```
+
+This switches you to your `master` branch, retrieves the refs from the QMK repo, downloads the current QMK `master` branch to your computer, and then uploads it to your fork.
+
+### Making Changes
+
+To make changes, create a new branch by entering:
+
+```
+git checkout -b dev_branch
+git push --set-upstream origin dev_branch
+```
+
+This creates a new branch named `dev_branch`, checks it out, and then saves the new branch to your fork. The `--set-upstream` argument tells git to use your fork and the `dev_branch` branch every time you use `git push` or `git pull` from this branch. It only needs to be used on the first push; after that, you can safely use `git push` or `git pull`, without the rest of the arguments.
+
+!> With `git push`, you can use `-u` in place of `--set-upstream` &mdash; `-u` is an alias for `--set-upstream`.
+
+You can name your branch nearly anything you want, though it is recommended to name it something related to the changes you are going to make.
+
+By default `git checkout -b` will base your new branch on the branch that is checked out. You can base your new branch on an existing branch that is not checked out by adding the name of the existing branch to the command:
+
+```
+git checkout -b dev_branch master
+```
+
+Now that you have a development branch, open your text editor and make whatever changes you need to make. It is recommended to make many small commits to your branch; that way, any change that causes issues can be more easily traced and undone if needed. To make your changes, edit and save any files that need to be updated, add them to Git's *staging area*, and then commit them to your branch:
+
+```
+git add path/to/updated_file
+git commit -m "My commit message."
+```
+
+`git add` adds files that have been changed to Git's *staging area*, which is Git's "loading zone." This contains the changes that are going to be *committed* by `git commit`, which saves the changes to the repo. Use descriptive commit messages so you can know what was changed at a glance.
+
+!> If you've changed a lot of files, but all the files are part of the same change, you can use `git add .` to add all the changed files that are in your current directory, rather than having to add each file individually.
+
+### Publishing Your Changes
+
+The last step is to push your changes to your fork. To do this, enter `git push`. Git now publishes the current state of `dev_branch` to your fork.
+
+
+## Resolving Merge Conflicts
+
+Sometimes when your work in a branch takes a long time to complete, changes that have been made by others conflict with changes you have made to your branch when you open a pull request. This is called a *merge conflict*, and is what happens when multiple people edit the same parts of the same files.
+
+### Rebasing Your Changes
+
+A *rebase* is Git's way of taking changes that were applied at one point, reversing them, and then applying the same changes to another point. In the case of a merge conflict, you can rebase your branch to grab the changes that were made between when you created your branch and the present time.
+
+To start, run the following:
+
+```
+git fetch upstream
+git rev-list --left-right --count HEAD...upstream/master
+```
+
+The `git rev-list` command entered here returns the number of commits that differ between the current branch and QMK's master branch. We run `git fetch` first to make sure we have the refs that represent the current state of the upstream repo. The output of the `git rev-list` command entered returns two numbers:
+
+```
+$ git rev-list --left-right --count HEAD...upstream/master
+7       35
+```
+
+The first number represents the number of commits on the current branch since it was created, and the second number is the number of commits made to `upstream/master` since the current branch was created, and thus, the changes that are not recorded in the current branch.
+
+Now that the current states of both the current branch and the upstream repo are known, we can start a rebase operation:
+
+```
+git rebase upstream/master
+```
+
+This tells Git to undo the commits on the current branch, and then reapply them against QMK's master branch.
+
+```
+$ git rebase upstream/master
+First, rewinding head to replay your work on top of it...
+Applying: Commit #1
+Using index info to reconstruct a base tree...
+M       conflicting_file_1.txt
+Falling back to patching base and 3-way merge...
+Auto-merging conflicting_file_1.txt
+CONFLICT (content): Merge conflict in conflicting_file_1.txt
+error: Failed to merge in the changes.
+hint: Use 'git am --show-current-patch' to see the failed patch
+Patch failed at 0001 Commit #1
+
+Resolve all conflicts manually, mark them as resolved with
+"git add/rm <conflicted_files>", then run "git rebase --continue".
+You can instead skip this commit: run "git rebase --skip".
+To abort and get back to the state before "git rebase", run "git rebase --abort".
+```
+
+This tells us that we have a merge conflict, and gives the name of the file with the conflict. Open the conflicting file in your text editor, and somewhere in the file, you'll find something like this:
+
+```
+<<<<<<< HEAD
+<p>For help with any issues, email us at [email protected].</p>
+=======
+<p>Need help? Email [email protected].</p>
+>>>>>>> Commit #1
+```
+
+The line `<<<<<<< HEAD` marks the beginning of a merge conflict, and the `>>>>>>> Commit #1` line marks the end, with the conflicting sections separated by `=======`. The part on the `HEAD` side is from the QMK master version of the file, and the part marked with the commit message is from the current branch and commit.
+
+Because Git tracks *changes to files* rather than the contents of the files directly, if Git can't find the text that was in the file previous to the commit that was made, it won't know how to edit the file. Re-editing the file will solve the conflict. Make your changes, and then save the file.
+
+```
+<p>Need help? Email [email protected].</p>
+```
+
+Now run:
+
+```
+git add conflicting_file_1.txt
+git rebase --continue
+```
+
+Git logs the changes to the conflicting file, and continues applying the commits from our branch until it reaches the end.

docs/ja/newbs_building_firmware.md

@@ -0,0 +1,98 @@
+# 初めてのファームウェアを構築する(コマンドライン版)
+
+<!---
+  original document: ed0575fc8:docs/newbs_building_firmware.md
+  $ git diff ed0575fc8 HEAD docs/newbs_building_firmware.md
+-->
+
+ビルド環境をセットアップしたので、カスタムファームウェアのビルドを開始する準備ができました。
+ガイドのこのセクションでは、ファイルマネージャ、テキストエディタ、ターミナルウィンドウの3つのプログラム間を行き来します。
+キーボードファームウェアが完成して満足するまで、この3つすべてを開いたままにします。
+
+ガイドの最初の部分を読んだ後でターミナルウィンドウを閉じて再度開いていた場合は、ターミナルが正しいディレクトリにあるように `cd qmk_firmware` を忘れないでください。
+
+## キーマップフォルダに移動する
+
+あなたのキーボードの `keymaps`フォルダに移動することから始めます。
+
+macOS または Windows を使用している場合は、キーマップフォルダを簡単に開くために使用できるコマンドがあります。
+
+### macOS:
+
+``` open keyboards/<keyboard_folder>/keymaps ```
+
+### Windows:
+
+``` start .\\keyboards\\<keyboard_folder>\\keymaps ```
+
+## `default` キーマップのコピーを作成する
+
+`keymaps` フォルダを開いたら、`default`フォルダのコピーを作成します。
+フォルダには、あなたの GitHub でのユーザー名と同じ名前を付けることを強くお勧めしますが、小文字、数字、アンダースコアのみが含まれている限り、任意の名前を使用できます。
+
+この手順を自動化するために、`new_keymap.sh`スクリプトを実行する方法もあります。
+
+`qmk_firmware/util` ディレクトリに移動して、次を入力します。
+
+```
+./new_keymap.sh <keyboard path> <username>
+```
+
+たとえば、John という名前のユーザーが 1up60hse の新しいキーマップを作成しようとするには、次のように入力します。
+
+```
+./new_keymap.sh 1upkeyboards/1up60hse john
+```
+
+## あなたの好みのテキストエディタで `keymap.c` を開く
+
+`keymap.c`を開きます。
+このファイル内には、キーボードの動作を制御する構造があります。
+`keymap.c`の上部には、キーマップを読みやすくする `define` と `enum` があります。
+さらに下には、次のような行があります。
+
+    const uint16_t PROGMEM keymaps[][MATRIX_ROWS][MATRIX_COLS] = {
+
+この行はレイヤーのリストの開始を表わしています。
+その下には、`LAYOUT` または `KEYMAP` のいずれかを含む行があり、これらの行はレイヤーの開始を表わしています。
+その行の下には、その特定のレイヤーを構成するキーのリストがあります。
+
+!> キーマップファイルを編集するときは、カンマを追加したり削除したりしないように注意してください。そうするとファームウェアのコンパイルができなくなり、余分であったり欠落していたりするカンマがどこにあるのかを容易に把握できない場合があります。
+
+## 好みに合わせてレイアウトをカスタマイズ
+
+納得のいくまでこのステップを繰り返します。
+気になる点をひとつづつ変更して試すのもよし、全部作りなおすのもよし。
+あるレイヤー全体が必要ない場合はレイヤーを削除することもでき、必要があれば、合計 32 個までレイヤーを追加することもできます。
+ここで定義できる内容については、次のドキュメントを参照してください。
+
+* [キーコード](keycodes.md)
+* [機能](features.md)
+* [FAQ](faq.md)
+
+?> キーマップがどのように機能するかを感じながら、各変更を小さくしてください。大きな変更は、発生する問題のデバッグを困難にします。
+
+## ファームウェアをビルドする
+
+キーマップの変更が完了したら、ファームウェアをビルドする必要があります。これを行うには、ターミナルウィンドウに戻り、ビルドコマンドを実行します:
+
+    make <my_keyboard>:<my_keymap>
+
+たとえば、キーマップの名前が "xyverz" で、rev5 planck のキーマップを作成している場合、次のコマンドを使用します:
+
+    make planck/rev5:xyverz
+
+これがコンパイルされる間、どのファイルがコンパイルされているかを知らせる多くの出力が画面に表示されます。
+次のような出力で終わるはずです。
+
+```
+Linking: .build/planck_rev5_xyverz.elf                                              [OK]
+Creating load file for flashing: .build/planck_rev5_xyverz.hex                      [OK]
+Copying planck_rev5_xyverz.hex to qmk_firmware folder                               [OK]
+Checking file size of planck_rev5_xyverz.hex                                        [OK]
+ * File size is fine - 18392/28672
+```
+
+## ファームウェアを書きこむ
+
+[「ファームウェアを書きこむ」](newbs_flashing.md) に移動して、キーボードに新しいファームウェアを書き込む方法を学習します。