We set `I18n.locale = :en` before each test, and so creating a new card
will automatically create English translations.
So visiting the Spanish page won't show the card, since no Spanish
translation exists for it. If we visit the klingon page after doing so,
the last used locale (Spanish) will still be used, and so the test will
fail.
Specifically creating Spanish translations instead of the English ones
makes the translations visible when visiting the Spanish homepage.
Instead of using I18n for the field texts and forcing the
locale (e.g. `I18n.t('seeds...', locale: :es)`), I'm moving
content out of `config/locales/` and into the seed file.
This is because this content is less about reacting to different
locales (the locale would always be forced so we don't actually
use the main i18n functionality), and more about demonstrating
the "translatable fields" feature.
We are using a simple unicorn.rb file in the Installer, which requires a different way of restarting the server
This task is still a little limited and hackish but it does the job for now 😌
We are killing any existing unicorn process and starting unicorn. It checks for existing processes in both the standard consul folder and in the capistrano `current` folder, and skipping any exception if unicorn was not running.
Capistrano configuration is prepared to deploy to multiple servers
For now assuming that we are going to use a single server for everthing (app, db, cron jobs, queue system, etc)
Ruby and bundler should already be installed in the system
Before we can bring back these commands we need to review them, right now they are raising an interesting exception
We were expecting translation parameters in legislation processes
`update` action. However, those parameters aren't sent when we get to
that action through the "proposals" tab.
There's no reason to only convert Markdown to HTML in translations when
their body changes but to always convert it when the "main" body field
changes.
Whether we should always use the condition or never use it is something
we can debate about, though.
They were failing if executed right before midnight. If the process is
created right before midnight and then the date changes, when we visit
the process path the phase will aready be open.
It was failing when executed right before midnight due to the date
changing between the moment the notification is created and the moment
the test checks the notification shows the current date.
