Internationalisation (i18n) : Avantages, meilleures pratiques et conseils de mise en œuvre

Qu'est-ce que l'i18n?

L'internationalisation (i18n) est le processus qui consiste à concevoir un logiciel de manière à ce qu'il puisse être adapté à différentes langues et régions sans modifier votre code. Le surnom « i18n » vient du fait qu'il y a 18 lettres entre le « i » et le « n » dans le internationalisation.

Considérez l'i18n comme un travail de fond :

• Emplacement (l10n) : La traduction et l'adaptation de votre contenu à un marché particulier.
• Mondialisation (g11n) : Coordination de la préparation des produits et des opérations sur l'ensemble des marchés.
  
  

En pratique, l'i18n consiste à s'assurer que votre application peut être gérée :

• Texte dans n'importe quelle langue
• Dates, heures, nombres et devises dans le bon format
• Règles de pluralisation adaptées à la grammaire locale
• Mise en page de droite à gauche (comme l'arabe ou l'hébreu)

Pourquoi i18n est important

Investir dans l'i18n dès le départ apporte des avantages tangibles à vos équipes d'ingénieurs et de produits :

• Réduction des coûts d'emplacement : L'extraction et le remplacement de chaînes de caractères sont plus faciles lorsque la logique de traduction est intégrée dès le départ.
• Développement plus rapide : Une infrastructure partagée pour la gestion des chaînes de caractères permet de réduire les travaux ultérieurs.
• Meilleure interface utilisateur : les utilisateurs voient le contenu dans leur langue, formaté de manière naturelle.
• Évolutivité : Les applications peuvent être lancées sur de nouveaux marchés avec moins de modifications du code.

Modèles de mise en œuvre de l'i18n dans les applications modernes

Vous trouverez ci-dessous quelques modèles courants de mise en œuvre de l'i18n dans les applications de production. Nous passerons en revue React (frontend), iOS et Android.

Quelle que soit la plateforme, les traductions proviennent généralement d'un système de gestion des traductions (TMS) tel que Smartling sous forme de fichiers JSON ou de fichiers de ressources. Ces fichiers sont ensuite chargés par votre application au moment de l'exécution par le biais d'un cadre i18n ou d'une API d'emplacement d'origine, ce qui garantit que les chaînes de caractères correctes sont affichées pour la langue ou le lieu de travail de l'utilisateur.

Frontend (React)

Les applications React modernes utilisent généralement une bibliothèque i18n dédiée. Deux des plus populaires sont i18next et FormatJS, qui sont tous deux agnostiques. Dans React, leurs implémentations respectives sont react-i18next (basé sur des fonctions et des crochets) et react-intl (basé sur des composants et des crochets, construit sur ICU MessageFormat). Les deux s'intègrent parfaitement aux flux de production d'entreprise et gèrent la pluralisation, les variables et le formatage local.

1. Réagir avec i18next + react-i18next

i18next est l'une des bibliothèques JavaScript i18n les plus populaires, et lorsqu'elle est associée aux bindings react-i18next, elle offre aux applications React une API puissante et conviviale pour le chargement et le rendu des traductions.

Dans l'exemple ci-dessous, nous allons étudier un modèle d'interface homme-machine commun aux entreprises. Nous allons définir des fichiers de traduction, initialiser i18next au point d'entrée de l'application, puis rendre les traductions dans les composants. Cette approche est compatible avec tous les cadres, s'intègre parfaitement à la plupart des systèmes de gestion des traductions (TMS) et s'adapte parfaitement à la croissance de votre application, que vous affichiez des chaînes de caractères statiques ou des messages dynamiques à variables, comme des décomptes.

Exemple de modèle i18n : i18next + reacti18next

Vous recevrez probablement le contenu sous forme de fichiers JSON de votre système de gestion de la traduction. L'exemple de fichier JSON ci-dessous montre comment les traductions sont conservées pour l'anglais. Chaque entrée a une clé unique et les formes plurielles sont définies séparément afin que la bibliothèque puisse choisir la bonne forme en fonction du nombre que vous transmettez. Votre TMS génère un fichier correspondant pour chaque langue prise en charge.

{

  "welcome": "Welcome",

  "visits_one": "Vous avez visité {{count}} fois.",

  "visits_other": "Vous avez visité {{count}} fois."

}

Vous verrez ensuite un exemple de configuration d'i18next pour qu'il sache quelles langues sont prises en charge par votre application, où trouver les traductions et ce qu'il faut faire si une traduction est manquante. Ce fichier d'installation est exécuté une fois au démarrage de votre application (souvent dans le fichier d'entrée comme index.js ou main.tsx). afin que les traductions soient prêtes avant le rendu de l'interface utilisateur. La centralisation de la configuration en un seul endroit permet de conserver une logique d'emplacement cohérent dans l'ensemble de l'application.

import i18next from 'i18next';

import { initReactI18next } from 'react-i18next';

import en from './locales/en/translation.json';

import fr from './locales/fr/translation.json';

const locale = 'fr'; // en production, résolution dynamique

i18next

  .use(initReactI18next)

  .init({

    lng: locale,

    fallbackLng: 'en',

    ressources : {

      en: { translation: en },

      fr : { translation : fr }

    },

    interpolation : { escapeValue : false }

  });

export default i18next;

Une fois i18next initialisé, vous pouvez l'utiliser n'importe où dans votre application. Dans l'exemple ci-dessous, le crochet useTranslation récupère la fonction t, qui prend une clé et des variables optionnelles pour rendre la bonne chaîne. Lorsque vous passez count comme variable, i18next sélectionne automatiquement le pluriel correct en fonction du fichier de traduction.

import { useTranslation } from 'react-i18next';

import './i18n';

export default function App() {

  const { t } = useTranslation();

  const count = 3;

  retourner (

    <>

      <h1>{t('welcome')}</h1>

      <p>{t('visits', { count })}</p>

    </>

  );

}

2. React avec FOrmatJS + react-intl

react-intl fait partie de l'écosystème FormatJS et fournit une approche basée sur des composants pour l'i18n dans React. Il s'appuie sur la norme ICU MessageFormat, ce qui vous permet de bénéficier d'une pluralisation intégrée, d'un formatage de la date et du nombre, et d'une adaptation des paramètres locaux.

Dans l'exemple ci-dessous, nous allons mettre en place des fichiers de traduction, intégrer l'application dans un IntlProvider et rendre le texte retrouvé à l'aide de FormattedMessage. Cette approche est bien adaptée aux équipes qui souhaitent un style déclaratif et axé sur les composants pour gérer l'i18n dans React.

Exemple de modèle i18n : FormatJS + react-intl

Le fichier JSON ci-dessous contient des traductions utilisant la syntaxe ICU MessageFormat, qui place la logique plurielle à l'intérieur de la chaîne elle-même. Toutes les règles linguistiques sont ainsi combinées en un seul endroit, ce qui permet aux traducteurs de contrôler entièrement la grammaire sans l'intervention d'un concepteur. Votre TMS gère ces fichiers par région.

{

  "welcome": "Welcome",

Vous verrez ensuite un exemple d'intégration de votre application dans le composant IntlProvider. Il s'agit d'une configuration unique, généralement effectuée dans un composant racine comme Root.tsx ou index.jsx. Il rend la locale active et ses messages disponibles dans l'ensemble de votre application, de sorte que n'importe quel composant puisse les utiliser sans importations supplémentaires.

import { IntlProvider } from 'react-intl';

import en from './locales/en.json';

import fr from './locales/fr.json';

const MESSAGES = { en, fr };

const locale = 'fr';

export default function Root() {

  retourner (

    <IntlProvider locale={locale} messages={MESSAGES[locale]}>

      <App />

    </IntlProvider>

  );

}

Enfin, lisez ci-dessous comment le composant FormattedMessage recherche une traduction par son ID et gère automatiquement la pluralisation. Tout ce que vous devez transmettre est le nombre, et la bibliothèque applique les règles linguistiques correctes à partir de votre fichier JSON.

import { FormattedMessage } from 'react-intl';

export default function App() {

  const count = 3;

  retourner (

    <>

      <h1><FormattedMessage id="welcome" defaultMessage="Welcome" /></h1>

      <p><FormattedMessage id="visits" values={{ count }} /></p>

    </>

  );

}

Quelques conseils supplémentaires pour la production :

• Locale source : Dans les applications réelles, déterminez la locale de manière centralisée (par exemple, à partir d'une URL comme /fr/*, du profil de l'utilisateur ou d'un paramètre fourni par le serveur) et transmettez-la à <IntlProvider>.
• Organisation des messages : Pour l'échelle, divisez les fichiers de messages par domaine ou par fonction (par exemple, auth.json, dashboard.json) et les fusionner pour la locale active.
• Retours : defaultMessage est votre filet de sécurité pendant le déploiement - gardez-le dans votre langue source.
• Chargement asynchrone (facultatif) : Pour les gros paquets, importer dynamiquement les fichiers de messages par locale (code-split) avant le rendu <IntlProvider>.

iOS

iOS vous offre d'emblée de solides outils d'emplacement, mais l'extension à de nombreuses localités nécessite une mise en œuvre réfléchie des meilleures pratiques en matière d'i18n. Sinon, sans une structure claire, vous risquez de vous retrouver avec des clés dupliquées, un formatage incohérent et des fichiers de traduction dont l'entretien devient un casse-tête. L'essentiel est de prendre quelques décisions structurelles dès le début afin que votre emplacement reste organisée et facile à étendre au fur et à mesure de l'ajout de nouveaux marchés.

Conseil 1 : Organiser les ressources de manière à ce qu'elles soient évolutives

Un bon point de départ est le catalogue de chaînes (.xcstrings) dans Xcode 15 et les versions ultérieures, ou les fichiers .strings/.stringsdict .si vous avez une configuration plus ancienne. Ils fonctionnent bien avec un TMS, qui vous enverra généralement des traductions au format XLIFF. Vous pouvez les importer directement dans votre catalogue et le système se chargera de les fusionner et de les gérer.

Il vous sera probablement plus facile de garder les choses en ordre si vous organisez les catalogues par fonction ou par module. Des fichiers plus petits et plus ciblés facilitent la recherche des clés, la révision des modifications et la transmission du travail aux traducteurs. Voici un exemple de la manière dont vous pourriez les organiser :

Ressources

  i18n/

    Auth.xcstrings

    Checkout.xcstrings

    Profil.xcstrings

Conseil 2 : traitez la pluralisation dans le catalogue, pas dans le code

La pluralisation est un autre domaine où la structure est payante. Il est préférable de définir toutes les règles de pluriel dans le catalogue plutôt que dans Swift, afin que votre code ne passe que des variables et que la bonne phrase soit choisie automatiquement pour chaque langue. Voici à quoi cela pourrait ressembler dans le catalogue :

Clé : unread_messages

Format : Pluriel

Un : "% d message non lu"

Autre : "% d messages non lus"

Voici comment vous pouvez l'utiliser en Swift :

let unreadCount = 3

let format = String(localized : "unread_messages")

let message = String.localizedStringWithFormat(format, unreadCount)

// "3 messages non lus"

De cette manière, vous ne codifiez pas la grammaire en dur dans le code, et les traducteurs peuvent adapter les détails à chaque langue.

Conseil n° 3 : centraliser le formatage des nombres, des dates et des devises

Vous voudrez également centraliser le formatage des nombres, des dates et des devises pour que chaque partie de l'application soit cohérente. Un service public ou un service partagé peut y contribuer. Voici un exemple simple utilisant l'API FormatStyle de Swift :

laissez le prix = 19.99

let display = price.formatted(.currency(code : "EUR"))

// "€19.99" ou "19,99 €" en fonction de la localisation

En organisant vos ressources de chaînes de caractères, en gérant la pluralisation dans le catalogue et en centralisant toutes les mises en forme tenant compte des paramètres locaux, vous préparez votre application iOS à évoluer sans créer de travail d'entretien supplémentaire. Une fois ces pratiques mises en place, le processus d'ajout de nouvelles langues devient beaucoup plus prévisible et beaucoup moins stressant. Passons maintenant à Android, qui offre ses propres outils d'emplacement intégrés.

Android

Le système de ressources d'Android est déjà conçu pour l'emplacement, mais son entretien dans de nombreuses langues nécessite une certaine planification. Si vous conservez tout dans un grand fichier ou si vous dispersez les règles de grammaire dans le code, vous risquez de vous retrouver rapidement dans le désordre. Au lieu de cela, donnez la priorité à l'organisation segmentée des fichiers, définissez toutes les règles de grammaire en XML et assurez-vous que votre formatage et vos mises en page fonctionnent pour tous les systèmes d'écriture que vous prévoyez de prendre en charge.

Conseil 1 : Organisez les ressources par caractéristiques

Pour la plupart des équipes, les traductions proviennent d'un TMS sous forme de fichiers XLIFF. Vous les importez dans les répertoires res/values pour chaque locale, et Android se charge de faire correspondre les bonnes chaînes à la langue de l'utilisateur.

Diviser vos ressources en fichiers distincts par caractéristique est un moyen simple de vous faciliter la vie. Des fichiers plus petits permettent de réviser plus rapidement les modifications et d'éviter les conflits de fusion.

app/src/main/res/

  values/strings_auth.xml

  values/strings_checkout.xml

  values/plurals_checkout.xml

Conseil n° 2 : définissez les règles de grammaire dans les ressources, et non dans le code

Comme dans iOS, la pluralisation est l'une des choses qu'il vaut mieux gérer dans les ressources pour que les traducteurs puissent l'adapter à chaque langue sans que vous ayez à modifier le code. Voici un exemple de ressource plurielle en anglais :

<plurals name="checkout_cart_items_count">

    <item quantity="one">%1$d item</item>

    <item quantity="other"> % 1$d items</item>

</plurals>

Et voici comment vous pouvez l'utiliser en Kotlin :

val msg = resources.getQuantityString(

    R.plurals.checkout_cart_items_count, compter, compter

)

De cette manière, notre code reste propre et Android choisit automatiquement le bon formulaire en fonction de la langue.

Conseil n° 3 : utilisez un formatage adapté aux spécificités locales 

Pour les mises en page, il est conseillé d'utiliser le début et la fin plutôt que la gauche et la droite afin de s'adapter aux langues qui vont de droite à gauche, comme l'arabe ou l'hébreu :

<LinearLayout

    android:paddingStart="16dp"

    android:paddingEnd="16dp"

    android:layout_width="match_parent"

    android:layout_height="wrap_content">

</LinearLayout>

Et lorsque vous mettez en forme des nombres ou des devises, indiquez les paramètres régionaux de l'application pour que tout soit cohérent :

val appLocale = LocaleListCompat.getAdjustedDefault()[0] ?: Locale.getDefault()

val price = NumberFormat.getCurrencyInstance(appLocale).format(1234.56)

// "$1,234.56" ou "1 234,56 €"

En fin de compte, pour obtenir un bon i18n sur Android, il faut surtout laisser la plateforme faire le gros du travail. En conservant tout le texte dans des ressources, en structurant ces ressources avec des dossiers particuliers à la langue locale et en intégrant le RTL et le formatage adapté à la langue locale dès le premier jour, vous évitez les pièges les plus courants qui fragilisent l'emplacement. Nombre de ces principes font écho aux meilleures pratiques d'iOS, mais le système de qualification des ressources d'Android signifie que vous pouvez souvent prendre en charge de nouvelles langues en ajoutant simplement les bons fichiers. Si elle est bien menée, l'extension à de nouveaux sites Web devient un processus prévisible et peu contraignant.

Les pièges communs de l'i18n

Malheureusement, même les systèmes bien conçus rencontrent parfois des problèmes évitables. Le tableau ci-dessous présente quelques-uns des faillis pas les plus courants, les raisons de ces problèmes et les moyens de les éviter. Il s'agit d'une référence rapide que vous pouvez utiliser pour vérifier votre propre installation avant l'expédition.

Préparer l'emplacement à grande échelle

Une fois que votre application est prête pour l'internationalisation, l'étape suivante consiste à rendre l'emplacement aussi efficace et facile à gérer que possible. Quelques outils d'automatisation et flux de travail peuvent vous faire passer de "nous pouvons traduire" à "nous pouvons déployer de nouvelles langues rapidement, sans charge de développement supplémentaire". Considérez :

• Utiliser un système de gestion de la traduction (TMS) doté d'une API d'entreprise, comme Smartling, pour synchroniser les fichiers de traduction et gérer les flux de travail de révision.
• Automatiser l'extraction et la livraison des chaînes de caractères à l'aide de votre flux de production CI/CD.
• L'utilisation d'outils d'IA (comme le Smartling's AI Hub) pour des traductions rapides de premier passage avec des contrôles de qualité intégrés tels que la gestion de la déviation et l'atténuation des hallucinations.

Dernières réflexions

L'internationalisation est une pratique fondamentale pour tout produit destiné à être commercialisé à l'échelle mondiale. Plus vous la mettez en œuvre tôt, moins vous aurez de maux de tête par la suite. Combinez de solides pratiques i18n avec l'automatisation de la traduction et des flux de travail d'essai, et votre équipe sera bien équipée pour livrer des logiciels prêts pour l'international plus rapidement et avec plus de confiance.

Souhaitez-vous approfondir vos connaissances? Consultez le site Web de Smartling Séminaire Web de la conférence Global Ready sur i18n à l'ère de l'IA.