5. I18N project settings

In the previous chapter, we talked about deployment and completed the core project skeleton. So in this chapter we will talk about 18n directly. Very few people talk about 18n directly in the previous part, but I mentioned the order of 18n in the previous order mainly for the following considerations:

1. Double the number of page indexes for the project and add exposure from small languages. 2. If you do this at the beginning, don’t worry about the subsequent content coverage of I18N, which will make this transformation project particularly large in the later stage. 3. The entire minimalist AI project pursues the fastest way to generate a closed-loop project, and the configured JSON structure that comes with I18N uses Key to fill in the content, which is more suitable for AI to fill in.

I18N basic settings

Then let’s start building the basics of our project I18N. The version in this section is github tag v2.01. The basic parts are based on the documentation, so I won’t go into too much detail.

Basic project configuration

Depends on the download and directory configuration document (https://next-intl.dev/docs/getting-started/app-router/with-i18n-routing). Its main function is to configure the i18n layout/page, jump, routing middleware, and translation file of the project.

app/[locale]/about/page.tsx is the usage of the client component, and app/[locale]/page.tsx is the usage of the server route.

Ts and Eslint settings

Project's Typescript documentation, Project's Eslint documentation. The main function is that the Ts syntax hints and Eslint restrictions used for the project must be overridden. The effect is as follows:

Eslint error

Ts grammar tips

I18N routing and detection

The version of this section is github tag v2.02.

Process routing prefix

In intl, the default prefix mode is Always, but this behavior is not in line with SEO practice. It is necessary to remove the routing suffix in the en language (the default language), while retaining the routing suffixes in other languages.

In next-intl, localePrefix has several options:

- always: always show language prefix - never: never show language prefix - as-needed: only show prefixes for non-default languages

Change localePrefix from always to as-needed so that the default language en does not show up in URLs, while other languages such as zh retain the prefix.

import { defineRouting } from 'next-intl/routing'

export const routing = defineRouting({
  locales: ['en', 'zh'],
  defaultLocale: 'en',
  localePrefix: 'as-needed'
})
```

After this modification, the URL of the English page will be `/about`, and the URL of the Chinese page will be `/zh/about`.

### Route detection mechanism

Next-intl has its own detection mechanism that can automatically determine the user's preferred language based on a variety of factors. By default, languages are detected in the following order of priority:

1. Language prefix in URL path (e.g. `/zh/about`)
2. Previously detected language preferences saved in cookies
3. Browser’s `accept-language` request header
4. If none of the above can be matched, the default language set by `defaultLocale` is used.

When users first visit the website, they will automatically jump to the corresponding language version based on the browser language, and their language preference will be remembered on subsequent visits.

#### Workflow example

1. The user requests the `/` path, and the system matches the `en` language based on the `accept-language` header.
2. The user is redirected to `/` (because we set `localePrefix: 'as-needed'` and `en` is the default language)
3. Application rendering `<Link locale="zh" href="/">Switch to Chinese</Link>` allows users to switch to Chinese
4. After the user clicks the link, he initiates a request for `/zh`
5. The middleware will add a cookie to remember the user’s preference for Chinese
6. If the user requests