Rails I18n

Rails
1

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 :slight_smile:

2

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 Sā€¦

3

Dhruva S. 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 Sā€¦

Best,

Marnen Laibow-Koser
http://www.marnen.org
[email protected]

4

Thanks & Regards,
Dhruva Sā€¦

On Mon, Apr 26, 2010 at 17:39, Marnen Laibow-Koser
[email protected]wrote:

Dhruva S. 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. However
I 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.

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.

5

Dhruva S. wrote:

Thanks & Regards,
Dhruva Sā€¦

On Mon, Apr 26, 2010 at 17:39, Marnen Laibow-Koser
[email protected]wrote:

Dhruva S. 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
[email protected]

6

On Mon, Apr 26, 2010 at 17:58, Marnen Laibow-Koser
[email protected]wrote:

Yes it is better to store the multilanguage strings in the .yml files.
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.

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.

Posted via http://www.ruby-forum.com/.

ā€“

Thanks & Regards,
Dhruva Sā€¦

7

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 :slight_smile:

8

On 26 April 2010 13:55, Dhruva S. [email protected] 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

9

Colin L. wrote:

On 26 April 2010 13:55, Dhruva S. [email protected] 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%.

Colin

Best,

Marnen Laibow-Koser
http://www.marnen.org
[email protected]

10

@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 L. [email protected] wrote:

then have to create 5 records for this very user with different ā€˜Roleā€™
You received this message because you are subscribed to the Google G.
ā€œRuby on Rails: Talkā€ group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected][email protected]
.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

ā€“

Thanks & Regards,
Dhruva Sā€¦

11

Thanks a lot for that, thatā€™s a good reply :slight_smile:

On Tue, Apr 27, 2010 at 07:02, Walter McGinnis
[email protected]wrote:

administrator interface for them. For Rails there is also a number of

ā€œRuby on Rails: Talkā€ group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected][email protected]
.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

ā€“

Thanks & Regards,
Dhruva Sā€¦

12

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
rails-i18n/rails/locale at master Ā· svenfuchs/rails-i18n Ā· GitHub.

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 (GitHub - kete/mongo_translatable: Rails specific I18n model localization, ala Globalize2, backed by MongoDB rather than an RDBMS. May include UI elements, too. -
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
Rails Internationalization (I18n) API ā€” Ruby on Rails Guides, too.

Cheers,
Walter