---
schema_version: "1"
id: caa54184c13ab4b67cffe06dba1cc4a768cd8f6c63e9746926bc1f2823057f8d
title: "@lwrjs/i18n"
collection: developer
version: current
locale: en-us
portal_url: https://docs.salesforce.com/developer/current/en-us/lwr-node/lwr/guides/lwr-i18n.md
canonical_url: https://developer.salesforce.com/docs/platform/lwr/guide/lwr-i18n.html
source_site: developer.salesforce.com
content_type: documentation
content_hash: 128b2db417f5e03a1693ebbc517690fbc03cadbff215ca126146f4e9729a36bd
products:
  - Lightning Web Runtime
---
# @lwrjs/i18n

The [i18n API](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Internationalization) 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

## Set Supported Locales in lwr.config.json

For LWR-JS, you have to format your locales as [UTS Locale Identifiers](https://www.unicode.org/reports/tr35/tr35-59/tr35.html#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.

```
{
    "i18n": {
        // These are all the locales you want to support in your application
        "locales": [{ "id": "en-US" }, { "id": "fr" }, { "id": "nl-NL", "fallback": "fr" }],
        // This is the default locale you want to be used when visiting
        // a non-locale prefixed path e.g. `/hello`
        "defaultLocale": "en-US"
    }
}
```

## Handle Locales with URI Patterns

To implement the locale rules that you created in [Set Supported Locales in lwr.config.json](#set-supported-locales-in-lwrconfigjson), you have to set up a URI pattern for handling locales. With LWR-JS, you can choose from path prefix routing and custom routing.

### Routing with Path Prefixes

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.

```
{
    "i18n": {
        // Supported locales: en-US, fr, nl-NL
        "locales": [{ "id": "en-US" }, { "id": "fr" }, { "id": "nl-NL", "fallback": "fr" }],
        "defaultLocale": "en-US",
        // Use path prefix routing
        "uriPattern": "path-prefix"
    },
    "routes": [
        {
            "id": "blog",
            "path": "/blog",
            "rootComponent": "demo/blog"
        }
    ]
}
```

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`).

### Custom Locale Routing

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.

```
{
    "i18n": {
        // Supported locales: en-US, fr, nl-NL
        "locales": [{ "id": "en-US" }, { "id": "fr" }, { "id": "nl-NL", "fallback": "fr" }],
        "defaultLocale": "en-US"
        // "path-prefix" isn't set
    },
    "routes": [
        {
            "id": "blog",
            "path": "/blog",
            "rootComponent": "demo/blog"
        },
        // `blog-localized` sets up URL path for a dynamic locale value
        {
            "id": "blog-localized",
            "path": ":locale/blog",
            "rootComponent": "demo/blog"
        }
    ]
}
```

## Access Locales with API Calls

If you want your API calls to have access to locale information, the following objects have a `locale` property that you can reference.

### page

The page information object (`page`) includes a locale property that you can use in your [template](https://developer.salesforce.com/docs/platform/lwr/guide/lwr-templates.md).

```
<script>
    const userLang = '{{page.locale}}';
    // Redirect if we support the desired locale
    const supportedLocales = ['fr', 'nl-NL'];
    if (supportedLocales.includes(userLang) && !window.location.pathname.startsWith(`/${userLang}`)) {
        window.location.href = `/${userLang}${window.location.pathname}`;
    }
</script>
```

### SsrRequestContext

The `SsrRequestContext` object also contains the `locale` property.

When a component is server-side rendered (SSRed), LWR-JS calls the [`getServerData()`](https://developer.salesforce.com/docs/platform/lwr/guide/lwr-enable-ssr-site.md#load-data-during-ssr) hook. This function returns public properties to the component.

```
export async function getServerData(context: SsrRequestContext): Promise<SsrDataResponse> {
    // This is called to fetch data when the component is SSRed
    const topic = context.params.topic;
    const locale = context.locale;
    const response = await fetch(
        `https://www.googleapis.com/books/v1/volumes?q=subject:${topic}&langRestrict=${locale}`,
    );
    const data = await response.json();
    return { props: { data, ...context.params } };
}
```

### lwr/environment

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:

```
import { locale } from 'lwr/environment';
```

<!-- https://github.com/salesforce-experience-platform-emu/lwr-recipes/blob/d9d09529e2346a07cb18877a73db9f0d4f9900e9/packages/internationalization/README.md -->
