Hi guys, I just saw that localized templates is now part of rails core (http:// github.com/rails/rails/commit/ a98cd7ca9b2f24a4500963e58ba5c37d6bdf9259). But I would like to discuss how it was implemented. I''m the maintainer of Localized Templates plugin (http://github.com/ josevalim/localized_templates/) and before implement it we had a discussion on I18n group how it should work. The first version of Localized Templates had the same "schema" as in Rails core. Assuming MessagesController, index action and locale pt- BR, our localized file would be: app/views/messages/index.pt-BR.html.erb (controller/action.locale) But the suggestions in I18n group defined a schema like this: app/views/pt-BR/messages/index.html.erb (locale/controller/ action) I already worked with both schemas and I personally think that "locale/ controller/action" is much better. I''ve talked with 5 or 6 other people that were also using Localized Templates and they all had the same point of view. There are two main reasons: 1. It''s easier to translate: in "locale/controller/action" schema, to create a new language we just have to copy and paste the locale root and start to translate. When using Rails current schema, we have to go in each controller folder and rename all files... at the end I was seriously thinking in developing a rake task that could do it for me. 2. It''s easier to mantain: in Rails current schema we usually end up with our controllers folders full of files (4 locales x 4 files = 16 files). In the second schema everything is organized by locale roots. Anyway, I brought this discussion to know what people think about both schemas and which one would be the best for Rails core. Well, that''s all. :) Cheers, José Valim. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
I agree with José - for the same reasons he mentioned. Maybe it makes sense to just drop the current implementation and include the localized templates plugin (if that''s possible)? - Clemens On Jan 30, 6:33 pm, José Valim <jose.va...@gmail.com> wrote:> Hi guys, > > I just saw that localized templates is now part of rails core (http:// > github.com/rails/rails/commit/ > a98cd7ca9b2f24a4500963e58ba5c37d6bdf9259). But I would like to discuss > how it was implemented. > > I''m the maintainer of Localized Templates plugin (http://github.com/ > josevalim/localized_templates/) and before implement it we had a > discussion on I18n group how it should work. > > The first version of Localized Templates had the same "schema" as in > Rails core. Assuming MessagesController, index action and locale pt- > BR, our localized file would be: > > app/views/messages/index.pt-BR.html.erb (controller/action.locale) > > But the suggestions in I18n group defined a schema like this: > > app/views/pt-BR/messages/index.html.erb (locale/controller/ > action) > > I already worked with both schemas and I personally think that "locale/ > controller/action" is much better. I''ve talked with 5 or 6 other > people that were also using Localized Templates and they all had the > same point of view. > > There are two main reasons: > > 1. It''s easier to translate: in "locale/controller/action" schema, > to create a new language we just have to copy and paste the locale > root and start to translate. When using Rails current schema, we have > to go in each controller folder and rename all files... at the end I > was seriously thinking in developing a rake task that could do it for > me. > > 2. It''s easier to mantain: in Rails current schema we usually end up > with our controllers folders full of files (4 locales x 4 files = 16 > files). In the second schema everything is organized by locale roots. > > Anyway, I brought this discussion to know what people think about both > schemas and which one would be the best for Rails core. > > Well, that''s all. :) > > Cheers, > > José Valim.--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Not sure. I think this largely depends on how many views you want to translate. If there are only some (e.g. ActionMailer notification views) that you want to translate as a whole while everything else uses the usual way of translating with I18n.t then having an extra directory seems like overkill to me ... and the current implementation much nicer. Why not ship the current implementation as a simple way with Rails core and still have José''s plugin available for people who want to rely on this approach for most of their views? Do these approaches necessarily clash? On 31.01.2009, at 11:32, Clemens Kofler wrote:> > I agree with José - for the same reasons he mentioned. Maybe it makes > sense to just drop the current implementation and include the > localized templates plugin (if that''s possible)? > > - Clemens > > On Jan 30, 6:33 pm, José Valim <jose.va...@gmail.com> wrote: >> Hi guys, >> >> I just saw that localized templates is now part of rails core >> (http:// >> github.com/rails/rails/commit/ >> a98cd7ca9b2f24a4500963e58ba5c37d6bdf9259). But I would like to >> discuss >> how it was implemented. >> >> I''m the maintainer of Localized Templates plugin (http://github.com/ >> josevalim/localized_templates/) and before implement it we had a >> discussion on I18n group how it should work. >> >> The first version of Localized Templates had the same "schema" as in >> Rails core. Assuming MessagesController, index action and locale pt- >> BR, our localized file would be: >> >> app/views/messages/index.pt-BR.html.erb (controller/ >> action.locale) >> >> But the suggestions in I18n group defined a schema like this: >> >> app/views/pt-BR/messages/index.html.erb (locale/controller/ >> action) >> >> I already worked with both schemas and I personally think that >> "locale/ >> controller/action" is much better. I''ve talked with 5 or 6 other >> people that were also using Localized Templates and they all had the >> same point of view. >> >> There are two main reasons: >> >> 1. It''s easier to translate: in "locale/controller/action" schema, >> to create a new language we just have to copy and paste the locale >> root and start to translate. When using Rails current schema, we have >> to go in each controller folder and rename all files... at the end I >> was seriously thinking in developing a rake task that could do it for >> me. >> >> 2. It''s easier to mantain: in Rails current schema we usually end >> up >> with our controllers folders full of files (4 locales x 4 files = 16 >> files). In the second schema everything is organized by locale roots. >> >> Anyway, I brought this discussion to know what people think about >> both >> schemas and which one would be the best for Rails core. >> >> Well, that''s all. :) >> >> Cheers, >> >> José Valim. > >--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
> Not sure. I think this largely depends on how many views you want to > translate. If there are only some (e.g. ActionMailer notification > views) that you want to translate as a whole while everything else > uses the usual way of translating with I18n.t then having an extra > directory seems like overkill to me ... and the current implementation > much nicer. > > Why not ship the current implementation as a simple way with Rails > core and still have José''s plugin available for people who want to > rely on this approach for most of their views? Do these approaches > necessarily clash?Agree with Sven. The current approach is an extraction from how I was translating Basecamp. The vast majority of pages would be translated inline with <%= t %> calls, but a handful of pages, like a help screen or a blank slate, was easier to translate in its entirety. The current approach is meant as a companion for an application that''s mostly using the <%= t %> approach to translation, but just has a few complete translations. If that pattern doesn''t fit your translation style and you''d rather translate every single view in its entirety, then I think the localized templates plugin is a fine approach to continue using. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Agreeing with David and Sven, but add some points: if you use the locale/controller/action schema, you''ll find a lot of rails apps with just the "en" directory in app/views, which would mean an uglier directory structure... And while translating the last rails app I''ve done, just using some t(...)''s was enough in 98% of the cases... On 31 ene, 15:18, DHH <david.heineme...@gmail.com> wrote:> > Not sure. I think this largely depends on how many views you want to > > translate. If there are only some (e.g. ActionMailer notification > > views) that you want to translate as a whole while everything else > > uses the usual way of translating with I18n.t then having an extra > > directory seems like overkill to me ... and the current implementation > > much nicer. > > > Why not ship the current implementation as a simple way with Rails > > core and still have José''s plugin available for people who want to > > rely on this approach for most of their views? Do these approaches > > necessarily clash? > > Agree with Sven. The current approach is an extraction from how I was > translating Basecamp. The vast majority of pages would be translated > inline with <%= t %> calls, but a handful of pages, like a help screen > or a blank slate, was easier to translate in its entirety. > > The current approach is meant as a companion for an application that''s > mostly using the <%= t %> approach to translation, but just has a few > complete translations. If that pattern doesn''t fit your translation > style and you''d rather translate every single view in its entirety, > then I think the localized templates plugin is a fine approach to > continue using.--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Thanks for the feedback guys. In fact, the approaches do not clash. It would be hard to do in Rails 2.2, but in Rails 2.3 it''s much easier. Anyway, since we are on the subject, what do you think of adding Localized Rescue to core also? This way we could have "public/404.en.html" and "public/404.pt- BR.html". I think this is the only missing part of Localized Templates. Gist is here: http://gist.github.com/55555 On Jan 31, 2:02 pm, Sven Fuchs <svenfu...@artweb-design.de> wrote:> Not sure. I think this largely depends on how many views you want to > translate. If there are only some (e.g. ActionMailer notification > views) that you want to translate as a whole while everything else > uses the usual way of translating with I18n.t then having an extra > directory seems like overkill to me ... and the current implementation > much nicer. > > Why not ship the current implementation as a simple way with Rails > core and still have José''s plugin available for people who want to > rely on this approach for most of their views? Do these approaches > necessarily clash? > > On 31.01.2009, at 11:32, Clemens Kofler wrote: > > > > > I agree with José - for the same reasons he mentioned. Maybe it makes > > sense to just drop the current implementation and include the > > localized templates plugin (if that''s possible)? > > > - Clemens > > > On Jan 30, 6:33 pm, José Valim <jose.va...@gmail.com> wrote: > >> Hi guys, > > >> I just saw that localized templates is now part of rails core > >> (http:// > >> github.com/rails/rails/commit/ > >> a98cd7ca9b2f24a4500963e58ba5c37d6bdf9259). But I would like to > >> discuss > >> how it was implemented. > > >> I''m the maintainer of Localized Templates plugin (http://github.com/ > >> josevalim/localized_templates/) and before implement it we had a > >> discussion on I18n group how it should work. > > >> The first version of Localized Templates had the same "schema" as in > >> Rails core. Assuming MessagesController, index action and locale pt- > >> BR, our localized file would be: > > >> app/views/messages/index.pt-BR.html.erb (controller/ > >> action.locale) > > >> But the suggestions in I18n group defined a schema like this: > > >> app/views/pt-BR/messages/index.html.erb (locale/controller/ > >> action) > > >> I already worked with both schemas and I personally think that > >> "locale/ > >> controller/action" is much better. I''ve talked with 5 or 6 other > >> people that were also using Localized Templates and they all had the > >> same point of view. > > >> There are two main reasons: > > >> 1. It''s easier to translate: in "locale/controller/action" schema, > >> to create a new language we just have to copy and paste the locale > >> root and start to translate. When using Rails current schema, we have > >> to go in each controller folder and rename all files... at the end I > >> was seriously thinking in developing a rake task that could do it for > >> me. > > >> 2. It''s easier to mantain: in Rails current schema we usually end > >> up > >> with our controllers folders full of files (4 locales x 4 files = 16 > >> files). In the second schema everything is organized by locale roots. > > >> Anyway, I brought this discussion to know what people think about > >> both > >> schemas and which one would be the best for Rails core. > > >> Well, that''s all. :) > > >> Cheers, > > >> José Valim.--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
jrom, this is actually not a problem, because in Localized Templates if the view cannot be found in "locale/controller/action", it will look for it on "controller/action". :) On Jan 31, 3:27 pm, jrom <jordirom...@gmail.com> wrote:> Agreeing with David and Sven, but add some points: if you use the > locale/controller/action schema, you''ll find a lot of rails apps with > just the "en" directory in app/views, which would mean an uglier > directory structure... And while translating the last rails app I''ve > done, just using some t(...)''s was enough in 98% of the cases... > > On 31 ene, 15:18, DHH <david.heineme...@gmail.com> wrote: > > > > Not sure. I think this largely depends on how many views you want to > > > translate. If there are only some (e.g. ActionMailer notification > > > views) that you want to translate as a whole while everything else > > > uses the usual way of translating with I18n.t then having an extra > > > directory seems like overkill to me ... and the current implementation > > > much nicer. > > > > Why not ship the current implementation as a simple way with Rails > > > core and still have José''s plugin available for people who want to > > > rely on this approach for most of their views? Do these approaches > > > necessarily clash? > > > Agree with Sven. The current approach is an extraction from how I was > > translating Basecamp. The vast majority of pages would be translated > > inline with <%= t %> calls, but a handful of pages, like a help screen > > or a blank slate, was easier to translate in its entirety. > > > The current approach is meant as a companion for an application that''s > > mostly using the <%= t %> approach to translation, but just has a few > > complete translations. If that pattern doesn''t fit your translation > > style and you''d rather translate every single view in its entirety, > > then I think the localized templates plugin is a fine approach to > > continue using.--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
> Anyway, since we are on the subject, what do you think of adding > Localized Rescue to core also? > > This way we could have "public/404.en.html" and "public/404.pt- > BR.html". > I think this is the only missing part of Localized Templates. > > Gist is here:http://gist.github.com/55555I like that. Do turn it into a patch. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Patch created and assigned to you. http://rails.lighthouseapp.com/projects/8994/tickets/1835-add-localized-rescue On Feb 1, 1:28 am, DHH <david.heineme...@gmail.com> wrote:> > Anyway, since we are on the subject, what do you think of adding > > Localized Rescue to core also? > > > This way we could have "public/404.en.html" and "public/404.pt- > > BR.html". > > I think this is the only missing part of Localized Templates. > > > Gist is here:http://gist.github.com/55555 > > I like that. Do turn it into a patch.--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Thanks for the clarification. Anyway, it would mess the directory structure by merging locale with the default rails tree. "app/views/ controller/action[.locale]" just feels better to me. On 1 feb, 00:43, José Valim <jose.va...@gmail.com> wrote:> jrom, this is actually not a problem, because in Localized Templates > if the view cannot be found in "locale/controller/action", it will > look for it on "controller/action". :) > > On Jan 31, 3:27 pm, jrom <jordirom...@gmail.com> wrote: > > > Agreeing with David and Sven, but add some points: if you use the > > locale/controller/action schema, you''ll find a lot of rails apps with > > just the "en" directory in app/views, which would mean an uglier > > directory structure... And while translating the last rails app I''ve > > done, just using some t(...)''s was enough in 98% of the cases... > > > On 31 ene, 15:18, DHH <david.heineme...@gmail.com> wrote: > > > > > Not sure. I think this largely depends on how many views you want to > > > > translate. If there are only some (e.g. ActionMailer notification > > > > views) that you want to translate as a whole while everything else > > > > uses the usual way of translating with I18n.t then having an extra > > > > directory seems like overkill to me ... and the current implementation > > > > much nicer. > > > > > Why not ship the current implementation as a simple way with Rails > > > > core and still have José''s plugin available for people who want to > > > > rely on this approach for most of their views? Do these approaches > > > > necessarily clash? > > > > Agree with Sven. The current approach is an extraction from how I was > > > translating Basecamp. The vast majority of pages would be translated > > > inline with <%= t %> calls, but a handful of pages, like a help screen > > > or a blank slate, was easier to translate in its entirety. > > > > The current approach is meant as a companion for an application that''s > > > mostly using the <%= t %> approach to translation, but just has a few > > > complete translations. If that pattern doesn''t fit your translation > > > style and you''d rather translate every single view in its entirety, > > > then I think the localized templates plugin is a fine approach to > > > continue using.--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---