Melhore a experiência multilíngue do seu app

مرحبا! (Marhaba) Meu nome é Omar. Estou empolgado para falar sobre como aprimorar a experiência multilíngue do seu app. Vivemos em um mundo multilíngue. Você não está apenas criando apps. Está criando experiências que devem funcionar para qualquer pessoa e lugar. Seja criando um app para redes sociais em Singapura e no Sudeste Asiático, uma ferramenta de produtividade para equipes remotas em Londres e no restante da Europa ou criando apps para Beirute e o mundo árabe, o idioma não é apenas texto na tela. É cultura. É identidade. Para milhões de pessoas, é também a diferença entre se sentirem incluídas ou deixadas de lado. No iOS 26, estamos apresentando recursos novos que tornam a experiência multilíngue ainda melhor. Como desenvolvedor, você pode aproveitar essas melhorias para criar apps mais acessíveis e globais. Vamos ver alguns desses novos recursos. No iOS 26, falantes de árabe podem usar o novo teclado de transliteração Arabizi. Agora eles podem digitar palavras em árabe usando o alfabeto latino, e o teclado automaticamente converte para o script árabe. Se você tem costume de digitar no teclado em inglês ou francês, é muito fácil digitar em árabe. Também adicionamos a capacidade do teclado de transliteração de oferecer sugestões bilíngues. Quando você digita uma palavra em inglês no teclado hindi, o iOS 26 sugere automaticamente a tradução dela. Também estamos lançando um novo teclado bilíngue multialfabeto para árabe e inglês. Se você fala árabe e inglês, o teclado detecta automaticamente o idioma enquanto você digita, simplificando a experiência de digitação nos dois idiomas. Por fim, temos um novo teclado tailandês com um layout de 24 teclas que facilita a experiência para falantes de tailandês. A internacionalização é fundamental na criação de apps para um público global. Com as ferramentas e tecnologias avançadas da Apple, incluindo Xcode, APIs Foundation e suporte a Unicode, é fácil preparar seus apps para dar suporte a vários idiomas, mesmo antes de você saber quais. Antes de falar sobre as novas ferramentas e APIs para internacionalização, vou compartilhar práticas recomendadas sobre como preparar seu app para ser multilíngue. O TextKit2 facilita o suporte a múltiplos idiomas no seu app. Ele lida com scripts complexos como coreano ou hindi e oferece mais controle sobre o layout e o estilo, para que seu texto fique perfeito, não importa o idioma. O TextKit2 gerencia texto bidirecional. Depois, meu colega Danny vai apresentar os avanços mais recentes para texto bidirecional. Os formatadores no Swift ajudam a exibir datas, números e textos de uma forma que se adapta ao idioma e à região de cada pessoa. Com poucas linhas de código, você pode localizar de moedas a formatos de data, sem escrever lógica personalizada para cada localidade. Há muitas APIs no Swift que simplificam a experiência de gerenciar diferentes modos de entrada, como teclados de software e de hardware. Por exemplo, você pode usar inputAccessoryView para colocar uma visualização acima teclado ou definir textInputContextIdentifier para ajudar o teclado a lembrar o último idioma e layout usados. Para saber mais sobre TextKit, formatadores e entrada de texto, confira o vídeo do ano passado no link abaixo. Você também pode conferir o código de exemplo associado. Vamos falar sobre a novas APIs que melhoram a experiência multilíngue do seu app. Veremos um novo recurso: descoberta de idioma. Saiba como dar suporte a calendários alternativos no seu app e explore os avanços no tratamento de texto bidirecional. Vamos começar com a descoberta de idiomas. Bilhões de pessoas no mundo são multilíngues. Em muitas regiões, a maioria das pessoas usa mais de um idioma no dia a dia. Ótimos apps precisam considerar toda a gama da experiência humana. É essencial que as pessoas possam interagir entre elas em seus próprios idiomas. Antes do iOS 26, o único jeito de escolher os idiomas era adicionando-os manualmente no app Ajustes. Sabemos como isso pode ser desafiador. Por exemplo, meu iPhone está configurado como inglês, mas meu idioma nativo é o árabe. Ouço música e podcasts em árabe. Leio as notícias e envio mensagens em inglês e em árabe. Mesmo que eu queira a interface do meu iPhone em inglês, eu adoraria receber recomendações de notícias, músicas e podcasts em árabe. No iOS 26, a Siri está pessoal, proativa e oferece sugestões inteligentes para ajudar a configurar meu dispositivo nos meus idiomas. Usando a inteligência do dispositivo, a Siri pode reconhecer que, embora meu iPhone esteja em inglês, também envio textos, ouço e navego em árabe. Então, ao tocar na sugestão da Siri, posso mudar o idioma do iPhone para árabe, adicionar um teclado bilíngue árabe-inglês e solicitar recomendações de conteúdo, como notícias, músicas e podcasts no meu idioma. Essa experiência vale para milhões de usuários multilíngues no mundo todo que adorariam receber recomendações de conteúdo em seus idiomas. Graças ao framework Foundation, você pode usar Locale.preferredLanguages para obter a lista de idiomas do usuário e personalizar a experiência multilíngue do seu app. Se você conhece Locale.preferredLanguages, sabe que ele retorna uma gama de identificadores de idioma como Strings. Esses valores String seguem a tag de idioma BCP-47. Entretanto, pode ser assustador e complexo lidar e manipular esses identificadores baseados em String. Este ano, estamos lançando Locale.preferredLocales, que retorna uma matriz de Locales contendo um superconjunto de informações em comparação com Locale.preferredLanguages. Uma localidade representa o idioma e a região, como inglês do Reino Unido ou inglês do Canadá. No meu iPhone, por exemplo, a localidade é árabe do Líbano. Usar Locales é essencial para que seus apps se adaptem a grafias corretas, formatos de data e moedas, para corresponder melhor às preferências dos usuários e personalizar a experiência. Com Locale, você ainda pode acessar o identificador baseado em String, se desejar, e escolher o formato exato do identificador, como BCP-47, ICU ou CLDR. Você também tem acesso a uma ampla variedade de propriedades sobre o Locale. Por exemplo, você pode obter numberingSystem ou usar as APIs localizedString para acessar nomes localizados de idiomas e regiões. Locale.preferredLanguages pode ser descontinuado, por isso, recomendamos que você migre para Locale.preferredLocales. No iOS 26, estamos usando preferredLocales. Por exemplo, o app Traduzir pode mostrar os idiomas das pessoas no topo, em vez de exibir uma longa lista de idiomas para selecionar. No Calendário, quando um calendário alternativo é configurado, o app pode mostrar elementos da interface, como dias e meses, em cada idioma. Por fim, o Apple Music usa preferredLocales para recomendar e oferecer traduções de letras. Isso personaliza ainda mais a experiência multilíngue. Essa experiência no app Traduzir se aplica a muitos apps em que as pessoas precisam escolher seus idiomas em uma longa lista. Você pode personalizar a experiência no seu app usando a API preferredLocales e o Foundation.

Vamos entrar no app Traduzir e criar essa experiência em conjunto. Considere availableLocales como a matriz dos objetos Locale disponíveis no seu app. Usaremos matchedLocales como a matriz que relaciona os preferredLocales das pessoas com os availableLocales do app. Você pode então percorrer a matriz availableLocales do app Traduzir. Para cada Locale disponível, verifique se esse Locale está em preferredLocales do usuário. Assim que encontrar uma correspondência, adicione-a a matchLocales e pare. matchLocales podem ser usados para priorizar os idiomas e colocá-los no topo da lista para acesso fácil. Você pode escolher usar isEquivalent ou hasCommonParent, conforme sua preferência. A descoberta de idioma torna seu app mais pessoal e natural, eliminando a necessidade de perguntar o idioma ao usuário. Os casos de uso são infinitos, e queremos ver como você usará preferredLocales no seu app. Vamos falar sobre as novas APIs de calendário alternativo disponíveis no Foundation. Com o iOS 26, você pode escolher entre vários calendários alternativos. Por exemplo, agora temos opções de calendários alternativos para gujarati, marathi e coreano. Esses calendários estão disponíveis em todas as plataformas. Agora, além dos 16 identificadores de calendário, adicionamos 11 novos calendários que você pode acessar usando Calendar.Identifier no framework Foundation. Temos novidades empolgantes sobre internacionalização. Falamos da descoberta de idioma e dos novos identificadores de calendário. Agora, vou passar a palavra para meu colega Danny, que vai apresentar as novidades sobre texto bidirecional. Obrigado, Omar. Xin chào. Meu nome é Danny. Estou animado para falar sobre os avanços no texto bidirecional no iOS e iPadOS. Essas inovações têm o potencial de melhorar significativamente a experiência multilíngue no seu app. Para compreender o texto bidirecional, consulte a sessão "Ir da direita (para a esquerda)". Para começar, vamos rever a definição de texto bidirecional. Ao escrever em inglês, o texto flui da esquerda para a direita. Essa direção de escrita é da esquerda para a direita, ou LTR. Ao escrever em hebraico, o texto flui da direita para a esquerda. Essa direção de escrita é da direita para a esquerda, ou RTL. Quando textos LTR e RTL são combinados, o texto escrito se torna bidirecional, o que tem implicações significativas para a seleção de texto. Para entender como a seleção de texto funciona em textos bidirecionais, vamos considerar a ordem do texto exibido versus a ordem do texto armazenado. Neste exemplo LTR, os caracteres são armazenados na ordem em que são escritos. Os caracteres em texto RTL também são armazenados na ordem em que são escritos. A diferença está em como o texto é exibido, que é da direita para a esquerda. Isso não causa problemas, pois o texto ainda pode ser selecionado invertendo o método de seleção para selecionar em ordem decrescente no armazenamento, conforme a seleção é arrastada para a direita. Isso resulta em um intervalo contíguo de texto no armazenamento que corresponde ao que está visualmente selecionado. O problema surge quando combinamos textos LTR e RTL. O texto ainda é armazenado na mesma ordem em que é escrito, mas agora deve acomodar múltiplas direções ao ser exibido. Ao restringir a seleção a um intervalo de texto no armazenamento, a seleção de texto não funcionará de modo natural. Por exemplo, se iniciarmos a seleção de texto arrastando da esquerda para a direita, a seleção não ficará alinhada com o cursor ao atravessar o limite entre LTR e RTL. Em vez disso, começará a selecionar o texto do lado direito, deixando uma lacuna estranha no meio da seleção. Apesar da intenção de selecionar o texto exibido, a seleção se comporta como se estivesse acontecendo no armazenamento. Como o fluxo do texto na tela não corresponde ao fluxo do texto no armazenamento, não é possível que a seleção seja contínua na tela e no armazenamento ao mesmo tempo. No iOS 26, em vez de forçar a seleção a seguir a ordem do armazenamento, agora permitimos que a seleção siga naturalmente o cursor. À medida que o ponto de seleção é arrastado, a seleção acompanha de perto o movimento. Chamamos isso de Seleção Natural. A Seleção Natural garante uma experiência de seleção de texto fluida e consistente, seja ao selecionar texto em uma única direção ou texto bidirecional. Com a Seleção Natural, a lacuna na seleção não é mais visível, ficando agora oculta no armazenamento do texto. Em vez de um único selectedRange, agora são necessários múltiplos selectedRanges. No macOS, NSTextView já aceita a Seleção Natural representando a seleção como uma matriz de valores que são NSRanges. No iOS 18, a UITextView tem uma propriedade selectedRange única para representar a seleção, que só pode expressar um intervalo contíguo. Isso significa que, no iOS 18, o texto bidirecional não pode ser selecionado de modo natural e sem lacunas visíveis, pois selectedRange acaba incluindo um intervalo que não foi selecionado. No iOS 26, há uma nova propriedade selectedRanges para representar uma matriz de NSRanges não contíguos, enquanto a propriedade única selectedRange será descontinuada em uma versão futura. O novo editor de texto com formatação da SwiftUI aceita Seleção Natural com intervalos representados como conjuntos de índices de strings atribuídos. Para saber mais, confira a apresentação "Criar uma experiência com texto avançado na SwiftUI com o AttributedString". Agora, como selecionamos anteriormente o texto bidirecional, selectedRanges representarão com precisão o texto escolhido. Se seu app estiver executando uma ação que depende do selectedRange, como excluir texto do armazenamento da textView, ele pode excluir por engano um intervalo incorreto de texto. Em vez disso, você deve usar selectedRanges para garantir que apenas o texto selecionado seja apagado. Além disso, atualizamos os protocolos UITextViewDelegate e UITextViewDelegate para aceitar uma matriz de valores do tipo NSRange, em vez de um único intervalo. Esses métodos são chamados quando o sistema de texto de entrada precisa alterar o texto nos intervalos específicos devido à entrada de texto. Por exemplo, ao selecionar um texto e colar em textView, o método shouldChangeTextInRanges será chamado para confirmar com o delegate se o texto pode ser alterado nos intervalos especificados antes que o texto apagado seja substituído pelo texto colado. Como os intervalos não são contíguos, há vários locais possíveis para inserção. O sistema de entrada de texto determina o local apropriado nos intervalos apagados para inserir o novo texto com base em vários fatores, incluindo o teclado em uso. Se o texto não deve ser inserido em nenhum desses locais, o delegate deve retornar false. E há novas versões do método editMenuForTextInRange que agora aceitam uma matriz de intervalos, em vez de um único intervalo, para representar com mais precisão os intervalos de texto aos quais o menu de edição retornado deve corresponder. Ao adotar o uso de selectedRanges e implementar os novos métodos de delegate, você garante que seus apps funcionem perfeitamente com a Seleção Natural, aprimorando a experiência com texto bidirecional. Para aproveitar os benefícios da Seleção Natural, seus apps devem utilizar o TextKit2. UITextView e UITextField já usam TextKit2 como mecanismo de texto e agora oferecem suporte à Seleção Natural por padrão no iOS 26. Entretanto, se seu app acessar textView.layoutManager, o mecanismo de texto será revertido para TextKit1, desativando a Seleção Natural e outros recursos. Se você precisar usar layoutManager, use textView.textLayoutManager, que é o gerenciador de layout do TextKit2. A seguir, vamos discutir o conceito de direção da escrita. Para entender a direção da escrita, precisamos compreender a direção do texto. Direção do texto refere-se ao fluxo dos caracteres dentro de um trecho contínuo de texto, enquanto direção da escrita refere-se ao fluxo desses textos dentro de um parágrafo. A direção da escrita é determinada pela direção do primeiro trecho de texto.

Quando o texto LTR é escrito primeiro, a direção da escrita será da esquerda para a direita. Se um texto RTL, como o urdu, for digitado em seguida, ele será exibido à direita do texto LTR porque a direção da escrita ainda é da esquerda para a direita. Mesmo digitando mais texto em urdu, formando uma frase em urdu, a direção da escrita permanece a mesma. Este ano, quando um texto LTR é escrito primeiro, a direção da escrita permanece LTR mesmo depois que um texto RTL é digitado, porque ainda é considerado uma frase em inglês. No entanto, a direção da escrita agora será determinada com base no conteúdo do texto, ou seja, à medida que mais texto em urdu for digitado para formar uma frase em urdu, a direção da escrita mudará da direita para a esquerda. Esse ajuste automático acontecerá dentro do app se ele usar textViews e textFields fornecidos pela Apple em todas as plataformas. Mas talvez seu app não use textViews fornecidas pela Apple, e sim seu próprio mecanismo de texto personalizado. Se for o caso, consulte o código de exemplo do Language Introspector para aprender a usar as novas APIs que determinam a direção da escrita com base no conteúdo do texto do seu app. Esperamos que essa nova forma de determinar a direção da escrita para texto bidirecional eleve ainda mais a experiência multilíngue do seu app. Nesta sessão, falamos sobre alguns novos recursos que ajudam a melhorar seus apps para um público multilíngue. A descoberta de idiomas detecta automaticamente as línguas de preferência, tornando seu app mais pessoal e natural. Calendários alternativos adicionais oferecem mais opções de personalização para aprimorar a experiência multilíngue. Com a introdução do suporte à Seleção Natural no iOS e iPadOS, seus apps agora funcionam de maneira fluida e consistente em mais dispositivos, atendendo ao público multilíngue. Estou ansioso para ver vocês criando oportunidades para conversar com amigos e familiares ao redor do mundo usando texto bidirecional. Agradecemos sua participação.