We've agreed `User.new` is easier to read than `described_class.new` and
since we are ignoring Hound's comments regarding this topic, we might as
well remove it.
As pointed out in PR consul#2734:
"After clicking the first link, there's an AJAX request which replaces
the existing `.in-favor a` and `.against a` links with new elements. So
if Capybara tries to click the existing `.against a` link at the same
moment it's being replaced, clicking the link won't generate a new
request".
Making Capybara check the page for new content before clicking the
second link solves the problem.
This commit solves issues afecting both Madrid's fork and the original
CONSUL repo.
Ruby can't have hyphens in method names, so sending something like
`record.title_pt-BR` would raise an exception.
Using globalize's `localized_attr_name_for` method fixes the bug.
Thanks Marko for the tip.
We think aborting the migration will generate more headaches to system
administrators, who will have to manually check and fix every invalid
record before anything can be migrated.
Since we've recently added German to the available languages, and we
might support every language in the future, we're using the fictional
world language to check a locale which isn't available.
Another option could be to set the available locales in the test
environment (or the rspec helper), but then we'd have to make sure it's
executed before the call to `globalize_accessors` in the model, and it
might be confusing for developers.
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
