Partager via

Localisation

  • Article

Ce guide présente les concepts de l’internationalisation et de la localisation et des liens vers des instructions sur la façon de produire des applications mobiles Xamarin à l’aide de ces concepts.

Si vous souhaitez passer directement aux détails techniques de la localisation des applications Xamarin, commencez par l’un de ces articles pratiques spécifiques à la plateforme :

i18n et L10n

L’internationalisation est le processus consistant à rendre votre code capable d’afficher différentes langues et d’adapter son affichage pour différents paramètres régionaux (comme le nombre et la mise en forme de date). C’est également ce qu’on appelle la mondialisation.

La localisation est l’étape suivante : création de ressources (telles que des chaînes et des images) pour chaque langue et regroupement avec l’application internationalize.

L’internationalisation est souvent raccourcie à i18n : raccourcie pour 18 lettres comprises entre « i » et « n ». La localisation est également raccourcie à L10n : pour 10 lettres comprises entre « L » et « n ».

Vue d’ensemble

Ce document présente les concepts associés à l’internationalisation et à la localisation, ainsi que la façon dont ils s’appliquent au développement d’applications mobiles en général. Lors de la conception et de la génération d’une application, les éléments que vous avez peut-être précédemment codés en dur, mais qui doivent être paramétrés pour la localisation sont les suivants :

  • Dispositions et texte de l’écran,
  • Icônes, graphiques et couleurs,
  • Fichiers vidéo et audio,
  • Texte dynamique et mise en forme de texte (par exemple, nombres, devises et dates),
  • Modifications de disposition pour les langues de droite à gauche (RTL) et
  • Tri des données.

Quelles que soient les plateformes mobiles ciblées par votre application, ces conseils vous aideront à créer une application localisée de haute qualité.

Remarques sur la conception

L’architecture d’une application afin qu’il soit possible de localiser son contenu est appelée internationalisation. Effectuer correctement l’internationalisation est plus que simplement autoriser le chargement de différentes chaînes linguistiques au moment de l’exécution. Une application bien conçue doit permettre à toutes les ressources d’être modifiées en fonction de la langue et des paramètres régionaux (y compris les images, les sons et les vidéos) et peut adapter la mise en forme et la disposition pour faire face à différentes chaînes de taille.

Cette section décrit certaines considérations relatives à la conception à prendre en compte lors de la création d’une application internationalisée.

Dispositions et longueur de chaîne

Les chaînes chinoises et japonaises peuvent être très courtes , parfois un ou deux caractères peuvent être suffisamment significatifs pour une étiquette de champ d’entrée.

Les chaînes allemandes (par exemple) peuvent être très longues ; parfois un mot relativement court en anglais devient très long dans d’autres langues , soit en devenant clippé ou autrement reflowant de manière inattendue votre disposition.

Comparez les longueurs de chaîne pour quelques éléments sur l’écran d’accueil iOS en anglais, en allemand et en japonais :

German vs Japanese string length

Notez que Paramètres en anglais (8 caractères) nécessite 13 caractères pour la traduction allemande, mais seulement 2 caractères en japonais.

Les dispositions où l’étiquette d’affichage et le champ d’entrée sont côte à côte sont difficiles à utiliser lorsque la longueur de l’étiquette peut varier considérablement. Souvent, une disposition où l’étiquette est affichée au-dessus d’un champ est plus facile à localiser, car la largeur totale de l’écran est disponible pour l’étiquette et l’entrée.

En règle générale, si vous créez des dispositions fixes (en particulier des éléments côte à côte) autorisez au moins 50 % plus de largeur que vos chaînes anglaises nécessitent des étiquettes et du texte. Cela ne résout pas chaque problème, mais fournit une mémoire tampon qui fonctionnera dans de nombreux cas.

Validation d’entrée

Attention aux hypothèses lors de l’écriture de règles de validation. Il peut sembler valide d’exiger une entrée de champ de texte pour « exiger » au moins trois caractères en anglais, car une seule lettre a très rarement une signification. En chinois et japonais toutefois, un caractère unique peut être une entrée valide, et un message de validation « au moins 3 caractères est requis » n’est pas logique pour ces langues.

D’autres tâches apparemment simples telles que la validation d’une adresse e-mail ou l’URL du site web deviennent plus complexes avec les caractères ne sont pas limitées au sous-ensemble ASCII.

Écrivez vos règles de validation avec l’internationalisation à l’esprit : choisissez les règles les moins restrictives ou écrivez la logique afin qu’elle fonctionne différemment pour chaque langue.

Images et couleurs

Toutes les images ne doivent pas changer en fonction du choix de langue d’un utilisateur. De nombreuses icônes ou photos seront adaptées à tous les utilisateurs, quelle que soit la langue qu’ils parlent. Toutefois, certaines ressources sont logiques pour localiser, par exemple :

  • Images illustrant des personnes ou des emplacements spécifiques : votre application peut se sentir plus pertinente pour les utilisateurs s’il affiche des personnes/emplacements locaux.
  • Icônes : certaines iconographies peuvent être propres à la culture et vous pouvez faciliter l’utilisation de votre application en localisant l’image pour refléter la compréhension locale.
  • Couleurs : certaines cultures comprennent les couleurs différemment : le rouge peut signifier un avertissement dans une région, mais bonne chance dans un autre. Vérifiez avec les haut-parleurs natifs lors de la conception de votre application pour déterminer si vous devez créer un mécanisme pour localiser les couleurs.

Vidéos et son

Les vidéos et le son présentent des défis spéciaux lors de la localisation d’une application, car bien qu’il soit relativement facile d’obtenir des chaînes traduites, l’enregistrement de plusieurs pistes vocales ou clips vidéo peut être coûteux et difficile.

Plusieurs copies de fichiers vidéo et audio peuvent également augmenter considérablement la taille de votre application (en particulier si vous localisez dans un grand nombre de langues ou si vous avez beaucoup de fichiers multimédias). Vous pouvez envisager de télécharger uniquement les ressources linguistiques requises une fois que l’utilisateur a installé votre application, mais cela peut également entraîner une mauvaise expérience utilisateur sur les réseaux lents.

Il existe souvent plusieurs façons de résoudre les problèmes de localisation : la chose la plus importante est de les considérer à l’avant-plan et de s’assurer que votre application est conçue pour les prendre en charge.

Dates, heures, nombres et devises

Si vous utilisez des fonctions de mise en forme .NET, n’oubliez pas de spécifier la culture afin que les séparateurs décimaux soient analysés correctement (et évitez les exceptions de conversion levées). Par exemple, 1,99 et 1 99 sont des représentations décimales valides en fonction de vos paramètres régionaux.

Lorsque les données proviennent d’une source connue (par exemple, à partir de votre propre code ou d’un service web que vous contrôlez), vous pouvez encoder en dur un identificateur de culture qui correspond à la mise en forme telle que l’InvariantCulture qui fonctionnera pour la mise en forme standard de la langue anglaise.

double.Parse("1,999.99", CultureInfo.InvariantCulture);

Si les données sont entrées par l’utilisateur de l’application, analysez-la à l’aide d’une instance CultureInfo qui reflète leurs paramètres régionaux :

double.Parse("1 999,99", CultureInfo.CreateSpecificCulture("fr-FR"));

Pour plus d’informations, consultez les articles MSDN sur l’analyse des chaînes numériques et l’analyse des chaînes de date et d’heure.

Langues de droite à gauche (RTL)

Certaines langues, telles que l’arabe, l’hébreu et l’Urdu (par exemple), sont lues de droite à gauche. Les applications qui prennent en charge ces langages doivent utiliser des conceptions d’écran qui s’adaptent aux lecteurs de droite à gauche, par exemple :

  • Le texte doit être aligné à droite.
  • Les étiquettes doivent apparaître à droite des champs d’entrée.
  • L’emplacement des boutons par défaut est généralement inversé.
  • Le balayage et l’animation de navigation hiérarchiques (et d’autres métaphores et animations de navigation) qui utilisent la direction pour le contexte doivent également être inversés.

IOS et Android prennent en charge les dispositions de droite à gauche et le rendu de police, avec des fonctionnalités intégrées qui aident à effectuer les ajustements ci-dessus. Xamarin.Forms ne prend actuellement pas en charge automatiquement le rendu RTL.

Tri

Les différentes langues définissent l’ordre de tri de leurs alphabets différemment, même lorsqu’elles utilisent le même jeu de caractères.

Consultez les détails de la comparaison de chaînes dans les meilleures pratiques pour l’utilisation de chaînes dans le .NET Framework pour obtenir un exemple où le langage (CultureInfo) affecte l’ordre de tri.

Il est peu probable que les fonctionnalités de base de données intégrées sur les plateformes mobiles prennent en charge l’ordre de tri spécifique au langage. Vous devrez peut-être implémenter du code supplémentaire dans votre logique métier.

Recherche de texte

Veillez à écrire et tester votre algorithme de recherche avec plusieurs langues à l’esprit. Voici quelques éléments à prendre en compte :

  • Saisie semi-automatique : si vous avez créé une fonction de saisie semi-automatique, assurez-vous qu’elle source des suggestions pertinentes pour la langue de l’utilisateur.
  • Correspondance de la requête aux données : les requêtes de recherche entrées dans une langue spécifique sont-elles exécutées par rapport au contenu écrit dans cette langue ou à tout le contenu de votre application ?
  • Recherche de recherche : si votre recherche est conçue pour rechercher des mots similaires, des racines de mots et d’autres optimisations de recherche, ces optimisations sont-elles conçues pour toutes les langues que vous prenez en charge ?
  • Tri : vérifiez que les résultats sont correctement triés (voir ci-dessus).

Données provenant de sources externes

De nombreuses applications téléchargent des données à partir de sources externes, des flux Twitter et RSS aux cours météo, actualités ou actions. Lorsque vous affichez ceci à un utilisateur, vous devez envisager la possibilité d’afficher un écran d’informations non pertinentes ou non lisibles pour eux.

Il existe quelques stratégies que vous pouvez utiliser pour essayer de vérifier que votre application affiche les données pertinentes pour l’utilisateur :

  • Différentes sources : votre application peut télécharger les données à partir d’une autre source en fonction de la langue ou des paramètres régionaux de l’utilisateur. Les actualités locales, la météo et les cours des actions peuvent être plus logiques que quelque chose téléchargé à partir d’un flux de Amérique du Nord n.
  • Affichage localisé : si vous affichez un flux Twitter ou photo, vous devez afficher les métadonnées (telles que le temps nécessaire) dans sa propre langue, même si le contenu lui-même reste dans la langue d’origine.
  • Traduction : vous pouvez créer une option de traduction dans votre application pour effectuer une traduction automatique de données entrantes. Cela peut être automatique ou à la discrétion de l’utilisateur : veillez simplement à informer l’utilisateur si cela se produit, car les traductions automatiques ne sont jamais parfaites !

Cela peut également affecter des liens externes vers des pistes audio ou des vidéos : lors de la conception de votre application, veillez à planifier l’approvisionnement du contenu traduit ou à garantir que les utilisateurs sont correctement informés par l’interface utilisateur lorsque le contenu ne sera pas présenté dans leur langue.

Ne pas sur-traduire

Certaines chaînes de votre application n’ont peut-être pas besoin de traduire, ou au moins besoin d’une attention particulière par le traducteur. Les exemples doivent inclure :

  • URL : si vous répertoriez une URL, il peut ou ne pas avoir besoin d’être ajustée par langue. Par exemple, facebook.com ne nécessite pas de traduction qu’elle détecte automatiquement la langue sur le site principal. D’autres sites ont du contenu spécifique aux paramètres régionaux et vous pouvez proposer une URL différente, telle que yahoo.com par rapport à yahoo.fr ou yahoo.it.
  • Numéros de téléphone , en particulier ceux avec différents codes de pays ou numéros pour les appelants qui parlent une langue particulière.
  • Coordonnées : les adresses et autres informations peuvent varier selon la langue ou les paramètres régionaux.
  • Marques et noms de produits : certaines chaînes n’ont pas besoin de traduire, car elles sont toujours écrites dans la même langue.

Enfin, veillez à inclure des instructions détaillées pour le traducteur si certaines chaînes nécessitent un traitement spécial.

Texte mis en forme

Pas généralement un problème avec les applications mobiles, car les chaînes ne sont généralement pas mises en forme richement. Toutefois, si le texte enrichi (par exemple, la mise en forme gras ou italique) est requis dans votre application, assurez-vous que le traducteur sait comment entrer la mise en forme, vos fichiers de chaînes le stockent correctement et sont mis en forme correctement avant d’être affichés à l’utilisateur (par exemple, ne laissez pas accidentellement les codes de mise en forme eux-mêmes être présentés à l’utilisateur).

Astuces de traduction

La traduction des chaînes utilisées par une application est considérée comme faisant partie du processus de localisation. En règle générale, cette tâche sera externalisée à un service de traduction et effectuée par le personnel multilingue qui ne connaîtra peut-être pas votre application ou votre entreprise.

Les conseils suivants vous aideront à produire des chaînes plus faciles à traduire avec précision et, par conséquent, améliorer la qualité de vos applications localisées.

Localiser des chaînes complètes, et non des mots

Parfois, les développeurs prennent l’approche d’essayer de spécifier des mots uniques ou des phrases « extraits de code » afin qu’ils puissent les réutiliser dans l’application. Par exemple, pour le texte « Vous avez 5 messages ». Ils peuvent spécifier les chaînes suivantes pour la traduction.

Mauvais :

"You have"
"no"
"message"
"messages"

puis tentez de créer l’expression correcte à la volée dans le code à l’aide de la concaténation de chaîne :

Mauvais :

"You have" + " " + numMsgs + " " + "messages"
"You have" + " no " + "messages"

Cela est déconseillé car il ne fonctionnera pas nécessairement pour toutes les langues et sera difficile pour le traducteur de comprendre le contexte de chaque segment court. Il conduit également à réutiliser des chaînes traduites, ce qui peut entraîner des problèmes ultérieurement s’ils sont utilisés dans différents contextes (puis être mis à jour).

Autoriser la réécriture des paramètres

Certains langages de programmation nécessitent une syntaxe supplémentaire pour spécifier l’ordre des paramètres dans une chaîne, mais .NET prend déjà en charge le concept d’espaces réservés numérotés.

Bon :

"a {0} b {1} cde {3}"

peut être traduit comme suit (où la position et l’ordre des espaces réservés sont modifiés)

"{2} {3} f g h {0}"

et les jetons seront commandés en tant que traducteur prévu. Veillez à inclure une explication de ce que chaque espace réservé contient lors de l’envoi de la chaîne à un traducteur.

Utiliser plusieurs chaînes pour carte inalité

Évitez les chaînes comme "You have {0} message/s." Utiliser des chaînes spécifiques pour chaque état afin de fournir une meilleure expérience utilisateur :

Bon :

"You have no messages."
"You have 1 message."
"You have 2 messages."
"You have {0} messages."

Vous devrez écrire du code dans votre application pour évaluer le nombre affiché et choisir la chaîne appropriée. Certaines plateformes (y compris iOS et Android) ont des fonctionnalités intégrées pour choisir automatiquement la meilleure chaîne plurielle en fonction des préférences de la langue/des paramètres régionaux actuels.

Autoriser le sexe

Les langues latines utilisent parfois des mots différents selon le sexe du sujet. Si votre application connaît le sexe, vous devez autoriser les chaînes traduites à refléter cela.

Il existe également le cas le plus évident même en anglais, où les chaînes font référence à une personne ou un utilisateur spécifique de votre application. Par exemple, certains sites affichent des messages tels "Bob commented on his post" que vous avez besoin de chaînes pour un sexe masculin, féminin et non binaire ou inconnu :

Bon :

"{0} commented on his post"
"{0} commented on her post"
"{0} commented on their post"

Ne réutilisez pas les chaînes

Ou plus précisément, ne réutilisez pas les chaînes simplement parce qu’elles sont similaires lorsque la chaîne elle-même a un objectif ou une signification différente.

Par exemple : imaginez que vous disposez d’un commutateur activé/désactivé dans votre application et que le contrôle de commutateur a besoin du texte « activé » et « désactivé » pour être localisé. Vous affichez également la valeur de ce paramètre ailleurs dans l’application dans une étiquette de texte. Vous devez utiliser différentes chaînes pour l’affichage du commutateur par rapport à l’état du commutateur (même s’il s’agit de la même chaîne dans votre langue par défaut), par exemple :

  • « Activé » : affiché sur le commutateur lui-même
  • « Désactivé » : affiché sur le commutateur lui-même
  • « Activé » : affiché dans une étiquette
  • « Désactivé » : affiché dans une étiquette

Cela offre une flexibilité maximale pour le traducteur :

  • Pour des raisons de conception, peut-être que le commutateur lui-même utilise des minuscules « on » et « off », mais l’étiquette d’affichage utilise les majuscules « On » et « Off ».
  • Certaines langues peuvent avoir besoin que la valeur de commutateur soit abrégée pour s’adapter au contrôle d’interface utilisateur, tandis que le mot complet (traduit) peut apparaître dans l’étiquette.
  • Par ailleurs, pour certaines langues, le rendu de votre commutateur peut être utilisé « I » et « O » pour connaître la culture, mais vous souhaiterez peut-être que l’étiquette lise « On » ou « Off ».

Services de traduction

Traduction automatique

Pour créer des fonctionnalités de traduction dans votre application, tenez compte de l’API De texte Azure Traducteur.

À des fins de test, vous pouvez utiliser l’un des nombreux outils de traduction en ligne pour inclure du texte localisé dans votre application pendant le développement :

Il y a beaucoup d’autres disponibles. La qualité de la traduction automatique n’est généralement pas considérée comme suffisante pour libérer une application sans être examinée et testée par des traducteurs professionnels ou des orateurs natifs.

Traduction professionnelle

Il existe également des services de traduction professionnels qui prendront vos chaînes et les distribueront à leurs propres traducteurs, ce qui vous fournira des traductions terminées pour un tarif.

L’un des services les plus connus est LionBridge. La plupart des services professionnels prennent en charge tous les types de fichiers courants, notamment les chaînes, XML, RESX et POT/PO.

Résumé

Cet article a présenté quelques-uns des concepts que vous devez connaître avant d’internationaliser votre application, puis de localiser vos ressources, et a également abordé comment modifier les préférences linguistiques pour chaque plateforme.

Ces concepts peuvent être appliqués aux différentes techniques d’internationalisation spécifiques à la plateforme et multiplateformes possibles avec Xamarin.

Poursuivez la lecture des détails techniques de la plateforme qui vous intéresse :