我们正准备将我们的PHP网站翻译成各种语言,PHP中的gettext支持看起来就像是要走的路.
我看到的所有教程都建议使用英文文本作为消息ID,即
gettext("你好!")
但这真的是个好主意吗？假设市场营销人员希望将文本更改为"你好,你们!".那么你不必更新所有语言文件,因为该字符串 - 实际上是消息ID - 已经改变了吗？
拥有某种通用ID(例如"hello.message")和英文翻译文件会更好吗？
哇,我很惊讶没有人主张用英语作为关键.我在几个软件项目中使用了这种风格,恕我直言,它的效果非常好.代码可读性很好,如果你改变一个英文字符串,很明显需要考虑重新翻译消息(这是一件好事).
如果您只是更正拼写或进行其他肯定不需要翻译的其他更改,则更新资源文件中该字符串的ID非常简单.
也就是说,我目前正在评估是否采用这种方式将I18N推向一个新项目,所以很高兴听到一些关于它为什么不是一个好主意的想法.
我使用有意义的ID,例如" welcome_back_1",这将是" welcome back, %1"等等.我总是将英语作为我的"基础"语言,因此在最坏的情况下,当特定语言没有消息ID时,我会依赖英语.
我不喜欢使用实际的英语短语作为消息ID,因为如果英语改变了ID也是如此.如果您使用一些自动化工具,这可能不会对您产生太大影响,但这让我感到困扰.我不喜欢使用简单的代码(如msg3975),因为它们没有任何意义,所以阅读代码会更加困难,除非你在任何地方发表评论.
我非常不同意理查德·哈里森的回答,他说这是"唯一的方式".亲爱的提问者,不要相信一个答案,说明这是唯一的方法,因为"唯一的方式"不存在.
以下是恕我直言与理查兹方法相比具有一些优势的另一种方式:
首先使用原始英文字符串的proto版本.
不要显示这些原型字符串,但要为英语创建翻译文件
将原始字符串复制到开头的翻译
好处:
可读代码
代码中的文本与视图显示的内容非常接近
如果要更改英文文本,则不要更改原始字符串,而是更改翻译
如果你想翻译相同的东西两次,只需编写一个略有不同的原型字符串或只是添加'版本为此和那',你仍然有一个完全可读的代码
ID为英语的原因是,如果翻译因任何原因失败而返回ID - 当前语言和令牌的翻译不可用,或其他错误.那当然假设开发人员正在编写原始英文文本,而不是一些文档人员.
此外,如果英文文本发生变化,那么其他翻译可能需要更新吗？
在实践中,我们也使用Pure ID而不是英文文本,但它确实意味着我们必须做很多额外的工作才能默认为英文.
总之,不要这样做.
英语中的相同单词/短语通常足以具有多个含义,并且每个含义都意味着不同的翻译.
为您的字符串定义助记符ID,并将英语视为另一种语言.
同意其他海报,代码中的id号码是代码可读性的噩梦.
Ex本地化工程师
有很多要考虑的问题，答案并不是那么容易。
使用简单的英语优点
易于编写和阅读代码
在大多数情况下，即使不运行代码中的翻译功能，它也可以工作
缺点
参与其中的程序员也必须是优秀的撰稿人:)
即使您需要使用的第一语言是另一种语言，也需要用英语完全写出正确的精确文本（即，我们正在以捷克语启动项目的开始，之后将它们本地化为EN）。
在很多情况下，您需要使用上下文。如果您不能通过begginig完成此操作，那么以后添加它们将需要很多工作。解释：用英语，一个单词可以有许多不同的意思-您需要使用上下文来区分它们-并非总是那么容易（order = sort order，也可以是采购订单）。
在此过程的后期纠正英语可能非常困难。源字符串的更正经常会导致丢失已翻译的短语。仅仅因为您更正了英语而将翻译松散为3种不同的语言，这非常令人沮丧。
使用按键
优点
您甚至可以为英语使用本地化平台功能。也就是说，我们正在使用可爱的Crowdin平台。有很多方便的工具-甚至是完整的工作流程-用于翻译管理：为不同的翻译，翻译历史，词汇表（有助于保持翻译/语言的连贯性），校对，批准等进行投票。更流畅。
发送Engish文本进行校对等要容易得多。通常，让撰稿人直接修改您的代码不是一个好主意:)
缺点
更复杂的项目设置。
很难使用％d，％s等。
京公网安备 11010802040832号 | 京ICP备19059560号-6 