Rails core - Jul 2008 - About the recently i18n added to Rails and locale files

I created the ticket/patch [1] to add the first locale files
(conventions and translations) to the recently i18n system (gem) added
to Rails.

After discussing in IRC, i was recommended to drop a line here.
Do you think this files should be in the core? If not, could it be
some way to "install" them with a rake task or script from an external
repository?

If Rails provides this feature it would be nice to have those files
available somehow.

As i said in the ticket:

"I believe that if we have simple localization out of the box, it
would be great to have the files included as well so they can be
revised by others who actually understand these conventions and
translations. "

[1] http://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/656

--~--~---------~--~----~------------~-------~--~----~
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 rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

Hey Emilio,

it''s awesome that you already come up with a localized version of that
data that''s not en-US.

As I said in that ticket''s comments ... I personally don''t
think that
addtional translation data (i.e. translations that either are not en- 
US or not used in Rails core) should go into Rails.

I agree that the translation data would certainly benefit from using  
the existing Rails infrastructure and community process. But on the  
other hand it would be quite hard to define what would go into the  
collection of "official" data and what wouldn''t. Maybe we
could
provide translations, e.g., for de-DE, but we certainly could not even  
provide data for several common languages in Rails without also  
shipping more complicated backends (e.g. for pluralization,  
localization of dates and numbers etc). This is one of the reasons why  
we sticked to only provide what Rails itself needs for en-US in the  
Simple backend: it could get really hard to draw a clear line.

Thus, I think we should - at least for the next couple of months,  
maybe for a really long time - collect this data, custom backends etc.  
in a central place, make it easy to find and install, but not ship it  
with Rails itself.

That said, this is just my personal opinion ... we explicitely did not  
want to decide on this matter without asking Rails core about this. So  
we''re really interested in what the community thinks about this.


On 21.07.2008, at 14:42, Emilio Tagua wrote:
>
> I created the ticket/patch [1] to add the first locale files
> (conventions and translations) to the recently i18n system (gem) added
> to Rails.
>
> After discussing in IRC, i was recommended to drop a line here.
> Do you think this files should be in the core? If not, could it be
> some way to "install" them with a rake task or script from an
external
> repository?
>
> If Rails provides this feature it would be nice to have those files
> available somehow.
>
> As i said in the ticket:
>
> "I believe that if we have simple localization out of the box, it
> would be great to have the files included as well so they can be
> revised by others who actually understand these conventions and
> translations. "
>
> [1] http://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/656
>
> >
--
sven fuchs			svenfuchs@artweb-design.de
artweb design		http://www.artweb-design.de
grünberger 65		+ 49 (0) 30 - 47 98 69 96 (phone)
d-10245 berlin		+ 49 (0) 171 - 35 20 38 4 (mobile)




--~--~---------~--~----~------------~-------~--~----~
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 rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

> Thus, I think we should - at least for the next couple of months,
> maybe for a really long time - collect this data, custom backends etc.
> in a central place, make it easy to find and install, but not ship it
> with Rails itself.
>
> That said, this is just my personal opinion ... we explicitely did not
> want to decide on this matter without asking Rails core about this. So
> we''re really interested in what the community thinks about this.
I agree with this sentiment, but for slightly different reasons.
We''re not qualified to make the judgement calls, and it
shouldn''t be
tied to our release timetable.

If you add up all the languages people on the core team speak, it''s
more than 1, but probably less than 5.  we''re in no position to judge
between two competing translation patches for pashtun or gulf arabic.
Or to apply a patch which purports to correct a spelling error in the
simplified chinese translations.

It also ties the releases of fixes and updates to translations to the
rails release schedule, if we have to push out a point release do we
wait for translators?  If the translations have a bunch of bugs but
we''re waiting for a new branch to land, do we hold off the releases of
the translation fixes?

I think for now the easiest option is just to keep them seperate, but
perhaps provide a rake task or a standard way for plugins to contain
translations.

-- 
Cheers

Koz

--~--~---------~--~----~------------~-------~--~----~
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 rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---