付録G: Rustの作られ方と“Nightly Rust”の和訳をアップデート

rust-lang/book@19c40bf

Author: shinmili

src/appendix-07-nightly-rust.md

@@ -1,21 +1,15 @@
 <!--
-# Appendix G - How Rust is Made and “Nightly Rust”
+## Appendix G - How Rust is Made and “Nightly Rust”
 -->
 
 ## 付録G: Rustの作られ方と“Nightly Rust”
 
 <!--
 This appendix is about how Rust is made and how that affects you as a Rust
-developer. We mentioned that the output in this book was generated by stable
-Rust 1.21.0, but any examples that compile should continue to compile in any
-stable version of Rust greater than that. This section is to explain how we
-ensure this is true!
+developer.
 -->
 
 この付録は、Rustのでき方と、それがRust開発者としてあなたにどう影響するかについてです。
-この本の出力は安定版Rust 1.21.0で生成されていますが、コンパイルできるいかなる例も、
-それより新しいRustのどんな安定版でもコンパイルでき続けられるはずということに触れました。
-この節は、これが本当のことであると保証する方法を説明します！
 
 <!--
 ### Stability Without Stagnation
@@ -283,8 +277,8 @@ install nightly, for example:
 rustupは、グローバルかプロジェクトごとにRustのリリースチャンネルを変更しやすくしてくれます。
 標準では、安定版のRustがインストールされます。例えば、ナイトリをインストールするには:
 
-```text
-$ rustup install nightly
+```console
+$ rustup toolchain install nightly
 ```
 
 <!--
@@ -316,7 +310,7 @@ nightly toolchain as the one `rustup` should use when you’re in that directory
 そうするためには、そのプロジェクトのディレクトリで`rustup override`を使用して、そのディレクトリにいる時に、
 `rustup`が使用するべきツールチェーンとしてナイトリ版のものをセットします。
 
-```text
+```console
 $ cd ~/projects/needs-nightly
 $ rustup override set nightly
 ```
@@ -350,7 +344,7 @@ Rustに改善を行いたければ、RFCと呼ばれる提案を書き上げま
 Anyone can write RFCs to improve Rust, and the proposals are reviewed and
 discussed by the Rust team, which is comprised of many topic subteams. There’s
 a full list of the teams [on Rust’s
-website](https://www.rust-lang.org/en-US/team.html), which includes teams for
+website](https://www.rust-lang.org/governance), which includes teams for
 each area of the project: language design, compiler implementation,
 infrastructure, documentation, and more. The appropriate team reads the
 proposal and the comments, writes some comments of their own, and eventually,
@@ -367,12 +361,12 @@ If the feature is accepted, an issue is opened on the Rust repository, and
 someone can implement it. The person who implements it very well may not be the
 person who proposed the feature in the first place! When the implementation is
 ready, it lands on the `master` branch behind a feature gate, as we discussed
-in the “Unstable Features” section.
+in the [“Unstable Features”](#unstable-features) section.
 -->
 
 機能が受け入れられれば、Rustリポジトリでissueが開かれ、誰かがそれを実装します。うまく実装できる人は、
 そもそもその機能を提案した人ではないかもしれません！実装の準備ができたら、
-「安定しない機能」節で議論したように、機能ゲートの背後の`master`に着地します。
+[「安定しない機能」](#安定しない機能)節で議論したように、機能ゲートの背後の`master`に着地します。
 
 <!--
 After some time, once Rust developers who use nightly releases have been able