Améliorez l’expérience multilingue de votre app

مرحبا! (Marhaba) Je m’appelle Omar et je suis ravi de vous parler aujourd’hui de la façon d’améliorer l’expérience multilingue de votre app. Nous vivons dans un monde profondément multilingue. Vous ne vous contentez plus de créer des apps. Vous créez des expériences qui doivent fonctionner partout, pour tout le monde. Que vous conceviez une app sociale pour des gens de Singapour et d’Asie du Sud-Est, un outil de productivité pour des équipes distantes à Londres et dans le reste de l’Europe ou des apps pour Beyrouth et le monde arabe, la langue ne se limite pas au texte affiché. C’est une culture. Une identité. Et pour des millions de personnes, cela fait toute la différence entre se sentir inclus ou exclu. iOS 26 propose plein de nouvelles fonctionnalités qui améliorent encore l’expérience multilingue. En tant que développeurs, vous pouvez profiter de ces améliorations pour créer des apps plus accessibles et plus internationales. Passons en revue certaines de ces nouvelles fonctionnalités. Dans iOS 26, les arabophones peuvent utiliser le nouveau clavier de translittération arabizi. Ils peuvent donc désormais taper des mots arabes en alphabet latin, puis le clavier saisit automatiquement l’alphabet arabe pour eux. Si vous avez l’habitude de taper sur le clavier anglais ou français, cela vous permet de taper très facilement en arabe. Le clavier de translittération offre également des suggestions bilingues. Donc, lorsque vous tapez un mot anglais sur ce clavier hindi, iOS 26 suggère automatiquement la traduction. Nous lançons également un nouveau clavier bilingue arabe/anglais multiscript. Si vous parlez à la fois l’arabe et l’anglais, la fonctionnalité détecte automatiquement la langue à mesure que vous tapez, ce qui simplifie la saisie dans les deux langues. Enfin, nous avons un nouveau clavier thaï avec 24 touches qui facilite beaucoup l’expérience pour les locuteurs thaïlandais. L’internationalisation est une première étape fondamentale dans la création d’apps destinées à un public mondial. Grâce à la puissance des outils et technologies d’Apple, comme Xcode, les API Foundation et la prise en charge d’Unicode, il est facile de préparer vos apps à la prise en charge de plusieurs langues, avant même de savoir lesquelles vous souhaitez ajouter. Avant d’aborder nos nouveaux outils et API pour l’internationalisation, j’aimerais partager avec vous quelques bonnes pratiques fondamentales pour rendre votre app multilingue. TextKit2 facilite la prise en charge de plusieurs langues dans votre app. Il gère les scripts complexes comme le coréen ou le hindi, et vous permet de mieux contrôler la mise en page et le style pour que le texte soit parfait, quelle que soit la langue. TextKit2 gère parfaitement le texte bidirectionnel. Plus tard, mon collègue Danny vous présentera les dernières avancées en la matière. Les formateurs dans Swift vous aident à afficher les dates, les nombres et le texte d’une manière qui s’adapte automatiquement à la langue et à la région de chaque personne. En quelques lignes de code, vous pouvez tout localiser, des devises aux formats de date, sans avoir à écrire de logique personnalisée pour chaque langue. De nombreuses API dans Swift simplifient la gestion des différents modes de saisie, comme les claviers logiciels voire matériels. Par exemple, vous pouvez utiliser inputAccessoryView pour placer une vue directement au-dessus du clavier ou définir textInputContextIdentifier pour aider le clavier à mémoriser automatiquement les dernières langue et disposition utilisées. Pour plus de détails sur TextKit, les formateurs et la saisie de texte, regardez la vidéo de l’an passé en lien ci-dessous. Vous pouvez également consulter l’exemple de code associé. Passons maintenant à de nouvelles API qui améliorent l’expérience multilingue de votre app. Je vais vous présenter une nouvelle fonctionnalité, Découverte de la langue, comment prendre en charge les calendriers alternatifs dans votre app, puis les avancées en matière de gestion du texte bidirectionnel. Commençons par Découverte de la langue. Des milliards de personnes dans le monde sont multilingues. Dans de nombreuses régions, la majorité des gens utilisent plusieurs langues dans leur vie quotidienne. Selon nous, pour concevoir d’excellentes apps, l’ensemble de l’expérience humaine doit être prise en compte. Il est crucial que les gens puissent interagir avec elles dans leurs propres langues. Avant iOS 26, la seule façon pour les gens de choisir leurs langues était de les ajouter manuellement dans l’app Réglages. Nous comprenons à quel point il est difficile de le faire. Par exemple, mon iPhone est réglé sur l’anglais, mais ma langue maternelle est l’arabe. J’écoute de la musique et des podcasts en arabe. Je lis les actualités et j’envoie des messages en anglais et en arabe. Donc, même si l’interface utilisateur de mon iPhone est en anglais, j’aimerais recevoir des recommandations d’actualités, de musique et de podcasts en arabe. Dans iOS 26, Siri est personnalisé, proactif et fait des suggestions intelligentes pour configurer mon appareil dans les langues que je parle. Grâce au système d’intelligence de l’appareil, Siri reconnaît que mon iPhone est configuré en anglais mais que j’écris, j’écoute et je navigue en arabe. Lorsque je touche la suggestion de Siri, je peux choisir de remplacer la langue de mon iPhone par l’arabe, ajouter un clavier bilingue arabe/anglais et demander à recevoir des suggestions comme des actualités, de la musique et des podcasts dans ma langue. Cette expérience s’adresse à des millions d’utilisateurs multilingues dans le monde qui aimeraient recevoir des recommandations dans leur langue. Grâce au framework Foundation, vous pouvez utiliser Locale.preferredLanguages pour obtenir la liste des langues de l’utilisateur et personnaliser l’expérience multilingue de votre app. Si vous connaissez Locale.preferredLanguages, vous savez qu’elle renvoie un tableau d’identifiants de langue sous forme de chaînes. Ces valeurs de chaîne sont conformes à la balise de langue BCP-47. Cependant, il peut être intimidant et complexe de gérer et de manipuler ces identifiants basés sur des chaînes. Cette année, nous introduisons Locale.preferredLocales, qui renvoie un tableau de paramètres régionaux contenant un sur-ensemble d’informations par rapport à Locale.preferredLanguages. Un paramètre régional représente à la fois la langue et la région, comme l’anglais du Royaume-Uni ou l’anglais du Canada. Pour mon iPhone, par exemple, le paramètre régional serait l’arabe du Liban. L’utilisation de paramètres régionaux est cruciale pour que vos apps personnalisent l’expérience selon les préférences des utilisateurs (orthographe, format de date, devise). Avec Locale, vous pouvez toujours accéder à l’identifiant basé sur une chaîne si vous le souhaitez et même choisir le format précis de l’identifiant, comme BCP-47, ICU ou CLDR. Vous avez également accès à un large éventail de propriétés sur les paramètres régionaux. Par exemple, vous pouvez obtenir le système de numérotation ou utiliser les API localizedString pour accéder aux noms traduits des langues et des régions. Locale.preferredLanguages sera peut-être bientôt obsolète. Nous vous encourageons donc à passer à Locale.preferredLocales. Dans iOS 26, nous utilisons beaucoup preferredLocales. Par exemple, l’app Traduire peut désormais afficher les langues des utilisateurs en haut de la liste, au lieu d’afficher une longue liste dans laquelle choisir. Dans Calendrier, quand un autre calendrier est défini, l’app peut désormais afficher les éléments de l’interface utilisateur tels que les jours et les mois dans leur langue. Enfin, Musique utilise preferredLocales pour recommander et proposer la traduction de paroles. L’expérience multilingue est ainsi encore plus personnalisée. Cette expérience dans l’app Traduire s’applique à de nombreuses apps où les utilisateurs doivent choisir leur langue dans une longue liste. Dans votre app, vous pouvez personnaliser l’expérience avec l’API preferredLocales et Foundation.

Entrons dans l’app Traduire et construisons cette expérience ensemble. Considérons availableLocales comme le tableau des objets de paramètres régionaux disponibles de votre app. Nous utiliserons matchedLocales comme le tableau qui fait correspondre les preferredLocales des utilisateurs aux availableLocales de votre app. Vous pouvez ensuite parcourir les paramètres régionaux disponibles de l’app Traduire. Vous pouvez ensuite vérifier que chaque paramètre régional disponible se trouve dans les preferredLocales. Si une correspondance est trouvée, vous pouvez l’ajouter à matchLocales et insérer « break ». matchLocales peut ensuite être utilisé pour hiérarchiser les langues et les placer en haut de la liste pour un accès facile. Selon vos préférences, vous pouvez choisir ici d’utiliser isEquivalent ou hasCommonParent. La découverte de la langue fait que votre app semble plus personnelle et naturelle. Elle évite aux utilisateurs de demander leur langue. Les cas d’utilisation sont infinis, et nous sommes impatients de voir comment vous utiliserez preferredLocales dans votre app. Parlons maintenant des nouvelles API de calendrier alternatif disponibles dans Foundation. Avec iOS 26, vous avez le choix entre de nombreux nouveaux calendriers alternatifs. Par exemple, pour le gujarati, le marathi et le coréen. Ces nouveaux calendriers sont disponibles sur toutes les plates-formes. En plus des 16 identifiants de calendrier existants, nous avons ajouté 11 nouveaux calendriers accessibles via Calendar.Identifier dans le framework Foundation. Nous avons aujourd’hui de nouvelles mises à jour passionnantes sur l’internationalisation, notamment la découverte de la langue et nos nouveaux identifiants de calendrier. Maintenant, je vais passer la parole à mon collègue, Danny, qui va vous expliquer les nouvelles mises à jour sur le texte bidirectionnel. Merci, Omar. Xin chào. Je m’appelle Danny et je suis ravi de vous présenter les progrès réalisés sur iOS et iPadOS en matière de texte bidirectionnel. Ces innovations peuvent considérablement améliorer l’expérience multilingue de votre app. Pour mieux comprendre le texte bidirectionnel, consultez la séance « Get it right (to left) ». Pour commencer, passons en revue la définition du texte bidirectionnel. Lorsque l’on écrit en anglais, le texte commence à gauche et se termine à droite. On parle donc de sens d’écriture « de gauche à droite » ou LTR. Lorsque l’on écrit dans une langue comme l’hébreu, le texte va de la droite vers la gauche. On parle donc de sens d’écriture « de droite à gauche » ou RTL. Lorsque l’on combine des textes LTR et RTL, le texte écrit devient bidirectionnel, ce qui a d’importantes implications pour la sélection du texte. Pour comprendre comment fonctionne la sélection dans un texte bidirectionnel, il faut d’abord considérer l’ordre du texte affiché par rapport à l’ordre du texte stocké. Dans cet exemple LTR, les caractères sont stockés dans l’ordre dans lequel ils sont écrits. Les caractères du texte RTL sont également stockés dans l’ordre dans lequel ils sont écrits. Mais la différence réside dans la façon dont le texte est affiché, qui est de droite à gauche. Cela ne pose pas de problèmes immédiats, car le texte peut être sélectionné en inversant simplement la méthode de sélection pour sélectionner par ordre décroissant dans le stockage tandis que la sélection est faite vers la droite. Cela se traduira par une seule plage contiguë de texte dans le stockage, correspondant à ce qui est visuellement sélectionné. Le problème se pose lorsque l’on combine des textes LTR et RTL. Le texte est toujours stocké dans l’ordre dans lequel il est écrit, mais il doit maintenant s’adapter à plusieurs sens lorsqu’il est affiché. Si nous limitons la sélection à une seule plage de texte stockée, la sélection de texte ne se comportera plus naturellement. Par exemple, si nous commençons la sélection de texte de gauche à droite, elle ne suivra plus le curseur lorsqu’elle traversera la limite LTR/RTL. Au lieu de cela, elle continuera à sélectionner le texte du côté droit, laissant un espace gênant au milieu de la sélection. Cela se produit parce que, malgré notre intention de sélectionner le texte affiché, la sélection se comporte comme si elle se produisait dans le stockage. Étant donné que le flux du texte à l’écran ne correspond pas à celui du texte stocké, il est impossible que la sélection soit contiguë à l’écran et dans le stockage en même temps. Dans iOS 26, au lieu de forcer la sélection à suivre l’ordre de stockage, nous permettons désormais à la sélection de suivre naturellement le curseur. Résultat : lorsque le point de sélection est déplacé, la sélection le suit parfaitement. C’est ce que nous appelons la sélection naturelle. La sélection naturelle garantit une sélection de texte fluide et cohérente, que vous sélectionniez du texte unidirectionnel ou bidirectionnel. Avec la sélection naturelle, l’écart de sélection n’est plus visible, mais est désormais masqué dans le stockage du texte. Ainsi, au lieu d’une seule selectedRange, il faut désormais plusieurs selectedRanges. Sous macOS, NSTextView prend déjà en charge la sélection naturelle en représentant la sélection sous forme de tableau de valeurs NSRanges. Dans iOS 18, UITextView a une seule propriété selectedRange pour représenter la sélection qui ne peut exprimer qu’une seule plage contiguë. Cela signifie que dans iOS 18, le texte bidirectionnel ne peut pas être sélectionné naturellement sans aucun espace visible, car selectedRange englobera par erreur la plage qui n’a pas été sélectionnée. Dans iOS 26, une nouvelle propriété appelée selectedRanges permet de représenter un tableau de NSRanges non contiguës. La propriété selectedRange unique sera bientôt obsolète. Le nouvel éditeur de texte enrichi SwiftUI prend aussi en charge la sélection naturelle. Les plages y sont représentées sous la forme d’un ensemble de plages de type AttributedString.Index. Pour plus de détails, consultez la présentation « Cook up a rich text experience in SwiftUI with AttributedString ». Maintenant, comme nous avions précédemment sélectionné le texte bidirectionnel, les selectedRanges représenteront avec précision le texte choisi. Si votre app a effectué une action basée sur la selectedRange, comme supprimer du texte du stockage TextView, elle peut supprimer par inadvertance la mauvaise plage de texte. Vous devez donc plutôt utiliser selectedRanges pour vous assurer que seul le texte qui a été réellement sélectionné est supprimé. En outre, nous avons mis à jour les protocoles UITextViewDelegate et UITextFieldDelegate pour qu’ils acceptent un tableau de valeurs NSRanges au lieu d’une seule plage. Ces méthodes sont déclenchées dès que le système de saisie de texte doit modifier le texte dans les plages spécifiées en réponse à la saisie de texte. Par exemple, si vous sélectionnez du texte, puis le collez dans une vue de texte, la méthode shouldChangeTextInRanges est appelée pour confirmer auprès du délégué que le texte peut être modifié dans les plages spécifiées avant que le texte supprimé ne soit remplacé par le texte collé. Comme les plages ne sont pas contiguës, il existe plusieurs points d’insertion potentiels. Le système de saisie de texte détermine l’emplacement d’insertion approprié dans les plages supprimées selon divers facteurs, y compris le clavier actuellement utilisé. Si le texte ne doit pas être inséré à l’un de ces emplacements, le délégué doit renvoyer « false ». En outre, de nouvelles versions de la méthode editMenuForTextInRange acceptent désormais un tableau de plages au lieu d’une seule plage pour représenter plus précisément les plages de texte auxquelles le menu d’édition renvoyé doit correspondre. En utilisant selectedRanges et en implémentant les nouvelles méthodes de délégué, vous pouvez vous assurer que vos apps fonctionnent parfaitement avec la sélection naturelle, pour améliorer l’expérience de texte bidirectionnel. Pour tirer le meilleur parti de la sélection naturelle, vos apps doivent utiliser TextKit2. UITextView et UITextField utilisent déjà TextKit2 comme moteur de texte et prennent désormais en charge la sélection naturelle par défaut dans iOS 26. Toutefois, si votre app accède à textView.layoutManager, elle rétablira le moteur de texte sur TextKit1, ce qui désactivera la sélection naturelle et d’autres fonctionnalités. Si vous avez besoin d’utiliser layoutManager, veuillez utiliser textView.textLayoutManager, qui est le gestionnaire de présentation pour TextKit2. Nous allons maintenant parler du concept de sens d’écriture. Pour comprendre le sens d’écriture, nous devons d’abord comprendre le sens du texte. Le sens du texte fait référence à la direction du flux de caractères dans une seule étendue continue de texte, alors que le sens d’écriture fait référence à la direction de flux de ces textes dans un paragraphe. Le sens d’écriture est déterminé par le sens de la première séquence de texte.

Par exemple, lorsque du texte LTR est écrit en premier, le sens d’écriture sera de gauche à droite. Si du texte RTL en ourdou est ensuite tapé, le texte sera affiché sur le côté droit du texte LTR, car le sens d’écriture est toujours de gauche à droite. Si davantage de texte en ourdou est ajouté, jusqu’à former une phrase, le sens d’écriture reste le même. Jusqu’ici, lorsque du texte LTR était écrit en premier, le sens d’écriture restait en LTR après la saisie de texte RTL, car il était toujours considéré comme une phrase anglaise. Cependant, le sens d’écriture sera désormais déterminé dynamiquement selon le contenu du texte. Ce qui signifie que maintenant, quand davantage de texte en ourdou sera saisi pour former une phrase, le sens d’écriture changera de droite à gauche. Cet ajustement automatique se fera dans votre app si elle utilise les vues et champs de texte fournis par Apple sur toutes les plates-formes. Mais peut-être que votre app utilise son propre moteur de texte personnalisé. Dans ce cas, consultez l’exemple de code Language Introspector montrant comment utiliser les nouvelles API pour déterminer le sens d’écriture selon le contenu du texte. Nous espérons que cette nouvelle façon de déterminer le sens d’écriture du texte bidirectionnel contribuera à améliorer encore l’expérience multilingue de votre app. Dans cette séance, nous avons parlé de certaines nouvelles fonctionnalités intéressantes qui vous aideront à améliorer vos apps pour un public multilingue. La découverte de la langue détecte automatiquement les langues préférées, ce qui rend votre app plus personnelle et naturelle. Des calendriers alternatifs supplémentaires offrent encore plus d’options de personnalisation pour améliorer l’expérience multilingue. Et avec l’introduction de la prise en charge de la sélection naturelle sous iOS et iPadOS, vos apps fonctionnent de manière fluide et cohérente sur une plus large gamme d’appareils, répondant ainsi aux besoins de votre public multilingue. J’ai vraiment hâte de vous voir créer des occasions de discuter avec votre famille et vos amis dans le monde en utilisant du texte bidirectionnel. Merci de votre attention !