Localisation dans Xamarin.iOS

Ce document décrit les fonctionnalités de localisation du Kit de développement logiciel (SDK) iOS et explique comment y accéder avec Xamarin.

Reportez-vous aux encodages d’internationalisation pour obtenir des instructions sur l’inclusion de jeux de caractères/pages de codes dans les applications qui doivent traiter des données non Unicode.

Fonctionnalités de la plateforme iOS

Cette section décrit certaines des fonctionnalités de localisation dans iOS. Passez à la section suivante pour afficher un code et des exemples spécifiques.

Langage

Les utilisateurs choisissent leur langue dans l’application Paramètres. Ce paramètre affecte les chaînes de langue et les images affichées par le système d’exploitation et dans les applications.

Pour déterminer la langue utilisée dans une application, obtenez le premier élément de NSBundle.MainBundle.PreferredLocalizations:

var lang = NSBundle.MainBundle.PreferredLocalizations[0];

Cette valeur sera un code de langue tel que en l’anglais, es l’espagnol, ja le japonais, etc. La valeur retournée est limitée à l’une des localisations prises en charge par l’application (à l’aide de règles de secours pour déterminer la meilleure correspondance).

Le code d’application n’a pas toujours besoin de case activée pour cette valeur : Xamarin et iOS fournissent toutes deux des fonctionnalités qui permettent de fournir automatiquement la chaîne ou la ressource correcte pour la langue de l’utilisateur. Ces fonctionnalités sont décrites dans le reste de ce document.

Remarque

Permet NSLocale.PreferredLanguages de déterminer les préférences linguistiques de l’utilisateur, quelles que soient les localisations prises en charge par l’application. Les valeurs retournées par cette méthode ont changé dans iOS 9 ; Consultez la note technique TN2418 pour plus d’informations.

Paramètres régionaux

Les utilisateurs choisissent leurs paramètres régionaux dans l’application Paramètres. Ce paramètre affecte la façon dont les dates, heures, nombres et devises sont mises en forme.

Cela permet aux utilisateurs de choisir s’ils voient des formats de temps de 12 heures ou de 24 heures, si leur séparateur décimal est une virgule ou un point, et l’ordre de jour, de mois et d’année dans l’affichage des dates.

Avec Xamarin, vous avez accès aux classes iOS d’Apple (NSNumberFormatter) ainsi qu’aux classes .NET dans System.Globalization. Les développeurs doivent évaluer ce qui convient mieux à leurs besoins, car il existe différentes fonctionnalités disponibles dans chacun d’eux. En particulier, si vous récupérez et affichez des prix d’achat dans l’application à l’aide de StoreKit, vous devez utiliser les classes de mise en forme d’Apple pour les informations de prix retournées.

Les paramètres régionaux actuels peuvent être interrogés de deux façons :

• NSLocale.CurrentLocale.LocaleIdentifier
• NSLocale.AutoUpdatingCurrentLocale.LocaleIdentifier

La première valeur peut être mise en cache par le système d’exploitation et peut donc ne pas toujours refléter les paramètres régionaux actuellement sélectionnés par l’utilisateur. Utilisez la deuxième valeur pour obtenir les paramètres régionaux actuellement sélectionnés.

Remarque

Mono (runtime .NET sur lequel Xamarin.iOS est basé) et les API iOS d’Apple ne prennent pas en charge des ensembles identiques de combinaisons de langage/région. Pour cette raison, il est possible de sélectionner une combinaison de langue/région dans l’application iOS Paramètres qui ne correspond pas à une valeur valide dans Mono. Par exemple, la définition de la langue d’un i Téléphone sur l’anglais et sa région en Espagne entraîne le rendement des API suivantes :

• CurrentThead.CurrentCulture: en-US (API Mono)
• CurrentThread.CurrentUICulture: en-US (API Mono)
• NSLocale.CurrentLocale.LocaleIdentifier: en_ES (API Apple)

Étant donné que Mono utilise CurrentThread.CurrentUICulture pour sélectionner des ressources et CurrentThread.CurrentCulture mettre en forme des dates et des devises, la localisation mono (par exemple, avec des fichiers .resx) peut ne pas générer de résultats attendus pour ces combinaisons de langage/région. Dans ces situations, reposez sur les API d’Apple pour localiser si nécessaire.

NSCurrentLocaleDidChangeNotification

iOS génère une NSCurrentLocaleDidChangeNotification fois que l’utilisateur met à jour ses paramètres régionaux. Les applications peuvent écouter cette notification pendant leur exécution et apporter des modifications appropriées à l’interface utilisateur.

Principes de base de la localisation dans iOS

Les fonctionnalités suivantes d’iOS sont facilement exploitées dans Xamarin pour fournir des ressources localisées à l’utilisateur. Reportez-vous à l’exemple TaskyL10n pour voir comment implémenter ces idées.

Spécification des langues par défaut et prises en charge dans Info.plist

Dans le Q&A TECHNIQUE Q&A QA1828 : Comment iOS détermine la langue de votre application, Apple décrit comment iOS sélectionne une langue à utiliser dans une application. Les facteurs suivants ont un impact sur la langue affichée :

• Langues préférées de l’utilisateur (trouvées dans l’application Paramètres)
• Localisations groupées avec l’application (dossiers.lproj)
• CFBundleDevelopmentRegion (Valeur Info.plist spécifiant la langue par défaut de l’application)
• CFBundleLocalizations (Tableau Info.plist spécifiant toutes les localisations prises en charge)

Comme indiqué dans le Q&A technique, CFBundleDevelopmentRegion représente la région et la langue par défaut d’une application. Si l’application ne prend pas explicitement en charge les langues préférées d’un utilisateur, elle utilise la langue spécifiée par ce champ.

Important

iOS 11 applique ce mécanisme de sélection de langage plus strictement que les versions précédentes du système d’exploitation. En raison de cela, toute application iOS 11 qui ne déclare pas explicitement ses localisations prises en charge , soit en incluant les dossiers .lproj, soit en définissant une valeur pour CFBundleLocalizations – peut afficher une langue différente dans iOS 11 que dans iOS 10.

S’il CFBundleDevelopmentRegion n’a pas été spécifié dans le fichier Info.plist , les outils de génération Xamarin.iOS utilisent actuellement une valeur en_USpar défaut . Bien que cela change dans une version ultérieure, cela signifie que la langue par défaut est l’anglais.

Pour vous assurer que votre application sélectionne une langue attendue, procédez comme suit :

• Spécifiez une langue par défaut. Ouvrez Info.plist et utilisez la vue Source pour définir une valeur pour la CFBundleDevelopmentRegion clé ; en XML, elle doit ressembler à ce qui suit :

<key>CFBundleDevelopmentRegion</key>
<string>es</string>

Cet exemple utilise des « es » pour spécifier que lorsque aucune des langues préférées d’un utilisateur n’est prise en charge, par défaut en espagnol.

• Déclarez toutes les localisations prises en charge. Dans Info.plist, utilisez la vue Source pour définir un tableau pour la CFBundleLocalizations clé ; en XML, elle doit ressembler à ce qui suit :

<key>CFBundleLocalizations</key>
<array>
    <string>en</string>
    <string>es</string>
    ...
</array>

Les applications Xamarin.iOS localisées à l’aide de mécanismes .NET tels que les fichiers .resx doivent également fournir ces valeurs Info.plist .

Pour plus d’informations sur ces clés Info.plist, consultez la référence de la clé de liste des propriétés d’information d’Apple.

GetLocalizedString, méthode

La NSBundle.MainBundle.GetLocalizedString méthode recherche du texte localisé qui a été stocké dans des fichiers .strings dans le projet. Ces fichiers sont organisés par langue, dans des répertoires spécialement nommés avec un suffixe .lproj (notez que la première lettre de l’extension est une minuscule « L »).

Emplacements des fichiers .strings

• Base.lproj est le répertoire qui contient des ressources pour la langue par défaut. Il se trouve souvent dans la racine du projet (mais peut également être placé dans le dossier Ressources ).
• <les répertoires language.lproj> sont créés pour chaque langue prise en charge, généralement dans le dossier Ressources.

Il peut y avoir plusieurs fichiers .strings différents dans chaque répertoire de langue :

• Localizable.strings : liste principale de texte localisé.
• InfoPlist.strings : certaines clés spécifiques sont autorisées dans ce fichier à traduire des éléments tels que le nom de l’application.
• <storyboard-name.strings> : fichier facultatif qui contient des traductions pour les éléments d’interface utilisateur dans un storyboard.

L’actionde génération pour ces fichiers doit être une ressource groupée.

Format de fichier .strings

La syntaxe des valeurs de chaîne localisées est la suivante :

/* comment */
"key"="localized-value";

Vous devez échapper aux caractères suivants dans les chaînes :

• \" citation
• \\ Backslash
• \n Newline

Il s’agit d’un exemple es/Localizable.strings (par exemple. Fichier espagnol) de l’exemple :

"<new task>" = "<new task>";
"Task Details" = "Detalles de la tarea";
"Name" = "Nombre";
"task name" = "nombre de la tarea";
"Notes" = "Notas";
"other task info"= "otra información de tarea";
"Done" = "Completo";
"Save" = "Guardar";
"Delete" = "Eliminar";

Images

Pour localiser une image dans iOS :

1. Reportez-vous à l’image dans le code, par exemple :

   UIImage.FromBundle("flag");
   

2. Placez le fichier image flag.png par défaut dans Base.lproj (répertoire du langage de développement natif).

3. Placez éventuellement des versions localisées de l’image dans des dossiers .lproj pour chaque langue (par exemple. es.lproj, ja.lproj). Utilisez le même nom de fichier flag.png dans chaque répertoire de langue.

Si une image n’est pas présente pour une langue particulière, iOS revient au dossier de langue native par défaut et charge l’image à partir de là.

Lancer des images

Utilisez les conventions d’affectation de noms standard pour les images de lancement (et le XIB ou Storyboard pour i Téléphone 6 modèles) lors de leur placement dans les répertoires .lproj pour chaque langue.

Default.png
Default@2x.png
Default-568h@2x.png
LaunchScreen.xib

Nom de l’application

Le placement d’un fichier InfoPlist.strings dans un répertoire .lproj vous permet de remplacer certaines valeurs de la liste Info.plist de l’application, y compris le nom de l’application :

"CFBundleDisplayName" = "LeónTodo";

Les autres clés que vous pouvez utiliser pour localiser des chaînes spécifiques à l’application sont les suivantes :

• CFBundleName
• CFBundleShortVersionString
• NSHumanReadableCopyright

Dates et heures

Bien qu’il soit possible d’utiliser les fonctions de date et d’heure .NET intégrées (ainsi que la date et l’heure actuelles CultureInfo) pour mettre en forme les dates et les heures d’un paramètre régional, cela ignorerait les paramètres utilisateur spécifiques aux paramètres régionaux (qui peuvent être définis séparément de la langue).

Utilisez iOS NSDateFormatter pour produire une sortie qui correspond à la préférence des paramètres régionaux de l’utilisateur. L’exemple de code suivant illustre les options de mise en forme de date et d’heure de base :

var date = NSDate.Now;
var df = new NSDateFormatter ();
df.DateStyle = NSDateFormatterStyle.Full;
df.TimeStyle = NSDateFormatterStyle.Long;
Debug.WriteLine ("Full,Long: " + df.StringFor(date));
df.DateStyle = NSDateFormatterStyle.Short;
df.TimeStyle = NSDateFormatterStyle.Short;
Debug.WriteLine ("Short,Short: " + df.StringFor(date));
df.DateStyle = NSDateFormatterStyle.Medium;
df.TimeStyle = NSDateFormatterStyle.None;
Debug.WriteLine ("Medium,None: " + df.StringFor(date));

Résultats pour l’anglais dans la États-Unis :

Full,Long: Friday, August 7, 2015 at 10:29:32 AM PDT
Short,Short: 8/7/15, 10:29 AM
Medium,None: Aug 7, 2015

Résultats pour l’espagnol en Espagne :

Full,Long: viernes, 7 de agosto de 2015, 10:26:58 GMT-7
Short,Short: 7/8/15 10:26
Medium,None: 7/8/2015

Pour plus d’informations, reportez-vous à la documentation apple Date Formatters . Lors du test de la mise en forme de date et d’heure sensibles aux paramètres régionaux, case activée paramètres i Téléphone Langue et Région.

Disposition de droite à gauche (RTL)

iOS fournit un certain nombre de fonctionnalités pour faciliter la création d’applications prenant en charge RTL :

• Utilisez les attributs et trailing les leading dispositions automatiques pour l’alignement du contrôle (qui correspond à gauche et à droite pour l’anglais, mais est inversé pour les langues RTL). Le UIStackView contrôle est particulièrement utile pour mettre en place des contrôles prenant en charge RTL.
• Utiliser TextAlignment = UITextAlignment.Natural pour l’alignement du texte (qui sera laissé pour la plupart des langues, mais à droite pour RTL).
• UINavigationController retourne automatiquement le bouton Précédent et inverse la direction des mouvements de balayage.

Les captures d’écran suivantes montrent l’exemple Tasky localisé en arabe et en hébreu (bien que l’anglais ait été entré dans les champs) :

iOS inverse automatiquement les UINavigationControllercontrôles, et les autres contrôles sont placés à l’intérieur UIStackView ou alignés avec la disposition automatique. Le texte RTL est localisé à l’aide de fichiers .strings de la même façon que le texte LTR.

Localisation de l’interface utilisateur dans le code

L’exemple Tasky (localisé dans le code) montre comment localiser une application où l’interface utilisateur est intégrée au code (plutôt qu’aux XIB ou aux storyboards).

Structure du projet

Fichier Localizable.strings

Comme décrit ci-dessus, le format de fichier Localizable.strings se compose de paires clé-valeur. La clé décrit l’intention de la chaîne et la valeur est le texte traduit à utiliser dans l’application.

Les localisations espagnoles (es) pour l’exemple sont indiquées ci-dessous :

"<new task>" = "<new task>";
"Task Details" = "Detalles de la tarea";
"Name" = "Nombre";
"task name" = "nombre de la tarea";
"Notes" = "Notas";
"other task info"= "otra información de tarea";
"Done" = "Completo";
"Save" = "Guardar";
"Delete" = "Eliminar";

Exécution de la localisation

Dans le code de l’application, où que le texte d’affichage d’une interface utilisateur soit défini (qu’il s’agisse du texte d’une étiquette ou de l’espace réservé d’une entrée, etc.), le code utilise la fonction iOS GetLocalizedString pour récupérer la traduction correcte à afficher :

var localizedString = NSBundle.MainBundle.GetLocalizedString ("key", "optional");
someControl.Text = localizedString;

Localisation des interfaces utilisateur de table de montage séquentiel

L’exemple tasky (storyboard localisé) montre comment localiser du texte sur des contrôles dans un storyboard.

Structure de projet

Le répertoire Base.lproj contient le storyboard et doit également contenir toutes les images utilisées dans l’application.

Les autres répertoires de langue contiennent un fichier Localizable.strings pour toutes les ressources de chaîne référencées dans le code, ainsi qu’un fichier MainStoryboard.strings qui contient des traductions pour du texte dans le storyboard.

Les répertoires linguistiques doivent contenir une copie de toutes les images localisées, pour remplacer celle présente dans Base.lproj.

ID d’objet / ID de localisation

Lors de la création et de la modification de contrôles dans un storyboard, sélectionnez chaque contrôle et case activée l’ID à utiliser pour la localisation :

• Dans Visual Studio pour Mac, il se trouve dans le panneau Propriétés et est appelé ID de localisation.
• Dans Xcode, il s’agit de l’ID d’objet.

Cette valeur de chaîne a souvent un formulaire tel que « NF3-h8-xmR », comme illustré dans la capture d’écran suivante :

Cette valeur est utilisée dans le fichier .strings pour affecter automatiquement du texte traduit à chaque contrôle.

MainStoryboard.strings

Le format du fichier de traduction de storyboard est similaire au fichier Localizable.strings , sauf que la clé (la valeur à gauche) ne peut pas être définie par l’utilisateur, mais doit au lieu de cela avoir un format très spécifique : ObjectID.property.

Dans l’exemple Mainstoryboard.strings ci-dessous, vous pouvez voir s’il UITextFields’agit d’une placeholder propriété de texte qui peut être localisée ; UILabelont une text propriété ; et UIButtonle texte par défaut est défini à l’aide de normalTitle:

"SXg-TT-IwM.placeholder" = "nombre de la tarea";
"Pqa-aa-ury.placeholder"= "otra información de tarea";
"zwR-D9-hM1.text" = "Detalles de la tarea";
"bAM-2j-Rzw.text" = "Notas";           /* Notes */
"NF3-h8-xmR.text" = "Completo";        /* Done */
"MWt-Ya-pMf.normalTitle" = "Guardar";  /* Save */
"IGr-pR-05L.normalTitle" = "Eliminar"; /* Delete */

Important

L’utilisation d’un storyboard avec des classes de taille peut entraîner des traductions qui n’apparaissent pas dans l’application. Les notes de publication Xcode d’Apple indiquent qu’un storyboard ou XIB n’est pas localisé correctement si trois choses sont vraies : il utilise des classes de taille, la localisation de base et la cible de build sont définies sur Universal et les cibles de build iOS 7.0. Le correctif consiste à dupliquer votre fichier de chaînes de storyboard en deux fichiers identiques : MainStoryboard~iphone.strings et MainStoryboard~ipad.strings, comme illustré dans la capture d’écran suivante :

Description de l’App Store

Suit le FAQ d’Apple sur la localisation d’App Store pour entrer des traductions pour chaque pays que votre application est en vente. Notez leur avertissement que les traductions s’affichent uniquement si votre application contient également un répertoire .lproj localisé pour la langue.

Résumé

Cet article décrit les principes de base de la localisation d’applications iOS à l’aide des fonctionnalités intégrées de gestion des ressources et de storyboard.

Vous pouvez en savoir plus sur i18n et L10n pour les applications iOS, Android et multiplateformes (y compris Xamarin.Forms) dans ce guide multiplateforme.

Liens associés

• Tâche (localisée dans le code) (exemple)
• Tasky (storyboard localisé) (exemple)
• Guide de localisation Apple
• Vue d’ensemble de la localisation multiplateforme
• Localisation Xamarin.Forms
• Localisation Android