消息翻译
Fuchsia 本地化提供的第一项功能是消息翻译。从概念上讲，这让程序能够使用用户选择的语言显示面向用户的消息。这通过使用语言区域敏感格式设置工具输出来实现。程序需要保留存储用户本地化偏好设置的“本地化上下文”。在程序执行过程中，当屏幕需要以用户的母语显示消息“Hello world!”时（例如，西班牙语应编码为“es”，欧洲西班牙语应编码为“es”，西班牙语需编码为“es-419”），该程序可以通过提供抽象消息和包含原始消息的 [Lookup] 服务查询翻译。从概念上讲，这相当于代码中的一行与以下常规模式匹配：
[Lookup].String({locale-ids=["es-419"]}, MSG_Hello_World) ⇒ (yields the translation)
在上面的示例中，[Lookup] 可以是任何类型的可调用端点：它可以是库公开函数，也可以是通过网络提取翻译的 RPC 存根的接口点。“获取翻译后的消息”的抽象操作在这里称为 String，以将其与对类型化数据的其他可能调用（例如 StringArray 等）区分开来。
请注意，消息可能比该示例更为复杂，因此我们通常不希望程序作者直接处理消息，而是通过消息 ID 进行处理。
另外请注意以下两点：
- 语言标识符以 Unicode 语言区域 ID 的形式指定（因此是示例中命名的参数
locale-ids），可一次提供多个此类语言区域 ID。这是因为用户可能具有多种首选语言，并且可能具有一种首选语言层次结构。这样，本地化系统便可以在单个会话中选择最佳可用消息，并且可能采用多种语言。 - 在代码中未将消息指定为其字符串表示形式。而是通过唯一的邮件标识符来引用。在上面的示例中，将其任意命名为
MSG_Hello_World。虽然关于字符串是应该内部化还是外部化，各流派的看法各不相同，但我们选择了后者。我们这样做的主要原因是使源代码远离语言学问题，这使得翻译工具链更易于维护，并简化大规模翻译的管理。
从上面的示例中引出两个主要问题：
- 在程序员所选的语言中，
[Lookup]服务的具体接口是什么样的？而且， - 译文如何在我的程序中可供使用？
讨论 Lookup API 时，我们会回答这些问题。