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:
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.
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:
> 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:
> 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.
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?
> 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:
>> 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.
> 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.
> 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:
> >> 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.
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.
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.
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.