internationalizing a gem: conventions?

17 views
Skip to first unread message

Dave Aronson

unread,
Jun 28, 2013, 2:07:02 PM6/28/13
to rubyonrails-talk
I need a pinch of help on internationalizing a gem. (Google Search
thinks I want help on an internationalization gem, not the same
thing.)

The question is, what is the accepted standard way to include
$LANGUAGE.yml files in a gem, and get I18n to acknowledge it?

From looking at a few other gems I'm using, it looks like the usual
way is to put it in lib/$GEMNAME/locale/$LANGUAGE.yml, or possibly
config/locales (plural despite the other being singular, go fig).
Either way, though, I don't see how it then gets picked up by I18n.
(I've tried just putting it there and neither seems to work.) I
could, in lib/$GEMNAME.rb or some such, add it to I18n.load_path.
However, that seems rather brute-force, and like the kind of thing
that there's probably already a convention for getting it done
automagically, at least for Rails apps if not Ruby.

Or maybe I'm going about the whole setup the wrong way. Gemfile has:

gem '$GEMNAME', :git => 'davearonson/$GEMNAME', :branch =>
'add-missing-translations'

(since I'm doing this in a Github-based fork of someone else's
existing gem) and I've done:

bundle config local.$GEMNAME ~/path/to/project/$GEMNAME/

from the command line, and I'm doing this work in that directory. The
Rails app itself is in a *parallel* directory,
~/path/to/project/$RAILSAPP. The other gems are down under vendor
(bundle install --path vendor); would it work better if I put this one
down there with them? Putting garbage in lib/$GEMNAME.rb does make
Rails barf, so I know Rails is picking up the gem from the right
place. Did I maybe miss some step?

(And before someone says "well you shouldn't be using a variable
there, put the actual name", I'm just using $GEMNAME as a placeholder
in this message; for real, I did actually use the real gem name.)

Thanks,
Dave

--
Dave Aronson, the T. Rex of Codosaurus LLC,
secret-cleared freelance software developer
taking contracts in or near NoVa or remote.
See information at http://www.Codosaur.us/.

Walter McGinnis

unread,
Jun 29, 2013, 4:00:44 AM6/29/13
to rubyonra...@googlegroups.com
In my experience with Rails 2.3, you need to add your I18n.load_path. Here's my creaky old example:




--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-ta...@googlegroups.com.
To post to this group, send email to rubyonra...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/CAHxKQig9WxwrmhwOuR916ukPPPqfA8gTeqa43n8qm3L0A4_GaA%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.



Dave Aronson

unread,
Jun 29, 2013, 6:32:24 PM6/29/13
to rubyonra...@googlegroups.com
On Sat, Jun 29, 2013 at 4:00 AM, Walter McGinnis
<walter....@gmail.com> wrote:

> In my experience with Rails 2.3, you need to add your I18n.load_path.

This is for 3.2, but since nobody has come forth with an "Oh, yeah,
just stick it in
lib/$GEMNAME/magic/locales/loadme/whizbang/$LANGUAGE.yml and it'll get
slurped right up", I ass-u-me'd that was still the case. I put it in
config/locales/en.yml like the gem author said to do, added that dir
to the load_path, and it works fine.

Walter McGinnis

unread,
Jun 29, 2013, 8:30:49 PM6/29/13
to rubyonra...@googlegroups.com
It's probably worth mentioned that this was done in an config.to_prepare block:



--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-ta...@googlegroups.com.
To post to this group, send email to rubyonra...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages