0_rails.2.3.yml

# This a sample YML file from Rails 2.3. The objective is to propose a yml based on this
# one which will reduce error messsages duplication, as outline in this post:
#
# http://groups.google.com/group/rails-i18n/browse_thread/thread/3085a78831ed8fae
#
# Proposals are available below and also check the forks at the right.
en: 
  activerecord: 
    models: 
      admin: "Admin"
      artist: "Artist" 

    attributes: 
      admin: 
        name: "Name"

    errors: 
      messages: 
        blank: "cannot be blank"

      models:
        user:
          blank: "no blank fields here"
          attributes:
            name:
              blank: "so how people call you?"

1.yml

# This simply proposes renaming activerecord to models and models to names,
# as first said in Rails I18n group.
en: 
  models: 
    names: 
      admin: "Admin"
      artist: "Artist" 

    attributes: 
      admin: 
        name: "Name"

    errors: 
      messages: 
        blank: "cannot be blank"

      models:
        user:
          blank: "no blank fields here"
          attributes:
            name:
              blank: "so how people call you?"

2.yml

# Since the problem are the error messages, we could move it to the root namespace,
# and keep all the rest compatible.
en: 
  activerecord: 
    models: 
      admin: "Admin"
      artist: "Artist" 

    attributes: 
      admin: 
        name: "Name"

  errors: 
    messages: 
      blank: "cannot be blank"

    models:
      user:
        blank: "no blank fields here"
        attributes:
          name:
            blank: "so how people call you?"

3.yml

# As suggested by Clemens Kofler on the mailing list, but with global
# translations and some more complete examples.
# I try to keep related to one subject grouped together.
en:
  models:

    admin:
      name: "Admin"

      attributes:
        name: "Name"

      messages:
        blank: "no blank fields here"
        attributes:
          name:
            blank: "so how people call you?"

      # override _any_ setting per model, like the formatting
      # of full messages
      errors:
        format: "{{message}} {{attribute}}"

    artist:
      name:
        one: "Artist"
        other: "Artists"
      # etc...

    # maybe add some underscores? e.g. "_global" or "_global_"
    # I don't like that very much though.
    global:

      messages:
        blank: "cannot be blank"

      errors:
        format: "{{attribute}} {{message}}"

      template:
        header:
          one: "1 error prohibited this {{model}} from being saved"
          other: "{{count}} errors prohibited this {{model}} from being saved"
        body: "There were problems with the following fields:"

      # heck, why not? it makes sense for default translations now we have
      # a global set of translations
      attributes:
        updated_at: "updated at"

        # how about how to treat when no translations have been found?
        # should go as pure Ruby lambda (or maybe when we support
        # R18n-style filters)
        __missing__: ### lambda { |str| str.humanize }

4.yml

# To make that "global" scope a bit more logic, just some of my brainstorming...
# Also added some stuff like 'labels' and 'hints', which demonstrates why
# I think bundling of translations per subject should be a good thing.

en:
  models:

    global:

      messages:
        blank: "cannot be blank"

      errors:
        format: "{{attribute}} {{message}}"

      template:
        header:
          one: "1 error prohibited this {{model}} from being saved"
          other: "{{count}} errors prohibited this {{model}} from being saved"
        body: "There were problems with the following fields:"

      # heck, why not? it makes sense for default translations now we have
      # a global set of translations
      attributes:
        updated_at: "Updated at"

        # how about how to treat when no translations have been found?
        # should go as pure Ruby lambda (or maybe when we support
        # R18n-style filters)
        __missing__: ### lambda { |str| str.humanize }


    # To remove the problem that models can conflict with "global"
    # we can introduce the "specific" scope.
    specific:

      admin:
        name: "Administrator"

        attributes:
          name: "Name"

        messages:
          blank: "no blank fields here"
          attributes:
            name:
              blank: "so how people call you?"

        labels:
          name: "What is your name?"

        hints:
          name: "Please enter your name here"

        # I like this, because it is extensible. Imagine your app has multiple views
        # on the same data, like a report or export of some kind.
        report_labels:
          name: "NAME"

      artist:
        name:
          one: "Artist"
          other: "Artists"
        # etc...