Languages

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?

Pale Horse 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:

http://guides.rubyonrails.org/i18n.html

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

Robert Walker wrote:

Pale Horse 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:

http://guides.rubyonrails.org/i18n.html

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.

Robert Walker wrote:

Pale Horse 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:

http://guides.rubyonrails.org/i18n.html

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 Mateo 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 Mateo.
There's no place like ~

Best,

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?

Pale Horse 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 wrote:

Pale Horse 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
marnen@marnen.org

Thank you. I'll investigate that now.

Pale Horse wrote:

Marnen Laibow-Koser wrote:

Pale Horse 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
marnen@marnen.org

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,

Leonardo Mateo 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 withi18n. 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.

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

dbkbali 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 http://github.com/marnen/quorum2 if you want to see
what views done with gettext look like.

Your thoughts would be much appreciated.

Regards

David

Best,

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

Frederick Cheung 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,

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