Do you guys have a blog/wiki/etc. with information covering what you
have so far?  Something with more detail than the bullet points below?
 If not, I'll wait the few weeks. :)

On 1/3/08, Matt Aimonetti <[EMAIL PROTECTED]> wrote:
>
> For quite a while, a bunch of great developers frustrated by the lack
> of internationalization solutions for Rails started writing their own
> plugins http://wiki.rubyonrails.org/rails/pages/InternationalizationComparison
>
> The major problem for us was the fact that we always had to monkey
> patch Rails so people could use Rails helpers / ActiveRecord in
> another languages than English.
>
> Most of us got frustrated and decided to work together in order to
> find a compromise and define an internationalization standard for
> Rails. Based on our different approaches and background we spent hours
> crafting a solution that will hopefully provide Rails with more
> flexibility.
>
> Looking at Globalize, Simple Localization, Ruby-GetText-Package or
> GlobaLite, you will notice a totally different approach. It has been
> really hard for us to agree on all the details but we did it!
>
> Here is a quick preview of what we are planning to do.
>
> 2 objectives:
>
>   * eliminate the need for monkey patching Rails in order to
> internationalize an application.
>
>   * a common api that can be leveraged by all l10n plugins.
>
> In order to do that, we agreed to keep things as simple as possible so
> each of us can developer his/her own solution, however since we want
> to have a common base to work from we decided to:
>
> - develop an internationalization library (i18n) that will handle all
> the usual i18n tasks such as adding a localization method,
> interpolation and basic pluralization. The i18n library will have
> built-in graceful degradation support using a default language
> provided by the library author. (used if no localization library is
> loaded)
>
> - patch Rails libraries to use the i18n library. (with English as
> fallback language)
>
> - develop a Localization library (l10n) that will handle locales,
> advanced pluralization rules, advanced interpolation and localization
> of objects (string, date/time, currency..). The l10n lib will use yaml
> files to lookup string localizations and use a ruby file defining
> language rules.
>
> I don't want to get into the implementation details since we are
> working on an official document. But we believe that by approaching
> the challenge this way, we will offer a very flexible solution that
> can be used by other libraries (Merb, Sinatra, DataMapper...) and at
> the same time can be extended by any plugin/gem developers without
> having to reinvent the wheel.
>
> Expect more details in the next few weeks.
>
> -Matt
> >
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to