如何组织本地化字符串资源？

我们正在开发一个包含许多小程序包的大型应用程序。每个软件包都有自己的一组资源文件以进行本地化。

组织和命名本地化字符串的最佳方法是什么？

到目前为止，这是我的想法：

处理重复项

同一文本（例如“邮政编码”）在给定的程序包中可能多次出现。编程本能（DRY）告诉我创建一个由所有实例共享的单个字符串资源。

再者，翻译者可能希望在某些地方选择长译本（“ Postleitzahl”），在空间较小的地方选择短译本（“ PLZ”）。或者，我们可能决定在某些情况下添加冒号（“邮政编码：”），而在其他情况下则不添加。或者我们可能在某些地方要求使用不同的大写字母（“邮政编码”）。所有这些参数都指向每种用法创建一个资源，即使它们的内容相同。

命名

如果我们希望消除重复，则可以按内容命名资源，也许可以通过前缀提示使用的种类。因此，我们可能有labelOK= “ OK”，messageFileTooLarge= “文件超出了最大文件大小。” 和labelZipCode= “邮政编码”。

按内容命名具有自然处理格式参数的优势：资源messageFileHas_0_MBWhileMaximumIs_1_MB显然采用两个格式参数，即实际文件大小和最大文件大小。

但是，如果我们允许重复，则仅按内容命名是没有意义的。为了获得唯一的资源名称，我们必须以某种方式在资源名称中包括使用位置。这适用于图形控件，尽管标识符往往有点长：fileSelectionConfirmationButtonText= “ OK”，customerDetailsTableColumnZipCode= “邮政编码”。但是，对于非可视代码文件，它会变得更加困难。如果您不知道字符串的最终显示位置，该如何命名字符串的特定用法？通过代码文件和函数名称？对我来说似乎很笨拙。

总而言之，我倾向于允许重复，但是我一直在努力寻找一个支持此目的的一致命名方案。

编辑：这个问题有两个方面：如何组织资源（DRY与重复项）以及如何命名它们。到目前为止，答案集中在第一方面。非常感谢您提供有关命名约定的反馈！

每当您不能完全确定在所有情况下使用特定字符串的含义是否完全相同时，我都会接受重复。

即使两个标签始终在英语（或您的母语）中包含相同的字符串，也不一定在所有语言中都相同。接受重复可以为您（或更确切地说是翻译）提供处理此类情况所需的灵活性。

例如：考虑一个标签“ Condition”，根据上下文，该标签可能会被翻译成德语的“ Zustand”或“ Bedingung”（在许多其他可能的翻译中）。

接受一些重复项。

您可以通过创建额外的控件来避免进行多次翻译。例如，a CancelButton和an OKButton已经包含其文本，现在Cancel / Abbrechen OK / OK只需要翻译一次。但这几乎是一个特例。

这是我们在公司中处理此问题的方式：

命名约定： 我们通过在标签前面加上类/节/表格/等来命名标签。举例来说loadFile_loadButton，loadFile_fileNameLabel，loadFile_cancel是属于加载文件对话的所有标签。尽管这种强调的命名约定不是最常见的命名约定，但我们更喜欢它而不是更标准的约定，因为它提高了可读性和“可分组性”：请注意，与标签相比，查看标签属于哪个元素以及每个标签代表什么是多么容易命名loadFileLoadButton，loadFileNameLabel和loadFileCancel。您可能会认为差异并不大，但是当您有数千个标签时，复合效果值得。

标题注释： 除了为标签名称加上前缀之外，我们还向资源文件添加“标题”注释，以明确定义标签分组。这样，想要修改或添加与某个特定类/节/表单/等相关的特定标签的某人可以在一个标题下的一个位置找到与该特定元素相关的所有标签，并且可以轻松地轻松进行添加或修改标签知道它们不会破坏任何其他元素的翻译（恕我直言，这也是为什么您需要允许重复的一个非常重要的观点）。

“合法的”重复是可取的： 如上所述，这些做法将最终导致重复的标签，但是我们认为这样做没有问题（更多关于如何在交易工具中处理此问题）。

正如其他人指出的那样，一种语言的标签可以根据其所呈现的上下文以两种或多种不同的方式用其他语言翻译。如果您“统一”标签，那么翻译人员将很难拿出一个单独的标签来适应所有找到的上下文。因此，正如我们所见，允许“合理的”重复项有助于提高本地化的质量，只要它们在相同的上下文中不引用相同的事物即可（这就是“合理的”含义）。

交易工具： 为了尽可能有效地进行翻译，您可以构建自己的工具来查找捆绑销售商品中存在的相似标签，并将其翻译作为新标签的默认值提供，甚至使用像这样的现有服务，该服务提供了我刚刚提到的服务，从而使新标签的翻译变得轻而易举（如果重复多次，则更加容易，因为默认情况下该工具将为您提供多个新标签的翻译选项） ）。

总结： 合理的重复和以上下文方式分组标签确实有助于翻译人员完成工作。重要时刻。试想一下：在帮助翻译者选择正确的翻译时，具有上下文的意义很大。允许“合理的”重复消除了必须选择一种不适合某些上下文的翻译（但总的来说还是最佳的翻译）的矛盾。

我希望这有帮助！

过去，当我们完成此操作时，我们会走上包含完整句子的资源文件的路径。如果完全重复使用完全相同的句子，但如果只是句子中的单个单词，那么这些单词将被复制。

我们被绑定到一个框架，在该框架中，资源文件仅包含英语短语列表，然后进行翻译（在结尾处带有一些索引数据以进行快速查找）。

对于小数据提示或按钮，例如字段名“ ZIP Code”或按钮“ OK”，它将存储字符串“ ZIP Code”和翻译，并在需要完整字符串的地方使用。但是（除非我们手动拆分字符串）不会将其用于句子中出现的“邮政编码”。

使用您的邮政编码示例，如果您尝试自己翻译它，并将其替换为所有使用它的句子，您将得到非常非常糟糕的翻译。

例如，“必须输入邮政编码”可能需要用另一种语言翻译“输入的邮政编码必须为”的字面等价形式。如果将句子切成小段，您不会得到另一种语言所需的单词反转。

这就是为什么一些翻译不当的英语看起来如此荒谬，这样做的人只是翻译了单个单词，而不是整个句子。

我们总是发现最好将句子整体翻译起来，而不要分解它们。我们为需要插入的数据提供了占位符（例如，“部件号@ 1是多余的”），翻译人员可以将占位符移动到他们想要的位置，以获得良好的翻译效果。

但是，我们发现允许使用完全相同的句子，相同的数据提示或相同的按钮标签等位置的位置可以共享翻译。从来没有出现过这样的问题，为翻译人员节省了时间/成本。

您对命名的想法很好。

目标

• 为本地化文本定义一个通用标签（即变量名）。
• 标签应为“头脑大小”。那是...尽可能简短而又毫不含糊。
• 标签应遵循一致的格式，以最大程度地提高可预测性和召回率。

实作

• 始终使用众所周知的缩写（例如，msg = message，lbl = label，btn = button等），以减少认知负担
• 工具以字母顺序列表形式显示变量/标签，因此，当相关标签组合在一起时，人工查找是最佳选择。使名称从最一般的到最具体的分层。（即msgFileMissing，msgFileSaved，msgFileDeleted）。
• 英语是动词-名词排序的语言。许多（大多数？）其他语言是名词-动词。名词动词最适合分层分组。