提升 App 的多语言体验

你好！ 我叫 Omar 今天非常荣幸 能和大家探讨 如何提升 App 的多语言体验 我们生活在一个多语言的世界 你构建的已不仅是 App 更是要为全球用户 打造随处可享的卓越体验 无论你是在为新加坡 和东南亚用户设计社交 App 为伦敦及欧洲各地的 远程团队开发生产力工具 还是为贝鲁特 和阿拉伯世界构建 App 语言从来都不只是 屏幕上的文字 它是文化的载体 是身份的象征 对数以百万计的用户而言 它更决定着他们感受到的是 归属感还是被排除在外 在 iOS 26 中 我们推出了多项全新功能 打造更加出色的多语言体验 作为开发者 你可以充分利用这些改进 打造更具包容性、 更全球化的 App 下面让我们一起来看看 这些新功能 iOS 26 为阿拉伯语用户推出了 全新的 Arabizi 音译键盘 这意味着用户现在可以 用拉丁字母输入阿拉伯语单词 键盘会自动将它们 转换为阿拉伯文字 如果你习惯使用英语或法语键盘打字 现在可以轻松地 用同样方式输入阿拉伯语了 我们还为音译键盘新增了 双语建议功能 当你在这款印地语键盘上 输入英语单词时 iOS 26 会自动提供对应的翻译建议 我们还将推出一款全新的 阿拉伯语和英语双语多文种键盘 如果你同时使用阿拉伯语和英语 键盘现在可以自动检测 你正在键入的语言 让双语输入体验更加流畅自如 最后 我们还有一款全新的 24 键布局的泰语键盘 为泰语用户带来更便捷的输入体验 国际化是构建全球化 App 的 首要基础步骤 借助 Apple 强大的工具和技术 包括 Xcode、Foundation API 和 Unicode 支持等 你可以轻松让 App 做好多语言适配准备 而无需预先确定 具体需要支持的语言类型 在深入探讨我们全新的 国际化工具和 API 之前 我想先分享一些基本的最佳实践 帮助你的 App 做好多语言适配准备 TextKit2 让 App 的多语言支持 变得轻而易举 无论是韩语、印地语等 复杂文字系统 还是布局样式微调 它都能确保你的文本 在任何语言环境下完美呈现 TextKit2 能无缝处理双向文本问题 稍后我的同事 Danny 将为大家介绍 双向文本技术的最新进展 Swift 中的格式化程序能自动适配 用户的语言和地区设置 智能显示日期、数字和文本内容 仅需几行代码 即可完成 从货币符号到日期格式的全套本地化 无需为每个区域单独编写逻辑 Swift 中有许多 API 可以简化 各类输入模式的管理 无论是软件键盘还是 硬件键盘都能轻松应对 例如 你可以使用 inputAccessoryView 在键盘正上方直接放置视图控件 或设置 textInputContextIdentifier 来帮助键盘自动记忆 上次使用的语言和布局方案 如需详细了解 TextKit、 格式化程序和文本输入 请观看下面链接里去年的视频 也可查阅配套示例代码 现在 让我们深入了解一些 能增强 App 多语言体验的 全新 API 我们将介绍一项新功能 即语言发现功能 了解如何在 App 中支持其他历法 并探索双向文本处理技术的最新进展 我们先来了解一下语言发现功能 全球有数十亿用户使用多种语言 在许多地区 大多数人在日常生活中 都会使用一种以上的语言 我们认为 优秀的 App 需充分考虑 人类体验的多样性 让用户能够使用自己的语言 与 App 交互至关重要 在 iOS 26 之前 用户选择语言的唯一方式是 通过设置 App 手动添加 我们深知这一操作有多麻烦 例如 我的 iPhone 系统语言设置为英语 但我的母语其实是阿拉伯语 我会听阿拉伯语的音乐和播客 同时使用英语和阿拉伯语 阅读新闻、发送消息 因此 虽然我希望 保持 iPhone 界面为英文界面 但更希望能获得阿拉伯语的 新闻、音乐和播客推荐内容 在 iOS 26 中 Siri 变得更加 个性化和主动 能够提供智能建议 帮助用户以母语设置设备 通过设备端智能技术 Siri 可以识别到 即使我将 iPhone 设置为英文界面 我仍会用阿拉伯语 发短信、听音乐和浏览网页 所以当我轻点 Siri 的建议时 我可以选择将 iPhone 系统语言 切换为阿拉伯语 添加阿拉伯语-英语双语键盘 并要求获取阿拉伯语的 新闻、音乐和播客等内容推荐 这一功能将惠及 全球数百万多语言使用者 让他们能够获得母语内容推荐 得益于 Foundation 框架 你可以 通过 Locale.preferredLanguages 获取用户的语言列表 为 App 打造个性化的多语言体验 如果你熟悉 Locale.preferredLanguages 你会知道这个属性会返回一个 由字符串组成的语言标识符数组 这些字符串值遵循 BCP-47 语言标签规范 但处理这些基于字符串的标识符 可能会相当复杂且令人困扰 今年 我们推出了 Locale.preferredLocales 属性 它返回的是一个 Locale 对象数组而非字符串数组 相比 Locale.preferredLanguages 能提供更全面的信息集 Locale 对象同时包含 语言和地区信息 例如“英语(英国)” 或“英语 (加拿大)” 以我的 iPhone 使用场景为例 Locale 为“阿拉伯语 (黎巴嫩)” 使用 Locale 对象对 App 至关重要 它能帮助你的 App 适配 正确的拼写规则、日期格式和货币 从而更精准地匹配用户偏好 提供更个性化的体验 通过 Locale 对象 你仍然可以 按需获取基于字符串的标识符 并能自由选择标识符的具体格式 如 BCP-47、ICU 或 CLDR 你还能访问 Locale 对象 丰富的属性集 例如 你可以通过 numberingSystem 或使用 localizedString API 获取语言和地区的本地化名称 Locale.preferredLanguages 未来可能被弃用 建议你尽快迁移至 Locale.preferredLocales 在 iOS 26 中 我们广泛使用了 preferredLocales 功能 例如 翻译 App 现在可以 将用户的语言显示在顶部 而无需再展示一长串待选语言列表 在日历 App 中 当用户设置了其他历法时 App 界面现在能够以对应语言 显示日期和月份等元素 最后值得一提的是 Apple Music 通过 preferredLocales 实现了歌词推荐与翻译功能 这使得多语言体验变得更加个性化 翻译 App 中的这种体验 同样适用于众多 需要用户从冗长语言列表中 进行选择的 App 你可以通过 preferredLocales API 和 Foundation 框架 来个性化你的 App 体验

让我们以翻译 App 为例 一起打造这种体验 假设 availableLocales 是 App 支持的 locale 对象的数组 而 matchedLocales 则是 用户 preferredLocales 与 App availableLocales 匹配后的数组 然后 你可以循环遍历 翻译 App 的 availableLocales 你可以检查每个可用的语言选项 是否在用户的 preferredLocales 列表中 一旦找到匹配项 就将它加入 matchedLocales 并终止查找 随后可以利用 matchedLocales 对这些语言进行优先排序 将它们置顶显示以便快速访问 根据你的偏好 这里可以选择调用 isEquivalent 或 hasCommonParent 语言发现功能可让你的 App 体验更加个性化、自然流畅 同时省去了手动选择语言的繁琐步骤 这一技术的应用场景非常广泛 我们期待看到你如何在 App 中 运用 preferredLocales 这一功能 现在 让我们来聊聊 Foundation 框架中 新增的其他历法 API 在 iOS 26 中 你可以 从众多新增的其他历法中进行选择 例如 我们现在为古吉拉特语、 马拉地语和韩语 提供了其他历法选项 这些新历法在所有平台上均可使用 现在 除了现有的 16 种 日历标识符外 我们还新增了 11 种日历 你可以通过 Foundation 框架中的 Calendar.Identifier 来访问它们 今天我们为大家带来了 一系列令人振奋的国际化功能更新 我们已经探讨了语言发现功能 和全新的日历标识符系统 现在 我想请我的同事 Danny 为大家详细介绍 双向文本方面的突破性进展 谢谢 Omar 大家好 我是 Danny 非常荣幸能和大家探讨 iOS 和 iPadOS 在双向文本支持 方面取得的最新进展 这些创新将显著提升 你 App 中的多语言用户体验 如需全面了解双向文本技术 请参考“向左语言”讲座 首先 让我们回顾一下 双向文本的定义 书写英语时 文字从左向右排列 我们称之为“从左到右”(LTR) 书写方向 而书写希伯来语等语言时 文字则从右向左排列 这种书写方向被称为 “从右到左”(RTL) 当 LTR 和 RTL 文本混合时 就形成了双向文本 这对文本选择功能有重要影响 要理解双向文本中的选择机制 我们首先需要区分 文本的显示顺序和存储顺序 在这个 LTR 示例中 字符的存储顺序 与书写顺序完全一致 而 RTL 文本中的字符 同样按照书写顺序存储 这点与 LTR 文本相同 但关键区别在于显示方式 RTL 文本会从右向左显示 这种机制本身不会造成直接问题 因为当用户向右拖动选择时 系统只需将选择方法翻转 即可在存储层面 按相反的顺序选取字符 这样仍能确保最终选中的文本 在存储中保持连续 并与视觉上的选择范围精确对应 在混合使用 LTR 和 RTL 文本时就会出现问题 虽然文本存储顺序 仍与书写顺序一致 但在显示时却需要适应多种方向 若将文本选择限制为 存储中的单一连续范围 文本选取行为将 不再符合自然操作习惯 例如 当我们从左向右 拖动选取文本时 选区在跨越 LTR 和 RTL 边界时 将不再与光标移动保持同步 相反 系统会优先选中右侧的文本 导致选区中间出现不连贯的断裂 这种现象的根源在于 虽然用户 意图选取的是屏幕上显示的文本 但实际选区操作 却基于文本的存储顺序 由于屏幕上的文本流向 与存储时的流向不一致 选区内容无法同时在视觉呈现 和存储结构上保持连续 在 iOS 26 中 我们不再 强制选区遵循存储顺序 而是允许选区自然跟随光标移动 因此当拖动选取点时 选区会实时紧随其后 我们将这一机制称为“自然选择” 这项技术能确保流畅一致的 文本选取体验 无论是选择单向文本 还是双向混合文本都同样适用 在“自然选择”模式下 选取间隙不再可见 而是被隐藏在文本存储结构中 因此不再用单一的 selectedRange 而是需要多个 selectedRanges 在 macOS 系统中 NSTextView 早已支持自然选择 它通过 NSRanges 数组来表示选区 而在 iOS 18 中 UITextView 仍仅 通过单一的 selectedRange 属性 来表示选区 这只能表达一个连续的范围 这意味着在 iOS 18 中 双向文本 无法自然地选取 会出现视觉断层 因为 selectedRange 会错误地包含 实际上未被选中的 文本范围 在 iOS 26 中 我们引入了一个 名为 selectedRanges 的新属性 来表示一组非连续的 NSRanges 数组 而原有的单一 selectedRange 属性 将在未来版本中被弃用 新的 SwiftUI 富文本编辑器 同样支持自然选择功能 这个功能通过 AttributedString.Index 类型的范围集合来表示选区 更多详情 请观看 “使用 SwiftUI 和 AttributedString 精心打造富文本体验”讲座 现在 当我们选中双向文本时 selectedRanges 属性能够 精确反映实际选中的内容 如果你的 App 之前依赖 selectedRange 执行操作 比如从 TextView 存储中删除文本 就可能会错误删除非目标文本范围 因此 你应当 改用 selectedRanges 属性 这样才能确保只删除 实际选中的文本内容 此外 我们已对 UITextViewDelegate 协议进行了更新 现在可以接收 NSRanges 数组而非单一范围值 当文本输入系统需要 修改指定范围内的文本时 这些方法就会被触发 例如 当你在文本视图中 选中某段文字并执行粘贴操作时 系统会调用 shouldChangeTextInRanges 方法 向委托对象确认是否允许 在选定的多个范围内进行文本替换 之后才会用粘贴内容替换已删除文本 由于这些选区范围是非连续的 因此存在多个潜在的插入位置 文本输入系统会根据多种因素 (包括当前使用的键盘类型) 来确定在已删除范围内 插入新文本的合适位置 如果文本不应插入到任何这些位置 委托对象应返回 false 此外 editMenuForTextInRange 方法现已推出新版本 可接受范围数组而非单一范围参数 从而更准确地表示文本选区范围 使返回的编辑菜单与选区相对应 通过改用 selectedRanges 并实现新的委托方法 你可以确保 App 完美兼容“自然选择”功能 从而显著提升双向文本的操作体验 要充分发挥自然选择的优势 App 必须采用 TextKit2 在 iOS 26 中 UITextView 和 UITextField 已采用 TextKit2 作为文本引擎 并默认支持“自然选择”功能 但若 App 直接访问 textView.layoutManager 属性 将导致文本引擎回退至 TextKit1 从而禁用“自然选择”等功能 如需使用 layoutManager 请改用 textView.textLayoutManager 这是 TextKit2 专用的布局管理器 接下来我们将探讨书写方向的概念 要理解书写方向 首先需要理解文本方向 文本方向是指连续单段文本中 字符的排列流向 而书写方向是指这些文本 在段落层级中的整体流向 书写方向由首段文本的流向决定

例如 当先输入 LTR 文本时 书写方向为从左到右 此时若继续输入乌尔都语 等 RTL 文本 新文本会显示在 原有 LTR 文本的右侧 因为整体书写方向 仍被识别为从左到右 即使连续输入更多乌尔都语 形成完整句子 书写方向依然不会改变 今年 当初始文本为从左到右书写时 即便后续插入从右到左文本 系统仍会将它视为英语句子 而维持从左到右的书写方向 然而 现在书写方向 将根据文本内容动态判定 也就是说今年 当连续输入乌尔都语形成完整句子时 书写方向会自动切换为从右到左 如果你的 App 在所有平台上都使用 Apple 提供的文本视图和文本字段 这一自动调节功能将会生效 但若你的 App 未采用 Apple 提供的文本视图 而是使用自定义文本引擎 请参考 Language Introspector 示例代码 了解如何通过新 API 在 App 内 实现基于文本内容的书写方向判定 我们希望这种双向文本 书写方向的全新判定方式 能进一步提升你 App 的多语言体验 在本讲座中 我们探讨了 一些令人振奋的新功能 它们能帮助你为多语言用户优化 App 语言发现功能可自动 检测用户偏好语言 让 App 体验更个性、更自然 新增的其他历法提供更多自定义选项 进一步优化多语言场景下的使用体验 随着 iOS 和 iPadOS 对 自然选择功能的支持 你的 App 现在能够 在更广泛的设备上 实现无缝且一致的运行体验 以更好地满足多语言用户群体的需求 万分期待你能借这个机会 运用双向文本功能 与全球各地的亲友畅所欲言 感谢观看