ZOMG HAPPY TUESDAY (UTC-7)!!! <3<3<3<3<3 I am happy to announce that the first release candidate for Rails 3.0.6 has been pushed to rubygems.org. ## Release Candidate: What does it mean? The release candidate is very similar to what we will actually release for version 3.0.6. The reason that we release an RC is so that the community can have a chance to postpone or veto commits that have happened between the previous version and the version we''re about to release. We are asking you (yes you!) to *try out* the release candidate. If something that changed between 3.0.5 and this release candidate breaks your application, we want to know about it! ## How do I try it out? Simply update your Gemfile to point at the rails version "3.0.6.rc1", then `bundle install`. ## Where can I see a list of Changes? Either look at the CHANGELOG in each particular project on [github](https://github.com/rails/rails/tree/3-0-6), *or* check out the handy [compare view](https://github.com/rails/rails/compare/v3.0.5...v3.0.6.rc1). Again, per project changelogs: https://github.com/rails/rails/tree/3-0-6 *or* compare view: https://github.com/rails/rails/compare/v3.0.5...v3.0.6.rc1 ## ZOMG SOMETHING BROKE, WHAT DO I DO? Email the [rails core mailing list](http://groups.google.com/group/rubyonrails-core) at let us know about the problem! We will discuss the problem and how to handle it before the final version is pushed. ## WHEN WILL THE FINAL VERSION BE RELEASED?!?!?! Unless there are problems found in the RC, we will release the final version no less than 72 hours from *now*, but not exactly 72 hours from now (as I will be on vacation :-P). If there are problems found in the RC, we will release another RC and give the community another chance to test before releasing. ## IN CLOSING Remember, this is *your* chance to veto / postpone our release. Despite the lols I have in this email, please take advantage of this opportunity! We do not want to break people''s applications. The best we can do is ask for help! Thanks for listening everyone! <3 <3 <3 <3 <3 -- Aaron Patterson http://tenderlovemaking.com/
You should run `bundle update` rather than `bundle install`, because `bundle update` ignores & updates the Gemfile.lock file, whereas `bundle install` doesn''t. -- Ryan Bigg On Wednesday, 30 March 2011 at 8:06 AM, Aaron Patterson wrote:> ZOMG HAPPY TUESDAY (UTC-7)!!! <3<3<3<3<3 > > I am happy to announce that the first release candidate for Rails 3.0.6 has > been pushed to rubygems.org. > > ## Release Candidate: What does it mean? > > The release candidate is very similar to what we will actually release for > version 3.0.6. The reason that we release an RC is so that the community can > have a chance to postpone or veto commits that have happened between the > previous version and the version we''re about to release. > > We are asking you (yes you!) to *try out* the release candidate. If something > that changed between 3.0.5 and this release candidate breaks your application, > we want to know about it! > > ## How do I try it out? > > Simply update your Gemfile to point at the rails version "3.0.6.rc1", then > `bundle install`. > > ## Where can I see a list of Changes? > > Either look at the CHANGELOG in each particular project on > [github](https://github.com/rails/rails/tree/3-0-6), *or* check out the > handy [compare > view](https://github.com/rails/rails/compare/v3.0.5...v3.0.6.rc1). > > Again, per project changelogs: > > https://github.com/rails/rails/tree/3-0-6 > > *or* compare view: > > https://github.com/rails/rails/compare/v3.0.5...v3.0.6.rc1 > > ## ZOMG SOMETHING BROKE, WHAT DO I DO? > > Email the [rails core mailing list](http://groups.google.com/group/rubyonrails-core) > at let us know about the problem! We will discuss the problem and how to handle > it before the final version is pushed. > > ## WHEN WILL THE FINAL VERSION BE RELEASED?!?!?! > > Unless there are problems found in the RC, we will release the final version > no less than 72 hours from *now*, but not exactly 72 hours from now (as I will > be on vacation :-P). > > If there are problems found in the RC, we will release another RC and give the > community another chance to test before releasing. > > ## IN CLOSING > > Remember, this is *your* chance to veto / postpone our release. Despite the > lols I have in this email, please take advantage of this opportunity! We do not > want to break people''s applications. The best we can do is ask for help! > > Thanks for listening everyone! > > <3 <3 <3 <3 <3 > > -- > Aaron Patterson > http://tenderlovemaking.com/ >-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
On Tue, Mar 29, 2011 at 11:30 PM, Ryan Bigg <radarlistener@gmail.com> wrote:> We are asking you (yes you!) to *try out* the release candidate. If > something > that changed between 3.0.5 and this release candidate breaks your > application, > we want to know about it!ActiveModel::Name does not have :i18n_key method anymore. Robert Pankowecki -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
I also found a bug that occurs on 3.0.5 ruby-1.9.2-p136 :004 > Time.now => 2011-03-30 01:15:20 +0200 ruby-1.9.2-p136 :005 > Date.today => Wed, 30 Mar 2011 ruby-1.9.2-p136 :006 > Date.yesterday => Mon, 28 Mar 2011 ruby-1.9.2-p136 :007 > Time.zone => (GMT+00:00) UTC ruby-1.9.2-p136 :008 > Date.tomorrow => Wed, 30 Mar 2011 As you can see the simple expectation that yesterday = today -1 and tomorrow = today + 1 is apparently not true in some cases. This problem probably happens around midnight in some zones... Do you want me to create tickets for them ? Robert Pankowecki -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
On Tue, Mar 29, 2011 at 3:14 PM, Robert Pankowecki < robert.pankowecki@gmail.com> wrote:> On Tue, Mar 29, 2011 at 11:30 PM, Ryan Bigg <radarlistener@gmail.com> > wrote: > > We are asking you (yes you!) to *try out* the release candidate. If > > something > > that changed between 3.0.5 and this release candidate breaks your > > application, > > we want to know about it! > > ActiveModel::Name does not have :i18n_key method anymore.Yep, this breaks my app too. This commit is the culprit: https://github.com/rails/rails/commit/f80eea3bf30dcceaca3c4a9cd9238bdc44a9e165 -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
I thank that because this bug has been around since 3.0.2 version: https://rails.lighthouseapp.com/projects/8994/tickets/6034-human_attribute_name-scopes-translations-differently-for-nested-classes-since-rails-302 lot of people assumed that using ''.'' instead of ''/'' is the new way of doing things in rails 3 and already changed their scopes in yml files and follow "the new convention". I also already started following a convention of namespacing classes only in modules (never in another classes) because of problems mentioned in https://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/6448-i18n-key-collision-with-namespaced-models#ticket-6448-11 I would have: class Articles module Articles class Articles::Articles This a big break in API and it happens second time during last 5 releases. Could we clarify this thing once for all the time? Robert Pankowecki -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
I meant class Articles module Articles class Articles::Category -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
This issue started here:
https://rails.lighthouseapp.com/projects/8994/tickets/3768-patch-add-full_message-option-to-validations#ticket-3768-69
Then José Valim thought it was a bug and asked me to create another issue:
https://rails.lighthouseapp.com/projects/8994/tickets/5572
Then, this issue was created:
https://rails.lighthouseapp.com/projects/8994/tickets/6448
Then Valim reverted 5572.
Now I know that my i18n locale files should be written like this:
pt-BR:
activerecord:
errors:
models:
my_module/order:
attributes:
amount:
not_a_number: deve ser um número
I think there will be no more confusing regarding this behavior now we
all know what to expect. Maybe there is some documentation missing,
regarding modules and i18n keys.
Best regards,
Rodrigo.
Em 30-03-2011 05:36, Robert Pankowecki escreveu:> I thank that because this bug has been around since 3.0.2 version:
>
https://rails.lighthouseapp.com/projects/8994/tickets/6034-human_attribute_name-scopes-translations-differently-for-nested-classes-since-rails-302
> lot of people assumed that using ''.'' instead of
''/'' is the new way of
> doing things in rails 3 and already changed their scopes in yml files
> and follow "the new convention".
>
> I also already started following a convention of namespacing classes
> only in modules (never in another classes) because of problems
> mentioned in
>
https://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/6448-i18n-key-collision-with-namespaced-models#ticket-6448-11
>
> I would have:
> class Articles
> module Articles
> class Articles::Articles
>
> This a big break in API and it happens second time during last 5
> releases. Could we clarify this thing once for all the time?
>
> Robert Pankowecki
>
--
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.
On Wed, Mar 30, 2011 at 5:47 AM, Rodrigo Rosenfeld Rosas <rr.rosas@gmail.com> wrote:> This issue started here: > > > https://rails.lighthouseapp.com/projects/8994/tickets/3768-patch-add-full_message-option-to-validations#ticket-3768-69 > > Then José Valim thought it was a bug and asked me to create another issue: > > https://rails.lighthouseapp.com/projects/8994/tickets/5572 > > Then, this issue was created: > > https://rails.lighthouseapp.com/projects/8994/tickets/6448 > > Then Valim reverted 5572. > > Now I know that my i18n locale files should be written like this: > > pt-BR: > activerecord: > errors: > models: > my_module/order: > attributes: > amount: > not_a_number: deve ser um número > > I think there will be no more confusing regarding this behavior now we all > know what to expect. Maybe there is some documentation missing, regarding > modules and i18n keys. >There are two problems here. The first problem is that the public API changed between 3.0.5 and 3.0.6.rc1: the i18n_key method was removed. This is a breaking change for applications (mine included) that used this method themselves. To fix this, the method should be restored, with either the 3.0.5 definition or a new definition (depending on the solution for the second, more difficult problem). The second problem is that we now have two competing conventions for where to place translations for attributes of nested models. 3.0.0-3.0.1 used one convention (''module/model''), 3.0.2-3.0.5 used another (''module.model''), and now in 3.0.6 is reverting to the first convention. The change from 3.0.1 to 3.0.2 broke all translations which followed the original convention, and for users on 3.0.2-3.0.5, the change from 3.0.5 to 3.0.6 will break them again. In order to avoid this breaking change, I suggest that we keep ''module/model'' as the documented preferred convention, but for compatibility, try ''module.model'' if no translation is found under ''module/model''. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
On Wed, Mar 30, 2011 at 08:18:45AM -0700, John Firebaugh wrote:> On Wed, Mar 30, 2011 at 5:47 AM, Rodrigo Rosenfeld Rosas <rr.rosas@gmail.com > > wrote: > > > This issue started here: > > > > > > https://rails.lighthouseapp.com/projects/8994/tickets/3768-patch-add-full_message-option-to-validations#ticket-3768-69 > > > > Then José Valim thought it was a bug and asked me to create another issue: > > > > https://rails.lighthouseapp.com/projects/8994/tickets/5572 > > > > Then, this issue was created: > > > > https://rails.lighthouseapp.com/projects/8994/tickets/6448 > > > > Then Valim reverted 5572. > > > > Now I know that my i18n locale files should be written like this: > > > > pt-BR: > > activerecord: > > errors: > > models: > > my_module/order: > > attributes: > > amount: > > not_a_number: deve ser um número > > > > I think there will be no more confusing regarding this behavior now we all > > know what to expect. Maybe there is some documentation missing, regarding > > modules and i18n keys. > > > > There are two problems here. > > The first problem is that the public API changed between 3.0.5 and > 3.0.6.rc1: the i18n_key method was removed. This is a breaking change for > applications (mine included) that used this method themselves. To fix this, > the method should be restored, with either the 3.0.5 definition or a new > definition (depending on the solution for the second, more difficult > problem). > > The second problem is that we now have two competing conventions for where > to place translations for attributes of nested models. 3.0.0-3.0.1 used one > convention (''module/model''), 3.0.2-3.0.5 used another (''module.model''), and > now in 3.0.6 is reverting to the first convention. The change from 3.0.1 to > 3.0.2 broke all translations which followed the original convention, and for > users on 3.0.2-3.0.5, the change from 3.0.5 to 3.0.6 will break them again. > In order to avoid this breaking change, I suggest that we keep > ''module/model'' as the documented preferred convention, but for > compatibility, try ''module.model'' if no translation is found under > ''module/model''.I agree we should support both for now, and deprecate one. I''ll come up with a test and fix, and we''ll release a new RC. Thanks for reporting this! -- Aaron Patterson http://tenderlovemaking.com/
On Wed, Mar 30, 2011 at 01:23:55AM +0200, Robert Pankowecki wrote:> I also found a bug that occurs on 3.0.5 > > ruby-1.9.2-p136 :004 > Time.now > => 2011-03-30 01:15:20 +0200 > ruby-1.9.2-p136 :005 > Date.today > => Wed, 30 Mar 2011 > ruby-1.9.2-p136 :006 > Date.yesterday > => Mon, 28 Mar 2011 > ruby-1.9.2-p136 :007 > Time.zone > => (GMT+00:00) UTC > ruby-1.9.2-p136 :008 > Date.tomorrow > => Wed, 30 Mar 2011 > > As you can see the simple expectation that yesterday = today -1 and > tomorrow = today + 1 is apparently not true in some cases. This > problem probably happens around midnight in some zones... > > Do you want me to create tickets for them ?Yes please. Does this happen on 3.0.4 too? -- Aaron Patterson http://tenderlovemaking.com/
On Wed, Mar 30, 2011 at 5:54 PM, Aaron Patterson <aaron@tenderlovemaking.com> wrote:> I agree we should support both for now, and deprecate one. I''ll come > up with a test and fix, and we''ll release a new RC.Or we could add a setting which version you prefer.> Thanks for reporting this!Thanks for RC release and the ability to test and veto :-) Robert Pankowecki -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
On Wed, Mar 30, 2011 at 5:55 PM, Aaron Patterson <aaron@tenderlovemaking.com> wrote:>> As you can see the simple expectation that yesterday = today -1 and >> tomorrow = today + 1 is apparently not true in some cases. This >> problem probably happens around midnight in some zones... >> >> Do you want me to create tickets for them ? > > Yes please. Does this happen on 3.0.4 too?Yes 3.0.4, 3.0.5, 3.0.6.rc1, maybe even earlier versions. https://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/6654-dateyesterday-and-datetomorrow-returns-wrong-values Robert Pankowecki -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
On Wed, Mar 30, 2011 at 08:33:28PM +0200, Robert Pankowecki wrote:> On Wed, Mar 30, 2011 at 5:55 PM, Aaron Patterson > <aaron@tenderlovemaking.com> wrote: > >> As you can see the simple expectation that yesterday = today -1 and > >> tomorrow = today + 1 is apparently not true in some cases. This > >> problem probably happens around midnight in some zones... > >> > >> Do you want me to create tickets for them ? > > > > Yes please. Does this happen on 3.0.4 too? > > Yes 3.0.4, 3.0.5, 3.0.6.rc1, maybe even earlier versions.We''ll discuss this on LH, but this ticket won''t block the release.> https://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/6654-dateyesterday-and-datetomorrow-returns-wrong-valuesThanks for filing this! -- Aaron Patterson http://tenderlovemaking.com/
On Wed, Mar 30, 2011 at 08:18:45AM -0700, John Firebaugh wrote:> On Wed, Mar 30, 2011 at 5:47 AM, Rodrigo Rosenfeld Rosas <rr.rosas@gmail.com > > wrote: > > > This issue started here: > > > > > > https://rails.lighthouseapp.com/projects/8994/tickets/3768-patch-add-full_message-option-to-validations#ticket-3768-69 > > > > Then José Valim thought it was a bug and asked me to create another issue: > > > > https://rails.lighthouseapp.com/projects/8994/tickets/5572 > > > > Then, this issue was created: > > > > https://rails.lighthouseapp.com/projects/8994/tickets/6448 > > > > Then Valim reverted 5572. > > > > Now I know that my i18n locale files should be written like this: > > > > pt-BR: > > activerecord: > > errors: > > models: > > my_module/order: > > attributes: > > amount: > > not_a_number: deve ser um número > > > > I think there will be no more confusing regarding this behavior now we all > > know what to expect. Maybe there is some documentation missing, regarding > > modules and i18n keys. > > > > There are two problems here. > > The first problem is that the public API changed between 3.0.5 and > 3.0.6.rc1: the i18n_key method was removed. This is a breaking change for > applications (mine included) that used this method themselves. To fix this, > the method should be restored, with either the 3.0.5 definition or a new > definition (depending on the solution for the second, more difficult > problem). > > The second problem is that we now have two competing conventions for where > to place translations for attributes of nested models. 3.0.0-3.0.1 used one > convention (''module/model''), 3.0.2-3.0.5 used another (''module.model''), and > now in 3.0.6 is reverting to the first convention. The change from 3.0.1 to > 3.0.2 broke all translations which followed the original convention, and for > users on 3.0.2-3.0.5, the change from 3.0.5 to 3.0.6 will break them again. > In order to avoid this breaking change, I suggest that we keep > ''module/model'' as the documented preferred convention, but for > compatibility, try ''module.model'' if no translation is found under > ''module/model''.Just so we''re on the same page, we would expect this test to pass: diff --git a/activemodel/test/cases/translation_test.rb b/activemodel/test/cases/translation_test.rb index 1db63e1..0584606 100644 --- a/activemodel/test/cases/translation_test.rb +++ b/activemodel/test/cases/translation_test.rb @@ -39,6 +39,15 @@ class ActiveModelI18nTests < ActiveModel::TestCase assert_equal ''person gender attribute'', Person::Gender.human_attribute_name(''attribute'') end + def test_translated_model_attributes_with_attribute_matching_namespaced_model_name_and_dot + assert_deprecated do + I18n.backend.store_translations ''en'', :activemodel => {:attributes => {:person => {:gender => ''person gender''}, :"person.gender" => {:attr + end + + assert_equal ''person gender'', Person.human_attribute_name(''gender'') + assert_equal ''person gender attribute'', Person::Gender.human_attribute_name(''attribute'') + end + def test_translated_model_names I18n.backend.store_translations ''en'', :activemodel => {:models => {:person => ''person model''} } assert_equal ''person model'', Person.model_name.human If that''s true, I''ll try to get another RC out tonight. If not, we may have to wait for a few days as I''ll be on vacation. :-( -- Aaron Patterson http://tenderlovemaking.com/
On Mar 30, 2011, at 7:18 PM, Aaron Patterson wrote:> I''ll be on vacation. :-DFixed that for you. :) -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
On Wed, Mar 30, 2011 at 08:18:45AM -0700, John Firebaugh wrote:> On Wed, Mar 30, 2011 at 5:47 AM, Rodrigo Rosenfeld Rosas <rr.rosas@gmail.com > > wrote: > > > This issue started here: > > > > > > https://rails.lighthouseapp.com/projects/8994/tickets/3768-patch-add-full_message-option-to-validations#ticket-3768-69 > > > > Then José Valim thought it was a bug and asked me to create another issue: > > > > https://rails.lighthouseapp.com/projects/8994/tickets/5572 > > > > Then, this issue was created: > > > > https://rails.lighthouseapp.com/projects/8994/tickets/6448 > > > > Then Valim reverted 5572. > > > > Now I know that my i18n locale files should be written like this: > > > > pt-BR: > > activerecord: > > errors: > > models: > > my_module/order: > > attributes: > > amount: > > not_a_number: deve ser um número > > > > I think there will be no more confusing regarding this behavior now we all > > know what to expect. Maybe there is some documentation missing, regarding > > modules and i18n keys. > > > > There are two problems here. > > The first problem is that the public API changed between 3.0.5 and > 3.0.6.rc1: the i18n_key method was removed. This is a breaking change for > applications (mine included) that used this method themselves. To fix this, > the method should be restored, with either the 3.0.5 definition or a new > definition (depending on the solution for the second, more difficult > problem). > > The second problem is that we now have two competing conventions for where > to place translations for attributes of nested models. 3.0.0-3.0.1 used one > convention (''module/model''), 3.0.2-3.0.5 used another (''module.model''), and > now in 3.0.6 is reverting to the first convention. The change from 3.0.1 to > 3.0.2 broke all translations which followed the original convention, and for > users on 3.0.2-3.0.5, the change from 3.0.5 to 3.0.6 will break them again. > In order to avoid this breaking change, I suggest that we keep > ''module/model'' as the documented preferred convention, but for > compatibility, try ''module.model'' if no translation is found under > ''module/model''.Sorry, I meant this: diff --git a/activemodel/test/cases/translation_test.rb b/activemodel/test/cases/translation_test.rb index 1db63e1..4deffc3 100644 --- a/activemodel/test/cases/translation_test.rb +++ b/activemodel/test/cases/translation_test.rb @@ -39,6 +39,15 @@ class ActiveModelI18nTests < ActiveModel::TestCase assert_equal ''person gender attribute'', Person::Gender.human_attribute_name(''attribute'') end + def test_translated_model_attributes_with_attribute_matching_namespaced_model_name_and_dot + assert_deprecated do + I18n.backend.store_translations ''en'', :activemodel => {:attributes => {:person => {:gender => ''person gender''}, :"person.gender" => {:attribute => ''person gender attribute''}}} + end + + assert_equal ''person gender'', Person.human_attribute_name(''gender'') + assert_equal ''person gender attribute'', Person::Gender.human_attribute_name(''attribute'') + end + def test_translated_model_names I18n.backend.store_translations ''en'', :activemodel => {:models => {:person => ''person model''} } assert_equal ''person model'', Person.model_name.human -- Aaron Patterson http://tenderlovemaking.com/
On Wed, Mar 30, 2011 at 4:29 PM, Aaron Patterson <aaron@tenderlovemaking.com> wrote:> + def > test_translated_model_attributes_with_attribute_matching_namespaced_model_name_and_dot > + assert_deprecated do > + I18n.backend.store_translations ''en'', :activemodel => {:attributes > => {:person => {:gender => ''person gender''}, :"person.gender" => {:attribute > => ''person gender attribute''}}} > + end > + > + assert_equal ''person gender'', Person.human_attribute_name(''gender'') > + assert_equal ''person gender attribute'', > Person::Gender.human_attribute_name(''attribute'') > + end > + >No, it''s in spirit something more like: def test_deprecated_namespaced_model_attribute_translation assert_deprecated do I18n.backend.store_translations ''en'', :activemodel => {:attributes => {:person => {:gender => {:attribute => ''person gender attribute''}}}} end assert_equal ''person gender attribute'', Person::Gender.human_attribute_name(''attribute'') end I''m not sure how to make the assert_deprecated part of that pass though... BTW, have a great vacation! :-) -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Attached is my proposed patch for the translation issue. I think we should support both conventions and deprecate neither. The newer convention is cleaner when you nest multiple models within one namespace: en: activemodel: models: namespace: model_one: one: Model One other: Model Ones model_two: one: Model Two other: Model Twos Vs: en: activemodel: models: namespace/model_one: one: Model One other: Model Ones namespace/model_two: one: Model Two other: Model Twos The newer convention fails only when you nest models within models, which is probably uncommon compared to nesting models in modules. In that case, if you use the old namespace/model convention, the lookup following the old convention will simply fail, and I18n.translate will move on and try the namespace/model convention. So I think it''s safe to support both. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.