a proposed solution for localized templates

[nnovik]

Hi all, I've been poking at globalize with Rails Edge, and it's dying because of the Rails overhaul of ActionView and templates, but in a good cause. The following Rails 2.0 change:

multiple controller view paths

renders localized templates trivial to do. It seems to me the best solution at this point is to simply ditch lib/globalize/lib/rails/action_view.rb and just let users move this into the main application logic like so: (taken from a sample application.rb):

  before_filter :set_locale  
  # Determines the user's language of choice
  def set_locale
     
    (...typical code that among other things sets @locale to user's locale here...)
    
    # use the user's locale in their view path
    prepend_view_path File.join(File.dirname(__FILE__), '..', "views/localized/#{@locale}")
  end 

This particular solution will cause Rails to go look in views/localized/[locale]/ first and then fall back to the normal structure. So for instance, I have views/users/show.html.erb as the default, and then I have views/localized/fr/users/show.html.erb. When the viewer's locale is set to 'fr' the latter is the version that will appear.

This allows for individual-application control over how localized templates are managed, sequesters these templates nicely, and eliminates the need for globalize itself to be modified for future versions of Rails if future changes happen in this area.

Does anyone have thoughts on this? See a problem I've missed with this solution?

[Chris Cruft]

Novik,

I was looking in this same area last week and I'm pretty sure I agree with you.  FWIW, I think the same thing can apply to ActionMailer.

Somebody needs to take the bull by the horns and wrest commit access from the existing core and fix this (and myriad other problems/opportunities) on Edge.

-Chris

On 2 May 2008, at 16:59, nnovik wrote:

Hi all, I've been poking at globalize with Rails Edge, and it's dying because of the Rails overhaul of ActionView and templates, but in a good cause. The following Rails 2.0 change:

multiple controller view paths

renders localized templates trivial to do. It seems to me the best solution at this point is to simply ditch lib/globalize/lib/rails/action_view.rb and just let users move this into the main application logic like so: (taken from a sample application.rb):

  before_filter :set_locale  
  # Determines the user's language of choice
  def set_locale
     
    (...typical code that among other things sets @locale to user's locale here...)
    
    # use the user's locale in their view path
    prepend_view_path File.join(File.dirname(__FILE__), '..', "views/localized/#{@locale}")
  end 

This particular solution will cause Rails to go look in views/localized/[locale]/ first and then fall back to the normal structure. So for instance, I have views/users/show.html.erb as the default, and then I have views/localized/fr/users/show.html.erb. When the viewer's locale is set to 'fr' the latter is the version that will appear.

This allows for individual-application control over how localized templates are managed, sequesters these templates nicely, and eliminates the need for globalize itself to be modified for future versions of Rails if future changes happen in this area.

Does anyone have thoughts on this? See a problem I've missed with this solution?

---

View this message in context: a proposed solution for localized templates
Sent from the Globalize-rails.org mailing list archive at Nabble.com.

[Nicola Piccinini]

it's a clever idea, I believe.

I can say that I was using globalize with RoR 2.0.2 for a while with
that ActionView code commented out. Everything seems to work correctly
with the obvious exception of template localization.

Btw, in this days I had the hare-brained idea to switch to the "soon
to be released" RoR 2.1.
The good news is that most of Globalize continue to work but not all
and so I had to write some patches.

We all know that Rails has moved to git, this SCM tool should be very
efficient in managing distributed development and probably also
Globalize could benefit of this sort of organization.
So I created a personal space at github and I forked Globalize
starting from trunk@183:
http://github.com/pic/globalize

Then I committed my patches so anyone can look at them, any comment is
well appreciated.

In current status the test suite is broken for every test regarding
template localization, in fact I removed action_view.rb without
implementing an alternative solution.
Moreover I had to disable a lot of tests of date helpers because with
RoR 2.1 the order of attributes in rendering an <option> tag is
changed. I don't know how much solid is testing those helpers with
string comparisons, how can we be sure that RoR will render:

<option selected="selected" value="10">

instead of

<option value="10" selected="selected">

in any possible environment?

Anyway for my needs the current status is more than sufficient.

Let me know If my fork of Globalize on a github repository is
inappropriate that I'll remove it in a minute.

Nicola