为什么在 Rails 中使用命名空间 YAML 本地化文件

Question

我正在本地化一个Rails应用程序，我想知道人们为什么这样做：

# de.yml
helpers:
  select:
    prompt: "Bitte wählen..."
  submit:
    create: "Erstellen"
    submit: "Speichern"
    update: "Aktualisieren"
# some_view.html.erb
f.submit t('helpers.submit.update')

这似乎是这样做的标准方法。

但是为什么不这样做呢：

# de.yml
prompt: "Bitte wählen..."
create: "Erstellen"
submit: "Speichern"
update: "Aktualisieren"
# some_view.html.erb
f.submit t('update')

无论如何，命名

YAML 文件有什么意义？它只是迫使我一直重复相同的路径（helpers.submit.update）。

我不明白...

有人可以在这里帮助我吗？

Answer 1

原因很简单，在普通的rails应用程序中，您可能有数百或数千个不同的值。这些值可能具有相同的名称，但具有细微的差异。如果你只去顶层，正如你所说，那么它们很容易变得模棱两可：你不会知道哪些标签属于哪些视图/模型。

想象一下：

name_missing: "you must enter a name"

如果您在 YAML 文件中看到它，您将不知道它是否用于产品名称、用户名或其他内容。因此，您必须搜索代码并查看其使用位置。

然而，像这样：

product:
  validation_errors:
    name_missing: "you must enter a name"

是明确的。

看到一个巨大的字段树似乎很随意，但是在处理数千或数万个标签和副本片段时，组织对于可维护性至关重要。

Answer 2

如果我们

抛开对命名空间的需求来本地化日期和活动记录消息、宝石和插件......为您自己的 i18N 数据命名具有许多优势，尤其是当应用程序变得复杂和/或随着时间的推移而演变时：

• 它允许您在特殊情况下更改键的翻译，例如，当您添加新语言时，例如消息的创建不使用与创建图片相同的单词。
• 命名空间文件更易于翻译和维护（例如，您不必检查代码即可查看是否所有出现的create都可以用erstellen翻译成其他语言）。
  如果您聘请外部翻译人员，这一点变得更加重要。
• 一旦项目变大，导航大量密钥并找到需要修改的密钥会更容易。

另一方面，如果只有程序员接触 yaml 文件并且您的项目不大，我同意你的看法，使用平面文件。
在这种情况下，即使是像 messages_create 或 pictures_create 这样的假命名空间也可以具有更容易在文本文件中找到它们的优势，具有 grep/ack 等。