Forum: Rails I18n User interface locale VS content locale

A4fa2e5a04dfad8b71cd83c8becb42a3?d=identicon&s=25 hydrozen (Guest)
on 2011-08-05 00:34
(Received via mailing list)
Hi,

I'm working on a little content management system where the user can
manage content that is translated in multiple languages. The UI of the
CMS itself is also available in multiple languages so I need to be
able to display the UI in english while the user is managing french
content. I am not sure of the smart way to handle this. Using
something like Globalize3 you end up having to keep switching the
value of I18n.locale back and forth when calling I18n.translate for
the UI or when displaying data from the model.

Anyone has tips or ideas?
4a551074ddba4460f95d011c47190d0e?d=identicon&s=25 Henrik --- (malesca)
on 2011-08-05 00:42
(Received via mailing list)
Perhaps Object#with_options plus the :locale param could be helpful.
Something like

I18n.locale = :en
# English
t(:"welcome")
with_options(:locale => :fr) do |trans|
  # French
  trans.t(:"hello")
end
# English
t(:"goodbye")

Or define a method like

  def self.in_locale(locale)
    old_locale = I18n.locale
    I18n.locale = locale
    yield
  ensure
    I18n.locale = old_locale
  end

and you could do stuff like

I18n.locale = :en
# English
t(:"welcome")
I18n.in_locale(:fr) do
  # French
  t(:"hello")
end
# English
t(:"goodbye")
4a551074ddba4460f95d011c47190d0e?d=identicon&s=25 Henrik --- (malesca)
on 2011-08-05 00:43
(Received via mailing list)
On Fri, Aug 5, 2011 at 00:40, Henrik Nyh <henrik@nyh.se> wrote:
> def self.in_locale(locale)
>     ...
>  end

Make that

module I18n
 def self.in_locale(locale)
     ...
  end
end
A4fa2e5a04dfad8b71cd83c8becb42a3?d=identicon&s=25 hydrozen (Guest)
on 2011-08-05 16:09
(Received via mailing list)
Yes I thought of this and Globalize3 already has a utility for this
called called with_locale to which you can pass a locale and a block.
But even with this it seems like it ends up being an hassle.
So basically, every time I want to display data from a model, I'll
need to wrap the call into that function to make sure I display using
the content locale and not the ui locale. If I display forms, I'll
also need to wrap each field into that function too.. making sure I
don't wrap any calls to I18n.translate.
6e6ad40d40c15fecdd1060573156d65f?d=identicon&s=25 Martin Svalin (Guest)
on 2011-08-05 16:40
(Received via mailing list)
Well, why not hack up I18n a bit?

Let I18n.locale be the content locale, but hack in a new I18n.ui_locale
method, and a I18n.ui_translate method that wraps I18n.translate inside
a
I18n.with_locale(I18n.ui_locale) {...}

Then you can mix ui and content freely by simply calling different
translation methods for them.

Or something... never tried it. Personally I'd just use I18n.with_locale
here and there, but we don't mix locales as much.

- Martin

PS. I had fun looking up how I18n.locale is stored (considering I18n is
a
module).
A4fa2e5a04dfad8b71cd83c8becb42a3?d=identicon&s=25 hydrozen (Guest)
on 2011-08-05 20:08
(Received via mailing list)
Yeah I think I'll look into the rails-i18n code and Globalize3 code
over the weekend. It seems like Globalize3 also stores a setting in
the Thread called :globalize_locale. I wonder if that means I could
have a different setting for the UI and for the Content. I was mostly
opening up a discussion to see if others had the same kinda problems
to solve.

Thanks for the feedback.
A4fa2e5a04dfad8b71cd83c8becb42a3?d=identicon&s=25 hydrozen (Guest)
on 2011-08-06 16:24
(Received via mailing list)
After a big of digging, it turns out that both Globalize2 and
Globalize3 use I18n.locale as a default locale but provide a way to
override that setting.

When using Globalize2 you can do:
ActiveRecord::Base.locale = :fr

When using Globalize3 you can do:
Thread.current[:globalize_locale] = :fr

and then you don't have to keep toggling I18n.locale back and forth ;)
A4fa2e5a04dfad8b71cd83c8becb42a3?d=identicon&s=25 hydrozen (Guest)
on 2011-08-07 01:19
(Received via mailing list)
Actually, for Globalize2 it might also be better to store in
Thread.current. Correct me if I'm wrong but changing it in
ActiveRecord::Base would affect all users and not just this single
request?
This topic is locked and can not be replied to.