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...@gmail.com> wrote: > On Mon, Apr 26, 2010 at 17:58, Marnen Laibow-Koser > <li...@ruby-forum.com>wrote: > > > > > Dhruva Sagar wrote: > > > Thanks & Regards, > > > Dhruva Sagar. > > > > On Mon, Apr 26, 2010 at 17:39, Marnen Laibow-Koser > > > <li...@ruby-forum.com>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...@marnen.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-t...@googlegroups.com. > > To unsubscribe from this group, send email to > > rubyonrails-talk+unsubscr...@googlegroups.com<rubyonrails-talk%2bunsubscr...@googlegroups.com> > > . > > 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-t...@googlegroups.com. > To unsubscribe from this group, send email to > rubyonrails-talk+unsubscr...@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-t...@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-talk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
