Hi Andreas, The state of most rails i18n plugins is rather immature at the moment. A bundling and therefore centralizing it's location might just be the answer. I propose to split it in probably a few separate plugins though.
I would imagine two types of i18n aware applications: Applications in a single language, not being able to switch between languages, but do use some of the i18n features. And fully fledged applications that support multiple languages. Besides these I think one might separate between 'backend-independent' and SimpleBackend dependent plugins. Just my 2 cents, Iain On Sat, Jan 10, 2009 at 14:41, Andreas Neuhaus <[email protected]> wrote: > > > On 27 Dez. 2008, 14:44, "Yaroslav Markin" <[email protected]> > wrote: >> I think that would be just great to merge this in, thanks for your work :-) >> I also think that locale checking tool must move to rails-core as rake >> i18n:check of something. What do you think, people? > > Nice idea. I'm not sure how useful this would be to app developers, > since the current script checks the completeness of the core > translation (if I remember right). Maybe we could enhance the rake > task a little so that app developers can check the completeness of > their translation. I guess, usually an application is developed in a > primary language and translated to other languages later. If > development goes on, additional strings are added that have to be > translated. A task which lists all missing keys would be helpful imo. > > Yesterday, another idea came to my mind. Why not include some more > i18n related features to the plugin? Currently, people still need to > do much things to make an app i18n aware. The Rails core only provides > an API to make i18n possible - people who don't need i18n won't even > notice that. Why not produce a plugin that provides all kind of useful > things to i18n aware apps. I was mainly thinking about merging most of > the useful i18n ideas together in one plugin. In my opinion it should > include: > > - rails core translations for all kind of languages (like svenfuchs/ > rails-i18n), automatically pulled into your app when the plugin is > installed (like my fork does) > - some useful rake tasks like finding missing translations and such > - easier i18n for date/time (like clemens/localized_dates) > - i18n related stuff to inspect the request (for finding out the > visitor's preferred locale, like iain/http_accept_language) > - by default a before_filter that inspects the http_accept_language > header and sets i18n.locale to the most preferred existing locale > (which is a good default behaviour, but it should be possible to > disable. http://zargony.com/2009/01/09/selecting-the-locale-for-a-request) > - date/time parsing methods (text to time object) that are i18n aware > (Unsure if this already exists somewhere) > > Imo, tools like the textmate bundle should be moved to an own > repository in this case (which makes it easier to install/update to > textmate anyway) > > What do you think? I wonder if people would find this useful and, > Sven, if you'd like to have it in your repo or if you want to keep it > as a locale collection rather than making it a plugin. > > regards, > Andreas Neuhaus > http://zargony.com/ > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "rails-i18n" 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/rails-i18n?hl=en -~----------~----~----~----~------~----~------~--~---
