migrate the rest of ja articles

Author: Solant

src/content/docs/docs/guides/examples/auth.mdx

@@ -4,7 +4,7 @@ sidebar:
   order: 1
 ---
 
-import { FileTree } from '@astrojs/starlight/components';
+import { FileTree, Aside } from '@astrojs/starlight/components';
 
 Broadly, authentication consists of the following steps:
 
@@ -36,12 +36,14 @@ Here we created two components and exported them both in the index file of the s
 
 If your app has a dialog for login that can be used on any page, consider making that dialog a widget. That way, you can still avoid too much decomposition, but have the freedom to reuse this dialog on any page.
 
-- 📂 widgets
-    - 📂 login-dialog
-        - 📂 ui
-            - 📄 LoginDialog.tsx
-        - 📄 index.ts
-    - other widgets…
+<FileTree>
+- widgets/
+  - login-dialog/
+    - ui/
+      - LoginDialog.tsx
+    - index.ts
+  - ...
+</FileTree>
 
 The rest of this guide is written for the dedicated page approach, but the same principles apply to the dialog widget.
 
@@ -130,11 +132,11 @@ Another drawback of this approach is that if your backend returns an object of y
 
 It's common for FSD projects to have an entity for a user and/or an entity for the current user. It can even be the same entity for both.
 
-:::note
+<Aside>
 
 The **current user** is also sometimes called "viewer" or "me". This is to distinguish the single authenticated user, with permissions and private information, from a list of all users with publicly accessible information.
 
-:::
+</Aside>
 
 To store the token in the User entity, create a reactive store in the `model` segment. That store can contain both the token and the user object.
 

src/content/docs/ja/docs/get-started/faq.mdx

@@ -0,0 +1,67 @@
+---
+title: FAQ
+---
+
+import { Aside } from '@astrojs/starlight/components';
+
+<Aside>
+
+質問は、[Discordコミュニティ][discord]、[GitHub Discussions][github-discussions]、および[Telegramチャット][telegram]で聞くことができます。
+
+</Aside>
+
+### ツールキットやリンターはありますか？ \{#is-there-a-toolkit-or-a-linter}
+
+はい！CLI または IDE を通じてプロジェクトのアーキテクチャと [フォルダー ジェネレーター][ext-tools] をチェックするための [Steiger][ext-steiger] というリンターがあります。
+
+### ページのレイアウト/テンプレートはどこに保存すればよいですか？ \{#where-to-store-the-layouttemplate-of-pages}
+
+シンプルなレイアウトテンプレートが必要な場合は、`shared/ui`に保存できます。より上層のレイヤーを使用する必要がある場合、いくつかのオプションがあります。
+
+- レイアウトが本当に必要ですか？レイアウトが数行で構成されている場合、各ページにコードを重複させる方が合理的です。
+- レイアウトが必要な場合は、個別のウィジェットやページとして保存し、App層のルーター設定にそれらを組み合わせることができます。ネストされたルーティングも一つのオプションです。
+
+### フィーチャーとエンティティの違いは何ですか？ \{#what-is-the-difference-between-feature-and-entity}
+
+<i>エンティティ</i>はアプリケーションが扱う現実世界の概念です。<i>フィーチャー</i>はユーザーに実際の価値を提供するインタラクションであり、ユーザーがエンティティで行いたいことです。
+
+詳細および例については、参考書セクションの[スライスについてのページ][reference-entities]を参照してください。
+
+### ページ/フィーチャー/エンティティを相互に埋め込むことはできますか？ \{#can-i-embed-pagesfeaturesentities-into-each-other}
+
+はい、しかし、この埋め込みはより上層のレイヤーで行う必要があります。例えば、ウィジェット内で両方のフィーチャーをインポートし、プロップス/子要素として一方のフィーチャーを他方に挿入することができます。
+
+一方のフィーチャーを他方のフィーチャーからインポートすることはできません。これは[**レイヤーのインポートルール**][import-rule-layers]で禁止されています。
+
+### Atomic Designはどうですか？ \{#what-about-atomic-design}
+
+現在、アトミックデザインをFeature-Sliced Designと一緒に使用することを義務付けていませんが、禁止もしていません。
+
+アトミックデザインは、モジュールの`ui`セグメントにうまく適用できます。
+
+### FSDに関する有用なリソース/記事などはありますか？ \{#are-there-any-useful-resourcesarticlesetc-about-fsd}
+
+はい！ https://github.com/feature-sliced/awesome
+
+### なぜFeature-Sliced Designが必要なのですか？ \{#why-do-i-need-feature-sliced-design}
+
+FSDは、プロジェクトの主要な価値を提供するコンポーネントの観点から、あなたとあなたのチームが迅速にプロジェクトを把握するのに役立ちます。標準化されたアーキテクチャは、オンボーディングを迅速化し、コード構造に関する議論を解決するのに役立ちます。FSDが作成された理由については、[モチベーション][motivation]のページを参照してください。
+
+### 初心者の開発者にFSDのアーキテクチャ/設計方法論は必要ですか？ \{#does-a-novice-developer-need-an-architecturemethodology}
+
+おそらく必要です。
+
+*通常、一人でプロジェクトを設計・開発する場合、すべてが順調に進みます。しかし、開発に中断が生じたり、新しい開発者がチームに加わると問題が発生します。*
+
+### 認証コンテキストをどのように扱えばよいですか？ \{#how-do-i-work-with-the-authorization-context}
+
+[こちら](/docs/guides/examples/auth)で回答しています。
+
+[ext-steiger]: https://github.com/feature-sliced/steiger
+[ext-tools]: https://github.com/feature-sliced/awesome?tab=readme-ov-file#tools
+[import-rule-layers]: /docs/reference/layers#import-rule-on-layers
+[reference-entities]: /docs/reference/layers#entities
+[motivation]: /docs/about/motivation
+[telegram]: https://t.me/feature_sliced
+[discord]: https://discord.gg/S8MzWTUsmp
+[github-discussions]: https://github.com/feature-sliced/documentation/discussions

src/content/docs/ja/docs/get-started/overview.mdx

@@ -0,0 +1,142 @@
+---
+title: 概要
+sidebar:
+  order: 1
+---
+
+import { FileTree } from '@astrojs/starlight/components';
+
+**Feature-Sliced Design** (FSD) とは、フロントエンドアプリケーションの設計方法論です。簡単に言えば、コードを整理するためのルールと規約の集大成です。FSDの主な目的は、ビジネス要件が絶えず変化する中で、プロジェクトをより理解しやすく、構造化されたものにすることです。
+
+ルールのセットに加えて、FSDはツールチェーンでもあります。プロジェクトのアーキテクチャをチェックするための[リンター][ext-steiger]、CLIやIDEを通じた[フォルダージェネレーター][ext-tools]、および豊富な[実装例のコレクション][examples]があります。
+
+## FSDは私のプロジェクトに適しているのか？ \{#is-it-right-for-me}
+
+FSDは、あらゆる規模のプロジェクトやチームに導入できます。以下の場合、あなたのプロジェクトに適しています。
+
+- **フロントエンド**開発での使用（ウェブサイト、モバイル/デスクトップアプリケーションのインターフェース作成など）
+- **アプリケーション**開発での使用（ライブラリ開発ではない）
+
+これだけです！使用するプログラミング言語、フレームワーク、状態管理ライブラリには制限がありません。尚、FSDを段階的に導入したり、モノレポで使用したり、アプリケーションをパッケージに分割し、それぞれにFSDを個別に導入することもできます！
+
+既存のアーキテクチャからFSDに移行することを検討している場合は、現在のアーキテクチャがチームに**支障をきたしている**かどうかを確認してください。例えば、プロジェクトが大きくなりすぎて新機能の開発が効率的に行えない場合や、多くの新しいメンバーがチームに加わることが予想される場合です。現在のアーキテクチャが正常に機能している場合、変更する必要はないかもしれません。しかし、移行を決定した場合は、[移行セクション][migration]の推奨事項を確認してください。
+
+## 基本的な例 \{#basic-example}
+
+以下は、FSDを実装したシンプルなプロジェクトです。
+
+<FileTree>
+- app/
+- pages/
+- shared/
+</FileTree>
+
+これらのトップレベルのフォルダーは*レイヤー*と呼ばれます。詳しく見てみましょう。
+
+<FileTree>
+- app/
+  - routes/
+  - analytics/
+- pages/
+  - home/
+  - article-reader/
+    - ui/
+    - api/
+  - settings/
+- shared/
+  - ui/
+  - api/
+</FileTree>
+
+`📂 pages`内のフォルダーは*スライス*と呼ばれます。スライスはドメイン（この場合はページ）ごとにレイヤーを分割します。
+
+`📂 app`、`📂 shared`、および`📂 pages/article-reader`内のフォルダーは*セグメント*と呼ばれ、スライス（またはレイヤー）を技術的な目的に応じて分割します。
+
+## 概念 \{#concepts}
+
+レイヤー、スライス、セグメントは、以下の図に示されるように階層を形成します。
+
+<figure>
+   ![FSDの概念の階層、以下に説明](../../../../../../static/img/visual_schema.jpg)
+
+   <figcaption style={{ fontStyle: "italic", fontSize: "0.9em" }}>
+      <p>上の図には、左から右に「レイヤー」、「スライス」、「セグメント」とラベル付けされた3つの列があります。</p>
+      <p>「レイヤー」列には、上から下に「app」、「processes」、「pages」、「widgets」、「features」、「entities」、「shared」とラベル付けされた7つの区分があります。「processes」区分は取り消し線が引かれています。「entities」区分は2番目の列「スライス」と接続されていて、2番目の列が「entities」の内容であることを示しています。</p>
+      <p>「スライス」列には、上から下に「user」、「post」、「comment」とラベル付けされた3つの区分があります。「post」区分は「セグメント」列と同様に接続されていて、「post」の内容であることを示しています。</p>
+      <p>「セグメント」列には、上から下に「ui」、「model」、「api」とラベル付けされた3つの区分があります。</p>
+    </figcaption>
+</figure>
+
+### レイヤー \{#layers}
+
+レイヤーはすべてのFSDプロジェクトで標準化されています。すべてのレイヤーを使用する必要はありませんが、ネーミングは重要です。現在、7つのレイヤーが存在しています（上から下へ）。
+
+1. App＊（アップ） — アプリケーションの起動に必要なすべてのもの（ルーティング、エントリーポイント、グローバルスタイル、プロバイダーなど）
+2. Processes（プロセス、非推奨） — 複雑なページ間のシナリオ
+3. Pages（ページ） — ページ全体、またはネストされたルーティングの場合、ページの大部分
+4. Widgets（ウィジェット） — 大きな自己完結型の機能部分、またはインターフェースの大部分。通常はユーザーシナリオ全体を実装する
+5. Features（フィーチャー） — プロダクト機能の再利用可能な実装、つまりユーザーにビジネス価値をもたらすアクション
+6. Entities（エンティティ） — プロジェクトが扱うビジネスエンティティ、例えば`user`や`product`
+7. Shared＊（シェアード） — 再利用可能なコード。特にプロジェクト/ビジネスの詳細から切り離されたもの
+
+_＊ — App層とShared層のレイヤーは他のレイヤーとは異なり、スライスを持たず、直接セグメントで構成されています。_
+
+レイヤーの特徴は、レイヤーのモジュールは、下層のレイヤーモジュールのみを知ることができ、その結果、レイヤーが下層のレイヤーからのみモジュールをインポートできることです。
+
+### スライス \{#slices}
+ 
+次にスライスがあり、レイヤーをドメインごとに分割します。スライスの名前は自由に付けることができ、いくつでも作成できます。スライスは、意味的に関連するコードをグループ化することで、プロジェクト内のナビゲーションをしやすくします。
+
+スライスは同じレイヤーの他のスライスを使用できないため、スライス内のコードの強い結合とスライス間の弱い結合が保証されます。
+
+### セグメント \{#segments}
+
+スライス、およびApp層とShared層のレイヤーはセグメントで構成され、セグメントはその目的に応じてコードをグループ化します。セグメントの名前は標準で固定されていませんが、最も一般的な目的のためにいくつかの共通の名前があります。
+
+- `ui` — 表示に関連するすべて: UIコンポーネント、日付フォーマッター、スタイルなど
+- `api` — バックエンドとのやり取り: リクエスト関数、データ型、マッパー
+- `model` — データモデル: バリデーションスキーマ、インターフェース、ストレージ、ビジネスロジック
+- `lib` — 他のモジュールが必要とするライブラリコード
+- `config` — 設定ファイルとフィーチャーフラグ
+
+通常、これらのセグメントはほとんどのレイヤーに十分であるため、独自のセグメントはShared層やApp層でのみ作成されることが多いです。しかし、これは厳格なルールではありません。
+
+## 利点 \{#advantages}
+
+- **一貫性**  
+ 構造が標準化されているため、プロジェクトがより一貫性を持ち、新しいメンバーのチームへの参加が容易になります。
+
+- **変更とリファクタリングへの耐性**  
+ レイヤーのモジュールは、同じレイヤーや上層レイヤーの他のモジュールを使用できないため、アプリケーションの他の部分に予期しない影響を与えることなく、分離された変更を加えることができます。
+
+- **ロジックの再利用制御**  
+ レベルに応じて、コードを非常に再利用可能にすることも、非常にローカルにすることもできます。  
+ これにより、**DRY**原則と実用性のバランスが保たれます。
+
+- **ビジネスとユーザーのニーズに焦点を当てる**  
+ アプリケーションはビジネスドメインに分割され、命名にはビジネス用語の使用が奨励されるため、プロジェクトの他の無関係な部分に完全に精通することなく、プロダクトで有用な作業を行うことができます。
+
+## 段階的な導入 \{#incremental-adoption}
+
+既存のコードベースをFSDに移行したい場合は、以下の戦略をお勧めします。私たち自身の移行経験から、この方法は非常に効果的であることが分かりました。
+
+1. App層とShared層のレイヤーを徐々に形成し、基盤を作る。
+
+2. 既存のすべてのインターフェースコードをウィジェットとページに分散させる。FSDのルールに違反する依存関係があっても良い。
+
+3. インポートのルール違反を徐々に修正しながら、エンティティやフィーチャーを抽出する。
+
+リファクタリング中に新しい大きなエンティティを追加することや、部分的なリファクタリングは避けることをお勧めします。
+
+## 次のステップ \{#next-steps}
+
+- **FSDの考え方を理解したい？** [チュートリアル][tutorial]を読んでください。
+- **例を見て学びたい？** [実装例セクション][examples]にたくさんあります。
+- **質問がある？** [Discordチャンネル][ext-discord]にアクセスして、コミュニティに質問してください。
+
+[tutorial]: /docs/get-started/tutorial
+[examples]: /examples
+[migration]: /docs/guides/migration/from-custom
+[ext-steiger]: https://github.com/feature-sliced/steiger
+[ext-tools]: https://github.com/feature-sliced/awesome?tab=readme-ov-file#tools
+[ext-discord]: https://discord.com/invite/S8MzWTUsmp