When we upgraded to Rails 7 in commit 8596f1539, we broke the custom
locales since now all nested folders in `config/locales/` are loaded by
default [1]. This meant that the custom folder was now loaded before any
languages whose code alphabetically goes after the word "custom".
As a workaround, we're overwriting the default locales paths so they
don't include the custom folder. We're doing this step before the
`add_locales` initializer; that is, before the default locales paths are
used.
Unfortunately, I haven't found a way to add a test for this behavior,
since we would need to add a file in `config/locales/custom` that
overwrites an internationalization key for an existing language, but
only during a specific test, and the i18n load path is evaluated when
the application starts up.
[1] See pull request 41872 in https://github.com/rails/rails/
So now we install a specific version of Node.js and use the packages
required for Debian Bookworm.
For consistency, we're also making them similar to the Ubuntu
instructions and installing rbenv instead of RVM. Since we now suggest
rbenv in both cases as well as in the macOS instructions, we're also
listing rbenv as the first option in the generic local installation
instructions.
This command simplifies some of the steps. However, there's a gotcha: it
might fail if the database requires username and password and they
haven't been configured before executing it.
On our regular README, this link used to point to the documentation
site, which made sense because the documentation used to be on a
different repository. Now that the documentation is on this repository
as well, we can directly link to that file.
And, on the documentation README, we can also link to the local
installation instructions, just like we do in other places.
We include ImageMagick in the local installation instructions as well as
in the installer, but we forgot to add it to the list of prerequisites
in the README.
It was a bit strange to leave the end date blank and have a message
associated with the start date, so we're using presence validations
instead.
For the range validation, we're using the comparison validator included
in Rails 7.0.
The `validates_comparison_of` method was added in Rails 7.0.
We aren't changing the `date_range` validation in polls yet because it's
a bit complex; we'll do it in the next commit.
While the `minimum` and `maximum` methods have been available for a long
time for ActiveRecord relations, Rails 7.0 has added these methods for
enumerables as well.
This means that the `start_date` and `end_date` methods in the
ShiftsHelper can use `minimum` and `maximum` no matter whether they
receive an ActiveRecord relation or an array of polls (I think the
latter never happens, though, but I'm not 100% sure).
This method was added in Rails 7.0 and makes the code slihgtly more
readable.
The downside is that it generates two queries instead of one, so it
might generate some confusion when debugging SQL queries. Its impact on
performance is probably negligible.
This method was introduced in Rails 7.0, and thanks to it we can
simplify the code that gets the translations in order.
We tried to use this method to simplify the `Randomizable` concern as
well. However, we found out that, when ordering tens of thousands of
records, the query could take several minutes, so we aren't using it in
this case. Using it for translation fallbacks is OK, since there's a
good chance we're never going to have tens of thousands of available
locales.
Note that automated security tools reported a false positive related to
SQL Injection due to the way we used `LEFT JOIN`, so now we get one less
false positive in these reports.
We hadn't added this rule before because there was no such rule in
scss-lint. Instead, we were following it without a linter, and so we
unintentionally broke it sometimes.
But now we're using Stylelint, so we can add the rule and let the linter
check we're still following it.
