It appears that when the rubocop-i18n gem is being packaged, the file modes of several files in the gem are not world-readable:

root@h6s7vwieu5opjoe:/var/lib/gems/2.5.0/gems/rubocop-i18n-2.0.0# chmod --recursive --changes o+r .
mode of './Rakefile' changed from 0660 (rw-rw----) to 0664 (rw-rw-r--)
mode of './bin/console' changed from 0770 (rwxrwx---) to 0774 (rwxrwxr--)
mode of './.rubocop_todo.yml' changed from 0660 (rw-rw----) to 0664 (rw-rw-r--)
mode of './rubocop-i18n.gemspec' changed from 0660 (rw-rw----) to 0664 (rw-rw-r--)
mode of './.travis.yml' changed from 0660 (rw-rw----) to 0664 (rw-rw-r--)
mode of './lib/rubocop/rspec/cop_helper.rb' changed from 0660 (rw-rw----) to 0664 (rw-rw-r--)
mode of './lib/rubocop/cop/i18n.rb' changed from 0660 (rw-rw----) to 0664 (rw-rw-r--)
mode of './lib/rubocop/cop/i18n/rails_i18n.rb' changed from 0660 (rw-rw----) to 0664 (rw-rw-r--)
mode of './lib/rubocop/cop/i18n/gettext.rb' changed from 0660 (rw-rw----) to 0664 (rw-rw-r--)
mode of './lib/rubocop/cop/i18n/rails_i18n/decorate_string.rb' changed from 0660 (rw-rw----) to 0664 (rw-rw-r--)
mode of './lib/rubocop/cop/i18n/gettext/decorate_string.rb' changed from 0660 (rw-rw----) to 0664 (rw-rw-r--)
mode of './lib/rubocop/cop/i18n/gettext/decorate_string_formatting_using_percent.rb' changed from 0660 (rw-rw----) to 0664 (rw-rw-r--)
mode of './lib/rubocop/cop/i18n/gettext/decorate_string_formatting_using_interpolation.rb' changed from 0660 (rw-rw----) to 0664 (rw-rw-r--)
mode of './lib/rubocop/cop/i18n/gettext/decorate_function_message.rb' changed from 0660 (rw-rw----) to 0664 (rw-rw-r--)
mode of './.rubocop.yml' changed from 0660 (rw-rw----) to 0664 (rw-rw-r--)
mode of './README.md' changed from 0660 (rw-rw----) to 0664 (rw-rw-r--)
mode of './CHANGELOG.md' changed from 0660 (rw-rw----) to 0664 (rw-rw-r--)
mode of './.gitignore' changed from 0660 (rw-rw----) to 0664 (rw-rw-r--)

The files in lib/ are particularly problematic because if the gem is installed as root (for example, as part of installing the PDK package) then regular users cannot use the gem and receive LoadErrors at runtime.

It appears that rubygems will warn about this condition at gem build time, but it does not fail the build:

$ gem build rubocop-i18n
WARNING: license value 'Apache-2' is invalid. Use a license identifier from
http://spdx.org/licenses or 'Nonstandard' for a nonstandard license.
Did you mean 'Apache-2.0'?
WARNING: lib/rubocop/cop/i18n.rb is not world-readable
WARNING: open-ended dependency on pry (>= 0, development) is not recommended
use a bounded requirement, such as '~> x.y'
WARNING: open-ended dependency on rb-readline (>= 0, development) is not recommended
use a bounded requirement, such as '~> x.y'
WARNING: See http://guides.rubygems.org/specification-reference/ for help
Successfully built RubyGem
Name: rubocop-i18n
Version: 2.0.0
File: rubocop-i18n-2.0.0.gem

See also puppetlabs/pdk#697

Use Case

I'm adding checking with rubocop-i18n to an existing code base so there are a lot of offenses. I'd like to fix the low-hanging fruit first, e.g., multi-line strings, and then move on to the more complex work, e.g., eliminating interpolation. The DecorateFunctionMessage cop checks both of these things and more, so slicing up the work becomes harder.

Describe the Solution You Would Like

I'd like to be able to just run a cop that checks for multi-line strings, or interpolation, and also disable each functionality separately in the RuboCop configuration.

Describe Alternatives You've Considered

I'm using grep right now to allow me to only look at multi-line strings, but it feels like a hack and doesn't allow disabling in the RuboCop config.

In rubocop gem version 1.0 there will be a breaking change (rubocop/rubocop#8490) that will affect rubocop-i18n. That PR with a breaking change has been already merged into master so that means version 1.0 is going to be released reasonably soon.

This is the description of the breaking change:

Change logic for cop department name computation. Cops inside deep namespaces (5 or more levels deep) now belong to departments with names that are calculated by joining module names starting from the third one with slashes as separators. For example, cop Rubocop::Cop::Foo::Bar::Baz now belongs to Foo/Bar department (previously it was Bar).

Due to this rubocop-i18n will need to update its documentation in README.md file to correctly address new department names. Basically the only thing to do is to add I18n/ before all the departments and cop names that would go in .rubocop.yml file. This is required because all the cops in this gem are "deep" (5 levels of nesting).

So instead of this:

GetText:
RailsI18n:
GetText/DecorateString:
GetText/DecorateFunctionMessage:
GetText/DecorateStringFormattingUsingInterpolation:
GetText/DecorateStringFormattingUsingPercent:
RailsI18n/DecorateString:
RailsI18n/DecorateStringFormattingUsingInterpolation:

it should be like this:

I18n/GetText:
I18n/RailsI18n:
I18n/GetText/DecorateString:
I18n/GetText/DecorateFunctionMessage:
I18n/GetText/DecorateStringFormattingUsingInterpolation:
I18n/GetText/DecorateStringFormattingUsingPercent:
I18n/RailsI18n/DecorateString:
I18n/RailsI18n/DecorateStringFormattingUsingInterpolation:

As far as I can see it's the only change due to that PR.

The following code is triggering the RailsI18n/DecorateString cop. That doesn't seem like expected behavior, does it?

      sql = <<~SQL
        "#{table_name}"."id" IN (
          SELECT id
          FROM "#{table_name}",
               jsonb_to_recordset("#{table_name}"."tasks") AS tasks(due_on date)
          WHERE tasks.due_on >= ?
            AND tasks.due_on <= ?
        )
      SQL

After the discussion in #15 , we found there are quite a few other decorators that it would be good to support such as Nn_ p_ and s_. We should consider adding those for the next Y release.

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.

Is your feature request related to a problem? Please describe.
When using this gem inside a Gem project, all text lines in the Gemspec file will be marked as missing a decorator.

Describe the solution you'd like
ANY gemspec file to be ignored by default

Describe alternatives you've considered
Manually adding a line to RuboCop's config file for every cop, or explicitly adding gemspec files to Global exclude sections

Additional context
Gemspecs should be as lean as possible, and I feel it better to have the Cops ignore these gemspecs by default, and not having to extend my configuration either globally for large projects/custom configurations or to list this lien for every Cop

I wish it would auto-correct my code to add the surrounding call to I18n.t()

Describe the solution you'd like
I have yet to look at which other cop that does this already, but I have a feeling we could take example for another cop that does this kind of auto-correct

Describe alternatives you've considered
doing it by hand, after all, I only have a few thousand places to update.

Additional context
N/A

Is your feature request related to a problem? Please describe.

It's not uncommon for new users of gettext to use _() in constants, not realize that will translate at first load and not on demand. This is easy to miss in code review.

Describe the solution you'd like

I'd like to see a Cop that checks for usage of _() in constants. Secondarily, if it's possible, it would useful to also detect memoized usage of _() in a class methods or global context.

Describe alternatives you've considered
Additional context

None

Excuse me, I really appreciate your project, as I need a linter to enforce i18n translations in my views. But can you actually list how to trigger the Rubocop violations? I've installed your gem and added the necessary configuration to the .rubocop.yml added strings with no translations into my view files but it isn't tripping rubocop. Thank you.