translate 02-sveltekit/07-page-options into Japanese

Author: tomoam

content/tutorial/02-sveltekit/07-page-options/01-page-options/README.md

@@ -2,15 +2,15 @@
 title: Basics
 ---
 
-In the chapter on [loading data](/tutorial/page-data), we saw how you can export `load` functions from `+page.js`, `+page.server.js`, `+layout.js` and `+layout.server.js` files. We can also export various **page options** from these modules:
+[loading data](/tutorial/page-data) の章では、`+page.js`、`+page.server.js`、`+layout.js`、`+layout.server.js` ファイルから `load` 関数をエクスポートする方法について見てきました。これらのモジュールからは他にも様々な **ページオプション(page options)** をエクスポートできます。
 
-- `ssr` — whether or not pages should be server-rendered
-- `csr` — whether to load the SvelteKit client
-- `prerender` — whether to prerender pages at build time, instead of per-request
-- `trailingSlash` — whether to strip, add, or ignore trailing slashes in URLs
+- `ssr` — ページをサーバーレンダリングするかどうか
+- `csr` — SvelteKit client をロードするかどうか
+- `prerender` — リクエストの度にレンダリングする代わりに、ビルド時にページをプリレンダリングするかどうか
+- `trailingSlash` — URL の末尾のスラッシュ(trailing slashes)を、削除するか、追加するか、無視するか
 
-In the following exercises, we'll learn about each of these in turn.
+この後の練習問題では、これらをそれぞれ順番に学んでいきます。
 
-Page options can apply to individual pages (if exported from `+page.js` or `+page.server.js`), or groups of pages (if exported from `+layout.js` or `+layout.server.js`). To define an option for the whole app, export it from the root layout. Child layouts and pages override values set in parent layouts, so — for example — you can enable prerendering for your entire app then disable it for pages that need to be dynamically rendered.
+ページオプションは (`+page.js` や `+page.server.js` からエクスポートすることで) ページ個別に適用することができますし、(`+layout.js` や `+layout.server.js` からエクスポートすることで) ページのグループに適用することもできます。アプリ全体のオプションを定義するには、最上位のレイアウト(root layout) からエクスポートします。子レイアウトやページは親レイアウトで設定された値をオーバーライドするので、例えば、アプリ全体ではプリレンダリングを有効にして、動的なレンダリングが必要なページではそれを無効にすることができます。
 
-You can mix and match these options in different areas of your app — you could prerender your marketing pages, dynamically server-render your data-driven pages, and treat your admin pages as a client-rendered SPA. This makes SvelteKit very versatile.
+アプリの様々な領域でこれらのオプションをうまく組み合わせることができます。マーケティング用のページはプリレンダリングし、データドリブンなページは動的にサーバーでレンダリングし、管理者用ページはクライアントレンダリングされる SPA として扱うことができます。このように、SvelteKit はとても万能で多くの用途にお使いいただけます。

content/tutorial/02-sveltekit/07-page-options/02-ssr/README.md

@@ -2,13 +2,13 @@
 title: ssr
 ---
 
-Server-side rendering (SSR) is the process of generating HTML on the server, and is what SvelteKit does by default. It's important for performance and [resilience](https://kryogenix.org/code/browser/everyonehasjs.html), and is very beneficial for search engine optimization (SEO) — while some search engines can index content that is rendered in the browser with JavaScript, it happens less frequently and reliably.
+サーバーサイドレンダリング (Server-side rendering, SSR) とはサーバーで HTML を生成するプロセスのことで、SvelteKit はデフォルトでこれを行っています。パフォーマンスと[レジリエンス](https://kryogenix.org/code/browser/everyonehasjs.html)のために重要であり、検索エンジン最適化 (SEO) にも非常に有益です。なぜなら、一部の検索エンジンではブラウザ上で JavaScript によってレンダリングされたコンテンツをインデックスできますが、その頻度は少なく、信頼性は低いためです。
 
-That said, some components _can't_ be rendered on the server, perhaps because they expect to be able to access browser globals like `window` immediately. If you can, you should change those components so that they _can_ render on the server, but if you can't then you can disable SSR:
+一方で、サーバーでレンダリング _できない_ コンポーネントもあります。例えば、`window` のようなブラウザのグローバルにアクセスできることを想定している場合などです。もし可能なら、コンポーネントを変更してサーバーでもレンダリングできるようにしたほうが良いですが、それができない場合は、SSR を無効にすることができます。
 
 ```js
 /// file: src/routes/+page.server.js
 export const ssr = false;
 ```
 
-> Setting `ssr` to `false` inside your root `+layout.server.js` effectively turns your entire app into an SPA.
+> 最上位(root)の `+layout.server.js` で `ssr` を `false` に設定すると、アプリ全体を SPA に変えることができます。

content/tutorial/02-sveltekit/07-page-options/03-csr/README.md

@@ -2,13 +2,13 @@
 title: csr
 ---
 
-Client-side rendering is what makes the page interactive — such as incrementing the counter when you click the button in this app — and enables SvelteKit to update the page upon navigation without a full-page reload.
+クライアントサイドレンダリングとは、ページをインタラクティブ (例えばこのアプリでは、ボタンクリックでカウンターがインクリメントするようになる) にし、SvelteKit がナビゲーション時にフルページリロードなしでページを更新できるようにすることです。
 
-As with `ssr`, you can disable client-side rendering altogether:
+`ssr` と同じように、クライアントサイドレンダリングも完全に無効にすることができます。
 
 ```js
 /// file: src/routes/+page.server.js
 export const csr = false;
 ```
 
-This means that no JavaScript is served to the client, but it also means that your components are no longer interactive. It can be a useful way to check whether or not your application is usable for people who — for whatever reason — cannot use JavaScript.
+これは、JavaScript がクライアントに全く提供されなくなることを意味しますが、それだけでなく、コンポーネントがインタラクティブでなくなることも意味します。これは、なんらかの理由で JavaScript が使用できない方々にとって、あなたのアプリケーションが使いやすいかどうかを確認するのに便利です。

content/tutorial/02-sveltekit/07-page-options/04-prerender/README.md

@@ -2,20 +2,20 @@
 title: prerender
 ---
 
-Prerendering means generating HTML for a page once, at build time, rather than dynamically for each request.
+プリレンダリングとは、リクエストのたびに動的にレンダリングするのではなく、ビルド時に1度だけ HTML を生成することを意味します。
 
-The advantage is that serving static data is extremely cheap and performant, allowing you to easily serve large numbers of users without worrying about cache-control headers (which are easy to get wrong).
+利点は、静的データの配信が圧倒的にチープでハイパフォーマンスなことにあります。cache-control ヘッダ (これは間違いやすいことです) のことを気にすることなく、大人数のユーザーに配信することができるようになります。
 
-The tradeoff is that the build process takes longer, and prerendered content can only be updated by building and deploying a new version of the application.
+トレードオフは、ビルドプロセスの時間が長くなることと、プリレンダリングされたコンテンツを更新するのにアプリケーションの新バージョンをビルドしてデプロイする他ないことです。
 
-To prerender a page, set `prerender` to `true`:
+ページをプリレンダリングするには、`prerender` を `true` に設定します。
 
 ```js
 export const prerender = true;
 ```
 
-Here in the tutorial, this won't have any observable effect, since the application is running in `dev` mode.
+このチュートリアルでは、アプリケーションが `dev` モードで実行されているため、目で見てわかるような効果はありません。
 
-Not all pages can be prerendered. The basic rule is this: for content to be prerenderable, any two users hitting it directly must get the same content from the server, and the page must not contain form actions. Pages with dynamic route parameters can be prerendered as long as they are specified in the [`prerender.entries`](https://kit.svelte.dev/docs/configuration#prerender) configuration or can be reached by following links from pages that _are_ in `prerender.entries`.
+全てのページをプリレンダリングできるわけではありません。基本的なルールはこうです: コンテンツがプリレンダリング可能であると言うためには、それを直接表示する2人のユーザーが、サーバーから同じコンテンツを取得できなけれならず、ページには form actions が含まれていないこと。動的なルートパラメータ(route parameters)を持つページは、[`prerender.entries`](https://kit.svelte.jp/docs/configuration#prerender) 設定で指定されているか、`prerender.entries` で指定されているページからリンクを辿って到達できるのであれば、プリレンダリングすることができます。
 
-> Setting `prerender` to `true` inside your root `+layout.server.js` effectively turns SvelteKit into a static site generator (SSG).
+> 最上位(root)の `+layout.server.js` で `prerender` を `true` に設定した場合、本質的には SvelteKit は静的サイトジェネレーター (static site generator, SSG) になります。

content/tutorial/02-sveltekit/07-page-options/05-trailingslash/README.md

@@ -2,24 +2,24 @@
 title: trailingSlash
 ---
 
-Two URLs like `/foo` and `/foo/` might look the same, but they're actually different. A relative URL like `bar` will resolve to `/bar` in the first case and `/foo/bar` in the second, and search engines will treat them as separate entries, harming your SEO.
+2つの URL `/foo` と `/foo/` は同じように見えるかもしれませんが、実際は異なります。`bar` のような相対 URL は、1つめのケースでは `/bar` に解決し、2つ目のケースでは `/foo/bar` に解決します。検索エンジンはこれらを別々のエントリとして扱うため、SEO に悪影響を与えます。
 
-In short, being loosey-goosey about trailing slashes is a bad idea. By default, SvelteKit strips trailing slashes, meaning that a request for `/foo/` will result in a redirect to `/foo`.
+要するに、末尾のスラッシュを雑に扱うのは悪い考えだということです。デフォルトで、SvelteKit は末尾のスラッシュを削除します。つまり、`/foo/` に対するリクエストは `/foo` にリダイレクトされます。
 
-If you instead want to ensure that a trailing slash is always present, you can specify the `trailingSlash` option accordingly:
+代わりに、末尾のスラッシュが常に存在するようにしたい場合は、`trailingSlash` オプションをそれに応じて指定することができます。
 
 ```js
 /// file: src/routes/always/+page.server.js
 export const trailingSlash = 'always';
 ```
 
-To accommodate both cases (this is not recommended!), use `'ignore`':
+両方とも許容するには (これは推奨されません！)、`'ignore'` を使用します。
 
 ```js
 /// file: src/routes/ignore/+page.server.js
 export const trailingSlash = 'ignore';
 ```
 
-The default value is `'never'`.
+デフォルトの値は `'never'` です。
 
-Whether or not trailing slashes are applied affects prerendering. A URL like `/always/` will be saved to disk as `always/index.html` whereas a URL like `/never` will be saved as `never.html`.
+末尾のスラッシュが適用されるかどうかは、プリレンダリングに影響します。`/always/` のような URL は、`always/index.html` としてディスクに保存され、一方で `/never` のような URL は `never.html` のように保存されます。