Rails - Dec 2004 - I18n support in Rails?

Hi,

it seems like there is no i18m support planned for Rails 1.0. What is 
the position on that? It sems like it is a good idea to implement i18n 
right from the beginning, if one is to implement it at all.

David, can you state shortly if there is going to be support for this or 
if you think that this is something that the developers have to come up 
themselves.

My personal opinion is that this should be supported by a web framework. 
And I would do it for my CMS cause it has to be able to do German and 
English from the beginning. The question is, will I do it only to 
through it away cause Rails will do it a diffrent way in the future?

Thank you
-- 
Sascha Ebach

Sascha Ebach wrote:
> Hi,
> 
> it seems like there is no i18m support planned for Rails 1.0. What is 
> the position on that? It sems like it is a good idea to implement i18n 
> right from the beginning, if one is to implement it at all.
What kind of "support" did you think of?

Hi Andreas,
>> it seems like there is no i18m support planned for Rails 1.0. What is 
>> the position on that? It sems like it is a good idea to implement i18n 
>> right from the beginning, if one is to implement it at all.
> 
> 
> What kind of "support" did you think of?
To describe what kind of support there should be, first, I think, some 
kind of commitment must be made. There are lots of techniques. The thing 
is: At the moment there doesn''t seem to be any need for our maintainer 
to implement such a thing. Just imagine Basecamp would be made available 
in other languages besides English, potentially doubling or trippling 
the customer base. Surely we would have David thinking of something very 
soon if that were the case. But it isn''t, or is it? Maybe the support 
cost is too high in the case of 37s (not being able to take in German 
support calls or even Japanese).

I18n is one of the bigger problems when building any kind of software 
for an international community / user base. We certainly have a nice mix 
of countries on the mailinglist. So far I have not seen any evidence 
that i18n is even beeing thought about. So I guessed I better ask.

The kind of support I think about is any technique, library, function, 
method, object or whatever that could help seperating the language of 
implementation from the language of usage.

Having clear recommendations and documentation on how to implement i18n 
for any rails app. And having a module for supporting any kind of i18n 
(or even an additional library) couldn''t hurt. It would even be cool,
if
the error message themselves (in rails) could be multilingual.

http://translate.openacs.org/

If you want an example for a framework for support with i18n. There work 
on this issue is impressive. It would be really cool to have a open 
source app like a cms or a forum and let the ppl translate it online.

The reason I think this is kinda *urgent* is that everybody knows that 
implementing i18n after the fact is a bad idea. What do you think? Will 
you do i18n in rforum by yourself or will you wait till rails attacks 
the issue and then maybe have to reimplement?

If there has been no thought put into it so far I''d be glad to explore 
it here a little more. What do all the other ppl think about being able 
to translate your app? Would the functional support be ideally in the 
framework itself or should everbody solve this problem on their own?

My cms needs to be German and English from the beginning so i18n is 
something I have to think about upfront.

-- 
Sascha Ebach

On Saturday, December 18, 2004, 10:03:45 AM, Sascha wrote:
> [...]
Sascha, I appreciate you bringing up this issue.  I''ll just throw two
comments in.
> The reason I think this is kinda *urgent* is that everybody knows that
> implementing i18n after the fact is a bad idea. What do you think? Will
> you do i18n in rforum by yourself or will you wait till rails attacks
> the issue and then maybe have to reimplement?
Reimplementing is not necessarily a bad thing.  You never hear people
complaining about reimplementing validations etc. in light of Rails
0.9.
> [...]
> My cms needs to be German and English from the beginning so i18n is 
> something I have to think about upfront.
Thinking about it in the application domain is easier and more
appropriate than doing so in the framework domain.  As DHH said,
"frameworks are extracted, not created".  You take an application
solution and extract/generalise it.  Maybe you will have to be the
application guinea pig :)

Cheers,
Gavin

Sascha Ebach wrote:
> http://translate.openacs.org/
> 
> If you want an example for a framework for support with i18n. There work 
> on this issue is impressive. It would be really cool to have a open 
> source app like a cms or a forum and let the ppl translate it online.
 >
> The reason I think this is kinda *urgent* is that everybody knows that 
> implementing i18n after the fact is a bad idea. What do you think? Will 
> you do i18n in rforum by yourself or will you wait till rails attacks 
> the issue and then maybe have to reimplement?
Actually I already have implemented it for RForum. Take a look at 
rforum/lib/localization.rb, rforum/lang/ and the templates (though not 
everything is translated yet). It''s a very simple system because we 
won''t need more than about a hundred strings. Something like the
OpenACS
translation server is absolutely overkill for this.

Translation is not something which should be in the framework. Good
translation needs a tailored infrastructure just like every web
application needs an own GUI.
However the framework should not be in the way of translation. 

Rails .9 for example now has all the validation errors consolidated in
a strings hash so that you
don''t have to overwrite all the methods if your users don''t
speak english.

If there are any other things in the framework which make
internationalization tricky please let me know and I will see if i can
come up with a patch.


On Sat, 18 Dec 2004 02:32:51 +0100, Andreas Schwarz
<usenet-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org>
wrote:
> Sascha Ebach wrote:
> > http://translate.openacs.org/
> >
> > If you want an example for a framework for support with i18n. There
work
> > on this issue is impressive. It would be really cool to have a open
> > source app like a cms or a forum and let the ppl translate it online.
>  >
> > The reason I think this is kinda *urgent* is that everybody knows that
> > implementing i18n after the fact is a bad idea. What do you think?
Will
> > you do i18n in rforum by yourself or will you wait till rails attacks
> > the issue and then maybe have to reimplement?
> 
> Actually I already have implemented it for RForum. Take a look at
> rforum/lib/localization.rb, rforum/lang/ and the templates (though not
> everything is translated yet). It''s a very simple system because
we
> won''t need more than about a hundred strings. Something like the
OpenACS
> translation server is absolutely overkill for this.
> 
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
> 

-- 
Tobi
http://blog.leetsoft.com

On Fri, 17 Dec 2004 20:40:16 -0500, Tobias Luetke
<tobias.luetke-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> Translation is not something which should be in the framework. Good
> translation needs a tailored infrastructure just like every web
> application needs an own GUI.
Maybe not in the framework, per se, but I can certainly imagine
plug-in like functionality that could support internationalization.
I''m not sure what that would look like, but clearly this is a problem
that doesn''t need to be solved in toto every time.

Bob

Hi Gavin,
> Reimplementing is not necessarily a bad thing.  You never hear people
> complaining about reimplementing validations etc. in light of Rails
> 0.9.
True, but they already have a framework to use. And as others on this 
list stated, the tight coupling between the validation and the database 
functionality is not that ideal. It is not particularly reusable. I hope 
that this gets refactored in the future as need arises. (So here is your 
first complaint ;)
> Thinking about it in the application domain is easier and more
> appropriate than doing so in the framework domain.  As DHH said,
> "frameworks are extracted, not created".  You take an application
> solution and extract/generalise it.  Maybe you will have to be the
> application guinea pig :)
I feared something like that ;)

--
Sascha Ebach

> Actually I already have implemented it for RForum. Take a look at 
> rforum/lib/localization.rb, rforum/lang/ and the templates (though not 
> everything is translated yet). It''s a very simple system because
we
> won''t need more than about a hundred strings. Something like the
OpenACS
> translation server is absolutely overkill for this.
For now, yes, it is overkill. OpenACS is an extreme example. 
Nevertheless, you don''t design your i18n support for the beginning of 
the life cycle of your software (rforum is in an early stage) you want 
to have l18n support ready when the software is ready for prime time and 
gets popular. We want a popular ruby forum package or not? Surely 
someday 100 strings will grow into 1000 and then what? Than maybe the 
Japanese pick up the package and there is not even Unicode support in 
it. All over sudden you have users that speak languages that are written 
from right to left. Alright, you can say you don''t want all of that and
that''s ok. But then you don''t really need to talk about it in
the first
place.

I will have a look at rforum again to check out the localization 
support. Last time I looked at the rforum code it was a great inspiration.

As Gavin said, maybe I just need to start implementing it and see what 
can be extract to the framework level. I am sure if David would have had 
to do it (e.g. for Basecamp) it would already be there.

--
Sascha Ebach

Hi Tobias,

Tobias Luetke schrieb:
> Translation is not something which should be in the framework. Good
> translation needs a tailored infrastructure just like every web
> application needs an own GUI.
> However the framework should not be in the way of translation. 
I agree. It also depends on how you define "in the framework". Looking
at ActionMailer I see a package which is completely separable from the 
framework. Maybe we need a package called ActionLanguage?
> Rails .9 for example now has all the validation errors consolidated in
> a strings hash so that you
> don''t have to overwrite all the methods if your users
don''t speak english.
What if the messages get updated. Am I to figure that out by myself? If 
they do I have to read through all of it everytime this happens. 
(Gettext does this for you automatically, at least to a degree)

Later on you have strings here and bits of pieces there, some in files, 
some in the database and before you know it have to manage 15 different 
mechanisms to translate your app. With duplication all over the place. I 
have had this before. This is hell. A translation mechanism needs to be 
in one place. Don''t you agree?
> If there are any other things in the framework which make
> internationalization tricky please let me know and I will see if i can
> come up with a patch.
I have only started exploring for now. I am sure that the issue will 
come up more often in the future.

--
Sascha Ebach

> Maybe not in the framework, per se, but I can certainly imagine
> plug-in like functionality that could support internationalization.
> I''m not sure what that would look like, but clearly this is a
problem
> that doesn''t need to be solved in toto every time.
Like Tobias said: "Good translation needs a tailored infrastructure just 
like every web application needs an own GUI." I believe this is only 
true to an extend. Totally not recognizing that a GUI and a i18n support 
framework is not really comparable at all (maybe it is comparable to a 
GUI framework?). I think most of i18n can be extracted. It largely 
depends on what you are doing. Like with every software. But there could 
be guideslines that tell you largely how to do it. Just like 
ActiveRecord tells you largely how to work with databases. (There is 
certainly going on a lot of great discussion about that subject on this 
list). You need to tailor your (db) infrastructure accordingly. I am 
looking for something similiar for i18n.

I confess that I have to aquire a lot more expertise in this field. 
Maybe I should look out for some good literature on this subject. Anyone 
have some good book recommendations on the subject?

--
Sascha Ebach

On Saturday, December 18, 2004, 4:12:20 PM, Sascha wrote:
> Hi Gavin,
>> Reimplementing is not necessarily a bad thing.  You never hear people
>> complaining about reimplementing validations etc. in light of Rails
>> 0.9.
> True, but they already have a framework to use. And as others on this
> list stated, the tight coupling between the validation and the database
> functionality is not that ideal. It is not particularly reusable. I hope
> that this gets refactored in the future as need arises. (So here is your
> first complaint ;)
That''s occured to me as well, but compaints like that indicate that
you''re being spoiled by the framework in the first place :)  If you
want to have your cake and eat it too, sometimes you need some tight
coupling.

Gavin

> That''s occured to me as well, but compaints like that indicate
that
> you''re being spoiled by the framework in the first place :)  If
you
> want to have your cake and eat it too, sometimes you need some tight
> coupling.
Actually, at the code level, the coupling is anything but tight. Active 
Record is very modular in its construction. ActiveRecord::Base is a 
fairly shallow beasts that know nothing of neither validations, 
transactions, associations, or any of the other nifty features that the 
full package has to offer. What happens is that the main 
active_record.rb embellish Base with all these capabilities by 
including modules:

ActiveRecord::Base.class_eval do
   include ActiveRecord::Validations
   include ActiveRecord::Callbacks
   include ActiveRecord::Associations
   include ActiveRecord::Aggregations
   include ActiveRecord::Transactions
   include ActiveRecord::Reflection
   include ActiveRecord::Timestamp
   include ActiveRecord::Acts::Tree
   include ActiveRecord::Acts::List
end

Almost all of these modules work in isolation of each other. That means 
if we remove the inclusion of include ActiveRecord::Validations, Active 
Record will live on happily in ignorance about validation matters. Same 
thing with almost all of the others (Callbacks is the only one that 
some modules, like Associations, Timestamp, and the Acts depend on).

That also means that if you''re duck-type compatible with Active Record,
you could include ActiveRecord::Validations in your own model approach 
AND IT WOULD WORK!

So I''m not entirely sure what the accusations of tight coupling in 
regards to validation are about?

I do realize that some people find it weird to have validation rules on 
the model and label their discontent tight coupling. I had some of the 
same reservations when starting out with the approach, but I''ve since 
grown to like it a lot.

For me, it''s just like pulling in constraints from the database
(let''s
not start that one again, though). It''s consolidating all the concerns 
that pertain to the use of the model in the model. So I''d much rather 
file it under "coherent", if we''re in the labeling game.
--
David Heinemeier Hansson,
http://www.basecamphq.com/   -- Web-based Project Management
http://www.rubyonrails.org/  -- Web-application framework for Ruby
http://macromates.com/       -- TextMate: Code and markup editor (OS X)
http://www.loudthinking.com/ -- Broadcasting Brain

Sascha Ebach wrote:
>  And as others on this
> list stated, the tight coupling between the validation and the database 
> functionality is not that ideal.
I strongly agree on this point. Form validation should be seperated from 
ActiveRecord.

> David, can you state shortly if there is going to be support for this 
> or if you think that this is something that the developers have to 
> come up themselves.
We''ve been exploring the subject at 
http://www.rubyonrails.org/show/Internationalization, but haven''t 
really found a conclusion. I''m still in doubt on whether Rails should 
offer any level of support. The approach to i18n seems to range widely 
from a simple lookup table and a translate(word) helper to big honking 
frameworks like OpenACS. And that''s probably because the needs for i18n
differ in similar regards.

In other words, it would appear that i18n is business logic 
masquerading as infrastructure. It''s already been established that 
Rails is about abstracting the latter, not the former. But the judge is 
still out on that, so no final verdict has been reached.

Also, as you correctly mentions, I haven''t done i18n in Rails yet, so 
there hasn''t been code to extract. There''s a lot of reasons
why
Basecamp isn''t available in many languages, but the prime one is that 
we don''t consider i18n to be a big technical problem, but rather a HUGE
organizational problem for a moving target application.

Additionally, I believe that the notion that doing i18n after the fact 
is impossible, or even significantly harder, is a myth. i18n is hard 
and a lot of work no matter when its being done, but mostly for other 
reasons than wrapping strings in translate calls.
--
David Heinemeier Hansson,
http://www.basecamphq.com/   -- Web-based Project Management
http://www.rubyonrails.org/  -- Web-application framework for Ruby
http://macromates.com/       -- TextMate: Code and markup editor (OS X)
http://www.loudthinking.com/ -- Broadcasting Brain

On Saturday, December 18, 2004, 10:27:49 PM, David wrote:
> So I'm not entirely sure what the accusations of tight coupling in 
> regards to validation are about?
From my part, it was presumptions rather than accusations.  I must
say, the design evident from your response is very impressive.  Well
done!

Gavin

_______________________________________________
Rails mailing list
Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails

On Sat, 18 Dec 2004 12:27:49 +0100, David Heinemeier Hansson
<david-OiTZALl8rpK0mm7Ywyx6yg@public.gmane.org> wrote:
> So I''m not entirely sure what the accusations of tight coupling in
> regards to validation are about?
> 
> I do realize that some people find it weird to have validation rules on
> the model and label their discontent tight coupling. I had some of the
> same reservations when starting out with the approach, but I''ve
since
> grown to like it a lot.
OK, I''ll bite. I agree that it''s not the so-called tight
coupling that
bothers me, it''s where the validation lies. Here are some reasons that
(I think) this is a problem (some of these may be due to
misunderstandings on my part--I''ve had some difficulty understanding
the model, but I think I''ve pieced it together). All of these have to
do with form validation, but probably apply to any other means that
you might acquire data.

1. By the time the validation rules are called, any form information
has already been converted into internal formats. Numeric fields may
be converted to floating point, for example. This means that I cannot
properly validate input format for these fields (without stepping
outside of this model). If the user types "50,100" for a numeric
field, for example, I believe this will probably be converted to "50",
with the ",100" silently ignored. No amount of validation on the model
will detect this.

2. Similarly, if I want to replay the form to the user after an error,
various conversions will already have happened to the data (such as
the 50,100 => 50 conversion, above). I don''t want this: I want to
replay the form EXACTLY as it was when the user submitted the form, so
that s/he can correct any mistakes from the form as it was initially
entered.

3. I don''t see any easy way to do multi-part forms, where the form
information is gathered in stages. The validation rules in the model
work globally on the whole record. So if several fields are labelled
as "required", for example, then that''s a useless validation
if only
part of the record is available. In any event, I don''t even see how to
invoke the validation if I''m not ready to save it. The stages that can
be associated with validations (save, update, create), don''t quite
match the processing implied by a multi-part form. One possible answer
is that the way to do such a form is to do it using a separate
temporary table for each part of the form. But this seems like a lot
of complexity which should be unecessary, I think.

4. Validations such as regexp matching are nice, but (as mentioned in
(1), above) they are done at the wrong level, after conversion to some
basic type. In addition, they''re likely to be repeated in different
models (or even in the same model) for the same basic types. In a bit
of a reversal of the usual duck typing argument: if something is a
duck, then we shouldn''t be presuming to tell the duck how it behaves.
The duck should do this. Or to be more concrete: if a field is
supposed to represent a credit card number, then we should somehow
tell the system this fact, not get into the details of credit card
representation directly in the model.

5. I may want to create a form that doesn''t correspond directly to the
ActiveRecord fields. Just as you''ve done for Date types, I may want to
use multiple form elements to represent a single field. For example,
an account balance might be represented by a numeric absolute balance
and a checkbox to indicate whether the balance is positive or
negative; a Visa card number might be represented one way on screen,
in more than one field (for expiration date, etc.), but stored
encrypted in the record. The current system is certainly "tightly
coupled" when it comes to types (like Date) that have been granted
special status (the clue to this is ActiveRecord code with case
statements that say "when date do this, when number do this, etc.".

Anyway, you asked, and those are some of my issues. Maybe I''m just
missing the point--I''d love to hear your response to this.

Bob

On Dec 18, 2004, at 11:00 AM, Bob Sidebotham wrote:
> The current system is certainly "tightly
> coupled" when it comes to types (like Date) that have been granted
> special status (the clue to this is ActiveRecord code with case
> statements that say "when date do this, when number do this,
etc.".
Although I haven''t had time to tackle it yet, the block of code
you''re
referring to is what I believe needs to be changed in order to support 
the remaining database adapters properly. It''s on my todo list. The 
solution I proposed earlier was to retain the "original" type (in my 
case, the type that''s in the database) so that later code can respond 
to that type (for quoting, etc.), not whatever internal implementation 
type Rails happens to be using that release.

Data coming from forms is a similar problem (types are being lost, 
manifesting itself in narrowing conversions), so it may be possible to 
do something similar for the data heading down into validation. For 
example, when the conversion is made to the Rails type, Rails could 
store the original, unconverted value (somewhere, keeping it until the 
converted data was committed to disk or whatever). Then at least it 
would be available in the model for validations.

The basic principle is that Rails shouldn''t be throwing away type 
information the way it does now.

As for not being able to do multiple forms (because the validation is 
tied to the database operations), that''s easy to work around: simply 
call the validation methods yourself. That''s how other frameworks do 
it, and it works well IMO. It might be reasonable for Rails to provide 
some kind of bottleneck method for all the validations being performed 
on a single piece of data, or to even support a "partial" validation 
directly (i.e. just validate data that has been entered so far, not 
every field possible).

Best, Eric

> 1. By the time the validation rules are called, any form information
> has already been converted into internal formats. Numeric fields may
> be converted to floating point, for example.
This is actually not quite what happens. Active Record uses lazy type 
casting, so the conversion only happens when that attribute is queried. 
So if you didn''t query a given attribute, it would stay in its 
string-based form as it was assigned by either controller or database.
> This means that I cannot properly validate input format for these 
> fields (without stepping outside of this model). If the user types 
> "50,100" for a numeric
> field, for example, I believe this will probably be converted to
"50",
> with the ",100" silently ignored. No amount of validation on the
model
> will detect this.
Actually, this is not as much a limitation in the having validations on 
the model as its a case of missing requests for this feature. 
Personally, I''ve had had the 50,100 case, but I can see the trouble now
that you mention it. The few times I did have issues with type-casting, 
I have used the before_validation family of callbacks to turn something 
like " email @address.com" into
"email-Jbz+COfnBihBDgjK7y7TUQ@public.gmane.org".

I''d recommend that you do the same for your 50,100. I can point you to 
many articles on user interface design that berates the inflexibility 
of web-applications that want a credit card or telephone number in one 
format and barks at everything else. Why should you bother the user 
with details on whether you internally store the number as
"XXXXXXXXX",
"XXXXX-XXXX", or "XXX XX XX XX". Machines were made to
correct these
trivial differences and the before_validation* callbacks were designed 
to do exactly this.

ALL THAT BEING SAID, I agree ;). In the rare cases where you truly do 
want to burden the user with the task of resolving formatting issues 
(launch codes for the nuclear strike center web-app in Rails and the 
likes), you should be able to...

And as of this moment, you are :). I just checked in a minor tweak that 
makes it possible to make *_before_type_cast calls to any attribute. 
 From the test case:

   # Developer has defined: validates_inclusion_of :salary, :in => 
50000..200000
   def test_throw_away_typing
     d = Developer.create "name" => "David",
"salary" => "100,000"
     assert !d.valid?
     assert_equal 100, d.salary
     assert_equal "100,000", d.salary_before_type_cast
   end

Naturally, this would be cumbersome to deal with manually, so I''ve also
tinkered with Action Pack that now picks up and uses *_before_type_cast 
calls for input fields and text areas.

Meaning that it now Just Works (tm).
> 2. Similarly, if I want to replay the form to the user after an error,
> various conversions will already have happened to the data (such as
> the 50,100 => 50 conversion, above). I don''t want this: I want
to
> replay the form EXACTLY as it was when the user submitted the form, so
> that s/he can correct any mistakes from the form as it was initially
> entered.
This is indeed now the behavior. The change was literally ten (10) 
lines of code, but I agree that its an improvement. Thanks for bringing 
it up!
> 3. I don''t see any easy way to do multi-part forms, where the form
> information is gathered in stages...
Base#valid? calls the all validations and you can then query the fields 
that are part of the current collection screen with 
model.errors.on(attribute).
> 4. Validations such as regexp matching are nice, but (as mentioned in
> (1), above) they are done at the wrong level, after conversion to some
> basic type. In addition, they''re likely to be repeated in
different
> models (or even in the same model) for the same basic types.
As demonstrated above, type conversion in Active Record is done lazily. 
And with the additions from this morning, it''s now possible to directly
query the un-cast values.

Regarding repetition, you deal with this as you would any other in 
software development: abstraction. Example:

   validates_format_of :credit_card,  :with => Formats::CREDIT_CARD
   validates_format_of :phone_number, :with => Formats::US_PHONE_NUMBER

Place the formats.rb file in lib and add require_dependency
''format'' to
your environment. Now the formats are available to all models in the 
system.
> 5. I may want to create a form that doesn''t correspond directly to
the
> ActiveRecord fields. Just as you''ve done for Date types, I may
want to
> use multiple form elements to represent a single field. For example,
> an account balance might be represented by a numeric absolute balance
> and a checkbox to indicate whether the balance is positive or
> negative; a Visa card number might be represented one way on screen,
> in more than one field (for expiration date, etc.), but stored
> encrypted in the record. The current system is certainly "tightly
> coupled" when it comes to types (like Date) that have been granted
> special status (the clue to this is ActiveRecord code with case
> statements that say "when date do this, when number do this,
etc.".
Again, this is really not accurate. Active Record supports what it 
calls multi-parameter attributes, which combined with aggregations 
sounds a lot like what you''re looking for. Take the example of Money in
a given currency. You have two parts constituting a single attribute, 
the amount and the currency.

class TravelersCheck < ActiveRecord::Base
   composed_of :value, :class_name => "Money", :mapping => [
%w(amount
amount), %w(currency currency) ]
end

Value   : <input type="text"
name="travelers_check[value(1)]" />
Currency: <input type="text"
name="travelers_check[value(2)]" />

...on travelers_check.attributes = @params["travelers_check"], the two
inputs will be transformed into Money.new(value, currency) that''s 
assigned to travelers_check.value. You can then validate this money 
object and do what you please with the results.

It might take a bit more legwork than the automatics we''ve grown 
accustomed to with the simpler 1-1 assignments, but it''s most certainly
possible. And I sincerely doubt that its anywhere near the trouble of 
maintaining any of the double mapping paradigms from other frameworks 
(ActionForms <-> Model <-> Database).
> Anyway, you asked, and those are some of my issues. Maybe I''m just
> missing the point--I''d love to hear your response to this.
Please do let me hear the rest. As today''s 10-line change demonstrated,
nothing is set in stone and most things are pretty easy to rectify.

The reason I''m being so bullish on this point is that I absolutely, 
positively hate saying the same thing twice. If form validations were a 
separate department, you''d have to first describe rules as they relate 
to the form and then repeat largely the same thing to ensure that the 
models couldn''t loose their integrity when used by other consumers 
(such as other models in the domain, daily scripts, or console 
interactions).

Another reason I''m kinda on guard (and might appear a bit pissy even 
when I''m not ;)), is that this issue resembles the Active Record vs 
Data Mapper debate. As originally described, the AR pattern didn''t 
address associations or inheritance. Hence, a lot of people dismissed 
it in favor of the much more complicated Data Mapper instead of trying 
to fix the issues.

So in my mind, this is a repetition of the same approach. Instead of 
rejecting the idea of model-based validations, why don''t we see if we 
can make it so good that it would appear silly to trade the last 5-10% 
of flexibility for 80% more work.
--
David Heinemeier Hansson,
http://www.basecamphq.com/   -- Web-based Project Management
http://www.rubyonrails.org/  -- Web-application framework for Ruby
http://macromates.com/       -- TextMate: Code and markup editor (OS X)
http://www.loudthinking.com/ -- Broadcasting Brain

David Heinemeier Hansson <david-OiTZALl8rpK0mm7Ywyx6yg@public.gmane.org>
said:
> So in my mind, this is a repetition of the same approach. Instead of
> rejecting the idea of model-based validations, why don''t we see if
we
> can make it so good that it would appear silly to trade the last 5-10%
> of flexibility for 80% more work.
David,

Thank you very much for your extensive reply to the concerns I raised.
I haven''t had time (yet) to thoroughly digest this or to try out your
changes. I would like to spend some time implementing some more of my
application before I give you any further feedback.

I appreciate the care and thought you are putting into this!

Bob

I agree with everyone saying that it isn''t something that should be a
part of the Rails framework. However, its obviously still a topic
worth exploring.

Like the wiki page says, there''s a few possible ways to solve it.
ruby-gettext doesn''t appear to be perfect without "someone"
fixing the
entities issue. YAML seems like a good solution, but how forgiving is
YAML with non-english characters? (it seems to me like its pretty
forgiving?)

Another thing I''ve noticed creating a non-english Rails app is that
you kinda loose some of the nicer things in rails, particular with
error messages if you''re anything like me and like your table names
and columns to be in english, ie this (with a bad german example error
msg)
validates_presence_of :username, :password, { "du bist verruckt" }
often needs to be expanded further depending on the grammar rules of
the language aswell as the table names (which one could create a
lookup table for or state the fieldname explicit in the error
message).. Not a lot of extra work required [1], but worth keeping in
mind.

But as David says, there''s a lot of ways to solve the issue of l18n
and in most cases the amount of work/code required depends on the
specific application in question.

But I''m still very much interested in seeing how other people have
solved the various issues of l18n together with rails.

-- johan

[1] http://collaboa.cocoa.se/trac/file/trunk/app/models/user.rb


On Sat, 18 Dec 2004 12:39:28 +0100, David Heinemeier Hansson
<david-OiTZALl8rpK0mm7Ywyx6yg@public.gmane.org>
wrote:
> > David, can you state shortly if there is going to be support for this
> > or if you think that this is something that the developers have to
> > come up themselves.
> 
> We''ve been exploring the subject at
> http://www.rubyonrails.org/show/Internationalization, but haven''t
> really found a conclusion. I''m still in doubt on whether Rails
should
> offer any level of support. The approach to i18n seems to range widely
> from a simple lookup table and a translate(word) helper to big honking
> frameworks like OpenACS. And that''s probably because the needs for
i18n
> differ in similar regards.
> 
> In other words, it would appear that i18n is business logic
> masquerading as infrastructure. It''s already been established that
> Rails is about abstracting the latter, not the former. But the judge is
> still out on that, so no final verdict has been reached.
> 
> Also, as you correctly mentions, I haven''t done i18n in Rails yet,
so
> there hasn''t been code to extract. There''s a lot of
reasons why
> Basecamp isn''t available in many languages, but the prime one is
that
> we don''t consider i18n to be a big technical problem, but rather a
HUGE
> organizational problem for a moving target application.
> 
> Additionally, I believe that the notion that doing i18n after the fact
> is impossible, or even significantly harder, is a myth. i18n is hard
> and a lot of work no matter when its being done, but mostly for other
> reasons than wrapping strings in translate calls.
> --
> David Heinemeier Hansson,
> http://www.basecamphq.com/   -- Web-based Project Management
> http://www.rubyonrails.org/  -- Web-application framework for Ruby
> http://macromates.com/       -- TextMate: Code and markup editor (OS X)
> http://www.loudthinking.com/ -- Broadcasting Brain
> 
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
> 

-- 
Johan Sørensen
Professional Futurist
www.johansorensen.com