47

我们正准备将我们的 PHP 网站翻译成各种语言，PHP 中的 gettext 支持看起来是可行的方法。

我看到的所有教程都建议使用英文文本作为消息 ID，即

gettext("你好！")

但这真的是个好主意吗？假设营销人员想要将文本更改为“Hi there, y'all!”。那么您是否不必更新所有语言文件，因为该字符串（实际上是消息 ID）已更改？

拥有某种通用 ID（例如“hello.message”）和英文翻译文件会更好吗？

4

11 回答 11

46

哇，我很惊讶没有人提倡使用英语作为键。我在几个软件项目中使用了这种风格，恕我直言，效果很好。代码可读性很好，如果您更改英文字符串，很明显需要考虑重新翻译该消息（这是一件好事）。

如果您只是更正拼写或进行一些其他绝对不需要翻译的更改，那么在资源文件中更新该字符串的 ID 是一件简单的事情。

也就是说，我目前正在评估是否将这种 I18N 的方式推进到一个新项目中，所以很高兴听到一些关于为什么它可能不是一个好主意的想法。

于 2009-02-23T21:59:16.037 回答
22

我强烈不同意理查德哈里森的回答，他说这是“唯一的方法”。亲爱的提问者，不要相信说这是唯一方法的答案，因为“唯一方法”不存在。

这是恕我直言与理查兹方法相比具有一些优势的另一种方法：

  • 首先使用英文字符串的原始版本作为 Original。
  • 不要显示这些原始字符串，但要为英语创建一个翻译文件
  • 将原始字符串复制到开头的翻译中

好处：

  • 可读代码
  • 如果与您的视图显示的不同，您的代码中的文本非常接近
  • 如果要更改英文文本，则不要更改原始字符串，而是更改翻译
  • 如果您想将同一件事翻译两次，只需编写一个稍微不同的原始字符串或添加“这个和那个的版本”，你仍然有一个完全可读的代码
于 2009-02-09T20:54:42.053 回答
21

我使用有意义的 ID，例如“ welcome_back_1”，这将是“ welcome back, %1”等。我总是将英语作为我的“基础”语言，所以在最坏的情况下，当特定语言没有消息 ID 时，我会使用英语。

我不喜欢使用实际的英语短语作为消息 ID，因为如果英语发生变化，ID 也会发生变化。如果您使用一些自动化工具，这可能不会对您产生太大影响，但它让我很困扰。我不喜欢使用简单的代码（比如 msg3975），因为它们没有任何意义，所以阅读代码会更加困难，除非你到处乱扔评论​​。

于 2008-10-19T19:00:07.053 回答
12

ID 为英语的原因是，如果由于任何原因翻译失败 - 当前语言和令牌的翻译不可用或其他错误，则返回 ID。当然，这假设开发人员正在编写原始英文文本，而不是某些文档人员。

此外，如果英文文本发生变化，那么其他翻译可能需要更新？

在实践中，我们也使用纯 ID 而不是英文文本，但这确实意味着我们必须做很多额外的工作才能默认为英文。

于 2008-10-19T15:44:20.787 回答
9

有很多事情要考虑，但回答并不那么容易。

使用简单的英语

优点

  • 易于编写和阅读代码
  • 在大多数情况下，即使没有在代码中运行翻译功能，它也能工作

缺点

  • 参与的程序员也必须是好的文案 :)
  • 您需要完全用英语编写正确、精确的文本，即使您需要运行的第一语言是其他语言（例如，我们正在开始使用捷克语进行大量项目，稍后我们会将它们本地化为 EN）。
  • 在很多情况下，您需要使用上下文。如果您从一开始就没有这样做，那么以后添加它们需要做很多工作。解释一下：在英语中，一个词可以有多种不同的意思——你需要使用上下文来区分它们——而且并不总是那么容易（order = sort order，或者它可以是采购订单）。
  • 在此过程的后期纠正英语可能非常困难。源字符串的更正通常会导致已经翻译的短语丢失。仅仅因为您更正了英语，就将翻译松散为 3 种不同的语言是非常令人沮丧的。

使用键

优点

  • 即使是英语，您也可以使用本地化平台功能。即我们正在使用可爱的 Crowdin 平台。有很多方便的工具 - 或者更确切地说是一个完整的工作流程 - 用于翻译管理：投票选择不同的翻译、翻译历史、词汇表（有助于保持翻译/语言的连贯性）、校对、批准等。使用密钥使这个过程变得很重要更顺畅。

  • 发送英文文本进行校对等要容易得多。通常，让文案人员直接修改您的代码不是一个好主意:)

缺点

  • 更复杂的项目设置。
  • 更难使用 %d、%s 等。
于 2017-10-16T19:59:58.307 回答
6

总之不要这样做。

英语中的相同单词/短语通常可以具有多个含义，并且每个含义都具有不同的翻译。

为您的字符串定义助记符 id，并将英语视为另一种语言。

同意其他发帖者的观点，即代码中的 id 数字是代码可读性的噩梦。

前本地化工程师

于 2009-07-31T00:22:22.923 回答
4

你不是已经回答了你自己的问题吗？:)

显然，如果您打算支持您的应用程序的 i18n，您应该对所有语言实现一视同仁。如果有人决定需要更改字符串，您可以在所有语言文件中进行类似的更改。带有签入的元数据应将所有语言文件分组到同一个更改中。如果您的“默认”语言处理方式不同，则维护起来会更加困难。

于 2008-10-19T14:36:26.010 回答
3

归根结底，翻译人员应该能够坐下来更改每种语言的文本（以便它们在含义上匹配），而不必让已经完成工作的程序员参与进来。

这让我觉得正确的答案是使用修改后的版本来gettext放置这样的字符串

_(id, backup_text, context)

_('ABOUT_ME', 'About Me', 'HOMEPAGE')

上下文是可选的

为什么这样？因为您需要使用唯一 ID 而不是可能在其他地方重复的英文文本来识别系统中的文本。

您还应该将备份、id 和上下文保存在代码中的同一位置，以减少差异。

id 也必须是可读的，这带来了同义词和重复使用的问题（即使作为 ids），我们可以像“HOMEPAGE_ABOUT_ME”或“MAIL_LETTER”这样的 ids 前缀，但是

  1. 人们一开始就忘记这样做，以后改变它是一个问题
  2. 系统可以更灵活地按 id 和 context 进行分组

这就是为什么我还在最后添加了上下文变量

备份文本几乎可以是任何内容，甚至可以是“[ABOUT_ME@HOMEPAGE 文本加载失败，请联系 example@example.com]”

它不适用于当前的 gettext 编辑程序，例如“poedit”，但我认为您可以为翻译定义自定义变量名称，例如“t()”，开头没有下划线。

我知道 gettext 也支持上下文，但它没有很好的文档记录或广泛使用。

PS我不确定执行良好和可扩展代码的最佳变量顺序，因此欢迎提出建议。

于 2016-01-30T11:12:52.810 回答
2

我什至会说你永远（对于从不的大多数值）想要使用自由文本作为任何东西的键。想象一下，如果 SO 使用查询标题作为此页面的键。如果有人链接到它，然后编辑了标题，则该链接不再有效。

你的问题是相似的，除了你还要负责更新所有的链接......

就像 Douglas Leeder 提到的那样，您可能想要做的是使用英语作为默认（备用）语言，尽管使用英语和另一种语言混合使用的界面非常令人困惑（但也有点有趣）。

于 2008-10-19T16:20:37.877 回答
0

除了上述考虑之外，在许多情况下，您希望“键”（msgid）与源文本（英语）不同。例如，在 HTML 视图中，我可能想说 [yyyy] 该锚标记的目的地和标签取决于用户的语言环境。例如，它可能是一个社交网络的链接，在美国它是 Facebook，但在中国它是微博。所以 MsgIds 可能类似于 socialSiteUrl 和 socialSiteLabel。

我使用混合。

对于我认为不会有冲突/变化/奇怪含义的基本字符串，我会让键与英语相同。

于 2012-12-20T18:55:08.873 回答
0

我们使用荷兰语。字符串应该用作者的母语编写；这使得与翻译人员的交流不太容易出错，因为作者可以用他们的母语与他们交流。

于 2020-03-27T00:51:26.167 回答