Comprendre la localisation et l'internationalisation

L'internationalisation (i18n) est le processus de conception de votre application afin qu'elle puisse être adaptée à différentes langues et régions sans changement d'ingénierie. La localisation (l10n) est la traduction et l'adaptation culturelle réelles du contenu de l'application et de l'interface utilisateur pour une localité spécifique. Les cadres Apple , qui gèrent une grande partie de la lourde charge, mais une stratégie bien pensée au début, permet d'économiser des efforts importants plus tard.

Apple fournit des outils complets en Xcode, Fondation et UIKit pour soutenir la localisation. L'objectif est de rendre votre application native dans chaque langue, en respectant la direction de lecture, les formats de date, le formatage des numéros et les conventions culturelles. Cet article passe par les étapes pratiques pour mettre en œuvre un support multi-langue robuste, de la configuration du projet aux techniques avancées.

Activer la localisation dans votre projet Xcode

La première étape consiste à indiquer à Xcode les langues que votre application prendra en charge. Ouvrez les paramètres de votre projet, sélectionnez votre projet dans le Navigateur de projet, et sous l'onglet Info, trouvez la section Localisations. Cliquez sur le bouton - -+- pour ajouter des langues. Pour chaque langue, Xcode crée automatiquement des fichiers ressources (storyboards, XIBs, chaînes de caractères) que vous pouvez modifier séparément.

Internationalisation de base

Apple recommande d'utiliser Base Internationalization. Dans votre onglet Info projet, cochez -Use Base Internationalization. Ceci stocke la mise en page originale de l'interface utilisateur dans une localisation de base (généralement en anglais) et chaque langue supplémentaire ne dépasse que les chaînes, et non la mise en page. Cela réduit la duplication et assure la cohérence de la mise en page. Si vous la décochez, vous devez dupliquer le storyboard entier pour chaque langue, qui est sujette aux erreurs.

Ajout de localisations aux fichiers existants

Pour les storyboards existants ou XIBs, sélectionnez le fichier dans l'inspecteur de fichiers, puis sous Localisation, vérifiez les langues que vous voulez localiser. Xcode génère des fichiers .strings spécifiques à la langue pour les storyboards. Pour les interfaces basées sur le code, vous aurez recours à et à des fichiers .strings séparés.

Création et gestion de fichiers de chaînes de données locales

La principale façon de traduire du texte à partir de code est de créer un fichier en allant dans Fichier > Nouveau > Fichier > Fichier de chaînes (sous Ressource). Nommez-le . Puis dans l'inspecteur de fichiers, localisez-le : cliquez Localiser, puis sélectionnez votre langue de base. Ensuite, pour chaque langue supplémentaire, un nouveau fichier apparaît dans un sous-dossier.

Le format est la clé = paires de valeurs:

Pour la localisation allemande:

Utilisez toujours des clés descriptives, et non la chaîne anglaise elle-même, pour éviter les changements accidentels qui brisent les recherches. Si vous utilisez la chaîne anglaise comme clé, le renommer plus tard devient problématique.

Organisation de cordes avec commentaires

Ajouter des commentaires pour expliquer le contexte pour les traducteurs. Ils ne sont pas compilés dans l'application. Exemple:


Utilisation de NSLocalizedString dans le code

La macro lit la chaîne du fichier approprié en fonction du langage de périphérique de l'utilisateur. Sa signature:

La plupart des appels utilisent la clé et commentent :

Si aucune traduction n'est trouvée, la clé elle-même est retournée (ou le paramètre de valeur si fourni). Toujours fournir un commentaire significatif pour guider les traducteurs.

Manipulation des chaînes de format avec paramètres

Pour le contenu dynamique, utilisez des spécifiants de format comme , , . Exemple :

En code:

Cela permet aux traducteurs de réordonner les mots de façon appropriée (p. ex. en japonais, la structure de la phrase peut placer le nombre après le nom).

Utilisation de .stringsdict pour les règles plurielles

Les langues différentes ont des règles plurielles complexes. Par exemple, l'anglais a singulier/plural, mais l'arabe a six formes, et le polonais en a trois. Apple fournit fichiers pour gérer la pluralité et d'autres textes variables. Créez un fichier nommé dans les mêmes dossiers de localisation que . Son format est une liste avec une clé par format. Exemple:

Ensuite, dans le code, utilisez la même clé : . iOS sélectionne automatiquement le bon formulaire pluriel en fonction des règles de la locale.

Localisation des planches à histoire et XIB

Lorsque vous localisez un storyboard, chaque étiquette, bouton et champ texte obtient un équivalent dans le fichier de chaînes de caractères spécifiques à la langue. Vous pouvez modifier ces chaînes directement, ou utiliser Interface Builder pour prévisualiser et modifier les mises en page par langue. Cependant, pour une interface plus dynamique, vous pouvez préférer définir le texte en utilisant ] puis gérer la mise en page avec Auto Layout.

Aperçu des localisations dans Xcode

Dans Xcode, vous pouvez prévisualiser un storyboard dans différentes langues sans construire : ouvrez le storyboard, puis dans le menu Éditeur, sélectionnez Preview. Ajoutez un preview, puis changez la langue en utilisant le menu déroulant en bas. Ceci montre comment les chaînes s'étendent ou se contractent.

Réglage de la disposition pour l'expansion du texte

Le texte allemand est souvent 30 % plus long que l'anglais. Utilisez Auto Layout avec des contraintes qui peuvent faire croître les étiquettes verticalement ou horizontalement. Définissez le nombre de lignes à 0. Évitez les contraintes de largeur fixe. Utilisez les priorités de résistance au câlin et à la compression du contenu. Pour les boutons, envisagez d'utiliser ou d'autoriser la largeur dynamique.

Traitement des langues de droite à gauche (RTL)

L'iOS prend en charge RTL à travers la propriété sur les vues et le système , le basculement automatique des images et la mise en page basé sur la direction de mise en page de l'interface utilisateur (à partir du langage de l'appareil).

Configuration pour RTL

Assurez-vous que vos vues storyboard utilisent des contraintes de guidage/de positionnement au lieu de gauche/droite. Xcode , Auto Layout prend en charge automatiquement le guidage/de positionnement correct. Pour les mises en page programmatiques, utilisez et . Si vous avez un dessin ou une transformation personnalisées, respectez la direction de mise en page de l'interface utilisateur à partir de ou vérifiez .

Images et RTL

Les images ayant une signification directionnelle (par exemple, une flèche pointant vers l'avant) doivent être retournées en mode RTL. Dans le catalogue Asset, vous pouvez définir des images comme -Mirror- pour RTL. Sinon, fournir des jeux d'images séparés pour chaque direction. Pour les images de modèles, iOS peut se miroirr automatiquement si vous définissez sur l'image.

Alignement du texte

Pour les étiquettes et les vues de texte, utilisez qui aligne automatiquement la gauche pour LTR et la droite pour RTL. Évitez l'alignement de codage dur.

Dates, numéros et devises de localisation

Les utilisateurs finaux attendent des dates et des numéros formatés selon leur localisation. Utilisez et avec la locale de l'utilisateur. Définissez (qui est la valeur par défaut) et utilisez des styles prédéfinis comme , ou des modèles personnalisés. Par exemple:

Pour les nombres, utilisez avec style ou . Il gère automatiquement le regroupement des séparateurs, des séparateurs décimals et des symboles de monnaie.

Utilisation de Locale avec des chaînes de format

Pour les chaînes orientées vers l'utilisateur, utilisez qui respecte la locale. Pour l'analyse interne, utilisez avec une locale fixe comme .

Localisation des essais

Des tests approfondis sont critiques. Simulez différentes langues sur le simulateur en éditant les paramètres de la langue et de la région d'applications. Allez dans Produit > Scheme > Editer Scheme, puis sous Exécuter > Options, choisissez une langue d'application différente (par exemple, l'allemand) et la région (par exemple, l'Allemagne).

Utilisation du commutateur de langage Simulator ,

Vous pouvez également changer la langue du Simulator: Settings > General > Language & Region. Cependant, la méthode de schéma est plus rapide pour tester une seule langue.

Essais RTL

Réglez le schéma de langue d'application en arabe. Vérifiez que toutes les vues s'affichent correctement. Faites une attention particulière aux vues personnalisées, aux vues par défilement et aux vues Web. Utilisez les outils de débogage > Afficher les outils de débogage pour inspecter la mise en page.

Test avec Pseudolocalisation

Xcode offre une pseudolocalisation pour simuler de longues chaînes ou RTL sans traduction réelle. Dans le schéma Options, activez -Double-Length Pseudolanguage - ou -Right to Left Pseudolanguage -. Cela aide à attraper les problèmes de troncation et d'alignement tôt.

Localisation du contenu dynamique et de l'interface utilisateur serveur

Si votre application télécharge du contenu depuis un serveur, vous ne pouvez pas vous fier uniquement à . Vous devez envoyer la préférence de l'utilisateur local au serveur et lui faire renvoyer du contenu traduit. Utilisez l'en-tête ou un paramètre personnalisé. Du côté iOS, vous pouvez obtenir les langues préférées de ou .

Pour l'interface utilisateur sous serveur rendue dans des composants natifs, vous pouvez mapper les clés de chaîne envoyées par le serveur vers des traductions locales en utilisant un modèle similaire mais avec une table ou un paquet différent.

Meilleures pratiques pour une localisation durable

  • Keep cles descriptives et cohérentes – Utilisez la notation par points comme pour les clés de l'espace de noms.
  • Utilisez une seule source de vérité – Évitez de dupliquer les traductions entre les fichiers. Utilisez la localisation de base et référez-vous à la même clé.
  • Automatiser l'exportation/importation – Xcode peut exporter toutes les localisations sous forme de fichiers XLIFF pour les traducteurs, puis importer les fichiers traduits en retour. Utilisez et .
  • Commander vos chaînes – Gardez et fichiers dans Git. Utilisez des outils de diff pour suivre les changements.
  • N'incluez jamais de texte localisable dans le code – Utilisez toujours ou pour la séparation.
  • Considérez attentivement l'interpolation de la chaîne – Les traducteurs doivent comprendre ce que représente chaque détenteur de place. Utilisez des arguments positionnels () pour permettre la réorganisation.

Travailler avec SwiftUI Localisation

SwiftUI simplifie la localisation. Par défaut, recherche la chaîne dans ] en utilisant la clé -Hello. Si aucune clé n'existe, elle utilise la chaîne proprement dite. Vous pouvez explicitement les clés avec et fournir des traductions.

Pour les chaînes formatées, utilisez – SwiftUI utilise automatiquement le si vous avez la clé -Vous avez %d items - dans un fichier . Cependant, pour correspondre précisément à la clé, vous pouvez avoir besoin de définir le format complet. Mieux vaut utiliser une clé dédiée:

ne fonctionne pas directement.

Ou utilisez SwiftUI , mais cela exige que la clé soit exactement --items count %d-- dans le fichier des chaînes. L'approche la plus sûre est de continuer à utiliser avec ] à l'intérieur d'une propriété calculée.

Localisation des images dans SwiftUI

Utilisez et fournissez la localisation du catalogue d'actifs pour chaque langue. Ou utilisez avec des étiquettes d'accessibilité localisées via .

Pièges courants et comment les éviter

  • Traduit par la Rédaction – Utilisez avec un paramètre pour fournir un retour en arrière en anglais. Exécutez régulièrement le simulateur dans chaque langue pour repérer des chaînes non traduites.
  • Layout codé en caractères durs – Évitez les largeurs fixes. Testez avec les traductions allemandes les plus longues.
  • Ignorer les règles plurielles – Utilisez toujours .stringsdict pour des chaînes pluralistes.
  • Oublier la locale pour l'analyse de date/numéro – Lorsque l'entrée de l'utilisateur est analysée, utilisez une locale fixe comme en US POSIX pour le stockage interne.
  • N'effectue pas de tests sur des appareils réels – La commutation de langage de simulateur est fiable, mais les tests de périphérique exposent des comportements spécifiques à une région comme le calendrier, le fuseau horaire et le clavier.
  • Accessibilité générale[ – VoiceOver parle des chaînes localisées. Assurez-vous que les étiquettes d'accessibilité sont aussi localisées et que l'utilisation est appropriée.

Ressources externes pour une compréhension plus approfondie

  • Apple , Guide d'internationalisation et de localisation[ – Documentation officielle couvrant tout, des fichiers de chaînes à l'assistance de droite à gauche. Apple Internationalization
  • NSHipster="s NSLocalizedString article – Conseils pratiques et fonctionnalités de l'API moins connues. NSHipster sur NSLocalizedString
  • Objc.io]s Internationalisation – Plongée profonde dans le .stringsdict et la pluralité. Objc.io Internationalisation

Conclusion

En mettant à profit les outils de localisation intégrés Apple—Base Internationalization, , ] et Auto Layout, vous pouvez créer une application qui se sent à la maison dans n'importe quelle langue. Tester régulièrement avec la pseudolocalisation et les appareils réels attrape les problèmes tôt. L'effort à l'avance sauve les maux de tête futurs et ouvre votre application à des millions d'utilisateurs dans le monde entier. Commencez par une solide fondation d'internationalisation, puis étendez les langues à mesure que votre base d'utilisateurs grandit.