User interface locale VS content locale

[hydrozen]

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?

[Henrik Nyh]

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")

> --
> You received this message because you are subscribed to the Google Groups "rails-i18n" group.
> To post to this group, send email to rails...@googlegroups.com.
> To unsubscribe from this group, send email to rails-i18n+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/rails-i18n?hl=en.
>
>

[Henrik Nyh]

On Fri, Aug 5, 2011 at 00:40, Henrik Nyh <hen...@nyh.se> wrote:
>  def self.in_locale(locale)
> ...
> end

Make that

module I18n
 def self.in_locale(locale)
...
end
end

[hydrozen]

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.

[Martin Svalin]

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). 

[hydrozen]

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.

[hydrozen]

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 ;)

[hydrozen]

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?