i18n-js VS i18next

I'm using expo-localization, which uses i18n-js to localise my app fully except for the app name.

The origin of this format start Ruby. The i18n-js format is a direct export of translations defined by Ruby on Rails. To export the translations, a Ruby gem can be used, that's completely disconnected from Rails and that can be used for the solely purpose of exporting the translations, even if your project is written in a different language. For JavaScript there's a companion JavaScript package. It comes bundled with all base translations made available by rails-i18n. Base translations allow formatting date, numbers, and sentence connectors, among other things.

In most packages (i18next, i18n-js), the approach used to access translations is as follows:

I was working on an app built with React on Rails. Most of the pages were written in React, but some pages were written in and rendered from the Rails views. This meant that I needed to figure out a way to provide translations on both the backend and the frontend. I searched for articles and tutorials, but I couldn’t find one that was solving the same problem I had. I found a lot of tutorials on “i18n-ing” Rails apps, and some on Rails and Javascript, but not on Rails and React. After spending some time researching, I decided to try rails-i18n and i18n-js gems.

When starting a new project with Next.js these days, next-intl and zod are my go to libraries for internationalization and schema validation, respectively. Of course, when using zod for client-facing validations I would like to translate potential error messages. The package zod-i18n can be used to achieve this for i18next, a popular alternative internationalization library. This means that by using this library as starting point one can quickly achieve zod translation with next-intl.

The best way to implement internationalization is to use an internationalization framework library, such as i18next. With this kind of library, you can easily handle translations and automatically display your frontend labels in the user's language. The frontend application also needs to be flexible and easily configurable so that its layout can change accordingly, reading from left to right or right to left. CSS allows this with the rtl and ltr CSS direction property.

For reference, I am using i18next for providing translations, which is configured to use the english message string as a key for the translations and fallback to it if no translation is found in the chosen language. I also use the official svelte-i18next integration. It wraps the i18next object in a Svelte store and, among other things, provides reactivity when the language is changed.

// app/components/BuiltInFormatsDemo.tsx 'use client'; import React from 'react'; import {useTranslation} from '../i18n/client'; import type {LocaleTypes} from '../i18n/settings'; import {useParams} from 'next/navigation'; const BuiltInFormatsDemo = () => { let locale = useParams()?.locale as LocaleTypes; const {t} = useTranslation(locale, 'built-in-demo'); return (

{/* "number": "Number: {{val, number}}", */} {t('number', { val: 123456789.0123, })} p>

{/* "currency": "Currency: {{val, currency}}", */} {t('currency', { val: 123456789.0123, style: 'currency', currency: 'USD', })} p>

{/* "dateTime": "Date/Time: {{val, datetime}}", */} {t('dateTime', { val: new Date(1234567890123), formatParams: { val: { weekday: 'long', year: 'numeric', month: 'long', day: 'numeric', }, }, })} p>

{/* "relativeTime": "Relative Time: {{val, relativetime}}", */} {t('relativeTime', { val: 12, style: 'long', })} p>

{/* "list": "List: {{val, list}}", */} {t('list', { // https://www.i18next.com/translation-function/objects-and-arrays#objects // Check the link for more details on `returnObjects` val: t('weekdays', {returnObjects: true}), })} p> div> ); }; export default BuiltInFormatsDemo;

As our world becomes increasingly interconnected, the development of web applications that cater to a global audience takes precedence among developers. If you're a TypeScript developer, you're likely acquainted with the advantages of static typing and the assurance it provides in your codebase. When it comes to internationalization (i18n) and localization (l10n), maintaining the same level of type safety becomes crucial. This is precisely where i18next, an influential i18n framework, enters the picture.

check i18next

In this article, we will go over how to perform internationalisation in our react app using the i18next framework. I18next is an internationalisation framework written in JavaScript. It comes with everything you need to localise your web, desktop or mobile product such as user language detection, loading and caching translations, and file conversion etc More features can be found in their documentation. (https://www.i18next.com/)

Luckily this is a well-solved problem: https://www.i18next.com/

I am so sorry for all the people using https://www.i18next.com/ and manually defining string ids. Fuck that. I will never write another message id in my life.

Internationalization (i18n) and localization (l10n) are crucial for businesses that want to expand globally and reach a wider audience. To do this, you need a robust solution that can handle different languages and cultural nuances, and this is where i18next and locize come in. These two elements have been designed to help you get the most out of your i18n efforts, and when used together, they are a powerhouse combination that can help you achieve your goals faster and more efficiently. In this video, we'll explore the fastest way to unleash the full power of i18next.