我并不是要成为坏消息的承担者，但你的提议实际上是一个坏主意。我在一家非常重视 i18n 的公司工作，我们（痛苦地）发现你不能只将单词放入这样的句子中，因为它们通常没有意义。
我们所做的只是将错误文本与变量位完全断开，以避免这些问题。例如，我们会生成一个错误：
XYZ-E-1002 Frobozz not configured for multiple zorkmids (F22, 7).
然后，在错误的描述中，您简单地指出末尾括号中的两个值是 Frobozz 标识符和您尝试对其施加的 zorkmids 的数量。
这使得 i18n 翻译成为一项非常容易的任务，因为您在翻译时拥有所有所需的语言元素，而不必担心变量位应该是单数还是复数、阳性还是阴性，第一、第二或第三变格（不管这到底是什么意思）。
翻译团队只需转换"Frobozz not configured for multiple zorkmids" 就容易多了。
对于那些想看一个具体例子的人，我从我们的翻译机构那里得到了一些回报（有足够的东西改变了以保护有罪的人）。
在某个时候，有人提交了以下内容：
The {name} {object} is invalid
其中{name} 是对象的名称（客户、订单等），{object} 是对象类型本身（表、文件、文档、存储过程等）。
对于开发人员的主要（可能唯一）语言英语来说足够简单，但他们在翻译成德语/瑞士德语时遇到了问题。
虽然“客户文档”正确翻译（在位置上）为Kundendokument，但格式字符串在两个单词之间有空格这一事实是一个问题。这基本上是因为开发人员试图让句子听起来更自然，但不幸的是，基于他们有限的经验，这只是更自然。
更大的问题是“客户存储过程”变成了gespeichertes Verfahren der Kunden，字面意思是“客户的存储过程”。虽然德国客户可能已经忍受了Kunden dokument 中的空间，但无法成功地将gespeichertes Verfahren der Kunden 强加到{name} {object} 上。
现在你可能会说一个更聪明的格式字符串可以解决这个问题，但有几个原因会导致它不正确：
- 这是一个非常简单的示例，可能还有其他更复杂的示例（我会尝试获取一些示例，但我们的翻译团队已经明确表示，他们有更紧迫的工作，而不是屈服于我的每一个突发奇想）。
- 格式字符串的全部意义在于将翻译外部化。如果格式字符串本身是特定于翻译目标的，那么通过将文本外部化，您获得的收益很少。
-
开发人员不必担心像
{possible-pre-adjectives} {possible-pre-owner} {object} {possible-post-adjectives} {possible-post-owner} {possible-postowner-adjectives} 这样的格式字符串。这是翻译团队的工作，因为他们了解其中的细微差别。
请注意，引入断开连接很好地回避了这个问题：
指定的对象，类型为 ，无效。
参数 1 = {名称}。
参数 2 = {对象}。
Der sache nannte , dessen art ist, ist falsch。
参数 1 = {名称}。
参数 2 = {对象}。
最后一个翻译是我的，请不要用它来质疑我们翻译的质量。毫无疑问，更流利的德语使用者会从中获得愉快的笑声。