-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
revisions.log full of translation missing: en.capistrano.revision_log_message #2080
Comments
Often times this warning means that someone has overwritten the i18n (internationalization) hash incorrectly, and has maybe blanked out a sub-section of the translations. You can see that string, unchanged for around 5 years here capistrano/lib/capistrano/i18n.rb Line 26 in d369967
I'd look for any add-ons, or changes to the i18n hash in your own code, and ensure that someone isn't overwriting it too aggressively, and overwriting the built-in translation texts. |
Thx! Will do - still find it baffling when all I do (with I18n) is add da.yml- but again: thx 🙏 |
If you share what you are doing, maybe we can shed some more light. On the end of |
I've trawled through all code and the only change I can find to remotely 'be in the way' of Capistrano is this one
So - I've changed that last line to Hopefully I can report back that it all accrues from my own [wrong]doings |
dang - I'm afraid it wasn't that easy 😢
So - this is not a life threatening issue - but if you guys have any idea where I should start looking... I know - you'd like to see what it's all about - and it's not like there is any hidden pond of gold is this small warehouse mgmt system I'm helping a friend out on but I guess I'm not too proud of the quality and missing tests and all - so I really would like just to offer bits and pieces; and if that is not enough to go on, I'm totally okay with that - then I'll just have to find that darn release version some other way |
Changes to Some things to sanity check, though:
|
hi @leehambley - it's so good of you to hang in there with me 😅
|
Hi @wdiechmann sorry I don't know what can be going wrong, you could try toggling those gems on-and-off and see what ones maybe do something with the I18n translations. I'm rather sure it's not a Capistrano fault. |
I'm having this same issue. Not sure what could cause it though? |
It seems that we were loading our Rails application in the deploy.rb so we could access other things and that caused this. To fix it we just added |
Short answer: no. I haven't been a maintainer of Capistrano from the beginning, so I can't speak to the intentions of its original designers, but I don't think cap was meant to support this. We monkey patch global objects in Capistrano to implement its DSL, so there is a good chance this could break your Rails code or vice versa. The i18n issue is probably just one of many weird things that might happen. If you need to reference things from your Rails app during a cap deploy, I suggest extracting those into a separate file under |
Unfortunately what we need to access is Rails credentials which I’m not sure we could load without just loading Rails. But thanks for the quick answer. At least I know there isn’t a “proper way” now. |
Generally when you need to use Rails credentials, you wrap whatever you are doing in a rake task and invoke that from Capistrano. It doesn't always map that easily, but something to consider. |
@will-in-wi thanks for the tip. I’ll have to see how I could make that work. Our Capistrano task that needs these credentials is actually installing Elasticsearch metricbeat and filebeat on the servers and making the config files for those services. Could I somehow call commands inside a Rails rake task that executes commands on those servers? I guess alternatively I could have a Rails rake task that generates the config maybe. |
The latter idea is probably how I'd do it. Have raw Capistrano install everything and then have the rake task output the config file. I'd probably use Depending on the complexity, sometimes it makes sense to use another tool for systems administration (like ansible, puppet, or chef) and then limit Capistrano to application deployment. Then you might put credentials into the systems administration deployment mechanism (like an Ansible Vault) and then dump them into environment variables which Capistrano can read. |
I have the same issue. It turns out that it comes from retrieving credentials from encrypted RAILS application. This retrievement messes up the Capistrano's "I18n" functionality. It works after changing this configuration to |
Steps to reproduce
Adding a second locale file to config/locales folder will have you start seeing
translation missing: en.capistrano.revision_log_message
in your deploy_to (using default)At least that's what I've been able to dig my way back into – 4 months down the road when I suddenly needed the exact revision having been deployed at some time in space 😄
Expected behavior
Not sure - maybe just the 'branch $stage (at $revision) ... like it is now? I don't need any translations
Actual behavior
System configuration
The text was updated successfully, but these errors were encountered: