Hi all, I''m new to Rails and learning from the Agile Web Dev w/Rails book. However, I found it weird that i18n was completely ignored, and searching through the rails site I only found http://wiki.rubyonrails.com/rails/show/Internationalization, which doesn''t explain much, and it seems to be harder than it should be. Since I usually build my apps with i18n from the beginning, I would appreciate it if anyone can shed light on this. Something like Struts'' application resources properties files would be exactly what I''m looking for. Thanks, Abdullah
Abdullah Jibaly wrote:> Hi all, > > I''m new to Rails and learning from the Agile Web Dev w/Rails book. However, I > found it weird that i18n was completely ignored, and searching through the > rails site I only found > http://wiki.rubyonrails.com/rails/show/Internationalization, which doesn''t > explain much, and it seems to be harder than it should be. Since I usually > build my apps with i18n from the beginning, I would appreciate it if anyone can > shed light on this.Try my guide on http://manuals.rubyonrails.com/read/book/16. It should get you started. Good luck. Sascha
I did read through the tutorial, nice work Sascha. Just curious though, are their any plans to integrate i18n funtionality as an inherent implementation in RoR? I have to confess that resource bundling (e.g. Struts, JSF, etc) make i18n support so much easier that having to look at a complete subframework for implementation. Since most of the apps that I build (and with a globalized world) need to be easily i18n supported this is a big deal. Dave On 7/23/05, Sascha Ebach <se-eFwX6J65rk9VioaHkBSlcw02NpfuEekPhC4ANOJQIlc@public.gmane.org> wrote:> > Abdullah Jibaly wrote: > > Hi all, > > > > I''m new to Rails and learning from the Agile Web Dev w/Rails book. > However, I > > found it weird that i18n was completely ignored, and searching through > the > > rails site I only found > > http://wiki.rubyonrails.com/rails/show/Internationalization, which > doesn''t > > explain much, and it seems to be harder than it should be. Since I > usually > > build my apps with i18n from the beginning, I would appreciate it if > anyone can > > shed light on this. > > Try my guide on http://manuals.rubyonrails.com/read/book/16. It should > get you started. > > Good luck. > > Sascha > _______________________________________________ > 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
Thanks! It looks a little complicated considering this is Rails and almost everything else is easy but hopefully it will make sense once I actually try and implement it. Regards, Abdullah --- Sascha Ebach <se-eFwX6J65rk9VioaHkBSlcw02NpfuEekPhC4ANOJQIlc@public.gmane.org> wrote:> Abdullah Jibaly wrote: > > Hi all, > > > > I''m new to Rails and learning from the Agile Web Dev w/Rails book. However, > I > > found it weird that i18n was completely ignored, and searching through the > > rails site I only found > > http://wiki.rubyonrails.com/rails/show/Internationalization, which doesn''t > > explain much, and it seems to be harder than it should be. Since I usually > > build my apps with i18n from the beginning, I would appreciate it if anyone > can > > shed light on this. > > Try my guide on http://manuals.rubyonrails.com/read/book/16. It should > get you started. > > Good luck. > > Sascha > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
Le 05-07-23 à 14:47, David Thompson a écrit :> I did read through the tutorial, nice work Sascha. > > Just curious though, are their any plans to integrate i18n > funtionality as an inherent implementation in RoR? I have to > confess that resource bundling (e.g. Struts, JSF, etc) make i18n > support so much easier that having to look at a complete > subframework for implementation. Since most of the apps that I > build (and with a globalized world) need to be easily i18n > supported this is a big deal.Can anyone (David H?) address Rails'' future plans for i18n? Coming from the Java world also, I''ve found Rails to be a pleasant experience, but IMO, the lack of built-in i18n support is a gaping hole in a framework. Considering today''s flat world, the lack of built-in support for i18n seems to be a rather serious ommission. david geary> > Dave > > On 7/23/05, Sascha Ebach <se-eFwX6J65rk9VioaHkBSlcw02NpfuEekPhC4ANOJQIlc@public.gmane.org> wrote: > Abdullah Jibaly wrote: > > Hi all, > > > > I''m new to Rails and learning from the Agile Web Dev w/Rails > book. However, I > > found it weird that i18n was completely ignored, and searching > through the > > rails site I only found > > http://wiki.rubyonrails.com/rails/show/Internationalization, > which doesn''t > > explain much, and it seems to be harder than it should be. Since > I usually > > build my apps with i18n from the beginning, I would appreciate it > if anyone can > > shed light on this. > > Try my guide on http://manuals.rubyonrails.com/read/book/16 . It > should > get you started. > > Good luck. > > Sascha > _______________________________________________ > 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 >_______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
David Thompson wrote:> I did read through the tutorial, nice work Sascha. > > Just curious though, are their any plans to integrate i18n funtionality > as an inherent implementation in RoR? I have to confess that resource > bundling (e.g. Struts, JSF, etc) make i18n support so much easier that > having to look at a complete subframework for implementation. Since most > of the apps that I build (and with a globalized world) need to be easily > i18n supported this is a big deal.Yeah, we had this discussion already multiple times on this mailing list. I fear this is not going to make it into 1.0. The main reason there is no kind of i18n (rather l10n) support in rails is that 37s doens''t do anything but english apps. (They could at least make Basecamp etc. available in Danish, any other language would mean that they have to scale (humans) because of the support issues, which they don''t want. Of course, they could at least double their revenue by supporting German and French...). I suspect it will make it into Rails at some point in the future, hopefully as a main feature for 1.x. Sascha
> Yeah, we had this discussion already multiple times on this mailing > list. I fear this is not going to make it into 1.0. The main reason > there is no kind of i18n (rather l10n) support in rails is that 37s > doens''t do anything but english apps.One of the reason rails is so nice to work with is that "it was in an app first". You''re right, it won''t make it into 1.0 as noone who contributes to rails has needed to build multi lingual applications yet. If all the people who need this today (you do actually *need* this right ;)) get together, I''m sure they can sketch a strategy/design for it and get a nice 1.x release out. -- Cheers Koz
Le 05-07-24 à 19:05, Michael Koziarski a écrit :>> Yeah, we had this discussion already multiple times on this mailing >> list. I fear this is not going to make it into 1.0. The main reason >> there is no kind of i18n (rather l10n) support in rails is that 37s >> doens''t do anything but english apps. >> > > One of the reason rails is so nice to work with is that "it was in an > app first". You''re right, it won''t make it into 1.0 as noone who > contributes to rails has needed to build multi lingual applications > yet.IMO, if Rails is to have a major impact in the long run, this criteria for adding crucial features like i18n must change. david> If all the people who need this today (you do actually *need* > this right ;)) get together, I''m sure they can sketch a > strategy/design for it and get a nice 1.x release out. > > > > > -- > Cheers > > Koz > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
Random question, and forgive me if this has already been covered. Has anyone thought of creating an i18n generator which would perhaps generate all of the basic gettext (or other) framework, etc.? On 7/25/05, David Geary <sabreware-ihVZJaRskl1bRRN4PJnoQQ@public.gmane.org> wrote:> > Le 05-07-24 à 19:05, Michael Koziarski a écrit : > > >> Yeah, we had this discussion already multiple times on this mailing > >> list. I fear this is not going to make it into 1.0. The main reason > >> there is no kind of i18n (rather l10n) support in rails is that 37s > >> doens''t do anything but english apps. > >> > > > > One of the reason rails is so nice to work with is that "it was in an > > app first". You''re right, it won''t make it into 1.0 as noone who > > contributes to rails has needed to build multi lingual applications > > yet. > > IMO, if Rails is to have a major impact in the long run, this > criteria for adding crucial features like i18n must change. > > > david > > > If all the people who need this today (you do actually *need* > > this right ;)) get together, I''m sure they can sketch a > > strategy/design for it and get a nice 1.x release out. > > > > > > > > > > -- > > Cheers > > > > Koz > > _______________________________________________ > > 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 >_______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
Anyone looked at how Nitro integrates localization? On 7/25/05, David Thompson <dandrew.thompson-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > Random question, and forgive me if this has already been covered. > Has anyone thought of creating an i18n generator which would perhaps > generate all of the basic gettext (or other) framework, etc.? > > On 7/25/05, David Geary <sabreware-ihVZJaRskl1bRRN4PJnoQQ@public.gmane.org> wrote: > > > > Le 05-07-24 à 19:05, Michael Koziarski a écrit : > > > > >> Yeah, we had this discussion already multiple times on this mailing > > >> list. I fear this is not going to make it into 1.0. The main reason > > >> there is no kind of i18n (rather l10n) support in rails is that 37s > > >> doens''t do anything but english apps. > > >> > > > > > > One of the reason rails is so nice to work with is that "it was in an > > > app first". You''re right, it won''t make it into 1.0 as noone who > > > contributes to rails has needed to build multi lingual applications > > > yet. > > > > IMO, if Rails is to have a major impact in the long run, this > > criteria for adding crucial features like i18n must change. > > > > > > david > > > > > If all the people who need this today (you do actually *need* > > > this right ;)) get together, I''m sure they can sketch a > > > strategy/design for it and get a nice 1.x release out. > > > > > > > > > > > > > > > -- > > > Cheers > > > > > > Koz > > > _______________________________________________ > > > 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 > > > > > _______________________________________________ > 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
> IMO, if Rails is to have a major impact in the long run, this > criteria for adding crucial features like i18n must change.The criteria for *adding* crucial features is that somebody builds it, doesn''t matter who. The criteria for having the current commiters build it is that *they* need it. Back in the day David HH didn''t need optimistic locking, and was fine with String interpolation for handling conditions in queries. I needed the locking and didn''t like the queries, so I implemented both. If you can come up with a nice design, I''m sure plenty of us will help you implement it and get it included. -- Cheers Koz
Hi! Since no current contributors have need support for multiple languages, but I do, may I propose following simple solution. And feel free to shoot this idea down. 1) one new (generated) directory in each application: RAILS_ROOT/app/i18n 2) that directory should contain ''properties'' files, like file ''finnish.properties'': # this is a comment Hello, world! = Moi, maailma! Bye, world! = Hyvästi, maailma! 3) in your controller you write: class HelloController < ApplicationController before_filter I18nFilter i18n :fi => "finnish.properties" def hello # or put "@i18n = :fi" resolving here and override filters end end 4) in your views you write: <%= i18n ''Hello, world!'' %> 5) there is no step 5, you are done I''ve attached initial working drafts of following files: internationalization.rb <implementation and dummy filter> hello_controller.rb <sample controller> hello.rhtml <sample view> finnish.properties <sample properties> Currently I can use this using (in config/environment.rb): require ''internationalization'' Features - if no internationalization is configured, original ''key'' text is returned, so you can always use <% i18n ''My label'' %> and it should work just fine without translations - term ''i18n'' is all you have to remember - no tests yet (this is just a probing proposal) - code is ugly and not commented (see previous dash) - works in my computer (so far) Now it is your turn: kill this proposal in every possible way. Jippo On Mon, Jul 25, 2005 at 08:57:01AM -0600, David Geary wrote:> Le 05-07-24 à 19:05, Michael Koziarski a écrit : > >One of the reason rails is so nice to work with is that "it was in an > >app first". You''re right, it won''t make it into 1.0 as noone who > >contributes to rails has needed to build multi lingual applications > >yet. > > IMO, if Rails is to have a major impact in the long run, this > criteria for adding crucial features like i18n must change. > > > david > > >-- > >Cheers > > > >Koz-- __________________________________________________________________ [ Juha Pohjalainen <jmp-X3B1VOXEql0@public.gmane.org> ] [__ http://www.iki.fi/jmp/ _______________ GSM +358 40 7 456 890 __] | "It sounds to me as though you''re waiting for someone to hand you | a silver bullet on a silver platter, and hit you on the head with | a silver hammer to make sure you notice it." | "Anton van Straaten" <anton-4+T8QRhnmeXMohDmgNdYFA@public.gmane.org> _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
Hi Juha, And welcome to the bunch of Finnish Rails users! On 26.7.2005, at 11.13, Juha Pohjalainen wrote:> Hi! > > Since no current contributors have need support for multiple > languages, but I do, may I propose following simple solution. > And feel free to shoot this idea down. >I took a quick look at your approach but didn''t see how it would be inherently different than Sascha''s Gettext-driven implementation [1]. That probably means I missed something important, but could you anyway elaborate how your approach is better/easier than Sascha''s? Cheers, //jarkko [1] http://manuals.rubyonrails.com/read/chapter/82 -- Jarkko Laine http://jlaine.net http://odesign.fi _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
> Since no current contributors have need support for multiple > languages, but I do, may I propose following simple solution. > And feel free to shoot this idea down. > > > I took a quick look at your approach but didn''t see how it would be > inherently different than Sascha''s Gettext-driven implementation [1]. That > probably means I missed something important, but could you anyway elaborate > how your approach is better/easier than Sascha''s?The approach looks like an application of the PhraseBook pattern (already mentionned in this list for an SQL phrasebook. See http://jerry.cs.uiuc.edu/~plop/plop2k/proceedings/Pinchuk/Pinchuk.pdf for informations on the phrasebook pattern) And it does look like the gettext project. However the gettext project introduces dependencies to libiconv (or gnome2-lib if you are on windows, and you have to install one more gem), to Racc (ruby yacc) and to GNU gettext. That makes it all a bit too complicated for my taste. Installing it on windows sounds too difficult. I am all for a pure ruby i18n handling with a single easy-to-package-and-install gem (if it doesn''t come with rails itself). Thus, while in itself this approach is not easier to use, it is easier to deploy.
Quick suggestion : * Use _ (underscore) instead of i18n so the changes in the code to go from gettext to you r package are minimized .. On 7/26/05, Juha Pohjalainen <voidjump-HEOGnkOaz3U@public.gmane.org> wrote:> Hi! > > Since no current contributors have need support for multiple > languages, but I do, may I propose following simple solution. > And feel free to shoot this idea down.Jean
On Tue, Jul 26, 2005 at 11:31:11AM +0300, Jarkko Laine wrote:> > Hi Juha, > > And welcome to the bunch of Finnish Rails users!Thank you, Jarkko! I''ve been lurking around but never posted before. :-)> On 26.7.2005, at 11.13, Juha Pohjalainen wrote: > >Hi! > > > >Since no current contributors have need support for multiple > >languages, but I do, may I propose following simple solution. > >And feel free to shoot this idea down. > > > > I took a quick look at your approach but didn''t see how it would be > inherently different than Sascha''s Gettext-driven implementation [1].Nope, it is not inherently different; it solves same problem.> That probably means I missed something important, but could you > anyway elaborate how your approach is better/easier than Sascha''s?If it is added into Rails core, then there would be no need for external library, in this case ''gettext'' (notes: I was aware of gettext approach; I have not tried it; maybe my mistake is that I thought gettext is external to Ruby and Rails [since that manual says I have to install some GetText package]). And two things that I think are different: - 1: not so many directories - 2: each controller can have its own i18n mappings (this can be seen as a good thing [my view] or bad thing; at least code generators could generate their translation files freely) But as I wrote above, it is just a simple solution and only continuation to discussion about what kind of support for different languages are added into core Rails. One more option is not a bad thing - I hope; at least there are more items to reject. :-) +Jippo> Cheers, > //jarkko > > [1] http://manuals.rubyonrails.com/read/chapter/82 > > -- > Jarkko Laine > http://jlaine.net > http://odesign.fi-- __________________________________________________________________ [ Juha Pohjalainen <jmp-X3B1VOXEql0@public.gmane.org> ] [__ http://www.iki.fi/jmp/ _______________ GSM +358 40 7 456 890 __] | "It sounds to me as though you''re waiting for someone to hand you | a silver bullet on a silver platter, and hit you on the head with | a silver hammer to make sure you notice it." | "Anton van Straaten" <anton-4+T8QRhnmeXMohDmgNdYFA@public.gmane.org>
On 7/26/05, Juha Pohjalainen <voidjump-HEOGnkOaz3U@public.gmane.org> wrote:> Hi! > > Since no current contributors have need support for multiple > languages, but I do, may I propose following simple solution. > And feel free to shoot this idea down. > > 1) one new (generated) directory in each application: > RAILS_ROOT/app/i18n > 2) that directory should contain ''properties'' files, like > file ''finnish.properties'': > # this is a comment > Hello, world! = Moi, maailma! > Bye, world! = Hyvästi, maailma!What''s the encoding of these files? Are you being careful when parsing it? Java''s .properties system requires iso-8859-1 for a reason, some utf-8 sequences look like \n to an ascii only parser.> 3) in your controller you write: > class HelloController < ApplicationController > before_filter I18nFilter > > i18n :fi => "finnish.properties" > > def hello > # or put "@i18n = :fi" resolving here and override filters > end > endi18n? not sure of the name for the helper, translate or something else perhaps?> 4) in your views you write: > <%= i18n ''Hello, world!'' %>I''d second the suggestion to use _(), it''s how gettext works so those of us who have suffered with it will feel more at home.> Now it is your turn: kill this proposal in every possible way.Congratulations, and thanks, even if this approach isn''t added, at least we''ll start talking about it ;) -- Cheers Koz
On Tue, Jul 26, 2005 at 10:30:41PM +1200, Michael Koziarski wrote:> On 7/26/05, Juha Pohjalainen <voidjump-HEOGnkOaz3U@public.gmane.org> wrote: > > 2) that directory should contain ''properties'' files, like > > file ''finnish.properties'': > > # this is a comment > > Hello, world! = Moi, maailma! > > Bye, world! = Hyvästi, maailma! > > What''s the encoding of these files? Are you being careful when > parsing it? Java''s .properties system requires iso-8859-1 for a > reason, some utf-8 sequences look like \n to an ascii only parser.Thank you, Michael! And no, I''m not being careful while reading/parsing; question - how can I know from file content in generig way, which encoding is used in that file? Except for convention?> > 3) in your controller you write: > > class HelloController < ApplicationController > > before_filter I18nFilter > > > > i18n :fi => "finnish.properties" > > > > def hello > > # or put "@i18n = :fi" resolving here and override filters > > end > > end > > i18n? not sure of the name for the helper, translate or something > else perhaps?I was trying to be consistent (using i18n everywhere) but that is easily changed to ''translate'' or something else. Any other good name candidates?> > 4) in your views you write: > > <%= i18n ''Hello, world!'' %> > > I''d second the suggestion to use _(), it''s how gettext works so those > of us who have suffered with it will feel more at home.Ok. I was trying to be explicit in this one. And consistent also. But for me it is ok (I might be little ''blind'' for such a little character as ''_'' but that is my problem) to use _ in templates if that is what is put in Rails implementation (or is it already there?). And hopefully _ is not reserved for any internal/future Ruby/other use. [Side note: is this starting to look like Perl?]> > Now it is your turn: kill this proposal in every possible way. > > Congratulations, and thanks, even if this approach isn''t added, at > least we''ll start talking about it ;)All I want/need is something inside core Rails that handles multiple languages support easily. If correct and right solution inside core Rails is already ''gettext'', then that is ok for me. +Jippo> -- > Cheers > > Koz
On 26.7.2005, at 14.19, Juha Pohjalainen wrote:> On Tue, Jul 26, 2005 at 10:30:41PM +1200, Michael Koziarski wrote: >>> <%= i18n ''Hello, world!'' %> >>> >> >> I''d second the suggestion to use _(), it''s how gettext works so >> those >> of us who have suffered with it will feel more at home. >> > > Ok. I was trying to be explicit in this one. And consistent also. > But for me it is ok (I might be little ''blind'' for such a little > character as ''_'' but that is my problem) to use _ in templates if > that is what is put in Rails implementation (or is it already there?). > And hopefully _ is not reserved for any internal/future Ruby/other > use. > [Side note: is this starting to look like Perl?]_ is the function name gettext [1] uses for this, so it''s pretty widely used among different languages.>> > > All I want/need is something inside core Rails that handles multiple > languages support easily. If correct and right solution inside core > Rails is already ''gettext'', then that is ok for me.No, it isn''t internal in Rails, unfortunately. It needs quite a lot of different things (gettext, ruby-gettext etc) installed so the deployment is not exactly a whirl. It''s not too hard either and I have done it even on Textdrive, but i18n support built inside Rails would certainly be a plus. //jarkko [1] http://www.gnu.org/software/gettext/gettext.html -- Jarkko Laine http://jlaine.net http://odesign.fi _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
On 7/26/05, Juha Pohjalainen <voidjump-HEOGnkOaz3U@public.gmane.org> wrote: [snip]> > I''d second the suggestion to use _(), it''s how gettext works so those > > of us who have suffered with it will feel more at home. > > Ok. I was trying to be explicit in this one. And consistent also. > But for me it is ok (I might be little ''blind'' for such a little > character as ''_'' but that is my problem) to use _ in templates if > that is what is put in Rails implementation (or is it already there?). > And hopefully _ is not reserved for any internal/future Ruby/other use. > [Side note: is this starting to look like Perl?] >the _() method is only used (usually) by gettext. I think that''s not enough to make ruby a hieroglyphic language. Regards, Rodrigo.
I would recomment making an all-ruby implementation of i18n as close to gettext as possible. Why? Because gettext is widely used (from different programming languages, frameworks and even OS''s). The syntax would be familiar to a lot of people. There are a lot of tools out there to help with the translations, etc. So, you shouldn''t need the extra packages and libraries to get gettext to work, but whatever ruby implementation of i18n is created, it should be modeled after gettext. Meaning the same _() call, the same RAILS_ROOT/locate folder, etc., etc. This way, if at a later time Rails decides to support i18n, and hopefully it decides to use gettext, it will make it that much easier to make the transition. just my $0.02. _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
I don''t *think* I agree with this. It doesn''t seem that any part of Rails is modeled so strictly after other technologies and I don''t think the reasons listed are really good enough to, as someone else said, make Rails a hieroglyphic framework. A lot of the language used in Ruby and in Rails is very meaningful. A method such as _() lacks meaning entirely and breaks from the elegant consistency that is, in my opinion, one of the nicer features of both the language and the framework. You don''t want Rails to end up like the PHP core lib, with inconsistencies and almost arbitrary vocabularies. If gettext were to ever be used -- either linked into the core framework or by "vendor" code -- creating pointers/delegates would be quite simple. I''m not convinced that doing just that -- building adapters to gettext -- isn''t the way to go. I18n is a big deal and if it''s needed, linking in a proven external library is *not* a big deal. Hell, requiring Ruby is more of a challenge at the moment. On Jul 26, 2005, at 9:55 AM, Ramin wrote:> I would recomment making an all-ruby implementation of i18n as > close to gettext as possible. Why? Because gettext is widely used > (from different programming languages, frameworks and even OS''s). > The syntax would be familiar to a lot of people. There are a lot of > tools out there to help with the translations, etc. > > So, you shouldn''t need the extra packages and libraries to get > gettext to work, but whatever ruby implementation of i18n is > created, it should be modeled after gettext. Meaning the same _() > call, the same RAILS_ROOT/locate folder, etc., etc. > > This way, if at a later time Rails decides to support i18n, and > hopefully it decides to use gettext, it will make it that much > easier to make the transition. > > just my $0.02. > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
On Jul 26, 2005, at 8:48 AM, Toby Boudreaux wrote:> I don''t *think* I agree with this. > > It doesn''t seem that any part of Rails is modeled so strictly after > other technologies and I don''t think the reasons listed are really > good enough to, as someone else said, make Rails a hieroglyphic > framework. > > A lot of the language used in Ruby and in Rails is very meaningful. > A method such as _() lacks meaning entirely and breaks from the > elegant consistency that is, in my opinion, one of the nicer > features of both the language and the framework. >+1 We''ve had an ''unobfuscated Ruby code'' contest on our Ruby User Group list, just because we can. I prefer self-documenting, clear, understandable code over saving a few keystrokes any day. Duane Johnson (canadaduane)
all in ruby gettex implementation: http://ri18n.berlios.de/ we could use that! 2005/7/26, Ramin <i8ramin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:> > I would recomment making an all-ruby implementation of i18n as close to > gettext as possible. Why? Because gettext is widely used (from different > programming languages, frameworks and even OS''s). The syntax would be > familiar to a lot of people. There are a lot of tools out there to help with > the translations, etc. > > So, you shouldn''t need the extra packages and libraries to get gettext to > work, but whatever ruby implementation of i18n is created, it should be > modeled after gettext. Meaning the same _() call, the same RAILS_ROOT/locate > folder, etc., etc. > > This way, if at a later time Rails decides to support i18n, and hopefully > it decides to use gettext, it will make it that much easier to make the > transition. > > just my $0.02. > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails > > >-- Giovanni Degani tiefox-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org ICQ 965609 _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
Just for conversation sake and demonstrating the importance of this development.... From David Geary's blog <http://jroller.com/page/dgeary/> (JSF/JAVA god) today... "But of course, Rails is not perfect. For example, Rails suprisingly provides no built-in support for i18n or client-side validation. Yes, you can wrestle with get_text() <http://manuals.rubyonrails.com/read/chapter/82>and use that in conjunction with Rails to localize text, but who wants to endure that pain, not to mention, you've still got other i18n issues, such as unicode, localizing dates and times, etc. Frankly, I'm baffled by Rails' lack of support for i18n. Lack of client-side validation's not that big of a deal—especially now that we can easily use Ajax to validate w/o page refreshes—but lack of i18n support, especially in today's flat world<http://www.amazon.com/exec/obidos/tg/detail/-/0374292884/qid=1122335518/sr=8-1/ref=pd_bbs_sbs_1/104-8350225-3438333?v=glance&s=books&n=507846>, is hard to understand. And it's not like Rails users don't want i18n; I have recently witnessed Rails users drooling over the idea of resource bundles. Imagine." On 7/26/05, Giovanni Degani <tiefox@gmail.com> wrote:> > all in ruby gettex implementation: > http://ri18n.berlios.de/ > > we could use that! > > 2005/7/26, Ramin <i8ramin@gmail.com>: > > > > I would recomment making an all-ruby implementation of i18n as close to > > gettext as possible. Why? Because gettext is widely used (from different > > programming languages, frameworks and even OS's). The syntax would be > > familiar to a lot of people. There are a lot of tools out there to help with > > the translations, etc. > > > > So, you shouldn't need the extra packages and libraries to get gettext > > to work, but whatever ruby implementation of i18n is created, it should be > > modeled after gettext. Meaning the same _() call, the same RAILS_ROOT/locate > > folder, etc., etc. > > > > This way, if at a later time Rails decides to support i18n, and > > hopefully it decides to use gettext, it will make it that much easier to > > make the transition. > > > > just my $0.02. > > > > _______________________________________________ > > Rails mailing list > > Rails@lists.rubyonrails.org > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > > > > > > -- > Giovanni Degani > tiefox@gmail.com > ICQ 965609 > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails > > >-- ~~~~~~~~~~~~~~~~~~~ D'Andrew Thompson http://dathompson.blogspot.com _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
Giovanni Degani wrote:> all in ruby gettex implementation: > http://ri18n.berlios.de/ > > we could use that!+1 Sascha
Ok, following two comments made me think/ask this:
If you would have "anything possible" card in Rails game, what would
make i18n library easier to use? How would you like to use it so that
it would make just right, easy and confortable? What is The Right Way?
Why?
Anyone?
( I have no answer, but I had to ask? Or I have partial wrong answer:
it should be internal to Rails [that easy deployment part]? )
+Jippo
> > That probably means I missed something important, but could you
> > anyway elaborate how your approach is better/easier than
Sascha''s?
>
> Thus, while in itself this approach is not easier to use, it is
> easier to deploy.
> If you would have "anything possible" card in Rails game, what would > make i18n library easier to use? How would you like to use > it so that > it would make just right, easy and confortable? What is The > Right Way? > Why?Don''t know about the "right" way but perhaps looking at the way Plone implements i18m might be useful? I realize Rails and Plone are two completely different beasts, but Plone is known, among other things, for great multi-lingual support. "Internationalization (i18n) For Developers" http://plone.org/documentation/how-to/i18n-for-developers/view?searchter m=i18n
Please excuse my ignorance, as I''ve not yet built an "internationalized" web application. The topic interests me, however, so I would like to ask a few of questions to understand the scope of this undertaking: 1. The basic functionality of so-called i18n seems pretty easy: Replace sentences or paragraphs in one language with those of another language. What issues do we have to face to get this done? 2. It seems like Juha''s quick-n-dirty implementation would do the job--is there something much more complicated lurking behind? 3. And in a related question... it seems the Java camp has implemented some ''advanced i18n'' features. What does that entail? Are we so far behind that it could take months to catch up? 4. How does localization fit in to the picture? Thanks to those who are familiar with this for bringing it up. I want to see Rails become more than just a darling little web app framework--I think it''s going to be *the* platform of choice within two or three years. It seems that by some standards, internationalization will help qualify it as "grown up". Duane Johnson (canadaduane)
On 7/26/05, Sascha Ebach <se-eFwX6J65rk9VioaHkBSlcw02NpfuEekPhC4ANOJQIlc@public.gmane.org> wrote:> Giovanni Degani wrote: > > all in ruby gettex implementation: > > http://ri18n.berlios.de/ > > > > we could use that! > > +1 >actually this also uses gettext and the ruby gettext binding/library jean
On 7/26/05, Jean Helou <jean.helou-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> On 7/26/05, Sascha Ebach <se-eFwX6J65rk9VioaHkBSlcw02NpfuEekPhC4ANOJQIlc@public.gmane.org> wrote: > > Giovanni Degani wrote: > > > all in ruby gettex implementation: > > > http://ri18n.berlios.de/ > > > > > > we could use that! > > > > +1 > > > actually this also uses gettext and the ruby gettext binding/library > > jean >My mistake, further code browsing showed it was independant of both project. I will give it a shot tomorrow. sorry for the noise jean
Duane Johnson wrote:> 1. The basic functionality of so-called i18n seems pretty easy: Replace > sentences or paragraphs in one language with those of another > language. What issues do we have to face to get this done?Replacing sentences and paragraphs is fairly easy if the text is static. It''s when you have dynamics within those that problems arise: some languages order things "A B C" whereas others might order then "C B A". Currency is a good example: when using British pounds you put "£100" but when using Euros you put "100€" (if that doesn''t come out the pound sign goes before the number, the euro sign after it). There are similar things for the phrases in various languages where the dynamic bit (say a count of something) comes before or after the thing it''s counting (like "10 cats" in one language, and "cats 10" in another).> 3. And in a related question... it seems the Java camp has implemented > some ''advanced i18n'' features. What does that entail? Are we so far > behind that it could take months to catch up?There are many things in I18N that are "complicated". If you look at the java.text package (http://java.sun.com/j2se/1.4.2/docs/api/java/text/package-summary.html) you''ll see alot of things to help with splitting text up in a language neutral manner (BreakIterator) and for putting it back together (MessageFormat). Breaking text is a good one: this (bad!) English is made up of letters (each letter of the word is an individual character / symbol), but in other languages a ''letter'' can be multiple symbols. Something that hasn''t been mentioned, or at least I haven''t spotted it in this thread, is the notion of skinning. In WebWork (http://opensymphony.com/webwork/) you can have the same controller used under different views, so you hit http://foobar.com/en/index.html and get the controller code uses the ''views/en/index.html'' file, but hit http://foobar.com/fr/index.html and the *same* controller code uses ''views/fr/index.html'' (if you ignore language you can implement a WAP and HTML application using this technique, which I have before). It seems to me that the closest to this technique I''ve seen is the work on the productising a RoR application, which essentially structures the layout of the code in the appropriate manner, it just doesn''t pull it altogether into a single application at runtime AFAIK. But being fairly new to Rails I''m figuring there''s something I''m missing in how to do this (I suppose some kind of route would work).> 4. How does localization fit in to the picture?Localization is the task of taking a language neutral application (an internationalised application) that refers to system specified keys, and mapping those keys to language specific phrases. For instance, your I18N application might refer to a message as ''THE_FIELD_IS_INVALID'', but the language specific files would map this to the appropriate phrase. Matt
Hi, Duane Johnson wrote:> Please excuse my ignorance, as I''ve not yet built an > "internationalized" web application.I already did it, with php (pure php and with my framework, binarycloud).> The topic interests me, however, > so I would like to ask a few of questions to understand the scope of > this undertaking: > > 1. The basic functionality of so-called i18n seems pretty easy: Replace > sentences or paragraphs in one language with those of another > language. What issues do we have to face to get this done?It''s abit more complex. First strings can come from db (ActiveRecord), or from inside code, except if all text can be set in views only. Having text in db often means adding a ''lang'' field and having a custom PK being (oldPK, lang). Then another pb is localization, and not i18n: country list, date formats, currencies in each language, units, phone format, and so on. Last pb is determining current lang: I prefer using this order: first lang from url ( /en/controller/action ), then from session, then default lang. And when translated text is not there, default lang text should be used.> 2. It seems like Juha''s quick-n-dirty implementation would do the > job--is there something much more complicated lurking behind?I''d really like to have texts in db. To have a frontend for translators, and to be able to edit menus, product pages, wiki-like texts, form hints as well as static texts. And encoding is a bit easier to deal with (mysql 4.1 or postgresql handle utf8 easily).> 4. How does localization fit in to the picture?Ah, see above. To my idea l11n should be a class/app/gem (?) with ActiveRecord data maintained by the community with all iso codes for countries, currencies, formats (phone, zip codes...), and we could even add there geographical data like the main towns list, superficy, inhabitants count... I''m interested to have i18n work asap in rails, even if I''m a rail newbie. I''m though experienced with web programming, and I contributed a lot to I18N module in binarycloud (see binarycloud.com). -- Jean-Christophe Michel
i18n encompasses far more than just string translation, as Jean-Christophe
mentions below. Java has done the best job I''ve seen of any language
in
this regard. In fact, it''s one of the very few (come to think of it,
I''m
not sure what others do, maybe C#) that have this level of support as a core
language feature. Having it as a core language feature provides
consistency, generally makes it more well understood by more people, and
makes it far more likely to get used within an application, than if
it''s an
add-on.
Having said that, I respectfully disagree with storing strings in a
database. You now instantly require a DB, when there is really no
advantage, and all you do is add a restriction and requirement (which is one
of the downsides of the current gettext setup). Also, the string
("resource") file approach is so nice and simple, and makes it trivial
to
provide your strings to a localization team, etc. (think: send them a zip of
the text files vs. here''s a DB dump, oh, and you need X version of so
and so
database, set up and configured this way, etc.; that likely won''t fly
with a
localization house). I don''t see how encoding is any easier with a DB.
If
you want a front end to edit the strings (I expect you''d only need this
if
you were using a DB, as editing a text file can''t be much easier),
there''s
no reason you couldn''t do that for the text file as well (and
it''d likely be
an easier implementation).
Personally, if I were to implement it, I''d just completely rip off what
Java
did. It works very well (I''ve used it extensively, from the string
localization, to date and currency items, to locale use in general, etc.).
In fact, it''s the only language situation I''ve been in where
it''s pretty
much a no-brainer to use, and thus gets used extensively, and rather without
much effort.
On 7/26/05 2:27 PM, "Jean-Christophe Michel"
<jc.michel-/aRvmaKoZxNWk0Htik3J/w@public.gmane.org> wrote:
> Hi,
>
> Duane Johnson wrote:
>> Please excuse my ignorance, as I''ve not yet built an
>> "internationalized" web application.
>
> I already did it, with php (pure php and with my framework, binarycloud).
>
>> The topic interests me, however,
>> so I would like to ask a few of questions to understand the scope of
>> this undertaking:
>>
>> 1. The basic functionality of so-called i18n seems pretty easy:
Replace
>> sentences or paragraphs in one language with those of another
>> language. What issues do we have to face to get this done?
>
> It''s abit more complex. First strings can come from db
(ActiveRecord),
> or from inside code, except if all text can be set in views only.
> Having text in db often means adding a ''lang'' field and
having a custom
> PK being (oldPK, lang).
> Then another pb is localization, and not i18n: country list, date
> formats, currencies in each language, units, phone format, and so on.
> Last pb is determining current lang: I prefer using this order: first
> lang from url ( /en/controller/action ), then from session, then default
> lang. And when translated text is not there, default lang text should be
> used.
>
>> 2. It seems like Juha''s quick-n-dirty implementation would do
the
>> job--is there something much more complicated lurking behind?
>
> I''d really like to have texts in db. To have a frontend for
translators,
> and to be able to edit menus, product pages, wiki-like texts, form hints
> as well as static texts. And encoding is a bit easier to deal with
> (mysql 4.1 or postgresql handle utf8 easily).
>
>> 4. How does localization fit in to the picture?
>
> Ah, see above. To my idea l11n should be a class/app/gem (?) with
> ActiveRecord data maintained by the community with all iso codes for
> countries, currencies, formats (phone, zip codes...), and we could even
> add there geographical data like the main towns list, superficy,
> inhabitants count...
>
>
> I''m interested to have i18n work asap in rails, even if
I''m a rail
> newbie. I''m though experienced with web programming, and I
contributed a
> lot to I18N module in binarycloud (see binarycloud.com).
I agree with Christopher on his point regard the simplicity of the Java message bundle implementation of i18n (which I will use for sake of brevity even though I know l10n is an important distinction). Naturally there are a number of items that come into play when considering i18n, including currency, time, etc. However, that said, it is immesurably easier to simply send a message bundle (text file) to a translationist who can simply comment in the translation needed for the appropriate language bundle. For example, in JSF message.properties (which includes message=translation key pairings). I don''t have to find a programmer who knows .po/.mo/gettext/whatever . All I have to do is find some under-fed college student to fill in the appropriate translation for me and boda-boom I''ve got the translation file I can just stick in my framework (so the message.properties becomes message_de.properties). Rails is being preached as a tool for developers, not for TOOLerS. And hence Rails over JSF for developers. Implementing gettext would IMHO move Rails away from that benefit. And now that I''ve whined I''ll go back to creating my tutorial on using Eclipse to lay Rails. ;) On 7/26/05, Christopher Bailey <chris-yzaz/rx7IpEXSVZzYpeOkQC/G2K4zDHf@public.gmane.org> wrote:> > i18n encompasses far more than just string translation, as Jean-Christophe > mentions below. Java has done the best job I''ve seen of any language in > this regard. In fact, it''s one of the very few (come to think of it, I''m > not sure what others do, maybe C#) that have this level of support as a > core > language feature. Having it as a core language feature provides > consistency, generally makes it more well understood by more people, and > makes it far more likely to get used within an application, than if it''s > an > add-on. > > Having said that, I respectfully disagree with storing strings in a > database. You now instantly require a DB, when there is really no > advantage, and all you do is add a restriction and requirement (which is > one > of the downsides of the current gettext setup). Also, the string > ("resource") file approach is so nice and simple, and makes it trivial to > provide your strings to a localization team, etc. (think: send them a zip > of > the text files vs. here''s a DB dump, oh, and you need X version of so and > so > database, set up and configured this way, etc.; that likely won''t fly with > a > localization house). I don''t see how encoding is any easier with a DB. If > you want a front end to edit the strings (I expect you''d only need this if > you were using a DB, as editing a text file can''t be much easier), there''s > no reason you couldn''t do that for the text file as well (and it''d likely > be > an easier implementation). > > Personally, if I were to implement it, I''d just completely rip off what > Java > did. It works very well (I''ve used it extensively, from the string > localization, to date and currency items, to locale use in general, etc.). > In fact, it''s the only language situation I''ve been in where it''s pretty > much a no-brainer to use, and thus gets used extensively, and rather > without > much effort. > > > On 7/26/05 2:27 PM, "Jean-Christophe Michel" <jc.michel-/aRvmaKoZxNWk0Htik3J/w@public.gmane.org> > wrote: > > > Hi, > > > > Duane Johnson wrote: > >> Please excuse my ignorance, as I''ve not yet built an > >> "internationalized" web application. > > > > I already did it, with php (pure php and with my framework, > binarycloud). > > > >> The topic interests me, however, > >> so I would like to ask a few of questions to understand the scope of > >> this undertaking: > >> > >> 1. The basic functionality of so-called i18n seems pretty easy: Replace > >> sentences or paragraphs in one language with those of another > >> language. What issues do we have to face to get this done? > > > > It''s abit more complex. First strings can come from db (ActiveRecord), > > or from inside code, except if all text can be set in views only. > > Having text in db often means adding a ''lang'' field and having a custom > > PK being (oldPK, lang). > > Then another pb is localization, and not i18n: country list, date > > formats, currencies in each language, units, phone format, and so on. > > Last pb is determining current lang: I prefer using this order: first > > lang from url ( /en/controller/action ), then from session, then default > > lang. And when translated text is not there, default lang text should be > > used. > > > >> 2. It seems like Juha''s quick-n-dirty implementation would do the > >> job--is there something much more complicated lurking behind? > > > > I''d really like to have texts in db. To have a frontend for translators, > > and to be able to edit menus, product pages, wiki-like texts, form hints > > as well as static texts. And encoding is a bit easier to deal with > > (mysql 4.1 or postgresql handle utf8 easily). > > > >> 4. How does localization fit in to the picture? > > > > Ah, see above. To my idea l11n should be a class/app/gem (?) with > > ActiveRecord data maintained by the community with all iso codes for > > countries, currencies, formats (phone, zip codes...), and we could even > > add there geographical data like the main towns list, superficy, > > inhabitants count... > > > > > > I''m interested to have i18n work asap in rails, even if I''m a rail > > newbie. I''m though experienced with web programming, and I contributed a > > lot to I18N module in binarycloud (see binarycloud.com<http://binarycloud.com> > ). > > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- ~~~~~~~~~~~~~~~~~~~ D''Andrew Thompson http://dathompson.blogspot.com _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
Hello, On 7/27/05, Christopher Bailey <chris-yzaz/rx7IpEXSVZzYpeOkQC/G2K4zDHf@public.gmane.org> wrote:> Having said that, I respectfully disagree with storing strings in a > database.I do agree with your arguments as far as most i18n and l10n on the application level is concerned - there is no point putting this stuff into the database. For application-level strings, I''d happily use a property-file based approach or gettext or something similar. There are, however, cases where you want to localize a database record - say, you have an attribute/field that represents a user-supplied label and it should be possible to supply different labels _per record_ for each language. In that case, what you want would be a second table that holds the locale-specific data: Say you have a ''pages'' table, that, in the unlocalized version has a "title" and a "label" field and you want to have both localized. Than you would have a ''pages_localized'' table that has a primary key consisting of two fields, page_id and locale(_id) and two fields "label" and "title". Then the most sensible thing to have seems to be a "has_localized_attributes" macro call in your Pages model that joins against the _localized table and provides each Page with a two hash accessors, "labels" and "titles", with locales as keys. Of course, you then would also need a possibility to put find-conditions on the second table - maybe through a second condition-option? (You''ll probably also want to implement some caching for the localized attributes, similar to what is done with assosications) As far as I see, it is not really easy to make something like this work out-of-the-box with current rails, but it seems (to me) that it would be a nice addition. I actually began looking into how this might be accomplished, but I am kinda new to rails (though not to ruby), so I''d have to dig quite a bit into the activerecord-code and look how things are done in there if I want to do it properly. Any thoughts? Sven P. S. Since this is my first posting to this list, I might as well add that I love the framework - actually, I am a total rails-fanboy and find it - like many others - really tedious to go back to other framework/language combinations when one of my day-jobs requires me to.
On Jul 27, 2005, at 9:12 AM, Sven Lauer wrote:> Hello, > > On 7/27/05, Christopher Bailey <chris-yzaz/rx7IpEXSVZzYpeOkQC/G2K4zDHf@public.gmane.org> wrote: > >> Having said that, I respectfully disagree with storing strings in a >> database. >> > > I do agree with your arguments as far as most i18n and l10n on the > application level is concerned - there is no point putting this stuff > into the database. For application-level strings, I''d happily use a > property-file based approach or gettext or something similar.Let''s be a bit more open about this. My usage of Java''s (via Struts and Tapestry) I18N support was done in a suite of applications that demanded centralization and customization of text strings. The clients of our software needed to customize the strings. By hooking the flexible message resources hooks of both of those web frameworks I was able to easily implement the loading (and caching) of message resources from a database. I also implemented a feature such that if an admin was logged into the system, any customized text that appeared on the web pages would turn into a hyperlink (because it was rendered via taglib of custom component) - clicking that hyperlink popped up a text box allowing the administrator to change the text in the database directly. So please make message resource handling be pluggable with the default implementation being resource bundles. Erik
Good points. I was just emailing with someone privately about this as well. I agree that a) make it pluggable - Java is already this way, string text files are not the only choice you have, and b) when it comes to dynamic content, that''s a different story. My primary concern here is that this will be a solution in Rails, as opposed to Ruby. To me, one of the things that makes Java''s solution so successful is that it''s part of the core language. So, I''d like to see static application text string support done similar to Java, and done at the Ruby level (I realize this thread is on the wrong mailing list to get that as noticed, but mentioning for completeness). In terms of dynamic content, or what''s being discussed in light of a database, to me that is application specific, and thus not really the responsibility of the language or the framework. I could see the framework (Rails) providing a solution in this regard, and having it be pluggable will make it useful probably in most cases, but maybe not all. As Erik mentioned, if I were doing that in Java, I''d use a filter, or one of the hook mechanisms of the framework or similar that I was using. That seems to make a lot of sense. If you apply that to Rails, you could essentially have the same thing, just like you might for authentication, where you could supply a translation callback for a specific field on your model, so that any text coming out of that field would be translated, etc, etc. (I haven''t thought that through, just thinking about it light of a Rails approach). On 7/27/05 6:25 AM, "Erik Hatcher" <erik-LIifS8st6VgJvtFkdXX2HpqQE7yCjDx5@public.gmane.org> wrote:> > On Jul 27, 2005, at 9:12 AM, Sven Lauer wrote: > >> Hello, >> >> On 7/27/05, Christopher Bailey <chris-yzaz/rx7IpEXSVZzYpeOkQC/G2K4zDHf@public.gmane.org> wrote: >> >>> Having said that, I respectfully disagree with storing strings in a >>> database. >>> >> >> I do agree with your arguments as far as most i18n and l10n on the >> application level is concerned - there is no point putting this stuff >> into the database. For application-level strings, I''d happily use a >> property-file based approach or gettext or something similar. > > Let''s be a bit more open about this. > > My usage of Java''s (via Struts and Tapestry) I18N support was done in > a suite of applications that demanded centralization and > customization of text strings. The clients of our software needed to > customize the strings. By hooking the flexible message resources > hooks of both of those web frameworks I was able to easily implement > the loading (and caching) of message resources from a database. > > I also implemented a feature such that if an admin was logged into > the system, any customized text that appeared on the web pages would > turn into a hyperlink (because it was rendered via taglib of custom > component) - clicking that hyperlink popped up a text box allowing > the administrator to change the text in the database directly. > > So please make message resource handling be pluggable with the > default implementation being resource bundles. > > Erik > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails