Skip to content
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

Don't require translation for strings not used in the application (Rails I18n) #55

Open
joshbuker opened this issue Jun 30, 2021 · 1 comment

Comments

@joshbuker
Copy link

Is your feature request related to a problem? Please describe.
The sentences used exclusively in your test suite don't need translation, as they are neither user facing, nor integrate with Rails I18n afaik.

For example, the common guard clause in spec/rails_helper.rb:

# Prevent database truncation if the environment is production
if Rails.env.production?
  abort('The Rails environment is running in production mode!')
end

Raises a linting error:

spec/rails_helper.rb:7:9: C: I18n/RailsI18n/DecorateString: decorator is missing around sentence
  abort('The Rails environment is running in production mode!')

Describe the solution you'd like
DecorateString cop automatically ignores strings that should not be covered by I18n (e.g. test suite strings not used in the app itself.

Describe alternatives you've considered
Currently I exclude the entire spec folder from the cop using Exclude, however I'm worried that I may be losing linting functionality for strings in the test suite that should be translated. E.g. when testing error notification strings in system specs.

Additional Context

#54 is a similar issue, although specific to Ruby gems rather than Rails apps.

@pointlessone
Copy link

Specs can be skipped with Exclude key in the Rubocop config.

I'd suggest making exceptions for specific methods. For example, exclude raise from this cop. Often exceptions are intercepted and go to some sort of storage for developer usage (e.g. Sentry). The end-users don't ever see these messages. Instead they see nicer user-facing messages, that are interpretations of the exceptions rather than specific error lines.

I consider exception messages are to be used by the developers and messages for users are coming from a different place. Exception messages might have additional information for the developers who can actually fix the issue. Users usually don't have much power to do the same. And when they do, UI presents them with specific instructions that are not bound to the exception message.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants