# Multilingual Rails Plugin Update **URL:** \ **Category:** Rails\ **Created:** [November 24, 2005, 3:32am UTC](https://www.ruby-forum.com/t/multilingual-rails-plugin-update/48752 "2005-11-24T03:32:00Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![jmharvey.9956003](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/dbc845/32.png) [@jmharvey.9956003](https://www.ruby-forum.com/u/jmharvey.9956003)\ **Post date:** [November 24, 2005, 3:32am UTC](https://www.ruby-forum.com/t/multilingual-rails-plugin-update/48752/1 "2005-11-24T03:32:00Z")
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 ---
**Author:** ![jmharvey.9956003](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/dbc845/32.png) [@jmharvey.9956003](https://www.ruby-forum.com/u/jmharvey.9956003)\ **Post date:** [November 24, 2005, 4:36am UTC](https://www.ruby-forum.com/t/multilingual-rails-plugin-update/48752/2 "2005-11-24T04:36:23Z")
> - 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/](http://raa.ruby-lang.org/project/fastercsv/) Hammed ---
**Author:** ![jmharvey.9956003](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/dbc845/32.png) [@jmharvey.9956003](https://www.ruby-forum.com/u/jmharvey.9956003)\ **Post date:** [November 24, 2005, 11:07am UTC](https://www.ruby-forum.com/t/multilingual-rails-plugin-update/48752/3 "2005-11-24T11:07:10Z")
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](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 ---
**Author:** ![jmharvey.9956003](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/dbc845/32.png) [@jmharvey.9956003](https://www.ruby-forum.com/u/jmharvey.9956003)\ **Post date:** [November 24, 2005, 1:00pm UTC](https://www.ruby-forum.com/t/multilingual-rails-plugin-update/48752/4 "2005-11-24T13:00:02Z")
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 W. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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](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