The documentation previously stated that calling `translate(".foo")` was
equivalent to calling `I18n.translate("people.index.foo")` which is
incorrect due to the various other functions of the `translate` view
helper. This has been fixed.
Additionally, a note about forcing the view helper to re-raise
exceptions was added to the section detailing the handling of missing
translations.
Other cleanup includes:
* Consistent formatting of code
* Stop indenting bulleted list as a code sample
* Tighten some of the language
* Wrap at 80 characters.
4.2.1 introduced a change to the way `translate`/`t` works with an
option of `default: [[]]`. In 4.2.0, this would give a default value of
`[]`, but in 4.2.1, it leads to a missing translation.
`default: [[]]` is again allowed for cases where a default of `[]` is
needed.
This addresses GitHub issue 19640.
The previous version of rails(4.2.0) you can pass objects
to the default option of translation helper.
For example:
```ruby
t('foo', default: 1)
```
But on rails 4.2.1 version this kind of use stopped to work,
because started only to accept String types.
Now with this fix we can use orther value types on this
helper again.
Previously default translation keys that didn't end in `_html`, but came
after a missing key that ended in `_html` were being returned as
html_safe. Now they are not. Fixes#18257
Before ec16ba75a5,
ActionView::Helpers::TranslationHelper#translate has raised errors with
specifying options[:raise] to true.
This should work by this fix:
begin
t(:"translations.missing", raise: true)
rescue I18n::MissingTranslationData
p :hello!
end
i18n doesn't depend on active support which means it can't use our html_safe
code to do its escaping when generating the spans. Rather than try to sanitize
the output from i18n, just revert to our old behaviour of rescuing the error
and constructing the tag ourselves.
Fixes: CVE-2013-4491
