翻译管理

本地化文件 (Strings)

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

本地化文件是文本文件,可以在文本编辑器(如记事本或 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 数组结构。

这篇文章有帮助吗?

Sorry about that! In what way was it not helpful?

The article didn’t address my problem.
I couldn’t understand the article.
The feature doesn’t do what I need.
Other reason.

Note that feedback is provided anonymously so we aren't able to reply to questions.
If you'd like to ask a question, submit a request to our Support team.
Thank you for your feedback.