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).
On Fri, Aug 5, 2011 at 16:08, hydrozen <[email protected]> wrote:
> 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.
>
>
> On Aug 4, 6:41 pm, Henrik Nyh <[email protected]> wrote:
> > On Fri, Aug 5, 2011 at 00:40, Henrik Nyh <[email protected]> wrote:
> > > def self.in_locale(locale)
> > > ...
> > > end
> >
> > Make that
> >
> > module I18n
> > def self.in_locale(locale)
> > ...
> > end
> > end
>
> --
> You received this message because you are subscribed to the Google Groups
> "rails-i18n" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected].
> For more options, visit this group at
> http://groups.google.com/group/rails-i18n?hl=en.
>
>
--
You received this message because you are subscribed to the Google Groups
"rails-i18n" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/rails-i18n?hl=en.
