I’ve had a couple of emails from Tracks users offering to help out with the effort to translate Tracks into other languages, which is fantastic.

What I suggest is that we try to agree on a localisation solution, and then once that is settled, anyone who is skilled in other languages (but not necessarily in Ruby programming) could contribute the necessary text). Perhaps someone with some Rails experience could take a lead and fork Tracks on github, then set up the necessary structure for localisation. Then others can chip in with the actual translations.

I know absolutely nothing about localisation, so if anyone has any experience with different localisation solutions, let us know if you have a favoured library or plugin.

This would be great! There is ticket #220 already with some people who said they like to contribute. I’m willing to help too for Dutch translation…

I don’t have the codebase in front of me atm—is there an i18n library already in? We’re using Globalite, which has generally worked well; Rails Wiki is a good start for general advice, though we found Globalize pretty heavyweight for our needs.

—Thomas.

I would do a german translation. PM me if the structure is there.

Hi Reinier,

Which ticket did you mean? This one ?

—Thomas.

Hello everyone!

My name is Christopher Moura and I’m a software developer from Brazil.
I’m interested in translating Tracks to Portuguese.

I’ve just begin to use Rails, but I’ll search for some l9n solutions that fits well…

See ya!

@thomasn: sorry, I meant #202: http://dev.rousette.org.uk/ticket/202

Ah, thanks Reinier, I’d missed that. I’ve pinged that email address in case s/he is still interested.

FWIW, we looked at most of the i18n libs on the Tracks wiki, including Globalize and ruby-gettext. As Hans says, GetText has the advantage that translation houses are familiar with the whole .po setup—but it’s quite a bit of complexity, and a learning curve for translators who don’t use GetText already. For the last few months we’ve been using Globalite with success, which just has a YAML file with

These can take parameters, and being YAML can include code. In use, you just use key.l—

It’s a plugin - more on googlecode, hosted on GitHub, works with Rails 2.1.

To translate to, say, Dutch, just create nl_NL.yml with appropriate keys. It’s a “Rubyish” solution, if you start using parameters translators will need to use

Using named params makes it easier for translators than the “positional parameters” stuff in gettext.

Works for us - but as ever, YMMV

—Thomas

now to find someone to integrate this in tracks

Hi,

I already did some localisation using gettext. This is work in progress so not everything is localised. The patch is against SVN revision 881 (I need to switch to git). You can download it here: http://www.pentatri.net/tracks-localization/, there’s also .po file for Czech language.

If Kamil Kukura has working code, then that trumps technical arguments about the relative merits of Globalite and GetText I think

I wouldn’t have any time to implement a Globalite patch for at least the next month, so if Kamil has done the heavy lifting then GetText is a great solution. Like Globalite, it stores text outside the DB and ticks the boxes for almost everything in the I18NCompariso.

Go Kamil go!

—Thomas.

Great work. Would be nice to have a patch against the git repository for easy integration

Hi everyone. Seems like an internationalization solution will be part of rails2.2. More info here: http://weblog.rubyonrails.com/2008/7/20/internationalization-in-edge-rails-and-more

Perhaps it’s wise to follow that route?

Polish translator here

Reinier Balt - 20 July 2008 05:15 PM

Hi everyone. Seems like an internationalization solution will be part of rails2.2. More info here: http://weblog.rubyonrails.com/2008/7/20/internationalization-in-edge-rails-and-more

Perhaps it’s wise to follow that route?

We’ve ported a Globalite app to the new I18n code and it works fine. It’s really intended to be just an API though - although we are using en-US.rb and friends as localization files, in the longer term the Globalize/GetText etc teams are working to get their backends working with this new API. So really the questions are:

* What’s already built? (Seems as though GetText may already be done)
* What is easiest for translators? (For professional translators, probably GetText .po / .mo files; if you’re building a UI to allow translation without coding, perhaps Globalize; if translators aren’t scared off by Ruby, perhaps en-US.rb)
* Is database overhead an issue? (Globalize stores all text in the db, but since it’s static it probably gets cached)
* Is memory overhead an issue? (en-US.rb lives entirely in RAM, not sure about the others)

I think all the other checkboxes at the Rails wiki comparison are covered by these options.

One other thing - the ink isn’t quite dry on the Rails 2.2 i18n code, though recent changes seem to cause us no problems.

If there’s an existing, working GetText fork of Tracks I suggest waiting till Rails 2.2 is out and GetText gets updated to the new API. Then update the fork to use the latest GetText. What do others think?

—Thomas.

AFAICS, there is no complete implementation yet. There is code on github by kamk (is that you Kamil?). I hope this can easily be ported to the 2.2 i18n code.

I’d rather go for your suggesting: using rails2.2 and gettext updated to the 2.2 api. I believe the work of kamk is using gettext, right?