-
Notifications
You must be signed in to change notification settings - Fork 161
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
Track translation keys #457
Comments
Coverband doesn't currently support this, in theory we could add another plugin or adapter to capture it, but I am unlikely to do so any time soon. If you wanted to make a branch that supported it I could take a look, but for a single company might be best to just start with a new gem. This old gem is out of date but is exactly what you want, a co-worker wrote this when I was at livingsocial and we used it there to clean up our translation keys. https://github.com/livingsocial/humperdink I believe most of the logic would still be good but the railtie and some of the methods or hooks might have changed since then. Take a look @Systho and let me know if that looks like what you want. |
Had the same issue a while back. A colleague made that: https://github.com/sergioisidoro/e7o It's a similar low overhead tool you can easily plop into prod. |
Note the current RC release has translation key tracking....
view of the integration: |
Is your feature request related to a problem? Please describe.
When most of the application grows, they keep legacy translation keys which are not used in the app anymore but nobody knows for sure they are not used. Looking in the codebase for the exact key won't work because sometimes we build the key programatically.
Eventually we end up with a huge translation .yml file and when trying to introduce a new language, it's very difficult to know which keys need translation and which do not. The problem is the same for any kind of global renaming of a concept.
Describe the solution you'd like
I wish that every call to I18n.t would trigger an update of the value "last usage" for the relevant key and being able to visualise which key have not been used for a long time. This use case is very similar to tracking views.
Describe alternatives you've considered
I've considered building a similar tracking on my test suite but I would need certainty that my e2e tests cover every corner of the app, which they don't.
Additional context
The text was updated successfully, but these errors were encountered: