Forum: Rails I18n Globalize1 migration path, scopes and namespaces

Hi,

I am working on this plugin I am calling globalize_bridge. It is meant
to provide a seamless migration path for rails apps using Globalize
(1) and utilizing the built in rails I18n mechanism. I am pretty much
done covering the entire scope of mapping the Globalize API, however,
only Globalize namespaces still make me scratch my head.

The problem is: with a translation string "Foo. And Bar.".t,
containing periods, the "." is mistaken for the scope separator.
Luckily, later versions of the I18n gem have the scope_separator
directive, to support gettext, etc. So this come handy for Globalize1
usage, however, Globalize also had the concept of namespaces (~ I18n
scopes), and it would be a shame if we could port the namespaces over.

Here is an example:

"Foo. And Bar.".tn(:my_namespace)   # Globalize1 syntax

# translates into this

I18n.t "Foo. And Bar.", :separator => "\001", :scope => :my_namespace

So this does not pick up the correct translation and ignores the scope
altogether.

I was looking for a seamless solution. However, the only workaround I
can think of is to define a secondary separator e.g. :separator => "|"
tweak my translations yml/db.

Anyone having a better idea?

Greetings,
Juergen

On Sat, Mar 6, 2010 at 19:40, Jürgen Feßlmeier
<jfesslmeier@googlemail.com> wrote:
> "Foo. And Bar.".tn(:my_namespace)   # Globalize1 syntax
>
> # translates into this
>
> I18n.t "Foo. And Bar.", :separator => "\001", :scope => :my_namespace
>
> So this does not pick up the correct translation and ignores the scope
> altogether.

One solution would be to replace the translation keys, e.g. with a
slugalized version of the string. So you'd use "foo_and_bar" in this
case. ActiveSupport has String#parameterize for that.

Then you could stick the original "Foo. And Bar." string into a yml
file instead (YAMLator may be helpful in this:
http://gist.github.com/293581).

Sounds like a useful plugin.

Hi Henrik,

that's a pretty smart idea!

The plugin utilizes I18n::Backend::Database plugin as the
ViewTranslation replacement by default, so the string is automatically
added. However, YAMLator could be an interesting tool if one decides
to add a special backend and add translations automatically to the YML
files.

Just need to make sure that the user understands that the string in
all or some cases is slugalized if not automatically written and how
to deal with it (what it is converted to, etc.).

Thanks for your input.

Greetings,
Juergen