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
[email protected] 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:
Helps you update Rails i18n YAML files programmatically. · GitHub).
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