Implement our own matching algorithm rather than trying to
patch the http_accept_language one and make sure everything is
using it in a consistent way.
Fixes#1125
The issues we had before seem to be fixed now, so drop our
custom version and go back to the upstream one with some minor
monkey patching tweaks.
This also fixes the sprockets dependencies to correctly rebuild
the javascript when the translations change.
Without this the result of converting the hash to JSON can vary
which causes different hashes for the result JS asset.
This is only an issue with ruby 1.8 as ruby 1.9 hashes behave like
the ActiveSupport::OrderedHash and enumerate in insertion order.
Now that we are using nb for our translations we can drop the fallback
from nb to no and just have one the other way. This also allows us to
drop the monkey patch to support mutually recursive fallbacks.
This can be removed when a new i18n gem release happens. It also allows
us to remvoe an old monkey patch that worked around the problem for one
specific translation key.
Unfortunately the rails-i18n-updater plugin adds the rails translations
to the load path after rails has already loaded the translations, so we
have to force a reload to get the translated versions.
It's impossible to stop rails 2 loading a newer i18n gem if it is
installed, so go with the flow and use the latest one but override
the interpolation pattern for now.
Rails 3 pulls in i18n version 0.4.1 as a separate gem which then
breaks our code if it is running on a machine with rails 3 installed
as it tries to monkey patch i18n and fails, so this fix allows us
to run on a machine with rails 3 installed.
time.formats in the locale and then looks for the requested format in
that hash, thereby not doing fallback correctly. To make things worse
it then defaults to just using the requested format name as the format...
