You can find it here, including a complete tutorial for consuming the service using the restlet framework. Even if your language of choice is not java, it shouldn't be very difficult for you to write your own consumer using the the documentation I've provided.
In brief, it's an asynchronous RESTful service that allows you to create a translation job by posting to a specific URL, and if the job is accepted it returns you a 201 Created status and a Location header telling you where you can pick up the results when processing has completed. Then it's just a simple task of polling the result URL (a job resource). The job resouce will return an HTTP 102 Processing status until it completes, at which point you'll then get a 200 Okay, and your results in UTF-8 encoded text/plain.
I posted about my service on the restlet list several days ago, in an effort to get some feedback on what I might have done better. The biggest point of contention has been the jobs resource url that you post to when you create a job. I chose the first option following the guidelines in the RWS book.
The other minor point of contention is my choice to use a 102 status to indicate that a job is still being processed. At least one person felt that a 202 Accepted would be more appropriate. Personally I think that a 102 Processing status is a clearer way to express the resource state, if your not opposed to using the WEBDAV extended status codes.
Beyond stress testing this service, I don't intend to become a major service provider so I'll publish the source code to my translate restlet backend eventually. The last two restlet framework releases, 1.0.2 and 1.0.3, both have problems with the servlet adapter. This piece of the framework allows you to run a restlet within any web container. Because of this I've had to code in some workarounds that I'd rather not publish. Hopefully these issues will be cleared up in the 1.0.4 release.