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 2010-03-06 19:45
on 2010-03-06 21:06
On Sat, Mar 6, 2010 at 19:40, Jürgen Feßlmeier <email@example.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.
on 2010-03-06 21:41
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