We're not adding the rule because it would apply the current line length
rule of 110 characters per line. We still haven't decided whether we'll
keep that rule or make lines shorter so they're easier to read,
particularly when vertically splitting the editor window.
So, for now, I'm applying the rule to lines which are about 90
characters long.
We were very inconsistent regarding these rules.
Personally I prefer no empty lines around blocks, clases, etc... as
recommended by the Ruby style guide [1], and they're the default values
in rubocop, so those are the settings I'm applying.
The exception is the `private` access modifier, since we were leaving
empty lines around it most of the time. That's the default rubocop rule
as well. Personally I don't have a strong preference about this one.
[1] https://rubystyle.guide/#empty-lines-around-bodies
This spec was causing a side effect on another spec[2], making it fail 😌
I think it was because no translation had been called yet, in the failing spec, and so the the i18n backend translations had not been initialized, and was always returning empty translations for any locale. This might have been due to tampering with translations in the this newly introduced spec.
By forcing translations to load after this new spec, the other spec passes again
[2] https://github.com/AyuntamientoMadrid/consul/blob/master/spec/features/localization_spec.rb#L20
There where two issues with the current implementation:
- There was a possible duplication between looking up the language name in key "locale" and in key "i18n.language.name"
- The "default" option was not being picked up, as the fallback always returned the default locale's translation, "English"
With this implementation there is only a single place to put the language name: i18n.language.name. I think this place is easier to find and understand for Crowdin translators than a "locale" key hidden in general.yml
If the translation is not found we display the language key, instead of English, which makes more sense to me too 😌
Solution based on recent comments[1] on a related I18n issue
[1] https://github.com/svenfuchs/i18n/issues/365#issuecomment-419263847