config.assets.initialize_on_precompile = false
On the other hand i18n-js requires this to be true. Any idea on how to use i18n-js when deploying to Heroku except manually exporting translations before each push...?
Found the same issue here: jwhitley/requirejs-rails#29
Hey. This asset pipeline thing is too complex. :(
I'm thinking about removing support for it from the i18n-js gem and adding it to its own gem. I don't use pipeline myself. Don't like it and I think that we were well served by external libs. That said, I don't really know how to help you. :(
Hi Nando, I resorted to compiling assets locally pre deploy and push to Heroku from a separate branch and everything works just fine now. I also figured that if I weren't using Devise it would have worked with that particular setting being set to true. Please don't remove support for the asset pipeline, it works very well and thanks by the way for this gem :)
I'm really wanting to use i18n-js, but this issue makes it a show stopper for my project.
I wonder if it would be possible to just manually load up the I18n subsystem from Rails, without requiring the whole environment to be loaded? Does i18n-js require anything more than access to the I18n.backend?
@malclocke the problem is that the Rails environment must be fully loaded, otherwise some translations would be missing (engines/railties can add translations as well).
If you're setting config.assets.initialize_on_precompile = false, then the only alternative I can think of is serving translations from your controller's action.
config.assets.initialize_on_precompile = false
Hi, I'm having the exact same problem that @carhartl pointed out.
I didn't know that i18n-js was not compatible with heroku. This should probably be included in the gem's README somewhere; I found out when deploying to my staging server.
@carhartl , I would love to see your (anonymized) deploy script/solution. Is it online somewhere?
@kikito I was using a fork of the kumade gem for this, that supports the asset pipeline and with that defined the precompilation as pre deploy task. It's pretty straightforward, even though we're no longer using it, you can find the fork in my repositories. I need to lookup and gist the rake task for this, it's quite a while that we changed it.
@kikito Wait, you just need the kumade fork and are ready to go with kumade deploy.
I think there's now also a labs feature by Heroku that enables database access as well as the entire environment during precompilation.
Hi @carhartl, thanks for answering. I have been browsing your kumade fork and, while it probably works, I'd rather not use a tool that thoughbot marks as deprecated.
I've had more luck with the heroku labs feature that you mention, which I believe it's labs-user-env-compile.
I activated it on my app:
$ heroku labs:enable user-env-compile
And reactivated config.assets.initialize_on_precompile on my config/application.rb file:
config.assets.initialize_on_precompile = true # enabled due to i18n-js
And then could remove the generated /app/assets/i18n/translations.js file from my repo. It seems to be self-regenerating on heroku now, after every push. I still need to do more tests, I will let you guys know if I find anything else.
"heroku labs:enable user-env-compile" is solving the problem currently. Thanks!
I'm having a tough time figuring out how to run this Heroku. Exporting the translation file for each deploy is less then ideal and frankly, somewhat out of the question. However, I am reading that any temporary written files will be deleted upon restarting a dyno . I would have assumed that the following would have correctly compiled any new translations.
However, this does not seem to work. I am really curious as to what's the problem. Can someone elaborate?
I'm currently having the same problem of deploying to Heroku — which does not update I18n.translations for some reason (rails 4.1).
@fnando @PikachuEXE or whoever maintains this gem at the moment: this is a major issue and it should be mentioned in README, not closed.
I'm currently balancing between setting I18n.translations manually (and trivially) and ditching this gem altogether.
Please tell us what setup you are using.
Do you precompile the i18n files? or export them?
What changes are made to translations? (changing content of existing locale files or adding new locale files?)
Hi, my setup is pretty standard, rails 4.1, backbone, nothing fancy. I've just seen i18n-js not picking up the changes in i18n-js.yml while developing locally — until I ran rake assets:clobber. And with Heroku, the latter doesn't even help, i18n-js doesn't seem to pick changes to the en.yml while precompiling during push.
So the issue is "Changes to config file does not get picked up by gem"?
If so please open a new issue and move the discussion there :)
@PikachuEXE Let's focus on the title issue, and once it's solved, we'll see what we're missing (I was trying to be helpful with additional symptoms, but the Heroku deployment is the actual showstopper).
Now do you have a (sample) app with asset-pipeline-integrated i18n-js deployed to Heroku to check against?
So your problem should be:
heroku run rake assets:precompile
I don't know how Heroku cache the assets
I do my precompiling on local machine
Can you reproduce the problem if you try to precompile locally?
(i.e. does it generate new file if any locale file content changed)
Also make sure you are using 3.0.0.rc*
I will try to debug the issue before working it around — it's a current showstopper for me after all — but my idea was to get someone else working on this ;)
@costa can you manually include the JS files you need into your application.js manifest file?
I tried everything for heroku and nothing worked except bumping the assets.version number in config/iniitalizers/assets.rb. That did not work for you all?
@nicops Doesn't work for me either.
@johnnyshields I've just got back to it, and it kinda worked for me as it should just now (Rails 4.1.9), through second deploy though, will keep an eye on it and report.
So what's the accepted solution / fix / work around for this !?
So, to conclude (hopefully), it works for me now just as it should, not sure if Heroku has anything to do with the improvement, but the most notable changes on my side are:
- i18n-js (3.0.0.rc7)
+ i18n-js (3.0.0.rc8)
- rails (4.1.7)
+ rails (4.1.8)
- sprockets (2.11.3)
+ sprockets (2.12.3)
I don't think any change in rails would cause this
Try switching i18n & sprockets, can't be sure which one cause it
You might want to try a "solution" provided in #283 too
@PikachuEXE Umm, just making sure you're not talking to me 'cause I've just reported it working.
LOL, didn't read it carefully enough
Perhaps this is working on Rails 4 but I still have issues on Rails 3. Have to purge CloudFront and Memcache to ensure new assets files are generated.