I was just wondering about locales and .yml files. Is it better to store the multilanguage strings in .yml files than in databases? And if yes, why? I was also wondering how rails are loading this files (for example, I have 4 languages in my web app, each has her own .yml file, will my rails app loads all the files in ram and then it will call each variable inside my web app? Or something else?) Thank you :) -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Yes it is better to store the multilanguage strings in the .yml files. Why you ask, well are you going to have all your record entries repeat one for each language you intent to support ?? Do you think that would be a good idea ?? The database should have single values which the .yml files will translate into different languages depending on the locale settings. I am not very sure regarding the loading of the different .yml files, that is something even I would like to know, but from my experience / knowledge I don''t think that is the case since locale change requires me to restart the app. Thanks & Regards, Dhruva Sagar. On Mon, Apr 26, 2010 at 15:17, Yiannis <istoselidas-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> I was just wondering about locales and .yml files. Is it better to > store the multilanguage strings in .yml files than in databases? And > if yes, why? > > I was also wondering how rails are loading this files (for example, I > have 4 languages in my web app, each has her own .yml file, will my > rails app loads all the files in ram and then it will call each > variable inside my web app? Or something else?) > > Thank you :) > > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Talk" group. > To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org > To unsubscribe from this group, send email to > rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org<rubyonrails-talk%2Bunsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org> > . > For more options, visit this group at > http://groups.google.com/group/rubyonrails-talk?hl=en. > >-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Dhruva Sagar wrote:> Yes it is better to store the multilanguage strings in the .yml files. > Why you ask, well are you going to have all your record entries repeat > one > for each language you intent to support ?? Do you think that would be a > good > idea ??Do you think this is a bad idea?> > The database should have single values which the .yml files will > translate > into different languages depending on the locale settings.Not necessarily. It would be quite feasible to use the DB.> I am not very > sure regarding the loading of the different .yml files, that is > something > even I would like to know,Then don''t make statements like this till you *are* sure!> but from my experience / knowledge I don''t > think > that is the case since locale change requires me to restart the app. >Wrong again. The whole point of i18n is to present your app multilingually without restarting. Now, it seems to me that an advantage of text files over a DB is that you can hand them straight to a skilled translator... But anyway, Rails i18n pretty much sucks out of the box. Use fast_gettext.> Thanks & Regards, > Dhruva Sagar.Best, -- Marnen Laibow-Koser http://www.marnen.org marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Thanks & Regards, Dhruva Sagar. On Mon, Apr 26, 2010 at 17:39, Marnen Laibow-Koser <lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org>wrote:> Dhruva Sagar wrote: > > Yes it is better to store the multilanguage strings in the .yml files. > > Why you ask, well are you going to have all your record entries repeat > > one > > for each language you intent to support ?? Do you think that would be a > > good > > idea ?? > > Do you think this is a bad idea? >Yes I think it is a bad idea. First it is a bad database design which will lead to unnecessary complications while searching for data, also for indexing. If I have to support somewhere around 5-10 different languages, I really think having a 5-10 .yml files for translations will be a lot more performant compared to a 5-10 times larger database.> >>> > The database should have single values which the .yml files will > > translate > > into different languages depending on the locale settings. > > Not necessarily. It would be quite feasible to use the DB. > > I agree, but as I was saying I don''t consider it to be a good idea. HoweverI do agree it could be in some specific scenarios, but in general for a web application I do not think it is.> > > I am not very > > sure regarding the loading of the different .yml files, that is > > something > > even I would like to know, > > Then don''t make statements like this till you *are* sure! >I will keep that in mind.> > > but from my experience / knowledge I don''t > > think > > that is the case since locale change requires me to restart the app. > > > > Wrong again. The whole point of i18n is to present your app > multilingually without restarting. > > Now, it seems to me that an advantage of text files over a DB is that > you can hand them straight to a skilled translator... > > But anyway, Rails i18n pretty much sucks out of the box. Use > fast_gettext. >Thanks for this information.>> Thanks & Regards, > > Dhruva Sagar. > > Best, > -- > Marnen Laibow-Koser > http://www.marnen.org > marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org > > -- > Posted via http://www.ruby-forum.com/. > > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Talk" group. > To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org > To unsubscribe from this group, send email to > rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org<rubyonrails-talk%2Bunsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org> > . > For more options, visit this group at > http://groups.google.com/group/rubyonrails-talk?hl=en. > >-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Dhruva Sagar wrote:> Thanks & Regards, > Dhruva Sagar. > > > > On Mon, Apr 26, 2010 at 17:39, Marnen Laibow-Koser > <lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org>wrote: > >> Dhruva Sagar wrote: >> > Yes it is better to store the multilanguage strings in the .yml files. >> > Why you ask, well are you going to have all your record entries repeat >> > one >> > for each language you intent to support ?? Do you think that would be a >> > good >> > idea ?? >> >> Do you think this is a bad idea? >> > Yes I think it is a bad idea. > First it is a bad database design which will lead to unnecessary > complications while searching for data, also for indexing.Wrong. Internationalized strings have nothing to do with searching for data.> If I have to support somewhere around 5-10 different languages, I really > think having a 5-10 .yml files for translations will be a lot more > performant compared to a 5-10 times larger database.Wrong again. It may well be faster to use the DB.> >> >> > > >> > The database should have single values which the .yml files will >> > translate >> > into different languages depending on the locale settings. >> >> Not necessarily. It would be quite feasible to use the DB. >> >> I agree, but as I was saying I don''t consider it to be a good idea. However > I do agree it could be in some specific scenarios, but in general for a > web > application I do not think it is.But you are probably wrong. If you have a logical reason to think this, I''d like to hear it. However, the fact that you were wrong about restarting the app to switch locales makes me think you''re not really qualified to have an opinion here. [...]>> Now, it seems to me that an advantage of text files over a DB is that >> you can hand them straight to a skilled translator... >> >> But anyway, Rails i18n pretty much sucks out of the box. Use >> fast_gettext. >> > Thanks for this information. >You''re welcome!>>Best, -- Marnen Laibow-Koser http://www.marnen.org marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On Mon, Apr 26, 2010 at 17:58, Marnen Laibow-Koser <lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org>wrote:> Dhruva Sagar wrote: > > Thanks & Regards, > > Dhruva Sagar. > > > > > > > > On Mon, Apr 26, 2010 at 17:39, Marnen Laibow-Koser > > <lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org>wrote: > > > >> Dhruva Sagar wrote: > >> > Yes it is better to store the multilanguage strings in the .yml files. > >> > Why you ask, well are you going to have all your record entries repeat > >> > one > >> > for each language you intent to support ?? Do you think that would be > a > >> > good > >> > idea ?? > >> > >> Do you think this is a bad idea? > >> > > Yes I think it is a bad idea. > > First it is a bad database design which will lead to unnecessary > > complications while searching for data, also for indexing. > > Wrong. Internationalized strings have nothing to do with searching for > data. >eg.) Lets say I have a User model and each user has a ''role'' as a column. So if I want to internationalize the value of the ''Role'', you propose that it should be done using the database ? I imagine so then for internationalizing to 5 different languages, I would then have to create 5 records for this very user with different ''Role'' values for each language. That is first of all not normalized data. Second of all it makes your basic search / find queries to be lesser performant (compared to if you weren''t doing this) since you will always have to ensure that you get the record with the specific language you are currently displaying, meaning you will have a perpetual where clause. If your solution is to have the value of ''Role'' as a set of localized values delimited by some special character, then that is even worse. If I wanted to get users by ''Role'' I would then have to use a LIKE query instead of a ''='', which is obviously not as performant again. I simply choose to have a simple set of values of Roles, say ''Admin'', ''User'', etc which I can easily capture and use i18n to get the appropriate transated text loaded from the appropriate .yml file> > > If I have to support somewhere around 5-10 different languages, I really > > think having a 5-10 .yml files for translations will be a lot more > > performant compared to a 5-10 times larger database. > > Wrong again. It may well be faster to use the DB. >You are wrong here, the files will be loaded in memory once, I can''t imagine any database query performing better than querying a file that is already in memory.> > > > >> > >> > > > > >> > The database should have single values which the .yml files will > >> > translate > >> > into different languages depending on the locale settings. > >> > >> Not necessarily. It would be quite feasible to use the DB. > >> > >> I agree, but as I was saying I don''t consider it to be a good idea. > However > > I do agree it could be in some specific scenarios, but in general for a > > web > > application I do not think it is. > > But you are probably wrong. If you have a logical reason to think this, > I''d like to hear it. > > However, the fact that you were wrong about restarting the app to switch > locales makes me think you''re not really qualified to have an opinion > here. >I have just tried the exact scenario using mongrel. I had to restart the app once I changed the locale. So my assumption was based on that. Maybe there are other better ways of doing the same without restarting my app, or maybe fusion or other servers support the same, but as I said ''in my experience...'' I don''t claim to be any expert, I have little experience in rails, I was expressing what I had experienced.> > [...] > >> Now, it seems to me that an advantage of text files over a DB is that > >> you can hand them straight to a skilled translator... > >> > >> But anyway, Rails i18n pretty much sucks out of the box. Use > >> fast_gettext. > >> > > Thanks for this information. > > > > You''re welcome! > > >> > > Best, > -- > Marnen Laibow-Koser > http://www.marnen.org > marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org > -- > Posted via http://www.ruby-forum.com/. > > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Talk" group. > To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org > To unsubscribe from this group, send email to > rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org<rubyonrails-talk%2Bunsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org> > . > For more options, visit this group at > http://groups.google.com/group/rubyonrails-talk?hl=en. > >-- Thanks & Regards, Dhruva Sagar. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
TSagar I am not sure I quite understand your example, it will translate the string "Role" in each language and there are many approaches to do a multilingual database design. I would make a database multilanguage design by setting each language in separate table, this approach will be normalized. Also I am wondering how good it is to load all the locales yml file into the ram... it''s ok for speed, but it will use many ram and maybe this is a bit scary... I''ll check the fast_gettext, thank you :) On Apr 26, 3:55 pm, Dhruva Sagar <dhruva.sa...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> On Mon, Apr 26, 2010 at 17:58, Marnen Laibow-Koser <li...-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org>wrote: > > > > > Dhruva Sagar wrote: > > > Thanks & Regards, > > > Dhruva Sagar. > > > > On Mon, Apr 26, 2010 at 17:39, Marnen Laibow-Koser > > > <li...-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org>wrote: > > > >> Dhruva Sagar wrote: > > >> > Yes it is better to store the multilanguage strings in the .yml files. > > >> > Why you ask, well are you going to have all your record entries repeat > > >> > one > > >> > for each language you intent to support ?? Do you think that would be > > a > > >> > good > > >> > idea ?? > > > >> Do you think this is a bad idea? > > > > Yes I think it is a bad idea. > > > First it is a bad database design which will lead to unnecessary > > > complications while searching for data, also for indexing. > > > Wrong. Internationalized strings have nothing to do with searching for > > data. > > eg.) Lets say I have a User model and each user has a ''role'' as a column. So > if I want to internationalize the value of the ''Role'', you propose that it > should be done using the database ? > > I imagine so then for internationalizing to 5 different languages, I would > then have to create 5 records for this very user with different ''Role'' > values for each language. > That is first of all not normalized data. > Second of all it makes your basic search / find queries to be lesser > performant (compared to if you weren''t doing this) since you will always > have to ensure that you get the record with the specific language you are > currently displaying, meaning you will have a perpetual where clause. > > If your solution is to have the value of ''Role'' as a set of localized values > delimited by some special character, then that is even worse. If I wanted to > get users by ''Role'' I would then have to use a LIKE query instead of a ''='', > which is obviously not as performant again. > > I simply choose to have a simple set of values of Roles, say ''Admin'', > ''User'', etc which I can easily capture and use i18n to get the appropriate > transated text loaded from the appropriate .yml file > > > > > > If I have to support somewhere around 5-10 different languages, I really > > > think having a 5-10 .yml files for translations will be a lot more > > > performant compared to a 5-10 times larger database. > > > Wrong again. It may well be faster to use the DB. > > You are wrong here, the files will be loaded in memory once, I can''t imagine > any database query performing better than querying a file that is already in > memory. > > > > > > > >> > The database should have single values which the .yml files will > > >> > translate > > >> > into different languages depending on the locale settings. > > > >> Not necessarily. It would be quite feasible to use the DB. > > > >> I agree, but as I was saying I don''t consider it to be a good idea. > > However > > > I do agree it could be in some specific scenarios, but in general for a > > > web > > > application I do not think it is. > > > But you are probably wrong. If you have a logical reason to think this, > > I''d like to hear it. > > > However, the fact that you were wrong about restarting the app to switch > > locales makes me think you''re not really qualified to have an opinion > > here. > > I have just tried the exact scenario using mongrel. I had to restart the app > once I changed the locale. So my assumption was based on that. > Maybe there are other better ways of doing the same without restarting my > app, or maybe fusion or other servers support the same, but as I said ''in my > experience...'' > I don''t claim to be any expert, I have little experience in rails, I was > expressing what I had experienced. > > > > > > > [...] > > >> Now, it seems to me that an advantage of text files over a DB is that > > >> you can hand them straight to a skilled translator... > > > >> But anyway, Rails i18n pretty much sucks out of the box. Use > > >> fast_gettext. > > > > Thanks for this information. > > > You''re welcome! > > > Best, > > -- > > Marnen Laibow-Koser > >http://www.marnen.org > > mar...-sbuyVjPbboAdnm+yROfE0A@public.gmane.org > > -- > > Posted viahttp://www.ruby-forum.com/. > > > -- > > You received this message because you are subscribed to the Google Groups > > "Ruby on Rails: Talk" group. > > To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org > > To unsubscribe from this group, send email to > > rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org<rubyonrails-talk%2Bunsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org> > > . > > For more options, visit this group at > >http://groups.google.com/group/rubyonrails-talk?hl=en. > > -- > > Thanks & Regards, > Dhruva Sagar. > > -- > You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. > To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org > To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. > For more options, visit this group athttp://groups.google.com/group/rubyonrails-talk?hl=en.-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On 26 April 2010 13:55, Dhruva Sagar <dhruva.sagar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:>... > > eg.) Lets say I have a User model and each user has a ''role'' as a column. So > if I want to internationalize the value of the ''Role'', you propose that it > should be done using the database ? > I imagine so then for internationalizing to 5 different languages, I would > then have to create 5 records for this very user with different ''Role'' > values for each language.I suggest that the role as a string ''Administrator'' or whatever should not be a column in the users table. The roles should be in a separate table, with user belongs_to role. I think this will make your life much easier. Colin -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Colin Law wrote:> On 26 April 2010 13:55, Dhruva Sagar <dhruva.sagar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: >>... >> >> eg.) Lets say I have a User model and each user has a ''role'' as a column. So >> if I want to internationalize the value of the ''Role'', you propose that it >> should be done using the database ? >> I imagine so then for internationalizing to 5 different languages, I would >> then have to create 5 records for this very user with different ''Role'' >> values for each language. > > I suggest that the role as a string ''Administrator'' or whatever should > not be a column in the users table. The roles should be in a separate > table, with user belongs_to role. I think this will make your life > much easier.I agree 100%.> > ColinBest, -- Marnen Laibow-Koser http://www.marnen.org marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
@Colin Ahh yes of course, well my example was just to demonstrate the usage of i18n. Roles should of course me a separate table, but then again, the separate table will have a role column right :). @Yiannis Using multiple tables for the purpose of internationalization to me seems like such an overkill, how do you map a single model to different table based on the locale ? On Mon, Apr 26, 2010 at 21:53, Colin Law <clanlaw-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote:> On 26 April 2010 13:55, Dhruva Sagar <dhruva.sagar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > >... > > > > eg.) Lets say I have a User model and each user has a ''role'' as a column. > So > > if I want to internationalize the value of the ''Role'', you propose that > it > > should be done using the database ? > > I imagine so then for internationalizing to 5 different languages, I > would > > then have to create 5 records for this very user with different ''Role'' > > values for each language. > > I suggest that the role as a string ''Administrator'' or whatever should > not be a column in the users table. The roles should be in a separate > table, with user belongs_to role. I think this will make your life > much easier. > > Colin > > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Talk" group. > To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org > To unsubscribe from this group, send email to > rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org<rubyonrails-talk%2Bunsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org> > . > For more options, visit this group at > http://groups.google.com/group/rubyonrails-talk?hl=en. > >-- Thanks & Regards, Dhruva Sagar. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
There isn''t really one answer to where to store different language values for a string. It depends on the case. There are two main ones. For static strings (text in templates, error messages), using locales/*.yml makes sense as they are easy to edit and use. They are called frequently and rarely change and thus loading them into memory once makes sense rather than pulling them from the database (though you could compromise and use cache per locale to offset this). See the translate plugin (http://github.com/newsdesk/translate) to add an administrator interface for them. For Rails there is also a number of standard strings already translated that you can simply grab from http://github.com/svenfuchs/rails-i18n/tree/master/rails/locale/. For dynamic strings that are from content pulled from the database anyway, most plugins and gems (globalize2, etc.) store the translations in the database. I''m actually working on a new gem that stores the translations in MongoDB that is paired with a standard RDBMS backed ActiveRecord (http://github.com/kete/mongo_translatable - not yet alpha) and there are many other plugins and gems that also work with translating dynamic content. You would probably get better answers asking this on the l18n specific http://groups.google.com/group/rails-i18n?pli=1. You should also check out http://rails-i18n.org/wiki and http://guides.rubyonrails.org/i18n.html, too. Cheers, Walter -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Thanks a lot for that, that''s a good reply :) On Tue, Apr 27, 2010 at 07:02, Walter McGinnis <walter.mcginnis-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>wrote:> There isn''t really one answer to where to store different language > values for a string. It depends on the case. There are two main > ones. > > For static strings (text in templates, error messages), using > locales/*.yml makes sense as they are easy to edit and use. They are > called frequently and rarely change and thus loading them into memory > once makes sense rather than pulling them from the database (though > you could compromise and use cache per locale to offset this). See the > translate plugin (http://github.com/newsdesk/translate) to add an > administrator interface for them. For Rails there is also a number of > standard strings already translated that you can simply grab from > http://github.com/svenfuchs/rails-i18n/tree/master/rails/locale/. > > For dynamic strings that are from content pulled from the database > anyway, most plugins and gems (globalize2, etc.) store the > translations in the database. I''m actually working on a new gem that > stores the translations in MongoDB that is paired with a standard > RDBMS backed ActiveRecord (http://github.com/kete/mongo_translatable - > not yet alpha) and there are many other plugins and gems that also > work with translating dynamic content. > > You would probably get better answers asking this on the l18n specific > http://groups.google.com/group/rails-i18n?pli=1. You should also > check out http://rails-i18n.org/wiki and > http://guides.rubyonrails.org/i18n.html, too. > > Cheers, > Walter > > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Talk" group. > To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org > To unsubscribe from this group, send email to > rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org<rubyonrails-talk%2Bunsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org> > . > For more options, visit this group at > http://groups.google.com/group/rubyonrails-talk?hl=en. > >-- Thanks & Regards, Dhruva Sagar. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.