Motivation Recently, we migrated our sub-project from to . During that migration, the main goal was to keep the previous behavior of setting and changing language in our app. react-localization i18next Storing language in a route path is a commonly used practice for the Nextjs framework. But for our project, that was an inappropriate solution. Our main application allows businesses to generate QR codes for their customers with a link to the sub-application where the end user can leave feedback regarding service quality and satisfaction. All QR codes had already been printed, and new ones would cost a fortune for the business. The previous version of the sub-app used to be built on the base of CRA, and only half a year ago, it was migrated to Nextjs. So, we were looking for library or libraries which could provide us with non-route-based internationalization and API similar to . We found . This is a library specifically designed for use with Nextjs. provides a simple and flexible way to add i18n functionality to Nextjs projects, including support for server-side rendering and other advanced features. react-i8next ni18n ni18n Basic Setup Let’s install all necessary dependencies to start working on our project. npm install i18next react-i18next ni18n The next step is to expand the existing with the default i18n config. next.config.js Basically, we need only a few fields for a quick start. is required to show all the locales we want to support in the app, and will be used when visiting a non-locale prefixed path (for us, it’s just the default language). locales defaultLocale // next.config.js
module.exports = {
	...yourNextConfig,
  i18n: {
    defaultLocale: 'GB',
    locales: ['GB', 'UA', 'PT'],
  },
}; Then we are required to create a new file in the root or utils/plugins/etc. directory named . - names which show us supported languages, and - namespaces, which we can use in some cases. ni18n.config.js supportedLngs ns // ni18n.config.js
export const ni18nConfig = {
  supportedLngs: ['GB', 'UA', 'PT'],
  ns: ['namespace-name'],
}; A few more things left. Our application requires , so let’s wrap the with the high-order component imported from . I18nextProvider App i18n It will initialize the instance and provide it as a context for all the children. i18next // pages/_app.jsx
import { appWithI18Next } from 'ni18n';
import { ni18nConfig } from '../ni18n.config';

const App = ({ Component, pageProps }) => <Component {...pageProps} />;

export default appWithI18Next(App, ni18nConfig); And the last preparation step before we started using translation into our components is a filling of translation files. The important thing - keep the following file structure. ./public
└── locales
    ├── GB
    │   ├── namespace-name.json  // { "key1": "Test" }
    │
    ├── UA
    │   ├── namespace-name.json  // { "key1": "Тест" }
    │
    ├── PT
		├── namespace-name.json  // { "key1": "Teste" } Finally, we’ve done with the setup and are ready to start integration of the i18n feature into components. Let’s take a look at the example in . ComponentName.jsx We extract the function from hook which will return translated string for the selected language. Looks simple, doesn’t it? t useTranslation // ComponentName.jsx
import { useTranslation } from 'react-i18next';

export const MyComponent = () => {
  const { t } = useTranslation();
  return (
		<div>{t('key1')}</div>
	);
}; If you store user language in DB, don’t forget to create a context with or any other solution to wrap pages and set the language in . Below, I’ll show you a simple snippet of how it could be implemented. React.Context useEffect // ContextName.jsx
const I18nProvider = ({ children, data }) => {
    const { i18n } = useTranslation();

    const { language = 'GB' } = data;

    useEffect(() => {
        i18n.changeLanguage(language);
    }, [language]);

    return (
        <I18nContext.Provider>
            {children}
        </I18nContext.Provider>
    );
}; That’s it. I hope it helped you to save some time, as always. In the future, we are going to migrate the existing i18n approach to route based. The reason is pretty simple - a unification of all our applications. I’ll definitely describe it in one of my next articles.

Implementing i18n in Next.js: A Guide to Non-Route-Based Localization

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Building Embeddable Widgets with TypeScript

10 Ways To Make Your Innovative, Game-Changing, Synergistic Website Stand Out In 2018

10 Use Cases for Using Laravel to Build Web App Development Projects

10 Things You Can Do Better While Working With Programmers

10 Prioritization Techniques for Agile Product Development

10 Popular Websites Built With Django

Building Embeddable Widgets with TypeScript

10 Ways To Make Your Innovative, Game-Changing, Synergistic Website Stand Out In 2018

10 Use Cases for Using Laravel to Build Web App Development Projects

10 Things You Can Do Better While Working With Programmers

10 Prioritization Techniques for Agile Product Development

10 Popular Websites Built With Django

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps