Internationalisation des applications TypeScript : guide complet avec exemples

Comment arrêter d’avoir peur et commencer à localiser : internationalisation des applications TypeScript

Vous êtes-vous déjà demandé pourquoi certains projets atteignent un niveau international tandis que d’autres restent des « startups russophones » ? Le plus souvent, la réponse est simple : la localisation. Oui, cette abréviation effrayante i18n qui donne à de nombreux développeurs un tic nerveux. Mais soyons honnêtes : rendre une application TypeScript internationalisée n’est pas sorcier. Ce n’est qu’un ensemble de bonnes approches et d’outils. Aujourd’hui, nous allons détailler cela en pratique, avec des exemples de code vivants, sans bla-bla ni théories abstruses.

Pourquoi TypeScript est-il un candidat idéal pour l’i18n ?

TypeScript nous donne ce qui manque au JavaScript simple : le typage statique. Quand il s’agit de traductions, cela devient un superpouvoir. Imaginez : vous changez une clé de traduction, et TypeScript crie avant même que l’application ne s’exécute : « Hé, tu as oublié de mettre à jour la traduction dans la locale espagnole ! ». D’accord, c’est mieux que de corriger des bugs en production.

De plus, les bibliothèques modernes pour l’i18n en TypeScript vous permettent de générer des types directement à partir des fichiers de traduction. Cela signifie que la complétion automatique dans l’EDI fonctionnera comme sur des roulettes. Pas de chaînes magiques, pas de fautes de frappe. Seulement du code propre et sûr.

Choisir une bibliothèque : i18next vs react-intl

Il y a deux acteurs principaux sur le marché : i18next et react-intl (faisant partie de FormatJS). Les deux fonctionnent très bien avec TypeScript, mais leurs approches diffèrent.

• i18next — le couteau suisse de l’internationalisation. Prend en charge la pluralisation, l’interpolation, les contextes, le chargement paresseux. Idéal pour les grands projets.
• react-intl — plus léger, adapté à React. Utilise une approche basée sur les composants (<FormattedMessage>) et un puissant système ICU MessageFormat.

Dans cet article, nous utiliserons i18next avec l’adaptateur React officiel react-i18next. Pourquoi ? Parce que c’est la pile la plus populaire et qu’elle vous donne un contrôle maximal.

Configuration étape par étape : du zéro à la première traduction

Allons droit au but. Installez les dépendances :

npm install i18next react-i18next i18next-browser-languagedetector

Créons maintenant un fichier de configuration. C’est le cœur de l’internationalisation de notre application TypeScript.

// i18n.tsimport i18n from 'i18next';import { initReactI18next } from 'react-i18next';import LanguageDetector from 'i18next-browser-languagedetector';

import enTranslation from './locales/en/translation.json';import ruTranslation from './locales/ru/translation.json';

i18n  .use(LanguageDetector) // détection automatique de la langue du navigateur  .use(initReactI18next) // intégration avec React  .init({    resources: {      en: { translation: enTranslation },      ru: { translation: ruTranslation },    },    fallbackLng: 'en', // si la traduction n'est pas trouvée    interpolation: {      escapeValue: false, // React échappe déjà    },  });

export default i18n;

Remarquez le fallbackLng. C’est d’une importance cruciale pour l’expérience utilisateur : si un utilisateur arrive avec un navigateur réglé sur le swahili, nous lui montrerons la version anglaise, pas un écran vide.

Structure des fichiers de traduction

Créons un dossier locales et, à l’intérieur, des sous-dossiers pour chaque langue. Voici un exemple du fichier en/translation.json :

{  "welcome": "Welcome to our application!",  "description": "This is a {{framework}} app with i18n support.",  "items": {    "zero": "No items",    "one": "One item",    "other": "{{count}} items"  }}

Et voici sa contrepartie russe :

{  "welcome": "Добро пожаловать в наше приложение!",  "description": "Это приложение на {{framework}} с поддержкой i18n.",  "items": {    "zero": "Нет элементов",