+
+
+
+
+
+
+This project follows the [all-contributors](https://github.com/all-contributors/all-contributors) specification. Contributions of any kind welcome!
+
+
+以下はSvelte公式のREADMEの内容です。
+
+---
+
# svelte.dev
This is the repository behind [svelte.dev](https://svelte.dev), the official Svelte site, and the related packages that it relies on.
diff --git a/apps/kit.svelte.dev/vercel.json b/apps/kit.svelte.dev/vercel.json
index 6b9ecfbe6e..639c67a8ad 100644
--- a/apps/kit.svelte.dev/vercel.json
+++ b/apps/kit.svelte.dev/vercel.json
@@ -3,36 +3,36 @@
"redirects": [
{
"source": "/",
- "destination": "https://svelte.dev/",
+ "destination": "https://svelte.jp/",
"permanent": true
},
{
"source": "/docs/layouts",
- "destination": "https://svelte.dev/docs/kit/routing",
+ "destination": "https://svelte.jp/docs/kit/routing",
"permanent": true
},
{
"source": "/docs/loading",
- "destination": "https://svelte.dev/docs/kit/load",
+ "destination": "https://svelte.jp/docs/kit/load",
"permanent": true
},
{
"source": "/docs/types",
- "destination": "https://svelte.dev/docs/kit/@sveltejs-kit"
+ "destination": "https://svelte.jp/docs/kit/@sveltejs-kit"
},
{
"source": "/docs",
- "destination": "https://svelte.dev/docs/kit",
+ "destination": "https://svelte.jp/docs/kit",
"permanent": true
},
{
"source": "/docs/(.*)",
- "destination": "https://svelte.dev/docs/kit/$1",
+ "destination": "https://svelte.jp/docs/kit/$1",
"permanent": true
},
{
"source": "/(.*)",
- "destination": "https://svelte.dev/"
+ "destination": "https://svelte.jp/"
}
]
}
diff --git a/apps/learn.svelte.dev/vercel.json b/apps/learn.svelte.dev/vercel.json
index 806baa00c2..0b7298c36c 100644
--- a/apps/learn.svelte.dev/vercel.json
+++ b/apps/learn.svelte.dev/vercel.json
@@ -3,95 +3,95 @@
"redirects": [
{
"source": "/tutorial/welcome-to-svelte",
- "destination": "https://svelte.dev/tutorial/svelte/welcome-to-svelte"
+ "destination": "https://svelte.jp/tutorial/svelte/welcome-to-svelte"
},
{
"source": "/tutorial/your-first-component",
- "destination": "https://svelte.dev/tutorial/svelte/your-first-component"
+ "destination": "https://svelte.jp/tutorial/svelte/your-first-component"
},
{
"source": "/tutorial/dynamic-attributes",
- "destination": "https://svelte.dev/tutorial/svelte/dynamic-attributes"
+ "destination": "https://svelte.jp/tutorial/svelte/dynamic-attributes"
},
{
"source": "/tutorial/styling",
- "destination": "https://svelte.dev/tutorial/svelte/styling"
+ "destination": "https://svelte.jp/tutorial/svelte/styling"
},
{
"source": "/tutorial/nested-components",
- "destination": "https://svelte.dev/tutorial/svelte/nested-components"
+ "destination": "https://svelte.jp/tutorial/svelte/nested-components"
},
{
"source": "/tutorial/html-tags",
- "destination": "https://svelte.dev/tutorial/svelte/html-tags"
+ "destination": "https://svelte.jp/tutorial/svelte/html-tags"
},
{
"source": "/tutorial/reactive-assignments",
- "destination": "https://svelte.dev/tutorial/svelte/state"
+ "destination": "https://svelte.jp/tutorial/svelte/state"
},
{
"source": "/tutorial/reactive-declarations",
- "destination": "https://svelte.dev/tutorial/svelte/derived-state"
+ "destination": "https://svelte.jp/tutorial/svelte/derived-state"
},
{
"source": "/tutorial/reactive-statements",
- "destination": "https://svelte.dev/tutorial/svelte/effects"
+ "destination": "https://svelte.jp/tutorial/svelte/effects"
},
{
"source": "/tutorial/updating-arrays-and-objects",
- "destination": "https://svelte.dev/tutorial/svelte/deep-state"
+ "destination": "https://svelte.jp/tutorial/svelte/deep-state"
},
{
"source": "/tutorial/declaring-props",
- "destination": "https://svelte.dev/tutorial/svelte/declaring-props"
+ "destination": "https://svelte.jp/tutorial/svelte/declaring-props"
},
{
"source": "/tutorial/default-values",
- "destination": "https://svelte.dev/tutorial/svelte/default-values"
+ "destination": "https://svelte.jp/tutorial/svelte/default-values"
},
{
"source": "/tutorial/spread-props",
- "destination": "https://svelte.dev/tutorial/svelte/spread-props"
+ "destination": "https://svelte.jp/tutorial/svelte/spread-props"
},
{
"source": "/tutorial/if-blocks",
- "destination": "https://svelte.dev/tutorial/svelte/if-blocks"
+ "destination": "https://svelte.jp/tutorial/svelte/if-blocks"
},
{
"source": "/tutorial/else-blocks",
- "destination": "https://svelte.dev/tutorial/svelte/else-blocks"
+ "destination": "https://svelte.jp/tutorial/svelte/else-blocks"
},
{
"source": "/tutorial/else-if-blocks",
- "destination": "https://svelte.dev/tutorial/svelte/else-if-blocks"
+ "destination": "https://svelte.jp/tutorial/svelte/else-if-blocks"
},
{
"source": "/tutorial/each-blocks",
- "destination": "https://svelte.dev/tutorial/svelte/each-blocks"
+ "destination": "https://svelte.jp/tutorial/svelte/each-blocks"
},
{
"source": "/tutorial/keyed-each-blocks",
- "destination": "https://svelte.dev/tutorial/svelte/keyed-each-blocks"
+ "destination": "https://svelte.jp/tutorial/svelte/keyed-each-blocks"
},
{
"source": "/tutorial/await-blocks",
- "destination": "https://svelte.dev/tutorial/svelte/await-blocks"
+ "destination": "https://svelte.jp/tutorial/svelte/await-blocks"
},
{
"source": "/tutorial/dom-events",
- "destination": "https://svelte.dev/tutorial/svelte/dom-events"
+ "destination": "https://svelte.jp/tutorial/svelte/dom-events"
},
{
"source": "/tutorial/inline-handlers",
- "destination": "https://svelte.dev/tutorial/svelte/inline-handlers"
+ "destination": "https://svelte.jp/tutorial/svelte/inline-handlers"
},
{
"source": "/tutorial/event-modifiers",
- "destination": "https://svelte.dev/tutorial/svelte/capturing"
+ "destination": "https://svelte.jp/tutorial/svelte/capturing"
},
{
"source": "/tutorial/component-events",
- "destination": "https://svelte.dev/tutorial/svelte/component-events"
+ "destination": "https://svelte.jp/tutorial/svelte/component-events"
},
{
"source": "/tutorial/event-forwarding",
@@ -99,47 +99,47 @@
},
{
"source": "/tutorial/dom-event-forwarding",
- "destination": "https://svelte.dev/tutorial/svelte/spreading-events"
+ "destination": "https://svelte.jp/tutorial/svelte/spreading-events"
},
{
"source": "/tutorial/text-inputs",
- "destination": "https://svelte.dev/tutorial/svelte/text-inputs"
+ "destination": "https://svelte.jp/tutorial/svelte/text-inputs"
},
{
"source": "/tutorial/numeric-inputs",
- "destination": "https://svelte.dev/tutorial/svelte/numeric-inputs"
+ "destination": "https://svelte.jp/tutorial/svelte/numeric-inputs"
},
{
"source": "/tutorial/checkbox-inputs",
- "destination": "https://svelte.dev/tutorial/svelte/checkbox-inputs"
+ "destination": "https://svelte.jp/tutorial/svelte/checkbox-inputs"
},
{
"source": "/tutorial/select-bindings",
- "destination": "https://svelte.dev/tutorial/svelte/select-bindings"
+ "destination": "https://svelte.jp/tutorial/svelte/select-bindings"
},
{
"source": "/tutorial/group-inputs",
- "destination": "https://svelte.dev/tutorial/svelte/group-inputs"
+ "destination": "https://svelte.jp/tutorial/svelte/group-inputs"
},
{
"source": "/tutorial/multiple-select-bindings",
- "destination": "https://svelte.dev/tutorial/svelte/multiple-select-bindings"
+ "destination": "https://svelte.jp/tutorial/svelte/multiple-select-bindings"
},
{
"source": "/tutorial/textarea-inputs",
- "destination": "https://svelte.dev/tutorial/svelte/textarea-inputs"
+ "destination": "https://svelte.jp/tutorial/svelte/textarea-inputs"
},
{
"source": "/tutorial/marked",
- "destination": "https://svelte.dev/tutorial/svelte/textarea-inputs"
+ "destination": "https://svelte.jp/tutorial/svelte/textarea-inputs"
},
{
"source": "/tutorial/onmount",
- "destination": "https://svelte.dev/docs/svelte/lifecycle-hooks"
+ "destination": "https://svelte.jp/docs/svelte/lifecycle-hooks"
},
{
"source": "/tutorial/update",
- "destination": "https://svelte.dev/docs/svelte/lifecycle-hooks"
+ "destination": "https://svelte.jp/docs/svelte/lifecycle-hooks"
},
{
"source": "/tutorial/elizabot",
@@ -147,27 +147,27 @@
},
{
"source": "/tutorial/tick",
- "destination": "https://svelte.dev/docs/svelte/lifecycle-hooks#tick"
+ "destination": "https://svelte.jp/docs/svelte/lifecycle-hooks#tick"
},
{
"source": "/tutorial/writable-stores",
- "destination": "https://svelte.dev/tutorial/svelte/introducing-stores"
+ "destination": "https://svelte.jp/tutorial/svelte/introducing-stores"
},
{
"source": "/tutorial/auto-subscriptions",
- "destination": "https://svelte.dev/docs/svelte/stores"
+ "destination": "https://svelte.jp/docs/svelte/stores"
},
{
"source": "/tutorial/readable-stores",
- "destination": "https://svelte.dev/docs/svelte/stores"
+ "destination": "https://svelte.jp/docs/svelte/stores"
},
{
"source": "/tutorial/derived-stores",
- "destination": "https://svelte.dev/docs/svelte/stores"
+ "destination": "https://svelte.jp/docs/svelte/stores"
},
{
"source": "/tutorial/custom-stores",
- "destination": "https://svelte.dev/docs/svelte/stores"
+ "destination": "https://svelte.jp/docs/svelte/stores"
},
{
"source": "/tutorial/store-bindings",
@@ -175,399 +175,399 @@
},
{
"source": "/tutorial/tweens",
- "destination": "https://svelte.dev/tutorial/svelte/tweens"
+ "destination": "https://svelte.jp/tutorial/svelte/tweens"
},
{
"source": "/tutorial/springs",
- "destination": "https://svelte.dev/tutorial/svelte/springs"
+ "destination": "https://svelte.jp/tutorial/svelte/springs"
},
{
"source": "/tutorial/transition",
- "destination": "https://svelte.dev/tutorial/svelte/transition"
+ "destination": "https://svelte.jp/tutorial/svelte/transition"
},
{
"source": "/tutorial/adding-parameters-to-transitions",
- "destination": "https://svelte.dev/tutorial/svelte/adding-parameters-to-transitions"
+ "destination": "https://svelte.jp/tutorial/svelte/adding-parameters-to-transitions"
},
{
"source": "/tutorial/in-and-out",
- "destination": "https://svelte.dev/tutorial/svelte/in-and-out"
+ "destination": "https://svelte.jp/tutorial/svelte/in-and-out"
},
{
"source": "/tutorial/custom-css-transitions",
- "destination": "https://svelte.dev/tutorial/svelte/custom-css-transitions"
+ "destination": "https://svelte.jp/tutorial/svelte/custom-css-transitions"
},
{
"source": "/tutorial/custom-js-transitions",
- "destination": "https://svelte.dev/tutorial/svelte/custom-js-transitions"
+ "destination": "https://svelte.jp/tutorial/svelte/custom-js-transitions"
},
{
"source": "/tutorial/transition-events",
- "destination": "https://svelte.dev/tutorial/svelte/transition-events"
+ "destination": "https://svelte.jp/tutorial/svelte/transition-events"
},
{
"source": "/tutorial/global-transitions",
- "destination": "https://svelte.dev/tutorial/svelte/global-transitions"
+ "destination": "https://svelte.jp/tutorial/svelte/global-transitions"
},
{
"source": "/tutorial/key-blocks",
- "destination": "https://svelte.dev/tutorial/svelte/key-blocks"
+ "destination": "https://svelte.jp/tutorial/svelte/key-blocks"
},
{
"source": "/tutorial/deferred-transitions",
- "destination": "https://svelte.dev/tutorial/svelte/deferred-transitions"
+ "destination": "https://svelte.jp/tutorial/svelte/deferred-transitions"
},
{
"source": "/tutorial/animate",
- "destination": "https://svelte.dev/tutorial/svelte/animations"
+ "destination": "https://svelte.jp/tutorial/svelte/animations"
},
{
"source": "/tutorial/actions",
- "destination": "https://svelte.dev/tutorial/svelte/actions"
+ "destination": "https://svelte.jp/tutorial/svelte/actions"
},
{
"source": "/tutorial/adding-parameters-to-actions",
- "destination": "https://svelte.dev/tutorial/svelte/adding-parameters-to-actions"
+ "destination": "https://svelte.jp/tutorial/svelte/adding-parameters-to-actions"
},
{
"source": "/tutorial/tippy.js",
- "destination": "https://svelte.dev/tutorial/svelte/tippy.js"
+ "destination": "https://svelte.jp/tutorial/svelte/tippy.js"
},
{
"source": "/tutorial/contenteditable-bindings",
- "destination": "https://svelte.dev/tutorial/svelte/contenteditable-bindings"
+ "destination": "https://svelte.jp/tutorial/svelte/contenteditable-bindings"
},
{
"source": "/tutorial/each-block-bindings",
- "destination": "https://svelte.dev/tutorial/svelte/each-block-bindings"
+ "destination": "https://svelte.jp/tutorial/svelte/each-block-bindings"
},
{
"source": "/tutorial/media-elements",
- "destination": "https://svelte.dev/tutorial/svelte/media-elements"
+ "destination": "https://svelte.jp/tutorial/svelte/media-elements"
},
{
"source": "/tutorial/dimensions",
- "destination": "https://svelte.dev/tutorial/svelte/dimensions"
+ "destination": "https://svelte.jp/tutorial/svelte/dimensions"
},
{
"source": "/tutorial/bind-this",
- "destination": "https://svelte.dev/tutorial/svelte/bind-this"
+ "destination": "https://svelte.jp/tutorial/svelte/bind-this"
},
{
"source": "/tutorial/component-bindings",
- "destination": "https://svelte.dev/tutorial/svelte/component-bindings"
+ "destination": "https://svelte.jp/tutorial/svelte/component-bindings"
},
{
"source": "/tutorial/component-this",
- "destination": "https://svelte.dev/tutorial/svelte/component-this"
+ "destination": "https://svelte.jp/tutorial/svelte/component-this"
},
{
"source": "/tutorial/classes",
- "destination": "https://svelte.dev/tutorial/svelte/classes"
+ "destination": "https://svelte.jp/tutorial/svelte/classes"
},
{
"source": "/tutorial/class-shorthand",
- "destination": "https://svelte.dev/tutorial/svelte/class-shorthand"
+ "destination": "https://svelte.jp/tutorial/svelte/class-shorthand"
},
{
"source": "/tutorial/styles",
- "destination": "https://svelte.dev/tutorial/svelte/styles"
+ "destination": "https://svelte.jp/tutorial/svelte/styles"
},
{
"source": "/tutorial/component-styles",
- "destination": "https://svelte.dev/tutorial/svelte/component-styles"
+ "destination": "https://svelte.jp/tutorial/svelte/component-styles"
},
{
"source": "/tutorial/slots",
- "destination": "https://svelte.dev/docs/svelte/legacy-slots"
+ "destination": "https://svelte.jp/docs/svelte/legacy-slots"
},
{
"source": "/tutorial/named-slots",
- "destination": "https://svelte.dev/docs/svelte/legacy-slots"
+ "destination": "https://svelte.jp/docs/svelte/legacy-slots"
},
{
"source": "/tutorial/slot-fallbacks",
- "destination": "https://svelte.dev/docs/svelte/legacy-slots"
+ "destination": "https://svelte.jp/docs/svelte/legacy-slots"
},
{
"source": "/tutorial/slot-props",
- "destination": "https://svelte.dev/docs/svelte/legacy-slots"
+ "destination": "https://svelte.jp/docs/svelte/legacy-slots"
},
{
"source": "/tutorial/optional-slots",
- "destination": "https://svelte.dev/docs/svelte/legacy-$slots"
+ "destination": "https://svelte.jp/docs/svelte/legacy-$slots"
},
{
"source": "/tutorial/context-api",
- "destination": "https://svelte.dev/tutorial/svelte/context-api"
+ "destination": "https://svelte.jp/tutorial/svelte/context-api"
},
{
"source": "/tutorial/svelte-self",
- "destination": "https://svelte.dev/docs/svelte/legacy-svelte-self"
+ "destination": "https://svelte.jp/docs/svelte/legacy-svelte-self"
},
{
"source": "/tutorial/svelte-component",
- "destination": "https://svelte.dev/docs/svelte/legacy-svelte-component"
+ "destination": "https://svelte.jp/docs/svelte/legacy-svelte-component"
},
{
"source": "/tutorial/svelte-element",
- "destination": "https://svelte.dev/tutorial/svelte/svelte-element"
+ "destination": "https://svelte.jp/tutorial/svelte/svelte-element"
},
{
"source": "/tutorial/svelte-window",
- "destination": "https://svelte.dev/tutorial/svelte/svelte-window"
+ "destination": "https://svelte.jp/tutorial/svelte/svelte-window"
},
{
"source": "/tutorial/svelte-window-bindings",
- "destination": "https://svelte.dev/tutorial/svelte/svelte-window-bindings"
+ "destination": "https://svelte.jp/tutorial/svelte/svelte-window-bindings"
},
{
"source": "/tutorial/svelte-body",
- "destination": "https://svelte.dev/tutorial/svelte/svelte-body"
+ "destination": "https://svelte.jp/tutorial/svelte/svelte-body"
},
{
"source": "/tutorial/svelte-document",
- "destination": "https://svelte.dev/tutorial/svelte/svelte-document"
+ "destination": "https://svelte.jp/tutorial/svelte/svelte-document"
},
{
"source": "/tutorial/svelte-head",
- "destination": "https://svelte.dev/tutorial/svelte/svelte-head"
+ "destination": "https://svelte.jp/tutorial/svelte/svelte-head"
},
{
"source": "/tutorial/svelte-options",
- "destination": "https://svelte.dev/docs/svelte/svelte-options"
+ "destination": "https://svelte.jp/docs/svelte/svelte-options"
},
{
"source": "/tutorial/svelte-fragment",
- "destination": "https://svelte.dev/docs/svelte/legacy-svelte-fragment"
+ "destination": "https://svelte.jp/docs/svelte/legacy-svelte-fragment"
},
{
"source": "/tutorial/sharing-code",
- "destination": "https://svelte.dev/tutorial/svelte/sharing-code"
+ "destination": "https://svelte.jp/tutorial/svelte/sharing-code"
},
{
"source": "/tutorial/module-exports",
- "destination": "https://svelte.dev/tutorial/svelte/module-exports"
+ "destination": "https://svelte.jp/tutorial/svelte/module-exports"
},
{
"source": "/tutorial/debug",
- "destination": "https://svelte.dev/docs/svelte/@debug"
+ "destination": "https://svelte.jp/docs/svelte/@debug"
},
{
"source": "/tutorial/congratulations",
- "destination": "https://svelte.dev/tutorial/svelte/congratulations"
+ "destination": "https://svelte.jp/tutorial/svelte/congratulations"
},
{
"source": "/tutorial/introducing-sveltekit",
- "destination": "https://svelte.dev/tutorial/kit/introducing-sveltekit"
+ "destination": "https://svelte.jp/tutorial/kit/introducing-sveltekit"
},
{
"source": "/tutorial/pages",
- "destination": "https://svelte.dev/tutorial/kit/pages"
+ "destination": "https://svelte.jp/tutorial/kit/pages"
},
{
"source": "/tutorial/layouts",
- "destination": "https://svelte.dev/tutorial/kit/layouts"
+ "destination": "https://svelte.jp/tutorial/kit/layouts"
},
{
"source": "/tutorial/params",
- "destination": "https://svelte.dev/tutorial/kit/params"
+ "destination": "https://svelte.jp/tutorial/kit/params"
},
{
"source": "/tutorial/page-data",
- "destination": "https://svelte.dev/tutorial/kit/page-data"
+ "destination": "https://svelte.jp/tutorial/kit/page-data"
},
{
"source": "/tutorial/layout-data",
- "destination": "https://svelte.dev/tutorial/kit/layout-data"
+ "destination": "https://svelte.jp/tutorial/kit/layout-data"
},
{
"source": "/tutorial/headers",
- "destination": "https://svelte.dev/tutorial/kit/headers"
+ "destination": "https://svelte.jp/tutorial/kit/headers"
},
{
"source": "/tutorial/cookies",
- "destination": "https://svelte.dev/tutorial/kit/cookies"
+ "destination": "https://svelte.jp/tutorial/kit/cookies"
},
{
"source": "/tutorial/lib",
- "destination": "https://svelte.dev/tutorial/kit/lib"
+ "destination": "https://svelte.jp/tutorial/kit/lib"
},
{
"source": "/tutorial/the-form-element",
- "destination": "https://svelte.dev/tutorial/kit/the-form-element"
+ "destination": "https://svelte.jp/tutorial/kit/the-form-element"
},
{
"source": "/tutorial/named-form-actions",
- "destination": "https://svelte.dev/tutorial/kit/named-form-actions"
+ "destination": "https://svelte.jp/tutorial/kit/named-form-actions"
},
{
"source": "/tutorial/form-validation",
- "destination": "https://svelte.dev/tutorial/kit/form-validation"
+ "destination": "https://svelte.jp/tutorial/kit/form-validation"
},
{
"source": "/tutorial/progressive-enhancement",
- "destination": "https://svelte.dev/tutorial/kit/progressive-enhancement"
+ "destination": "https://svelte.jp/tutorial/kit/progressive-enhancement"
},
{
"source": "/tutorial/customizing-use-enhance",
- "destination": "https://svelte.dev/tutorial/kit/customizing-use-enhance"
+ "destination": "https://svelte.jp/tutorial/kit/customizing-use-enhance"
},
{
"source": "/tutorial/get-handlers",
- "destination": "https://svelte.dev/tutorial/kit/get-handlers"
+ "destination": "https://svelte.jp/tutorial/kit/get-handlers"
},
{
"source": "/tutorial/post-handlers",
- "destination": "https://svelte.dev/tutorial/kit/post-handlers"
+ "destination": "https://svelte.jp/tutorial/kit/post-handlers"
},
{
"source": "/tutorial/other-handlers",
- "destination": "https://svelte.dev/tutorial/kit/other-handlers"
+ "destination": "https://svelte.jp/tutorial/kit/other-handlers"
},
{
"source": "/tutorial/page-store",
- "destination": "https://svelte.dev/tutorial/kit/page-store"
+ "destination": "https://svelte.jp/tutorial/kit/page-store"
},
{
"source": "/tutorial/navigating-store",
- "destination": "https://svelte.dev/tutorial/kit/navigating-store"
+ "destination": "https://svelte.jp/tutorial/kit/navigating-store"
},
{
"source": "/tutorial/updated-store",
- "destination": "https://svelte.dev/tutorial/kit/updated-store"
+ "destination": "https://svelte.jp/tutorial/kit/updated-store"
},
{
"source": "/tutorial/error-basics",
- "destination": "https://svelte.dev/tutorial/kit/error-basics"
+ "destination": "https://svelte.jp/tutorial/kit/error-basics"
},
{
"source": "/tutorial/error-pages",
- "destination": "https://svelte.dev/tutorial/kit/error-pages"
+ "destination": "https://svelte.jp/tutorial/kit/error-pages"
},
{
"source": "/tutorial/fallback-errors",
- "destination": "https://svelte.dev/tutorial/kit/fallback-errors"
+ "destination": "https://svelte.jp/tutorial/kit/fallback-errors"
},
{
"source": "/tutorial/redirects",
- "destination": "https://svelte.dev/tutorial/kit/redirects"
+ "destination": "https://svelte.jp/tutorial/kit/redirects"
},
{
"source": "/tutorial/handle",
- "destination": "https://svelte.dev/tutorial/kit/handle"
+ "destination": "https://svelte.jp/tutorial/kit/handle"
},
{
"source": "/tutorial/event",
- "destination": "https://svelte.dev/tutorial/kit/event"
+ "destination": "https://svelte.jp/tutorial/kit/event"
},
{
"source": "/tutorial/handlefetch",
- "destination": "https://svelte.dev/tutorial/kit/handlefetch"
+ "destination": "https://svelte.jp/tutorial/kit/handlefetch"
},
{
"source": "/tutorial/handleerror",
- "destination": "https://svelte.dev/tutorial/kit/handleerror"
+ "destination": "https://svelte.jp/tutorial/kit/handleerror"
},
{
"source": "/tutorial/page-options",
- "destination": "https://svelte.dev/tutorial/kit/page-options"
+ "destination": "https://svelte.jp/tutorial/kit/page-options"
},
{
"source": "/tutorial/ssr",
- "destination": "https://svelte.dev/tutorial/kit/ssr"
+ "destination": "https://svelte.jp/tutorial/kit/ssr"
},
{
"source": "/tutorial/csr",
- "destination": "https://svelte.dev/tutorial/kit/csr"
+ "destination": "https://svelte.jp/tutorial/kit/csr"
},
{
"source": "/tutorial/prerender",
- "destination": "https://svelte.dev/tutorial/kit/prerender"
+ "destination": "https://svelte.jp/tutorial/kit/prerender"
},
{
"source": "/tutorial/trailingslash",
- "destination": "https://svelte.dev/tutorial/kit/trailingslash"
+ "destination": "https://svelte.jp/tutorial/kit/trailingslash"
},
{
"source": "/tutorial/preload",
- "destination": "https://svelte.dev/tutorial/kit/preload"
+ "destination": "https://svelte.jp/tutorial/kit/preload"
},
{
"source": "/tutorial/reload",
- "destination": "https://svelte.dev/tutorial/kit/reload"
+ "destination": "https://svelte.jp/tutorial/kit/reload"
},
{
"source": "/tutorial/optional-params",
- "destination": "https://svelte.dev/tutorial/kit/optional-params"
+ "destination": "https://svelte.jp/tutorial/kit/optional-params"
},
{
"source": "/tutorial/rest-params",
- "destination": "https://svelte.dev/tutorial/kit/rest-params"
+ "destination": "https://svelte.jp/tutorial/kit/rest-params"
},
{
"source": "/tutorial/param-matchers",
- "destination": "https://svelte.dev/tutorial/kit/param-matchers"
+ "destination": "https://svelte.jp/tutorial/kit/param-matchers"
},
{
"source": "/tutorial/route-groups",
- "destination": "https://svelte.dev/tutorial/kit/route-groups"
+ "destination": "https://svelte.jp/tutorial/kit/route-groups"
},
{
"source": "/tutorial/breaking-out-of-layouts",
- "destination": "https://svelte.dev/tutorial/kit/breaking-out-of-layouts"
+ "destination": "https://svelte.jp/tutorial/kit/breaking-out-of-layouts"
},
{
"source": "/tutorial/universal-load-functions",
- "destination": "https://svelte.dev/tutorial/kit/universal-load-functions"
+ "destination": "https://svelte.jp/tutorial/kit/universal-load-functions"
},
{
"source": "/tutorial/using-both-load-functions",
- "destination": "https://svelte.dev/tutorial/kit/using-both-load-functions"
+ "destination": "https://svelte.jp/tutorial/kit/using-both-load-functions"
},
{
"source": "/tutorial/await-parent",
- "destination": "https://svelte.dev/tutorial/kit/await-parent"
+ "destination": "https://svelte.jp/tutorial/kit/await-parent"
},
{
"source": "/tutorial/invalidation",
- "destination": "https://svelte.dev/tutorial/kit/invalidation"
+ "destination": "https://svelte.jp/tutorial/kit/invalidation"
},
{
"source": "/tutorial/custom-dependencies",
- "destination": "https://svelte.dev/tutorial/kit/custom-dependencies"
+ "destination": "https://svelte.jp/tutorial/kit/custom-dependencies"
},
{
"source": "/tutorial/invalidate-all",
- "destination": "https://svelte.dev/tutorial/kit/invalidate-all"
+ "destination": "https://svelte.jp/tutorial/kit/invalidate-all"
},
{
"source": "/tutorial/env-static-private",
- "destination": "https://svelte.dev/tutorial/kit/env-static-private"
+ "destination": "https://svelte.jp/tutorial/kit/env-static-private"
},
{
"source": "/tutorial/env-dynamic-private",
- "destination": "https://svelte.dev/tutorial/kit/env-dynamic-private"
+ "destination": "https://svelte.jp/tutorial/kit/env-dynamic-private"
},
{
"source": "/tutorial/env-static-public",
- "destination": "https://svelte.dev/tutorial/kit/env-static-public"
+ "destination": "https://svelte.jp/tutorial/kit/env-static-public"
},
{
"source": "/tutorial/env-dynamic-public",
- "destination": "https://svelte.dev/tutorial/kit/env-dynamic-public"
+ "destination": "https://svelte.jp/tutorial/kit/env-dynamic-public"
},
{
"source": "/tutorial/next-steps",
- "destination": "https://svelte.dev/tutorial/kit/next-steps"
+ "destination": "https://svelte.jp/tutorial/kit/next-steps"
},
{
"source": "/",
- "destination": "https://svelte.dev/tutorial"
+ "destination": "https://svelte.jp/tutorial"
},
{
"source": "/(.*)",
- "destination": "https://svelte.dev/$1"
+ "destination": "https://svelte.jp/$1"
}
]
}
diff --git a/apps/svelte.dev/content/blog/2016-11-26-frameworks-without-the-framework.md b/apps/svelte.dev/content/blog/2016-11-26-frameworks-without-the-framework.md
index 7756f3135a..ea64857d28 100644
--- a/apps/svelte.dev/content/blog/2016-11-26-frameworks-without-the-framework.md
+++ b/apps/svelte.dev/content/blog/2016-11-26-frameworks-without-the-framework.md
@@ -1,51 +1,51 @@
---
-title: "Frameworks without the framework: why didn't we think of this sooner?"
-description: You can't write serious applications in vanilla JavaScript without hitting a complexity wall. But a compiler can do it for you.
+title: "フレームワークの無いフレームワーク: なぜもっと早く思いつかなかったのか"
+description: 純粋なJavaScriptでは、複雑さの壁にぶつかることなく本格的なアプリケーションを書くことはできません。しかしコンパイラならそれができます。
author: Rich Harris
authorURL: https://bsky.app/profile/rich-harris.dev
---
-> Wait, this new framework has a _runtime_? Ugh. Thanks, I'll pass.
+> 待って、この新しいフレームワークには _ランタイム_ があるの？ うーん。ありがとう、やめておくよ。
> **– front end developers in 2018**
-We're shipping too much code to our users. Like a lot of front end developers, I've been in denial about that fact, thinking that it was fine to serve 100kb of JavaScript on page load – just use [one less .jpg!](https://twitter.com/miketaylr/status/227056824275333120) – and that what _really_ mattered was performance once your app was already interactive.
+私たちはあまりに多くのコードをユーザーに配布しています。多くのフロントエンド開発者と同じように私もこの事実を否定し、ページロードの際に 100kb の JavaScript を配布しても問題ないと考えていました。[.jpg を1つ減らせば](https://twitter.com/miketaylr/status/227056824275333120) 良いだけだと。そして _本当に_ 重要なのはアプリケーションがインタラクティブになった後のパフォーマンスだと考えていました。
-But I was wrong. 100kb of .js isn't equivalent to 100kb of .jpg. It's not just the network time that'll kill your app's startup performance, but the time spent parsing and evaluating your script, during which time the browser becomes completely unresponsive. On mobile, those milliseconds rack up very quickly.
+しかし、私は間違っていました。100kb の .js は 100kb の .jpg と同じではありません。アプリの起動時のパフォーマンスを低下させるのはネットワークの時間だけではありません。script の解析と評価にも時間がかかり、その間ブラウザーは完全に無反応になります。モバイルでは、このミリ秒単位の時間があっという間に積み上がります。
-If you're not convinced that this is a problem, follow [Alex Russell](https://bsky.app/profile/infrequently.org) on BlueSky. Alex [hasn't been making many friends in the framework community lately](https://twitter.com/slightlylate/status/728355959022587905), but he's not wrong. But the proposed alternative to using frameworks like Angular, React and Ember – [Polymer](https://www.polymer-project.org/1.0/) – hasn't yet gained traction in the front end world, and it's certainly not for a lack of marketing.
+これが問題であることに納得できないなら、Twitter で [Alex Russell](https://bsky.app/profile/infrequently.org) をフォローしてください。Alex は [最近、フレームワークコミュニティで多くの友人を作ろうとしませんが](https://twitter.com/slightlylate/status/728355959022587905)、彼は間違っていません。しかし、Angular、React、Ember などのフレームワークの代替として提案されている [Polymer](https://www.polymer-project.org/1.0/) は、フロントエンドの世界ではまだ普及していませんし、それは決してマーケティングが不足しているからではありません。
-Perhaps we need to rethink the whole thing.
+おそらく、全てを再考する必要があります。
-## What problem do frameworks _really_ solve?
+## フレームワークが _本当に_ 解決すること
-The common view is that frameworks make it easier to manage the complexity of your code: the framework abstracts away all the fussy implementation details with techniques like virtual DOM diffing. But that's not really true. At best, frameworks _move the complexity around_, away from code that you had to write and into code you didn't.
+フレームワークはコードの複雑さを管理しやすくする、というのが一般的な認識です。フレームワークは仮想DOMの差分検出などの技術によって面倒な実装の詳細を抽象化する、というものです。しかし、実際にはそうではありません。せいぜい、あなたが書かなければならないコードからあなたが書いていないコードに _複雑さを移動させる_ だけです。
-Instead, the reason that ideas like React are so wildly and deservedly successful is that they make it easier to manage the complexity of your _concepts_. Frameworks are primarily a tool for structuring your thoughts, not your code.
+むしろ、React のようなアイデアがこれほど成功した理由は、 _コンセプト_ の複雑さを管理しやすくしているからです。フレームワークはコードではなく思考を構造化するためのツールです。
-Given that, what if the framework _didn't actually run in the browser_? What if, instead, it converted your application into pure vanilla JavaScript, just like Babel converts ES2016+ to ES5? You'd pay no upfront cost of shipping a hefty runtime, and your app would get seriously fast, because there'd be no layers of abstraction between your app and the browser.
+そう考えると、もしそのフレームワークが _実際にはブラウザーで動かない_ としたらどうでしょうか？ 代わりに、Babel が ES2016+ から ES5 に変換するように、アプリケーションを純粋なJavaScriptに変換するとしたら？ 重たいランタイムを配布するための初期コストを支払うことはなく、アプリは本当に高速になります。アプリとブラウザの間の抽象レイヤーがなくなるからです。
## Introducing Svelte
-Svelte is a new framework that does exactly that. You write your components using HTML, CSS and JavaScript (plus a few extra bits you can [learn in under 5 minutes](https://v2.svelte.dev/guide)), and during your build process Svelte compiles them into tiny standalone JavaScript modules. By statically analysing the component template, we can make sure that the browser does as little work as possible.
+Svelte はまさにそれを実現するフレームワークです。HTML、CSS、JavaScript (それと [5分以内に学べる](https://v2.svelte.dev/guide) ちょっとしたこと) でコンポーネントを書き、Svelte がそれをビルドプロセスで小さなスタンドアローンの JavaScript モジュールにコンパイルします。コンポーネントのテンプレートを静的に解析することで、ブラウザーの作業を可能な限り少なくなるようにすることができます。
-The [Svelte implementation of TodoMVC](https://svelte-todomvc.surge.sh/) weighs 3.6kb zipped. For comparison, React plus ReactDOM _without any app code_ weighs about 45kb zipped. It takes about 10x as long for the browser just to evaluate React as it does for Svelte to be up and running with an interactive TodoMVC.
+[Svelte による TodoMVC の実装](https://svelte-todomvc.surge.sh/) は 3.6kb (zipped) です。比較として、 _アプリコードを除いた_ React と ReactDOM はおよそ 45kb (zipped) です。ブラウザーが React を評価するのにかかる時間は、Svelteがインタラクティブな TodoMVC を起動して実行するのにかかる時間の約10倍です。
-And once your app _is_ up and running, according to [js-framework-benchmark](https://github.com/krausest/js-framework-benchmark) **Svelte is fast as heck**. It's faster than React. It's faster than Vue. It's faster than Angular, or Ember, or Ractive, or Preact, or Riot, or Mithril. It's competitive with Inferno, which is probably the fastest UI framework in the world, for now, because [Dominic Gannaway](https://bsky.app/profile/trueadm.dev) is a wizard. (Svelte is slower at removing elements. We're [working on it](https://github.com/sveltejs/svelte/issues/26).)
+そして [js-framework-benchmark](https://github.com/krausest/js-framework-benchmark) によれば、アプリが起動して実行されると **Svelte はとてもつもなく高速です**。React よりも速いです。Vue よりも速いです。Angular、Ember、Ractive、Preact、Riot、Mithrilよりも速いです。今のところ、おそらく世界で最も高速な UI フレームワークである Inferno ([Dominic Gannaway](https://bsky.app/profile/trueadm.dev) は魔法使い(a wizard)なので) に匹敵します。(Svelte は要素の削除が遅いですが、[それについては取り組んでいます](https://github.com/sveltejs/svelte/issues/26))
-It's basically as fast as vanilla JS, which makes sense because it _is_ vanilla JS – just vanilla JS that you didn't have to write.
+基本的には純粋な JS と同じくらい速いです。実際、それは _純粋な JS なので_ 当然です。ただ、純粋な JS を書く必要がないというだけです。
-## But that's not the important thing
+## 本当に重要なことは
-Well, it _is_ important – performance matters a great deal. What's really exciting about this approach, though, is that we can finally solve some of the thorniest problems in web development.
+ええ、パフォーマンスはとても重要です。しかし、このアプローチの本当にエキサイティングなところは、Web 開発におけるいくつかの厄介な問題をついに解決できることです。
-Consider interoperability. Want to `npm install cool-calendar-widget` and use it in your app? Previously, you could only do that if you were already using (a correct version of) the framework that the widget was designed for – if `cool-calendar-widget` was built in React and you're using Angular then, well, hard cheese. But if the widget author used Svelte, apps that use it can be built using whatever technology you like. (On the TODO list: a way to convert Svelte components into web components.)
+相互運用性について考えてみてください。`npm install cool-calendar-widget` を実行してアプリで使いたいですか？ これまでは、そのウィジェットがそのフレームワーク向けにデザインされていて、あなたがそのフレームワーク(の正しいバージョン)を使っているときに限りそれが可能でした。もし `cool-calendar-widget` が React で作られており、あなたが Angular を使っていたら、まあ、残念でしたね。しかし、もしそのウィジェットの作者が Svelte を使用した場合、そのウィジェットを使用するアプリを好きなテクノロジーで構築することができます。(TODOリスト : Svelte コンポーネントを Web Components に変換する方法)
-Or [code splitting](https://twitter.com/samccone/status/797528710085652480). It's a great idea (only load the code the user needs for the initial view, then get the rest later), but there's a problem – even if you only initially serve one React component instead of 100, _you still have to serve React itself_. With Svelte, code splitting can be much more effective, because the framework is embedded in the component, and the component is tiny.
+他には、[コード分割](https://twitter.com/samccone/status/797528710085652480) があります。これは素晴らしいアイデア (初期表示に必要なコードだけをロードし、残りは後で取得する) ですが、問題があります。100個の React コンポーネントではなく、最初に1個の React コンポーネントを配布するだけでも、 _React自体を配布しなければなりません_ 。Svelteでは、フレームワークはコンポーネントに埋め込まれており、そのコンポーネントは小さいため、コード分割がより効果的です。
-Finally, something I've wrestled with a great deal as an open source maintainer: your users always want _their_ features prioritised, and underestimate the cost of those features to people who don't need them. A framework author must always balance the long-term health of the project with the desire to meet their users' needs. That's incredibly difficult, because it's hard to anticipate – much less articulate – the consequences of incremental bloat, and it takes serious soft skills to tell people (who may have been enthusiastically evangelising your tool up to that point) that their feature isn't important enough. But with an approach like Svelte's, many features can be added with absolutely no cost to people who don't use them, because the code that implements those features just doesn't get generated by the compiler if it's unnecessary.
+最後に、オープンソースのメンテナーとして悪戦苦闘してきたこと。ユーザーは常に自分の機能を優先してほしいし、その機能を必要としていない人に対してその機能のコストを低く見積もります。フレームワークの作者は、プロジェクトの長期的な健全性と、ユーザーのニーズを満たしたいという欲求との間でバランスを常に取り続けなければなりません。これはとてつもなく難しいことです。なぜなら、少しずつ大きくなっていく成果・結果を予測したりすることはできないですし、ましてや明確にすることは不可能です。また、(それまで熱狂的にツールを伝道してきた)人たちに、それらの機能に重要な部分が足りていないと伝えるには本格的なソフトスキルが必要です。しかし Svelte のようなアプローチでは、使用していない機能のコードはコンパイラによって生成されないため、多くの機能を追加しても、その機能を必要としていない人にそのコストを与えることは全くありません。
-## We're just getting started
+## まだ始まったばかり
-Svelte is very new. There's a lot of work still left to do – creating build tool integrations, adding a server-side renderer, hot reloading, transitions, more documentation and examples, starter kits, and so on.
+Svelteは非常に新しいです。ビルドツールのインテグレーション作成、サーバーサイドレンダラー、ホットリロード、トランジション、ドキュメントやサンプルの追加、スターターキットなど、まだまだやるべきことがたくさんあります。
-But you can already build rich components with it, which is why we've gone straight to a stable 1.0.0 release. [Read the guide](https://v2.svelte.dev/guide), [try it out in the REPL](/repl), and head over to [GitHub](https://github.com/sveltejs/svelte) to help kickstart the next era of front end development.
+しかし、すでにリッチなコンポーネントを構築することができます。それが stable な 1.0.0 のリリースに至った理由です。[ガイドを読み](https://v2.svelte.dev/guide)、[REPL で試して](/repl)、そして [GitHub](https://github.com/sveltejs/svelte) にアクセスして、次世代のフロントエンド開発をスタートしてください。
diff --git a/apps/svelte.dev/content/blog/2017-12-31-sapper-towards-the-ideal-web-app-framework.md b/apps/svelte.dev/content/blog/2017-12-31-sapper-towards-the-ideal-web-app-framework.md
index 228c149ddd..224c371ecd 100644
--- a/apps/svelte.dev/content/blog/2017-12-31-sapper-towards-the-ideal-web-app-framework.md
+++ b/apps/svelte.dev/content/blog/2017-12-31-sapper-towards-the-ideal-web-app-framework.md
@@ -1,80 +1,80 @@
---
-title: 'Sapper: Towards the ideal web app framework'
-description: Taking the next-plus-one step
+title: "Sapper: 理想の Web アプリケーションフレームワークを目指して"
+description: 次の一歩を踏み出す
author: Rich Harris
authorURL: https://bsky.app/profile/rich-harris.dev
---
-> Quickstart for the impatient: [the Sapper docs](https://sapper.svelte.dev), and the [starter template](https://github.com/sveltejs/sapper-template)
+> せっかちな人のためのクイックスタート: [Sapper のドキュメント](https://sapper.svelte.dev)、[スターターテンプレート](https://github.com/sveltejs/sapper-template)
-If you had to list the characteristics of the perfect Node.js web application framework, you'd probably come up with something like this:
+もし完璧な Node.js の Web アプリケーションフレームワークの特徴を挙げるとしたら、次のようなものを思いつくでしょう:
-1. It should do server-side rendering, for fast initial loads and no caveats around SEO
-2. As a corollary, your app's codebase should be universal — write once for server _and_ client
-3. The client-side app should _hydrate_ the server-rendered HTML, attaching event listeners (and so on) to existing elements rather than re-rendering them
-4. Navigating to subsequent pages should be instantaneous
-5. Offline, and other Progressive Web App characteristics, must be supported out of the box
-6. Only the JavaScript and CSS required for the first page should load initially. That means the framework should do automatic code-splitting at the route level, and support dynamic `import(...)` for more granular manual control
-7. No compromise on performance
-8. First-rate developer experience, with hot module reloading and all the trimmings
-9. The resulting codebase should be easy to grok and maintain
-10. It should be possible to understand and customise every aspect of the system — no webpack configs locked up in the framework, and as little hidden 'plumbing' as possible
-11. Learning the entire framework in under an hour should be easy, and not just for experienced developers
+1. 最初の読み込みの高速化や SEO 対策に支障をきたさないために、サーバーサイドレンダリングを行う
+2. 当然の結果として、アプリケーションのコードベースは普遍的である — サーバーとクライアント _共通_ で1度だけコードを書く
+3. クライアントサイドのアプリは、サーバーでレンダリングされた HTML を再レンダリングすると言うより既存の要素にイベントリスナ（などなど）をアタッチして _ハイドレート_ する
+4. 瞬時に次のページに移動できる
+5. オフラインや、その他のプログレッシブウェブアプリの特徴をすぐにサポートしている
+6. 最初のページに必要な JavaScript と CSS のみが最初に読み込まれる。 つまり、フレームワークはルートレベルで自動的にコード分割を行い、より細かい手動制御のために動的な `import(...)` をサポートしている
+7. パフォーマンスに妥協がない
+8. ホットモジュールリローディングやその他痒い所に手が届く様々な機能など、最高の開発環境を提供している
+9. 出来上がったコードベースは、理解しやすくメンテナンス性が高い
+10. システムのあらゆる側面を理解し、カスタマイズをすることができる — webpack の設定をフレームワークの中に閉じ込めず、できるだけ隠された「配管」を少なくしている
+11. フレームワーク全体を1時間以内に学習することは、経験豊富な開発者でなくても簡単にできる
-[Next.js](https://github.com/zeit/next.js) is close to this ideal. If you haven't encountered it yet, I strongly recommend going through the tutorials at [learnnextjs.com](https://learnnextjs.com). Next introduced a brilliant idea: all the pages of your app are files in a `your-project/pages` directory, and each of those files is just a React component.
+[Next.js](https://github.com/zeit/next.js) はこの理想に近いです。 もし Next.js に出会ったことがないなら、 [learnnextjs.com](https://learnnextjs.com) でチュートリアルを見てみることを強くおすすめします。 Next は素晴らしいアイディアをご紹介します: あなたのアプリケーションの全ページは `your-project/pages` ディレクトリにあるファイルで、それらのファイルのそれぞれが React のコンポーネントです。
-Everything else flows from that breakthrough design decision. Finding the code responsible for a given page is easy, because you can just look at the filesystem rather than playing 'guess the component name'. Project structure bikeshedding is a thing of the past. And the combination of SSR (server-side rendering) and code-splitting — something the React Router team [gave up on](https://reacttraining.com/react-router/web/guides/code-splitting), declaring 'Godspeed those who attempt the server-rendered, code-split apps' — is trivial.
+それ以外のことについては、この画期的な設計の方針に基づいています。「コンポーネント名推測ゲーム」をして遊ぶわけではなくファイルシステムを見るだけでいいので、特定のページを受け持つコードを見つけるのは簡単です。 プロジェクトの構造のことで無駄に細かいことを考える必要がある時代は終わりました。 また、 SSR（サーバーサイドレンダリング）とコード分割の組み合わせは (React Router チームが「サーバーでレンダリングされ、コード分割されたアプリに挑戦する人たちに神の祝福あれ」と言って[断念した](https://reacttraining.com/react-router/web/guides/code-splitting)ものではありますが) 些細なことです。
-But it's not perfect. As churlish as it might be to list the flaws in something _so, so good_, there are some:
+それでも、完璧なわけではありません。 _とても素晴らしいもの_ の粗探しをするのは無粋かもしれませんが、いくつか挙げられます:
-- Next uses something called 'route masking' to create nice URLs (e.g. `/blog/hello-world` instead of `/post?slug=hello-world`). This undermines the guarantee about directory structure corresponding to app structure, and forces you to maintain configuration that translates between the two forms
-- All your routes are assumed to be universal 'pages'. But it's very common to need routes that only render on the server, such as a 301 redirect or an API endpoint that serves the data for your pages, and Next doesn't have a great solution for this. You can add logic to your `server.js` file to handle these cases, but it feels at odds with the declarative approach taken for pages
-- To use the client-side router, links can't be standard `` tags. Instead, you have to use framework-specific `` components, which is impossible in the markdown content for a blog post such as this one, for example
+- Next は「ルートマスキング」と呼ばれる機能を使ってイケてる URL を生成します (例えば `/post?slug=hello-world` の代わりに `/blog/hello-world`)。 これは、アプリケーションの構造に対するディレクトリ構造の保証を損なうものであり、2つの構造の形式の間で変換する設定を維持する必要があります。
+- 全てのルーティングは普遍的な「ページ」であると想定されます。 しかしながら、 301 redirect やページにデータを提供する API エンドポイントのような、サーバーでのみレンダリングされるルーティングが必要になることは一般的にあることで、 Next はこれに関して良い解決策を持っていません。 こういったケースを処理するために `server.js` ファイルにロジックを追加することはできますが、これはページの宣言的なアプローチに相反するものです。
+- クライアントサイドのルーティングを利用する場合、リンクに標準的な `` タグを使うことができません。 代わりに、例えば本ブログ記事のようなマークダウンコンテンツでは利用不可能な、フレームワーク固有の `` コンポーネントを使わなければいけません
-The real problem, though, is that all that goodness comes for a price. The simplest possible Next app — a single 'hello world' page that renders some static text — involves 66kb of gzipped JavaScript. Unzipped, it's 204kb, which is a non-trivial amount of code for a mobile device to parse at a time when performance is a critical factor determining whether or not your users will stick around. And that's the _baseline_.
+しかしながら、実際の問題として、これらのような良い機能には代償が伴います。 もっともシンプルな Next のアプリケーションは、 — 静的なテキストを表示する「hello world」ページですが — 66kb の 圧縮された JavaScript を含みます。 解凍すると 204kb になりますが、これは、パフォーマンスがユーザーの定着率を左右する重要な要素であるときに、モバイルデバイスが一度に解析するには大きく問題のあるコードの量です。 そして、これが _ベースライン_ になります。
-We can do better!
+私たちなら、もっとより良くできます！
-## The compiler-as-framework paradigm shift
+## フレームワークパラダイムシフトとしてのコンパイラ
-[Svelte introduced a radical idea](/blog/frameworks-without-the-framework): what if your UI framework wasn't a framework at all, but a compiler that turned your components into standalone JavaScript modules? Instead of using a library like React or Vue, which knows nothing about your app and must therefore be a one-size-fits-all solution, we can ship highly-optimised vanilla JavaScript. Just the code your app needs, and without the memory and performance overhead of solutions based on a virtual DOM.
+[Svelte は根本的な思想を紹介しています](/blog/frameworks-without-the-framework): UIフレークワークがフレームワークではなく、コンポーネントをスタンドアロンな JavaScript モジュールに変換するコンパイラだったらどうですか？React や Vue のような、アプリのことを何も知らず無難なソリューションにならざるを得ないライブラリを使う代わりに、私たちは高度に最適化された純粋な JavaScript を送り出すことができます。 アプリケーションに必要なコードだけで、仮想DOMをベースとしたソリューションのようなメモリやパフォーマンスのオーバーヘッドはありません。
-The JavaScript world is [moving towards this model](https://tomdale.net/2017/09/compilers-are-the-new-frameworks/). [Stencil](https://stenciljs.com), a Svelte-inspired framework from the Ionic team, compiles to web components. [Glimmer](https://glimmerjs.com) _doesn't_ compile to standalone JavaScript (the pros and cons of which deserve a separate blog post), but the team is doing some fascinating research around compiling templates to bytecode. (React is [getting in on the action](https://twitter.com/trueadm/status/944908776896978946), though their current research focuses on optimising your JSX app code, which is arguably more similar to the ahead-of-time optimisations that Angular, Ractive and Vue have been doing for a few years.)
+JavaScript の世界は [このモデルに向かっています](https://tomdale.net/2017/09/compilers-are-the-new-frameworks/)。 [Stencil](https://stenciljs.com) は Ionic のチームによる Svelte からインスピレーションを受けたフレームワークで、 Web コンポーネントにコンパイルされます。 [Glimmer](https://glimmerjs.com) は スタンドアロンな JavaScript にコンパイル _するわけではありませんが_ (その長所と短所については、別のブログの記事にしたいと思います)、このチームはテンプレートをバイトコードにコンパイルすることについての興味深い研究を行なっています。 (React は [このような動きに足を踏み入れていますが](https://twitter.com/trueadm/status/944908776896978946)、彼らの現在の研究は JSX で書かれたアプリケーションのコードを最適化することに焦点を当てており、これは間違いなく Angular、 Ractive、 そして Vue がここ数年で行なっている事前最適化によく似たものです)
-What happens if we use the new model as a starting point?
+私たちがこの新しいモデルを出発点として用いるとどうなるのでしょうか？
-## Introducing Sapper
+## Sapper の紹介
-
+
-[Sapper](https://sapper.svelte.dev) is the answer to that question. **Sapper is a Next.js-style framework that aims to meet the eleven criteria at the top of this article while dramatically reducing the amount of code that gets sent to the browser.** It's implemented as Express-compatible middleware, meaning it's easy to understand and customise.
+[Sapper](https://sapper.svelte.dev) はその問いへの答えです。 **Sapper は Next.js スタイルのフレームワークで、この記事の上部にある11の基準を満たしつつ、ブラウザに送信されるコードの量を劇的に減らすことを目的としています。** Express と互換性のあるミドルウェアとして実装されているため、理解しやすく、カスタマイズも容易に行えます。
-The same 'hello world' app that took 204kb with React and Next weighs just 7kb with Sapper. That number is likely to fall further in the future as we explore the space of optimisation possibilities, such as not shipping any JavaScript _at all_ for pages that aren't interactive, beyond the tiny Sapper runtime that handles client-side routing.
+同じ「hello world」のアプリケーションでも、React や Next では 204kb もあったものが、 Sapper ではたったの 7kb です。 クライアントサイドのルーティングを処理する Sapper のごく僅かなランタイムを除いて、インタラクティブではないページでは _一切の_ JavaScript を読み込まないなどの最適化の可能性を探っていくうちに、将来的にこの数字はさらに小さくなっていくでしょう。
-What about a more 'real world' example? Conveniently, the [RealWorld](https://github.com/gothinkster/realworld) project, which challenges frameworks to develop an implementation of a Medium clone, gives us a way to find out. The [Sapper implementation](https://github.com/sveltejs/realworld) takes 39.6kb (11.8kb zipped) to render an interactive homepage.
+さらに、「RealWorld」の例はどうでしょうか？ 好都合なことに、 Medium クローンの実装をフレームワークで開発するという [RealWorld](https://github.com/gothinkster/realworld) プロジェクトでは、その結果を知ることができます。 [Sapper での実装](https://github.com/sveltejs/realworld) では、インタラクティブなホームページを表示するのに 39.6kb (zip形式では 11.8kb) かかります。
-
+
-The entire app costs 132.7kb (39.9kb zipped), which is significantly smaller than the reference React/Redux implementation at 327kb (85.7kb), but even if it was as large it would _feel_ faster because of code-splitting. And that's a crucial point. We're told we need to code-split our apps, but if your app uses a traditional framework like React or Vue then there's a hard lower bound on the size of your initial code-split chunk — the framework itself, which is likely to be a significant portion of your total app size. With the Svelte approach, that's no longer the case.
+アプリ全体のコストは 132.7kb (zip形式で 39.9kb) で、リファレンスの React/Redux での実装の 327kb (85.7kb) よりは著しく小さいですが、例え同じくらいの大きさであってもコード分割のおかげで _体感的には_ 速くなっています。そしてこれが重要なポイントです。 アプリケーションではコード分割をする必要があると言われていますが、 React や Vue のような伝統的なフレームワークを利用している場合、最初にコードを分割するチャンクのサイズには厳しい下限があります — フレームワーク自体がアプリ全体のサイズの中で大部分を占めていると考えられるからです。 Svelte のアプローチは、もはやそのようなことはありません。
-But size is only part of the story. Svelte apps are also extremely performant and memory-efficient, and the framework includes powerful features that you would sacrifice if you chose a 'minimal' or 'simple' UI library.
+しかしサイズの話は物語の一部に過ぎません。 また、 Svelte アプリケーションはパフォーマンスやメモリ効率が非常に高く、「ミニマル」や「シンプル」なUIライブラリを選択した場合に犠牲にしてしまうような強力な機能がこのフレームワークには含まれています。
-## Trade-offs
+## トレードオフ
-The biggest drawback for many developers evaluating Sapper would be 'but I like React, and I already know how to use it', which is fair.
+多くの開発者が Sapper を評価する際の最大の難点は、「それでも React は好きだし、使い方もすでに知ってるよ」ということでしょうが、それは妥当なことです。
-If you're in that camp, I'd invite you to at least try alternative frameworks. You might be pleasantly surprised! The [Sapper RealWorld](https://github.com/sveltejs/realworld) implementation totals 1,201 lines of source code, compared to 2,377 for the reference implementation, because you're able to express concepts very concisely using Svelte's template syntax (which [takes all of five minutes to master](https://v2.svelte.dev/guide#template-syntax)). You get [scoped CSS](/blog/the-zen-of-just-writing-css), with unused style removal and minification built-in, and you can use preprocessors like LESS if you want. You no longer need to use Babel. SSR is ridiculously fast, because it's just string concatenation. And we recently introduced [svelte/store](https://v2.svelte.dev/guide#state-management), a tiny global store that synchronises state across your component hierarchy with zero boilerplate. The worst that can happen is that you'll end up feeling vindicated!
+そんな方々には、ぜひ代替フレームワークを試していただきたいと思います。 嬉しい驚きがあるかも知れません！ [Sapper による RealWorld](https://github.com/sveltejs/realworld) の実装ではソースコードの総行数が 1,201 行なのに対し、リファレンスでの実装では 2,377 行となっています。 これは、Svelte のテンプレート構文を使って概念を非常に簡潔に表現できるからで、[5分もあればマスターできます](https://v2.svelte.dev/guide#template-syntax)。 使われていないスタイルの削除と縮小化が組み込まれた[scoped CSS](/blog/the-zen-of-just-writing-css)を取得し、必要に応じて LESS のようなプリプロセッサを使用することができます。 Babel を使用する必要はありません。 SSR は、文字列を連結するだけなのでとてつもなく高速です。 また、最近導入した [svelte/store](https://v2.svelte.dev/guide#state-management)は、コンポーネント階層間で状態を同期させる小さなグローバルストアです。 最悪の場合、自分の正当性が証明されたような気になってしまうかも知れませんね！
-But there are trade-offs nonetheless. Some people have a pathological aversion to any form of 'template language', and maybe that applies to you. JSX proponents will clobber you with the 'it's just JavaScript' mantra, and therein lies React's greatest strength, which is that it is infinitely flexible. That flexibility comes with its own set of trade-offs, but we're not here to discuss those.
+とは言え、トレードオフもあります。 いかなる「テンプレート言語」にも病的なまでに嫌悪感を抱く人がいますが、もしかしたらあなたも当てはまるかも知れません。 JSX の支持者は「それはただの JavaScript だ」と酷評するでしょうが、そこには React の最大の強みである、無限の柔軟性があるのです。 そのような柔軟性にはトレードオフがつきものですが、ここでそれについて議論するつもりはありません。
-And then there's _ecosystem_. The universe around React in particular — the devtools, editor integrations, ancillary libraries, tutorials, StackOverflow answers, hell, even job opportunities — is unrivalled. While it's true that citing 'ecosystem' as the main reason to choose a tool is a sign that you're stuck on a local maximum, apt to be marooned by the rising waters of progress, it's still a major point in favour of incumbents.
+そして、 _エコシステム_ があります。 特に React を取り巻く世界では、開発ツール、統合開発環境、付属ライブラリ、チュートリアル、 StackOverflow の回答、就職の機会に至るまで、他の追随を許さないものとなっています。 確かに、ツールを選ぶ主な理由として「エコシステム」を挙げるのは、無難な位置にとどまってしまっていて進歩の波に取り残されがちであることを示していますが、それでも既存の企業にとっては大きなポイントになります。
-## Roadmap
+## ロードマップ
-We're not at version 1.0.0 yet, and a few things may change before we get there. Once we do (soon!), there are a lot of exciting possibilities.
+まだバージョン 1.0.0 ではありませんし、そこに辿り着くまでにいくつか修正する点があるかも知れません。 それが実現した暁には (もうすぐです！)、ワクワクするようなたくさんの可能性を秘めているでしょう。
-I believe the next frontier of web performance is 'whole-app optimisation'. Currently, Svelte's compiler operates at the component level, but a compiler that understood the boundaries _between_ those components could generate even more efficient code. The React team's [Prepack research](https://twitter.com/trueadm/status/944908776896978946) is predicated on a similar idea, and the Glimmer team is doing some interesting work in this space. Svelte and Sapper are well positioned to take advantage of these ideas.
+私は、 Web パフォーマンスにおける次の新天地は「アプリケーション全体の最適化」だと考えています。 現在、 Svelte のコンパイラはコンポーネントレベルで動作していますが、_コンポーネント間_ の境界を解釈することができるコンパイラがあれば、より効率的なコードを生成することができます。 React チームの [Prepack の研究](https://twitter.com/trueadm/status/944908776896978946) も同様の考え方に基づいていますし、 Glimmer チームもこの分野で興味深い研究を行なっています。 Svelte と Sapper はこれらのアイディアを活かすことのできるポジションにいます。
-Speaking of Glimmer, the idea of compiling components to bytecode is one that we'll probably steal in 2018. A framework like Sapper could conceivably determine which compilation mode to use based on the characteristics of your app. It could even serve JavaScript for the initial route for the fastest possible startup time, then lazily serve a bytecode interpreter for subsequent routes, resulting in the optimal combination of startup size and total app size.
+Glimmerといえば、コンポーネントをバイトコードにコンパイルするというアイディアは、2018年にはおそらく盗むことになるでしょう。 Sapper のようなフレームワークは、アプリの特性に応じてどのコンパイルモードを使うかを決めることができます 。 初回のルーティングでは JavaScript を提供して起動時間を最短にし、その後のルーティングではバイトコードインタプリタを遅延なく提供することで、起動サイズとアプリ全体のサイズの最適な組み合わせを実現することもできます。
-Mostly, though, we want the direction of Sapper to be determined by its users. If you're the kind of developer who enjoys life on the bleeding edge and would like to help shape the future of how we build web apps, please join us on [GitHub](https://github.com/sveltejs/svelte) and [Discord](/chat).
+とは言え、 Sapper の方向性の大部分はユーザーに決めてもらいたいと考えています。あなたが最先端の生活を楽しみ、 Web アプリケーションの構築方法の未来を形作る手助けをしたいと思っている開発者であれば、ぜひ私たちの [GitHub](https://github.com/sveltejs/svelte) や [Discord](/chat) に参加してください。
diff --git a/apps/svelte.dev/content/blog/2018-12-27-virtual-dom-is-pure-overhead.md b/apps/svelte.dev/content/blog/2018-12-27-virtual-dom-is-pure-overhead.md
index 9aece76947..a462b534b3 100644
--- a/apps/svelte.dev/content/blog/2018-12-27-virtual-dom-is-pure-overhead.md
+++ b/apps/svelte.dev/content/blog/2018-12-27-virtual-dom-is-pure-overhead.md
@@ -1,26 +1,30 @@
---
-title: Virtual DOM is pure overhead
-description: Let's retire the 'virtual DOM is fast' myth once and for all
+title: 仮想DOMは純粋なオーバーヘッド(Virtual DOM is pure overhead)
+description: "'仮想DOMは速い'という神話を完全に終わりにしよう"
author: Rich Harris
authorURL: https://bsky.app/profile/rich-harris.dev
---
-If you've used JavaScript frameworks in the last few years, you've probably heard the phrase 'the virtual DOM is fast', often said to mean that it's faster than the _real_ DOM. It's a surprisingly resilient meme — for example people have asked how Svelte can be fast when it doesn't use a virtual DOM.
+ここ数年でJavaScriptフレームワークを使ったことがある人なら、'仮想DOMは速い' というフレーズを聞いたことがあるでしょう、これはしばしば、実際のDOMよりも速い、という意味で言われることがあります。これは驚くほどしぶといミームです — 例えば、どうやってSvelteは仮想DOMを使わずに高速にできるのかを尋ねられることがありました。
-It's time to take a closer look.
+では、じっくり見ていきましょう。
-## What is the virtual DOM?
+## 仮想DOMとは？
-In many frameworks, you build an app by creating `render()` functions, like this simple [React](https://reactjs.org/) component:
+多くのフレームワークで、`render()`関数を作ってアプリを構築します。例えばシンプルな [React](https://reactjs.org/) コンポーネントでは:
-```ts
+```js
// @noErrors
function HelloMessage(props) {
- return
`, which means we can keep the same DOM node
-2. We enumerate all the attributes on the old `
` and the new one to see if any need to be changed, added or removed. In both cases we have a single attribute — a `className` with a value of `"greeting"`
-3. Descending into the element, we see that the text has changed, so we'll need to update the real DOM
+1. どちらのスナップショットにも単一の要素が含まれています。どちらの場合もそれは `
` であり、同じ DOM ノードを維持できることを意味します。
+2. 古い `
` と新しい `
` のすべての属性を列挙して、変更、追加、削除する必要があるか調べます。どちらも、値が `"greeting"` の `className` 属性だけがあります。
+3. 要素に降りていくと、テキストが変更されていることがわかるので、実際のDOMを更新する必要があります。
-Of these three steps, only the third has value in this case, since — as is the case in the vast majority of updates — the basic structure of the app is unchanged. It would be much more efficient if we could skip straight to step 3:
+この3つのステップのうち、今回のケースでは3番目のステップだけが価値を持ちます、というのも — ほとんどの更新がそうであるように — アプリの基本構造は変わっていないからです。3番目のステップに直接進むことができれば、より効率的です:
```js
// @noErrors
@@ -82,11 +88,12 @@ if (changed.name) {
}
```
-(This is almost exactly the update code that Svelte generates. Unlike traditional UI frameworks, Svelte is a compiler that knows at _build time_ how things could change in your app, rather than waiting to do the work at _run time_.)
+(これはSvelteが生成する更新のコードとほぼ同じです。従来のUIフレームワークとは異なり、Svelteは、 _実行時_ にこの作業をするのを待つのではなく、どのように変更されるか _ビルド時_ にわかるコンパイラです)
+
-## It's not just the diffing though
+## 差分検出だけではありません
-The diffing algorithms used by React and other virtual DOM frameworks are fast. Arguably, the greater overhead is in the components themselves. You wouldn't write code like this...
+Reactや他の仮想DOMフレームワークで使われている差分検出アルゴリズムは高速です。議論の余地はありますが、より大きなオーバーヘッドはコンポーネント自体にあります。こんなコードは普通書かないと思います…
```js
// @noErrors
@@ -97,7 +104,7 @@ function StrawManComponent(props) {
}
```
-...because you'd be carelessly recalculating `value` on every update, regardless of whether `props.foo` had changed. But it's extremely common to do unnecessary computation and allocation in ways that seem much more benign:
+…なぜなら、`props.foo` が変更されたかどうかに関わらず、更新のたびに不注意に `value` を再計算してしまうからです。しかし、もっと無害に見える方法で、不必要な計算やアロケーションが行われてしまうことは非常に一般的です:
```js
// @noErrors
@@ -120,16 +127,16 @@ function MoreRealisticComponent(props) {
}
```
-Here, we're generating a new array of virtual `
` elements — each with their own inline event handler — on every state change, regardless of whether `props.items` has changed. Unless you're unhealthily obsessed with performance, you're not going to optimise that. There's no point. It's plenty fast enough. But you know what would be even faster? _Not doing that._
+ここでは、`props.items` が変化したかどうかに関わらず、仮想的な `
` 要素の新しい配列（それぞれがインラインのイベントハンドラを持つ）をそれぞれの状態が変化するたびに生成しています。よっぽどパフォーマンスにこだわっていない限り、これを最適化することはないでしょう。意味がありません。これで十分に速いのですから。しかし、さらに速い方法がわかりますか？ _こうしないことです_ 。
-
+
-The danger of defaulting to doing unnecessary work, even if that work is trivial, is that your app will eventually succumb to 'death by a thousand cuts' with no clear bottleneck to aim at once it's time to optimise.
+デフォルトで不必要な作業を行うことは危険で、たとえその作業が些細なものであっても、最適化の際に明確なボトルネックがないためにアプリがやがて 'じわじわと破滅に向かう'(原文 : death by a thousand cuts)ことに屈してしまいます。
-Svelte is explicitly designed to prevent you from ending up in that situation.
+Svelteは、そのような状況に陥らないよう明示的に設計されています。
-## Why do frameworks use the virtual DOM then?
+## では、なぜフレームワークは仮想DOMを使うのか？
-It's important to understand that virtual DOM _isn't a feature_. It's a means to an end, the end being declarative, state-driven UI development. Virtual DOM is valuable because it allows you to build apps without thinking about state transitions, with performance that is _generally good enough_. That means less buggy code, and more time spent on creative tasks instead of tedious ones.
+重要なのは、仮想DOMは _機能ではない_ ということです。それは目的を達成するための手段であり、その目的とは宣言的で状態駆動型のUI開発です。仮想DOMは、状態遷移を考えることなくアプリケーションを開発できるようにし、 _一般的には十分な_ パフォーマンスを得られるという点で価値があります。つまり、バグを減らし、退屈な作業ではなく創造的な作業に多くの時間を費やすことができるようになります。
-But it turns out that we can achieve a similar programming model without using virtual DOM — and that's where Svelte comes in.
+しかし、仮想DOMを使用せずに同様のプログラミングモデルを実現できることがわかりました — つまりSvelteの登場です。
diff --git a/apps/svelte.dev/content/blog/2019-04-20-write-less-code.md b/apps/svelte.dev/content/blog/2019-04-20-write-less-code.md
index edb8796d45..39caf1f3c7 100644
--- a/apps/svelte.dev/content/blog/2019-04-20-write-less-code.md
+++ b/apps/svelte.dev/content/blog/2019-04-20-write-less-code.md
@@ -1,21 +1,21 @@
---
-title: Write less code
-description: The most important metric you're not paying attention to
+title: コード量を減らす(Write less code)
+description: 注意が払われていない最も重要な指標について
author: Rich Harris
authorURL: https://bsky.app/profile/rich-harris.dev
---
-All code is buggy. It stands to reason, therefore, that the more code you have to write the buggier your apps will be.
+全てのコードにはバグが存在する可能性があります(All code is buggy)。したがって、書かなければいけないコードが多ければ多いほど、アプリケーションがバグだらけになるのは理にかなっています。
-Writing more code also takes more time, leaving less time for other things like optimisation, nice-to-have features, or being outdoors instead of hunched over a laptop.
+多くのコードを書くには多くの時間がかかるので、他のこと(例えば最適化や、良い機能を開発すること、またはPCの前に座らずに外出することなど)に充てられる時間は少なくなります。
-In fact it's widely acknowledged that [project development time](https://blog.codinghorror.com/diseconomies-of-scale-and-lines-of-code/) and [bug count](https://www.mayerdan.com/ruby/2012/11/11/bugs-per-line-of-code-ratio) grow _quadratically_, not linearly, with the size of a codebase. That tracks with our intuitions: a ten-line pull request will get a level of scrutiny rarely applied to a 100-line one. And once a given module becomes too big to fit on a single screen, the cognitive effort required to understand it increases significantly. We compensate by refactoring and adding comments — activities that almost always result in _more_ code. It's a vicious cycle.
+実際、[プロジェクトの開発時間](https://blog.codinghorror.com/diseconomies-of-scale-and-lines-of-code/) と [バグ件数](https://www.mayerdan.com/ruby/2012/11/11/bugs-per-line-of-code-ratio) はコードベースのサイズに対して直線的ではなく _二次関数的_ に増加することが広く知られています。これは私たちの直感と一致しています : 10行のプルリクエストは、100行のプルリクエストだと有り得ないレベルで精査されるでしょう。また、モジュールが1つの画面に収まりきらないほど大きくなると、それを理解するために必要な認知的努力が著しく増大します。リファクタリングし、コメントを追加することでこの問題に対応しようとしますが、ほとんどの場合コードがもっと増加してしまいます。悪循環です。
-Yet while we obsess — rightly! — over performance numbers, bundle size and anything else we can measure, we rarely pay attention to the amount of code we're writing.
+しかし、私たちはパフォーマンスの数値やバンドルサイズ、その他計測できるものはなんでも気にかける一方で、書いているコードの量に注意を払うことはほとんどありません。
-## Readability is important
+## 重要なのは読みやすさ(Readability is important)
-I'm certainly not claiming that we should use clever tricks to scrunch our code into the most compact form possible at the expense of readability. Nor am I claiming that reducing _lines_ of code is necessarily a worthwhile goal, since it encourages turning readable code like this...
+巧妙なトリックを使って読みやすさを犠牲にしてでもできるだけコードをコンパクトにするべきだ、と主張しているわけではありません。また、コードの _行数_ を減らすことこそが価値のある目標であると主張しているわけでもありません、このような主張は、例えば次のような読みやすいコードを…
```js
for (let i = 0; i <= 100; i += 1) {
@@ -25,17 +25,17 @@ for (let i = 0; i <= 100; i += 1) {
}
```
-...into something much harder to parse:
+…次のように解析がより難しいものに変えるよう促してしまいます:
```js
for (let i = 0; i <= 100; i += 1) if (i % 2 === 0) console.log(`${i} is even`);
```
-Instead, I'm claiming that we should favour languages and patterns that allow us to naturally write less code.
+代わりに、自然とコードが少なくなるような言語とパターンを好むべきだと主張します。
-## Yes, I'm talking about Svelte
+## はい、Svelteについて話しています
-Reducing the amount of code you have to write is an explicit goal of Svelte. To illustrate, let's look at a very simple component implemented in React, Vue and Svelte. First, the Svelte version:
+書かなければいけないコードの量を減らすことは、Svelteの明確な目標です。説明のために、React、Vue、Svelteでそれぞれ実装されたシンプルなコンポーネントを見てみましょう。まずはSvelteのバージョンです:
-How would we build this in React? It would probably look something like this:
+これをReactで構築するには？ おそらく次のようになるでしょう:
```js
// @noErrors
@@ -76,7 +76,7 @@ export default () => {
};
```
-Here's an equivalent component in Vue:
+Vueで同等のことをやると次のようになります:
```svelte
@@ -101,22 +101,22 @@ Here's an equivalent component in Vue:
```
-In other words, it takes 442 characters in React, and 263 characters in Vue, to achieve something that takes 145 characters in Svelte. The React version is literally three times larger!
+つまり、Svelteだと145文字でできることが、Reactだと442文字、Vueだと263文字かかります。Reactバージョンは文字通り3倍大きいです！
-It's unusual for the difference to be _quite_ so obvious — in my experience, a React component is typically around 40% larger than its Svelte equivalent. Let's look at the features of Svelte's design that enable you to express ideas more concisely:
+ここまで差がつくのは中々珍しいケースです - 私の経験では、ReactコンポーネントはSvelteの同等のコンポーネントより大体約40%ほど大きいです。では、アイデアを簡潔に表現することを可能にするSvelteの設計の特徴を見ていきましょう。
-### Top-level elements
+### トップレベル要素(Top-level elements)
-In Svelte, a component can have as many top-level elements as you like. In React and Vue, a component must have a single top-level element — in React's case, trying to return two top-level elements from a component function would result in syntactically invalid code. (You can use a fragment — `<>` — instead of a `
`, but it's the same basic idea, and still results in an extra level of indentation).
+Svelteでは、1つのコンポーネントに好きなだけトップレベル要素を含めることができます。ReactやVueは、1つのコンポーネントには単一のトップレベル要素しか含めることができません - Reactの場合、コンポーネント関数から2つのトップレベル要素を返そうとすると構文的に誤ったコードになります。(`
` の代わりに `<>`を使用できますが、基本的な考え方は同じで、インデントが余分に発生します)
-In Vue, your markup must be wrapped in a `` element, which I'd argue is redundant.
+Vueの場合、``要素でラップしなければなりません、これは冗長です。
-### Bindings
+### バインディング(Bindings)
-In React, we have to respond to input events ourselves:
+Reactでは、自分で入力イベントに対応しなければなりません。
```js
// @noErrors
@@ -125,13 +125,13 @@ function handleChangeA(event) {
}
```
-This isn't just boring plumbing that takes up extra space on the screen, it's also extra surface area for bugs. Conceptually, the value of the input is bound to the value of `a` and vice versa, but that relationship isn't cleanly expressed — instead we have two tightly-coupled but physically separate chunks of code (the event handler and the `value={a}` prop). Not only that, but we have to remember to coerce the string value with the `+` operator, otherwise `2 + 2` will equal `22` instead of `4`.
+これは退屈で画面上に余分なスペースを取るだけでなく、余分なバグを生みかねません。概念的には、入力の値は `a` の値と結びついており、その逆も同様ですが、この関係が綺麗に表現されていません - その代わり、緊密に結合しているものの物理的には分離しているコードのチャンク(イベントハンドラと `value={a}` prop) になります。それだけでなく、`+` 演算子で文字列の値が強制(coerce)されることも忘れないようにしないといけません( _訳注 : JavaScriptでは暗黙的に型が変換されるケースがあります。詳しくは [Type coercion (型強制) - MDN Web Docs](https://developer.mozilla.org/ja/docs/Glossary/Type_coercion) をご参照ください_ )。さもないと、`2 + 2` が `4` ではなく `22` になってしまいます。
-Like Svelte, Vue does have a way of expressing the binding — the `v-model` attribute, though again we have to be careful to use `v-model.number` even though it's a numeric input.
+Svelteと同様、Vueにはバインディングを表現する方法があります - `v-model`属性です。ただし、数値入力であっても `v-model.number` を使うように気をつけなければなりません。
### State
-In Svelte, you update local component state with an assignment operator:
+Svelteでは、ローカルコンポーネントのstateを代入演算子で更新します。
```js
let count = 0;
@@ -141,7 +141,7 @@ function increment() {
}
```
-In React, we use the `useState` hook:
+Reactでは、`useState`フックを使用します。
```js
// @noErrors
@@ -152,12 +152,12 @@ function increment() {
}
```
-This is much _noisier_ — it expresses the exact same concept but with over 60% more characters. As you're reading the code, you have to do that much more work to understand the author's intent.
+これは _かなりノイジー(much noisier)_ です。全く同じ概念を表現していますが文字が60%も多いです。コードを読む際に、その意図を理解するためにより多くの労力をかける必要があります。
-In Vue, meanwhile, we have a default export with a `data` function that returns an object literal with properties corresponding to our local state. Things like helper functions and child components can't simply be imported and used in the template, but must instead be 'registered' by attaching them to the correct part of the default export.
+一方Vueでは、デフォルトのエクスポートに `data`関数があり、ローカルのstateに対応するプロパティを持つオブジェクトリテラルを返します。ヘルパー関数や子コンポーネントなどは単純にインポートしてテンプレートで使用することはできません、デフォルトのエクスポートの正しい部分にアタッチして'登録'する必要があります。
-## Death to boilerplate
+## ボイラープレートに終焉を(Death to boilerplate)
-These are just some of the ways that Svelte helps you build user interfaces with a minimum of fuss. There are plenty of others — for example, reactive declarations (`$:` statements) essentially do the work of React's `useMemo`, `useCallback` and `useEffect` without the boilerplate (or indeed the garbage collection overhead of creating inline functions and arrays on each state change).
+これらは、最小限の手間でユーザーインタフェースを構築するのにSvelteが役立つことの、ほんの一部に過ぎません。他には、例えば[reactive declarations](/tutorial/reactive-declarations) はReactの`useMemo`、`useCallback`、`useEffect`にあたる動作をボイラープレート(あるいは、stateが変化するたびにインライン関数と配列を作成するのに伴うガベージコレクションのオーバーヘッド)なしで本質的に行います。
-How? By choosing a different set of constraints. Because [Svelte is a compiler](/blog/frameworks-without-the-framework), we're not bound to the peculiarities of JavaScript: we can _design_ a component authoring experience, rather than having to fit it around the semantics of the language. Paradoxically, this results in _more_ idiomatic code — for example using variables naturally rather than via proxies or hooks — while delivering significantly more performant apps.
+どうやって？別の制約セットを選択します。[Svelteはコンパイラ](/blog/frameworks-without-the-framework)なので、JavaScriptの特性に縛られません : 言語のセマンティクスに合わせるのではなく、コンポーネントのオーサリングエクスペリエンスを設計できます。逆説的に言えば、結果としてよりイディオムなコードが可能になります - 例えば、プロキシやフックを経由するのではなく、自然に変数を使用することができます - しかも、よりパフォーマンスの高いアプリを提供することができます。
diff --git a/apps/svelte.dev/content/blog/2019-04-22-svelte-3-rethinking-reactivity.md b/apps/svelte.dev/content/blog/2019-04-22-svelte-3-rethinking-reactivity.md
index 5a179a2a6b..5ed70acfb6 100644
--- a/apps/svelte.dev/content/blog/2019-04-22-svelte-3-rethinking-reactivity.md
+++ b/apps/svelte.dev/content/blog/2019-04-22-svelte-3-rethinking-reactivity.md
@@ -1,25 +1,25 @@
---
-title: 'Svelte 3: Rethinking reactivity'
-description: It's finally here
+title: "Svelte 3: リアクティビティ再考"
+description: ついにここまで来ました
author: Rich Harris
authorURL: https://bsky.app/profile/rich-harris.dev
---
-After several months of being just days away, we are over the moon to announce the stable release of Svelte 3. This is a huge release representing hundreds of hours of work by many people in the Svelte community, including invaluable feedback from beta testers who have helped shape the design every step of the way.
+あとほんの数ヶ月後には、Svelte 3 の安定版リリースを発表することができ、大変嬉しく思っています。これは、Svelteコミュニティの多くの人々による数百時間の作業を表す巨大なリリースです。これには、あらゆる段階で設計の形成に貢献したベータテスターからの貴重なフィードバックが含まれます。
-We think you're going to love it.
+私たちはあなたがそれを気に入ってくれると思います。
-## What is Svelte?
+## Svelte とは何か？
-Svelte is a component framework — like React or Vue — but with an important difference. Traditional frameworks allow you to write _declarative_ state-driven code, but there's a penalty: the browser must do extra work to convert those declarative structures into DOM operations, using techniques like [virtual DOM diffing](/blog/virtual-dom-is-pure-overhead) that eat into your frame budget and tax the garbage collector.
+Svelteはコンポーネントフレームワーク — React や Vue のような — ですが、重要な違いがあります。従来のフレームワークでは、宣言的な state 駆動型のコードを書くことができますが、ペナルティがあります。ブラウザは宣言的な構造を DOM 操作に変換するために余分な作業をしなければならず、[仮想 DOM の差分更新](/blog/virtual-dom-is-pure-overhead)技術のようなものはフレーム予算を食い荒らし、ガベージコレクタに課税します。
-Instead, Svelte runs at _build time_, converting your components into highly efficient _imperative_ code that surgically updates the DOM. As a result, you're able to write ambitious applications with excellent performance characteristics.
+その代わり、Svelteは _ビルド時_ に実行され、あなたのコンポーネントを DOM の更新を行う非常に効率的な _命令的_ コードに変換します。その結果、優れたパフォーマンス特性を持つ野心的なアプリケーションを書くことができます。
-The first version of Svelte was all about [testing a hypothesis](/blog/frameworks-without-the-framework) — that a purpose-built compiler could generate rock-solid code that delivered a great user experience. The second was a small upgrade that tidied things up a bit.
+Svelte の最初のバージョンは[仮説を検証する](/blog/frameworks-without-the-framework)ことがすべてでした -- これは、専用のコンパイラが優れたユーザーエクスペリエンスを提供する強固なコードを生成することができることを示しています。2つ目は、物事を少し片付けた小さなアップグレードでした。
-Version 3 is a significant overhaul. Our focus for the last five or six months has been on delivering an outstanding _developer_ experience. It's now possible to write components with [significantly less boilerplate](/blog/write-less-code) than you'll find elsewhere. Try the brand new [tutorial](/tutorial) and see what we mean — if you're familiar with other frameworks we think you'll be pleasantly surprised.
+バージョン3は大幅なオーバーホールです。この5、6か月間、私たちの焦点は、優れた _開発者体験_ を提供することにありました。今では、他の場所で見かけるものよりも[大幅に少ないボイラープレート](/blog/write-less-code)でコンポーネントを書くことができるようになりました。真新しい[チュートリアル](/tutorial)を試してみて、私たちが何を言っているのか確認してください — 他のフレームワークに慣れている人なら、きっと驚くと思います。
-To make that possible we first needed to rethink the concept at the heart of modern UI frameworks: reactivity.
+それを可能にするためには、まず、現代のUIフレームワークの中心となるコンセプト、リアクティビティを再考する必要がありました。
@@ -31,9 +31,9 @@ To make that possible we first needed to rethink the concept at the heart of mod
-## Moving reactivity into the language
+## リアクティビティを言語にする
-In old Svelte, you would tell the computer that some state had changed by calling the `this.set` method:
+昔の Svelte では、`this.set` メソッドを呼び出すことで state が変わったことをコンピュータに伝えることができました。
```js
// @noErrors
@@ -43,7 +43,7 @@ this.set({
});
```
-That would cause the component to _react_. Speaking of which, `this.set` is almost identical to the `this.setState` method used in classical (pre-hooks) React:
+これはコンポーネントが _react(反応)_ する原因になります。そういえば、`this.set` は古典的な (hooks 以前の) React で使われている `this.setState` メソッドとほぼ同じです。
```js
// @noErrors
@@ -53,50 +53,49 @@ this.setState({
});
```
-There are some important technical differences (as I explain in the video above, React is not reactive) but conceptually it's the same thing.
+いくつかの重要な技術的な違いがありますが（上の動画で説明したように、React はリアクティブではありません）、概念的には同じものです。
-That all changed with the advent of [hooks](https://reactjs.org/docs/hooks-intro.html), which handle state in a very different fashion. Many frameworks started experimenting with their own implementations of hooks, but we quickly concluded it wasn't a direction we wanted to go in. Hooks have some intriguing properties, but they also involve some unnatural code and create unnecessary work for the garbage collector. For a framework that's used in [embedded devices](https://mobile.twitter.com/sveltejs/status/1088500539640418304) as well as animation-heavy interactives, that's no good.
+それは [フック](https://reactjs.org/docs/hooks-intro.html) の登場ですべてが変わりました。多くのフレームワークがフックの独自の実装を実験し始めましたが、私たちはすぐにそれは私たちが望んでいる方向ではないと結論付けました。フックには魅力的な特性がありますが、不自然なコードを含んでいたり、ガベージコレクタのために不必要な作業が発生したりします。[組込みデバイス](https://mobile.twitter.com/sveltejs/status/1088500539640418304)やアニメーションを多用するインタラクティブな環境で使用されているフレームワークでは、それは良いことではありません。
-So we took a step back and asked ourselves what kind of API would work for us... and realised that the best API is no API at all. We can just _use the language_. Updating some `count` value — and all the things that depend on it — should be as simple as this:
+そこで、私たちは一歩下がって、どのようなAPIが私たちにとって機能するのかを自問自答しました…そして、最高のAPIは全くAPIがないことに気付きました。私たちはただ _言語を使う_ ことができます。いくつかの `count` 値の更新 -- そしてそれに依存するすべてのもの -- は、このように簡単であるべきです。
-```ts
-let count: number = 10;
-// ---cut---
+```js
+// @noErrors
count += 1;
```
-Since we're a compiler, we can do that by instrumenting assignments behind the scenes:
+コンパイラなので、裏で代入にタグ付けすることでそれが可能になります。
-```ts
-let count: number = 10;
-const $$invalidate = (name: string, value: T) => {
- return void 0;
-};
-// ---cut---
-count += 1;
-$$invalidate('count', count);
+```js
+// @noErrors
+count += 1; $$invalidate('count', count);
```
-Importantly, we can do all this without the overhead and complexity of using proxies or accessors. It's just a variable.
+重要なことは、プロキシやアクセサを使用する際のオーバーヘッドや複雑さを伴わずに、これらのことをすべて行うことができるということです。ただの変数です。
+
-## New look
+## 新しい Svelte
-Your components aren't the only thing that's getting a facelift. Svelte itself has a completely new look and feel, thanks to the amazing design work of [Achim Vedam](https://vedam.de/) who created our new logo and website, which has moved from [svelte.technology](https://svelte.technology) to [svelte.dev](https://svelte.dev).
+改修されているのはコンポーネントだけではありません。[svelte.technology](https://svelte.technology) から [svelte.dev](https://svelte.dev)(訳注:[日本語版](https://svelte.jp)) に移行した新しいロゴとウェブサイトを作成した [AchimVedam](https://vedam.de/) の素晴らしいデザイン作業のおかげで、Svelte 自体はまったく新しいルックアンドフィールになっています。
-We've also changed our tagline, from 'The magical disappearing UI framework' to 'Cybernetically enhanced web apps'. Svelte has many aspects — outstanding performance, small bundles, accessibility, built-in style encapsulation, declarative transitions, ease of use, the fact that it's a compiler, etc — that focusing on any one of them feels like an injustice to the others. 'Cybernetically enhanced' is designed to instead evoke Svelte's overarching philosophy that our tools should work as intelligent extensions of ourselves — hopefully with a retro, William Gibson-esque twist.
+また、私たちはキャッチフレーズを「魔法のように消える UI フレームワーク」から「サイバネティックに強化されたウェブアプリ」に変更しました。Svelte には様々な側面があります。-- 卓越した性能、小さなバンドル、アクセシビリティ、組み込みのスタイルカプセル化、宣言的な遷移、使いやすさ、コンパイラであることなど -- その中のどれか1つに焦点を当てることは、他のものに不公平感を与えるような気がします。「Cybernetically enhanced」は、私たちのツールは私たち自身の知能の拡張として機能するべきだという Svelte の包括的な哲学を思い起こさせるようにデザインされています -- 願わくばレトロでウィリアム・ギブソン風のひねりを加えて。
-## Upgrading from version 2
+## バージョン2からのアップグレード
-If you're an existing Svelte 2 user, I'm afraid there is going to be some manual upgrading involved. In the coming days we'll release a migration guide and an updated version of [svelte-upgrade](https://github.com/sveltejs/svelte-upgrade) which will do the best it can to automate the process, but this _is_ a significant change and not everything can be handled automatically.
+もしあなたが既存の Svelte 2 ユーザーであれば、手動でのアップグレードが必要になると思います。近日中に移行ガイドと [svelte-upgrade](https://github.com/sveltejs/svelte-upgrade) の更新版をリリースする予定です。これは作業を自動化するためにできる限りのことをしてくれます。しかし、 _これ_ は大きな変化であり、すべてが自動的に処理できるわけではありません。
-We don't take this lightly: hopefully once you've experienced Svelte 3 you'll understand why we felt it was necessary to break with the past.
+私たちはこれを軽視していません、Svelte 3 を体験してもらえれば、なぜ過去と決別する必要があると感じたのか理解してもらえると思います。
-## Still to come
+## これから
-As grueling as this release has been, we're nowhere near finished. We have a ton of ideas for generating smarter, more compact code, and a long feature wish-list. [Sapper](https://sapper.svelte.dev), our Next.js-style app framework, is still in the middle of being updated to use Svelte 3. The [Svelte Native](https://svelte-native.technology/) community project, which allows you to write Android and iOS apps in Svelte, is making solid progress but deserves more complete support from core. We don't yet have the bounty of editor extensions, syntax highlighters, component kits, devtools and so on that other frameworks have, and we should fix that. We _really_ want to add first-class TypeScript support.
+<<<<<<< HEAD
+このリリースは大変なものでしたが、まだ完成には至っていません。 よりスマートでコンパクトなコードと長い機能のウィッシュリストを生成するためのアイデアがたくさんあります。Next.js スタイルのアプリフレームワークである [Sapper](https://sapper.svelte.dev) は、Svelte 3 を使用するためのアップデートの真っ最中です。[Svelte Native](https://svelte-native.technology/) のコミュニティプロジェクトは、Svelte で Android や iOS アプリを書くことができるようになり、順調に進んでいますが、コアからのより完全なサポートが必要です。他のフレームワークが持っているようなエディタ拡張機能、シンタックスハイライター、コンポーネントキット、devtools などの豊富な機能はまだありません。私たちは _本当に_ ファーストクラスの TypeScript サポートを追加したいと思っています。
+しかし、それらを待つ間でも Svelte 3 は Web アプリを構築するための最良の方法だと考えています。1時間ほどかけて[チュートリアル](/tutorial)を読んでみてください。いずれにしても、[Discord チャットルーム](https://svelte.dev/chat)や [GitHub](https://github.com/sveltejs/svelte) でお待ちしています。-- 誰でも歓迎します、特にあなたは。
+=======
But in the meantime we think Svelte 3 is the best way to build web apps yet. Take an hour to go through the [tutorial](/tutorial) and we hope to convince you of the same. Either way, we'd love to see you in our [Discord chatroom](/chat) and on [GitHub](https://github.com/sveltejs/svelte) — everyone is welcome, especially you.
+>>>>>>> sveltejs/main
diff --git a/apps/svelte.dev/content/blog/2020-07-17-svelte-and-typescript.md b/apps/svelte.dev/content/blog/2020-07-17-svelte-and-typescript.md
index ad1158257e..bd8ec68f3c 100644
--- a/apps/svelte.dev/content/blog/2020-07-17-svelte-and-typescript.md
+++ b/apps/svelte.dev/content/blog/2020-07-17-svelte-and-typescript.md
@@ -1,70 +1,70 @@
---
title: Svelte <3 TypeScript
-description: Typernetically enhanced web apps
+description: 型により強化されたWebアプリ
author: Orta Therox
authorURL: https://bsky.app/profile/orta.io
---
-It's been by far the most requested feature for a while, and it's finally here: Svelte officially supports TypeScript.
+以前から最も多く要望をもらっていた機能がついに実現しました、Svelte は正式に TypeScript をサポートします。
-We think it'll give you a much nicer development experience — one that also scales beautifully to larger Svelte code bases — regardless of whether you use TypeScript or JavaScript.
+これにより、より良い開発体験が得られると考えています。 -- また、より大きな Svelte コードベースにも美しくスケールします -- TypeScript と JavaScript のどちらを使用していても。
Image of TypeScript + Svelte in VS Code (theme is Kary Pro.)
-## Try it now
+## 今すぐ試してみてください(Try it now)
You can start a new Svelte TypeScript project using Svelte's official scaffolding CLI by running `npm create svelte@latest` and following the prompts. This sets up a new SvelteKit project for you.
Alternatively you can run `npm create vite@latest myapp -- --template svelte-ts` to scaffold a Vite project using Svelte and TypeScript.
-If you're a VS Code user, make sure you're using the (new) [official extension](https://marketplace.visualstudio.com/items?itemName=svelte.svelte-vscode), which replaces the popular extension by James Birtles.
-Later in this blog post, we'll detail the individual steps involved in using TypeScript in an existing Svelte project.
+VS Code ユーザーの方は、(新しい) [公式の拡張機能](https://marketplace.visualstudio.com/items?itemName=svelte.svelte-vscode) を使用していることを確認してください。これは James Birtles による人気の高い拡張機能に取って代わるものです。
+この記事の後半では、既存の Svelte プロジェクトで TypeScript を使用するための個々のステップについて詳しく説明します。
-## What does it mean to support TypeScript in Svelte?
+## Svelte の TypeScript サポートとは何を意味しますか？(What does it mean to support TypeScript in Svelte?)
-TypeScript support in Svelte has been possible for a long time, but you had to mix a lot of disparate tools together and each project ran independently. Today, nearly all of these tools live under the Svelte organization and are maintained by a set of people who take responsibility over the whole pipeline and have common goals.
+Svelte で TypeScript に対応することはかなり前から可能でしたが、多くの異なるツールを組み合わせ、それぞれを個別に動作するようにしなければなりませんでした。今日では、これらのツールのほぼすべてが Svelte の組織の下にあり、パイプライン全体に責任を持ち、共通の目標を持った人たちによってメンテナンスされています。
-A week before COVID was declared a pandemic, [I pitched a consolidation](https://github.com/sveltejs/svelte/issues/4518) of the best Svelte tools and ideas from similar dev-ecosystems and provided a set of steps to get first class TypeScript support. Since then, many people have pitched in and written the code to get us there.
+COVID がパンデミックと宣言される前の週、私は類似の開発エコシステムによる最高の Svelte 用のツールとアイデアの[統合を提案](https://github.com/sveltejs/svelte/issues/4518)し、ファーストクラスの TypeScript サポートを得るための一連のステップを提供しました。それ以来、多くの人たちが協力してくれて、そこにたどり着くためのコードを書いてくれました。
-When we say that Svelte now supports TypeScript, we mean a few different things:
+Svelte が TypeScript をサポートするようになったということは、いくつかの異なる意味を持っています。
-- You can use TypeScript inside your `
```
-For client-side navigation, we use a slightly different mechanism. Data from the server is serialized as [newline delimited JSON](https://dataprotocols.org/ndjson/), and SvelteKit reconstructs the values — using a similar deferred mechanism — with `devalue.parse`:
+クライアントサイドナビゲーションの場合は、少し異なるメカニズムを使用します。サーバーからのデータは [newline delimited JSON](https://dataprotocols.org/ndjson/) としてシリアライズされ、SvelteKit は `devalue.parse` で似たような遅延メカニズムを使用してその値を再構築します:
```json
// this is generated immediately — note the ["Promise",1]...
@@ -117,21 +117,21 @@ For client-side navigation, we use a slightly different mechanism. Data from the
[{"id":1,"data":2},1,[3],{"comment":4},"First!"]
```
-Because promises are natively supported in this way, you can put them anywhere in the data returned from `load` (except at the top level, since we automatically await those for you), and they can resolve with any type of data that devalue supports — including more promises!
+このように promise はネイティブにサポートされているため、`load` から返されるデータのどこにでも置くことができます (トップレベルは除く。トップレベルは自動的に await するからです)。そして devalue がサポートするあらゆるタイプのデータを解決することができます — もちろんさらに多くの promise も！
-One caveat: this feature needs JavaScript. Because of this, we recommend that you only stream in non-essential data so that the core of the experience is available to all users.
+注意事項: この機能には JavaScript が必要です。そのため、重要でないデータのみ、ストリーミングすることを推奨します。すべてのユーザーがエクスペリエンスのコアを利用できるようにするためです。
-For more on this feature, see [the documentation](/docs/kit/load#Streaming-with-promises). You can see a demo at [sveltekit-on-the-edge.vercel.app](https://sveltekit-on-the-edge.vercel.app/edge) (the location data is artificially delayed and streamed in) or [deploy your own on Vercel](https://vercel.com/templates/svelte/sveltekit-edge-functions), where streaming is supported in both Edge Functions and Serverless Functions.
+この機能の詳細については、[ドキュメント](/docs/kit/load#Streaming-with-promises)をご覧ください。デモは [sveltekit-on-the-edge.vercel.app](https://sveltekit-on-the-edge.vercel.app/edge) (ロケーションデータをわざと遅延させ、ストリーミングしています) でご覧頂けますし、[ご自身で Vercel にデプロイ](https://vercel.com/templates/svelte/sveltekit-edge-functions)することもできます。Vercel では Edge Functions と Serverless Functions のどちらもストリーミングをサポートしています。
-We're grateful for the inspiration from prior implementations of this idea including Qwik, Remix, Solid, Marko, React and many others.
+私たちは、Qwik、Remix、Solid、Marko、React などの、このアイデアの先行実装からインスピレーションを受けました。深く感謝します。
## Snapshots
-Previously in a SvelteKit app, if you navigated away after starting to fill out a form, going back wouldn’t restore your form state – the form would be recreated with its default values. Depending on the context, this can be frustrating for users. Since SvelteKit 1.5, we have a built-in way to address this: snapshots.
+以前までの SvelteKit アプリでは、フォームに入力を開始したあとで移動して、そのあと戻ってくるとフォームの state は復元されず、デフォルトの値でフォームが再作成されていました。場合によっては、ユーザーはフラストレーションが溜まるかもしれません。SvelteKit 1.5 以降は、これに対応するための方法が組み込まれています: それが snapshots です。
-Now, you can export a `snapshot` object from a `+page.svelte` or `+layout.svelte`. This object has two methods: `capture` and `restore`. The `capture` function defines what state you want to store when the user leaves the page. SvelteKit will then associate that state with the current history entry. If the user navigates back to the page, the `restore` function will be called with the state you previously had set.
+現在、`+page.svelte` や `+layout.svelte` で `snapshot` オブジェクトをエクスポートすることができます。このオブジェクトには、`capture` と `restore` という2つのメソッドがあります。`capture` 関数は、ユーザーがページを離れたときにどの state を保存するかを定義します。SvelteKit はその state を現在の履歴エントリに関連付けます。ユーザがページに戻った場合は、以前に設定した state を引数に取って `restore` 関数が呼び出されます。
-For example, here is how you would capture and restore the value of a textarea:
+こちらは textarea の値を capture し、restore する方法の例です:
```svelte
```
-While this is super convenient, this isn't just about that. It's also about _correctness_: When copying and pasting code it's easy to accidentally get `PageServerLoadEvent` mixed up with `LayoutServerLoadEvent` or `PageLoadEvent`, for example — similar types with subtle differences. Svelte's major insight was that by writing code in a declarative way we can get the machine to do the bulk of the work for us, correctly and efficiently. This is no different — by leveraging strong framework conventions like `+page` files, we can make it easier to do the right thing than to do the wrong thing.
+これはとても便利ですが、それだけではありません。より _正しい_ のです: コードをコピーペーストするときに、例えば `PageServerLoadEvent` と `LayoutServerLoadEvent` と `PageLoadEvent` のような、似ているが少し違う型を混同してしまうことがよくあります。Svelte の主な考え方は、コードを宣言的に書くことで、機械が私たちのためにほとんどの作業を、それも正しく効率的にやってくれる、というものでした。これも同じです — `+page` ファイルのような強いフレームワークの規約を活用すれば、間違いをするのが難しくなり、正しいことをするほうが簡単になるのです。
-This works for all exports from SvelteKit files (`+page`, `+layout`, `+server`, `hooks`, `params` and so on) and for `data`, `form` and `snapshot` properties in `+page/layout.svelte` files.
+これは SvelteKit ファイル (`+page`、`+layout`、`+server`、`hooks`、`params` など) からのすべての export と、`+page/layout.svelte` ファイルの `data`、`form`、`snapshot` プロパティで動作します。
-To use this feature with VS Code install the latest version of the Svelte for VS Code extension. For other IDEs, use the latest versions of the Svelte language server and the Svelte TypeScript plugin. Beyond the editor, our command line tool `svelte-check` also knows how to add these annotations since version 3.1.1.
+VS Code でこの機能を使用するには、Svelte for VS Code extension の最新バージョンをインストールしてください。他の IDE では、Svelte language server と Svelte TypeScript plugin の最新バージョンを使用してください。エディタ以外では、コマンドラインツール `svelte-check` でも、バージョン 3.1.1 以降であればこれらのアノテーションを追加する方法が組み込まれています。
## How does it work?
-Getting this to work required changes to both the language server (which powers the IntelliSense in Svelte files) and the TypeScript plugin (which makes TypeScript understand Svelte files from within `.ts/js` files). In both we auto-insert the correct types at the correct positions and tell TypeScript to use our virtual augmented file instead of the original untyped file. That in combination with mapping the generated and original positions back and forth gives the desired result. Since `svelte-check` reuses parts of the language server under the hood, it gets that feature for free without further adjustments.
+この機能を実現するには、(Svelte ファイルのインテリセンスを行ってくれる) language server と、(TypeScript に `.ts/js` ファイルの内部から Svelte ファイルを理解させる) TypeScript plugin の両方を変更する必要がありました。両方とも、正しい型を正しいポジションに自動挿入し、オリジナルの型付けされていないファイルではなく拡張された仮想ファイルを使用するよう TypeScript に指示します。生成されたファイルのポジションとオリジナルファイルのポジションを前後にマッピングして組み合わせることで、これを実現しています。`svelte-check` は language server の一部を再利用しているため、調整することなくこの機能が使えます。
-We'd like to thank the Next.js team for [inspiring](https://twitter.com/shuding_/status/1625263297573400578) this feature.
+この機能は Next.js チームから[インスパイア](https://twitter.com/shuding_/status/1625263297573400578)されました。Next.js チームに感謝します。
## What's next
-For the future we want to look into making even more areas of SvelteKit type-safe — links for example, be it in your HTML or through programmatically calling `goto`.
+将来的には、SvelteKit のさらに多くの領域を型安全にすることを検討したいと思っています — 例えばリンクは、HTML の中や、プログラム的に `goto` を呼び出していますよね。
-TypeScript is eating the JavaScript world — and we're here for it! We care deeply about first class type safety in SvelteKit, and we provide you the tools to make the experience as smooth as possible — one that also scales beautifully to larger Svelte code bases — regardless of whether you use TypeScript or typed JavaScript through JSDoc.
+TypeScript は JavaScript の世界を席巻しています — 私たちはそれに夢中です！ 私たちは SvelteKit のファーストクラスの型安全性に深く取り組んでおり、TypeScript を使用するか JSDoc で型付けされた JavaScript を使用するかに関わらず、より大規模な Svelte コードベースにも美しくスケールすることができる、できる限り開発体験をスムーズにするツールを提供します。
diff --git a/apps/svelte.dev/content/blog/2023-04-01-whats-new-in-svelte-april-2023.md b/apps/svelte.dev/content/blog/2023-04-01-whats-new-in-svelte-april-2023.md
index 7388b400dc..2d51d94402 100644
--- a/apps/svelte.dev/content/blog/2023-04-01-whats-new-in-svelte-april-2023.md
+++ b/apps/svelte.dev/content/blog/2023-04-01-whats-new-in-svelte-april-2023.md
@@ -1,17 +1,17 @@
---
-title: "What's new in Svelte: April 2023"
-description: 'Loads of new Svelte compiler features, plus Svelte Summit and SvelteHack'
+title: "What's new in Svelte: 2023年4月"
+description: "たくさんの Svelte コンパイラの新機能, そして Svelte Summit と SvelteHack"
author: Dani Sandoval
authorURL: https://dreamindani.com
---
-Happy April, everyone! This month, we're covering all the new features in the Svelte compiler, some quality-of-life improvements in SvelteKit and a huge showcase (like always).
+Happy April、みなさん！ 今月は、Svelte コンパイラの全ての新機能や、SvelteKit における QOL の改善、そしてたくさんのショーケースを見ていきますよ (いつものようにね)。
-In core team news, Dominic Gannaway has joined Vercel to work on Svelte full-time! Dominic is a world-class expert on wringing performance out of javascript engines, on the DOM, on reactivity, on accessibility, and more! You might know him as the creator of the [Inferno](https://www.infernojs.org/) UI framework or [Lexical](https://lexical.dev/), Meta's WYSIWYG editor. It'll be great to see his talents at work across the Svelte ecosystem 🌱
+コアチームのニュースとしては、Dominic Gannaway が Vercel にジョインし、フルタイムで Svelte に取り組むことになりました！ Dominic は javascript エンジンのパフォーマンスや、DOM、リアクティビティ、アクセシビリティなどのワールドクラスのエキスパートです！ UI フレームワークの [Inferno](https://www.infernojs.org/) や Meta の WYSIWYG エディタである [Lexical](https://lexical.dev/) の作者としても知られています。彼の才能が Svelte エコシステムで発揮されたら、とても素晴らしい未来が待っているでしょう🌱
-Don't forget! Svelte Summit Spring, Svelte's 6th virtual conference, will be happening on May 6th. Also, there's just two weeks left until the end of [SvelteHack](https://hack.sveltesociety.dev/)... It's a great opportunity to share your creations with the community and maybe even earn a prize!
+こちらもお忘れなく！ 6回目 となる Svelte のバーチャルカンファレンス、Svelte Summit Spring が 5月6日に開催されます。また、[SvelteHack](https://hack.sveltesociety.dev/) の締め切りまであと2週間です… あなたの作品をコミュニティにシェアする素晴らしい機会ですし、もしかしたら賞品を獲得できるかも！
-Now let's jump into this month's changes...
+それでは、今月の更新を見ていきましょう…
## What's new in Svelte
@@ -29,7 +29,7 @@ Now let's jump into this month's changes...
- The `style:` directive will now take precedence over a `style=` attribute (**3.57.0**, [#7475](https://github.com/sveltejs/svelte/issues/7475))
- CSS units are now supported in the `fly` and `blur` transitions (**3.57.0**, [#7623](https://github.com/sveltejs/svelte/pull/7623), [Docs](https://v4.svelte.dev/docs#run-time-svelte-transition))
-For all the changes to the Svelte compiler, including unreleased changes, check out the [CHANGELOG](https://github.com/sveltejs/svelte/blob/master/CHANGELOG.md).
+Svelte コンパイラに対する全ての変更については、まだ未リリースの変更も含め、[CHANGELOG](https://github.com/sveltejs/svelte/blob/master/CHANGELOG.md) をご確認ください。
## What's new in SvelteKit
@@ -109,8 +109,8 @@ _To Read_
- [AI Chat Bestie](https://github.com/KTruong008/aichatbestie) is an unofficial ChatGPT app
- [chatgpt-svelte](https://github.com/ichbtrv/chatgpt-svelte) is a simple UI for the ChatGPT Open AI API
-Thanks for reading! And don't forget to try your hand at the [Svelte Hackathon](https://hack.sveltesociety.dev/) 🧑💻
+お読みいただきありがとうございました！あと、[Svelte Hackathon](https://hack.sveltesociety.dev/) にも是非チャレンジしてみてください 🧑💻
-As always, feel free to let us know if we missed anything on [Reddit](https://www.reddit.com/r/sveltejs/) or [Discord](https://discord.gg/svelte).
+いつも通り、見落としなどございましたら [Reddit](https://www.reddit.com/r/sveltejs/) や [Discord](https://discord.gg/svelte) にてお気軽にお知らせください。
-See ya next time!
+また次回お会いしましょう！
diff --git a/apps/svelte.dev/content/blog/2023-05-01-whats-new-in-svelte-may-2023.md b/apps/svelte.dev/content/blog/2023-05-01-whats-new-in-svelte-may-2023.md
index d8e1311282..a90d0b5a05 100644
--- a/apps/svelte.dev/content/blog/2023-05-01-whats-new-in-svelte-may-2023.md
+++ b/apps/svelte.dev/content/blog/2023-05-01-whats-new-in-svelte-may-2023.md
@@ -1,41 +1,41 @@
---
-title: "What's new in Svelte: May 2023"
-description: 'New Ambassadors, a new ESLint plugin and a whole bunch of SvelteHack submissions'
+title: "What's new in Svelte: 2023年5月"
+description: "新たなアンバサダー、新たな ESLint plugin、そして SvelteHack の全応募を一挙公開"
author: Dani Sandoval
authorURL: https://dreamindani.com
---
-Before we dive into the updates, there's a few announcements worth mentioning at the top:
+最新情報に飛び込む前に、まず最初に特別なアナウンスがあります:
## New Svelte Ambassadors
-Regular features of this newsletter and all-around great content creators for Svelte [JoyOfCode](https://www.youtube.com/@JoyofCodeDev) and [HuntaByte](https://www.youtube.com/@Huntabyte) have been appointed as Svelte Ambassadors. Ambassadors are people who are well known for their helpfulness and contributions and for upholding Svelte’s reputation as a friendly, welcoming community, and we’re deeply grateful for their involvement!
+このニュースレターでも定期的にフィーチャーされている、素晴らしい Svelte コンテンツのクリエーターである [JoyOfCode](https://www.youtube.com/@JoyofCodeDev) と [HuntaByte](https://www.youtube.com/@Huntabyte) が Svelte アンバサダーに任命されました。Svelte のアンバサダーの方々はその親切さと貢献がよく知られており、そして Svelte がフレンドリーで歓迎されるコミュニティであるという評判を維持してくれていて、私たちはアンバサダーの方々に深く感謝しています。
## SvelteHack winners will be announced May 6th
-In a just a few days, we'll find out who won [SvelteHack](https://hack.sveltesociety.dev/) - the Svelte Hackathon that took place between February 17th and April 17th. Tune in to [Svelte Summit](https://www.sveltesummit.com/) on May 6th to see if your favorite project was chosen 👀
+2/17から4/17にかけて開催された [SvelteHack](https://hack.sveltesociety.dev/) の優勝者があと数日で発表されます。あなたが好きなプロジェクトが選ばれたかどうか、5/6 の [Svelte Summit](https://www.sveltesummit.com/) をご覧ください 👀
-Lots of submissions to the hackathon are featured in this month's showcase... but first, let's see what's new!
+今月のショーケースにはたくさんのハッカソンへの応募作品を紹介しています… でもまずは、最新情報を見ていきましょう！
## What's new in Svelte
-- `style` blocks now support CSS `@container` queries (**3.58.0**)
-- `bind:innerText` is now available for `contenteditable` elements (**3.58.0**)
-- A new accessability warning, `a11y-interactive-supports-focus` will now warn when interactive elements are not focusable (**3.58.0**)
+- `style` ブロックで CSS `@container` クエリがサポートされました (**3.58.0**)
+- `bind:innerText` が `contenteditable` 要素でサポートされました (**3.58.0**)
+- 新たなアクセシビリティ警告 `a11y-interactive-supports-focus` は、インタラクティブな要素がフォーカスできないようになっているときに警告してくれます (**3.58.0**)
-For all the changes to the Svelte compiler, including unreleased changes, check out the [CHANGELOG](https://github.com/sveltejs/svelte/blob/master/CHANGELOG.md).
+Svelte コンパイラに対する全ての変更については、まだ未リリースの変更も含め、[CHANGELOG](https://github.com/sveltejs/svelte/blob/master/CHANGELOG.md) をご確認ください。
## What's new in SvelteKit
-- When hot module reloading (HMR) is enabled, the page will reload after an error is fixed (**1.14.0**, [#9497](https://github.com/sveltejs/kit/pull/9497))
-- Two apps loaded into the same html page can now be loaded simultaneously in "embedded" mode (**1.15.7**, [#9610](https://github.com/sveltejs/kit/pull/9610))
-- Vite's compilation will now log warnings for packages that use the `svelte` field to resolve Svelte files differently than standard Vite resolve (**vite-plugin-svelte@2.1.0**, **kit@1.15.8**)
+- ホットモジュールリローディング (HMR) が有効なとき、エラーが修正されたあとにページがリロードされるようになりました (**1.14.0**, [#9497](https://github.com/sveltejs/kit/pull/9497))
+- 同じ html ページにロードされた2つのアプリを、"embedded" モードで同時に読み込めるようになりました (**1.15.7**, [#9610](https://github.com/sveltejs/kit/pull/9610))
+- Vite のコンパイルで、標準の Vite resolve ではなく `svelte` フィールドを使用して Svelte ファイルの resolve を行うパッケージに対し、警告のログを出力するようになりました (**vite-plugin-svelte@2.1.0**, **kit@1.15.8**)
## What's new in Language Tools
-- Support for `` ([#1958](https://github.com/sveltejs/language-tools/pull/1958)) and intellisense report for new bindings ([#1957](https://github.com/sveltejs/language-tools/pull/1957)) (**107.3.0**)
-- The new fix-all menu option for the "Quick fix..." makes it easy to "Add all missing imports" and other detected errors (**107.3.0**, [#1939](https://github.com/sveltejs/language-tools/pull/1939))
-- We have a new and better official [ESLint plugin](https://github.com/sveltejs/eslint-plugin-svelte)! Previous support for Svelte in ESLint did not handle the template AST well, resulting in false positive/negatives and a high barrier to custom ESLint rules. This new official version is based on [ota-meshi](https://github.com/ota-meshi)'s [svelte-eslint-parser](https://github.com/sveltejs/svelte-eslint-parser) and is ready for prime time. Try it out and [share your feedback](https://github.com/sveltejs/eslint-plugin-svelte/issues)!
+- `` がサポートされ ([#1958](https://github.com/sveltejs/language-tools/pull/1958))、新たなバインディング向けのインテリセンスレポートがサポートされました ([#1957](https://github.com/sveltejs/language-tools/pull/1957)) (**107.3.0**)
+- "Quick fix..." の新たな fix-all メニューオプションで、"Add all missing imports" や other detected errors が簡単にできるようになりました (**107.3.0**, [#1939](https://github.com/sveltejs/language-tools/pull/1939))
+- 公式の [ESLint plugin](https://github.com/sveltejs/eslint-plugin-svelte) が新しく、より良くなりました！これまでの ESLint の Svelte に対するサポートは、テンプレートの AST をうまく扱えず、偽陽性/偽陰性になってしまったり、カスタムの ESLint ルールを作成するのに高い障壁がありました。この新しい公式バージョンは [ota-meshi](https://github.com/ota-meshi) の [svelte-eslint-parser](https://github.com/sveltejs/svelte-eslint-parser) がベースとなっており、すぐにお使いいただけます。トライしてみて、[フィードバックをシェアしてください](https://github.com/sveltejs/eslint-plugin-svelte/issues)！
---
@@ -112,6 +112,6 @@ _To Read_
- [Lucia](https://lucia-auth.com/blog/lucia-1) just reached 1.0 for their simple and flexible auth library for SvelteKit
- [svelte-stepper](https://github.com/efstajas/svelte-stepper) is a simple library for building animated stepper flows with Svelte
-As always, feel free to let us know if we missed anything on [Reddit](https://www.reddit.com/r/sveltejs/) or [Discord](https://discord.gg/svelte).
+いつも通り、見落としなどございましたら [Reddit](https://www.reddit.com/r/sveltejs/) や [Discord](https://discord.gg/svelte) にてお気軽にお知らせください。
-See ya next time!
+また次回お会いしましょう！
diff --git a/apps/svelte.dev/content/blog/2023-06-01-whats-new-in-svelte-june-2023.md b/apps/svelte.dev/content/blog/2023-06-01-whats-new-in-svelte-june-2023.md
index 6fae813147..87eeb75e22 100644
--- a/apps/svelte.dev/content/blog/2023-06-01-whats-new-in-svelte-june-2023.md
+++ b/apps/svelte.dev/content/blog/2023-06-01-whats-new-in-svelte-june-2023.md
@@ -1,29 +1,28 @@
---
-title: "What's new in Svelte: June 2023"
-description: 'SvelteHack winners, lots of new bindings, Svelte 4.0.0-next.0, and a bunch of new features in SvelteKit'
+title: "What's new in Svelte: 2023年6月"
+description: "SvelteHack の受賞者、たくさんのバインディング、Svelte 4.0.0-next.0、そして SvelteKit の新機能がいっぱい"
author: Dani Sandoval
authorURL: https://dreamindani.com
---
-Welcome to June everyone and [congrats to our SvelteHack winners](https://hack.sveltesociety.dev/winners), across all the categories! If you missed it, these winners were announced at Svelte Summit on May 6th 🎉
+6月になりましたね。まず、[SvelteHack の全カテゴリーの受賞者の皆さま](https://hack.sveltesociety.dev/winners)、おめでとうございます！受賞者は5月6日の Svelte Summit で発表されました 🎉
-The entire playlist of the summit, including all the talks broken up in to separate videos, can be found [on the Svelte Society YouTube channel](https://www.youtube.com/playlist?list=PL8bMgX1kyZTiODueVnrK5GR42u3hgN13X). So check it out, if you haven't already.
+Summit のプレイリストは、[the Svelte Society YouTube channel](https://www.youtube.com/playlist?list=PL8bMgX1kyZTiODueVnrK5GR42u3hgN13X) からご覧いただけます (各講演ごとに動画がビデオが分割されています)。まだ見ていない場合は、チェックしてみてください。
-Lots to cover in this month's newsletter, including a lot of improvements to both Svelte and Kit...
+今月のニュースレターは、Svelte と Kit の改善点をたくせんお届けします…
## What's new in Svelte
-[Svelte 4.0.0-next.0](https://github.com/sveltejs/svelte/releases), the first pre-release version of Svelte 4.0 is out! An explanation of the changes, improvements and goals of this release can be found in [the Releases page on GitHub](https://github.com/sveltejs/svelte/releases/tag/svelte%404.0.0-next.0). Check it out to get an early sneak peek of the future of Svelte. It also includes a migration guide, for those interested in the minimal amount of breaking changes and deprecations.
+Svelte 4.0 の最初のプレリリースバージョンである [Svelte 4.0.0-next.0](https://github.com/sveltejs/svelte/releases) が公開されました！ このリリースの変更点、改善点、目的に関する説明は [GitHub のリリースページ](https://github.com/sveltejs/svelte/releases/tag/svelte%404.0.0-next.0) でご確認いただけます。Svelte の未来を先行して知りたければ、チェックしてみてください。移行ガイドも含まれておりますので、ごくわずかな破壊的変更・非推奨事項についてもご確認いただけます。
-Svelte 3.59.0 is also out, with a ton of new features:
+Svelte 3.59.0 も公開され、新機能がたくさん追加されています:
+- スプレッド構文 (`...`) による配列の再構築が正しく処理されるようになりました (**3.59.0**, [#8552](https://github.com/sveltejs/svelte/issues/8552), [#8554](https://github.com/sveltejs/svelte/issues/8554))
+- 新たに追加された `a11y-autocomplete-valid` 警告は、autocomplete 属性が HTML の仕様に従って使用されていない場合に警告を出します (**3.59.0**, [Examples](https://github.com/evcohen/eslint-plugin-jsx-a11y/blob/d32a27fb64f4127d31e4e76bd08e319cfaf0ba53/docs/rules/autocomplete-valid.md), [#8520](https://github.com/sveltejs/svelte/pull/8520))
+- `fullscreenElement` と `visibilityState` バインディングが `` 要素で使用できるようになりました (**3.59.0**, [#8507](https://github.com/sveltejs/svelte/pull/8507))
+- `devicePixelRatio` バインディングが `` 要素で使用できるようになりました (**3.59.0**, [#8285](https://github.com/sveltejs/svelte/issues/8285))
+- `ResizeObserver` のバインディング `contentRect`/`contentBoxSize`/`borderBoxSize`/`devicePixelContentBoxSize` が、`bind:` で使用できるようになりました (**3.59.0**, [#8022](https://github.com/sveltejs/svelte/pull/8022))
-- Restructuring arrays with the spread operator (`...`) is now handled correctly (**3.59.0**, [#8552](https://github.com/sveltejs/svelte/issues/8552), [#8554](https://github.com/sveltejs/svelte/issues/8554))
-- The new `a11y-autocomplete-valid` warning will now warn if the autocomplete attribute isn't used according to the HTML specification (**3.59.0**, [Examples](https://github.com/evcohen/eslint-plugin-jsx-a11y/blob/d32a27fb64f4127d31e4e76bd08e319cfaf0ba53/docs/rules/autocomplete-valid.md), [#8520](https://github.com/sveltejs/svelte/pull/8520))
-- `fullscreenElement` and `visibilityState` bindings are now available for the `` element (**3.59.0**, [#8507](https://github.com/sveltejs/svelte/pull/8507))
-- The `devicePixelRatio` binding is now available for the `` element (**3.59.0**, [#8285](https://github.com/sveltejs/svelte/issues/8285))
-- The `ResizeObserver` bindings `contentRect`/`contentBoxSize`/`borderBoxSize`/`devicePixelContentBoxSize` are now usable with `bind:`(**3.59.0**, [#8022](https://github.com/sveltejs/svelte/pull/8022))
-
-For all the changes to the Svelte compiler, including unreleased changes, check out the [CHANGELOG](https://github.com/sveltejs/svelte/blob/master/CHANGELOG.md).
+Svelte コンパイラに対する全ての変更については、まだ未リリースの変更も含め、[CHANGELOG](https://github.com/sveltejs/svelte/blob/master/CHANGELOG.md) をご確認ください。
## What's new in SvelteKit
@@ -98,6 +97,6 @@ _To Read_
- [Svelte Smart Doc](https://www.sveltron.com/) is a natural language interface to search the Svelte Svelte documentation
- [Tailwind Elements](https://tailwind-elements.com/docs/standard/integrations/svelte-integration/) now has a Svelte Integration
-Thanks for reading! As always, feel free to let us know if we missed anything on [Reddit](https://www.reddit.com/r/sveltejs/) or [Discord](https://discord.gg/svelte).
+お読みくださりありがとうございました！ いつも通り、見落としなどございましたら [Reddit](https://www.reddit.com/r/sveltejs/) や [Discord](https://discord.gg/svelte) にてお気軽にお知らせください。
-Until next time 👋
+また次回お会いしましょう 👋
diff --git a/apps/svelte.dev/content/blog/2023-06-22-svelte-4.md b/apps/svelte.dev/content/blog/2023-06-22-svelte-4.md
index 3b87513644..8130f68547 100644
--- a/apps/svelte.dev/content/blog/2023-06-22-svelte-4.md
+++ b/apps/svelte.dev/content/blog/2023-06-22-svelte-4.md
@@ -1,13 +1,13 @@
---
-title: 'Announcing Svelte 4'
-description: 'Updated performance, developer experience, and site'
+title: "Svelte 4 発表"
+description: 'パフォーマンス、デベロッパーエクスペリエンス、サイトの更新'
author: The Svelte team
authorURL: https://svelte.dev/
---
-After months in the making, we're excited to announce the stable release of Svelte 4.
+数ヶ月の開発期間を経て、Svelte 4 の安定版リリースを発表できることを嬉しく思います。
-Time flies - Svelte 3 was released more than four years ago! In JavaScript-framework-time, that's eons. Svelte’s freshness has persisted throughout, but Node.js and browser APIs have evolved during that time and today we’re updating Svelte to take advantage of some of these improvements. Svelte 4 is mainly a maintenance release, bumping minimum version requirements and tightening up the design in specific areas. It sets the stage for the next generation of Svelte to be released as Svelte 5 - we think you’ll love it.
+光陰矢の如し - Svelte 3 がリリースされたのはもう4年以上前です！ JavaScript フレームワークの時間としては、それは大昔のことです。Svelte のフレッシュさはずっと保たれたままでしたが、その間に Node.js と ブラウザの API は進化しており、その改善点を取り入れるため、今日、私たちは Svelte を更新します。Svelte 4 は主にメンテナンスリリースであり、要求される最小バージョンを上げ、特定エリアの設計を強化しました。これは、次世代の Svelte、つまり Svelte 5 のための基盤となります - きっとあなたにも気に入って頂けると思います。
If you haven't tried Svelte yet, take it for a spin in our [interactive tutorial](/tutorial), on [StackBlitz](https://sveltekit.new/), or locally with `npm create svelte@latest`. Svelte lets you easily put together web UIs leveraging the power of HTML, CSS, JS, and the Svelte compiler. Watch [Svelte Radio Live](https://www.youtube.com/watch?v=72TIVhRtyWE) to learn more about this release.
@@ -15,45 +15,45 @@ If you haven't tried Svelte yet, take it for a spin in our [interactive tutorial
### Performance
-This release results in smaller and faster hydration code. To see the impact, SvelteKit users can see their compiled output shrink in size by examining the `.svelte-kit/output/client/_app/immutable/nodes` folder. For example, on [kit.svelte.dev](https://kit.svelte.dev) the JS generated across the whole site was reduced in size by 12.7% (126.3 kB to 110.2 kB).
+このリリースにより、ハイドレーションコードが小さくなり、高速になりました。そのインパクトが見たければ、SvelteKit ユーザーなら `.svelte-kit/output/client/_app/immutable/nodes` フォルダを調べてみればコンパイル後の出力サイズが小さくなっていることがわかります。例えば、[kit.svelte.dev](https://kit.svelte.dev) のサイト全体で生成された JS は 12.7% 削減されました (126.3 kB から 110.2 kB になりました)。
Svelte 4 reduces the Svelte package size by nearly 75% (10.6 MB down to 2.8 MB), which means less waiting on `npm install`. This improvement will be especially noticeable for users who are loading [our interactive learning experience](/tutorial) for the first time, users of the Svelte REPL, and users with limited connectivity. The majority of the remaining package size is eslint support, which necessitates distributing a CJS build, and once [the eslint rewrite](https://github.com/eslint/eslint/discussions/16557) is completed the Svelte package size can drop by over another 50%.
-The number of dependencies in Svelte has been greatly reduced from 61 down to 16. This means faster downloads for our users as well as less susceptibility to supply chain attacks. We also slightly reduced the number of dependencies in the latest versions of SvelteKit as well.
+Svelte の dependencies の数は 61 から 16 に大幅に削減されました。つまり、ユーザーにとってはダウンロードが速くなるとともに、サプライチェーンアタックのリスクも低くなったということです。SvelteKit の最新バージョンでも、dependencies の数を少し減らせました。
### Developer experience
-Svelte 4 makes the Svelte authoring experience more intuitive and consistent: `|local` is now the default for transitions to avoid animations blocking page transitions, preprocessors are now easier to write, and multiple fixes make CSP easier to set up and use.
+Svelte 4 では Svelte でのオーサリング・エクスペリエンスが、より一貫性があり直感的になりました: トランジションでは `|local` がデフォルトとなったことでアニメーションがページトランジションをブロックしないようになり、プリプロセッサは書くのがより簡単になり、またいくつかの修正によって CSP の設定と使用が簡単になりました。
-For users of web components, the largest change is an overhaul of the way you use Svelte to author custom elements. By changing the way they are generated, a whole class of bugs and inconsistencies was eliminated.
+web components のユーザーにとって、最も大きい変更点は Svelte で custom elements を作成する方法がオーバーホールされたことでしょう。生成方法が変わったことにより、あらゆるバグや不整合が取り除かれました。
-Finally, we’ve also made several [improvements to the IDE authoring experience](https://github.com/sveltejs/svelte/pull/8702):
-cmd+click in svelte modules now takes you to the implementation rather than a `.d.ts` file
-imports from `svelte/internal` are now hidden and will not clutter autocomplete suggestions
-auto-imports now work more reliably
+最後に、[IDE のオーサリングエクスペリエンスの改善](https://github.com/sveltejs/svelte/pull/8702)もいくつか行いました:
+- svelte モジュールで cmd+click すると、`.d.ts` ファイルではなく実装に移動するようになりました
+- `svelte/internal` からのインポートが非表示になり、オートコンプリート候補がきれいになりました
+- auto-imports がより確実に動作するようになりました
### Updated site, docs, and tutorial
The official [svelte.dev](https://svelte.dev) site has gotten an overhaul. It’s now split into multiple pages with improved mobile nav, overhauled typescript docs, dark mode, and an enhanced REPL. The SvelteKit site is also being updated to match. And we’ve updated all the tutorial links to point to our new [tutorial](/tutorial) experience.
-Stay tuned for a more in-depth blog post about all the site changes in the coming days!
+近日、サイトの全ての変更点についてより詳細なブログ記事を掲載しますので、乞うご期待！
## Migrating
-Most apps and libraries that are compatible with Svelte 3 should be compatible with Svelte 4. Library authors will need to update the version range to include Svelte 4 if `svelte` is specified in the `peerDependencies`. For application authors, the most common change required will be updating tooling to meet the new minimum version requirements such as Node.js 16. Many other migration steps can be handled with `npx svelte-migrate@latest svelte-4`.
+Svelte 3 と互換性のあるアプリやライブラリのほとんどは、Svelte 4 にも互換性があるでしょう。ライブラリの作者の方は、もし `peerDependencies` に `svelte` が指定されている場合は version range に Svelte 4 を含めるように更新する必要があります。アプリケーションの作者の方は、新しくなった最小バージョンの要求 (Node.js 16 など) を満たすようにツールを更新する必要があるでしょう。その他多くの移行ステップは、`npx svelte-migrate@latest svelte-4` で処理できます。
-Read the [migration guide](/docs/v4-migration-guide) for full details.
+完全な詳細については[マイグレーションガイド](/docs/v4-migration-guide)をお読みください。
## Svelte 5: the next generation of Svelte
-Svelte 5 will be a rewrite of the Svelte compiler and runtime. Svelte 4 was mainly about setting the ground for these future improvements by adopting modern tooling and dropping support for some legacy versions of various technologies such as older bundlers. These changes will help us in a number of ways such as being able to more easily compare the Svelte 5 and Svelte 4 codebases and being able to run the existing tests against the new implementation. Svelte 5 will bring major new features and performance improvements to Svelte. The changes are still baking and not quite ready to share yet, but stay tuned!
+Svelte 5 では Svelte コンパイラとランタイムの書き換えを行う予定です。Svelte 4 の主な目的は、古いバンドラーなの様々なテクノロジーのレガシーバージョンをドロップし、モダンなツールを取り入れ、将来の改善のための土台を整えることでした。これらの変更により、Svelte 5 と Svelte 4 のコードベースを比較するのが簡単になり、新しい実装に対して既存のテストを実行することができるようになり、様々なことが便利になります。Svelte 5 では、大きい新機能とパフォーマンスの改善を予定しています。変更についてはまだ作成中で、まだ共有できる段階ではありませんが、ご期待ください！
## Changelog
-See the full list of changes in the [changelog](https://github.com/sveltejs/svelte/blob/master/packages/svelte/CHANGELOG.md).
+変更点の完全なリストについては [changelog](https://github.com/sveltejs/svelte/blob/master/packages/svelte/CHANGELOG.md) をご参照ください。
## Acknowledgements
-First and foremost, thank you to all of the many Svelte maintainers and contributors who made this release possible. Developers contributing multiple PRs to this release were [@dummdidumm](https://github.com/dummdidumm), [@gtm-nayan](https://github.com/gtm-nayan), [@benmccann](https://github.com/benmccann), [@tanhauhau](https://github.com/tanhauhau), [@Karlinator](https://github.com/Karlinator), and [@ngtr6788](https://github.com/ngtr6788). Also, thank you to the many community members who donated to [the Svelte OpenCollective](https://opencollective.com/svelte) - these donations sponsored the site overhaul completed by [PuruVJ](https://github.com/puruvj) as well as a number of recent fixes from [@gtm-nayan](https://github.com/gtm-nayan).
+何よりもまず、このリリースを可能にしてくれた Svelte のメンテナー、コントリビューターの皆さまに感謝したいと思います。このリリースに対する複数の PR をコントリビュートしてくれた開発者は [@dummdidumm](https://github.com/dummdidumm)、[@gtm-nayan](https://github.com/gtm-nayan)、[@benmccann](https://github.com/benmccann)、[@tanhauhau](https://github.com/tanhauhau)、[@Karlinator](https://github.com/Karlinator)、[@ngtr6788](https://github.com/ngtr6788) です。また、[the Svelte OpenCollective](https://opencollective.com/svelte) に寄付してくれたコミュニティメンバーにも感謝したいと思います。この寄付で、[PuruVJ](https://github.com/puruvj) によるサイトのオーバーホールと、[@gtm-nayan](https://github.com/gtm-nayan) の多数の修正をスポンサーすることができました。
-Finally, thank you to the various library maintainers from across the ecosystem who helped prepare for this release. Thank you to [@jessebeach](https://github.com/jessebeach) for the help in getting out new versions of `aria-query` and `axobject-query`, [@jreinhold](https://github.com/jreinhold) for ensuring compatibility with Storybook, and [@yanick](https://github.com/yanick) for updating `svelte-testing-library`. And to ensure things stay working, the [`svelte-ecosystem-ci`](https://github.com/sveltejs/svelte-ecosystem-ci) setup by [@dominikg](https://github.com/dominikg) — which was modeled off his similar work for Vite — has been helping to test against major projects in the ecosystem on an ongoing basis.
+最後に、このリリースの準備を助けてくれたエコシステムの多くのライブラリメンテナーにも感謝します。新しいバージョンの `aria-query` や `axobject-query` のリリースを助けてくれた [@jessebeach](https://github.com/jessebeach)、Storybook との互換性を確保してくれた [@jreinhold](https://github.com/jreinhold)、`svelte-testing-library` をアップデートしてくれた [@yanick](https://github.com/yanick)、ありがとうございました。また、様々なものが動作していることを確認するために、[@dominikg](https://github.com/dominikg) がセットアップしてくれた [`svelte-ecosystem-ci`](https://github.com/sveltejs/svelte-ecosystem-ci) は、彼が Vite のために行ってくれた同様の作業をモデルにしており、エコシステム内の主要なプロジェクトに対するテストを継続的に支援しています。
diff --git a/apps/svelte.dev/content/blog/2023-09-20-runes.md b/apps/svelte.dev/content/blog/2023-09-20-runes.md
index 8c4ae8b7ed..bad5b82ca8 100644
--- a/apps/svelte.dev/content/blog/2023-09-20-runes.md
+++ b/apps/svelte.dev/content/blog/2023-09-20-runes.md
@@ -1,11 +1,11 @@
---
-title: Introducing runes
-description: "Rethinking 'rethinking reactivity'"
+title: Rune 導入 (Introducing runes)
+description: "'rethinking reactivity' を再考する"
author: The Svelte team
authorURL: /
---
-In 2019, Svelte 3 turned JavaScript into a [reactive language](/blog/svelte-3-rethinking-reactivity). Svelte is a web UI framework that uses a compiler to turn declarative component code like this...
+2019 年、Svelte 3 は JavaScript を [リアクティブな言語](/blog/svelte-3-rethinking-reactivity) に変えました。Svelte はコンパイラを使用する web UI フレームワークで、このような宣言的なコンポーネントを…
```svelte
@@ -22,11 +22,11 @@ In 2019, Svelte 3 turned JavaScript into a [reactive language](/blog/svelte-3-re
```
-...into tightly optimized JavaScript that updates the document when state like `count` changes. Because the compiler can 'see' where `count` is referenced, the generated code is [highly efficient](/blog/virtual-dom-is-pure-overhead), and because we're hijacking syntax like `let` and `=` instead of using cumbersome APIs, you can [write less code](/blog/write-less-code).
+…`count` のようなステートが変化したときに document を更新する、タイトに最適化された JavaScript に変換します。コンパイラは `count` が参照されている場所を '把握' することができるので、生成されるコードは[非常に効率的](/blog/virtual-dom-is-pure-overhead)です。また、扱いにくい API を使用するのではなく、`let` や `=` などの構文をジャックしているため、[コード量を減らす](/blog/write-less-code)ことができます。
-A common piece of feedback we get is 'I wish I could write all my JavaScript like this'. When you're used to things inside components magically updating, going back to boring old procedural code feels like going from colour to black-and-white.
+私たちがよく受けるフィードバックとして、'JavaScript をすべてこのように書けたらいいのに' というものがあります。コンポーネント内のものが魔法のように更新されることに慣れていると、退屈で古い手続き型のコードに戻ることは、まるでカラーから白黒に戻るように感じられます。
-Svelte 5 changes all that with _runes_, which unlock _universal, fine-grained reactivity_.
+Svelte 5 では、_rune_ によって全てを変え、_ユニバーサルできめ細やかなリアクティビティ(universal, fine-grained reactivity)_ を実現します。
@@ -34,25 +34,25 @@ Svelte 5 changes all that with _runes_, which unlock _universal, fine-grained re
-Introducing runes
+Rune 導入
-## Before we begin
+## 前書き
-Even though we're changing how things work under the hood, Svelte 5 should be a drop-in replacement for almost everyone. The new features are opt-in — your existing components will continue to work.
+内部の動作を変更しているのですが、Svelte 5 はほとんどの方の場合ドロップインで置き換えられるはずです。この新機能はオプトインであるため、既存のコンポーネントを引き続き使用することができます。
-We don't yet have a release date for Svelte 5. What we're showing you here is a work-in-progress that is likely to change!
+Svelte 5 のリリース日はまだ決まっていません。ここでお見せするものはまだ作業中のものであり、変更される可能性があります！
-## What are runes?
+## Rune とは
> [!NOTE] **rune** /ro͞on/ _noun_
>
-> A letter or mark used as a mystical or magic symbol.
+> 神秘的で魔法的なシンボルとして使用される文字、またはマーク。
-Runes are symbols that influence the Svelte compiler. Whereas Svelte today uses `let`, `=`, the `export` keyword and the `$:` label to mean specific things, runes use _function syntax_ to achieve the same things and more.
+Rune は Svelte コンパイラに働きかけるシンボルです。現在の Svelte では `let`、`=`、[`export`](https://learn.svelte.jp/tutorial/declaring-props) キーワード、そして [`$:`](https://learn.svelte.jp/tutorial/reactive-declarations) ラベル を特殊なものとして意味するように使用するのに対し、rune は同様のことを _関数の構文(function syntax)_ で実現します。
-For example, to declare a piece of reactive state, we can use the `$state` rune:
+例えば、リアクティブなステートを宣言するには、`$state` という rune を使用します:
```svelte
@@ -70,13 +70,13 @@ For example, to declare a piece of reactive state, we can use the `$state` rune:
```
-At first glance, this might seem like a step back — perhaps even [un-Svelte-like](https://twitter.com/stolinski/status/1438173489479958536). Isn't it better if `let count` is reactive by default?
+一見すると、これは後退しているように見えるかもしれません。[Svelte らしくない(un-Svelte-like)](https://twitter.com/stolinski/status/1438173489479958536)、と。デフォルトで `let count` がリアクティブであるほうが良いのではないか？と。
-Well, no. The reality is that as applications grow in complexity, figuring out which values are reactive and which aren't can get tricky. And the heuristic only works for `let` declarations at the top level of a component, which can cause confusion. Having code behave one way inside `.svelte` files and another inside `.js` can make it hard to refactor code, for example if you need to turn something into a [store](/tutorial/svelte/introducing-stores) so that you can use it in multiple places.
+いいえ、それは違います。実際、アプリケーションが複雑になってくるにつれ、どの値がリアクティブでどの値がリアクティブでないのか判別するのが難しくなってくるのです。また、このヒューリスティックはコンポーネントのトップレベルにある `let` 宣言でのみ機能するため、混乱を招く可能性があります。コードの振る舞いが `.svelte` ファイル内と `.js` で異なっていると、コードのリファクタリングが難しくなります。例えば、何かを [store](/tutorial/svelte/introducing-stores) にして複数の場所で使えるようにする必要がある場合などです。
-## Beyond components
+## コンポーネントを越えて
-With runes, reactivity extends beyond the boundaries of your `.svelte` files. Suppose we wanted to encapsulate our counter logic in a way that could be reused between components. Today, you would use a [custom store](/docs/svelte/stores) in a `.js` or `.ts` file:
+rune を使うと、リアクティビティが `.svelte` ファイルの境界を越えて拡がっていきます。counter のロジックをコンポーネント間で再利用できるようにカプセル化したいとします。現在は、[custom store](/docs/svelte/stores) を `.js` や `.ts` ファイルで使用することになるでしょう:
```js
/// file: counter.js
@@ -92,7 +92,7 @@ export function createCounter() {
}
```
-Because this implements the _store contract_ — the returned value has a `subscribe` method — we can reference the store value by prefixing the store name with `$`:
+これは _ストアコントラクト(store contract)_ を実装しているため、戻り値には `subscribe` メソッドがあり、store の名前の先頭に `$` を付けることで その store の値を参照することができます:
```svelte
@@ -115,9 +115,9 @@ Because this implements the _store contract_ — the returned value has a `subsc
```
-This works, but it's pretty weird! We've found that the store API can get rather unwieldy when you start doing more complex things.
+動作しますが、かなり奇妙です！ store API は、複雑なことをやり始めるとかなり扱いにくくなることがわかりました。
-With runes, things get much simpler:
+rune を使えば、もっとシンプルになります:
```js
/// file: counter.svelte.js
@@ -150,30 +150,30 @@ export function createCounter() {
```
-> [!NOTE] Outside `.svelte` components, runes can only be used in `.svelte.js` and `.svelte.ts` modules.
+> [!NOTE] rune は、`.svelte` コンポーネント以外だと `.svelte.js` モジュールと `.svelte.ts` モジュールでのみ使うことができます。
-Note that we're using a [get property](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/get) in the returned object, so that `counter.count` always refers to the current value rather than the value at the time the function was called.
+戻り値のオブジェクトで [get property](https://developer.mozilla.org/docs/Web/JavaScript/Reference/Functions/get) を使用しているため、`counter.count` はこの関数が呼ばれたときの値ではなく、常に現在の値を指すことにご留意ください。
## Runtime reactivity
-Today, Svelte uses _compile-time reactivity_. This means that if you have some code that uses the `$:` label to re-run automatically when dependencies change, those dependencies are determined when Svelte compiles your component:
+現在、Svelte は _コンパイル時のリアクティビティ(compile-time reactivity)_ を使用しています。これはつまり、依存しているものが変更されたときに自動的に再実行されるよう `$:` ラベルを使用しているコードがある場合において、それらの依存関係 (dependencies) は Svelte がコンポーネントをコンパイルするときに決定される、ということです:
```svelte
```
-This works well... until it doesn't. Suppose we refactored the code above:
+これは上手く機能します…が、上手くいかないこともあります。上記のコードをリファクタリングしたとしましょう:
```js
// @errors: 7006 2304
@@ -181,9 +181,9 @@ const multiplyByHeight = (width) => width * height;
$: area = multiplyByHeight(width);
```
-Because the `$: area = ...` declaration can only 'see' `width`, it won't be recalculated when `height` changes. As a result, code is hard to refactor, and understanding the intricacies of when Svelte chooses to update which values can become rather tricky beyond a certain level of complexity.
+この `$: area = ...` の宣言では、`width` しか '把握' することができないため、`height` が変更されても再計算されなくなります。結果として、コードをリファクタリングするのが難しくなり、複雑さがあるレベルを越えてくると Svelte がいつどの値を更新するのか、ということを理解するのが難しくなってきます。
-Svelte 5 introduces the `$derived` and `$effect` runes, which instead determine the dependencies of their expressions when they are evaluated:
+Svelte 5 では `$derived` rune と `$effect` rune が導入され、評価されるときにその式の依存関係(dependencies)が決定されるようになります:
```svelte
```
-As with `$state`, `$derived` and `$effect` can also be used in your `.js` and `.ts` files.
+`$state` と同様、`$derived` と `$effect` も `.js` ファイルや `.ts` で使用することができます。
## Signal boost
-Like every other framework, we've come to the realisation that [Knockout](https://knockoutjs.com/) was right all along.
+他のすべてのフレームワークと同じように、私たちは [Knockout](https://knockoutjs.com/) が正しかったことに気が付きました。
-Svelte 5's reactivity is powered by _signals_, which are essentially [what Knockout was doing in 2010](https://dev.to/this-is-learning/the-evolution-of-signals-in-javascript-8ob). More recently, signals have been popularised by [Solid](https://www.solidjs.com/) and adopted by a multitude of other frameworks.
+Svelte 5 のリアクティビティは _signal_ によってもたらされており、これは本質的には [Knockout が 2010年に行っていたこと](https://dev.to/this-is-learning/the-evolution-of-signals-in-javascript-8ob)です。最近では、signal は [Solid](https://www.solidjs.com/) によって普及し、そして他の多くのフレームワークにも採用されています。
-We're doing things a bit differently though. In Svelte 5, signals are an under-the-hood implementation detail rather than something you interact with directly. As such, we don't have the same API design constraints, and can maximise both efficiency _and_ ergonomics. For example, we avoid the type narrowing issues that arise when values are accessed by function call, and when compiling in server-side rendering mode we can ditch the signals altogether, since on the server they're nothing but overhead.
+しかし、私たちの方法は少し異なります。Svelte 5 では、signal は直接操作をするものではなく、内部実装の詳細です。そのため、同様の API の設計上の制約がないため、効率とエルゴノミクスの両方を最大化することができます。例えば、関数呼び出しで値にアクセスすることによって発生する型の絞り込み(type narrowing)の問題を避けることができ、また、サーバーサイドレンダリングーモードでコンパイルする際には signal を完全に取り除くことができます (サーバー上では signal はオーバーヘッドだからです)。
-Signals unlock _fine-grained reactivity_, meaning that (for example) changes to a value inside a large list needn't invalidate all the _other_ members of the list. As such, Svelte 5 is ridonkulously fast.
+Signal は _きめ細やかなリアクティビティ(fine-grained reactivity)_ を実現し、それはつまり (例えば) 大きいリストの中にある値を変更しても、そのリストの他のメンバーを最新化(invalidate)する必要がないということです。そのため、Svelte 5 はとてつもなく高速です。
-## Simpler times ahead
+## よりシンプルな時代の到来
-Runes are an additive feature, but they make a whole bunch of existing concepts obsolete:
+Rune は付加的な機能ですが、既存のコンセプトの多くを不要なものにします:
-- the difference between `let` at the top level of a component and everywhere else
+- コンポーネントのトップレベルにある `let` とそれ以外の場所にある `let` の違い
- `export let`
-- `$:`, with all its attendant quirks
-- different behaviour between `
```
-> [!NOTE] Often, layout data is unchanged when navigating between pages. SvelteKit will intelligently rerun [`load`](load) functions when necessary.
+> [!NOTE] しばしば、ページ間を移動しているときにレイアウトデータが変更されないことがあります。SvelteKit は必要に応じてインテリジェントに [`load`](load) 関数を再実行します。
### +layout.server.js
-To run your layout's `load` function on the server, move it to `+layout.server.js`, and change the `LayoutLoad` type to `LayoutServerLoad`.
+サーバー上でレイアウトの `load` 関数を実行するためには、それを `+layout.server.js` に移動し、`LayoutLoad` 型を `LayoutServerLoad` に変更します。
-Like `+layout.js`, `+layout.server.js` can export [page options](page-options) — `prerender`, `ssr` and `csr`.
+`+layout.js` と同様に、`+layout.server.js` では [page options](page-options) — `prerender`、`ssr`、`csr` をエクスポートすることができます。
## +server
-As well as pages, you can define routes with a `+server.js` file (sometimes referred to as an 'API route' or an 'endpoint'), which gives you full control over the response. Your `+server.js` file exports functions corresponding to HTTP verbs like `GET`, `POST`, `PATCH`, `PUT`, `DELETE`, `OPTIONS`, and `HEAD` that take a `RequestEvent` argument and return a [`Response`](https://developer.mozilla.org/en-US/docs/Web/API/Response) object.
+ページと同様に、`+server.js` ファイル (よく 'API ルート(API route)' または 'エンドポイント(endpoint)' とも呼ばれる) でルート(routes) を定義でき、これによってレスポンスを完全にコントロールすることができます。`+server.js` ファイル は `GET`、`POST`、`PATCH`、`PUT`、`DELETE`、`OPTIONS`、`HEAD` といった HTTP verbs に対応する関数をエクスポートします。これは `RequestEvent` を引数に取り、[`Response`](https://developer.mozilla.org/ja/docs/Web/API/Response) オブジェクトを返します。
-For example we could create an `/api/random-number` route with a `GET` handler:
+例えば、`GET` ハンドラを使用した `/api/random-number` ルート(route)を作成できます:
```js
/// file: src/routes/api/random-number/+server.js
@@ -303,19 +303,19 @@ export function GET({ url }) {
}
```
-The first argument to `Response` can be a [`ReadableStream`](https://developer.mozilla.org/en-US/docs/Web/API/ReadableStream), making it possible to stream large amounts of data or create server-sent events (unless deploying to platforms that buffer responses, like AWS Lambda).
+`Response` の第一引数には [`ReadableStream`](https://developer.mozilla.org/ja/docs/Web/API/ReadableStream) を指定することができ、大量のデータをストリームしたり、server-sent events を作成したりすることができます (AWS Lambda のような、レスポンスをバッファするプラットフォームにデプロイする場合は除きます)。
-You can use the [`error`](@sveltejs-kit#error), [`redirect`](@sveltejs-kit#redirect) and [`json`](@sveltejs-kit#json) methods from `@sveltejs/kit` for convenience (but you don't have to).
+便宜上、`@sveltejs/kit` の [`error`](@sveltejs-kit#error)、[`redirect`](@sveltejs-kit#redirect)、[`json`](@sveltejs-kit#json) メソッドを使用することは可能です (ただし、使用する必要はありません)。
-If an error is thrown (either `error(...)` or an unexpected error), the response will be a JSON representation of the error or a fallback error page — which can be customised via `src/error.html` — depending on the `Accept` header. The [`+error.svelte`](#error) component will _not_ be rendered in this case. You can read more about error handling [here](errors).
+エラーがスローされる場合 (`error(...)` の場合でも、予期せぬエラーの場合でもどちらでも)、レスポンスは `Accept` ヘッダーに応じて、そのエラーの JSON 表現か、`src/error.html` でカスタマイズすることができるフォールバックエラーページとなります。この場合、[`+error.svelte`](#error) コンポーネントはレンダリングされません。エラーハンドリングに関する詳細は [こちら](errors) からお読み頂けます。
-> [!NOTE] When creating an `OPTIONS` handler, note that Vite will inject `Access-Control-Allow-Origin` and `Access-Control-Allow-Methods` headers — these will not be present in production unless you add them.
+> [!NOTE] `OPTIONS` ハンドラを作成する場合、Vite が `Access-Control-Allow-Origin` ヘッダーと `Access-Control-Allow-Methods` ヘッダーを注入することにご注意ください。本番環境では、あなたが明示的に追加しない限り注入されないはずです。
> [!NOTE] `+layout` files have no effect on `+server.js` files. If you want to run some logic before each request, add it to the server [`handle`](hooks#Server-hooks-handle) hook.
### Receiving data
-By exporting `POST`/`PUT`/`PATCH`/`DELETE`/`OPTIONS`/`HEAD` handlers, `+server.js` files can be used to create a complete API:
+`+server.js` ファイルは、`POST`/`PUT`/`PATCH`/`DELETE`/`OPTIONS`/`HEAD` ハンドラをエクスポートすることで、完全な API を作成することができます:
```svelte
@@ -355,13 +355,13 @@ export async function POST({ request }) {
}
```
-> [!NOTE] In general, [form actions](form-actions) are a better way to submit data from the browser to the server.
+> [!NOTE] 一般的には、ブラウザからサーバーにデータを送信する方法としては [form actions](form-actions) のほうがより良い方法です。
-> [!NOTE] If a `GET` handler is exported, a `HEAD` request will return the `content-length` of the `GET` handler's response body.
+> [!NOTE] `GET` ハンドラがエクスポートされている場合、`HEAD` リクエストは `GET` ハンドラのレスポンスボディの `content-length` を返します。
### Fallback method handler
-Exporting the `fallback` handler will match any unhandled request methods, including methods like `MOVE` which have no dedicated export from `+server.js`.
+`fallback` ハンドラをエクスポートすると、ハンドリングされていないリクエスト (`+server.js` にそれ専用のエクスポートがない `MOVE` などのメソッドを含む) にマッチします。
```js
/// file: src/routes/api/add/+server.js
@@ -380,21 +380,21 @@ export async function fallback({ request }) {
}
```
-> [!NOTE] For `HEAD` requests, the `GET` handler takes precedence over the `fallback` handler.
+> [!NOTE] `HEAD` リクエストの場合、`fallback` ハンドラより `GET` ハンドラが優先されます。
### Content negotiation
-`+server.js` files can be placed in the same directory as `+page` files, allowing the same route to be either a page or an API endpoint. To determine which, SvelteKit applies the following rules:
+`+server.js` ファイルは `+page` ファイルと同じディレクトリに置くことができ、これによって同じルート(route)がページにも API エンドポイントにもなるようにすることができます。これがどちらなのか判断するために、SvelteKit は以下のルールを適用します:
-- `PUT`/`PATCH`/`DELETE`/`OPTIONS` requests are always handled by `+server.js` since they do not apply to pages
-- `GET`/`POST`/`HEAD` requests are treated as page requests if the `accept` header prioritises `text/html` (in other words, it's a browser page request), else they are handled by `+server.js`.
-- Responses to `GET` requests will include a `Vary: Accept` header, so that proxies and browsers cache HTML and JSON responses separately.
+- `PUT`/`PATCH`/`DELETE`/`OPTIONS` リクエストは、ページには適用されないため、常に `+server.js` で処理されます。
+- `GET`/`POST`/`HEAD` リクエストは、`accept` ヘッダーが `text/html` を優先している場合 (言い換えると、ブラウザのページリクエストの場合)、ページリクエストとして扱われます。それ以外の場合は `+server.js` で処理されます。
+- `GET` リクエストに対するレスポンスには `Vary: Accept` ヘッダーが含まれるため、プロキシーやブラウザは HTML と JSON のレスポンスを別々にキャッシュします。
## $types
-Throughout the examples above, we've been importing types from a `$types.d.ts` file. This is a file SvelteKit creates for you in a hidden directory if you're using TypeScript (or JavaScript with JSDoc type annotations) to give you type safety when working with your root files.
+これまでの例を通してずっと、`$types.d.ts` ファイルからインポートしてきました。これは、TypeScript (または JavaScript を JSDoc の型アノテーションと) 使用している場合に最上位のファイル(root files)を扱う際に型の安全性をもたらすために SvelteKit が隠しディレクトリに作成するファイルです。
-For example, annotating `let { data } = $props()` with `PageProps` (or `LayoutProps`, for a `+layout.svelte` file) tells TypeScript that the type of `data` is whatever was returned from `load`:
+例えば、`let { data } = $props()` に `PageProps` (または `+layout.svelte` ファイルの場合は `LayoutProps`) アノテーションを付けると、`data` の型は `load` の戻り値であると TypeScript に伝えることができます:
```svelte
@@ -421,19 +421,19 @@ For example, annotating `let { data } = $props()` with `PageProps` (or `LayoutPr
> let { data, children } = $props();
> ```
-In turn, annotating the `load` function with `PageLoad`, `PageServerLoad`, `LayoutLoad` or `LayoutServerLoad` (for `+page.js`, `+page.server.js`, `+layout.js` and `+layout.server.js` respectively) ensures that `params` and the return value are correctly typed.
+`load` 関数に `PageLoad`、`PageServerLoad`、`LayoutLoad`、`LayoutServerLoad` (それぞれ `+page.js`、`+page.server.js`、`+layout.js`、`+layout.server.js`) というアノテーションを付けると、`params` と戻り値が正しく型付けされることが保証されます。
-If you're using VS Code or any IDE that supports the language server protocol and TypeScript plugins then you can omit these types _entirely_! Svelte's IDE tooling will insert the correct types for you, so you'll get type checking without writing them yourself. It also works with our command line tool `svelte-check`.
+VS Code や、language server protocol と TypeScript plugin をサポートする IDE を使用している場合は、これらの型を _完全に_ 省略することができます！ Svelte の IDE ツール類があなたのために正しい型を挿入してくれるので、あなたはご自身で型を書くことなく型チェックすることができます。これはコマンドラインツール `svelte-check` でも機能します。
-You can read more about omitting `$types` in our [blog post](/blog/zero-config-type-safety) about it.
+`$types` の省略については、私たちの[ブログ記事](/blog/zero-config-type-safety)でより詳細な情報をお読み頂けます。
-## Other files
+## その他のファイル
-Any other files inside a route directory are ignored by SvelteKit. This means you can colocate components and utility modules with the routes that need them.
+ルート(route)ディレクトリ内のその他のファイルは SvelteKit から無視されます。つまり、コンポーネントやユーティリティモジュールを、それらを必要とするルート(routes)に配置することができます。
-If components and modules are needed by multiple routes, it's a good idea to put them in [`$lib`]($lib).
+コンポーネントやモジュールが複数のルート(routes)から必要な場合、[`$lib`]($lib) にそれらを配置すると良いでしょう。
-## Further reading
+## その他の参考資料
- [Tutorial: Routing](/tutorial/kit/pages)
- [Tutorial: API routes](/tutorial/kit/get-handlers)
diff --git a/apps/svelte.dev/content/docs/kit/20-core-concepts/20-load.md b/apps/svelte.dev/content/docs/kit/20-core-concepts/20-load.md
index a93eae45f3..787bf18719 100644
--- a/apps/svelte.dev/content/docs/kit/20-core-concepts/20-load.md
+++ b/apps/svelte.dev/content/docs/kit/20-core-concepts/20-load.md
@@ -3,11 +3,11 @@ NOTE: do not edit this file, it is generated in apps/svelte.dev/scripts/sync-doc
title: Loading data
---
-Before a [`+page.svelte`](routing#page-page.svelte) component (and its containing [`+layout.svelte`](routing#layout-layout.svelte) components) can be rendered, we often need to get some data. This is done by defining `load` functions.
+[`+page.svelte`](routing#page-page.svelte) コンポーネント (と [`+layout.svelte`](routing#layout-layout.svelte) コンポーネント) をレンダリングする前に、データを取得する必要があるケースが多いでしょう。`load` 関数を定義することでこれができるようになります。
## Page data
-A `+page.svelte` file can have a sibling `+page.js` that exports a `load` function, the return value of which is available to the page via the `data` prop:
+`+page.svelte` ファイルは、`load` 関数をエクスポートする `+page.js` という兄弟ファイルを持つことができ、`load` 関数の戻り値は page で `data` プロパティを介して使用することができます。
```js
/// file: src/routes/blog/[slug]/+page.js
@@ -41,13 +41,13 @@ export function load({ params }) {
> let { data } = $props();
> ```
>
-> In Svelte 4, you'd use `export let data` instead.
+> Svelte 4 では、代わりに `export let data` を使います。
-Thanks to the generated `$types` module, we get full type safety.
+生成される `$types` モジュールのおかげで、完全な型安全性を確保できます。
-A `load` function in a `+page.js` file runs both on the server and in the browser (unless combined with `export const ssr = false`, in which case it will [only run in the browser](page-options#ssr)). If your `load` function should _always_ run on the server (because it uses private environment variables, for example, or accesses a database) then it would go in a `+page.server.js` instead.
+`+page.js` ファイルの `load` 関数はサーバーでもブラウザでも実行されます (ただし、`export const ssr = false` を設定した場合は[ブラウザでのみ実行されます](page-options#ssr))。`load` 関数を*常に*サーバーで実行させたければ (例えばプライベートな環境変数を使用していたり、データベースにアクセスする場合など)、代わりに `+page.server.js` に `load` 関数を置くとよいでしょう。
-A more realistic version of your blog post's `load` function, that only runs on the server and pulls data from a database, might look like this:
+例えばブログ記事の `load` 関数をより現実的なものにするとしたら、以下のように、サーバー上でのみ実行され、データベースからデータを取得する、というものになるでしょう。
```js
/// file: src/routes/blog/[slug]/+page.server.js
@@ -68,11 +68,11 @@ export async function load({ params }) {
}
```
-Notice that the type changed from `PageLoad` to `PageServerLoad`, because server `load` functions can access additional arguments. To understand when to use `+page.js` and when to use `+page.server.js`, see [Universal vs server](load#Universal-vs-server).
+型が `PageLoad` から `PageServerLoad` に変わっていることにご注意ください。server `load` 関数では追加の引数にアクセスすることができます。どのような場合に `+page.js` を使用し、どのような場合に `+page.server.js` を使用するのかを理解するには、[Universal vs server](load#Universal-vs-server) を参照してください。
## Layout data
-Your `+layout.svelte` files can also load data, via `+layout.js` or `+layout.server.js`.
+`+layout.svelte` ファイルでも、`+layout.js` や `+layout.server.js` を通じてデータを読み込むことができます。
```js
/// file: src/routes/blog/[slug]/+layout.server.js
@@ -127,7 +127,7 @@ export async function load() {
> let { data, children } = $props();
> ```
-Data returned from layout `load` functions is available to child `+layout.svelte` components and the `+page.svelte` component as well as the layout that it 'belongs' to.
+レイアウトの `load` 関数から返されたデータは、子の `+layout.svelte` コンポーネントやそのレイアウトに属する `+page.svelte` コンポーネントでも利用可能です。
```svelte
/// file: src/routes/blog/[slug]/+page.svelte
@@ -151,13 +151,13 @@ Data returned from layout `load` functions is available to child `+layout.svelte
{/if}+++
```
-> [!NOTE] If multiple `load` functions return data with the same key, the last one 'wins' — the result of a layout `load` returning `{ a: 1, b: 2 }` and a page `load` returning `{ b: 3, c: 4 }` would be `{ a: 1, b: 3, c: 4 }`.
+> [!NOTE] 複数の `load` 関数が同じキーを持つデータを返した場合、最後に返したものが'勝ちます'。レイアウトの `load` が `{ a: 1, b: 2 }` を返し、ページの `load` が `{ b: 3, c: 4 }` を返すと、結果は `{ a: 1, b: 3, c: 4 }` となります。
## page.data
-The `+page.svelte` component, and each `+layout.svelte` component above it, has access to its own data plus all the data from its parents.
+`+page.svelte` コンポーネントとその上の各 `+layout.svelte` コンポーネントは、自身のデータとその親の全てのデータにアクセスすることができます。
-In some cases, we might need the opposite — a parent layout might need to access page data or data from a child layout. For example, the root layout might want to access a `title` property returned from a `load` function in `+page.js` or `+page.server.js`. This can be done with `page.data`:
+場合によっては、その逆も必要かもしれません — 親レイアウトからページのデータや子レイアウトのデータにアクセスする必要があるかもしれません。例えば、最上位のレイアウト(root layout)から、`+page.js` や `+page.server.js` の `load` 関数から返された `title` プロパティにアクセスしたい場合があるでしょう。これは `page.data` で行うことができます:
```svelte
@@ -170,7 +170,7 @@ In some cases, we might need the opposite — a parent layout might need to acce
```
-Type information for `page.data` is provided by `App.PageData`.
+`page.data` の型情報は `App.PageData` から提供されます。
> [!LEGACY]
> `$app/state` was added in SvelteKit 2.12. If you're using an earlier version or are using Svelte 4, use `$app/stores` instead.
@@ -178,44 +178,44 @@ Type information for `page.data` is provided by `App.PageData`.
## Universal vs server
-As we've seen, there are two types of `load` function:
+これまで見てきたように、`load` 関数には2つの種類があります:
-* `+page.js` and `+layout.js` files export _universal_ `load` functions that run both on the server and in the browser
-* `+page.server.js` and `+layout.server.js` files export _server_ `load` functions that only run server-side
+* `+page.js` ファイルと `+layout.js` ファイルは、サーバーとブラウザの両方で実行される universal `load` 関数をエクスポートします
+* `+page.server.js` ファイルと `+layout.server.js` ファイルは、サーバーサイドでのみ実行される server `load` 関数をエクスポートします
-Conceptually, they're the same thing, but there are some important differences to be aware of.
+概念上は同じものですが、気をつけなければならない重要な違いがあります。
-### When does which load function run?
+### いつ、どの load 関数が実行されるのか？
-Server `load` functions _always_ run on the server.
+server `load` 関数は _常に_ サーバーで実行されます。
-By default, universal `load` functions run on the server during SSR when the user first visits your page. They will then run again during hydration, reusing any responses from [fetch requests](#Making-fetch-requests). All subsequent invocations of universal `load` functions happen in the browser. You can customize the behavior through [page options](page-options). If you disable [server side rendering](page-options#ssr), you'll get an SPA and universal `load` functions _always_ run on the client.
+デフォルトでは、universal `load` 関数は、ユーザーがはじめてページにアクセスしたときの SSR 中にサーバーで実行されます。そのあとのハイドレーション中に、[fetch リクエスト](#Making-fetch-requests) で取得したレスポンスを再利用してもう一度実行されます。それ以降の universal `load` 関数の呼び出しは、すべてブラウザで行われます。この動作は [page options](page-options) によってカスタマイズすることができます。[サーバーサイドレンダリング](page-options#ssr) を無効にした場合、SPA となるため、universal `load` 関数は _常に_ クライアントで実行されるようになります。
-If a route contains both universal and server `load` functions, the server `load` runs first.
+ルート(route)に universal と server の両方の `load` 関数が含まれている場合、server `load` が最初に実谷されます。
-A `load` function is invoked at runtime, unless you [prerender](page-options#prerender) the page — in that case, it's invoked at build time.
+`load` 関数は実行時に呼び出されます。ページを [プリレンダリング](page-options#prerender) する場合は、ビルド時に呼び出されます。
### Input
-Both universal and server `load` functions have access to properties describing the request (`params`, `route` and `url`) and various functions (`fetch`, `setHeaders`, `parent`, `depends` and `untrack`). These are described in the following sections.
+universal `load` 関数と server `load` 関数はどちらも、リクエストを表すプロパティ (`params`、`route`、`url`) と様々な関数 (`fetch`、`setHeaders`、`parent`、`depends`、`untrack`) にアクセスできます。これらについては、以下のセクションで説明します。
-Server `load` functions are called with a `ServerLoadEvent`, which inherits `clientAddress`, `cookies`, `locals`, `platform` and `request` from `RequestEvent`.
+server `load` 関数は `ServerLoadEvent` を引数にとって呼び出されます。`ServerLoadEvent` は、`RequestEvent` から `clientAddress`、`cookies`、`locals`、`platform`、`request` を継承しています。
-Universal `load` functions are called with a `LoadEvent`, which has a `data` property. If you have `load` functions in both `+page.js` and `+page.server.js` (or `+layout.js` and `+layout.server.js`), the return value of the server `load` function is the `data` property of the universal `load` function's argument.
+universal `load` 関数は、`LoadEvent` を引数にとって呼び出されます。`LoadEvent` は `data` プロパティを持っています。もし `+page.js` と `+page.server.js` (または `+layout.js` と `+layout.server.js`) の両方に `load` 関数がある場合、server `load` 関数の戻り値が、universal `load` 関数の引数の `data` プロパティとなります。
### Output
-A universal `load` function can return an object containing any values, including things like custom classes and component constructors.
+universal `load` 関数は、任意の値(カスタムクラスやコンポーネントコンストラクタなどを含む)を含むオブジェクトを返すことができます。
-A server `load` function must return data that can be serialized with [devalue](https://github.com/rich-harris/devalue) — anything that can be represented as JSON plus things like `BigInt`, `Date`, `Map`, `Set` and `RegExp`, or repeated/cyclical references — so that it can be transported over the network. Your data can include [promises](#Streaming-with-promises), in which case it will be streamed to browsers.
+server `load` 関数は、ネットワークで転送できるようにするために、[devalue](https://github.com/rich-harris/devalue) でシリアライズできるデータ (つまり JSON で表現できるものに加え、`BigInt`、`Date`、`Map`、`Set`、`RegExp` や、繰り返し/循環参照など) を返さなければなりません。データには [promises](#Streaming-with-promises) を含めることができ、その場合はブラウザにストリーミングされます。
-### When to use which
+### どちらを使用すべきか
-Server `load` functions are convenient when you need to access data directly from a database or filesystem, or need to use private environment variables.
+server `load` 関数は、データベースやファイルシステムからデータを直接アクセスする必要がある場合や、プライベートな環境変数を使用する必要がある場合に有用です。
-Universal `load` functions are useful when you need to `fetch` data from an external API and don't need private credentials, since SvelteKit can get the data directly from the API rather than going via your server. They are also useful when you need to return something that can't be serialized, such as a Svelte component constructor.
+universal `load` 関数は、外部の API から データを `fetch` (取得) する必要があり、プライベートなクレデンシャルが必要ない場合に便利です。なぜなら、SvelteKit はあなたのサーバーを経由せずに、その API から直接データを取得することができるからです。また、Svelte コンポーネントコンストラクタのような、シリアライズできないものを返す必要がある場合にも便利です。
-In rare cases, you might need to use both together — for example, you might need to return an instance of a custom class that was initialised with data from your server. When using both, the server `load` return value is _not_ passed directly to the page, but to the universal `load` function (as the `data` property):
+まれに、両方を同時に使用する必要がある場合もあります。例えば、サーバーからのデータで初期化されたカスタムクラスのインスタンスを返す必要がある場合です。両方を使用する場合は、server `load` の戻り値は直接ページには渡されず、universal `load` 関数に (`data` プロパティとして) 渡されます:
```js
/// file: src/routes/+page.server.js
@@ -239,19 +239,19 @@ export async function load({ data }) {
}
```
-## Using URL data
+## URL data を使用する
-Often the `load` function depends on the URL in one way or another. For this, the `load` function provides you with `url`, `route` and `params`.
+多くの場合、`load` 関数は何らかの形で URL に依存します。そのため、`load` 関数では `url`、`route`、`params` を提供しています。
### url
-An instance of [`URL`](https://developer.mozilla.org/en-US/docs/Web/API/URL), containing properties like the `origin`, `hostname`, `pathname` and `searchParams` (which contains the parsed query string as a [`URLSearchParams`](https://developer.mozilla.org/en-US/docs/Web/API/URLSearchParams) object). `url.hash` cannot be accessed during `load`, since it is unavailable on the server.
+[`URL`](https://developer.mozilla.org/ja/docs/Web/API/URL) のインスタンスで、`origin`、`hostname`、`pathname`、`searchParams` ([`URLSearchParams`](https://developer.mozilla.org/ja/docs/Web/API/URLSearchParams) オブジェクトとしてパースされたクエリ文字列を含む) を含んでいます。`url.hash` はサーバーで利用できないため、`load` 中にアクセスすることはできません。
-> [!NOTE] In some environments this is derived from request headers during server-side rendering. If you're using [adapter-node](adapter-node), for example, you may need to configure the adapter in order for the URL to be correct.
+> [!NOTE] 環境によっては、サーバーサイドレンダリング時のリクエストヘッダからこれが導出されることもあります。例えば [adapter-node](adapter-node) では、URL を正しく設定するために adapter の設定をする必要があるかもしれません。
### route
-Contains the name of the current route directory, relative to `src/routes`:
+現在のルート(route)ディレクトリの名前を含んでいます。`src/routes` との相対です:
```js
/// file: src/routes/a/[b]/[...c]/+page.js
@@ -263,9 +263,9 @@ export function load({ route }) {
### params
-`params` is derived from `url.pathname` and `route.id`.
+`params` は `url.pathname` と `route.id` から導出されます。
-Given a `route.id` of `/a/[b]/[...c]` and a `url.pathname` of `/a/x/y/z`, the `params` object would look like this:
+`route.id` が `/a/[b]/[...c]` で、`url.pathname` が `/a/x/y/z` の場合、`params` オブジェクトはこのようになります:
```json
{
@@ -274,15 +274,15 @@ Given a `route.id` of `/a/[b]/[...c]` and a `url.pathname` of `/a/x/y/z`, the `p
}
```
-## Making fetch requests
+## fetch リクエストの作成
-To get data from an external API or a `+server.js` handler, you can use the provided `fetch` function, which behaves identically to the [native `fetch` web API](https://developer.mozilla.org/en-US/docs/Web/API/fetch) with a few additional features:
+外部の API や `+server.js` ハンドラからデータを取得するには、提供されている `fetch` 関数を使用します。これは [ネイティブの `fetch` web API](https://developer.mozilla.org/ja/docs/Web/API/fetch) と同じように動作しますが、いくつか追加の機能があります:
-- It can be used to make credentialed requests on the server, as it inherits the `cookie` and `authorization` headers for the page request.
-- It can make relative requests on the server (ordinarily, `fetch` requires a URL with an origin when used in a server context).
-- Internal requests (e.g. for `+server.js` routes) go directly to the handler function when running on the server, without the overhead of an HTTP call.
-- During server-side rendering, the response will be captured and inlined into the rendered HTML by hooking into the `text`, `json` and `arrayBuffer` methods of the `Response` object. Note that headers will _not_ be serialized, unless explicitly included via [`filterSerializedResponseHeaders`](hooks#Server-hooks-handle).
-- During hydration, the response will be read from the HTML, guaranteeing consistency and preventing an additional network request - if you received a warning in your browser console when using the browser `fetch` instead of the `load` `fetch`, this is why.
+- ページリクエストの `cookie` と `authorization` ヘッダーを継承するので、サーバー上でクレデンシャル付きのリクエストを行うことができます
+- サーバー上で、相対パスのリクエストを行うことができます (通常、`fetch` はサーバーのコンテキストで使用する場合にはオリジン付きの URL が必要です)
+- サーバーで動作している場合、内部リクエスト (例えば `+server.js` ルート(routes)に対するリクエスト) は直接ハンドラ関数を呼び出すので、HTTP を呼び出すオーバーヘッドがありません
+- サーバーサイドレンダリング中は、`Response` オブジェクトの `text` メソッドと `json` メソッドと `arrayBuffer` メソッドにフックすることにより、レスポンスはキャプチャされ、レンダリング済の HTML にインライン化されます。ヘッダーは、[`filterSerializedResponseHeaders`](hooks#Server-hooks-handle) で明示的に指定されない限り、シリアライズされないことにご注意ください。
+- ハイドレーション中は、レスポンスは HTML から読み込まれるため、一貫性が保証され、追加のネットワークリクエストを防ぎます。もし、`load` 関数の `fetch` ではなくブラウザの `fetch` を使用しているときにブラウザコンソールに警告が出た場合は、これが理由です。
```js
/// file: src/routes/items/[id]/+page.js
@@ -297,14 +297,14 @@ export async function load({ fetch, params }) {
## Cookies
-A server `load` function can get and set [`cookies`](@sveltejs-kit#Cookies).
+server `load` 関数では [`cookies`](@sveltejs-kit#Cookies) を取得したり設定したりすることができます。
```js
/// file: src/routes/+layout.server.js
// @filename: ambient.d.ts
declare module '$lib/server/database' {
export function getUser(sessionid: string | undefined): Promise<{ name: string, avatar: string }>
-}
+rerunning-load-functions}
// @filename: index.js
// ---cut---
@@ -320,19 +320,19 @@ export async function load({ cookies }) {
}
```
-Cookies will only be passed through the provided `fetch` function if the target host is the same as the SvelteKit application or a more specific subdomain of it.
+Cookie は、ターゲットホストが Sveltekit アプリケーションと同じか、より明確・詳細(specific)なサブドメインである場合にのみ、SvelteKit から提供される `fetch` 関数を介して引き渡されます。
-For example, if SvelteKit is serving my.domain.com:
-- domain.com WILL NOT receive cookies
-- my.domain.com WILL receive cookies
-- api.domain.com WILL NOT receive cookies
-- sub.my.domain.com WILL receive cookies
+例えば、SvelteKit が my.domain.com でサーブしている場合:
+- domain.com は cookie を受け取りません
+- my.domain.com は cookie を受け取ります
+- api.domain.com は cookie を受け取りません
+- sub.my.domain.com は cookie を受け取ります
-Other cookies will not be passed when `credentials: 'include'` is set, because SvelteKit does not know which domain which cookie belongs to (the browser does not pass this information along), so it's not safe to forward any of them. Use the [handleFetch hook](hooks#Server-hooks-handleFetch) to work around it.
+その他の cookie は、`credentials: 'include'` がセットされているときには渡されません。なぜなら、Sveltekit はどの cookie がどのドメインに属しているかわからないからです (ブラウザはこの情報を渡さないからです)。そのため、cookie を転送するのは安全ではありません。これを回避するには、[handleFetch hook](hooks#Server-hooks-handleFetch) をお使いください。
## Headers
-Both server and universal `load` functions have access to a `setHeaders` function that, when running on the server, can set headers for the response. (When running in the browser, `setHeaders` has no effect.) This is useful if you want the page to be cached, for example:
+server `load` 関数と universal `load` 関数はどちらも `setHeaders` 関数にアクセスでき、サーバー上で実行している場合、 レスポンスにヘッダーを設定できます (ブラウザで実行している場合、`setHeaders` には何の効果もありません)。これは、ページをキャッシュさせる場合に便利です、例えば:
```js
// @errors: 2322 1360
@@ -353,11 +353,11 @@ export async function load({ fetch, setHeaders }) {
}
```
-Setting the same header multiple times (even in separate `load` functions) is an error. You can only set a given header once using the `setHeaders` function. You cannot add a `set-cookie` header with `setHeaders` — use `cookies.set(name, value, options)` instead.
+同じヘッダーを複数回設定することは (たとえ別々の `load` 関数であっても) エラーとなります。指定したヘッダーを設定できるのは一度だけです。`set-cookie` ヘッダーは、`setHeaders` では追加できません。代わりに、`cookies.set(name, value, options)` を使用してください。
## Using parent data
-Occasionally it's useful for a `load` function to access data from a parent `load` function, which can be done with `await parent()`:
+`load` 関数が親の `load` 関数からのデータにアクセスできたら便利なことがあるでしょう。`await parent()` でこれを行うことができます:
```js
/// file: src/routes/+layout.js
@@ -396,13 +396,13 @@ export async function load({ parent }) {
{data.a} + {data.b} = {data.c}
```
-> [!NOTE] Notice that the `load` function in `+page.js` receives the merged data from both layout `load` functions, not just the immediate parent.
+> [!NOTE] `+page.js` の `load` 関数が、直接の親だけなく、両方のレイアウトの `load` 関数からマージされたデータを受け取っていることにご注意ください。
-Inside `+page.server.js` and `+layout.server.js`, `parent` returns data from parent `+layout.server.js` files.
+`+page.server.js` と `+layout.server.js` の中では、`parent` は親の `+layout.server.js` ファイルからデータを取得します。
-In `+page.js` or `+layout.js` it will return data from parent `+layout.js` files. However, a missing `+layout.js` is treated as a `({ data }) => data` function, meaning that it will also return data from parent `+layout.server.js` files that are not 'shadowed' by a `+layout.js` file
+`+page.js` や `+layout.js` では、親の `+layout.js` ファイルからデータを返します。しかし、`+layout.js` が見つからない場合は `({ data }) => data` 関数として扱われます。つまり、`+layout.js` ファイルによって'シャドウ(shadowed)'されていない親の `+layout.server.js` ファイルからデータを返します。
-Take care not to introduce waterfalls when using `await parent()`. Here, for example, `getData(params)` does not depend on the result of calling `parent()`, so we should call it first to avoid a delayed render.
+`await parent()` を使用する際はウォータフォールを発生させないよう注意してください。例えば、こちらの `getData(params)` は `parent()` の呼び出しの結果には依存しないので、レンダリングの遅延を避けるために最初に呼び出すほうが良いでしょう。
```js
/// file: +page.js
@@ -426,7 +426,7 @@ export async function load({ params, parent }) {
## Errors
-If an error is thrown during `load`, the nearest [`+error.svelte`](routing#error) will be rendered. For [_expected_](errors#Expected-errors) errors, use the `error` helper from `@sveltejs/kit` to specify the HTTP status code and an optional message:
+`load` 中にエラーがスローされた場合、最も近くにある [`+error.svelte`](routing#error) がレンダリングされます。[想定されるエラー](errors#Expected-errors)には、`@sveltejs/kit` からインポートできる `error` ヘルパーを使用して HTTP ステータスコードとオプションのメッセージを指定できます:
```js
/// file: src/routes/admin/+layout.server.js
@@ -456,15 +456,15 @@ export function load({ locals }) {
}
```
-Calling `error(...)` will throw an exception, making it easy to stop execution from inside helper functions.
+`error(...)` を呼び出すと例外がスローされるため、ヘルパー関数の内側から簡単に実行を止めることができます。
-If an [_unexpected_](errors#Unexpected-errors) error is thrown, SvelteKit will invoke [`handleError`](hooks#Shared-hooks-handleError) and treat it as a 500 Internal Error.
+[予期せぬエラー](errors#Unexpected-errors)がスローされた場合、SvelteKit は [`handleError`](hooks#Shared-hooks-handleError) を呼び出し、それを 500 Internal Error として処理します。
-> [!NOTE] [In SvelteKit 1.x](migrating-to-sveltekit-2#redirect-and-error-are-no-longer-thrown-by-you) you had to `throw` the error yourself
+> [!NOTE] [SvelteKit 1.x 系では](migrating-to-sveltekit-2#redirect-and-error-are-no-longer-thrown-by-you)、ご自分で error を `throw` する必要がありました
## Redirects
-To redirect users, use the `redirect` helper from `@sveltejs/kit` to specify the location to which they should be redirected alongside a `3xx` status code. Like `error(...)`, calling `redirect(...)` will throw an exception, making it easy to stop execution from inside helper functions.
+ユーザーをリダイレクトさせるには、`@sveltejs/kit` からインポートできる `redirect` ヘルパーを使用して、ステータスコード `3xx` と一緒にリダイレクト先の location を指定します。`error(...)` と同じように、`redirect(...)` を呼び出すと例外がスローされるため、ヘルパー関数の内側から簡単に実行を止めることができます。
```js
/// file: src/routes/user/+layout.server.js
@@ -489,15 +489,15 @@ export function load({ locals }) {
}
```
-> [!NOTE] Don't use `redirect()` inside a `try {...}` block, as the redirect will immediately trigger the catch statement.
+> [!NOTE] `try {...}` ブロックの中で `redirect()` を使用してはいけません。redirect がすぐにその catch ステートメントをトリガーしてしまうからです。
-In the browser, you can also navigate programmatically outside of a `load` function using [`goto`]($app-navigation#goto) from [`$app.navigation`]($app-navigation).
+ブラウザでは、[`$app.navigation`]($app-navigation) からインポートできる [`goto`]($app-navigation#goto) を使うことで、`load` 関数の外側でプログラム的にナビゲーションを行うことができます。
-> [!NOTE] [In SvelteKit 1.x](migrating-to-sveltekit-2#redirect-and-error-are-no-longer-thrown-by-you) you had to `throw` the `redirect` yourself
+> [!NOTE] [SvelteKit 1.x 系では](migrating-to-sveltekit-2#redirect-and-error-are-no-longer-thrown-by-you)、ご自分で `redirect` を `throw` する必要がありました
## Streaming with promises
-When using a server `load`, promises will be streamed to the browser as they resolve. This is useful if you have slow, non-essential data, since you can start rendering the page before all the data is available:
+server `load` を使用する場合、promise が解決されると同時にブラウザにストリームされます。これにより、遅くて重要でないデータがある場合でも、すべてのデータが利用可能になる前にページのレンダリングを開始することができます:
```js
/// file: src/routes/blog/[slug]/+page.server.js
@@ -522,7 +522,7 @@ export async function load({ params }) {
}
```
-This is useful for creating skeleton loading states, for example:
+これはロード状態(loading states)のスケルトンを作成するのに便利です、例えば:
```svelte
@@ -545,7 +545,7 @@ This is useful for creating skeleton loading states, for example:
{/await}
```
-When streaming data, be careful to handle promise rejections correctly. More specifically, the server could crash with an "unhandled promise rejection" error if a lazy-loaded promise fails before rendering starts (at which point it's caught) and isn't handling the error in some way. When using SvelteKit's `fetch` directly in the `load` function, SvelteKit will handle this case for you. For other promises, it is enough to attach a noop-`catch` to the promise to mark it as handled.
+データをストリーミングする場合は、promise の reject を正しく処理するようにしてください。具体的には、レンダリングの開始時点 (本来この時点で catch される) より前に遅延ロード (lazy-loaded) された promise が失敗し、エラーを処理していない場合、server が "unhandled promise rejection" エラーでクラッシュする可能性があります。SvelteKit の `fetch` を `load` 関数で直接使用する場合は SvelteKit がこのケースを処理してくれます。それ以外の promise の場合は、何もしない `catch` (noop-`catch`) をアタッチし、処理済であることを明示するだけで十分です。
```js
/// file: src/routes/+page.server.js
@@ -562,23 +562,23 @@ export function load({ fetch }) {
}
```
-> [!NOTE] On platforms that do not support streaming, such as AWS Lambda or Firebase, responses will be buffered. This means the page will only render once all promises resolve. If you are using a proxy (e.g. NGINX), make sure it does not buffer responses from the proxied server.
+> [!NOTE] AWS Lambda や Firebase のような ストリーミングをサポートしないプラットフォームでは、レスポンスはバッファされます。つまり、すべての promise が解決してからでないとページがレンダリングされないということです。もしプロキシ (例えば NGINX) を使用している場合は、プロキシされたサーバーからのレスポンスをバッファしないようにしてください。
-> [!NOTE] Streaming data will only work when JavaScript is enabled. You should avoid returning promises from a universal `load` function if the page is server rendered, as these are _not_ streamed — instead, the promise is recreated when the function reruns in the browser.
+> [!NOTE] ストリーミングデータは JavaScript が有効なときにのみ動作します。ページがサーバーでレンダリングされる場合、universal `load` 関数からは promise を返すのは避けたほうがよいでしょう、ストリーミングされないからです (代わりに、関数がブラウザで再実行されるときに promise が再作成されます)。
-> [!NOTE] The headers and status code of a response cannot be changed once the response has started streaming, therefore you cannot `setHeaders` or throw redirects inside a streamed promise.
+> [!NOTE] レスポンスのヘッダーとステータスコードは、レスポンスがストリーミングを開始すると変更することはできなくなります。そのため、ストリームされた promise の中で `setHeaders` を呼んだりリダイレクトをスローしたりすることはできません。
-> [!NOTE] [In SvelteKit 1.x](migrating-to-sveltekit-2#Top-level-promises-are-no-longer-awaited) top-level promises were automatically awaited, only nested promises were streamed.
+> [!NOTE] [SvelteKit 1.x 系では](migrating-to-sveltekit-2#Top-level-promises-are-no-longer-awaited)、トップレベルの promise は自動的に await され、ネストした promise だけがストリーミングされていました。
## Parallel loading
-When rendering (or navigating to) a page, SvelteKit runs all `load` functions concurrently, avoiding a waterfall of requests. During client-side navigation, the result of calling multiple server `load` functions are grouped into a single response. Once all `load` functions have returned, the page is rendered.
+ページをレンダリング (またはページにナビゲーション) するとき、SvelteKit はすべての `load` 関数を同時に実行し、リクエストのウォーターフォールを回避します。クライアントサイドナビゲーションのときは、複数の server `load` 関数の呼び出し結果が単一のレスポンスにグループ化されます。すべての `load` 関数が返されると、ページがレンダリングされます。
-## Rerunning load functions
+## load 関数の再実行
-SvelteKit tracks the dependencies of each `load` function to avoid rerunning it unnecessarily during navigation.
+SvelteKit は それぞれの `load` 関数の依存関係を追跡し、ナビゲーションの際に不必要に再実行されるのを回避します。
-For example, given a pair of `load` functions like these...
+例えば、このような `load` 関数のペアがあるとして…
```js
/// file: src/routes/blog/[slug]/+page.server.js
@@ -618,17 +618,17 @@ export async function load() {
}
```
-...the one in `+page.server.js` will rerun if we navigate from `/blog/trying-the-raw-meat-diet` to `/blog/i-regret-my-choices` because `params.slug` has changed. The one in `+layout.server.js` will not, because the data is still valid. In other words, we won't call `db.getPostSummaries()` a second time.
+…もし、`/blog/trying-the-raw-meat-diet` から `/blog/i-regret-my-choices` に移動したら、`params.slug` が変更されているので、`+page.server.js` のほうは再実行されるでしょう。`+layout.server.js` のほうは再実行されません、なぜならデータがまだ有効だからです。言い換えると、`db.getPostSummaries()` を2回呼び出すことはないということです。
-A `load` function that calls `await parent()` will also rerun if a parent `load` function is rerun.
+`await parent()` を呼び出している `load` 関数は、親の `load` 関数が再実行された場合に再実行されます。
-Dependency tracking does not apply _after_ the `load` function has returned — for example, accessing `params.x` inside a nested [promise](#Streaming-with-promises) will not cause the function to rerun when `params.x` changes. (Don't worry, you'll get a warning in development if you accidentally do this.) Instead, access the parameter in the main body of your `load` function.
+依存関係の追跡は、`load` 関数から返したあとには適用されません。例えば、ネストした [promise](#Streaming-with-promises) の内側で `params.x` にアクセスしている場合、`params.x` が変更されても関数の再実行は行われません (ご心配なく、誤ってこれを行っても開発中に警告が表示されます)。代わりに、`load` 関数の本体部分でパラメータにアクセスしてください。
-Search parameters are tracked independently from the rest of the url. For example, accessing `event.url.searchParams.get("x")` inside a `load` function will make that `load` function re-run when navigating from `?x=1` to `?x=2`, but not when navigating from `?x=1&y=1` to `?x=1&y=2`.
+search parameter は url の他の部分とは独立し追跡されます。例えば、`load` 関数の中で `event.url.searchParams.get("x")` にアクセスすると、`?x=1` から `?x=2` にナビゲーションするときにその `load` 関数が再実行されますが、`?x=1&y=1` から `?x=1&y=2` にナビゲーションするときには再実行されません。
### Untracking dependencies
-In rare cases, you may wish to exclude something from the dependency tracking mechanism. You can do this with the provided `untrack` function:
+まれに、依存関係の追跡メカニズムからなにかを除外したいケースがあります。このような場合、`untrack` 関数を使用します:
```js
/// file: src/routes/+page.js
@@ -643,9 +643,9 @@ export async function load({ untrack, url }) {
### Manual invalidation
-You can also rerun `load` functions that apply to the current page using [`invalidate(url)`]($app-navigation#invalidate), which reruns all `load` functions that depend on `url`, and [`invalidateAll()`]($app-navigation#invalidateAll), which reruns every `load` function. Server load functions will never automatically depend on a fetched `url` to avoid leaking secrets to the client.
+現在のページに適用される `load` 関数は、[`invalidate(url)`]($app-navigation#invalidate) を使用することで再実行させることもできます。これは `url` に依存しているすべての `load` 関数を再実行させるものです。[`invalidateAll()`]($app-navigation#invalidateAll) は、すべての `load` 関数を再実行させます。server load 関数の場合は、クライアントに秘情報が漏れるのを防ぐため、取得した `url` に自動的に依存することはありません。
-A `load` function depends on `url` if it calls `fetch(url)` or `depends(url)`. Note that `url` can be a custom identifier that starts with `[a-z]:`:
+`load` 関数が `fetch(url)` や `depends(url)` を呼び出している場合、その `load` 関数は `url` に依存しています。`url` には `[a-z]:` から始まるカスタムの識別子を指定することができることにご注意ください:
```js
/// file: src/routes/random-number/+page.js
@@ -684,35 +684,34 @@ export async function load({ fetch, depends }) {
```
-### When do load functions rerun?
+### load 関数はいつ再実行されるのか
-To summarize, a `load` function will rerun in the following situations:
+まとめると、`load` 関数は以下のシチュエーションで再実行されます:
-- It references a property of `params` whose value has changed
-- It references a property of `url` (such as `url.pathname` or `url.search`) whose value has changed. Properties in `request.url` are _not_ tracked
-- It calls `url.searchParams.get(...)`, `url.searchParams.getAll(...)` or `url.searchParams.has(...)` and the parameter in question changes. Accessing other properties of `url.searchParams` will have the same effect as accessing `url.search`.
-- It calls `await parent()` and a parent `load` function reran
-- A child `load` function calls `await parent()` and is rerunning, and the parent is a server load function
-- It declared a dependency on a specific URL via [`fetch`](#Making-fetch-requests) (universal load only) or [`depends`](@sveltejs-kit#LoadEvent), and that URL was marked invalid with [`invalidate(url)`]($app-navigation#invalidate)
-- All active `load` functions were forcibly rerun with [`invalidateAll()`]($app-navigation#invalidateAll)
+- `params` のプロパティを参照していて、その値が変更された場合
+- `url` のプロパティ (例えば `url.pathname` や `url.search`) を参照していて、その値が変更された場合。`request.url` のプロパティは追跡されません
+- `url.searchParams.get(...)` や `url.searchParams.getAll(...)` や `url.searchParams.has(...)` を呼び出しており、その該当するパラメータが変更された場合。`url.searchParams` の他のプロパティにアクセスした場合は、`url.search` にアクセスした場合と同じ効果になる。
+- `await parent()` を呼び出していて、親の `load` 関数が再実行されたとき
+- [`fetch`](#Making-fetch-requests) (universal load のみ) や [`depends`](@sveltejs-kit#LoadEvent) を介して特定の URL に対する依存を宣言していて、その URL が [`invalidate(url)`]($app-navigation#invalidate) で無効(invalid)であるとマークされた場合
+- [`invalidateAll()`]($app-navigation#invalidateAll) によって全ての有効な `load` 関数が強制的に再実行された場合
-`params` and `url` can change in response to a `` link click, a [`
```
-The returned data must be serializable as JSON. Beyond that, the structure is entirely up to you. For example, if you had multiple forms on the page, you could distinguish which `
```
-Note that you need to `deserialize` the response before processing it further using the corresponding method from `$app/forms`. `JSON.parse()` isn't enough because form actions - like `load` functions - also support returning `Date` or `BigInt` objects.
+処理を進める前に、`$app/forms` の `deserialize` でレスポンスをデシリアライズする必要があることにご注意ください。`JSON.parse()` では不十分です。なぜなら、例えば `load` 関数のような form action は、`Date` や `BigInt` オブジェクトも戻り値としてサポートしているからです。
-If you have a `+server.js` alongside your `+page.server.js`, `fetch` requests will be routed there by default. To `POST` to an action in `+page.server.js` instead, use the custom `x-sveltekit-action` header:
+もし `+page.server.js` と `+server.js` のどちらも存在する場合、デフォルトでは、`fetch` リクエストは `+server.js` のほうにルーティングされます。`+page.server.js` の action に `POST` をするには、カスタムの `x-sveltekit-action` ヘッダーを使用します:
```js
const response = await fetch(this.action, {
@@ -481,7 +481,7 @@ const response = await fetch(this.action, {
## Alternatives
-Form actions are the preferred way to send data to the server, since they can be progressively enhanced, but you can also use [`+server.js`](routing#server) files to expose (for example) a JSON API. Here's how such an interaction could look like:
+サーバーにデータを送信する方法として、プログレッシブな強化(progressively enhance)を行うことができるため Form actions は望ましい方法ですが、[`+server.js`](routing#server) ファイルを使用して (例えば) JSON API を公開することもできます。それは例えばこのように行います:
```svelte
@@ -507,9 +507,9 @@ export function POST() {
## GET vs POST
-As we've seen, to invoke a form action you must use `method="POST"`.
+これまで見てきたように、フォームアクションを使うには、`method="POST"` を使用する必要があります。
-Some forms don't need to `POST` data to the server — search inputs, for example. For these you can use `method="GET"` (or, equivalently, no `method` at all), and SvelteKit will treat them like `` elements, using the client-side router instead of a full page navigation:
+サーバーにデータを `POST` する必要がないフォームもあるでしょう — 例えば検索入力(search inputs)です。これに対応するには `method="GET"` (または、`method` を全く書かないのも同等です) を使うことができ、そして SvelteKit はそれを `` 要素のように扱い、フルページナビゲーションの代わりにクライアントサイドルーターを使用します。:
```html
```
-Submitting this form will navigate to `/search?q=...` and invoke your load function but will not invoke an action. As with `` elements, you can set the [`data-sveltekit-reload`](link-options#data-sveltekit-reload), [`data-sveltekit-replacestate`](link-options#data-sveltekit-replacestate), [`data-sveltekit-keepfocus`](link-options#data-sveltekit-keepfocus) and [`data-sveltekit-noscroll`](link-options#data-sveltekit-noscroll) attributes on the `
