1

我正在本地化一个 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）。

我不明白...

有人可以帮我吗？

4

2 回答 2

2

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

想象一下：

name_missing: "you must enter a name"

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

鉴于，类似：

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

是明确的。

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

于 2013-01-29T19:04:44.840 回答
2

如果我们撇开命名空间的需求来定位日期和活动记录消息、gem 和插件......在命名您自己的 i18n 数据时有许多优势，尤其是当应用程序变得复杂和/或随着时间的推移而发展时：

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

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

于 2013-01-29T19:25:19.050 回答