获取文本：消息 ID 是英文文本是个好主意吗？

StackOverflow https://stackoverflow.com/questions/216478

题

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

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

gettext("你好！")

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

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

有帮助吗？

解决方案

我使用有意义的ID，例如“ welcome_back_1 ”这将是“ welcome back，％1 ”我总是把英语作为我的“基础”。因此，在特定语言没有消息ID的最坏情况下，我会依赖英语。

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

其他提示

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

如果您只是更正拼写或进行其他肯定不需要翻译的其他更改，则更新资源文件中该字符串的ID非常简单。

那就是说，我现在正在评估是否采用这种方式将I18N转发到一个新项目，所以最好听一些关于它为什么不是一个好主意的想法。

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

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

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

优点：

  • 可读代码
  • 代码中的文本与视图显示的内容非常接近（即使不完全相同）
  • 如果你想改变英文文本，你不需要改变原字符串，而是改变翻译
  • 如果你想将同一件事翻译两次，只需编写一个稍微不同的原始字符串或添加“这个和那个的版本”，你仍然有一个完全可读的代码

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

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

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

总之，不要这样做。

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

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

同意其他海报，代码中的id号码是代码可读性的噩梦。

Ex本地化工程师

有很多事情需要考虑，而答案并不那么容易。

使用简单的英语

优点

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

缺点

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

使用按键

优点

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

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

缺点

  • 更复杂的项目设置。
  • 更难使用 %d、%s 等。

你还没有回答过自己的问题吗？ ：）

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

在一天结束时，翻译人员应该能够坐下来改变每种语言的文本（因此它们的含义相符），而不必让已经完成其工作的程序员参与其中。

这让我觉得正确的答案是使用 gettext 的修改版本，你可以在这里放置这样的字符串

_(id, backup_text, context)

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

上下文是可选的

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

您还应将备份，ID和上下文保留在代码中的相同位置，以减少差异。

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

  1. 人们忘记在开始时这样做，以后更改它是一个问题
  2. 它更灵活，系统能够按ID和上下文进行分组

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

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

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

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

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

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

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

就像Douglas Leeder所提到的那样，你可能想要做的是使用英语作为默认（备份）语言，尽管使用英语和其他语言混合的界面非常混乱（但也有点有趣）。

除了上面的考虑因素之外，还有很多情况下你需要“密钥”。 （msgid）与源文本（英文）不同。例如，在HTML视图中，我可能想说[yyyy]其中锚标记的目标和标签取决于用户的区域设置。例如。它可能是一个社交网络的链接，在美国它将是Facebook，但在中国它将是微博。因此，MsgIds可能类似于socialSiteUrl和socialSiteLabel。

我使用混音。

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

许可以下： CC-BY-SA 和 归因
不隶属于 StackOverflow
scroll top