We had a validation rule for milestones which made sure either the
status or the description was present. However, since the description is
now translatable, the validation error wasn't being displayed in the
admin form.
Moving the validation rule to the translation object fixes the problem.
However, the translation object needs to check an attribute in the
milestone object in order to know whether the description is required or
not. This is tricky because by default it loads the milestone object
from the database, meaning it doesn't work with new records and it
ignores params sent by the browser.
The solution is to manually assign the globalized model before
validating the object. It's a hack, but apparently Rails doesn't provide
a better way to handle this case [1].
[1] https://github.com/rails/rails/issues/32024
This way we can show/hide that div when displaying translations, and we
can remove the duplication applying the same logic to the label, the
input, the error and the CKEditor.
This way we also solve the problem of the textarea of the CKEditor
taking space when we switch locales, as well as CKEditor itself taking
space even when not displayed.
We needed to bring back support for CKEditor in our translatable form,
which we had temporarily remove.
And now we support CKEditor in our translatable specs, and so we can
remove the duplicated specs for poll question answers.
Updating it required reorganizing the form so translatable fields are
together.
We also needed to add a `hint` option to the form label and input
methods so the hint wouldn't show up for every language.
Finally, the markdown editor needed to use the same globalize attributes
as inputs, labels and hints, which adds a bit of duplication.
After removing a translation while editing another one with invalid data
and sending the form, we were displaying the removed translation to the
user.
We now remove that translation from the form, but we don't remove it
from the database until the form has been sent without errors.
After adding a new translation with invalid data and sending the form,
we were disabling the new translation when displaying the form again to
the user, which was confusing.
This change forces us to use nested attributes for translations, instead
of using the more convenient `:"title_#{locale}"` methods.
On the other hand, we can use Rails' native `_destroy` attribute to
remove existing translations, so we don't have to use our custom
`delete_translations`, which was a bit buggy since it didn't consider
failed updates.
Skipping a spec in the middle of it, particularly after doing some
requests, caused Capybara to keep using the same driver in the following
spec.
Since the current spec uses the JavaScript driver, the next test would
also use the JavaScript driver, causing apparently random failures if
that test was supposed to use the Rack driver.
Using `have_content` detected textareas, but not text input contents.
All credit to Marko (mlovic) for finding the issue and suggesting the
implemented solution.
The example tests if a certain selector is hidden after adding
one image but the assertion expected said selector to be visible,
which made the scenario to fail at random
