Rails 3.0.6.rc1

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

You should run bundle update rather than bundle install, because bundle update ignores & updates the Gemfile.lock file, whereas bundle install doesn’t.

ActiveModel::Name does not have :i18n_key method anymore.

Robert Pankowecki

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

Yep, this breaks my app too.

This commit is the culprit: https://github.com/rails/rails/commit/f80eea3bf30dcceaca3c4a9cd9238bdc44a9e165

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

I meant

class Articles
module Articles
class Articles::Category

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.

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!

Yes please. Does this happen on 3.0.4 too?

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 :slight_smile:

Robert Pankowecki

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

>> 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-values

Thanks for filing this!

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

Fixed that for you. :slight_smile:

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

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! :slight_smile:

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.

0001-Support-both-conventions-for-translations-for-namesp.patch (3.65 KB)