Users were unable to reset a translation to its original value after
updating it because we weren't storing anything in the database in that
case.
I've considered deleting the existing translation when this happens. I'm
not sure about which approach is the better one, so I'm using the less
destructive one.
We're not adding the rule because it would apply the current line length
rule of 110 characters per line. We still haven't decided whether we'll
keep that rule or make lines shorter so they're easier to read,
particularly when vertically splitting the editor window.
So, for now, I'm applying the rule to lines which are about 90
characters long.
This way we avoid fetching each translation every time it's requested.
This reduces the amount of queries in the development logs and also
makes the test suite faster.
This is a mistake I made in commit f2ef27d3. Back then I thought we
needed to keep Globalize.locale and I18n.locale in sync, but the truth
is it automatically happens when setting Globalize.locale to nil.
So now we can use I18n.with_locale (at least in the tests) and forget
about Globalize, which will make it easier to switch to Mobility in the
future.
This code might be slightly slower because it performs one query per
field in the form, but I didn't notice any differences on my development
machine, and the code is now much easier to understand.
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.
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
