Fix human_attribute_name to handle names with dots #3859

Merged
merged 1 commit into from Dec 5, 2011

Conversation

Projects
None yet
5 participants
Contributor

kuroda commented Dec 5, 2011

Nested I18n namespace lookup under activerecord.models is deprecated now (c19bd4f).
But when a model uses accepts_nested_attributes_for, its Errors object can have
an attribute name with "addresses.street" style. In this case, the dots should be
substituted with slashes so that we can provide the translation under the
"activemodel.attributes.person.addresses/street" key.

@kuroda kuroda Fix human_attribute_name to handle names with dots
Nested I18n namespace lookup under activerecord.models is deprecated now (c19bd4f).
But when a model uses accepts_nested_attributes_for, its Errors object can have
an attribute name with "addresses.street" style. In this case, the dots should be
substituted with slashes so that we can provide the translation under the
"activemodel.attributes.person.addresses/street" key.
dff19f7

@josevalim josevalim added a commit that referenced this pull request Dec 5, 2011

@josevalim josevalim Merge pull request #3859 from kuroda/human_attribute_name
Fix human_attribute_name to handle names with dots
2985151

@josevalim josevalim merged commit 2985151 into rails:master Dec 5, 2011

torsakch commented Mar 3, 2012

@kuroda If I want multi-level nested attributes, what should I do to define the locale?
For your example, you have just location/address. If I have customer/person/location/address, what should I do?

Contributor

kuroda commented Mar 3, 2012

@torsakch

Although I have enough time to check it out now, I think that current implementation can not handle correctly the deeply (more than two-level) nested attributes.

In that case, we should make a new patch and send a pull request.

torsakch commented Mar 3, 2012

@kuroda Do you have work around solution?

Contributor

kuroda commented Mar 3, 2012

Not yet. It should not be difficult, but I am a little busy now.

I'm new to Rails (and programming in general), so please forgive me if I'm posting out of turn here. I noticed this issue is marked as closed. I'm having trouble localizing nested attributes, so I'm wondering if I'm doing something wrong or if this issue still remains. I'm on Rails 3.2.3. Thank you.

Contributor

kuroda commented Apr 7, 2012

As for deeply nested attributes, this issue is still open.

Ok, thank you!

@kuroda kuroda added a commit to kuroda/rails that referenced this pull request May 15, 2012

@kuroda kuroda Fix human attribute_name to handle deeply nested attributes
When a model nests another model that also nests yet another model
using accepts_nested_attributes_for method, its Errors object can
have an attribute name with "contacts.addresses.street" style.

In this case, the dots within the namespace should be substituted
with slashes so that we can provide the translation under the
"activemodel.attributes.person/contacts/addresses.street" key.

This commit is related to #3859.
b0e2fc8

I think this patch should be back-ported to Rails 3.1

Contributor

kuroda commented Jun 4, 2012

@leehambley OK. I will do that job. Please wait a few days.

@kuroda Thanks very much, I was referred to this issue from AASM https://github.com/rubyist/aasm/issues/38

@kuroda kuroda added a commit to kuroda/rails that referenced this pull request Jun 6, 2012

@kuroda kuroda Fix human attribute_name to handle deeply nested attributes
This is a back-port of b0e2fc8 to Rails 3.2.
See #5843 and #3859 also.
029936e
Contributor

kuroda commented Jun 6, 2012

@leehambley I have sent a pull request of a backport to Rails 3.2.

It seems that this fix is not relevant to Rails 3.1. Correct me if I am wrong.

It seems that this fix is not relevant to Rails 3.1. Correct me if I am wrong.

It seems it's unrelated to the warning I am receiving out of AASM; aasm uses "#{state_columln}.#{model_state}" for i18n'ing keys, example:

activerecord:
   attributes:
      user:
        state:
          confirmed: "Bestätigt" # Confirmed
          locked: "Gesperrt" # Locked

The same warning is being raised, but apparently for a different reason.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment