Why not have RoR define a reference set of modules and class (call it
i18n for now) whose API implements the most basic i18n methods with no
real functionality? Then the plugins could flesh out the
functionality. I know this is pretty simplistic, but we need to start
somewhere. As RoR evolves, the hooks could be strengthened, but at
this point even one or two basic hooks would be a great start. I
would envision i18n's submodules being included in the standard RoR
frameworks and handling string translation (a la .t), error message
translation, model translation, locale initialization, time zone
determination, template selection, currency/time/date/number
formatting, etc.
Key points:
1. API hooks need to be in many, many places
2. API hooks need to be in places that are currently deep within RoR
undocumented code
3. We can start small -just one or two hooks.
4. Rails Core need not define any new functionality behind the hooks
-they can effectively be no-ops that aim to replicate the current
functionality.
5. For testing, a special Rails Locale can be defined so that test
assertions based on translatable output can be consistent on any
platform. The Rails locale would be the only locale effectively
supported by the default (no-op) i18n implementation. Other
implementations should mimic it for test compatibility.
This is essentially the idea I was promoting. I think a good way of
introducing this is to write a plugin that will monkey patch rails
core and provide the no-op api for l10n plugins. Once we do that we
can sell it to all the l10n plugin devs and try to standardize around
it. If we've got that going, it will look a lot more attractive to
rails core dev. We'll start discussing this in Globalize dev.
introducing this is to write a plugin that will monkey patch rails
core and provide the no-op api for l10n plugins. Once we do that we
can sell it to all the l10n plugin devs and try to standardize around
it. If we've got that going, it will look a lot more attractive to
rails core dev. We'll start discussing this in Globalize dev.
I like where you're going, let's just slightly modify the core
(without affecting performances and understandability) to render the
hard coded strings in different languages.
And let's get all the l10n plugins developers to work together on
defining a standard for dealing with l10n/i18n issues. If we can come
to an agreement on what standard to use and get most plugins to use
these conventions, it might then make sense to integrate it in the
core. (if it doesn't affect the performances obviously).
Once again, I'm not asking for l10n/i18n support in Rails, just a
simple way of having a core helper rendering in Italian, French or
whichever language you use.
All non-core l10n issues should imho be dealt on a plugin level.
