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