I thought I’d share my tips on implementation as there seem to be a few gotchas. For me, load_path didn’t quite work as intended, so I came up with this:

This goes in environment.rb after the Rails Initializer, and loads in all the translation files I have in /lib/locale. Once loaded, you can set the locale you want in a set_locale method as before_filter in ApplicationController and you’re set. You can now use I18n.t(‘key’) in views and so on

Some tips and warnings, however.

• Don’t reuse phrases. What’s reusable in one language may not be in another.
• Namespace. I made the fatal mistake of not namespacing enough- I would recommend models, views and controllers as your bases.
• Where possible, keep HTML out of your YAML. It makes it easier to read and keeps formatting and style to views instead of localisation material.

And don’t lose hope. It took me a solid day sat down working through the app to get everything sorted out for Nexus, but it’s very much worth it! Now the next challenge-finding translators…

Rails 2.2 comes with I18n built in, so I’ve been using that. It’s a slow process, turning every string into it’s own categorised, indexed line. It’s all in YAML though, so I can easily work on it freehand without needing to worry about complex systems for storage. The one downside is I get to reload my development server to see changes to the pages, but that’s not too big an issue. It’s easy to use and works like a charm, so it fits the bill for my purposes.

Also, Rails 2.2 is thread safe! I’m interested to see what this does performance-wise on Passenger. Load on my server isn’t a problem but memory is my main concern- Passenger with Ruby Enterprise Edition works great by sharing common elements in memory to reduce usage, but thread safe Rails means I should be able to get away with running fewer servers in the first place. I’ll spend some time with JMeter and New Relic RPM at some point to see what the real-world gains are.

My next challenge is going to be creating a decent looking fittings/kill display interface. I’ve learned a lot working on the TacMap, and have some ideas for how I’m going to display fittings. I don’t think I’ll use the ingame fittings screen picture with overlays; it’s overly complex and imo there’s better ways to show fittings. Considering one of the main goals with Nexus is high performance and given the slashdot-effect style killboard spammings that occur whenever a big kill gets scored, I’d like to try and keep the SQL loading down to a minimum.

I’m also trying to work out what the best way of handling caching will be. My whole configuration system thus far is getting looked at sternly- I’m using Configatron, but think I need something a little beefier than that which supports some kind of webinterface for editing configuration values. Still, that’s a problem for another day.

On the EVE front, Shrike lost his titan. Again. In exactly the same way (cloaked off a gate). Yay.