Title changed from [PATCH] I18n, look up a translation with the default locale when it's missed with another specific locale to I18n, look up a translation with the default locale when it's missed with another specific locale

All tests pass after applying your patch and the code in the
patch looks good!

This will be very awesome, I was just working on I18n not just
yesterday and would have appreciated this a lot for production
code.

For one thing it changes the shipped I18n gem so any changes
should obviously be applied over there.

Also, fallbacks can be a hairy issue. If hardcoding anything
you'd at least want to provide support for falling back from, e.g.,
de-DE to de, but then quickly get into various special cases (e.g.
Scandinavian locales). So in the end you'll want to let the user
customize fallback rules.

Globalize2 ships support for this and you can use the fallback
stuff separately from the rest of the library. If Globalize2's
fallback support is not good enough I'd suggest either improving it
or implementing your needs as a different plugin.

All that said, of course I can see we'll want to provide this
kind of support (as an optional module) in the I18n gem. But I'd
want to proceed on our conservative route of cherry-picking proven
things from plugins or other battle-tested solutions.

Francesc, I'm sure a lot of people use fallbacks. That doesn't
mean it must be included to Rails though right now though. Rails
I18n was built to support no other locale than :en out of the box.
The reason for this is that it can be incredibly hard to figure out
"the right way" to do it - and Gettext is not always a good
example.

Please keep in mind that experimenting with advanced features in
plugin-land, then comparing solutions, maybe cherrypicking a few
things from the best breeds and then including them into
the I18n lib in a defensive way is part of the plan :)

Does Globalize2 fallback support solve your problem? If so we
should better document (e.g. in the I18n guide) that it's there and
how it can be used. If not, please provide feedback so it can be
improved.

In my opinion falling back to the message user has provided if
no translation available it's a good solution, this makes me think
that although my application is in english I always have to
translate it creating locale files. In my opinion:

t("Hello World") should become "Hello
World" if no translation available.

Users don't have to see those "missing translation" & "en,
Hello World" warnings.

Gettext maybe it's not a good example, but makes sense to return
the same message if no translation is available. (Other thing is
how it's implemented)