Handle situation when I18n date.order values are strings #848
Conversation
| position = ActionView::Helpers::DateTimeSelector::POSITION[position] | ||
| "#{attribute_name}_#{position}i" | ||
| position_value = ActionView::Helpers::DateTimeSelector::POSITION[position_key] | ||
| "#{attribute_name}_#{position_value}i" |
There was a problem hiding this comment.
Any specific reason to change the variable names and not sticking with position only? It seems to just make the diff harder to follow since the real change is the to_sym call.
Thanks.
There was a problem hiding this comment.
position_key made more sense to me re: what the top bit is finding, so I went with it. Don't feel strongly.
Sent from my iPhone
On Jul 16, 2013, at 21:30, Carlos Antonio da Silva [email protected] wrote:
In lib/simple_form/inputs/date_time_input.rb:
position = ActionView::Helpers::DateTimeSelector::POSITION[position]"#{attribute_name}_#{position}i"position_value = ActionView::Helpers::DateTimeSelector::POSITION[position_key]"#{attribute_name}_#{position_value}i"Thansk.
—
Reply to this email directly or view it on GitHub.
There was a problem hiding this comment.
@mjankowski we would prefer not to change this for now. Could you please revert it? :) Thanks!
Rails 4 changes the `date.order` I18n setting to return strings, which resulted in a missed lookup in POSITION, and a value like `date_i` instead of `date_1i` for the `for` attribute on `label` elements.
|
Updated the commit to not change the |
Handle situation when I18n date.order values are strings
|
@mjankowski thank you! |
Rails 4 changes the
date.orderI18n setting to return strings, whichresulted in a missed lookup in POSITION, and a value like
date_iinstead of
date_1ifor theforattribute onlabelelements.