Archive for the ‘Python’ Category

Using the myGengo Translation API with Python

Tuesday, May 31st, 2011

For those who haven’t heard the news, Google has deprecated a slew of their APIs, leaving many developers and services in a bit of a pinch. While there’s admittedly still time for developers to transition, it’s a good time to start considering alternatives. In my opinion, it’s probably a good idea to choose an alternative that has the technology in question as a core competency, otherwise you’re much more liable to have your provider pull the rug out from underneath you.

With that said, many engineers are hit particularly hard by the deprecation of the Translation API that Google has so generously offered up to this point, and desire a solid alternative. While there are other machine translation APIs out there, I wanted to take a moment to show more developers how integrating with the myGengo API can get them the best of both worlds.

A Polite Heads Up
As of May 31, 2011 I am currently working with myGengo to further develop their translation services. However, this post represents my own thoughts and opinions, and in no way represents myGengo as a company. myGengo offers both free machine translation and paid human translation under one API, and is currently offering $25 in free API credits to all new developers interested in trying it out. I simply want to show other developers that this is very easy to use.

Getting Started with the myGengo API

This takes all of 5 minutes to do, but it’s required before you can start getting things translated. A full rundown is available, which includes details on using the API Sandbox for extensive testing. For the code below, we’re going to work on the normal account.

A Basic Example

The myGengo API is pretty simple to use, but the authentication and signing can be annoying to do at first (like many other APIs). To ease this, there’s a few client libraries you can use – the one I advocate using (and to be fair, I also wrote it) is the mygengo-python library, which you just installed. With this it becomes incredibly easy to start making calls and submitting things for translation:

The above script should print out 25.00 if you signed up with myGengo using that link above.

Actually Translating Text

Extending the above bit of code to actually translate some text is very simple – the thing to realize up front is that myGengo works on a system of tiers, with said tiers being machine, standard, pro, and ultra. These dictate the type of translation you’ll get back. Machine translations are the fastest and free, but least accurate; the latter three are all tiers of human translation, and their rates vary accordingly (see the website for current rates).

For the example below, we’re going to just use machine translation, since it’s an effective 1:1 replacement for Google’s APIs. A great feature of the myGengo API is that you can upgrade to a human translation whenever you want; while you’re waiting for a human to translate your job, myGengo still returns the machine translation for any possible intermediary needs.

It’s your responsibility to determine what level you need – if you’re translating something to be published in another country, for instance, human translation will inevitably work better since a native translator understands the cultural aspects that a machine won’t.

This really couldn’t be more straight-forward. We’ve just requested our text be translated from English to Japanese by a machine, and gotten our results instantly. This is only the tip of the iceberg, too – if you have multiple things you need translated, you can actually bundle them all up and post them all at once (see this example in the mygengo-python repository).

Taking it One Step Further!

Remember the “human translation is more accurate” point I noted above? Well, it hasn’t changed in the last paragraph or two, so let’s see how we could integrate this into a web application. The problem with human translation has historically been the human factor itself; it’s slower because it has to pass through a person or two. myGengo has gone a long way in alleviating this pain point, and their API is no exception: you can register a callback url to have a job POSTed back to when it’s been completed by a human translator.

This adds another field or two to the translation API call above, but it’s overall nothing too new:

All we’ve done here is change the level we want, to use a human (standard level), and supplied a callback url to post the job to once it’s completed. As you can see, the response from our submission includes a free machine translation to use in the interim, so you’re not left completely high and dry. You can also specify a comment for the translator (e.g, if there’s some context that should be taken into account).

Now we need a view to handle the job being sent back to us when it’s completed. Being a python-focused article, we’ll use Django as our framework of choice below, but this should be fairly portable to any framework in general. I leave the routing up to the reader, as it’s largely basic Django knowledge anyway:

Now, wasn’t that easy? Human translations with myGengo are pretty fast, and you get the machine translation for free – it makes for a very bulletproof approach if you decide to use it.

Room for Improvement?

mygengo-python is open source and fork-able over on GitHub. I’m the chief maintainer, and love seeing pull requests and ideas for new features. If you think something could be made better (or is lacking completely), don’t hesitate to get in touch!

The Everlasting Fight To Expand My Metaphorical Sight (Part 2)

Monday, February 7th, 2011

Well, time certainly flies by quickly. Since the last entry in this little mini-series, I’ve globe-trotted some more (London, New Jersey, New York City, DC, San Francisco, Seattle… San Francisco again…) and released some new projects that’ve been in the pipeline for some time. What’s next?

On Traveling

London was a very, very interesting experience. I had the fun experience of being stuck there well past my intended departure date due to a massive snow storm that shut most of Europe down; London Heathrow, why you refused the help of the Army to clear away snow is simply beyond me. That said, the city of London itself is a nice place, one that I could see myself spending more time in. The surrounding area is equally cool and worth checking out! Yet again this was a country where public transportation is pretty slick. Notice a recurring theme here?

The rest of my travels have been pretty US-centric; nothing noteworthy, sans shooting up to Seattle for a week to visit with my younger brother. Now, enough of all this personal drivel, there’s work to discuss.

ProgProfessor

I think kids should be taught programming at a young age, but with absolutely no initial focus on mathematics. People can fight it all they want, but math doesn’t interest kids, and a direct approach to trying to make it interesting so more come into the subject field won’t work. Programming, if taught with a creative and artistic edge, is well suited to fix this problem.

At least, that’s my theory, and the entire line of reason behind my efforts with ProgProfessor. This’ll be followed up soon with a few other new projects, stay tuned!

FeedBackBar

When I got back into San Francisco, I met up with my good friend Brandon Leonardo. Awhile back he had conceived of this pretty cool idea to distribute a “feedback bar” type widget, where any site could sign up, throw some code on, and get immediate feedback from users. It’s an idea somewhat in the same realm as UserVoice or Get Satisfaction, but much more stripped down and to the point. I thought it was pretty cool, and we managed to hack it out in a night.

FeedBackBar is free and quick to implement. Check it out and let us know what you think!

pyGengo – Pythonic myGengo Translation API Library

The other notable release I’ve thrown out in the past month is pyGengo, a library that wraps the myGengo API. myGengo is a cool service that offers an easy, reliable way to get text translated into other languages by other humans. Machine translation alone can be notoriously incorrect, so having a human back it up is quite the awesome technique to have up your sleeve.

pyGengo is fully documented and has a test suite to boot. Issues can be filed on the Github Issue Tracker, give it a shot and let me know what you think!

So… What’s Next?

I’ve got a few projects coming up that should be pretty significant releases, so at the moment I’m working towards those. You should follow me on Twitter to know when they’re released!

Emulating Ruby’s “method_missing” in Python

Tuesday, November 2nd, 2010

I don’t pretend to be a huge fan of Ruby. That said, I can respect when a language has a feature that’s pretty damn neat and useful. For the uninformed, method_missing in Ruby is something like the following:

Obviously, this is a trick that should be used with caution. It can make for some unmaintainable code, as a class with many methods could get difficult to trace through and figure out just what the hell is happening. It can be put to good use, though – take an API wrapper, for instance. What’s it consist of? Generally, nothing more than the same function calls made over and over to various service endpoints.

Cool, let’s use this in Python!

I recently rewrote Twython to support OAuth authentication with Twitter (as of Twython 1.3). It ships with an example Django application to get people up and running quickly, and the adoption has been pretty awesome so far.

The funny thing about the Twython 1.3.0 release is that it was largely a rewrite of the entire library. It had become somewhat unwieldy, some odd two thousand lines of code with each API endpoint getting its own method definition. The only differing aspect of these calls is the endpoint URL itself. This is a perfect case for a method_missing setup – let’s catch the calls to non-existent methods, and grab them out of a dictionary mapping to every endpoint.

The source above is fairly well commented, but feel free to ask in the comments if you need further explanation. This resulted in a much more maintainable version of Twython – for each function that’s listed in a hash table, we can now just take any named parameter and url-encode/combine it. This makes Twython pretty API-change agnostic of the entire Twitter API. Pretty awesome sauce, no?

Rendering emails with Django templates

Tuesday, July 13th, 2010

I talk a lot about Javascript on this blog: client-side, server-side, wherever the language can be used. It’s not the only language I enjoy working in, though; Python has always had a bit of a soft spot with me, and with that comes some inevitable Django love.

I use Django for a lot of my server side tasks where I don’t feel I can safely use something like Node.js. On top of being battle tested beyond belief, it’s a veritable bag of magic tricks just waiting to be used. Take this one case I ran into recently: I’m building a service (stealth at the moment, stay tuned) that has to do something as simple as send out an email when a new user signs up.

Now, that email should ideally contain a few things. Let’s assume that, for a basic example, we’re gonna just include their username, a brand new password, and their full name (how we’ll use each of these is shown in depth below). Django makes sending mail pretty easy, using the send_mail function:

That’s all well and good, but what if we want to do more than just a simple string for our body message? Ideally, we should be able to treat this like any other Django template. In practice, this is actually incredibly easy (and fun).

The code should be fairly well documented, but for those who’d like a little more verbose of a walkthrough, it’s pretty simple: instead of passing in a string, load up a template and pass it a rendering context. See, what got me the first time around is that the render method of get_template needs a Template Context to do the dirty work, not a standard dict.

With that, here’s an example of an email template – it’s literally just a Django template, but ready for all your email attributes.

Django’s templating system is incredibly flexible, and can easily be used for more than just your generic views. If you have any questions or suggestions, feel free to throw them in the comments!