Languages

Rails
1

My client has a translator and wants a lot of his page content to be
translated into 6 different languages.

When a user selects their language on the front end, it need to alter
the Page content, Page title and Navigation title.

I’ve made alternate columns in my database for the other languages.
Although it’s messy, it is what the client requested.

So I assume I’ll need an action in my application controller to set
session data and then render the appropriate content front-end.

Now, can someone give me any help regarding this process, or has anyone
come across this before?

2

Pale H. wrote:

My client has a translator and wants a lot of his page content to be
translated into 6 different languages.

When a user selects their language on the front end, it need to alter
the Page content, Page title and Navigation title.

I’ve made alternate columns in my database for the other languages.
Although it’s messy, it is what the client requested.

So I assume I’ll need an action in my application controller to set
session data and then render the appropriate content front-end.

Now, can someone give me any help regarding this process, or has anyone
come across this before?

First I have to ask if you have read the Rails Internationalization
(I18n) guide:

Or is your question specifically related to how to store the user’s
preferred language.

3

Robert W. wrote:

Pale H. wrote:

My client has a translator and wants a lot of his page content to be
translated into 6 different languages.

When a user selects their language on the front end, it need to alter
the Page content, Page title and Navigation title.

I’ve made alternate columns in my database for the other languages.
Although it’s messy, it is what the client requested.

So I assume I’ll need an action in my application controller to set
session data and then render the appropriate content front-end.

Now, can someone give me any help regarding this process, or has anyone
come across this before?

First I have to ask if you have read the Rails Internationalization
(I18n) guide:

Rails Internationalization (I18n) API — Ruby on Rails Guides

I’ve not read this, though I imagine it to be overkill for my purposes.

Or is your question specifically related to how to store the user’s
preferred language.

What I really want is to render a different column based on the session
data.

4

On Tue, Aug 3, 2010 at 11:06 AM, Pale H. [email protected]
wrote:

I’ve not read this, though I imagine it to be overkill for my purposes.
Really?
You should read it. That’s how rails works with i18n. Overkill would
be to implement a different solution when a lot (and I mean a LOT) of
people already worked it out in a really nice way.
If you think that translate an application to 6 different languages
doesn’t need an elegant and easy-to-maintain solution, then you’re in
trouble.

Or is your question specifically related to how to store the user’s
preferred language.

What I really want is to render a different column based on the session
data.
If you want to do that, it’s a different story. You don’t need to ask
anybody to do that, just make a case/when structure and you’ll be on
your way.

–
Leonardo M…
There’s no place like ~

5

Marnen Laibow-Koser wrote:

Rails I18N is not “really nice”. I recommend fast_gettext instead.

If you think that translate an application to 6 different languages
doesn’t need an elegant and easy-to-maintain solution, then you’re in
trouble.

Agreed.

Or is your question specifically related to how to store the user’s
preferred language.

What I really want is to render a different column based on the session
data.

No, you really don’t. You want to use one of the existing I18N
solutions – and you don’t want to add a column to the DB every time you
need to support another language.

If you want to do that, it’s a different story. You don’t need to ask
anybody to do that, just make a case/when structure and you’ll be on
your way.

But don’t do it.

How effective and accurate are the I18N translation solutions? More-so
than members of the foreign-speaking countries themselves that my client
is in contact with?

6

Leonardo M. wrote:

On Tue, Aug 3, 2010 at 11:06 AM, Pale H. [email protected]
wrote:

I’ve not read this, though I imagine it to be overkill for my purposes.
Really?
You should read it. That’s how rails works with i18n. Overkill would
be to implement a different solution when a lot (and I mean a LOT) of
people already worked it out in a really nice way.

Rails I18N is not “really nice”. I recommend fast_gettext instead.

If you think that translate an application to 6 different languages
doesn’t need an elegant and easy-to-maintain solution, then you’re in
trouble.

Agreed.

Or is your question specifically related to how to store the user’s
preferred language.

What I really want is to render a different column based on the session
data.

No, you really don’t. You want to use one of the existing I18N
solutions – and you don’t want to add a column to the DB every time you
need to support another language.

If you want to do that, it’s a different story. You don’t need to ask
anybody to do that, just make a case/when structure and you’ll be on
your way.

But don’t do it.

–
Leonardo M…
There’s no place like ~

Best,

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

7

Marnen Laibow-Koser wrote:

Pale H. wrote:
[…]

How effective and accurate are the I18N translation solutions? More-so
than members of the foreign-speaking countries themselves that my client
is in contact with?

The Rails I18N modules are not translation solutions. They’re simply
modules for managing the translated text. You still need a human
translator to generate that translated text.

Best,

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

Thank you. I’ll investigate that now.

8

Pale H. wrote:
[…]

How effective and accurate are the I18N translation solutions? More-so
than members of the foreign-speaking countries themselves that my client
is in contact with?

The Rails I18N modules are not translation solutions. They’re simply
modules for managing the translated text. You still need a human
translator to generate that translated text.

Best,

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

9

On Aug 3, 11:25 pm, Marnen Laibow-Koser [email protected] wrote:

RailsI18Nis not “really nice”. I recommend fast_gettext instead.

Marnen,

I am currently working on a multiple language application using rails
I18n and globalize2 to facilitate
the rendering of our application’s static and activerecord database
fields in multiple languages.

Not knowing much about fast_gettext except what I have read on the
github page, could you elaborate on your comment
that I18n is not very nice? and given your experience explain what
advantages a switch/utilization of fast gettext would
provide. Also, would there be a steep learning curve by switching?

Your thoughts would be much appreciated.

Regards

David

10

Pale H. wrote:

Marnen Laibow-Koser wrote:

Pale H. wrote:
[…]

How effective and accurate are the I18N translation solutions? More-so
than members of the foreign-speaking countries themselves that my client
is in contact with?

The Rails I18N modules are not translation solutions. They’re simply
modules for managing the translated text. You still need a human
translator to generate that translated text.

Best,

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

Thank you. I’ll investigate that now.

Actually, I think some of the Rails I18N stuff may have translations of
common Rails boilerplate (“{{model}} could not be saved because of the
following errors”), but for anything nonstandard, my point stands.

Best,

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

11

dbkbali wrote:

On Aug 3, 11:25�pm, Marnen Laibow-Koser [email protected] wrote:

RailsI18Nis not “really nice”. �I recommend fast_gettext instead.

Marnen,

I am currently working on a multiple language application using rails
I18n and globalize2 to facilitate
the rendering of our application’s static and activerecord database
fields in multiple languages.

Not knowing much about fast_gettext except what I have read on the
github page, could you elaborate on your comment
that I18n is not very nice?

Rails I18N seems needlessly complex to me, and uses symbolic keys
(“application.welcome”) so that your view files are not easily readable.
It also stores the translated strings in YAML files. I don’t think it
handles pluralization as well as gettext, though I could be wrong.

By contrast, fast_gettext (which works with the Rails I18N
infrastructure) works like GNU Gettext: it uses the translatable strings
themselves as keys (“Welcome to my site!”), so that your view files are
still readable and all hell doesn’t break loose if you miss a key. It
stores the translated strings in industry-standard PO files, which
professional translators can be assumed to know how to deal with.

and given your experience explain what
advantages a switch/utilization of fast gettext would
provide.

Gettext is easier to work with.

Also, would there be a steep learning curve by switching?

I don’t know. I was using gettext before Rails I18N existed, so when
Rails I18N came out, I looked at the default I18N mechanism, concluded
it was clumsier than gettext, and went on using gettext (but this time
as a Rails I18N plugin).

Gettext is so simple, however, that I can’t imagine that t would be
difficult to learn. What might be time-consuming is switching your
views to use gettext-style string keys.

But really, do your own research. Install gettext and try converting a
view or two. See GitHub - marnen/quorum2: The Quorum calendar system. if you want to see
what views done with gettext look like.

Your thoughts would be much appreciated.

Regards

David

Best,
–Â
Marnen Laibow-Koser
http://www.marnen.org
[email protected]

Sent from my iPhone

12

Frederick C. wrote:

On Aug 19, 1:26�pm, Marnen Laibow-Koser [email protected] wrote:

By contrast, fast_gettext (which works with the Rails I18N
infrastructure) works like GNU Gettext: it uses the translatable strings
themselves as keys (“Welcome to my site!”), so that your view files are
still readable and all hell doesn’t break loose if you miss a key. �It
stores the translated strings in industry-standard PO files, which
professional translators can be assumed to know how to deal with.

If the key is the translatable string, how do you handle the case
where in english (or whatever your source language is) two things
have the same text but they don’t in one of the languages you’re
translating into?

I understand the possibility, but I’ve never run into that in practice.
I believe there are ways to disambiguate.

Fred

Best,

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

13

On Aug 19, 1:26 pm, Marnen Laibow-Koser [email protected] wrote:

By contrast, fast_gettext (which works with the Rails I18N
infrastructure) works like GNU Gettext: it uses the translatable strings
themselves as keys (“Welcome to my site!”), so that your view files are
still readable and all hell doesn’t break loose if you miss a key. It
stores the translated strings in industry-standard PO files, which
professional translators can be assumed to know how to deal with.

If the key is the translatable string, how do you handle the case
where in english (or whatever your source language is) two things
have the same text but they don’t in one of the languages you’re
translating into?

Fred

14

On Aug 19, 8:26 pm, Marnen Laibow-Koser [email protected] wrote:

infrastructure) works like GNU Gettext: it uses the translatable strings

David

Best,

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

Sent from my iPhone

Posted viahttp://www.ruby-forum.com/.

Thanks Marnen,

Good to have a practical opinion as there was some conflicting
opinions when I googled “fast gettext”.

Your feedback is much appreciated.

Regards

David