I need a pinch of help on internationalizing a gem. (Google Search
thinks I want help on an internationalization gem, not the same
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 =>
(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.)
Dave A., 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/.