本地化文件 (Strings)

文本由 Phrase Language AI 从英语机器翻译而得。

本地化文件是文本文件，可以使用文本编辑器（如 Notepad 或 TextEdit）或程序员使用的无数增强型文本编辑工具打开和编辑。这些文件通常遵循键值原则。这意味着它们包含一个文本片段 (Strings) 列表，这些片段与唯一 ID (键) 相关联。因此，每个字符串都是键的一个值（这个简单的示例是 Java 编程中使用的本地化文件的格式）：

key1 = value1
key2 = value2
...
keyN = valueN

创建本地化文件

本地化文件是具有简单结构的纯文本文件。它们可以手动创建，但通常由国际化工具或脚本自动生成，这些工具或脚本适用于不同的开发环境。自动创建本地化文件可确保文件结构有效。

要创建本地化文件，代码文件中的所有可显示文本片段都将替换为唯一 ID。然后将这些文本 Strings 及其 ID 添加到本地化文件中。

使用本地化文件

代码现在只包含键，而不是实际的文本 Strings。当软件为用户生成视图时，这些键用于在本地化文件中查找关联的 Strings。

如果应用程序设置为以英语和西班牙语使用，则所有英语文本都可以保存在名为 English.txt 的文件中，并且这是默认的文本位置。如果用户未选择语言，则将从该文件中提取所有文本以生成任何显示内容。如果用户选择西班牙语，软件将重定向到 Spanish.txt。这样的系统可以使用多种语言。

其优势在于，显示所选的语言不会影响代码。如果软件需要显示一个登录按钮，它可能需要与键 login_button 关联的字符串，并且只需要知道在哪个文件中查找，即可检索给定语言的相应字符串。

字符串管理

作为基于键的翻译平台，Phrase 支持许多不同的资源文件类型。在上传文件<1> 后，会提取键<2> 及其关联的字符串值。然后，键和 Strings 会以标准化的格式呈现给译员。译员专注于他们的任务，而不必担心本地化文件的确切格式。他们可以检查键，因为键本身可以提供关键的上下文，并引导他们做出正确的词汇选择。

当所有 Strings 都翻译完成后，即可下载文件。在此过程中，会创建所需的本地化文件格式，以匹配原文/源语文件。

资源格式

支持四种广泛的资源类型，它们本质上都是基于文本的，可以在文本编辑器中打开和查看。

电子表格

支持 .XLSX 和 .CSV 文件。这些格式在本地化方面是等效的，并且包含键值对的行。键位于一行中，而相应的值位于相邻的行中。具体使用哪一列用于何种目的取决于应用程序，译员需要配置 Phrase 以正确解释这些列。 Zendesk .CSV 文件具有固定的结构，因此该类型不需要进一步调整：

"Title","Default language","Default text","English text","Variant status"
"simple_key","German","Einfacher Schlüssel.","Simple key.","Current"

XML

xml 是一种以 <标记> 形式提供元信息的格式。标签结构用于确定键及其对应值的位置，如下面来自 Android xml 文件所示：

 <string name=\"simple_key\">Just a  key with a message.</string>

两种标准的 xml 翻译格式是 .TMX 和 .XLIFF。这些文件不仅以一种语言保存键和值，还将原文/源语中的值对与译文中的对应值关联起来。此类文件通常是双语的，如下面 Symfony Xliff 文件中的翻译单元所示：

<trans-unit id="simple_key" resname="simple_key">
 <source xml:lang="de-DE">Nur ein einfacher Schlüssel mit einer einfachen Nachricht.</source
<target xml:lang=\"en-GB\">Just a simple key with a simple message.</target>
</trans-unit>

QT 程序使用资源文件，其结构与这些标准化格式非常相似，但由于历史原因，其布局有所不同。

纯键值列表

有些资源文件仅包含简单的键和值列表，如下面这段 Ruby on Rails YAML 所示：

simple_key: Just a simple key with a simple message.

许多不同的编程语言或平台使用此类格式，但布局有轻微差异。

由于这些是单语言文件，本地化程序需要维护此类文件的并行版本——一个用于原文/源语，其他用于译文。

Gettext 生成包含额外信息的键值文件，例如描述性注释或复数变体：

# This is the amazing description for this key!
msgid "key_with_description"
msgid_plural ""
msgstr[0] \"Check it out!"This key has a description!(At least in some formats)"
msgstr[1] \"Check it out!"此键有 %s 个描述！(At least in some formats)"

存在一些功能和布局相似但存在轻微差异的竞争格式。

关联数组

虽然其他格式需要自定义代码（解析器）来读取，但某些格式对开发人员和本地化人员来说更容易。基于 .JSON (JavaScript) 和 .PHP 数组的格式可以直接读取并映射到易于操作的通用代码结构（数组）中。数组可能很复杂，不同的应用程序会生成自定义数组结构。

例如，go-i18n JSON 将键称为 ID：

{
    "id": "simple_key",
    "translation": "simple key, simple message, so simple."
},

Angular 在其数组中使用键本身作为键：

"simple_key": "I am a simple key with a simple message."。

由于存在这些轻微但至关重要的差异，因此支持广泛使用的 .JSON 和 .PHP 数组结构。