【问题标题】：What is the most practical approach to using and/or reusing localized strings使用和/或重用本地化字符串的最实用方法是什么
【发布时间】：2017-08-28 21:46:06
【问题描述】：

问题

假设我至少有 3 个不同的对话框视图：

创建你想创建这个吗？ [取消][确定]

保存要保存吗？ [取消][确定]

删除要删除吗？ [取消][确定]

在这种情况下创建键/值对最实用的方法是什么？

选项 1：每个视图的唯一键

createTitle : "Create"
createDescription : "Would you like to create this?"
createPositiveButton: "OK"
createNegativeButton: "Cancel"

saveTitle : "Save"
saveDescription : "Would you like to save this?"
savePositiveButton: "OK"
saveNegativeButton: "Cancel"

deleteTitle : "Delete"
deleteDescription : "Would you like to delete this?"
deletePositiveButton: "OK"
deleteNegativeButton: "Cancel"

缺点：键之间存在大量重复值。更改每个都花费大量时间，例如，如果您想将 Ok 更改为 Accept

选项 2：常见字符串的可重用变量

genericPositiveButton: "OK"
genericNegativeButton: "Cancel"

createTitle : "Create"
createDescription : "Would you like to create this?"

saveTitle : "Save"
saveDescription : "Would you like to save this?"

deleteTitle : "Delete"
deleteDescription : "Would you like to delete this?"

缺点：如果需要单独更改，例如将OK更改为Confirm CreateConfirm Save和Confirm Delete，则需要更改代码中的变量。

总结

显然这里没有万能的答案，但我想知道是否有一套关于本地化文件变量的使用和重用的最佳实践，尤其是在大型多平台应用程序中。

【问题讨论】：

标签： localization internationalization multilingual

【解决方案1】：

我提倡选项 1。并且加倍下注。

但实际上，这是一个重要的设计决策，您应该与您的国际化团队讨论。准备好谨慎权衡现在的投资和以后更快、更便宜的本地化，与现在更快、更便宜的首次上市时间和以后的返工成本。 “实用”通常归结为对这些权衡的一组权重。

这是选项 1 的情况。现在投资，以后可以更快、更便宜地进行本地化。您说您对“特别是对大型多平台应用程序”感兴趣。让我们假设“大”还意味着“准备好本地化为世界各地的大量语言”，以及“大到足以收获规模经济”。

任何大规模完成的本地化都应该由核心开发人员、本地化团队和翻译的语言服务提供商进行自动化处理。自动化的一个重要部分是使用translation memory。该工具可识别源短语何时与已翻译的源短语相同或相似，并提供翻译以供与该源短语重复使用。

随着您对越来越多的语言进行本地化，您越来越可能会遇到原始开发人员不知道如何区分的情况，因为原始开发人员使用的语言并不重要。

在你的例子中，“这个”这个词突然出现在我身上。您省略了句子的对象，即命名正在创建或保存的事物的名词。您没有规定根据隐含对象的性别或数量以不同方式拒绝“this”一词。您应该期望遇到一种语言，其中对象需要是显式的，或者对它的引用在创建和保存时拼写不同。

当您允许将消息存储为完整的单元时，您就可以让翻译人员和本地化人员获得正确使用短语所需的控制权。

您不必担心将“OK”更改为“Accept”所需的努力。如果您对按钮文本的键具有自动化和一致的拼写，那么您应该能够编写一个工具来进行批量更改。例如，正则表达式可以识别键“createPositiveButton”、“deletePositiveButton”和“savePositiveButton”，然后在一个操作中将所有这些键后面的“OK”文本更改为“Accept”。

【讨论】：

【解决方案2】：

您在这里没有专门研究语言，所以我将使用 Ruby on Rails 来散列一个简单的玩具示例。

选项 3：缺少翻译时的回退

verbs:
  save: 'save'
  delete: 'delete'
  create: 'create'
dialogs:
  default:
    ok: 'OK'
    cancel: 'Cancel'
    title: '%{verb}'
    text: 'Would you like to %{verb} this?'
  delete:
    text: 'Are you sure you want to %{verb} this? Warning: This cannot be undone'
  save:
    ok: 'Confirm %{verb}'

然后，您可以使用足够智能的助手来使用这些后备：

module DialogHelper
  def dialog_text(verb, field)
    translated_verb = t("verbs.#{verb}")
    t("dialogs.#{verb}.#{field}", default: t("dialogs.default.#{field}", verb: translated_verb), verb: translated_verb)
  end

  def nicely_render_a_dialog(verb)
    render(partial: 'nice_dialog_box', locals: {verb: verb}) # This then calls dialog_text(verb, 'ok'), dialog_text(verb, 'cancel') repeatedly
  end

  def create_dialog
    nicely_render_a_dialog('create')
  end

  # et cetera...
end

如果您想更改默认的“OK”文本，它只定义在一个地方。如果您想专门覆盖删除确认文本，您只需在dialogs.delete 子树下写一个案例。我还没有找到任何已发布的此类最佳实践，但我认为分层结构（可能具有多层后备）将提供您所追求的那种灵活性。

【讨论】：