Skip to content
noniq edited this page Apr 22, 2013 · 13 revisions

Idea

I've been thinking a lot about the issues that delocalize currently has and has had in the past.

Lots of the issues that we've had with delocalize over the years seem to have come from the fact that it is just too involved with Rails inner workings – ActiveRecord/ActiveModel in particular. The tight coupling to AR/AM is particularly worrying since i18n/l10n are frontend rather than backend concerns: It shouldn't be the model layer's responsibility to parse user input and since delocalize is currently implemented in the model layer, it is doing things on the wrong level.

I think the issue is similar to what we've seen with attr_accessible/attr_protected and the new strong_parameters gem as well as issues outlined by various people about putting business logic into ActiveModel callbacks (e.g. the famous example where creating a user always sends a confirmation email). Hence, I think the solution to the problem at hand is similar: We need to move delocalize from the model to the controller layer.

I think, delocalize could be used for parsing and converting the params hash directly. The syntax could actually be quite similar to the spike branch:

class Admin::ProductsController < Admin::BaseController
  delocalize :product => { :price => :number, :available_at => :datetime }
end

delocalize would then be executed as a before_filter, check if params[:product] is set and finally check for the presence of price and available_at and convert them as usual.

While I acknowledge that this means more setup compared to the original implementation (even more than the spike branch), it has the benefit of being much less involved with Rails' inner workings and thus being much less brittle. Also, delocalizing could be done on a case by case basis (e.g. not using it in API controllers where programmers can be trusted/forced to use certain formats) and even customized as necessary just like any other before_filter.

What are your opinions on this?

Please append your opinions to this wiki page and include your GitHub username followed by the date and your thoughts. Thanks!

Your thoughts

@noniq (22 April 2013)

I think that's exactly the right thing to do, so +1 from me. (Last time I struggled with some problem caused by delocalizing in the model layer, I tried to rethink the whole concept and came to conclusion very similar to yours … never got around to implement it, though :-| )

Clone this wiki locally