揭秘语法一致性的本质

♪ ♪

Alla：大家好 我叫 Alla Shashkina 是 Internationalization 团队的 一名工程师 我来帮你处理语言相关的问题 今天 我们将 揭秘语法一致性的本质 软件中的语言 对我们与其交互的日常产生影响 你 App 中的文字至关重要 在软件中处理语言可能很困难 尤其是当你不懂该语言时 2021 年 我们在 Foundation 中 引入了新的 API 帮助你的 App 实现语法一致性 今天 我想为你介绍 Foundation 中的新功能 通过更准确、更动听 和更具包容性的自然语言 让你的 App 为用户 提供更高水平的使用体验 那么 让我们来深入探讨一下

首先 我们简要回顾为什么我们认为 处理语法一致性很重要 我们将为你展示自 2021 年以来 我们为语言添加支持的不同示例 我们将讨论 语法一致性领域的新 API 并引入依赖一致性 我们进一步思考并问自己： 如何使你 App 中的语言 不仅语法正确 而且更具包容性 语法不应成为 你构建 App 时的负担 我们相信设计良好的 API 可以简化语言复杂性 并帮助你扩展规模 UI 中丰富且语法正确的词汇 使用户体验流畅且愉悦 对于不同的语言 我们要考虑和应对不同的挑战 当我们设计新的 API 时 我们要考虑所有这些语言的复杂性 我们的目标是将所有这些内容 打包到简单易用的界面中 让我们简要回顾一下 语法一致性如何增强 不同语言环境下的用户体验 在 2021 年推出的新 API 允许你指定一系列词汇 这些词汇 需要根据用户首选的称呼方式 在可变化范围内的 其他单词进行更改 如果用户选择了女性称呼 在设置首次使用手机时 iPhone 将会 以西班牙语的女性称呼问候她 去年 除了西班牙语 还有三种语言也有这个特性 使用法语的用户在选择称呼时 可以享受更个性化的体验 系统中的软件会相应更改单词 就像备忘录 App 中的 这个例子一样 个性化的字符串 在整个系统体验中普遍存在 设置手机、使用共享备忘录 或管理日历等 语言会根据你的设置进行适应 就像这里 在意大利语或巴西葡萄牙语中一样

今年 我们将 语法一致性的支持 引入到两个新的语言环境： 欧洲葡萄牙语和德语 现在让我们来看看 今年 Foundation 中的 语法一致性有什么新变化 语言是复杂的 但好的 API 并非如此 在 UI 中 很多时候单词需要 根据其他单词的变化而改变形式 为了帮助你更直观地理解 我将通过 食品订购 App 的示例来向你介绍 这是西班牙语 在西班牙语中 形容词 需要与其所描述的名词保持一致 在这里 食物尺寸“pequeño” 需要与其描述的食物 “ensalada”保持一致 这在其他语言中 也是非常常见的用例 即单词一致性 发生在特定的词类之间 由于这些单词在 UI 上是分开的 处理这种一致性并不容易 我们创建了一个新的 API 可轻松 解决这种依赖关系的一致性问题 修复非常简单 只需少量的代码更改

在这里 我们希望一个包含 食物尺寸“pequeño”的字符串 与食物名“ensalada”保持一致 今年 我们在 LocalizationOptions 中 引入了一个新的属性 concepts 它允许我们 指定影响语法一致性的对象 但不像参数那样出现在字符串中 对于我们想要与之保持一致的字符串值 我们使用了 localizedPhrase 概念 在这种情况下是“ensalada” 最后 我们需要用 agreeWithConcept 来注释需要变化的单词 这里的值为 1 意味着我们 要求与概念数组中的第一个对象 进行语法一致性 请注意 我们使用基于 1 的索引 agreeWithConcept 属性 也是今年新引入的 但即使你的 App 在旧设备上运行 你也可以使用它 这种情况下 我们将简单地忽略该属性 现在我们已经介绍了这些变化 让我们来看一下我们的 UI

请注意“pequeño”一词 已经变为“pequeña” 这是在西班牙语中描述 “ensalada”的正确形式 现在让我们看看 其他需要语言增强的地方

在句子“Our salad contains lettuce, cheese, tomatoes and ham.”中 西班牙语单词 “nuestro”和“hecho”都需要 与名词“ensalada”保持一致 幸运的是 我们只需要在字符串内部 进行语法一致性的处理 因此不需要进行任何代码更改 首先 让我们用 inflect 属性对其进行注释 使“nuestro”与食物保持一致 当我们在具有参数的块上 使用 inflect 属性时 它将尝试使每个单词 在语法上与参数保持一致 然而 我们还需要对 另一个词进行变形 即“hecho” 我们尽量将词形变化 代码块保持简短 以帮助消除歧义 因此我们无法在“hecho”上 使用 inflect: true 进行注释 今年 我们引入了另一个 新属性 称为 agreeWithArgument

与 agreeWithConcept 不同 在 agreeWithConcept 中 你需要通过传递食品名称的值 对代码进行更改 agreeWithArgument 属性 不需要进行任何代码更改 并且非常方便 它可以促成 inflect 属性无法实现的一致性 我们可以使用 agreeWithArgument 来指示“hecho”应与 字符串中的其他位置的参数一致 这里 值为 1 表示我们希望该词 与字符串中的第一个参数一致 在进行了这些更改后 让我们再次查看 UI

现在 两个词的语法格式 都和“ensalada”保持一致 我们在本地化中 使用了完全正确的西班牙语 接下来 让我们看一个 类似但有所不同的示例

这是法语 在法语中 指示形容词 需要与其描述的名词一致 请注意 由于我们应用了 agreeWithConcept 和 inflect 属性 所以在西班牙语中 带有尺寸和数量的按钮 已经修复好了 现在让我们来修复 法语中指示代词不匹配的情况 修复非常简单 将形容词和参数 都放入 inflect: true 块中 然后让引擎自动处理 好了 语法正确的食物更美味 回顾一下 依赖一致性使得 它们可以根据所依赖的词进行更改 当你希望某个词与不存在于 同一句子中的其他词一致时 请使用 agreeWithConcept 属性 在希望某个词与 另一个词或短语一致的情况下 请使用 agreeWithArgument 属性 而且它们都在同一个字符串中

现在让我们谈谈 关于包容性语言的新 API 让我们再次看一下 我们的 Caffé App

假设我们选择了一个小三明治 和一杯小果汁作为午餐并下单 因为我们非常饿 所以我们想要查询订单的状态 看起来 Tony 快要送我们的订单了 在本地化 UI 时 使用中性语言是一种良好的实践 同时 在 UI 中 使用具有性别的语言 让人感觉更个性化 听起来也更自然 让我们尝试为 Tony 这个字符串进行个性化 使用代词 he/him

首先 我们需要更改送货人的模型 以包含他们的首选称谓 为此 我们添加了一个今年新引入的 名为 TermOfAddress 的新属性 然后 我们可以将称谓设置为 男性、女性或中性中的任意一种 由于我们希望使用 he/him 来指代 Tony 我们选择男性

接下来 我们需要对 需要更改代词的字符串进行注释 为此 我们使用了 新的 referentConcept 属性

值为 1 表示代词的指代对象 应为 LocalizationOptions 中的 第一个概念 我们可以将 referentConcept 应用于任何第三人称人称代词 引擎会自动决定替换内容 现在让我们在对字符串进行 变形时传递 termsOfAddress 概念 我们将其分配给 LocalizationOptions 的 concepts 属性 就像我们之前 对语法一致性所做的那样 让我们看看这如何改变英文 UI

请注意 “their”和“they” 已被“his”和“he”替换 你可以使用 同一本地化字符串指代其他人 当你希望使用 she 和 her 代词指代某人时 请使用女性称谓 当你希望使用 they 和 them 代词指代某人时 请使用中性称谓 你还可以通过使用 本地化称谓来进一步个性化代词 在本地化的称谓中 你必须指定 适用的语言 例如英语 并使用新的 Morphology.Pronoun 类型 列出所有要使用的代词形式 在英语中 我们需要列出 5 个代词

每个代词都由目标语言中的代词形式 和描述何时使用的语态学信息组成 请参考我们的文档以获取 关于构建代词的详细指导说明 使用此 API 可以增强 App 的个性化 我们在 iOS 的本地化字符串中 使用这种技术 现在让我展示 这些新功能在演示中的实际效果 希望大家现在 对我们 Caffè App 的美食充满了食欲 让我用西班牙语开始吧

我们来看看菜单上有什么

这次我们点一个披萨

这里有我们刚才 讨论过的同样的语法问题 在西班牙语中 冠词和形容词需要与名词一致 为了使两个词相互一致 我们可以使用 inflect: true 属性 让我们对“nuestro”和“pizza” 这两个词应用这个简单的修正 首先 在我们的 字符串目录中找到这个字符串

为了使“nuestro”与“pizza”一致 我们将它们都放入 inflect: true 块中

接下来 我们还需要修正形容词“hecho” 使其与同一句子中的 “pizza”保持一致 我们想在这里使用 agreeWithArgument 属性 我们通常保持 inflect: true 块 尽量简短 以帮助消除歧义 因为“hecho”与 inflect 块距离较远 所以这次我们需要 使用“agreeWithArgument”属性

这里的值为 1 表示 我们希望“hecho” 与字符串中的第一个参数一致 即“pizza” 让我们再次运行 App

现在看来 这是一个很棒的 西班牙语本地化体验 现在让我们看看如何使用 新的 agreeWithConcept 属性 来修复这里的食物尺寸 由于 pizza 是阴性名词 描述它的形容词应该是“pequeña”

我们已经为 食物尺寸定义了本地化名称 为了修复一致性 根据特定的食物项目 我们想要通过某种方法或逻辑 来选择正确的本地化名称 接下来 我们想在格式化 SIZE_BUTTON 时传递食物名称 在这里 我们将为 LocalizationOptions 定义一个新的属性 即 concept Concept 是影响词形变化的对象 但不像参数那样插入到字符串中 在这里 我们使用 localizedPhrase concept 来插入我们希望 与之进行语法一致的字符串

我们应记得使用 options 它在初始化字符串时进行了定义

接下来 我们想修改 我们的西班牙语字符串目录

我们想要使用新的 agreeWithConcept 属性对其进行注解

这里的值 1 表示我们希望该参数 与传递给 LocalizationOptions 的第一个 concept 保持一致 最后 让我们更新 FoodSizeView 用户在其中使用新方法选择 所需的披萨大小

现在让我们再次运行我们的 App 并最终下订单购买披萨

太棒了 我们的食物大小 与这里的披萨完全一致 让我们试试三明治 它在西班牙语中是阳性名词 这看起来很棒 现在让我们用英语 启动我们的 App 并最终下单披萨

这次我要买一个大的 而且要买两个 为什么不呢？

看起来 Tony 快要送到我们的订单了 这里的中性语言很好 但我们知道 Tony 设置了他的代词为 he/him/his 这是一件容易解决的事情 为此 让我们扩展配送员的模型 使其包括 preferredTermsofAddress

同时 扩展我们的 Tony 实例 并指示他偏好使用阳性代词

接下来 我们想要改变字符串本身

在这里 我们想替换根据配送员的 termsOfAddress 而定的代词“they” 为此 我们使用了 新的 referentConcept 属性

这里的值 1 意味着“they”代词的指代对象 是传递给 LocalizationOptions 的 第一个 concept

我们可以将其应用于 该句子中的任何第三人称代词

接下来 我们想在 LocalizationOptions 中 将 termsOfAddress 作为一个 concept 传递 让我们为送货信息 初始化 LocalizationOptions

在这里 我们还可以使用 termsOfAddress 概念 来提供我们可以用于 语法一致性的称谓

最后 当我们初始化字符串时 让我们使用新的 LocalizationOptions

现在让我们再次运行我们的 App

好的 巨大的披萨 两个 我们把它改为三个吧

现在 我们应用了一致性 这看起来更具个性化

Foundation 今年有很多很棒的新功能 并且它们已经 可以供你在 App 中尝试 Inflect：true 今年支持更多的语言 我们新的依赖关系 一致性 API 将帮助你 在同一字符串中一致地使用单词 甚至是在完全脱离上下文的情况下 最后 在 Markdown 中 新的 termsOfAddress 概念 和 referentConcept 属性 将有助于使你的语言更加个性化 有关语言级别支持 请参阅我们的文档 希望你会喜欢这些新功能 我们期待看到它们美化 你的 App 语言 谢谢 哦 我的披萨到了 谢谢你 Tony ♪ ♪