Having translations makes this validation too complex and not worth the
effort, since now we can't just scope in a single column but we need to
scope in the translations locale and the question ID.
This way we guarantee there will be at least one translation for a model
and we keep compatibility with the rest of the application, which
ideally isn't aware of globalize.
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.
We need to replace ".title=" by ".title_#{locale}=" in one place because
for some reason globalize builds a new translation record when using the
latter but it doesn't build one when using the former.
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.
Note the title field was hidden since commit 01b9aa8, even though it was
required and translatable. I've removed the required validation rule,
since it doesn't seem to make much sense and made the translatable
tests harder to write.
Also note the method `I18n.localize`, which is used to set the
milestone's title, uses `I18n.locale` even if it's inside a
`Globalize.with_locale` block, and so the same format is generated for
every locale.
The same way we did for banners.
We needed to add new translation keys so the labels are displayed in the
correct language. I've kept the original `title` and `body` attributes
so they can be used in other places.
While backporting, we also added the original translations because they
hadn't been backported yet.
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.
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.
