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 mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
On 10-nov-2005, at 6:52, Peter Michaux 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... -- Julian "Julik" Tarkhanov
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Nov 10, 2005, at 1:16 PM, Julian ''Julik'' Tarkhanov wrote:> On 10-nov-2005, at 6:52, Peter Michaux wrote: >> 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".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-----
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
joshmh-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org 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?
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 Ravet
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Nov 10, 2005, at 2:06 PM, Alain Ravet 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-----
On 11/10/05, Jeremy Kemper <jeremy-w7CzD/W5Ocjk1uMJSBkQmQ@public.gmane.org> 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 _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
On 11/10/05, Alain Ravet <arav2132-6SW1mVBvVAbXsMajfR9tMA@public.gmane.org> 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. _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
On 11/10/05, Jeremy Kemper <jeremy-w7CzD/W5Ocjk1uMJSBkQmQ@public.gmane.org> 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? _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
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! On 11/10/05, Peter Michaux <petermichaux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> On 11/10/05, Jeremy Kemper <jeremy-w7CzD/W5Ocjk1uMJSBkQmQ@public.gmane.org> 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? > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails > > >
Hi Josha, Could you please send me the svn url. Thanks, Peter On 11/10/05, Joshua Harvey <jmharvey.9956003-opCBI309nnGakBO8gow8eQ@public.gmane.org> wrote:> > 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 <http://product.name> -> "Albondigas" > > Locale.set("en_US") > product = Product.find 1 > product.name <http://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 joshmh-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org 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? > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >_______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
Hi Josha, Could yoy please send me the svn url? Thank you and have a nice day Alejandro> On 11/10/05, Joshua Harvey <jmharvey.9956003-opCBI309nnGakBO8gow8eQ@public.gmane.org> wrote: > > > > 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 <http://product.name> -> "Albondigas" > > > > Locale.set("en_US") > > product = Product.find 1 > > product.name <http://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 joshmh-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org 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? > > _______________________________________________ > > Rails mailing list > > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > > http://lists.rubyonrails.org/mailman/listinfo/rails-- Alex alex-5WIk9p9x9W7MywiVi6ypYg@public.gmane.org Sure eating yogurt will improve your sex life. People know that if you''ll eat that stuff, you''ll eat anything.
David Heinemeier Hansson
2005-Nov-11 13:11 UTC
Re: Re: Rails core going multiligual...ever?
> > 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 Hansson 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
Jeremy Kemper 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 ;) SO, Joshua Harvey, what is your take on that? Sascha Ebacdh
David Heinemeier Hansson 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 ;) Good support for i18n before 2.0 would be just great. Sascha Ebach
I agree about authentication, every different applications have different authentication needs. Especially since most of my apps are internal company apps and are *supposed* to support IE passthrough authentication with NTLM and Active Directory (Microsoft environment, sadly), I have to use a very different and weird authentication scheme that I''ll detail in another post when I have time to write it up. David> -----Original Message----- > From: rails-bounces-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org [mailto:rails- > bounces-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org] On Behalf Of David Heinemeier Hansson > Sent: Friday, November 11, 2005 8:11 AM > To: rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > Subject: Re: [Rails] Re: Rails core going multiligual...ever? > > > > 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 Hansson > 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 > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails=============================================================================CONFIDENTIALITY NOTICE: The information in this electronic message (including any attachments) is confidential and may be privileged or proprietary. If you are not the intended recipient, any dissemination, disclosure, copying, downloading, or other use of the information is prohibited and unauthorized, and may be unlawful, regardless of address or routing. If you are not the intended recipient, please inform the sender immediately and permanently delete and destroy the original and any copies of this message, including any attachments. ==============================================================================
On 11/11/05, David Heinemeier Hansson <david.heinemeier-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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? _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
David Heinemeier Hansson
2005-Nov-11 16:35 UTC
Re: Re: Rails core going multiligual...ever?
> <david.heinemeier-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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(TM) 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 Hansson 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
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 Sascha wrote:> 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 ;) > > SO, Joshua Harvey, what is your take on that? > > Sascha Ebach
> > 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 : - date formats - currency formats - number separators - ... (in both object to display conversion and input to object conversion ?) Lack of strong i18n support is pretty much a blocker to me so far... I really hope it will be addressed. [1] http://msdn.microsoft.com/msdnmag/issues/05/11/Membership/default.aspx Thibaut -- [blog] http://www.dotnetguru2.org/tbarrere _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
Julian ''Julik'' Tarkhanov
2005-Nov-12 00:30 UTC
Re: Re: Rails core going multiligual...ever?
On 11-nov-2005, at 17:35, David Heinemeier Hansson wrote:>> <david.heinemeier-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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(TM) 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. -- Julian "Julik" Tarkhanov
On 10-nov-2005, at 22:34, Joshua Harvey wrote:> > It also comes with a fairly complete table of languages. > Josh HarveyPlease count me in -- Julian "Julik" Tarkhanov
Hello all, (Sorry not sure if this was sent or not - sent from the wrong email address) I''m having a hell of a time getting Rails running under Apache for Windows. I''ve created a rails app- myapp - and run it under webrick and it works fine. I''ve followed the instructions on http://wiki.rubyonrails.com/rails/pages/Fast+CGI+and+Apache2+for+Windows+XP and I simply can''t get it working at all. Does anyone have any pointers to alternative setup instructions or have any suggestions? Basically it works to the point of: "Now open a browser and type in ”\YourRailsAppName” you should load the default Welcome to Rails page with blazing \FastCGI speeds." but if i was to do \MyApp\friends\view - for example, it can''t find the file which leads me to believe that the rails side of things is not working and it was simply loading the default welcome page as an ordinary html page. I''m going absolutely nuts over this.. any help would really really be appreciated! Thanks, Alastair
Julian, A lot of plugins will rely on overriding Rails behavior. If it breaks, we fix it, or it gets swallowed into core. Another option would be to make the overrides configurable, as are the unicode normalization routines currently (depending on whether the gem is installed). Joshua Sierles On 11/12/05, Julian ''Julik'' Tarkhanov <listbox-RY+snkucC20@public.gmane.org> wrote:> > On 11-nov-2005, at 17:35, David Heinemeier Hansson wrote: > > >> <david.heinemeier-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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(TM) 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. > > > -- > Julian "Julik" Tarkhanov > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
On 11 Nov 2005, at 13:11, David Heinemeier Hansson 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. :-) 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 Robinson - http://iconoplex.com "Cogito, ergo sum." -- Descartes
On Nov 12, 2005, at 9:39 AM, Paul Robinson wrote:> On 11 Nov 2005, at 13:11, David Heinemeier Hansson 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. :-) > > 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...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
On 12 Nov 2005, at 17:09, Jamis Buck wrote:> 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.)I work on projects that are cross-EU and even within the UK several of the big projects that I am lining up now have Welsh audiences. If I haven''t got a clear strategy to handle multi-lingual work within a particular framework, for those projects, that framework can''t go near it. This isn''t preference: on some projects I work on it is law. I can, in theory, go to prison or have to repay a multi-million budget if I ship code that isn''t multi-lingual-friendly. Plus, I have a hard time thinking of a web application that would need to be mono-lingual these days. I know everybody thinks English is the lingua franca of the web, but in the same way you wouldn''t dare ship a web app that is not time-zone aware, I can''t think how anybody could think multi-lingualism isn''t a critical capability of any code that ships these days. But that''s me.> 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.Sure, lots of third party solutions is OK, and I''ve been looking at those today - as I pointed out in my initial e-mail, I have mailed Josh to send me his SVN URL so I can see if that hits the spot. What I''m saying I suppose is that without i18n in there, or at least a clear set of third-party solutions (which atm, there isn''t a clear path for this set out, not that I can see anyway) there are many, many, many projects for which Rails just couldn''t be considered. That''s not a bad thing or a good thing: it''s just a fact. I don''t care if it''s in core of it''s in a plugin. I just want it to exist and for the solution to the problem to be well understood. For me, it makes sense for i18n to be in core, but I''m just one of the 5.7 billion people on the planet that doesn''t live in the USA. :-)> 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.I''ve already explained that whilst I haven''t looked in a few months because I''ve been busy on other projects, I''ve started looking at this again. I don''t have the resources to throw at this right now, but I''m not saying "do this for me", I''m saying "this needs to be thought about, otherwise people might not take the framework seriously and that would be dumb", that''s all.> 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.")Yup, understood. I think for me the key is to move everything - error messages, language in template code, everything - out into an industry-standard i18n format.> 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".)I think you''re confusing me with somebody going around apportioning blame. I''m not. I''m telling you that for Rails to truly be taken as seriously as some of the Java (or even Python) frameworks out there the core team should consider thinking about i18n and working out a way of being able to make it as easy as the rest of Rails, perhaps based on an existing solution, and that if I were in your position I wouldn''t ship 1.0 until it had been thought about. Shipping 1.0 isn''t a job I''ve signed up to, so my opinion counts for nothing. :-) However, what strikes me as strange about your response is that you appear to be suggesting we should just shut up about it. All I was doing was adding to the discussion, and your response has a hint of hostility about it. Perhaps I''m reading it wrong, but it doesn''t seem like a response that is about opening up the debate. RoR aint a democracy, sure, but I find it odd that the first response to my first mail to the list is basically a long way of telling me to shut up... if I''ve misread you, my apologies in advance. Anyway, I shall go and dig through the i18n solutions already out there and see what comes of it... -- Paul Robinson - http://iconoplex.com "Cogito, ergo sum." -- Descartes
Jamis, I think part of the problem is documentation. If I want i18n in my Rails application I have options * integrate i18n in my app - not easily portable or updateable * write an plugin - where is the documentation/HowTos/tutorials about writing plugins and how they link to the core? (I don''t mean that as a demand. It is just a question. I know plugins are new.) * write an engine - recently discouraged approach, complicated. In a way, discouraging is as good as forbiding or might have that affect when people genuinely want to do things "the rails way" or "David''s way". So what do I do? I say "Hey, this is an issue that 6 billion people can benefit from solving well. Perhaps this is a core issue." I definitely take your point that if the core developers do not need i18n then they should not develop this aspect of Rails. But pehaps the core devs will be open to cooperative discussions identifying every topic of i18n that must be addressed in a solution. And then discussing ideas for how to start moving the core towards i18n in a piecewise way. I''m not looking for the core to do the work. But some guidence on implementing a solution to this important issue would be very helpful. Peter _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
On Nov 12, 2005, at 12:08 PM, Peter Michaux wrote:> Jamis, > > I think part of the problem is documentation. If I want i18n in my > Rails application I have options > > * integrate i18n in my app - not easily portable or updateable > * write an plugin - where is the documentation/HowTos/tutorials > about writing plugins and how they link to the core? (I don''t mean > that as a demand. It is just a question. I know plugins are new.)You''re dead on--we need better docs here. And there will be some.> I definitely take your point that if the core developers do not > need i18n then they should not develop this aspect of Rails. But > pehaps the core devs will be open to cooperative discussions > identifying every topic of i18n that must be addressed in a > solution. And then discussing ideas for how to start moving the > core towards i18n in a piecewise way.I strongly advise against talking this thing to death. Yes, discussion is helpful, and often necessary, but don''t let discussion take the place of experimentation. (FWIW, there is a thread currently on the rails-core mailing list about i18n, and anyone that has a stake in i18n is encouraged to follow, if not participate in, that thread.) For many years I labored under the delusion that it was possible to specify something completely, up front, simply by thinking and talking about it. I''ve since been disabused of that notion. As Truly Scrumptious said to Caractacus Potts in Chitty-Chitty-Bang-Bang, "It''s a beautiful dream, but I don''t see how it''s going to help..." Sure, you want to have some idea of what you need to implement, but that can be as simple as a few HTML mockups of a real application ("real" is key) demonstrating where and how internationalized text ought to be used. In my experience, that''s as much as you need, up- front. From there, development is an iterative/evolutionary process that builds on each previous cycle. It''s called "Getting Real" [1]. - Jamis [1] http://getreal.37signals.com
+-Le 12/11/2005 10:09 -0700, Jamis Buck a dit :
| 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.)
I totally agree with you, I feel that it does not need to be in core, I
have a framework working pretty nicely here, working with gettext::mo just
to store things.
It''s composed of an RR/lang/extract.rb <http://p.mat.cc/C> which
gets the
hell out of the app file, a RR/lang/Makefile <http://p.mat.cc/A> which
automates the updating task, a RR/lib/i18n.rb <http://p.mat.cc/D> which is
the whole framework, a RR/config/environments/i18n_env.rb
<http://p.mat.cc/E> which sets defaults, I have :
require ''environments/i18n_env''
require ''i18n''
I18N::load_localized_strings
in my RR/config/environment.rb
and to finish, an "include I18N" in my
RR/app/helpers/application_helper.rb
and RR/app/controllers/application.rb
whenever I need some i18n string, I just say :
l(:levels)
or
l(''Error %s : %s'', e.class, e.to_str)
when I have to add some language, I just touch lang/xx.po and run make in
the lang directory, it''ll fill it with empty strings and it''ll
rock.
(maybe I will be punished with the task to put that in the rails wiki)
--
Mathieu Arnold
On 11/12/05, Jamis Buck <jamis-uHoyYlH2B+GakBO8gow8eQ@public.gmane.org> wrote:> I strongly advise against talking this thing to death. Yes, > discussion is helpful, and often necessary, but don''t let discussion > take the place of experimentation.From there, development is an iterative/evolutionary process> that builds on each previous cycle.I agree! This is exactly why I asked if the core devs are open allowing i18n solutions to creep into the core over time. The problem being that if I come up with a great solution to i18n that requires the core to keep track of a locale or culture or something similar, but the core devs won''t hear anything of it, then was my work was in vain? I found that the symphony framework has already imbraced some i18n into the core. That at least indicates some other frameworks do think i18n is a core issue that needs to be incorporated in today''s web development world. http://www.symfony-project.com/content/book/page/i18n.html Some of these ideas are really great. - Peter _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
On 12 Nov 2005, at 19:45, Mathieu Arnold wrote:> (maybe I will be punished with the task to put that in the rails wiki)Yes, that might be one work-around. It doesn''t seem very Rails-ish, but it''s a solution that will work well for most cases. It just makes development a pain in the proverbial which kind of negates the point of using Rails. I think what we need for it to be a Rails solution is that Rails somehow just "looks after it" for you - convention over configuration, etc. which is why I figured it was a core issue. I appear to be in a minority though, so I think I''ll end up aping your solution. If you don''t whack it into the wiki, I''m sure I will in a day or two when I''ve played with it some more. -- Paul Robinson - http://iconoplex.com "Cogito, ergo sum." -- Descartes
On 12 Nov 2005, at 20:19, Peter Michaux wrote:> I found that the symphony framework has already imbraced some i18n > into the core. That at least indicates some other frameworks do > think i18n is a core issue that needs to be incorporated in today''s > web development world. > > http://www.symfony-project.com/content/book/page/i18n.html > > Some of these ideas are really great.What on the symfony page? I''d prefer ''ugly'' over ''great'' :-), but yes, the principles are interesting. Very interesting, but I think it can be made a little more elegant if it is deserving of the title of going into Rails... One tactic might be to put something into rake to parse the templates in the views directory to find strings and create .fr.html and .de.html and so on based on the text strings found. Another tactic might be to figure a way of separating out the content of a view in a text sense from the layout of a view, but in a way that makes sense in a Rails-style. I agree this is a big area to bite off and chew. We might need to start collecting ideas on a wiki, although today I''ve seen three or four approaches that all look like they''re half-reasonable, but not in a way I would advocate going into the core of Rails because there would be too much lifting going on for everybody else. That''s the main reason why it would be nice if core said ''no way chaps, keep it separate'' in which case we already have a bunch of solutions mostly worked out. -- Paul Robinson - http://iconoplex.com "Cogito, ergo sum." -- Descartes _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
+-Le 12/11/2005 20:23 +0000, Paul Robinson a dit : | On 12 Nov 2005, at 19:45, Mathieu Arnold wrote: | |> (maybe I will be punished with the task to put that in the rails wiki) | | Yes, that might be one work-around. It doesn''t seem very Rails-ish, but | it''s a solution that will work well for most cases. It just makes | development a pain in the proverbial which kind of negates the point of | using Rails. Well, I don''t find it to be particularely a pita, but I''m used to it :-) | I think what we need for it to be a Rails solution is that Rails somehow | just "looks after it" for you - convention over configuration, etc. | which is why I figured it was a core issue. I appear to be in a minority | though, so I think I''ll end up aping your solution. If you don''t whack | it into the wiki, I''m sure I will in a day or two when I''ve played with | it some more. Well, in i18n, you have to extract what has to be translated one way or the other and merge it with what''s already translated, and that''s a pita :-) You also have to have it translated one way or the other. I used po/mo files because there is already nice and powerful utilities to deal with them. (and I used a Makefile and not a Rakefile because it''s something ported from a perl/mason app). -- Mathieu Arnold
Did you modify the .htaccess to use a RewriteBase?
From .htaccess:
RewriteBase /retainit
From httpd.conf:
Alias /retainit "C:/rails/retainit/public/"
<Directory "C:/rails/retainit/public">
AddHandler fastcgi-script .fcgi
Options +ExecCGI
AllowOverride all
Allow from all
Order allow,deny
</Directory>
So basically you set an Alias in your httpd.conf and a RewriteBase in
the .htaccess. Below is my full .htaccess file. The instructions on
the site should work. More info on your exact error message and what
works and what doesn''t would be helpful.
Charles
# General Apache options
AddHandler fastcgi-script .fcgi
AddHandler cgi-script .cgi
Options +FollowSymLinks +ExecCGI
# If you don''t want Rails to look in certain directories,
# use the following rewrite rules so that Apache won''t rewrite certain
requests
#
# Example:
# RewriteCond %{REQUEST_URI} ^/notrails.*
# RewriteRule .* - [L]
# Redirect all requests not available on the filesystem to Rails
# By default the cgi dispatcher is used which is very slow
#
# For better performance replace the dispatcher with the fastcgi one
#
# Example:
# RewriteRule ^(.*)$ dispatch.fcgi [QSA,L]
RewriteEngine On
# If your Rails application is accessed via an Alias directive,
# then you MUST also set the RewriteBase in this htaccess file.
#
# Example:
# Alias /myrailsapp /path/to/myrailsapp/public
# RewriteBase /myrailsapp
RewriteBase /retainit
RewriteRule ^$ index.html [QSA]
RewriteRule ^([^.]+)$ $1.html [QSA]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ dispatch.fcgi [QSA,L]
# In case Rails experiences terminal errors
# Instead of displaying this message you can supply a file here which
will be rendered instead
#
# Example:
# ErrorDocument 500 /500.html
ErrorDocument 500 "<h2>Application error</h2>Rails ap
Alastair Moore wrote:
> Hello all,
>
> (Sorry not sure if this was sent or not - sent from the wrong email
> address)
>
> I''m having a hell of a time getting Rails running under Apache for
> Windows. I''ve created a rails app- myapp - and run it under
webrick
> and it works fine. I''ve followed the instructions on
>
> http://wiki.rubyonrails.com/rails/pages/Fast+CGI+and+Apache2+for+Windows+XP
>
>
> and I simply can''t get it working at all. Does anyone have any
> pointers to alternative setup instructions or have any suggestions?
> Basically it works to the point of:
>
> "Now open a browser and type in ”\YourRailsAppName”
>
> you should load the default Welcome to Rails page with blazing
> \FastCGI speeds."
>
> but if i was to do \MyApp\friends\view - for example, it can''t
find
> the file which leads me to believe that the rails side of things is
> not working and it was simply loading the default welcome page as an
> ordinary html page.
>
> I''m going absolutely nuts over this.. any help would really really
be
> appreciated!
>
> Thanks,
>
> Alastair
>
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
>
>
El Sábado 12 Noviembre 2005 20:08, Peter Michaux escribió:> Jamis, > > I think part of the problem is documentation. If I want i18n in my Rails > application I have options > > * integrate i18n in my app - not easily portable or updateable > * write an plugin - where is the documentation/HowTos/tutorials about > writing plugins and how they link to the core? (I don''t mean that as a > demand. It is just a question. I know plugins are new.) > * write an engine - recently discouraged approach, complicated. In a way, > discouraging is as good as forbiding or might have that affect when people > genuinely want to do things "the rails way" or "David''s way". > > So what do I do? I say "Hey, this is an issue that 6 billion people can > benefit from solving well. Perhaps this is a core issue." > > I definitely take your point that if the core developers do not need i18n > then they should not develop this aspect of Rails. But pehaps the core devs > will be open to cooperative discussions identifying every topic of i18n > that must be addressed in a solution. And then discussing ideas for how to > start moving the core towards i18n in a piecewise way.Well, I posted a mail with subject "[RFC] Multi-language rails" almost 1 month ago and got no comments. I took some notes at http://wiki.rubyonrails.com/rails/pages/RailsLocalization and I''m planning to do some more work when I get some more free time :)> I''m not looking for the core to do the work. But some guidence on > implementing a solution to this important issue would be very helpful. > > Peter-- Jorge Bernal <jbernal-OqA2i3GDl8k@public.gmane.org> Warp Networks S.L. http://www.warp.es/ [EN] http://koke.amedias.org/ [ES] http://www.amedias.org/koke
On 11/12/05, Peter Michaux <petermichaux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> * write an engine - recently discouraged approach, complicated. In a way, > discouraging is as good as forbiding or might have that affect when people > genuinely want to do things "the rails way" or "David''s way".Incidentally, an engine really wouldn''t be a suitable way of doing i18n - engines are (or should be) focused and relatively self-contained. "Vertical application slices" is a phrase I throw about sometimes. I18n is far more "horizontal" (i.e. across the whole application like a layer of peanut butter). Engines (and other focussed plugins/components) might want to support i18n, but not provide it. That''s the job of something *far* more application-wide (or, as it seems to be moving towards, in the core itself). - james
There''s been a lot of talk about login systems and components/engines in the last few weeks, so I though I''d bring up a related topic: single sign-on. David Heinemeier Hansson 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.While I don''t want rails to contain a ton of authentication code, I would like it to provide a standard mechanism or convention that allows different components/engines/applications to share their userbase. It happens all the time: you build a website out of various public packages (e.g. blog, cms and forum) and then you would like them to use the same login system so your users are not annoyed when moving from one part of the site to the other. I''m not exactly sure how to do that while staying clearly on the infrastructure side, but I would like something really simple and lightweight along the lines of: | class WeblogController < ActionController::Base | before_filter :authenticate | def authenticate | @user = single_sign_on_authentication(WeblogUser) With single_sign_on_authentication taking care of any magic required to tie disparate login systems together. Any thoughts?
This is a bit off topic but... I''ve been thinking a lot about DHH''s recent comments about engines being a sideshow to the Rails main stage[1]. I wonder if Rails is really meant to do what you, others and I are hoping it can do without a mess: single login/multiple apps. I don''t know for sure and could easily be wrong but I think DHH is in a position unlike many other Rails web developers. Seems like he has the luxury of being an idealist: all parts of an application are integrated rather than assembled from parts/engines (forum app, cms app, blog app, etc). I think maybe for him T is closer to zero [2] than it is for other developers with less money/time to get a complete application up and maintained for, say, a non-profit organization. A developer may want to make a few such websites a month. But DHH has only a few main apps (Backpack etc) that need maintaining so the work may not seem as time consuming and so Rails stays single app minded. So maybe doing what you want to do is tough in the Rails world since these assembled apps are not what Rails was originally written for. - Peter [1] http://weblog.rubyonrails.com/archives/search?q=evil [2] I don''t know where I read about "T approaches zero" but it meant that by the time the application is specified the application is already finished being written. Certainly we are not there yet but Rails is closer than anything else I''ve tried. _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
Being a long time SSO hater I feel I must weigh in on this. I''ve gone through the SSO wars on the Java/Portal/WebApp side of things and even wrote a few little libraries to handle situations where SSO doesn''t help (search for CryptoWallet). I''ve also used Yale''s CAS system and investigated other systems. My comments below are entirely my own though. For the purpose of this discussion I''ll put things into porn terms since that''s something we can all understand. See, if I use banks people get that glazed look when I ask the hard questions. When I talk about porn though, they listen. You''ll see in a minute. :-) The first thing is that when people say "SSO" they generally mean something entirely different depending on if they are talking about from the user''s perspective or from the implementer''s perspective. From a user''s perspective they mean, "Dude logs in to porntastic.com and can access all 10 of his porn sites without using his other hand to type another password." That''s simple enough.>From an implementer''s perspective it gets ugly. Generally, implementerslook at the problem from the user''s perspective, "Dude logs into any site on the porntastic.com domain and we BLANK his credentials to the other sites." Ok, what is BLANK? Proxied credentials? Passwords from a database? URL redirect bounces? SAML credentials? CAS requests off cookies? How do you keep the passwords synced? What if you don''t own all the sites? What if the other sites don''t want to play? Huh smart guy? Huh?! At some point, BLANK becomes a problem. This is the devilish detail of SSO that nobody mentions in their product literature: a) You''ll have to rewrite *all* of these apps to use foreign and usually ugly ass technology that never runs right on your flavor of OS/Language. b) You''ll need an already consolidated identity management system such as LDAP for all the users. SSO and login silos don''t mix. c) You''ll *have* to evaluate the impact of SSO for each application. There are other people in charge of these applications, and they may not like the idea of letting people log into other apps to get to their''s. It adds one more attack vector to deal with. d) It''s a pain in the ass. No solution could be done with just "single_sign_on_authentication" no matter how slick Rails is. The SSO tech out there just isn''t that easy to use, and if it is it''s probably not secure. e) Beware of people who try to tell you it''s easy. They are liars trying to sell you something or people who just don''t understand the problem. You are basically allowing one password to access all your applications. That''s damn scary. If you own all the sites and have total control over the authentication then you have a hope of doing it. Never mind that you''ll have to retrofit a completely foreign authentication system onto all of these (probably) legacy applications. If you''re in this situation, then check Yale''s CAS and look at OctetString''s Virtual Directory stuff (just bought by Oracle). [Disclaimer: I know someone who works there, but it is a good product.] If you don''t own the sites, then there''s probably no way you can do this, and I''ll use my porn punchline to illustrate the reason why. Imagine that porntastic.com has 10 sites on SSO because they own all the sites. Now they want to offer a partnership with getsome.com so that people can head on over to getsome.com after using a porntastic.com site. Here''s why this is stupid: 1) getsome.com now has to trust you to authenticate users to its site. If the deal is bidirectional (that''s DIRECTIONAL dude, read it right) then you have to trust getsome.com. 2) The owners of getsome.com now get to see your users yanking habits. Hopefully your users don''t find out. 3) If the users do find out, you have to invalidate them in two locations at the same time. 4) You don''t control the getsome.com network, so how do you know they aren''t harvesting the passwords? Yes, this is really easy with some simple web page changes and pretty hard for you to detect. In the end, this never happens unless one company buys the other, and even then it''s usually too much of a pain to do it. It''s just too risky to trust another application to not have a security hole. What this finally comes down to is there''s various strategies for SSO which makes it much more complex and way outside the realm of Rails. DHH is right, it''s not Rails'' job, it''s your job because every SSO initiative is just like porn: it''s private and it''s personal. And that''s just my 0.02. If you''re thinking of doing this, then check out CAS and kick the ruby-ldap guys in the ass so that there''s a win32 build. You''ll never get any attention from serious LDAP vendors if win32 isn''t supported easily as maybe a rubygem (because yes, occaisionally a windows computer has to login using LDAP too). Zed A. Shaw http://www.zedshaw.com/> There''s been a lot of talk about login systems and components/engines in > the last few weeks, so I though I''d bring up a related topic: single > sign-on. > > David Heinemeier Hansson 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. > > While I don''t want rails to contain a ton of authentication code, I > would like it to provide a standard mechanism or convention that allows > different components/engines/applications to share their userbase. It > happens all the time: you build a website out of various public packages > (e.g. blog, cms and forum) and then you would like them to use the same > login system so your users are not annoyed when moving from one part of > the site to the other. > > I''m not exactly sure how to do that while staying clearly on the > infrastructure side, but I would like something really simple and > lightweight along the lines of: > > | class WeblogController < ActionController::Base > | before_filter :authenticate > | def authenticate > | @user = single_sign_on_authentication(WeblogUser) > > With single_sign_on_authentication taking care of any magic required to > tie disparate login systems together. > > Any thoughts? > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
My .001 . CAS is great (if you have a common auth infrastructure in place already) and you can use it from rails easy. See http:// wiki.case.edu/Central_Authentication_Service#Ruby_. 2F_Ruby_on_Rails . I converted over a site using the login generator to this in a hour or so . Also this seems to be more through https://clearinghouse.ja-sig.org/wiki/display/CAS/Ruby+on +Rails+CAS+Client . On Nov 25, 2005, at 11:36 PM, zedshaw-dd7LMGGEL7NBDgjK7y7TUQ@public.gmane.org wrote:> > And that''s just my 0.02. If you''re thinking of doing this, then > check out > CAS and kick the ruby-ldap guys in the ass so that there''s a win32 > build. > You''ll never get any attention from serious LDAP vendors if win32 > isn''t > supported easily as maybe a rubygem (because yes, occaisionally a > windows > computer has to login using LDAP too). > > Zed A. Shaw > http://www.zedshaw.com/
There were a lot of very good and true points about SSO in that last post but mostly they''re about shared trust between sites. That''s not a vital component of SSO and, frankly, I don''t want to touch it with a forty-foot pole. I usually view authentication as composed of: 1. identification: who are you? Bob / unknown 2. authorization: do you have access? yes / no It may seem like a trivial thing to point out but it''s important because I agree that authorization is *firmly* in the realm of business logic. Whether someone can be granted access or not is something only the application can decide. If the app wants to talk to another system and figure out if the user is trusted, that''s fine, but it doesn''t have anything to do with the infrastructure. As for identification, it''s a trivial thing to implement so it''s usually bundled together with the authorization. But as it was so eloquently pointed out by Zed, trying to retrofit SSO into an existing app is not exactly funny. That''s why it has to be part of the infrastructure right from the start. rails is all about convention over configuration, right? If there was a simple convention for authentication, then anyone could use that as a basis for SSO later on. Unless you want a super-powerful SSO solution that does everything and the kitchen sink, it *is* as simple as "single_sign_on_authentication". Let''s say that we have something along the lines of: | class ActionController::Base | def authenticate(user_class, username, password) | session[:rails_user] = user_class.authenticate(username, password) | end | def authenticated_user | session[:rails_user] | end This is beyond simplistic; it''s a mere wrapper for the real method doing the work. But a similar approach built into the infrastructure would allow an SSO plugin to come in, override those standard methods, and provide SSO that is *gasp* not a pain in the ass! My whole point is that if rails doesn''t leave the door unlocked for SSO, no one can open it. dd zedshaw-dd7LMGGEL7NBDgjK7y7TUQ@public.gmane.org wrote:> Being a long time SSO hater I feel I must weigh in on this. I''ve gone > through the SSO wars on the Java/Portal/WebApp side of things and even > wrote a few little libraries to handle situations where SSO doesn''t help > (search for CryptoWallet). I''ve also used Yale''s CAS system and > investigated other systems. My comments below are entirely my own though. > > For the purpose of this discussion I''ll put things into porn terms since > that''s something we can all understand. See, if I use banks people get > that glazed look when I ask the hard questions. When I talk about porn > though, they listen. You''ll see in a minute. :-) > > The first thing is that when people say "SSO" they generally mean > something entirely different depending on if they are talking about from > the user''s perspective or from the implementer''s perspective. From a > user''s perspective they mean, "Dude logs in to porntastic.com and can > access all 10 of his porn sites without using his other hand to type > another password." That''s simple enough. > >>From an implementer''s perspective it gets ugly. Generally, implementers > look at the problem from the user''s perspective, "Dude logs into any site > on the porntastic.com domain and we BLANK his credentials to the other > sites." Ok, what is BLANK? Proxied credentials? Passwords from a > database? URL redirect bounces? SAML credentials? CAS requests off > cookies? How do you keep the passwords synced? What if you don''t own all > the sites? What if the other sites don''t want to play? Huh smart guy? > Huh?! > > At some point, BLANK becomes a problem. This is the devilish detail of > SSO that nobody mentions in their product literature: > > a) You''ll have to rewrite *all* of these apps to use foreign and > usually ugly ass technology that never runs right on your flavor of > OS/Language. > b) You''ll need an already consolidated identity management system such > as LDAP for all the users. SSO and login silos don''t mix. > c) You''ll *have* to evaluate the impact of SSO for each application. > There are other people in charge of these applications, and they may not > like the idea of letting people log into other apps to get to their''s. > It adds one more attack vector to deal with. > d) It''s a pain in the ass. No solution could be done with just > "single_sign_on_authentication" no matter how slick Rails is. The SSO > tech out there just isn''t that easy to use, and if it is it''s probably > not secure. > e) Beware of people who try to tell you it''s easy. They are liars > trying to sell you something or people who just don''t understand the > problem. You are basically allowing one password to access all your > applications. That''s damn scary. > > If you own all the sites and have total control over the authentication > then you have a hope of doing it. Never mind that you''ll have to retrofit > a completely foreign authentication system onto all of these (probably) > legacy applications. If you''re in this situation, then check Yale''s CAS > and look at OctetString''s Virtual Directory stuff (just bought by Oracle). > [Disclaimer: I know someone who works there, but it is a good product.] > > If you don''t own the sites, then there''s probably no way you can do this, > and I''ll use my porn punchline to illustrate the reason why. > > Imagine that porntastic.com has 10 sites on SSO because they own all the > sites. Now they want to offer a partnership with getsome.com so that > people can head on over to getsome.com after using a porntastic.com site. > Here''s why this is stupid: > > 1) getsome.com now has to trust you to authenticate users to its site. > If the deal is bidirectional (that''s DIRECTIONAL dude, read it right) then > you have to trust getsome.com. > 2) The owners of getsome.com now get to see your users yanking habits. > Hopefully your users don''t find out. > 3) If the users do find out, you have to invalidate them in two locations > at the same time. > 4) You don''t control the getsome.com network, so how do you know they > aren''t harvesting the passwords? Yes, this is really easy with some > simple web page changes and pretty hard for you to detect. > > In the end, this never happens unless one company buys the other, and even > then it''s usually too much of a pain to do it. It''s just too risky to > trust another application to not have a security hole. > > What this finally comes down to is there''s various strategies for SSO > which makes it much more complex and way outside the realm of Rails. DHH > is right, it''s not Rails'' job, it''s your job because every SSO initiative > is just like porn: it''s private and it''s personal. > > And that''s just my 0.02. If you''re thinking of doing this, then check out > CAS and kick the ruby-ldap guys in the ass so that there''s a win32 build. > You''ll never get any attention from serious LDAP vendors if win32 isn''t > supported easily as maybe a rubygem (because yes, occaisionally a windows > computer has to login using LDAP too). > > Zed A. Shaw > http://www.zedshaw.com/
> | class ActionController::Base > | def authenticate(user_class, username, password) > | session[:rails_user] = user_class.authenticate(username, password) > | end > | def authenticated_user > | session[:rails_user] > | end > > This is beyond simplistic; it''s a mere wrapper for the real method doing > the work. But a similar approach built into the infrastructure would > allow an SSO plugin to come in, override those standard methods, and > provide SSO that is *gasp* not a pain in the ass! My whole point is that > if rails doesn''t leave the door unlocked for SSO, no one can open it.If you''ll notice, most of the login generators/plugins/engines derive somehow from xal''s login generator. Therefore, they all (for the most part): store the data (usually the user model which is bad IMO, but anyhow) in session[:user]. use current_user as a comment method for retrieving the logged in user. use login_required as the before filter. authenticate with a User.authenticate method. So, there''s already a convention being used. I don''t see why the framework has ''support'' anything. I''ve been able to use these conventions to implement a crude single-sign on for i2, rforum and typo, three apps with completely different authentication schemes. I didn''t implement any way to move freely among the apps, but I could log in with the same username/password. -- rick http://techno-weenie.net