Here''s a quick update on the Multilingual plugin. First of all, thanks for all the kind words and helpful comments. I''m glad to see that so many people are interested in this project. After the initial release, it became apparent that there were a few major glitches with the code, so I had to make some changes. There are probably a few more rough spots ahead. Here''s what I changed since yesterday: - Not overriding to_s and strftime anymore. I was warned about this, and it really breaks too much stuff. Would have been cool, though. Now Fixnum, Bignum, and Float have "localized" methods that return locale-formatted versions. Time and Date also have "localized(format)" methods that return localized versions of strftime. - Now using CSV formatted rows to populate the tables, instead of hardcoded inserts. This makes the migrate script totally cross-platform. On the downside, it now takes about 60 seconds to do the migrate on my computer. Maybe the CSV library is really slow? I also have some thoughts about issues brought up in the mailing list. - Some alternate table schemas were offered. I''m not that concerned about this right now, because I think the most important part to nail down now is the API interface. The implementation can certainly be tweaked later. That said, I still think my approach has a big advantage: it doesn''t require messing with tables during development. The other approaches would require some kind of script to create or alter tables every time a field or language was added or deleted. This could quickly turn into a nightmare, especially if you''re working with a production app on a remote machine. If you''re using sqlite, you might have to rebuild the entire db. This also seems to contradict the Rails spirit. The drawback of my solution may be performance, but that hasn''t been demonstrated. It uses joins on integer primary key columns, so the db engines should do a good job with the queries. I''m not sure this will be an issue. Another drawback cited was cleanliness of design. I think that''s debatable, too. - Caching translations. Yes, I definitely plan to cache translations, especially view translations, in the near future. At first there will probably be an option to cache every translation in memory, once loaded. Later we can explore more sophisticated approaches. Finally, Josh Sierles was kind enough to host the project on his server. We''ll be moving the svn repository and RDocs there tomorrow, and hopefully setup Collaboa and a wiki soon. I''ll keep you posted. Cheers, Josh Harvey
> > - Now using CSV formatted rows to populate the tables, instead of > hardcoded inserts. This makes the migrate script totally > cross-platform. On the downside, it now takes about 60 seconds to do > the migrate on my computer. Maybe the CSV library is really slow? >Hi Joshua, I came across this the other day. I haven''t tried it but it may speed up your csv processing: http://raa.ruby-lang.org/project/fastercsv/ Hammed _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
Hi Joshua, Thanks for your work on making rails multlingual.> > - Now using CSV formatted rows to populate the tables, instead of > hardcoded inserts. This makes the migrate script totally > cross-platform. On the downside, it now takes about 60 seconds to do > the migrate on my computer. Maybe the CSV library is really slow? >Hmm. Does not seem to work for me. I created a new Rails (0.14.3) project, databases (postgresql) and tried to install the plugin by - script/plugin install https://OpenSVN.csie.org/multi_lingual_rails/multilingual/trunk (worked fine) - script/generate multilingual (created the migration) and - rake migrate failed with `rake aborted! uninitialized constant DATA'' Any help with this? I''m using Rails 0.14.3, ruby 1.8.2 on Linux with postgres 8.1 Morus
Same here with OSX Tiger and latest Rails rc. However I noticed that the tables were created in the database. It''s the data loading that fails. On 11/24/05, Morus Walter <morus.walter.ml-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote:> Hi Joshua, > I created a new Rails (0.14.3) project, databases (postgresql) and tried > to install the plugin by > - script/plugin install > https://OpenSVN.csie.org/multi_lingual_rails/multilingual/trunk > (worked fine) > - script/generate multilingual (created the migration) > and > - rake migrate > failed with `rake aborted! uninitialized constant DATA''-- Eduardo Fernández Corrales
Sorry about that, guys. I hadn''t checked in the latest version --
it''s
up now and should work.
Also, you might have to do the following to get it to work:
In your application.rb:
model "multilingual/models/language.rb",
"multilingual/models/country.rb",
"multilingual/models/view_translation.rb"
Multilingual::Locale.set_base_language(''en'')
Multilingual::Locale.set(''en-US'')
Of course, the language and locale codes can be any language/locale,
they just have to be set. I don''t understand exactly why the
"model"
directive is necessary, but without it, Rails seems to load these
models as ActiveRecord::Base, and they throw missing_method
exceptions. Anybody have any information about this?
Also, if it wasn''t obvious, this is still beta code, so don''t
expect
it to run smoothly on all platforms. The bug reports are extremely
useful, because I''m only testing on Windows/MySql/Sqlite at this
point. Thanks to everyone who''s helping to iron out the glitches.
Josh Harvey