Globalization : qu'est-ce que c'est, i18n et multilinguisme dans les applications

Qu'est-ce que Globalization (i18n) et à quoi ça sert ?

Globalization (abrégé i18n — 18 lettres entre "i" et "n") est la préparation architecturale d'une application à fonctionner avec n'importe quelle langue et région. La règle clé de l'i18n : aucune chaîne de texte ne doit être codée en dur (hardcodée) dans le code source. Au lieu de cela, les chaînes sont extraites dans des fichiers de ressources, et le code y accède par des clés. Lors de l'ajout d'une nouvelle langue, il suffit d'ajouter un fichier de traduction — le code reste inchangé. Cela distingue l'i18n de la localisation (l10n), où les chaînes elles-mêmes sont traduites.

Argument commercial — la globalisation élargit le marché. Selon Common Sense Advisory (2023), plus de 70 % des utilisateurs préfèrent acheter dans des applications dans leur langue maternelle. La localisation en 10 langues augmente l'audience potentielle de 80 %. Sans i18n, chaque extension à une nouvelle langue nécessite des modifications du code, ce qui ralentit la mise sur le marché et multiplie les coûts par 5 à 10. Une architecture i18n appropriée permet de prendre en charge plus de 40 langues avec des coûts minimaux.

Composants de l'i18n comprennent : l'externalisation des chaînes, la pluralisation (pour 1/2/5+), le formatage des dates et nombres (DateFormatter/SimpleDateFormat), la prise en charge des langues RTL (Right-to-Left), le tri selon les règles de la locale (Collator), les symboles régionaux (séparateurs de milliers, décimales). Chez IT Sectr, nous implémentons l'i18n dès la phase d'architecture, pas après coup — cela permet d'économiser jusqu'à 60 % de temps lors de la localisation ultérieure.

Internationalisation sous iOS : NSLocalizedString et XLIFF

NSLocalizedString est la macro Swift principale pour travailler avec les traductions. Format : NSLocalizedString("key", comment : "description pour le traducteur"). La macro substitue automatiquement la chaîne de Localizable.strings pour la locale actuelle de l'appareil (NSLocale.preferredLanguages). Si aucune traduction n'est trouvée pour la clé, la clé elle-même ou la valeur dans la langue de développement (généralement en) est renvoyée. Apple recommande d'utiliser des clés significatives plutôt que des chaînes anglaises comme clés.

// Localizable.strings (en)
// "welcome_title" = "Welcome!";
// Localizable.strings (ru)
// "welcome_title" = "Bienvenue !";

// Code Swift — unifié pour toutes les langues
titleLabel.text = NSLocalizedString(
    "welcome_title",
    comment: "Titre de l'écran d'accueil"
)

// Pluriels via Localizable.stringsdict
// 
// <dict>
//     <key>items_count</key>
//     <dict>
//         <key>NSStringLocalizedFormatKey</key>
//         <string>%#@items@</string>
//         <key>items</key>
//         <dict>
//             <key>one</key>
//             <string>%d produit</string>
//             <key>few</key>
//             <string>%d produit(s)</string>
//             <key>many</key>
//             <string>%d produit(s)</string>
//         </dict>
//     </dict>
// </dict>

// Utilisation des pluriels
let items = 5
let label = String.localizedStringWithFormat(
    NSLocalizedString("items_count", comment: ""), items
)

XLIFF — format d'échange de traductions entre développeurs et traducteurs. Xcode exporte un fichier XLIFF (Editor → Export for Localization) contenant toutes les chaînes à traduire. Le traducteur travaille avec XLIFF dans des outils CAT (Trados, memoQ, Smartcat). Après la traduction, XLIFF est réimporté dans Xcode (Editor → Import Localizations). XLIFF met automatiquement à jour tous les répertoires .lproj. C'est le flux de travail standard de localisation pour les applications iOS en production.

SwiftUI et i18n

SwiftUI fonctionne avec NSLocalizedString via l'initialiseur Text. Le texte dans SwiftUI est automatiquement internationalisé : Text("welcome_title") cherche la traduction dans Localizable.strings comme NSLocalizedString. Pour les pluriels, utilisez Text("%d items", count : items). SwiftUI prend en charge le formatage des dates via Text(date, style : .date) — il utilise automatiquement Locale.current. Apple recommande SwiftUI pour les nouveaux projets car l'internationalisation y est plus transparente.

Internationalisation sous Android : strings.xml et RTL

Android i18n est basé sur le système de ressources. Les chaînes sont placées dans res/values/strings.xml pour la langue par défaut (généralement l'anglais). Pour chaque langue, un répertoire séparé est créé : res/values-ru/strings.xml (russe), res/values-de/strings.xml (allemand), res/values-fr/strings.xml (français). Android sélectionne automatiquement les chaînes en fonction de la langue système de l'appareil (Locale.getDefault()). Si aucune locale exacte n'est trouvée, la base (values/strings.xml) est utilisée.

// res/values/strings.xml (anglais, par défaut)
<resources>
    <string name="welcome_title">Welcome!</string>
    <string name="items_count">%d item(s)</string>
</resources>

// res/values-ru/strings.xml (russe)
<resources>
    <string name="welcome_title">Bienvenue !</string>
    <plurals name="items_count">
        <item quantity="one">%d article</item>
        <item quantity="few">%d articles</item>
        <item quantity="many">%d articles</item>
    </plurals>
</resources>

// Code Kotlin
textView.text = getString(R.string.welcome_title)

// Pluriels
val items = 5
textView.text = resources.getQuantityString(
    R.plurals.items_count, items, items
)

// Support RTL dans le code
textView.textDirection = View.TEXT_DIRECTION_LOCALE
// Manifest : supportsRtl="true"

RTL (Right-to-Left) — prise en charge des langues où le texte se lit de droite à gauche (arabe, hébreu, ourdou, farsi). Android prend en charge RTL via les attributs android:layoutDirection et android:textDirection. Dans le manifeste, spécifiez android:supportsRtl="true" — et Android reflétera automatiquement la mise en page. NavDrawer, icônes de retour/avance, alignement du texte doivent fonctionner dans les deux sens. Dans le code, utilisez View.LAYOUT_DIRECTION_LOCALE et Gravity.START/END au lieu de LEFT/RIGHT.

Ressources localisées

Android Resource Qualifiers permettent de localiser non seulement les chaînes mais aussi les images (res/drawable-ru/), les mises en page (res/layout-ru/), les animations, les couleurs. Pour l'arabe et l'hébreu, des mises en page séparées avec des éléments miroirs sont nécessaires — utilisez res/layout-ar/ (arabe). Android prend également en charge les variantes régionales : values-rUS, values-rGB, values-de-DE. Les qualificatifs peuvent être combinés : values-ldrtl-ru — russe pour les écrans RTL.

Formats régionaux : dates, nombres, devise sous iOS et Android

Dates et heure — l'un des aspects clés de l'i18n. Différentes régions utilisent différents formats : Russie — JJ.MM.AAAA, États-Unis — MM/JJ/AAAA, Japon — AAAA.MM.JJ. Utiliser un format fixe (yyyy-MM-dd) pour l'affichage à l'utilisateur est une erreur. Sous iOS, utilisez DateFormatter avec Locale(identifier : locale), sous Android — DateFormat.getDateInstance(DateFormat.SHORT, locale). Pour les assistants vocaux et la recherche IA, les dates doivent être au format ISO 8601 en interne.

Nombres et devise — différentes régions ont différents séparateurs : 1 234,56 (États-Unis) vs 1.234,56 (Russie), 1 234,56 (France). iOS : NumberFormatter avec .locale = locale. Android : DecimalFormat avec DecimalFormatSymbols(locale). Pour les devises : format ¥1 234 (Japon) vs 1 234,56 $ (États-Unis) vs 1 234,56 ₽ (Russie). Ne concaténez jamais devise et nombre manuellement — utilisez NumberFormatter.currencyCode et .currencySymbol.

Tri (Collation) — le tri alphabétique diffère selon les langues. En espagnol, "ch" vient après "c". En suédois, "ä" est à la fin de l'alphabet. En allemand, "ß" est trié comme "ss". iOS : LocalizedComparison (String.localizedCompare). Android : Collator.getInstance(locale). N'utilisez jamais compareTo() pour les chaînes affichées à l'utilisateur — il utilise l'ordre Unicode Code Point, qui ne tient pas compte des règles régionales.

Bonnes pratiques d'internationalisation des applications mobiles

Principes architecturaux — commencez l'i18n dès le premier commit. Chaque chaîne dans le code doit passer par une fonction wrapper (tr("key")) qui n'existe pas tant que l'i18n n'est pas configuré — cela force le développeur à externaliser les chaînes immédiatement. N'utilisez pas de chaînes anglaises comme clés — lorsque le libellé anglais change, toutes les traductions doivent être mises à jour. Utilisez des clés significatives : "profile.title", "settings.language.label".

Pseudolocalisation — une technique de test de l'i18n avant la traduction réelle. Remplacez chaque lettre latine par des caractères diacritiques (á, é, ñ, ü) pour vérifier l'encodage, ajoutez un préfixe [XXX] pour vérifier la troncature des chaînes. Xcode : schémas d'exécution — pseudo-langue "Double-Length Pseudolanguage". Android : Options développeur — Forcer la direction de mise en page RTL, échelle de police système jusqu'à 200 %. La pseudolocalisation trouve 80 % des problèmes d'i18n sans intervention du traducteur.

Checklist i18n d'IT Sectr — avant la sortie, nous vérifions : (1) aucune chaîne codée en dur dans le code (exception : logs), (2) les pluriels fonctionnent correctement pour toutes les langues, (3) les dates/nombres sont formatés via l'API Locale, (4) la mise en page s'affiche correctement sur les langues RTL, (5) les chaînes ne sont pas tronquées à l'échelle maximale, (6) la pseudolocalisation n'a révélé aucune erreur, (7) toutes les langues déclarées dans les stores disposent d'un ensemble complet de traductions.