New deutsch translations of remote translations
interface have broke these specs where we were
using English translations at specs to do the checks
while the spec interface was in deutsch and now we
have deutsch translations for the interface application
is not returning english fallbacks anymore and a lot of
specs of this file fails.
This commits also changes the alternative language
used at spec from deutsch to spanish which is
maintaned by code not through Crowdin, so if any
developer update current spanish translations for the
user interface this specs will fail.
These changes fix a bug that causes categories
of a legislation process to be wiped on update
of the process. It also adds a regression test
for this fix.
Generating a random title with `Faker::Lorem.sentence` sometimes caused
validation errors in tests because the generated sentence was more than
80 characters long.
The test environment was using the file in `config/puma.rb`, meaning it
wouldn't work with Rails 5.1, which uses a different setup for Puma.
I've decided to create a new file called `defaults.rb`, which will be
used in every environment but development and test. We could also add an
empty file in `config/puma/test.rb`; I think that's less intuitive, but
it's a subjective opinion.
While the browser gem is great, we don't need it in this case for such a
simple usage.
There are a few really small differences between this code and the old
one: matching `/MSIE/` will return true for Opera 12 and false for
certain versions of IE11. Since we're only rendering a comment for IE8
and below, we don't care about IE11, and Opera 12 is six years old and
its users won't be affected by the comment.
Note we're still using the browser gem because ahoy_matey depends on it,
but now it's an indirect dependency.
The task `deploy:restart` was doing nothing since we moved from unicorn
to puma.
Now we're also restarting delayed jobs on `deploy:restart`, which is
probably what's expected in most cases.
So now the way to restart the application does not depend on whether we
use puma or passenger.
What this plugin actually does is restarting puma when we touch the
`tmp/restart.txt` file, which is what `rails restart` does.
This way we don't have to start it manually every time the server is
restarted.
Note if we start the application with `bin/rails s start -e production`,
as we'd probably want to do so this task doesn't depend on the server we
use, the application will crash when we restart it because it will be
restarted in the development environment. Maybe this issue will be fixed
in future versions of Rails and/or Puma.
Also note we're passing `2` workers to delayed job, and this number must
be the same number we use for the `delayed_job_workers` variable in
capistrano. I haven't found a way to share this variable between
whenever and capistrano.
We need to download the most recent CONSUL and check its `.ruby-version`
file before installing Ruby.
The `rvm1-capistrano` gem knows it and was invoking the `updating` task
before installing Ruby. So we were getting a warning in Capistrano about
the `updating` task being executed twice.
New CONSUL instances who didn't use the newest installer and haven't
done any deployments with capistrano would get an exception because the
`current` capistrano folder doesn't exist yet.
