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.
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.
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.
All other languages will fallback to the default locale
Rails also, seems to pick up dialect fallbacks, for locales with this format: es-CO, es-PE, etc, which will fallback to "es", so that is great 😌
There seems to be some differences between the folder name and the locale name used in the files themselves.
For example: the folder might have been called "de-DE", for German, but the files use one "de"
And thus translations where not being displayed
Using the locale key in the files and modifying the folder name if neccesary, let's see what happens in the next Crowdin pull, might need to review more thoroughly why this is happening (maybe due to custom settings in Crowdin)
