Rails core going multiligual...ever?


#1

Hi,

I have seen a lot of threads over the last couple weeks about using
rails
for multilingual sites. What is the plan for the rails core with respect
to
going multilingual. Is it in the future plans? It seems like a lot of
people
want this which I think makes it a framework issue. After all,
translation
isn’t specific to a particular application.

There are many sources of text that is displayed on a web page. I can at
least think of four sources

  • dynamic from the database
  • static in the template files
  • generated by a flash
  • generated by validation (the header and the list of errors)
  • more?

It would be nice if there was a unified approach to having all of these
translated the same way and in a slick manner the way Rails does so many
things.

I suppose the first thing would be defining a standard way to handle the
session variable holding the current language.

Any thoughts about the future of multilingualism and Rails?

Thanks,
Peter


Rails core going multiligual...ever?
Re: Rails core going multiligual...ever?
#2

As I mentioned on the rails-core list, Josh Sierles and I are going to
release an i18n plugin based on Muiltilingual Rails. It also supports
translating db content via a class method, e.g.:

class Product < ActiveRecord::Base
translates :name, :description
end

Locale.set(“es_ES”)
product = Product.find 1
product.name -> “Albondigas”

Locale.set(“en_US”)
product = Product.find 1
product.name -> “Meatballs”

It also comes with a fairly complete table of languages.

My hope is that once it becomes well established as a plugin, it will
eventually be integrated into rails core. If anybody want to check out
the beta code, send me an email at removed_email_address@domain.invalid and I’ll send you
the subversion url. We need help with testing and docs.

Josh Harvey

Julian ‘Julik’ Tarkhanov wrote:

They don’t care. None of the core users of Rails need this
functionality as I know. The answer will be “make a plugin”.

Muiltilingual Rails project was promising, I think it could have
given Rails a good foundation - but will parties involved
agree to the ways it has to do stuff?


#3

Good point, Sascha – our library is indeed LGPL. My take is I’ll make
my code any license that will get it into rails. The problem is we’re
using code from another author (Per Wigren), and we’ll need permission
from him, too. We’ve just managed to make brief contact with him, so
I’ll keep you posted.

Josh Harvey


#4

On 10-nov-2005, at 6:52, Peter M. wrote:

Hi,

I have seen a lot of threads over the last couple weeks about using
rails for multilingual sites. What is the plan for the rails core
with respect to going multilingual. Is it in the future plans? It
seems like a lot of people want this which I think makes it a
framework issue. After all, translation isn’t specific to a
particular application.

Any thoughts about the future of multilingualism and Rails?

They don’t care. None of the core users of Rails need this
functionality as I know. The answer will be “make a plugin”.

Muiltilingual Rails project was promising, I think it could have
given Rails a good foundation - but will parties involved
agree to the ways it has to do stuff?

I mean - can imagine the protetst when we try to put an
implementation of Locale and a proper full ISO contry list in there…


#5

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Nov 10, 2005, at 1:16 PM, Julian ‘Julik’ Tarkhanov wrote:

They don’t care. None of the core users of Rails need this
functionality as I know. The answer will be “make a plugin”.

I am using Rails for a large internationalized webapp. Localization
is a hard problem whose solution varies from simple yaml files to
large, heavyweight frameworks like ICU. “They don’t care”
inaccurately portrays the problem that localization poses.

This answer is to make a plugin. Let’s throw some solutions on the
wall and see what sticks and for whom.

Muiltilingual Rails project was promising, I think it could have
given Rails a good foundation - but will parties involved
agree to the ways it has to do stuff?

The project has been picked up by new developers and is progressing
nicely.

Unfortunately, it is GPL and therefore incompatible with Rails’ MIT
license.

I mean - can imagine the protetst when we try to put an
implementation of Locale and a proper full ISO contry list in there…

I wish this was included in Ruby proper, rather than having to solve
the problem in Rails. Likewise with character encoding issues.

Best,
jeremy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (Darwin)

iD8DBQFDc7zOAQHALep9HFYRAk6ZAJ0fxHbcN2Q+42O6wF/MJo7hTHTziwCgnA9D
ceEOccEKyston+vH3ad/Ll0=
=SX2a
-----END PGP SIGNATURE-----


#6

Jeremy
> This answer is to make a plugin.

Core core or core plugin, it doesn’t matter, but it really needs to be
part of the - 1.0 - standard distribution.
Another obvious candidate is authentication: half a dozen solutions, and
growing, just to add a “login” to your app!? It’s messy. There should
be one - plugin - in the core.

AJAX is neat, but authentication and i18n are vital.

Alain R.


#7

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Nov 10, 2005, at 2:06 PM, Alain R. wrote:

Jeremy

This answer is to make a plugin.

Core core or core plugin, it doesn’t matter, but it really needs
to be part of the - 1.0 - standard distribution.
Another obvious candidate is authentication: half a dozen
solutions, and growing, just to add a “login” to your app!? It’s
messy. There should be one - plugin - in the core.

AJAX is neat, but authentication and i18n are vital.

Thank you for the reemphasis. Note that I do not disagree.

jeremy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (Darwin)

iD8DBQFDc87YAQHALep9HFYRAhjgAKDeRxvRA2EnLxKiJ/T9CLaWINta9gCeJ9bN
6BJuLMSTajBhApYbbgPNyp8=
=rUVV
-----END PGP SIGNATURE-----


#8

On 11/10/05, Jeremy K. removed_email_address@domain.invalid wrote:

I am using Rails for a large internationalized webapp. Localization
is a hard problem whose solution varies from simple yaml files to
large, heavyweight frameworks like ICU.

This implies that one solution doesn’t fit all problems which is always
true. But this thinking would apply to web frameworks as well. I’m
chosing
to use Rails because eventhough Rails may makes certain tasks more
difficult, in general Rails makes things easier. Can’t we take a
similarly
opinionated software approach with internationalization as Rails has
with
web frameworks?

This answer is to make a plugin. Let’s throw some solutions on the
wall

and see what sticks and for whom.

Is this effort organized or just a bunch people re-inventing the wheel?
(The
reason I ran from PHP and all it’s fragmented frameworks.)

If the solution is inside or outside of core Rails cannot break when
someone
using i18n wants to upgrade Rails. I heard that was a problem with the
multilingual rails project. Maybe not true though.

But enough talk, I’d like to get involved. I’d really like to see a
(complete?) list of the i18n problems that need to be addressed.

Thanks,
Peter


#9

On 11/10/05, Jeremy K. removed_email_address@domain.invalid wrote:

I wish this was included in Ruby proper, rather than having to solve

the problem in Rails. Likewise with character encoding issues.

Could this be written for Ruby? Ruby is extensible with C code, yes?


#10

On 11/10/05, Alain R. removed_email_address@domain.invalid wrote:

AJAX is neat, but authentication and i18n are vital.

Well said! AJAX optimizes the user experience. A lot of people need
authentication and i18n and I still think they are framework issues.


#11

I just wanted to chip in that I’ve been using Joshua’s Multilingual
Rails Plugin for the last day or two. It’s been great, other than a
few small bugs. Thanks for the good work!


#12

Jeremy K. wrote:

Muiltilingual Rails project was promising, I think it could have given
Rails a good foundation - but will parties involved
agree to the ways it has to do stuff?

The project has been picked up by new developers and is progressing nicely.

Unfortunately, it is GPL and therefore incompatible with Rails’ MIT
license.

Hi Jeremy,

that is not true. Ri18n is GPL, which really is bad (for me) since I
have
invested so much time in it and it seems dead. I can’t reach the main
author and development is halted for over six months.

Multilingual Rails on the other hand is LGPL which would allow to
include
it into Rails. I am sure that the original authors would change licences
if
asked. Any author would like to see his/her lib make it into the Rails
core
because that means indefinite stardom :wink:

SO, Joshua Harvey, what is your take on that?

Sascha Ebacdh


#13

David Heinemeier H. wrote:

AJAX is neat, but authentication and i18n are vital.
Well said! AJAX optimizes the user experience. A lot of people need
authentication and i18n and I still think they are framework issues.

Let’s not mix these together. I agree that a i18n definitely stands a
shot at making it into the Rails core, …

Ooh, that gives me hope. I will print this and hang it on the wall :wink:

Good support for i18n before 2.0 would be just great.

Sascha E.


#14

AJAX is neat, but authentication and i18n are vital.

Well said! AJAX optimizes the user experience. A lot of people need
authentication and i18n and I still think they are framework issues.

Let’s not mix these together. I agree that a i18n definitely stands a
shot at making it into the Rails core, but authentication absolutely
does not. There’s a fine line between infrastructure and business
logic. i18n sits on the infrastructure side, authentication on the
business logic side.

David Heinemeier H.
http://www.loudthinking.com – Broadcasting Brain
http://www.basecamphq.com – Online project management
http://www.backpackit.com – Personal information manager
http://www.rubyonrails.com – Web-application framework


#15

removed_email_address@domain.invalid wrote:

I agree that a i18n definitely stands a
shot at making it into the Rails core,

Is there already an organized effort to make this happen?

The organized effort is for a Best of Breed™ plugin to emerge and
win the hearts of many. There’s quite a few contenders out there. Even
one in the Rails svn under plugins/localization.

David Heinemeier H.
http://www.loudthinking.com – Broadcasting Brain
http://www.basecamphq.com – Online project management
http://www.backpackit.com – Personal information manager
http://www.rubyonrails.com – Web-application framework


#16

On 11/11/05, David Heinemeier H. removed_email_address@domain.invalid
wrote:

I agree that a i18n definitely stands a
shot at making it into the Rails core,

Is there already an organized effort to make this happen?


#17

Let’s not mix these together. I agree that a i18n definitely stands a
shot at making it into the Rails core, but authentication absolutely
does not. There’s a fine line between infrastructure and business
logic. i18n sits on the infrastructure side, authentication on the
business logic side.

Some built-in authentication as part of the infrastructure itself would
be
valuable maybe. Something such as providing a structure or mechanism
where
people or the core team could plug authentication providers (along with
maybe the most common authentication providers such as say LDAP). Could
be
something quite similar to the authentication providers in ASP.Net 2
(see
[1]) ?
About i18n the need is obviously there, but I’m wondering if the answer
will only address translation of text messages, or also things such as :


#18

On 11-nov-2005, at 17:35, David Heinemeier H. wrote:

removed_email_address@domain.invalid wrote:

I agree that a i18n definitely stands a
shot at making it into the Rails core,

Is there already an organized effort to make this happen?

The organized effort is for a Best of Breed™ plugin to emerge and
win the hearts of many. There’s quite a few contenders out there. Even
one in the Rails svn under plugins/localization.

I’m very sorry to interrupt this debate, but is it sane to engage in
a plugin which will have to override like a good 2/5ths of ActionPack
and quite some AR ounyl to find out it broke with the next 0.0.01
update?

The one under plugins/localization is nice, but it translates strings.

Rails, should I remind you, must have error messages, helpers, date
and coutnry selects (which don’t even use ISO code now) not minding
model field translations etc. Most of this functionality can’t be
bolted on as a plugin because it needs very heavy overriding of the
Rails internals.


#19

On 11 Nov 2005, at 13:11, David Heinemeier H. wrote:

Let’s not mix these together. I agree that a i18n definitely stands a
shot at making it into the Rails core, but authentication absolutely
does not. There’s a fine line between infrastructure and business
logic. i18n sits on the infrastructure side, authentication on the
business logic side.

I won’t disagree with that sentiment around authentication (actually,
because I’m an IETF-head, let’s call that AAA), but just realise that
without i18n Rails is for many of us, in essence, just a toy
framework - there is no way on Earth I can take this into work
projects I’m hoping to deploy across the whole of the EU if it won’t
do i18n. It’s core, and for me it’s a show-stopper if it’s not there
in 1.0. I’d love to switch all development effort to Rails, but
without i18n, there’s no hope.

I appreciate I’m in a minority on this list, but I can assure you
that I’m in the majority when it comes to the rest of humanity. :slight_smile:

I’ll go through what is out there and see if there is enough there to
chew off what I need (including Josh’s plugin) but I would suggest
that this is addressed in some reasonable way before 1.0… I haven’t
actually looked at it for work projects in a couple of months because
of this, but it looks like things have moved on a little. Let’s see
if it’s enough…


Paul R. - http://iconoplex.com
“Cogito, ergo sum.” – Descartes


#20

On Nov 12, 2005, at 9:39 AM, Paul R. wrote:

realise that without i18n Rails is for many of us, in essence, just
to chew off what I need (including Josh’s plugin) but I would
suggest that this is addressed in some reasonable way before 1.0…
I haven’t actually looked at it for work projects in a couple of
months because of this, but it looks like things have moved on a
little. Let’s see if it’s enough…

This really fascinates me. I can completely understand that you may
need i18n for your apps, and without i18n support, you can’t get your
work done. But why does i18n need to be in the core? (I’m not saying
it shouldn’t be, just wondering why it must be.)

The assumption, it seems, is that if something is in the core, it
will be just what you need. This is definitely not going to be the
case for everyone–as has been pointed out repeatedly, i18n has many
application-specific needs, and just because there may someday be
an implementation of i18n in core, that does not imply that it may
be the implementation you need. I see the proliferation of 3rd
party i18n efforts as a good thing, in many ways.

May I politely suggest that people stop complaining about the lack
of i18n in Rails, and please do something about it. Use an existing
solution. Join an existing effort to build something else. Or even
build something else yourself. Some members of the core team have put
forward i18n solutions that work for them. Other rails users have
proposed several other solutions, either complete or in-progress. If
they don’t work for you, put together something that does. Once we
have a few really good solutions that have been tested in the field,
we can start to decide what kind of solution ought to reside in core,
if any. (The key here is “tested in the field.”)

And before anyone points the finger at the core team and declares
that it is our responsibility to solve your problems, please
understand that the core team believes firmly in the opinionated and
pragmatic stance of “don’t write it if you don’t need it.” Virtually
all of Rails has been developed along these lines. I have never
needed to write an i18n application, so I am unsuited for putting
together anything along those lines. Jeremy and Thomas have both
needed (and written) such solutions, but they don’t please everyone.
We (the core team) have done as much as we’re going to at this point,
I think. The ball is in your court now (where “you” refers to “anyone
needing an i18n solution”.)

Yah, it’s an awkward time to be exploring rails if you need an i18n
solution RIGHT NOW. If you’re in that boat and you absolutely cannot
live with Thomas’ minimal solution, or with any of the other
solutions that are out there, and you simply cannot take the time to
build your own, then you probably ought to look into another
framework for now. But please know that there are many bright people
working on this problem, even if the core team itself isn’t
dedicating their R&D efforts to it.

Anyway, I’m done rambling.

  • Jamis