Merge pull request #705 from reactjs/ci-enable-textlint

Enable Textlint in GitHub Actions

.github/workflows/site_lint.yml

@@ -25,3 +25,6 @@ jobs:
 
       - name: Lint codebase
         run: yarn ci-check
+
+      - name: Textlint (Japanese)
+        run: yarn textlint

src/content/blog/2023/03/16/introducing-react-dev.md

@@ -464,7 +464,7 @@ export default function PackingList() {
 
 各 API ページは少なくとも*リファレンス*と*使用法*の 2 つのセグメントに分かれていることに気付くでしょう。
 
-[リファレンス](/reference/react/useState#reference)は、API の引数と戻り値をリストアップすることによって、正式な API シグネチャを説明します。簡潔ですが、その API に慣れていない場合は少し抽象的に感じることがあります。API が何をするのかは説明しますが、我々がどのように使用するのかは説明しません。
+[リファレンス](/reference/react/useState#reference)は、API の引数と返り値をリストアップすることによって、正式な API シグネチャを説明します。簡潔ですが、その API に慣れていない場合は少し抽象的に感じることがあります。API が何をするのかは説明しますが、我々がどのように使用するのかは説明しません。
 
 [使用法](/reference/react/useState#usage)では、実際にどのようにこの API を使用するのかを、同僚や友人が説明するような形で示します。これは、**React チームが各 API を使用するために意図した標準的なシナリオ**を示しています。色分けされたスニペット、異なる API を一緒に使用するサンプル、コピーペーストできるレシピも追加しました：
 

src/content/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023.md

@@ -68,7 +68,7 @@ React Forget の目標は、React アプリがデフォルトでちょうどよ
 
 コンパイラのコアは、Babel からほぼ完全に切り離されています。コアコンパイラ API は（大まかには）古い AST から新しい AST への変換（ソース位置データを保持しながら）を行うものです。内部では、カスタムコード表現や変換パイプラインを使用して、低レベルのセマンティック解析を行います。ただし、コンパイラへの主要な公開インターフェースは、Babel やその他のビルドシステムプラグインを通すものです。テストのしやすさのために現在 Babel プラグインを作っており、これはコンパイラを呼び出して各関数の新バージョンを生成し元の関数と入れ替える作業を行う、薄いラッパとなっています。
 
-過去数ヶ月間でコンパイラをリファクタリングする中で、私たちは条件分岐、ループ、再代入、ミューテーションなどによる複雑性を確実に扱えるよう、コアコンパイルモデルを洗練させることに焦点を当ててきました。ただし JavaScript には、if/else、三項演算子、for、for-in、for-of など、それらの機能を表現する方法がたくさんあります。最初から言語の全てをサポートしようとすると、コアモデルを検証できる時期が遅れてしまったことでしょう。そのかわり、私たちは言語の小さいながらも代表的なサブセットから始めました。`let/const`、`if/else`、`for` ループ、オブジェクト、配列、プリミティブ、関数呼び出し、その他いくつかの機能です。コアモデルに対する自信を得て、内部の抽象化を洗練させながら、サポートされる言語サブセットの範囲を拡大していきました。また、まだサポートしていない構文について明確化し、サポートされていない入力に対しては診断情報をログに記録しつつコンパイルをスキップするようにしました。Meta のコードベースでコンパイラを試すためのユーティリティが存在し、サポートされていない中で最も一般的な機能を見つけ出し、それらを次に優先するよう決めることができるようになっています。言語全体をサポートするまで、段階的にサポート範囲の拡大を続けていく予定です。
+過去数ヶ月間でコンパイラをリファクタリングする中で、私たちは条件分岐、ループ、再代入、ミューテーションなどによる複雑性を確実に扱えるよう、コアコンパイルモデルを洗練させることに焦点を当ててきました。ただし JavaScript には、if/else、三項演算子、for、for-in、for-of など、それらの機能を表現する方法がたくさんあります。最初から言語のすべてをサポートしようとすると、コアモデルを検証できる時期が遅れてしまったことでしょう。そのかわり、私たちは言語の小さいながらも代表的なサブセットから始めました。`let/const`、`if/else`、`for` ループ、オブジェクト、配列、プリミティブ、関数呼び出し、その他いくつかの機能です。コアモデルに対する自信を得て、内部の抽象化を洗練させながら、サポートされる言語サブセットの範囲を拡大していきました。また、まだサポートしていない構文について明確化し、サポートされていない入力に対しては診断情報をログに記録しつつコンパイルをスキップするようにしました。Meta のコードベースでコンパイラを試すためのユーティリティが存在し、サポートされていない中で最も一般的な機能を見つけ出し、それらを次に優先するよう決めることができるようになっています。言語全体をサポートするまで、段階的にサポート範囲の拡大を続けていく予定です。
 
 React コンポーネント内のプレーンな JavaScript をリアクティブにするには、コードが実行していることを正確に理解できる、セマンティクスを深く理解したコンパイラが必要です。このアプローチを取ることで、ドメイン固有言語に制限されるのではなく、JavaScript 言語のすべての表現力を使ってプロダクトコードを記述できる、JavaScript 内リアクティビティシステムを作成しています。
 

src/content/community/versioning-policy.md

@@ -4,7 +4,7 @@ title: バージョニングポリシー
 
 <Intro>
 
-React の全ての安定版ビルドは広範なテストに通過しており、セマンティックバージョニング (semver) に従います。また、実験的機能に対する早期フィードバックを促すため、不安定版のリリースチャンネルも提供されています。このページでは、React の各リリースで期待できることについて説明します。
+React のすべての安定版ビルドは広範なテストに通過しており、セマンティックバージョニング (semver) に従います。また、実験的機能に対する早期フィードバックを促すため、不安定版のリリースチャンネルも提供されています。このページでは、React の各リリースで期待できることについて説明します。
 
 </Intro>
 

src/content/learn/importing-and-exporting-components.md

@@ -149,7 +149,7 @@ JavaScript には値をエクスポートする主な方法が 2 つあります
 
 ## 同じファイルから複数のコンポーネントをエクスポート・インポートする {/*exporting-and-importing-multiple-components-from-the-same-file*/}
 
-ギャラリーではなく、`Profile` を 1 つだけを表示したい場合はどうでしょう。`Profile` コンポーネントもエクスポートすればいいのです。しかし、`Gallery.js` にはすでにデフォルトエクスポートがあり、デフォルトエクスポートは 2 つ以上存在できません。デフォルトエクスポートを持つ新しいファイルを作成するか、または `Profile` 用の*名前付き*エクスポートを追加することができます。**1 つのファイルはデフォルトエクスポートを 1 つしか持つことができませんが、名前付きエクスポートはたくさんあっても構いません！**
+ギャラリではなく、`Profile` を 1 つだけを表示したい場合はどうでしょう。`Profile` コンポーネントもエクスポートすればいいのです。しかし、`Gallery.js` にはすでにデフォルトエクスポートがあり、デフォルトエクスポートは 2 つ以上存在できません。デフォルトエクスポートを持つ新しいファイルを作成するか、または `Profile` 用の*名前付き*エクスポートを追加することができます。**1 つのファイルはデフォルトエクスポートを 1 つしか持つことができませんが、名前付きエクスポートはたくさんあっても構いません！**
 
 <Note>
 

src/content/learn/keeping-components-pure.md

@@ -155,7 +155,7 @@ export default function TeaSet() {
 
 React には "Strict Mode" という機能があり、開発中には各コンポーネント関数を 2 回呼び出します。**関数呼び出しを 2 回行うことで、Strict Mode はこれらのルールに反するコンポーネントを見つけるのに役立ちます。**
 
-元の例では "Guest #1"、"Guest #2"、"Guest #3" と表示される代わりに "Guest #2"、"Guest #4"、"Guest #6" と表示されてしまっていましたね。元の関数が純粋でなかったため、2 回呼び出すと壊れていたわけです。修正された純粋なバージョンは、毎回 2 回呼び出されても問題ありません。**純関数は計算をするだけなので、2 回呼び出しても何も変わりません**。`double(2)` を 2 回呼び出しても戻り値が変わることはなく、<Math><MathI>y</MathI> = 2<MathI>x</MathI></Math> を 2 回解いても <MathI>y</MathI> が変わることがないのと全く同じです。入力が同じならば、出力も同じにしてください。常にそうしてください。
+元の例では "Guest #1"、"Guest #2"、"Guest #3" と表示される代わりに "Guest #2"、"Guest #4"、"Guest #6" と表示されてしまっていましたね。元の関数が純粋でなかったため、2 回呼び出すと壊れていたわけです。修正された純粋なバージョンは、毎回 2 回呼び出されても問題ありません。**純関数は計算をするだけなので、2 回呼び出しても何も変わりません**。`double(2)` を 2 回呼び出しても返り値が変わることはなく、<Math><MathI>y</MathI> = 2<MathI>x</MathI></Math> を 2 回解いても <MathI>y</MathI> が変わることがないのと全く同じです。入力が同じならば、出力も同じにしてください。常にそうしてください。
 
 Strict Mode は本番環境では影響を与えないため、ユーザが使うアプリを遅くすることはありません。Strict Mode を有効にするには、ルートコンポーネントを `<React.StrictMode>` でラップします。一部のフレームワークでは、これがデフォルトで行われます。
 

src/content/learn/lifecycle-of-reactive-effects.md

@@ -23,7 +23,7 @@ title: 'リアクティブなエフェクトのライフサイクル'
 
 ## エフェクトのライフサイクル {/*the-lifecycle-of-an-effect*/}
 
-全ての React コンポーネントは同じライフサイクルを持ちます。
+すべての React コンポーネントは同じライフサイクルを持ちます。
 
 - 画面に追加されたとき、コンポーネントは*マウント*されます。
 - （大抵はインタラクションに応じて）新しい props や state を受け取ったとき、コンポーネントは*更新*されます。
@@ -552,7 +552,7 @@ button { margin-left: 10px; }
 
 ### コンポーネント本体で宣言された変数はすべてリアクティブである {/*all-variables-declared-in-the-component-body-are-reactive*/}
 
-リアクティブな値は、props や state だけではありません。これらの値から導出される値もまた、リアクティブな値となります。props や state が変更されるとコンポーネントは再レンダーされ、導出される値も変化します。これが、コンポーネント本体で宣言された変数で、エフェクトが利用するものは、全てそのエフェクトの依存配列に含まなければならない理由です。
+リアクティブな値は、props や state だけではありません。これらの値から導出される値もまた、リアクティブな値となります。props や state が変更されるとコンポーネントは再レンダーされ、導出される値も変化します。これが、コンポーネント本体で宣言された変数で、エフェクトが利用するものは、すべてそのエフェクトの依存配列に含まなければならない理由です。
 
 ユーザがドロップダウンでチャットサーバを選択できますが、設定でデフォルトサーバを指定することもできるとしましょう。設定の状態を表す state をすでに[コンテクスト](/learn/scaling-up-with-reducer-and-context)に入れていると仮定し、そのコンテクストから `settings` を読み取ります。そして、props から得られる選択されたサーバと、デフォルトサーバに基づいて `serverUrl` を計算します。
 

src/content/learn/passing-data-deeply-with-context.md

@@ -218,7 +218,7 @@ export default function Heading({ level, children }) {
 
 </Diagram>
 
-<Diagram name="passing_data_context_far" height={430} width={608} captionPosition="top" alt="10 ノードからなるツリーの図。各ノードには最大 2 つの子がある。ルート親ノードにはオレンジ色でハイライトされた値がある。値はツリー内の 4 つのリーフノードと 1 つの中間コンポーネントに直接投影され、それらは全てオレンジ色でハイライトされている。他の中間コンポーネントはハイライトされていない。">
+<Diagram name="passing_data_context_far" height={430} width={608} captionPosition="top" alt="10 ノードからなるツリーの図。各ノードには最大 2 つの子がある。ルート親ノードにはオレンジ色でハイライトされた値がある。値はツリー内の 4 つのリーフノードと 1 つの中間コンポーネントに直接投影され、それらはすべてオレンジ色でハイライトされている。他の中間コンポーネントはハイライトされていない。">
 
 遠くの子にコンテクストを使用
 

src/content/learn/rendering-lists.md

@@ -30,7 +30,7 @@ title: リストのレンダー
 </ul>
 ```
 
-これらのリスト項目は、その中身、すなわちデータのみが異なっています。インターフェースを構築する際にはよく、コメント一覧やプロフィール画像のギャラリーなどのように、異なるデータを使用して同じコンポーネントの複数のインスタンスを表示する必要があります。このような場合、JavaScript のオブジェクトや配列にそのデータを保存し、[`map()`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/map) や [`filter()`](https://developer.mozilla.org/docs/Web/JavaScript/Reference/Global_Objects/Array/filter) などのメソッドを使ってコンポーネントのリストをレンダーすることができます。
+これらのリスト項目は、その中身、すなわちデータのみが異なっています。インターフェースを構築する際にはよく、コメント一覧やプロフィール画像のギャラリなどのように、異なるデータを使用して同じコンポーネントの複数のインスタンスを表示する必要があります。このような場合、JavaScript のオブジェクトや配列にそのデータを保存し、[`map()`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/map) や [`filter()`](https://developer.mozilla.org/docs/Web/JavaScript/Reference/Global_Objects/Array/filter) などのメソッドを使ってコンポーネントのリストをレンダーすることができます。
 
 以下は、配列からアイテムのリストを生成する方法を示す簡単な例です。
 

src/content/learn/state-a-components-memory.md

@@ -732,7 +732,7 @@ React を使用するためにこのことを理解する必要はありませ
 
 state は画面上の個々のコンポーネントインスタンスに対してローカルです。言い換えると、**同じコンポーネントを 2 回レンダーした場合、それぞれのコピーは完全に独立した state を有することになります！** そのうちの 1 つを変更しても、もう 1 つには影響しません。
 
-この例では、先ほどの `Gallery` コンポーネントが、そのロジックには変更を加えずに 2 回レンダーされています。それぞれのギャラリーの中のボタンをクリックしてみてください。これらの state が独立していることが分かるでしょう。
+この例では、先ほどの `Gallery` コンポーネントが、そのロジックには変更を加えずに 2 回レンダーされています。それぞれのギャラリの中のボタンをクリックしてみてください。これらの state が独立していることが分かるでしょう。
 
 <Sandpack>
 
@@ -895,7 +895,7 @@ button {
 
 また、`Page` コンポーネントは、`Gallery` の state の値も、そもそも state が存在するかどうかも「知らない」ということにとにも注目してください。props と違い、**state はそれを宣言したコンポーネントに完全にプライベートなものです**。親コンポーネントがそれを変更することはできません。このおかげで、任意のコンポーネントに state を追加したり削除したりしても、他のコンポーネントに影響を与えることはありません。
 
-両方のギャラリーで state を同期させたい場合はどうすればよいでしょうか？ React での正解は、子コンポーネントから state を*削除*して、それらに最も近い共有の親に追加することです。ここからの数ページでは、1 つのコンポーネント内での state の管理に焦点を当てていますが、[コンポーネント間での state 共有](/learn/sharing-state-between-components)で改めてこのトピックに戻って解説します。
+両方のギャラリで state を同期させたい場合はどうすればよいでしょうか？ React での正解は、子コンポーネントから state を*削除*して、それらに最も近い共有の親に追加することです。ここからの数ページでは、1 つのコンポーネント内での state の管理に焦点を当てていますが、[コンポーネント間での state 共有](/learn/sharing-state-between-components)で改めてこのトピックに戻って解説します。
 
 <Recap>
 
@@ -913,7 +913,7 @@ button {
 
 <Challenges>
 
-#### ギャラリーの完成 {/*complete-the-gallery*/}
+#### ギャラリの完成 {/*complete-the-gallery*/}
 
 最後の彫刻が表示されているときに "Next" を押すと、コードがクラッシュします。クラッシュを防ぐためにロジックを修正してください。そのためには、イベントハンドラに追加のロジックを追加するか、操作が不可能な場合はボタンを無効化しましょう。