Update Japanese translation

Author: yuhattor

translation/ja/patterns/extensions-for-sustainable-growth.md

@@ -66,7 +66,7 @@
 4. **テスト戦略:** 拡張機能を個別に、または組み合わせてテストする方法は？
    - **拡張機能を個別にテストする:** 拡張機能のテンプレートは、拡張機能の開発者が追加した機能をテストするためのテストフレームワークを提供します。これには、ユニットテスト、ランタイムパフォーマンステスト、品質テストのフレームワークが含まれることがあります。
    - **拡張機能をプライマリリポジトリと組み合わせてテストする:** 拡張機能の開発者は、プライマリリポジトリの特定のバージョンに対して自分の拡張機能をテストするための良好なパターンの方法を持つべきで、これにはプライマリリポジトリのメンテナの関与は必要ありません。
-   - **拡張機能を他の拡張機能と組み合わせてテストする:** このシナリオのためのテストフレームワークを提供することは、ユーザーがまだ探求中であり、全てが組み合わせて使用される可能性が低い多くの拡張機能が存在する場合には過度となる可能性があります。ユーザーが拡張機能を組み合わせて使用する際に競合が発生した場合（十分な疎結合があればこれはまれであるはずです）、ユーザーはそれぞれの拡張機能の所有者に問題を提起することができ、彼らはそれを解決します。拡張機能がライフサイクルの後期に達し、プライマリリポジトリにマージされると、それは残りのライブラリと組み合わせてテストされ、その時点で任意の依存関係の競合を解決しなければなりません。
+   - **拡張機能を他の拡張機能と組み合わせてテストする:** このシナリオのためにテストフレームワークを提供することは、特に、ユーザによってまだ調査中であり、すべての拡張機能を組み合わせて使用する可能性が低い多数の拡張機能がある場合、過剰になる可能性があります。もしユーザが拡張機能を組み合わせて使っているときにコンフリクトに遭遇した場合 (十分な疎結合であればありえないはずです)、ユーザはそれぞれの拡張機能の所有者に問題を提起することができます。拡張機能がライフサイクルの後半に達し、プライマリリポジトリにマージされるようになると、ライブラリの残りの部分と組み合わせてテストされるようになり、依存関係の衝突はその時点で解決されなければならなくなります。
 5. **発見性と利便性:**
    - ユーザーが作成し、製品の使用に共有したいと思っている拡張機能を表示する公開ページで、拡張機能を容易に発見できるようにします。
    - ユーザーが元のプロジェクトと一緒に拡張機能を利用できるように、プライマリプロジェクトに拡張機能の登録を許可します。これにより、同じユーザーエクスペリエンスが維持されます。
@@ -83,7 +83,7 @@
 - 拡張機能は、プライマリプロジェクトの全てのユーザーによって反復可能な方法で発見できます。コードがまだメインリポジトリに存在していないとしても、それが価値がないわけではありません。
 - メンテナの負担は、拡張機能がプライマリプロジェクトで重要なギャップを埋めていることを示すまで軽減されます。
 - コアプロジェクトの共通コード（例えば、ベースクラスやユーティリティ関数）は、プロジェクトの領域を拡張する新しい開発の出発点となります。これにより、革新的な作業を後から移植する必要がなくなり、プロジェクトにとって新しい機能を開発する全体的な負担を軽減します。
-- 開発者は、彼らのコードベースのためのコミュニティのメンテナンスとコミュニティ構築にコントリビューションし、関与し続ける可能性が高くなります。これは全体のプロジェクトエコシステムの健康にも良い影響を与えます。
+- 開発者は、コードベースのためのコミュニティのメンテナンスとコミュニティ構築にコントリビューションし、関与し続ける可能性が高くなります。これは全体のプロジェクトエコシステムの健康にも良い影響を与えます。
 
 ## 結果の状況
 
@@ -100,7 +100,7 @@
 
 ## エイリアス
 
-スケールでのコントリビューション管理のための拡張
+大規模にコントリビューションを管理するための拡張
 
 ## ステータス