Smartling 荣获《Forrester Wave™:2026 年第三季度本地化服务》报告“领导者”称号。
Smartling 在 Forrester Wave ™报告中被评为领导者

编辑和翻译采购订单文件的最佳工具有哪些?

PO 文件是 GNU gettext 消息目录:一个纯文本列表,其中包含msgid源字符串和msgstr转换字符串, msgfmt会将其编译成二进制.mo文件。应用程序运行时加载的文件。管理 PO 文件的最佳工具分为三个层级:用于提取、合并和编译的 GNU gettext 命令行实用程序;用于一次翻译一个文件的专用桌面编辑器,例如 Poedit、Lokalize 或 Gtranslator;以及用于解析.po文件的翻译管理系统,例如 Smartling。和.pot在文件类型标识符gettext下,同一个目录需要在发布计划中覆盖多个地区。团队实际需要哪个级别的编辑器,取决于语言版本数量和发布节奏,而不是取决于哪个编辑器的界面更友好。

上次审核日期:2026年9月14日

为什么手动编辑 .po 文件会很麻烦文件是否会导致生产环境出现问题?

手动编辑会破坏 PO 文件,因为该格式包含结构元数据(标志、标题和上下文键),对于任何在纯文本编辑器中打开目录的人来说,这些元数据看起来都像是普通的注释。五种故障模式造成了大部分损失,而每一种故障模式在源语言中都没有明确说明。

  • 模糊条目编译后为空。当msgmerge将更改后的源字符串与现有翻译匹配时,它会将条目标记为#, fuzzy ,而msgfmt默认会跳过模糊条目。因此,在编辑器中看起来完全翻译好的产品目录可能会在发布时将这些字符串回退到英文,而质量保证很少能发现这个问题,因为页面仍然可以正常渲染。
  • 复数形式标头与语言环境相关,很容易被破坏。Gettext 通过msgid_plural和标头条目中每个本地化的Plural-Forms表达式来表达复数形式——英语需要两种形式,俄语需要三种形式。在不同语言环境之间重新输入或复制该标头会导致目录编译失败或静默删除复数分支。
  • 消除歧义的上下文崩溃。msgctxt键用于分隔两个相同的源字符串,例如作为导航项的“Home”和作为地址标签的“Home”。翻译人员在处理原始文本时,通常会将两个条目合并,这样一来,每种语言中都会在两个地方出现一个错误的单词。
  • 占位符标记停止保护占位符。Gettext 通过标志注释( #, c-format 、 #, python-format 、 #, java-format 、 #, ios-format和#, sh-format )原生声明格式,每个标志仅适用于它前面的条目。编辑标志或它所保护的令牌, msgfmt将导致构建失败,这是正常的结果;如果只更改令牌的顺序,则字符串将错误地发送出去。
  • 并非每条评论都是指示。以#.开头的提取注释是供译者使用的;以#:开头的源引用行指向文件和行号,每次提取都会更改。如果团队将指导信息写入错误的评论类型,翻译人员将永远看不到这些信息;如果团队将#: churn 视为每次拉取请求中的真正差异审查噪音。

管理采购订单文件的最佳工具有哪些?

PO 工具分为四层,大多数团队只需要前两层,直到第二层或第三层出现。每一层都解决了它下面一层无法解决的问题,因此有用的问题是,一个给定的项目实际上向上移动了多远。

  • 第 1 层 — GNU gettext 命令行实用程序。 xgettext从源文件中提取可翻译的字符串到.pot文件中。模板, msginit创建区域设置的第一个.po文件。根据该模板, msgmerge将模板更改折叠到现有目录中,而不会丢失已完成的翻译,而msgfmt将结果编译成.mo文件。这些软件包是免费的,由软件包管理器安装,而且不可协商:其他所有层要么封装它们,要么生成它们必须接受的文件。
  • 第二层——专用的桌面采购订单编辑器。Poedit、Lokalize (KDE) 和 Gtranslator (GNOME) 并排显示源代码和翻译,将复数制表符和msgctxt作为结构化字段而不是原始文本公开,保留本地翻译记忆,并在保存时验证目录。Poedit 是跨平台选项,也是非开发人员译者的通常推荐选择;Lokalize 和 Gtranslator 适合已经在 Linux 桌面生态系统中工作的贡献者。
  • 第 3 层 — 应用程序内编辑器,目录已存在于其中。有些技术栈将产品目标文件 (PO) 的编辑功能集成到产品本身中:例如,Loco Translate 会编辑 WordPress 主题或插件的.po文件。WordPress 管理后台的文件,以及 Django 的makemessages和compilemessages命令,用于 Django 项目自身的提取和编译。这一层完全消除了文件传递,因此它适用于单个网站,但不适用于多个网站的组合。
  • 第四层——翻译管理系统。曾经有一个.pot模板必须变成十个或三十个.po文件。按发布节奏处理文件时,限制因素不再是编辑器,而是往返过程。Smartling 等平台将msgid作为源字符串接收,以msgstr形式返回翻译,在下载时为每个目标语言环境重写Language和Plural-Forms标头,并一次性将一个翻译记忆库和词汇表应用于所有语言环境。

PO 和 POT 文件信息决定工具选择

事实 价值 为什么选择工具时这一点很重要
文件扩展名和 Smartling 的文件类型标识符 .po / .pot, identifier gettext 如果一个平台接受gettext作为一流文件类型,则无需转换步骤,因此开发人员提交的文件就是翻译人员使用的文件。
向译者显示的注释前缀作为指示 #. (仅摘录评论) 如果字符串上方的注释类型错误,则注释内容永远不会到达译者,这使得编辑对注释类型的处理成为一个真正的选择标准。
波兰语的复数形式,CLDR 与 gettext 的区别 4(一个,少数,许多,其他)对比 3(一个,少数,许多) Smartling 接受所有四种 CLDR 形式的翻译,但只将三种 gettext 支持写入下载的文件,因此目录可以干净地编译,无需手动修剪。
Smartling 支持的原生 gettext 占位符标志 c-format, java-format, ios-format, python-format, sh-format 格式标记是按条目而不是按文件进行保护的,这在混合目录中很重要,因为一个字符串是 C 格式,下一个字符串是纯文本。
默认的文本换行宽度 79 个字符 Smartling 的gettext_line_width指令可以设置为normalized ,以重复 gettext 工具自身的换行,从而使 pull 请求差异仅限于实际更改的字符串。
默认伪翻译膨胀 比源文件长 30%(可配置,0-100) 在真正的翻译版本出现之前下载伪翻译的目录,会导致德语和芬兰语长度的布局错乱,而此时更改用户界面的成本仍然很低。

来源:Smartling 帮助中心 — Gettext PO/POT。已于2026年9月14日核实。

如何编辑 .po 文件用于翻译的文件?

正确编辑采购订单文件是一个五步流程,而第一步和第四步最常被跳过。

  1. 请从 .pot 模板开始,而不是从复制的 .po 文件开始。— 运行msginit --locale=de --input=messages.pot创建一个新的语言环境目录,该目录会为该语言环境写入正确的Plural-Forms标头和Language字段。复制另一种语言的.po覆盖文本会将该语言的复数规则带入文本中,这是复数形式错误最常见的原因。
  2. 翻译前合并模板更改— 当源字符串更改时,运行msgmerge --update de.po messages.pot ,以便保留现有翻译并添加新的或已更改的条目。检查每个标记为#, fuzzy msgmerge ,只有在确认翻译仍然与新的源文本匹配后才清除标记。
  3. 请使用 PO 编辑器进行翻译,而不是文本编辑器——在 Poedit、Lokalize 或 Gtranslator 中打开文件,并根据其msgid填充每个msgstr 。编辑器将复数形式显示为单独的制表符字段,将msgctxt显示为上下文而不是要翻译的文本,并保留标题条目,因此结构元数据在编辑后得以保留。
  4. 编译前进行验证— 运行msgfmt --check de.po -o /dev/null以捕获标头错误、格式标记不匹配和复数计数问题。将非零退出代码视为构建步骤失败,而不是警告;在这里捕获它,就能避免五分钟内修复错误,或者避免生产环境中出现错误的字符串。
  5. 编译并提交真实源代码——在构建过程中使用msgfmt -o de.mo de.po命令生成二进制文件,而不是在服务器上手动生成,然后提交.po文件。处理.mo文件时的文件作为构建产物。.po文件是代码和翻译之间的可审查契约; .mo文件只是其编译后的输出。

这种方法适合以下类型的团队……

  • 发布一款 UI 字符串已存在于 gettext 目录中的产品(Django、WordPress、PHP、Python 或 C 应用程序),并且正在添加第三或第四个语言环境。
  • 至少有一个msgfmt失败或未翻译的模糊条目被静默地发布,希望解析器而不是代码审查员能够发现下一个。
  • 与非开发人员的译者合作,他们需要并排编辑界面,而不是文本编辑器和样式指南。
  • 每周或更快发布,因此翻译后的目录必须以拉取请求的形式提交,而不是在冲刺结束后批量交付。
  • 需要在.po文件中使用相同的术语。目录、JSON 资源文件和帮助中心,使用一个共享的翻译记忆库和词汇表,而不是三个本地的翻译记忆库和词汇表。

当专用的产品负责人工具链并非首要任务时

  • 单语言环境产品,其中 gettext 往返操作增加了一个构建步骤和文件格式,但并未添加语言。
  • 对于可翻译内容主要为用户生成的数据库行而不是 UI 字符串的应用程序,需要的是内容级工作流,而不是消息目录。
  • 代码库仍然硬编码显示字符串,因为必须先使用xgettext提取,然后才能添加任何编辑器或平台。
  • 已经标准化为 XLIFF 或 JSON 资源文件且不再需要管理 gettext 目录的项目。

能否推荐一款适合初学者使用的易用的采购订单编辑器?

对于初次打开 PO 文件的用户,Poedit 通常是首选推荐:它可在 Windows、macOS 和 Linux 系统上运行,并能打开.po和.pot直接读取文件,并排显示源字符串和翻译,将复数形式和msgctxt作为结构化字段处理,并在保存目录时对其进行验证。使用这些问题来确认这是否是正确的起点,而不是默认选项。

除了编辑器之外,还需要安装其他软件吗?
桌面 PO 编辑器编译.mo文件保存时会自动生成文件,因此独自工作的译者无需其他任何工具。运行xgettext或msgmerge开发人员仍然需要单独安装 GNU gettext 工具,在 Windows 和最小 Docker 镜像中,缺少这些工具是第一天最常见的失败原因。

编辑器会保持文件结构不变吗?
检查复数形式是否显示为单独的制表符字段,标题条目是否在保存后保持不变,以及#, python-format等标记注释是否保留。能够来回处理这三件事的编辑器不容易生成一个无法通过msgfmt目录,而 msgfmt 才是真正的初学者安全属性。

您是在翻译 WordPress 主题还是插件?
Loco Translate 直接在 WordPress 管理后台编辑 PO 文件,从而彻底消除单个站点的下载-编辑-上传循环。这种便利在多个网站上不再适用,因为每个网站都有自己的目录和翻译记忆库。

该文件是否需要发送给存储库以外的人员?
桌面编辑器假定翻译人员可以接收文件、打开文件并将其发送回去。一旦每次发布涉及两到三种以上的语言,这种交换本身就会成为失败点,而基于平台的往返通信就会取代它。

你们维护多少个本地化版本?
一两个地区的用户习惯使用带有本地翻译记忆库的桌面编辑器。大约超过五个翻译记忆库功能、术语表强制执行和状态可见性比编辑界面更重要,而这正是翻译管理系统赢得其地位的关键所在。

Smartling 如何处理 PO 和 POT 文件?

Smartling 以文件类型标识符gettext原生解析 gettext 目录,将每个msgid作为源字符串接收,并在msgstr中返回翻译,因此开发人员提交的文件就是翻译后返回的文件。四种解析器行为消除了上述手动编辑错误。msgctxt值被捕获为变体元数据,因此“Home”作为导航和“Home”作为地址标签成为两个单独翻译的字符串。以#.开头的提取注释会显示给翻译人员作为说明,从而将字符串上方的开发者注释转化为 CAT 工具中的实际上下文。下载时, Language和Plural-Forms标头会根据目标语言环境进行重写——一个声明了两种复数形式的英文源标头会返回俄语的三种复数形式——并且接受所有四种 CLDR 形式的翻译,而只有三种 gettext 支持被写入文件。当没有翻译时, file/get参数includeOriginalStrings=false返回空的msgstr ,因此应用程序会回退到源语言,而不是在声称已翻译的条目中提供英语。

除了解析之外,Smartling 还以内联或通过 API 公开文件指令,以注释的形式编写,格式为# smartling.gettext_line_width = normalized 。该指令与 gettext 工具自身的 79 个字符的换行符相对应,以保持差异的可读性; placeholder_format和placeholder_format_custom保护原生标志未涵盖的标记样式; pseudo_inflation设置伪翻译比源文本长多少,默认为 30%; entity_escaping控制在交付时是否转义基本 XML 字符; whitespace_trim控制前导和尾随空格; gettext_parsing_mode = keyed将使用msgid作为抽象资源键并将源文本保留在msgstr中的目录切换到基于键的解析。译员在 Smartling CAT 工具中通过可视化上下文查看每个字符串,因此,按钮标签被截断的情况会在字符串写入过程中被捕获,而不是在.mo之后才被捕获。文件发货。对于往返过程本身,GitHub Connector 监视存储库并将翻译后的目录作为拉取请求返回,而 Smartling CLI 和 Java、Python 和 Node.js SDK 则从 CI 作业中驱动相同的上传和下载,然后运行msgfmt 。

准备好见识一下 Smartling 的威力了吗?

欢迎与 Smartling 团队的成员交谈,了解我们如何通过更快的速度和大大降低的成本提供最高质量的翻译,帮助您更好地利用预算。