You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/content/docs/02.guide/07.lazy-load-translations.md
+6Lines changed: 6 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -75,6 +75,12 @@ About `defineI18nLocale()`{lang="ts"} details, see the [here](/docs/composables/
75
75
This is decided per locale, by reading the locale file at build time: message functions are found through variables, spreads and loader `return`s **within that file**. Ones the file cannot reveal - imported from another module, or built from runtime values - are not detected. Those are reported with a warning in development and while prerendering.
76
76
::
77
77
78
+
::callout{icon="i-heroicons-light-bulb"}
79
+
The server runs loader functions outside the Nuxt app, so they can only use APIs that exist in the browser and in Nitro, such as `$fetch()`{lang="ts"} and `useRuntimeConfig()`{lang="ts"}. A locale file calling a Nuxt app composable (`useNuxtApp()`{lang="ts"}, `useState()`{lang="ts"}, `useCookie()`{lang="ts"}, ...) is loaded inside the Nuxt app instead, on both server and client, and is not served from the messages endpoint.
80
+
81
+
See [where a loader runs](/docs/composables/define-i18n-locale#where-the-loader-runs) for what that costs and what stays undetected.
82
+
::
83
+
78
84
If the function returns an Object available in nuxt i18n module, you can configure the dynamic locale messages, like the API (including external API) or back-end, via fetch:
A loader runs on the server as well as in the browser. In a production build the server runs it outside the Nuxt app - that is what lets its messages be served from the [messages endpoint](/docs/guide/lazy-load-translations) - so it can only use APIs that exist in both places, such as `$fetch()`{lang="ts"} and `useRuntimeConfig()`{lang="ts"}. Nitro-only APIs (the h3 utilities, `useStorage()`{lang="ts"}) are not available in the browser, or in development where loaders always run in the Nuxt app.
45
+
46
+
Nuxt app composables (`useNuxtApp()`{lang="ts"}, `useState()`{lang="ts"}, `useCookie()`{lang="ts"}, `useRequestHeaders()`{lang="ts"}, ...) are the exception: a locale file calling one keeps its loader inside the Nuxt app instead, and is loaded there on both server and client. That is decided at build time, by reading the calls the locale file makes itself. A composable reached through an imported helper is not visible, and fails when the server loads that locale - call it in the locale file to make it detectable.
47
+
48
+
```ts [i18n/locales/en.ts]
49
+
exportdefaultdefineI18nLocale(asynclocale=> {
50
+
// loaded in the Nuxt app, not through the messages endpoint
Messages for such a locale are produced per request during SSR and again in the browser, and the locale file ships in the client bundle. A loader that reads server-only resources (a database, an internal service) must not use these composables - keep it loadable by the server.
0 commit comments