doc: svelte/awaitの翻訳 (#67)

HitoshiroKyoka · web-flow · commit b5e17c4fcd10 · 2025-10-03T12:32:41.000+09:00
diff --git a/apps/svelte.dev/content/docs/svelte/03-template-syntax/19-await-expressions.md b/apps/svelte.dev/content/docs/svelte/03-template-syntax/19-await-expressions.md
@@ -3,13 +3,13 @@ NOTE: do not edit this file, it is generated in apps/svelte.dev/scripts/sync-doc
 title: await
 ---
 
-As of Svelte 5.36, you can use the `await` keyword inside your components in three places where it was previously unavailable:
+Svelte5.36 以降、コンポーネント内のうち、これまで使えなかった3箇所で `await` キーワードを使えるようになりました:
 
-- at the top level of your component's `<script>`
-- inside `$derived(...)` declarations
-- inside your markup
+- コンポーネントの `<script>` トップレベル
+-  `$derived(...)` 宣言の内部
+- マークアップの内部
 
-This feature is currently experimental, and you must opt in by adding the `experimental.async` option wherever you [configure](/docs/kit/configuration) Svelte, usually `svelte.config.js`:
+この機能は実験的なものであり、Svelteの[設定](/docs/kit/configuration)(通常は `svelte.config.js`)に `experimental.async` オプションを追加して、明示的に有効にする必要があります:
 
 ```js
 /// file: svelte.config.js
@@ -22,11 +22,11 @@ export default {
 };
 ```
 
-The experimental flag will be removed in Svelte 6.
+この実験的なフラグは Svelte 6 で削除される予定です。
 
-## Boundaries
+## Boundary(境界) <!--Boundaries-->
 
-Currently, you can only use `await` inside a [`<svelte:boundary>`](svelte-boundary) with a `pending` snippet:
+現在、 `await` は `pending` snippetを持つ [`<svelte:boundary>`](svelte-boundary) の内部でのみ使えます:
 
 ```svelte
 <svelte:boundary>
@@ -38,13 +38,13 @@ Currently, you can only use `await` inside a [`<svelte:boundary>`](svelte-bounda
 </svelte:boundary>
 ```
 
-This restriction will be lifted once Svelte supports asynchronous server-side rendering (see [caveats](#Caveats)).
+この制限は、 Svelte が非同期のサーバーサイドレンダリングをサポートするようになれば解除されます([注意事項](#Caveats)を参照)。
 
-> [!NOTE] In the [playground](/playground), your app is rendered inside a boundary with an empty pending snippet, so that you can use `await` without having to create one.
+> [!NOTE] [プレイグラウンド](/playground)では、アプリは空の pending snippet を持つ boudary 内でレンダリングされるため、自分で作成しなくても `await` を使えます。
 
-## Synchronized updates
+## 同期された更新 <!--Synchronized-updates-->
 
-When an `await` expression depends on a particular piece of state, changes to that state will not be reflected in the UI until the asynchronous work has completed, so that the UI is not left in an inconsistent state. In other words, in an example like [this](/playground/untitled#H4sIAAAAAAAAE42QsWrDQBBEf2VZUkhYRE4gjSwJ0qVMkS6XYk9awcFpJe5Wdoy4fw-ycdykSPt2dpiZFYVGxgrf2PsJTlPwPWTcO-U-xwIH5zli9bminudNtwEsbl-v8_wYj-x1Y5Yi_8W7SZRFI1ZYxy64WVsjRj0rEDTwEJWUs6f8cKP2Tp8vVIxSPEsHwyKdukmA-j6jAmwO63Y1SidyCsIneA_T6CJn2ZBD00Jk_XAjT4tmQwEv-32eH6AsgYK6wXWOPPTs6Xy1CaxLECDYgb3kSUbq8p5aaifzorCt0RiUZbQcDIJ10ldH8gs3K6X2Xzqbro5zu1KCHaw2QQPrtclvwVSXc2sEC1T-Vqw0LJy-ClRy_uSkx2ogHzn9ADZ1CubKAQAA)...
+ある `await` 式が特定の state に依存しているとき、その state への変更は、非同期処理が完了するまでUIに反映されません。UIが矛盾した状態にならないようにするためです。つまり、[こちら](/playground/untitled#H4sIAAAAAAAAE42QsWrDQBBEf2VZUkhYRE4gjSwJ0qVMkS6XYk9awcFpJe5Wdoy4fw-ycdykSPt2dpiZFYVGxgrf2PsJTlPwPWTcO-U-xwIH5zli9bminudNtwEsbl-v8_wYj-x1Y5Yi_8W7SZRFI1ZYxy64WVsjRj0rEDTwEJWUs6f8cKP2Tp8vVIxSPEsHwyKdukmA-j6jAmwO63Y1SidyCsIneA_T6CJn2ZBD00Jk_XAjT4tmQwEv-32eH6AsgYK6wXWOPPTs6Xy1CaxLECDYgb3kSUbq8p5aaifzorCt0RiUZbQcDIJ10ldH8gs3K6X2Xzqbro5zu1KCHaw2QQPrtclvwVSXc2sEC1T-Vqw0LJy-ClRy_uSkx2ogHzn9ADZ1CubKAQAA)のような例では...
 
 ```svelte
 <script>
@@ -63,46 +63,46 @@ When an `await` expression depends on a particular piece of state, changes to th
 <p>{a} + {b} = {await add(a, b)}</p>
 ```
 
-...if you increment `a`, the contents of the `<p>` will _not_ immediately update to read this —
+...`a` の値をインクリメントしても、 `<p>` の内容は次のようには _なりません。_
 
 ```html
 <p>2 + 2 = 3</p>
 ```
 
-— instead, the text will update to `2 + 2 = 4` when `add(a, b)` resolves.
+実際には、`add(a, b)`が解決されたときに、`<p>`の内容を `2 + 2 = 4` に更新します。
 
-Updates can overlap — a fast update will be reflected in the UI while an earlier slow update is still ongoing.
+更新は重複することがあります。先行する更新が遅く、まだ進行中であっても、続く更新が速ければ、速いほうが先にUIに反映されます。
 
-## Concurrency
+## 並行性 <!--Concurrency-->
 
-Svelte will do as much asynchronous work as it can in parallel. For example if you have two `await` expressions in your markup...
+Svelte は可能な限り非同期処理を並行におこないます。例えば、マークアップ内に2つの `await` 式があるとき...
 
 ```svelte
 <p>{await one()}</p>
 <p>{await two()}</p>
 ```
 
-...both functions will run at the same time, as they are independent expressions, even though they are _visually_ sequential.
+...それらは独立した式ですので、 _見た目上は_ 順次実行されているように見えても、両方の関数が同時に実行されます。
 
-This does not apply to sequential `await` expressions inside your `<script>` or inside async functions — these run like any other asynchronous JavaScript. An exception is that independent `$derived` expressions will update independently, even though they will run sequentially when they are first created:
+これは、`<script>` 内や非同期関数内の連続した `await` 式には適用されません。これらは他の非同期JavaScriptと同じように実行されます。例外として、独立した `$derived` 式は、最初の作成時には順次実行されますが、そのあとは独立して更新されます:
 
 ```js
 async function one() { return 1; }
 async function two() { return 2; }
 // ---cut---
-// these will run sequentially the first time,
-// but will update independently
+// これらは最初は順次実行されますが、
+// そのあとは独立して更新されます
 let a = $derived(await one());
 let b = $derived(await two());
 ```
 
-> [!NOTE] If you write code like this, expect Svelte to give you an [`await_waterfall`](runtime-warnings#Client-warnings-await_waterfall) warning
+> [!NOTE] このようなコードを書くと、Svelteから [`await_waterfall`](runtime-warnings#Client-warnings-await_waterfall) 警告が表示されます。
 
-## Indicating loading states
+## ローディング状態の表示<!--Indicating-loading-states-->
 
-In addition to the nearest boundary's [`pending`](svelte-boundary#Properties-pending) snippet, you can indicate that asynchronous work is ongoing with [`$effect.pending()`]($effect#$effect.pending).
+`await` によるローディング状態は、それを囲むもっとも内側の `<svelte:boundary>` に定義された [`pending`](svelte-boundary#Properties-pending) によって表示されます。それに加えて、 [`$effect.pending()`]($effect#$effect.pending) を使っても、非同期処理が進行中であることを示せます。
 
-You can also use [`settled()`](svelte#settled) to get a promise that resolves when the current update is complete:
+また、 [`settled()`](svelte#settled) を使うと、現在の更新が完了したときに解決(resolve)される Promise を取得できます:
 
 ```js
 let color = 'red';
@@ -114,32 +114,32 @@ import { tick, settled } from 'svelte';
 async function onclick() {
 	updating = true;
 
-	// without this, the change to `updating` will be
-	// grouped with the other changes, meaning it
-	// won't be reflected in the UI
+	// これがないと、`updating` への変更は
+	// 他の変更とまとめられてしまうため、
+	// UI に反映されません
 	await tick();
 
 	color = 'octarine';
 	answer = 42;
 
 	await settled();
 
-	// any updates affected by `color` or `answer`
-	// have now been applied
+	// `color` や `answer` の変更に影響される
+	// あらゆる更新が、この時点で適用済みになります
 	updating = false;
 }
 ```
 
-## Error handling
+## エラーハンドリング <!--Error-handling-->
 
-Errors in `await` expressions will bubble to the nearest [error boundary](svelte-boundary).
+`await` 式のエラーは、もっとも近い [error boundary](svelte-boundary) に伝播します。
 
-## Caveats
+## 注意事項 <!--Caveats-->
 
-As an experimental feature, the details of how `await` is handled (and related APIs like `$effect.pending()`) are subject to breaking changes outside of a semver major release, though we intend to keep such changes to a bare minimum.
+実験的な機能であるため、 `await` 扱いの詳細(および `$effect.pending()` のような関連API)は、セマンティックバージョニングのメジャーリリース外では破壊的変更がおこなわれる可能性があります。ただし、そのような変更は最小限に抑えるつもりです。
 
-Currently, server-side rendering is synchronous. If a `<svelte:boundary>` with a `pending` snippet is encountered during SSR, only the `pending` snippet will be rendered.
+現在、サーバーサイドレンダリングは同期的です。SSR中に `pending` snippet を持つ `<svelte:boundary>` が検出されたとき、 `pending` snippet のみがレンダリングされます。
 
-## Breaking changes
+## 破壊的変更 <!--Breaking-changes-->
 
-Effects run in a slightly different order when the `experimental.async` option is `true`. Specifically, _block_ effects like `{#if ...}` and `{#each ...}` now run before an `$effect.pre` or `beforeUpdate` in the same component, which means that in [very rare situations](/playground/untitled?#H4sIAAAAAAAAE22R3VLDIBCFX2WLvUhnTHsf0zre-Q7WmfwtFV2BgU1rJ5N3F0jaOuoVcPbw7VkYhK4_URTiGYkMnIyjDjLsFGO3EvdCKkIvipdB8NlGXxSCPt96snbtj0gctab2-J_eGs2oOWBE6VunLO_2es-EDKZ5x5ZhC0vPNWM2gHXGouNzAex6hHH1cPHil_Lsb95YT9VQX6KUAbS2DrNsBdsdDFHe8_XSYjH1SrhELTe3MLpsemajweiWVPuxHSbKNd-8eQTdE0EBf4OOaSg2hwNhhE_ABB_ulJzjj9FULvIcqgm5vnAqUB7wWFMfhuugQWkcAr8hVD-mq8D12kOep24J_IszToOXdveGDsuNnZwbJUNlXsKnhJdhUcTo42s41YpOSneikDV5HL8BktM6yRcCAAA=) it is possible to update a block that should no longer exist, but only if you update state inside an effect, [which you should avoid]($effect#When-not-to-use-$effect).
+`experimental.async` オプションが `true` のとき、効果の実行順序がわずかに異なります。具体的には、 `{#if ...}` や `{#each ...}` のような _ブロック_ の効果を、 `$effect.pre` や `beforeUpdate` の前に実行するようになります。これにより、[非常にまれな状況](/playground/untitled?#H4sIAAAAAAAAE22R3VLDIBCFX2WLvUhnTHsf0zre-Q7WmfwtFV2BgU1rJ5N3F0jaOuoVcPbw7VkYhK4_URTiGYkMnIyjDjLsFGO3EvdCKkIvipdB8NlGXxSCPt96snbtj0gctab2-J_eGs2oOWBE6VunLO_2es-EDKZ5x5ZhC0vPNWM2gHXGouNzAex6hHH1cPHil_Lsb95YT9VQX6KUAbS2DrNsBdsdDFHe8_XSYjH1SrhELTe3MLpsemajweiWVPuxHSbKNd-8eQTdE0EBf4OOaSg2hwNhhE_ABB_ulJzjj9FULvIcqgm5vnAqUB7wWFMfhuugQWkcAr8hVD-mq8D12kOep24J_IszToOXdveGDsuNnZwbJUNlXsKnhJdhUcTo42s41YpOSneikDV5HL8BktM6yRcCAAA=)では、存在しないはずのブロックを更新してしまう可能性があります。ただし、これは効果内で state を更新した場合に限られますし、[そのような状況は避けるべきです]($effect#When-not-to-use-$effect)。
