Mejora la experiencia multilingüe de tu app

مرحبا! (Marhaba) Mi nombre es Omar, y hoy hablaré sobre cómo mejorar la experiencia multilingüe de tu app. Vivimos en un mundo profundamente multilingüe. Ya no se trata solo de crear apps. Estás creando experiencias que deben funcionar en cualquier lugar y para cualquier persona. Tanto si diseñas apps para el sudeste asiático, herramientas de productividad para equipos remotos en Europa o apps para el mundo árabe, el lenguaje nunca es solo texto en una pantalla. Es cultura. Es identidad. Y para millones de personas, también es la diferencia entre identificarse en un grupo o no. En iOS 26, presentamos funcionalidades nuevas que hacen que la experiencia multilingüe sea aún mejor. Y, como desarrollador, puedes aprovechar estas mejoras para crear apps más accesibles y amigables a nivel global. Repasemos algunas de estas nuevas funcionalidades. En iOS 26, los hablantes de árabe pueden usar el nuevo teclado de transliteración Arabizi. Ahora pueden escribir palabras árabes en alfabeto latino y el teclado ingresará automáticamente el alfabeto árabe. Si acostumbras a escribir en el teclado inglés o francés, esto te hará muy fácil escribir en árabe. Agregamos la capacidad de que el teclado de transliteración ofrezca sugerencias bilingües. Cuando escribes una palabra en inglés en el teclado hindi, iOS 26 sugiere automáticamente la traducción. También presentamos un nuevo teclado multiescritura bilingüe en árabe e inglés. Detectará automáticamente el idioma mientras escribes, lo que simplifica la experiencia de escribir en dos idiomas. Por último, el nuevo teclado tailandés de 24 teclas facilita la experiencia para los hablantes de tailandés. La internacionalización es un primer paso fundamental al crear apps para un público global. Con las potentes herramientas y tecnologías de Apple, es fácil preparar apps para que admitan varios idiomas, incluso antes de saber qué idiomas agregarás. Veamos prácticas clave para apps multilingües antes de ir a las nuevas herramientas y las API de internacionalización. TextKit2 facilita la compatibilidad de idiomas en la app. Maneja alfabetos complejos, como el coreano, y te ofrece más control sobre el diseño y el estilo para que el texto tenga el aspecto adecuado en cualquier idioma. TextKit2 maneja sin problemas el texto bidireccional. Más tarde, mi colega Danny presentará los avances más recientes en texto bidireccional. Los formateadores en Swift muestran fechas, números y texto adaptados automáticamente al idioma y la región. Localiza todo, como moneda y fechas, con poco código, sin necesidad de lógica personalizada para cada región. Swift tiene API que simplifican el manejo de modos de entrada, como teclados de software y hardware. Usa inputAccessoryView para colocar una vista directamente sobre el teclado o configura textInputContextIdentifier para que el teclado recuerde el último idioma y diseño usados. Mira el video del año pasado vinculado para obtener más detalles sobre TextKit, formateadores y entrada de texto. También puedes consultar el código de muestra asociado. Ahora, veamos algunas API nuevas que mejoran la experiencia multilingüe de la app. Presentaré la nueva funcionalidad Detección de idiomas. Descubre cómo admitir calendarios alternativos en la app y explora los avances en el manejo de texto bidireccional. Comencemos con Detección de idiomas. Miles de millones de personas en todo el mundo son multilingües. En muchas regiones, la mayoría de la gente usa más de un idioma en su vida cotidiana. Creemos que las mejores apps deben considerar toda la gama de la experiencia humana. Es crucial que las personas puedan interactuar con ellas en sus propios idiomas. Antes de iOS 26, las personas debían elegir idiomas agregándolos manualmente en la app Configuración. Comprendemos lo problemático que es hacerlo. Por ejemplo, mi iPhone está configurado en inglés, pero mi lengua materna es el árabe. Escucho música y podcasts en árabe. Leo noticias y envío mensajes tanto en inglés como en árabe. Aunque me gusta tener la IU del iPhone en inglés, me encantaría recibir recomendaciones en árabe. En iOS 26, Siri es personal, proactiva, y puede ofrecer sugerencias inteligentes para ayudarme a configurar el dispositivo en mis propios idiomas. Gracias a la inteligencia del dispositivo, Siri puede reconocer que, aunque configuro mi iPhone en inglés, también envío mensajes de texto, escucho y navego en árabe. Cuando toco la sugerencia de Siri, puedo cambiar al árabe, agregar un teclado bilingüe árabe-inglés y solicitar recomendaciones en mi idioma, como noticias y podcasts. Esta experiencia es útil para millones de usuarios de todo el mundo que son multilingües y a quienes les encantaría recibir contenido recomendado en sus propios idiomas. Gracias a la estructura Foundation, puedes usar Locale.preferredLanguages para obtener la lista de idiomas del usuario y personalizar la experiencia multilingüe de la app. Si conoces Locale.preferredLanguages, sabrás que devuelve un conjunto de identificadores de idioma como cadenas. Los valores de cadena se ajustan a la etiqueta de idioma BCP-47. Pero puede resultar desalentador y complejo manejar y manipular los identificadores de cadenas. Este año, presentamos Locale.preferredLocales, que devuelve un conjunto de configuraciones regionales que contiene un superconjunto de información en comparación con Locale.preferredLanguages. Una configuración regional representa tanto el idioma como la región, como inglés del Reino Unido o inglés de Canadá. En el caso de uso de mi iPhone, por ejemplo, la configuración regional sería árabe de Líbano. Las configuraciones regionales son fundamentales para que las apps se adapten a las ortografías, formatos de fecha y monedas correctos, y coincidan con las preferencias de los usuarios. Con Locale, puedes acceder al identificador basado en cadenas y elegir el formato preciso del identificador, como BCP-47, ICU o CLDR. También obtendrás acceso a muchas propiedades sobre la ubicación. Puedes obtener numberingSystem o usar las API localizedString para acceder a nombres localizados para idiomas y regiones. Puede que Locale.preferredLanguages quede obsoleto en el futuro, por lo que recomendamos usar Locale.preferredLocales. En iOS 26, usamos preferredLocales ampliamente. Por ejemplo, la app Traducir ahora puede mostrar los idiomas en la parte superior en vez de mostrar una larga lista de idiomas para seleccionar. En Calendario, cuando se configura un calendario alternativo, la app puede mostrar elementos de la IU, como días y meses, en sus idiomas. Por último, Apple Music usa preferredLocales para dar y recomendar traducciones de letras. Así, la experiencia multilingüe es aún más personalizada. Esta experiencia en Traducir se aplica a muchas apps donde las personas tienen que elegir su idioma de una larga lista de idiomas. Puedes personalizar la experiencia en tu app con la API preferredLocales y Foundation. Entremos en la app Traducir y construyamos esta experiencia juntos. Consideremos availableLocales como el conjunto de objetos de configuración regional disponibles. Usaremos matchedLocales como el conjunto que hace coincidir las preferredLocales de las personas con las availableLocales de la app. Puedes recorrer las availableLocales dentro de la app Traducir. Para cada configuración regional disponible, puedes revisar si está en sus preferredLocales. Una vez que se encuentra una coincidencia, puedes agregarla a matchLocales y poner break. Se pueden usar matchLocales para priorizar idiomas y colocarlos arriba en la lista para facilitar el acceso. Según tus preferencias, aquí puedes elegir usar ya sea isEquivalent o hasCommonParent. Detección de idiomas permite que la app se sienta más personal y natural, y elimina el paso de tener que preguntar a las personas cuál es su idioma. Los casos de uso son infinitos y estamos impacientes por ver cómo usarás preferredLocales. Ahora, hablemos de las nuevas API de calendario alternativo disponibles en Foundation. Con iOS 26, podrás seleccionar entre muchos nuevos calendarios alternativos. Por ejemplo, ahora tenemos opciones de calendario para gujarati, marathi y coreano. Estos nuevos calendarios están disponibles en todas las plataformas. Ahora, además de los 16 identificadores existentes, agregamos 11 calendarios nuevos a los que puedes acceder con Calendar.Identifier en la estructura Foundation. Hoy tenemos novedades interesantes sobre internacionalización. Ya revisamos Detección de idiomas y los nuevos identificadores de calendario. Ahora, cederé la palabra a mi colega, Danny, para que te muestre las nuevas actualizaciones del texto bidireccional. Gracias, Omar. Xin chào. Mi nombre es Danny y voy a hablar sobre los avances en texto bidireccional en iOS y iPadOS. Con estas innovaciones podrás mejorar significativamente la experiencia multilingüe en tu app. Consulta la sesión “Hazlo derecho (e izquierdo)” para obtener una comprensión completa del texto bidireccional. Primero, veamos la definición de texto bidireccional. Cuando se escribe en inglés, el texto fluye desde la izquierda y concluye en la derecha. Esta dirección de escritura se conoce como “de izquierda a derecha” o LTR. Cuando se escribe un idioma como el hebreo, el texto fluye desde la derecha y concluye en la izquierda. Esta dirección de escritura se conoce como “de derecha a izquierda” o RTL. Cuando se combinan textos LTR y RTL, el texto escrito se vuelve bidireccional, y esto repercute de forma significativa en la selección de texto. Para entender cómo funciona la selección de texto en texto bidireccional, primero debemos considerar el orden del texto que se muestra versus el que se almacena. En este ejemplo de LTR, los caracteres se almacenan en el orden en que se escriben. Los caracteres en el texto RTL también se almacenan en el orden en que se escriben, al igual que el texto LTR. Sin embargo, la diferencia radica en cómo se muestra el texto, que es de derecha a izquierda. Esto no es un problema porque aún se puede seleccionar texto invirtiendo la selección en orden descendente en el almacenamiento a medida que la selección se arrastra hacia la derecha. El resultado seguirá siendo un solo rango contiguo de texto almacenado, que es igual a la selección visual.

El problema surge cuando combinamos texto LTR y RTL. El texto todavía se almacena en su orden de escritura, pero debe adaptarse a varias direcciones al mostrarse. Al restringir la selección a un solo rango de texto en el almacenamiento, ya no se comporta de forma natural. Por ejemplo, si iniciamos la selección de texto arrastrándola de izquierda a derecha, la selección ya no se alineará con el cursor cuando cruce el límite LTR y RTL. En su lugar, comenzará a seleccionar primero el texto del lado derecho, y deja un espacio en el medio. Esto ocurre porque, aunque intentamos seleccionar el texto que se muestra, la selección se comporta como si estuviera sucediendo en el almacenamiento. Dado que el flujo de texto en la pantalla no coincide con el del almacenamiento, es imposible que la selección sea contigua en ambos simultáneamente. En iOS 26, en vez de forzar la selección a seguir el orden de almacenamiento, ahora seguirá naturalmente al cursor. En consecuencia, a medida que se arrastra el punto de selección, la selección lo sigue de cerca. A esto lo llamamos selección natural. Esta garantiza una experiencia de selección de texto consistente, independientemente de que selecciones texto unidireccional o bidireccional. Con la selección natural, la brecha de selección ya no es visible, sino que ahora está oculta en el almacenamiento de texto. Entonces, en vez de un único selectedRange, ahora se requieren múltiples selectedRanges. En macOS, NSTextView ya admite la selección natural al representarla como un conjunto de valores NSRanges. En iOS 18, UITextView tiene una única propiedad selectedRange para representar la selección que solo puede expresar un único rango contiguo. El texto bidireccional no se puede seleccionar de forma natural sin espacios visibles, porque selectedRange abarca por error el rango que en realidad no estaba seleccionado. En iOS 26, tenemos una nueva propiedad selectedRanges para representar un conjunto de NSRanges no contiguos, mientras que selectedRange quedará obsoleta. El nuevo editor de texto enriquecido de SwiftUI también admite la selección natural, donde los rangos se representan como un conjunto con un tipo de índice de cadena atribuido. Para obtener más información, consulta la charla “Crea una experiencia de texto enriquecido en SwiftUI con AttributedString”. Ahora, como ya habíamos seleccionado el texto bidireccional, ahora selectedRanges representará con precisión el texto elegido. Si la app realizó una acción que depende de selectedRange, como eliminar texto del almacenamiento TextView, podría eliminar el rango de texto incorrecto. En su lugar, debes usar selectedRanges para garantizar que solo se elimine el texto seleccionado. Además, actualizamos los protocolos UITextViewDelegate y UITextViewDelegate para aceptar un conjunto de valores que son NSRanges en lugar de un solo rango. Estos métodos se activan siempre que el sistema de entrada de texto necesita modificar el texto en los rangos especificados en respuesta a la entrada de texto. Por ejemplo, si seleccionas texto y lo pegas, se llama al método shouldChangeTextInRanges para confirmar que el texto se puede cambiar antes de que el texto eliminado se reemplace con el texto pegado. Dado que los rangos no son contiguos, existen varias ubicaciones de inserción potenciales. El sistema de entrada de texto determina la ubicación adecuada dentro de los rangos eliminados para insertar el nuevo texto en función de varios factores, incluido el teclado. Si el texto no debe insertarse en estas ubicaciones, el delegado debe devolver false. Además, hay nuevas versiones del método editMenuForTextInRange que ahora aceptan varios rangos, no solo uno, para representar con mayor precisión los rangos de texto para los que debe corresponder el menú de edición devuelto. Al cambiar a selectedRanges e implementar los nuevos métodos delegados, tus apps funcionan sin problemas con la selección natural, y se mejora el texto bidireccional. Las apps deben usar TextKit2 para maximizar los beneficios de la selección natural. UITextView y UITextField ya emplean TextKit2 como su motor de texto y son compatibles con la selección natural de forma predeterminada en iOS 26. Sin embargo, si tu app accede a textView.layoutManager, revertirá el motor de texto a TextKit1, lo que deshabilita la selección natural y otras funcionalidades. Si necesitas usar layoutManager, usa textView.textLayoutManager, que es el administrador de diseño para TextKit2. A continuación, discutiremos el concepto de dirección de escritura. Para entender la dirección de la escritura, primero debemos entender la dirección del texto. La dirección del texto es la dirección del flujo de caracteres en un único fragmento continuo de texto. La dirección de escritura es la dirección del flujo de esos textos dentro de un párrafo. La dirección de escritura está determinada por la dirección del primer fragmento de texto.

Por ejemplo, cuando se escribe primero un LTR, la dirección de escritura será de izquierda a derecha. Si después se escribe un texto RTL, como el urdu, el texto se mostrará en el lado derecho del texto LTR porque la dirección de escritura sigue siendo de izquierda a derecha. Incluso a medida que se escribe más texto en urdu, creando una oración, la dirección de escritura es la misma. Este año, al escribir primero de izquierda a derecha, la dirección de escritura permanece así después de escribir el texto de derecha a izquierda porque se considera una oración en inglés. Pero la dirección de escritura ahora se determinará de forma dinámica en función del contenido del texto. Lo que significa que este año, a medida que se escriba más texto en urdu para formar una oración, la dirección de escritura cambiará de derecha a izquierda. Este ajuste automático se produce dentro de la app si usas vistas de texto y campos de texto proporcionados por Apple en todas las plataformas. Pero tal vez tu app no use las vistas de texto de Apple, sino que usa su propio motor de texto personalizado. Si es así, consulta el código de muestra de Language Introspector para aprender a usar nuevas API y determinar la dirección de escritura según el texto dentro de la app. Esperamos que esta nueva forma de determinar la dirección de escritura para texto bidireccional ayude a mejorar aún más la experiencia multilingüe de tu app. En esta sesión, repasamos las nuevas funcionalidades que mejoran las apps para un público multilingüe. Tu app se sentirá más personal y natural con Detección de idiomas, que detecta automáticamente los idiomas preferidos. Los calendarios alternativos adicionales ofrecen aún más opciones de personalización para mejorar la experiencia. Con la compatibilidad con Selección natural en iOS y iPadOS, tus apps ahora funcionan de forma fluida y consistente en más dispositivos, para un público multilingüe. Espero que puedas crear oportunidades para chatear con personas de todo el mundo con el texto bidireccional. Gracias por acompañarnos.