@lwrjs/i18n

The i18n API lets you add internationalization support to your Lightning Web Runtime on Node.js (LWR-JS) application. Based on a user’s locale, you can use this package to:

• Translate strings into different languages
• Load different content on a page
• Translate user-inputted text

For LWR-JS, you have to format your locales as UTS Locale Identifiers. A locale identifier has the structure language-region-script. The language value is required while region and script are optional.

For example, the en-US identifier refers to English (en) spoken in the United States (US). The en identifier only refers to English without a specific geographical region.

To set which locales your application supports, create an i18n section in lwr.config.json and add a subsection called locales. To set the default locale for your site’s content, create a defaultLocale subsection and set it to a single locale.

1{
2    "i18n": {
3        // These are all the locales you want to support in your application
4        "locales": [{ "id": "en-US" }, { "id": "fr" }, { "id": "nl-NL", "fallback": "fr" }],
5        // This is the default locale you want to be used when visiting
6        // a non-locale prefixed path e.g. `/hello`
7        "defaultLocale": "en-US"
8    }
9}

To implement the locale rules that you created in Set Supported Locales in lwr.config.json, you have to set up a URI pattern for handling locales. With LWR-JS, you can choose from path prefix routing and custom routing.

Path prefix routing adds locale information to the user’s URL. To use path prefix routing in your site, add "uriPattern": "path-prefix" to the i18n section of lwr.config.json.

For example, let’s say the site MyExampleSite uses the following i18n configuration.

1{
2    "i18n": {
3        // Supported locales: en-US, fr, nl-NL
4        "locales": [{ "id": "en-US" }, { "id": "fr" }, { "id": "nl-NL", "fallback": "fr" }],
5        "defaultLocale": "en-US",
6        // Use path prefix routing
7        "uriPattern": "path-prefix"
8    },
9    "routes": [
10        {
11            "id": "blog",
12            "path": "/blog",
13            "rootComponent": "demo/blog"
14        }
15    ]
16}

This site’s URL is https://myexamplesite.com. It has the route /blog, which supports these URLs.

• https://myexamplesite.com/blog
• https://myexamplesite.com/fr/blog
• https://myexamplesite.com/nl-nl/blog

Although the MyExampleSite website registers each route with the default locale prefix, users that try to access those URLs (like https://myexamplesite.com/en-us/blog) get redirected to that URL without the prefix (https://myexamplesite.com/blog).

If you don’t set uriPattern in lwr.config.json, you have to use the :locale token in your routes configuration to define how URLs represent localized pages.

Here’s an example of a config file for a site with a /blog route that uses custom URI routing.

1{
2    "i18n": {
3        // Supported locales: en-US, fr, nl-NL
4        "locales": [{ "id": "en-US" }, { "id": "fr" }, { "id": "nl-NL", "fallback": "fr" }],
5        "defaultLocale": "en-US"
6        // "path-prefix" isn't set
7    },
8    "routes": [
9        {
10            "id": "blog",
11            "path": "/blog",
12            "rootComponent": "demo/blog"
13        },
14        // `blog-localized` sets up URL path for a dynamic locale value
15        {
16            "id": "blog-localized",
17            "path": ":locale/blog",
18            "rootComponent": "demo/blog"
19        }
20    ]
21}

If you want your API calls to have access to locale information, the following objects have a locale property that you can reference.

The page information object (page) includes a locale property that you can use in your template.

1<script>
2    const userLang = '{{page.locale}}';
3    // Redirect if we support the desired locale
4    const supportedLocales = ['fr', 'nl-NL'];
5    if (supportedLocales.includes(userLang) && !window.location.pathname.startsWith(`/${userLang}`)) {
6        window.location.href = `/${userLang}${window.location.pathname}`;
7    }
8</script>

The SsrRequestContext object also contains the locale property.

When a component is server-side rendered (SSRed), LWR-JS calls the getServerData() hook. This function returns public properties to the component.

1export async function getServerData(context: SsrRequestContext): Promise<SsrDataResponse> {
2    // This is called to fetch data when the component is SSRed
3    const topic = context.params.topic;
4    const locale = context.locale;
5    const response = await fetch(
6        `https://www.googleapis.com/books/v1/volumes?q=subject:${topic}&langRestrict=${locale}`,
7    );
8    const data = await response.json();
9    return { props: { data, ...context.params } };
10}

Only in LWR-JS, the lwr/environment module contains the current locale in the locale value. locale doesn’t get populated within the Salesforce platform, but you can import it like this:

1import { locale } from 'lwr/environment';

j

Get Started

Quick Start

Content and Layout Templates

Routing

Compile-Time Data

Project Configuration

Server-Side Rendering

Packages and Modules

Module Providers

Label Module Provider

@lwrjs/security

@lwrjs/auth-middleware

@lwrjs/i18n

Salesforce Platform Integrations

LWR on Node.js Troubleshooting Guide