errors 的翻譯會輸入數個 translate key 去一個個嘗試尋找翻譯，而前篇 translate missing message 給出來的 key，是翻譯優先度最高的，同時也是適用範圍最小的 key。

關於他會輸入哪些 key 到 I18n 進行翻譯，或者換句話說，我們可以使用哪些 key 來規劃翻譯檔。
這邊根據優先度高到低羅列出來，一律以 attrbute: :name, message: :blank 做示例。

attribute 的部分：

:"activemodel.attributes.my_cls.name"
:"activemodel.attributes.super_class.name" # 如果有繼承 active model class的話，super_class 可以替換成父層 class
# 繼承鍊越上層優先度越低，但只要有用到 active model，都會被抓出來組 key 一起放進 I18n 嘗試翻譯。
:"attributes.name"
"Name" # 如果上述翻譯 key 都找不到，就直接 string.humanize

message 的部分：

:"activemodel.errors.models.my_cls.attributes.name.blank"
:"activemodel.errors.models.my_cls.blank"
:"activemodel.errors.models.super_class.attributes.name.blank" 
:"activemodel.errors.models.super_class.blank" # 同上，super_class 可以替換成父層 class
:"activemodel.errors.messages.blank"
:"errors.attributes.name.blank"
:"errors.messages.blank"

看到這些 key 你會發現，不管你要不要共用你的翻譯，Rails 他都幫你留好了一套翻譯規則。
不管你要或不要把翻譯限縮在你設定的 i18n_scope ( 上方顯示為 activemodel 的位置就是了 ) 範圍內，或者要不要限定欄位名稱，都可以依照讀者專案需求去思考翻譯的適用範圍，並規劃翻譯檔。

那像筆者我比較省，寫好的 I18n 翻譯檔能共用就共用，絕不重寫第二遍，message 的部分我就直接使用 errors.messages.blank 這支 key，規劃起來 yaml 檔就會像這樣：

en:
  errors:
    messages:
      my_custom_message: "MY CUSTOM MESSAGE!!"

那既然都講到了 I18n 規則，下一篇接著就順便講講 form builder 吧！
Rails 的 form builder 其實也能支援 attribute 的翻譯，想不到吧～！