本地化文件是文本文件,可以在文本编辑器(如记事本或 TextEdit)或程序员使用的众多增强文本编辑工具之一中打开和编辑。这些文件通常遵循键值原则。这意味着它们包含与唯一 ID (键) 关联的文本片段 (Strings) 列表。因此,每个字符串是一个键的值(这个简单的例子是Java编程中使用的本地化文件格式):
-
key1 = value1
-
key2 = value2
-
...
-
keyN = valueN
创建本地化文件
本地化文件是纯文本文件,结构简单。它们可以手动创建,但通常由国际化实用程序或脚本自动生成,适用于不同的开发环境。自动创建本地化文件可确保文件结构有效。
要创建本地化文件,所有可显示文本都会被替换为代码文件中的唯一 ID。然后,文本字Strings连同其 ID 一起添加到本地化文件中。
本地化文件的使用
代码现在只包含键,而不是实际的文本 Strings。当软件为用户生成视图时,这些键用于在本地化文件中查找关联的字Strings。
如果应用程序设置为使用英语和西班牙语,所有英语文本都可以保存在一个名为“English.txt”
的文件中,并且是默认文本位置。如果用户没有选择语言,将从该文件中提取所有文本以生成任何显示。如果用户选择西班牙语,软件将被重定向到Spanish.txt
。许多语言“”都可以与这样的系统一起使用。
这样做的好处是,显示语言的选择不会影响代码。如果软件需要显示登录按钮,它可能需要与键 login_按钮
关联的字符串,并且只需要知道要查找的文件就可以为给定语言检索适当的字符串。
字符串管理
phrase 是一个基于键的翻译平台,支持多种不同的资源文件类型。 文件上传后,提取 键及其相关字符串值。然后,键和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 是一种以 `%<tags>
形式提供元信息的格式。标签结构用于确定键及其相应值的位置,如以下 Android XML 文件所示:
<字符串名称="simple_key">只是一个带有信息的键。</字符串>
两种标准的 XML 翻译格式是 .TMX Orchestrator 和 Orchestrator.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 <译文 xml:lang="en-GB">只是一个带有简单信息的简单键。</译文> </trans-unit>
QT 程序使使用的资源文件的结构与这些标准化格式非常相似,但由于历史原因有不同的布局。
纯键值列表
有些资源文件仅包含键和值的简单列表,如 Ruby on Rails YAML 中的此代码片段所示:
simple_key:简单的键与简单的信息。“简单的键与简单的信息。”,
许多不同的编程语言或平台都使用这种格式,排版轻微不同。
由于这些是单语文件,本地化程序需要维护这些文件的并行版本--一个针对原文/源语语言,另一个针对译文语言。
Gettext=""生成包含附加信息的键值文件,例如描述性备注或复数变体:"
# 这是这个键的惊人描述! msgid "key_with_description" msgid_plural "" msgstr[0] "看看!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":"我是一个简单的键,有一个简单的信息。". "我是一个简单的键,有一个简单的信息。"
由于这些轻微但至关重要的区别,因此支持广泛使用的 .JSON 和 PHP 数组结构。