When we were visiting a page showing the content of a record which uses
globalize and our locale was the default one and there was no
translation for the default locale, the application was crashing in some
places because there are no fallbacks for the default locale.
For example, when visiting a legislation process, the line with
`CGI.escape(title)` was crashing because `title` was `nil` for the
default locale.
We've decided to solve this issue by using any available translations as
globalize fallbacks instead of showing a 404 error or a translation
missing error because these solutions would (we thinkg) either require
modifying many places in the application or making the translatable
logic even more complex.
Initially we tried to add this solution to an initializer, but it must
be called after initializing the application so I18n.fallbacks[locale]
gets the value defined in config.i18n.fallbacks.
Also note the line:
fallbacks[locale] = I18n.fallbacks[locale] + I18n.available_locales
Doesn't mention `I18n.default_locale` because the method
`I18n.fallbacks[locale]` automatically adds the default locale.
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.
When we grouped the fields together, the last one turned into a
`last-child`, which foundation automatically aligns to the right.
The markdown editor also needed to be tweaked a little bit.
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.
When using the OR operator, if the left side of the expression evaluates
to false, its right side is taken into consideration. Since in Ruby nil
is false, we can avoid using conditionals for this particular scenario
In order to be consistent with similar specs, the I18nContent#begins_with_key
spec was improved by explicitly specifying an I18n key for one (1) factory
that relied on its default value
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.
If we enabled the locale and then added an option, the "add option" link
added the partial which was generated before enabling the translation,
and so it generated a field where the translation was disabled.
Enabling the translation after inserting each field solves the issue.
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.
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.
Creating a new form builder might be too much. My idea was so the view
uses more or less the same syntax it would use with Rails' default
builder, and so we can use `text_field` instead of
`translatable_text_field`.
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.
The proposal image only can be present if feature :allow_images is enabled, so there is no need to include both conditions. The data-equalizer also is unnecessary because the :thumb image already has an fix height.
