New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rails 3.1 nested I18n namespace deprecations #1869

Closed
BDQ opened this Issue Jun 27, 2011 · 29 comments

Comments

Projects
None yet
@BDQ
Contributor

BDQ commented Jun 27, 2011

Working off of 3-1-stable branch I'm getting lots of the following deprecation warnings:

[DEPRECATION WARNING] Nested I18n namespace lookup under "activerecord.attributes.order" is no longer supported
...
[DEPRECATION WARNING] Nested I18n namespace lookup under "activerecord.models.order" is no longer supported

After digging through the code I can't seem to find any suggested or replacement structure.

Here's the current yml that's causing the warnings:

en:
  activerecord:
    attributes:
      order:
        ship_address:
          address1: "Shipping address street"
        state: State
        total: Total
    models:
      order:
        one: Order
        other: Orders

I'm happy to submit a patch for deprecation warning once I know how to replace the existing values.

@schof

This comment has been minimized.

Show comment
Hide comment
@schof

schof Jun 27, 2011

Contributor

According to @josevalim so-called "nested models" (ie. order.ship_address) are no longer supported b/c of possible conflicts with attributes that have the same name as the nested model namespace. He also says the first instance has been fixed recently. Patches to the warning message to clarify are welcome.

Contributor

schof commented Jun 27, 2011

According to @josevalim so-called "nested models" (ie. order.ship_address) are no longer supported b/c of possible conflicts with attributes that have the same name as the nested model namespace. He also says the first instance has been fixed recently. Patches to the warning message to clarify are welcome.

@BDQ

This comment has been minimized.

Show comment
Hide comment
@BDQ

BDQ Jun 28, 2011

Contributor

Okay, so the first instance has been fixed recently (thank you), but the second is still an issue.

From the yaml above, if I remove the nested ship_address values the validation messages on an order update (with nested attributes for the ship_address association) would look like:

"Ship address address1 can't be blank"

instead of the current:

"Shipping address street can't be blank"

So will it be possible to localize associations anymore when the nested lookup is actually removed?

Contributor

BDQ commented Jun 28, 2011

Okay, so the first instance has been fixed recently (thank you), but the second is still an issue.

From the yaml above, if I remove the nested ship_address values the validation messages on an order update (with nested attributes for the ship_address association) would look like:

"Ship address address1 can't be blank"

instead of the current:

"Shipping address street can't be blank"

So will it be possible to localize associations anymore when the nested lookup is actually removed?

@JeanMertz

This comment has been minimized.

Show comment
Hide comment
@JeanMertz

JeanMertz Jul 12, 2011

I just got the same deprecation when working with nested forms. If this function is removed, I don't really see a working solution for now, is that correct?

On the other hand, the current situation wasn't very DRY anyway, as you had to repeat the same attribute name for each nested form.

JeanMertz commented Jul 12, 2011

I just got the same deprecation when working with nested forms. If this function is removed, I don't really see a working solution for now, is that correct?

On the other hand, the current situation wasn't very DRY anyway, as you had to repeat the same attribute name for each nested form.

@BDQ

This comment has been minimized.

Show comment
Hide comment
@BDQ

BDQ Jul 12, 2011

Contributor

Yeah, I'm not sure what the final solution for this one is. The old method is still working, so we'll live with the deprecation warning until the we figure out the intended replacement is.

Contributor

BDQ commented Jul 12, 2011

Yeah, I'm not sure what the final solution for this one is. The old method is still working, so we'll live with the deprecation warning until the we figure out the intended replacement is.

@dmke

This comment has been minimized.

Show comment
Hide comment
@dmke

dmke Sep 4, 2011

@JeanMertz: The situation with nested forms could be made DRY with YAML aliases:

  foo: &foo_atts
    bar: "Bar!"
    baz: "Arrrr!!"
  snafu:
    <<: *foo_atts

This way, you'd have a snafu.bar. A practical example for nested forms (User accepts Address) would have been :

  activerecord:
    attributes:
      address: &address_attributes
        name: "Full name"
        zip: "Zip code"
      user:
        email: "Mail address"
        address_fields:
          <<: *address_attributes

But that causes deprecation warnings now...

Have any workarounds been developed since July?

—Dominik

dmke commented Sep 4, 2011

@JeanMertz: The situation with nested forms could be made DRY with YAML aliases:

  foo: &foo_atts
    bar: "Bar!"
    baz: "Arrrr!!"
  snafu:
    <<: *foo_atts

This way, you'd have a snafu.bar. A practical example for nested forms (User accepts Address) would have been :

  activerecord:
    attributes:
      address: &address_attributes
        name: "Full name"
        zip: "Zip code"
      user:
        email: "Mail address"
        address_fields:
          <<: *address_attributes

But that causes deprecation warnings now...

Have any workarounds been developed since July?

—Dominik

@JeanMertz

This comment has been minimized.

Show comment
Hide comment
@JeanMertz

JeanMertz Sep 5, 2011

@dmke thanks, that certainly cleans things up, but if that also shows the deprecation then I guess we still don't have a viable alternative.

I don't understand how something can be deprecated if there is no clear alternative? I mean, surely there must be plenty of users serving international Rails apps to their customers? But looking at the number of replies here it's almost as if it's a non-issue (I guess it is, as it's only a deprecation warning, but who knows, perhaps the feature will be completely removed in 3.2)

JeanMertz commented Sep 5, 2011

@dmke thanks, that certainly cleans things up, but if that also shows the deprecation then I guess we still don't have a viable alternative.

I don't understand how something can be deprecated if there is no clear alternative? I mean, surely there must be plenty of users serving international Rails apps to their customers? But looking at the number of replies here it's almost as if it's a non-issue (I guess it is, as it's only a deprecation warning, but who knows, perhaps the feature will be completely removed in 3.2)

@dennisreimann

This comment has been minimized.

Show comment
Hide comment
@dennisreimann

dennisreimann Sep 5, 2011

I've got the same problem and I tried to mention it in the comments of the commit, but haven't gotten a answer for that, yet: c19bd4f#commitcomment-514010

dennisreimann commented Sep 5, 2011

I've got the same problem and I tried to mention it in the comments of the commit, but haven't gotten a answer for that, yet: c19bd4f#commitcomment-514010

@szimek

This comment has been minimized.

Show comment
Hide comment
@szimek

szimek Sep 9, 2011

Contributor

I've got the same problem. I've got User model that has one Web::Account. To create translations for Web::Account attributes I can do:

activerecord:
  attributes:
    web/account:
      password_digest: "Password"

But I have no idea how to create translations for the nested form where I edit user and his web account.

activerecord:
  attributes:
    user:
      web_account:
        password: "Password"

is the only thing that seems to work, but produces this deprecation error....

Contributor

szimek commented Sep 9, 2011

I've got the same problem. I've got User model that has one Web::Account. To create translations for Web::Account attributes I can do:

activerecord:
  attributes:
    web/account:
      password_digest: "Password"

But I have no idea how to create translations for the nested form where I edit user and his web account.

activerecord:
  attributes:
    user:
      web_account:
        password: "Password"

is the only thing that seems to work, but produces this deprecation error....

@plentz

This comment has been minimized.

Show comment
Hide comment
@plentz

plentz Sep 15, 2011

Contributor

@szimek

activerecord:
  attributes:
    user:
      web_account/password: "Password"

This works for the view label without generating the warning. BUT, the problem with this approach is that if your nested form have any validation form and you try to display it's errors, the translation in error messages don't work.

I really think that this warning should be removed since I think there's no workaround for nested forms validation messages.

Contributor

plentz commented Sep 15, 2011

@szimek

activerecord:
  attributes:
    user:
      web_account/password: "Password"

This works for the view label without generating the warning. BUT, the problem with this approach is that if your nested form have any validation form and you try to display it's errors, the translation in error messages don't work.

I really think that this warning should be removed since I think there's no workaround for nested forms validation messages.

@JeanMertz

This comment has been minimized.

Show comment
Hide comment
@JeanMertz

JeanMertz Sep 15, 2011

@plentz, well, either that or go with the style you described and fix the case where the error messages don't work. On the other hand, the way you describe the solution seems like a step back regarding DRY'ing up your code.

The above mentioned technique that @dmke suggested won't work anymore with the web_account/password technique, as far as I can tell.

Either way, the deprecation warning is annoying when you are developing and testing your app, to say the least, so I hope this gets resolved soon, it seems a rather small thing to fix (or revert) compared to everything that has been going on in Rails (sprockets, asset pipeline, coffee script, etc)

JeanMertz commented Sep 15, 2011

@plentz, well, either that or go with the style you described and fix the case where the error messages don't work. On the other hand, the way you describe the solution seems like a step back regarding DRY'ing up your code.

The above mentioned technique that @dmke suggested won't work anymore with the web_account/password technique, as far as I can tell.

Either way, the deprecation warning is annoying when you are developing and testing your app, to say the least, so I hope this gets resolved soon, it seems a rather small thing to fix (or revert) compared to everything that has been going on in Rails (sprockets, asset pipeline, coffee script, etc)

@Mange

This comment has been minimized.

Show comment
Hide comment
@Mange

Mange Sep 27, 2011

We're getting this one as well. Anyone from Rails Core willing to comment? @josevalim?

Mange commented Sep 27, 2011

We're getting this one as well. Anyone from Rails Core willing to comment? @josevalim?

@Mange

This comment has been minimized.

Show comment
Hide comment
@Mange

Mange Sep 27, 2011

Sorry, seems like I misunderstood the warning I got. I genuinely had an error in my locale files.
Example:

en:
  activerecord:
    attributes:
      blog:
        title:
          one: Title
          other: Titles

Note that the attribute isn't an association. I have no idea how we ended up with this key like that.

Sorry for spamming you, José. :-(

Mange commented Sep 27, 2011

Sorry, seems like I misunderstood the warning I got. I genuinely had an error in my locale files.
Example:

en:
  activerecord:
    attributes:
      blog:
        title:
          one: Title
          other: Titles

Note that the attribute isn't an association. I have no idea how we ended up with this key like that.

Sorry for spamming you, José. :-(

@diegorv

This comment has been minimized.

Show comment
Hide comment
@diegorv

diegorv Sep 29, 2011

Not working yet! :/// @josevalim?

diegorv commented Sep 29, 2011

Not working yet! :/// @josevalim?

@bbenezech

This comment has been minimized.

Show comment
Hide comment
@bbenezech

bbenezech Oct 13, 2011

My yml is like:

  subscription:
    method_of_payment: Le mode de règlement
    user:
      email: L'email
      email_confirmation: La confirmation email
      password: Le mot de passe
      password_confirmation: La confirmation de mot de passe
      lastname: Le nom de famille
      firstname: Le prénom
    delivery_address:
      recipient: Le destinataire de livraison
      tel: Le téléphone de livraison
      address: L'adresse (rue) de livraison
      city: La ville de livraison
      zip_code: Le code postal de livraison
      country: Le pays de livraison
    billing_address:
      recipient: Le destinataire de facturation
      tel: Le téléphone de facturation
      address: L'adresse (rue) de facturation
      city: La ville de facturation
      zip_code: Le code postal de facturation
      country: Le pays de facturation

I do have a nameclash bug:

 ActionView::Template::Error (translation data {:address=>"L'adresse (rue) de livraison", :city=>"La ville de livraison", :zip_code=>"Le code postal  de livraison", :country=>"Le pays de livraison"} can not be used with :count => 1)

When translating the delivery_address association itself (belongs_to relationship)

Both point to fr.activerecord.attributes.subscription.delivery_address

Clearly we need to implement the nested attribute look-up as

fr.activerecord.attributes.subscription/delivery_address

It may clash with a model named Subscription::DeliveryAddress but not likely.

bbenezech commented Oct 13, 2011

My yml is like:

  subscription:
    method_of_payment: Le mode de règlement
    user:
      email: L'email
      email_confirmation: La confirmation email
      password: Le mot de passe
      password_confirmation: La confirmation de mot de passe
      lastname: Le nom de famille
      firstname: Le prénom
    delivery_address:
      recipient: Le destinataire de livraison
      tel: Le téléphone de livraison
      address: L'adresse (rue) de livraison
      city: La ville de livraison
      zip_code: Le code postal de livraison
      country: Le pays de livraison
    billing_address:
      recipient: Le destinataire de facturation
      tel: Le téléphone de facturation
      address: L'adresse (rue) de facturation
      city: La ville de facturation
      zip_code: Le code postal de facturation
      country: Le pays de facturation

I do have a nameclash bug:

 ActionView::Template::Error (translation data {:address=>"L'adresse (rue) de livraison", :city=>"La ville de livraison", :zip_code=>"Le code postal  de livraison", :country=>"Le pays de livraison"} can not be used with :count => 1)

When translating the delivery_address association itself (belongs_to relationship)

Both point to fr.activerecord.attributes.subscription.delivery_address

Clearly we need to implement the nested attribute look-up as

fr.activerecord.attributes.subscription/delivery_address

It may clash with a model named Subscription::DeliveryAddress but not likely.

@henrik

This comment has been minimized.

Show comment
Hide comment
@henrik

henrik Oct 14, 2011

Contributor

I think it should fall back to fr.activerecord.attributes.delivery_address (and further to fr.attributes, like human_attribute_name would) if there is no nested entry.

As for clashes, are there realistic use cases for Foo having a bar attribute and a nested Bar model? Seems like you would go with one or the other.

Contributor

henrik commented Oct 14, 2011

I think it should fall back to fr.activerecord.attributes.delivery_address (and further to fr.attributes, like human_attribute_name would) if there is no nested entry.

As for clashes, are there realistic use cases for Foo having a bar attribute and a nested Bar model? Seems like you would go with one or the other.

@bbenezech

This comment has been minimized.

Show comment
Hide comment
@bbenezech

bbenezech Oct 14, 2011

Yes, it sounds reasonable.
Can someone work on it? Jose sound OK to pull it.
And I agree we should not remove functionality until patched for an alternative.

bbenezech commented Oct 14, 2011

Yes, it sounds reasonable.
Can someone work on it? Jose sound OK to pull it.
And I agree we should not remove functionality until patched for an alternative.

@henrik

This comment has been minimized.

Show comment
Hide comment
@henrik

henrik Oct 16, 2011

Contributor

I could probably find the time to make the change, but I would want @josevalim or someone else to sign off on it first, or I suspect I would be wasting my time.

Contributor

henrik commented Oct 16, 2011

I could probably find the time to make the change, but I would want @josevalim or someone else to sign off on it first, or I suspect I would be wasting my time.

@bbenezech

This comment has been minimized.

Show comment
Hide comment
@bbenezech

bbenezech commented Oct 17, 2011

@henrik He is ok for "address/location"
c19bd4f#commitcomment-619858

ozeias added a commit to ozeias/rails that referenced this issue Oct 26, 2011

@derekprior

This comment has been minimized.

Show comment
Hide comment
@derekprior

derekprior Nov 23, 2011

Contributor

@ozeias, what's the status of the commit referenced here? Has it been submitted in a pull request? It's frustrating that this bahvior has been deprecated with no equivalent replacement...

Contributor

derekprior commented Nov 23, 2011

@ozeias, what's the status of the commit referenced here? Has it been submitted in a pull request? It's frustrating that this bahvior has been deprecated with no equivalent replacement...

@ozeias

This comment has been minimized.

Show comment
Hide comment
@ozeias

ozeias Nov 23, 2011

@derekprior I'm waiting for the core team. This type of warning is very annoying... :)

ozeias commented Nov 23, 2011

@derekprior I'm waiting for the core team. This type of warning is very annoying... :)

@morgoth

This comment has been minimized.

Show comment
Hide comment
@morgoth

morgoth Dec 22, 2011

Member

Support for this translations was removed in Rails 3.2.0.rc1 without any substitution.
It would be good to have this fixed in final 3.2.

Member

morgoth commented Dec 22, 2011

Support for this translations was removed in Rails 3.2.0.rc1 without any substitution.
It would be good to have this fixed in final 3.2.

@francocatena

This comment has been minimized.

Show comment
Hide comment
@francocatena

francocatena Dec 22, 2011

Contributor

I agree with @morgoth

Contributor

francocatena commented Dec 22, 2011

I agree with @morgoth

@bbenezech

This comment has been minimized.

Show comment
Hide comment
@bbenezech

bbenezech Dec 22, 2011

+1

Not optional, that thing is needed.

bbenezech commented Dec 22, 2011

+1

Not optional, that thing is needed.

@janv

This comment has been minimized.

Show comment
Hide comment
@janv

janv Dec 22, 2011

Contributor

Seems like this is fixed (= a substitute provided) in 3.2.0: #3859

Contributor

janv commented Dec 22, 2011

Seems like this is fixed (= a substitute provided) in 3.2.0: #3859

@venkatnr

This comment has been minimized.

Show comment
Hide comment
@venkatnr

venkatnr Apr 5, 2012

hi, actually i have similar problem..

"[DEPRECATION WARNING] Nested I18n namespace lookup under "activerecord.attribute s.order" is no longer supported"

This is coming when i am running server, i am did my rake db:migrate set up and i am using sqlite3
and
ruby ruby 1.9.2p290
rails 3.1.1
gem 'spree', '~> 0.70.1'

can any body help me out...

venkatnr commented Apr 5, 2012

hi, actually i have similar problem..

"[DEPRECATION WARNING] Nested I18n namespace lookup under "activerecord.attribute s.order" is no longer supported"

This is coming when i am running server, i am did my rake db:migrate set up and i am using sqlite3
and
ruby ruby 1.9.2p290
rails 3.1.1
gem 'spree', '~> 0.70.1'

can any body help me out...

@schof

This comment has been minimized.

Show comment
Hide comment
@schof

schof Apr 5, 2012

Contributor

@venkatnr This is fixed in Rails 3.2.x and consequently will be fixed in the upcoming Spree 3.1.x. Its already fixed on the Spree master branch (ie. edge)

Contributor

schof commented Apr 5, 2012

@venkatnr This is fixed in Rails 3.2.x and consequently will be fixed in the upcoming Spree 3.1.x. Its already fixed on the Spree master branch (ie. edge)

@venkatnr

This comment has been minimized.

Show comment
Hide comment
@venkatnr

venkatnr Apr 5, 2012

@schof You mean i need to modify my rails version or upgrade the Spree gem. can you explain plz

venkatnr commented Apr 5, 2012

@schof You mean i need to modify my rails version or upgrade the Spree gem. can you explain plz

@wandtasie

This comment has been minimized.

Show comment
Hide comment
@wandtasie

wandtasie Apr 5, 2012

@venkatnr: If you got no further issues, ignore the warning

wandtasie commented Apr 5, 2012

@venkatnr: If you got no further issues, ignore the warning

@steveklabnik

This comment has been minimized.

Show comment
Hide comment
@steveklabnik

steveklabnik Apr 28, 2012

Member

As @schof and @janv says, this was fixed in 3.2.x, so I'm closing.

Member

steveklabnik commented Apr 28, 2012

As @schof and @janv says, this was fixed in 3.2.x, so I'm closing.

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