preferWordとallowsに追加および同義語エラーの解消 (#1229)

AlesInfiny · May 14, 2024 · ea0c735 · ea0c735
1 parent 574935c
commit ea0c735
Show file tree

Hide file tree

Showing 10 changed files with 766 additions and 22 deletions.
diff --git a/.textlintrc b/.textlintrc
diff --git a/documents/README.md b/documents/README.md
@@ -44,7 +44,7 @@ documents フォルダー配下のフォルダー、ファイルの配置は以
 |               | images           |                       |                    |                     | ページ固有の画像ファイル置き場                |
 |               |                  | about-maris           |                    |                     | mdファイルの配置フォルダーと構造をそろえる    |
 |               |                  |                       | hoge.png           |                     | 画像ファイルはsvgかpngにする                  |
-|               |                  |                       | animation.gif      |                     | gifアニメも利用可                             |
+|               |                  |                       | animation.gif      |                     | gif アニメーションも利用可                             |
 |               |                  | app-architecture      |                    |                     |                                               |
 |               |                  | guidebooks            |                    |                     |                                               |
 |               |                  |                       | app-testing        |                     |                                               |
@@ -81,7 +81,7 @@ Feature ブランチの名前は「feature/<更新内容を表す名前>」と
 Visual Studio Code を起動して、 [ファイル] メニューから [ワークスペースを開く] を選択します。
 クローンしたフォルダー内にある maris.code-workspace ファイルを選択して開きます。
 
-[ソース管理] メニューを開き、 [チェックアウト先] を選択します。
+[`ソース`管理] メニューを開き、 [チェックアウト先] を選択します。
 
 ![チェックアウト先をクリック](readme-images/click-checkout.png)
 
@@ -96,7 +96,7 @@ main ブランチをチェックアウトしたら、 pull を実行して最新
 ### Feature ブランチの作成
 
 記事を作成するための Feature ブランチをローカルに作成します。
-[ソース管理] メニューを開き、 [ブランチ] > [分岐の作成] を選択します。
+[`ソース`管理] メニューを開き、 [ブランチ] > [分岐の作成] を選択します。
 
 ![ブランチの作成をクリック](readme-images/click-create-branch.png)
 
@@ -260,15 +260,15 @@ description: クライアントサイドレンダリングを行う Web アプ
 ### 修正内容のコミット
 
 記事の作成と体裁の修正が完了したら、 Feature ブランチにコミットします。
-[ソース管理] メニューを開き、上部の [メッセージ] にコミットメッセージを入力します。
+[`ソース`管理] メニューを開き、上部の [メッセージ] にコミットメッセージを入力します。
 また [✓] アイコンを押下して、ローカルリポジトリにコミットします。
 
 コミットは意味のある単位であれば、何回行ってもかまいません。
 
 ### Feature ブランチのアップロード
 
 コミットが完了したら、 Feature ブランチをプッシュして、リモートリポジトリにアップロードします。
-[ソース管理] メニューを開き、 [プッシュ] を選択します。
+[`ソース`管理] メニューを開き、 [プッシュ] を選択します。
 
 ![プッシュを選択](readme-images/click-push.png)
 

diff --git a/...architecture/client-side-rendering/test/backend-application/integration-test.md b/...architecture/client-side-rendering/test/backend-application/integration-test.md
@@ -26,7 +26,7 @@ description: バックエンドアプリケーションのテスト方針につ
 結合テストでは、プレゼンテーション層からデータベースまで、すべての層を対象とした機能性を確認します。
 開発したアプリケーションは原則モック化せず、完成済みのものを使用してテストします。
 
-!!! note "結合テストでモックを利用するケース"
+!!! note "結合テストでモックを利用する場合"
     以下のパターンに該当する箇所は、結合テストであってもモック化することを検討してください。
 
     - テストモードの存在しない外部のサービスを呼び出す個所

diff --git a/documents/contents/guidebooks/git/select-git-hosting-service.md b/documents/contents/guidebooks/git/select-git-hosting-service.md
@@ -28,7 +28,7 @@ Git リポジトリのホスティングサービスは、比較的安価に利
 
 ### ツールの提供機能 {#functions}
 
-Git リポジトリのホスティングツール・サービスは、多くの場合 ALM ツールとしての性格を持ち合わせています。
+Git リポジトリのホスティングツール・サービスは、多くの場合 ALM ツールとしての特性を持ち合わせています。
 開発プロセスの効率化に寄与するチケット管理の仕組みや、情報共有のための Wiki 機能、 CI / CD を実現する機能、レビュー支援機能など、 Git リポジトリ以外に付帯する機能があります。
 これらの中でも、チケット管理の仕組みと CI / CD 機能については、ツールによる差異が出やすい部分です。
 
@@ -48,7 +48,7 @@ CD 機能がどのように実現されているかよく確認し、開発プ
 ほとんどのツールは、利用するユーザーに対して月額利用料を定めています。
 ツールによっては、利用するユーザーのロールによって月額利用料に差を設けていることがあります ( 閲覧するだけのメンバーは無償、など ) 。
 またオールインワン型の課金体系を取っているものもあれば、利用する機能ごとに利用料を加算するタイプのツールもあります。
-使い方によっては、他サービスと比較して高額になるケースもあります。
+使い方によっては、他サービスと比較して高額になる場合もあります。
 利用する機能が決まったら事前に見積り、大まかなコスト感を確認しましょう。
 
 ## ツールの選択肢 {#choice-of-tools}

diff --git a/...ents/guidebooks/how-to-develop/dotnet/configure-asp-net-core-web-api-project.md b/...ents/guidebooks/how-to-develop/dotnet/configure-asp-net-core-web-api-project.md
@@ -339,7 +339,7 @@ ASP.NET Core Web API プロジェクトを作成した際、一緒に作成さ
 ??? example "基本のログ構成例"
     本番環境向けのログレベル設定は、 [appsettings.json] に行います。
     Information レベル以上のログを出力するように設定しましょう。
-    ただし、 `Microsoft.AspNetCore` のカテゴリについては、 Warning 以上のレベルのみ出力するようにします。
+    ただし、 `Microsoft.AspNetCore` のカテゴリーについては、 Warning 以上のレベルのみ出力するようにします。
 
     開発しているアプリケーションから出力するログのログレベルも、明示的に設定しておくことを推奨します。
     例のように、 `LogLLevel` 要素にソリューション名と同名のキーを追加し、値としてログレベルを設定します。

diff --git a/documents/contents/guidebooks/how-to-develop/dotnet/create-project-structure.md b/documents/contents/guidebooks/how-to-develop/dotnet/create-project-structure.md
@@ -21,7 +21,7 @@ description: バックエンドで動作する .NET アプリケーションの
     エンティティや値オブジェクトのクラス名は、設計で抽出したキーワードをそのまま利用するようにします。
     アプリケーションサービス、ドメインサービス、リポジトリのインターフェースは、各クラスの役割を表す語をクラス名の末尾に付けて識別します。
 
-慣例として、コンポーネントの種類で先にフォルダー分割するケースもあります。
+慣例として、コンポーネントの種類で先にフォルダー分割することもあります。
 例えば Web API のコントローラークラスは、 Controllers フォルダーに配置することが多いです。
 このような慣例がある場合は、そちらを優先してかまいません。
 

diff --git a/documents/contents/guidebooks/how-to-develop/dotnet/create-solution-structure.md b/documents/contents/guidebooks/how-to-develop/dotnet/create-solution-structure.md
@@ -16,7 +16,7 @@ Git リポジトリの構築については、以下を参照してください
 
 作成した Git リポジトリ内に、ソリューションを作成していきます。
 原則としてソリューションはサブシステムごとに作成します。
-ソリューション全体構造の概略は「[アプリケーションアーキテクチャ概要編 - ソリューション構造](../../../app-architecture/overview/application-structure.md#solution-structure)」を参照してください。
+ソリューション全体構造の概要は「[アプリケーションアーキテクチャ概要編 - ソリューション構造](../../../app-architecture/overview/application-structure.md#solution-structure)」を参照してください。
 本節では、単一のソリューション内の構造について、更に詳細に解説します。
 
 ### ソリューション構成と物理フォルダーの関係 {#solution-and-physical-folder-relationships}
@@ -86,7 +86,7 @@ tests フォルダー内は、テストの目的にあわせてテストプロ
 
 プロジェクトの数が多くなりすぎると、単一のソリューションで開発を進めるのが困難になります。
 その場合は、[ソリューションフィルター](https://learn.microsoft.com/ja-jp/visualstudio/msbuild/solution-filters#solution-filter-files) を用いて業務や機能の単位でプロジェクトをフィルタリングします。
-プロジェクトの総数が 30 を超えるようなソリューションの場合、ソリューションフィルターの活用を検討しましょう。
+プロジェクトの総数が 30 以上のソリューションの場合、ソリューションフィルターの活用を検討しましょう。
 プロジェクトを業務単位で分割しておくことで、ソリューションフィルターが効果的に活用できます。
 ソリューションフィルターを使用する場合は、単体機能確認のためのテストプロジェクトも業務単位で分割しましょう。
 

diff --git a/documents/contents/guidebooks/how-to-develop/local-environment/index.md b/documents/contents/guidebooks/how-to-develop/local-environment/index.md
@@ -21,9 +21,9 @@ AlesInfiny Maris のアプリケーションを開発するコンピューター
 
 ### ハードウェア要件 {#hardware-requirements}
 
-- 1.8 GHz 以上、 4 コア以上の 64 ビットプロセッサ ( ARM プロセッサは対象外です ) が必要です。
+- 1.8 GHz 以上、 4 コア以上の 64 ビットプロセッサ ( ARM プロセッサーは対象外です ) が必要です。
     - 8 論理コア ( ハイパースレッディングなど ) 以上を推奨します。
-    - 仮想マシンの場合、 4 仮想プロセッサ以上が必要です。 8 仮想プロセッサ以上を推奨します。
+    - 仮想マシンの場合、 4 仮想プロセッサー以上が必要です。 8 仮想プロセッサー以上を推奨します。
 - 8 GB 以上の RAM が必要です。 16 GB 以上を推奨します。
 - 50 GB 以上の空き容量を持つ SSD が必要です。
 - FullHD ( 1920 * 1080 ) 以上の解像度を持つディスプレイが必要です。

diff --git a/documents/contents/guidebooks/migration/dotnetfw-risk/dotnet-runtime-trends.md b/documents/contents/guidebooks/migration/dotnetfw-risk/dotnet-runtime-trends.md
@@ -29,7 +29,7 @@ description: .NET Framework にとどまり続けることで起こりうる リ
 
 .NET 以外にも IT 技術の革新は進みました。
 クライアントサイドにおいてはスマートフォンアプリや IoT の登場、サーバーサイドにおいては AI 等 SaaS によって提供される高度なサービスの活用が進みました。
-これにより、 Windows 製品のみの組み合わせによる単純なアプリケーションでは、ユーザーの需要を満たすシステムを実現することが難しくなりました。
+これにより、 Windows 製品のみの組み合わせによる単純なアプリケーションでは、ユーザーのニーズを満たすシステムを実現することが難しくなりました。
 そこで Microsoft は、 2016 年 6 月に .NET Core 1.0 をリリースします。
 これは、 Windows 上でも Linux 上でも動作するクロスプラットフォームかつオープンソースの .NET ランタイムであり、「 Windows 縛り」からの脱却ができるようになりました。
 

diff --git a/documents/contents/guidebooks/migration/dotnetfw-risk/risk-of-dotnet-framework.md b/documents/contents/guidebooks/migration/dotnetfw-risk/risk-of-dotnet-framework.md
@@ -41,7 +41,7 @@ RESTful API の Open API 仕様書を生成する Swagger のライブラリ「
 ### 新しい開発環境が使えない {#cannot-use-new-ide}
 
 2022 年 6 月現在最新 Visual Studio 2022 では、 .NET Framework 4.0 から 4.5.1 までの開発がサポートされません。
-よってこれらのバージョンをターゲットとしたアプリケーションをビルドできません。
+よってこれらのバージョンを対象としたアプリケーションをビルドできません。
 今後、 Visual Studio でビルドできる .NET Framework のバージョンは減っていくことが考えられます。
 
 ### 言語バージョンが更新されないため、モダンなコーディングができない {#without-modern-coding}
@@ -79,11 +79,11 @@ C# 8.0 以降追加された便利で生産性を上げてくれる記法は使
 
 また、無償の動画コンテンツ ( [.NET の公式チャンネル](https://www.youtube.com/c/dotNET) ) が存在しますが、 .NET Framework のコンテンツは存在しません。
 
-このように、社外では .NET の技術者や技術者コミュニティが拡大すると同時に、 .NET Framework のコミュニティは縮小しています。
+このように、社外では .NET の技術者や技術者コミュニティーが拡大すると同時に、 .NET Framework のコミュニティーは縮小しています。
 最新の機能や技術はすべて .NET に追加されるため、技術者は .NET Framework ではなく .NET を学習するようになるでしょう。
 また、技術書や研修プログラムといった学習のツールも、新しく提供される物は .NET Framework ではなく .NET 向けのコンテンツとなります。
 
-これらのことから、社内外を問わず .NET Framework コミュニティは縮小していきます。
+これらのことから、社内外を問わず .NET Framework コミュニティーは縮小していきます。
 それに伴って、 .NET Framework に詳しい、特に若手の人材は今後減っていくでしょう。
 開発プロジェクトにおいて .NET Framework の有識者を確保することは困難となります。
 
@@ -107,7 +107,7 @@ C# 8.0 以降追加された便利で生産性を上げてくれる記法は使
 新しいことに挑戦しない企業は、優秀なエンジニアにとって魅力がないものに映るでしょう。
 .NET Framework にいつまでも留まり続けることで、業界内だけでなく、就職・転職市場においても、企業の価値が低下することは避けられません。
 
-## 移行を急がなくても良いケース {#cases-no-need-to-rush-the-migration}
+## 移行を急がなくても良い例 {#cases-no-need-to-rush-the-migration}
 
 ここまで、 .NET Framework に留まり続けることのリスクについて解説しました。
 しかし、移行を急ぐ必要があまりないアプリケーションも、数は少ないものの存在します。