Dhruva Sagar wrote:
Thanks & Regards,
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
for each language you intent to support ?? Do you think that would be a
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
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
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
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
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.