Developing Translation Tools for BuildmLearn : Introduction

[Prasoon Shukla]

Hi, I'm Prasoon, and I'd like to formally introduce myself to the community. (I know you guys are busy so I won't bore you too much with the details. Here are few things that might matter though)

The OSS contributions:

I've worked as a student under GSoC 2013 under SymPy [1] and several bugfixes as well

I've made a few patches to mercurial, out of which one got merged [2]

I've got a few patches merged into simplecv [3], an unmerged patch to django [4], one merged patch in django-browserid [5], and two patches in sugarlabs [6].

Other work :

I've worked a lot with Python/Django and developed a few applications using it for my college's intranet portal. However, I cannot share their code since it technically belongs to the institute. But, you can take a look at out page where there are a bunch of photos of our work (we're a group!). Aside from that, I did a brief stint with PHP as well working for a startup. 

Hopefully, this convinces the core devs that I am competent enough to take on the project.

Now, to talk about the project. The project description seems simple enough - implementing a standard UI for the users that would work off of Google/Bing translations APIs to provide translation. That said, I haven't explored the concrete details as of yet. So, I'll explore the possible ways ahead and hopefully come up with an application in a few days. Once the first draft of the application is done, I'll post the link on this thread [asking for feedback, of course :) ]

Anyway, I hope this was a good introduction. See you around guys :)

Links:

[1] : Majority of the code, official link some important patches: 1, 2, 3, 4

[2] : One, Two, Three, Merged Patch

[3] : One, Two, Three, Four

[4] : Patch

[5] : Patch

[6] : P1, P2

[Prasoon Shukla]

Sorry! Correction on that third line - *and made several bugfixes* instead of "and several bugfixes".

[Pankaj Nathani]

Thanks Prasoon for your introduction and the links :)

Read this once your proposal is ready: http://goo.gl/jCEcEv

[Prasoon Shukla]

Hi again.

So, I explored the idea some more and now, I've decided on a basic architecture to follow for the project. As I see it, the project will constitute of three major components:

1. A UI for interfacing with the user. The UI will be, by the very nature of the project, quite simple - a file upload widget for accepting a standard csv/xlsx/OpenDocumentFormat spreadsheet(ods files). This part will, IMO, be relatively easy to develop.

2. A Python based processing backend to process the uploaded file, connect to the Google/Bing APIs, get the translated result, process it to generate an output file (we can allow the user to pick the output format). These operations will rely on third party python libraries (xlrd, xlwt, xlutils, odfpy/simple-odspy) to parse the data in spreadsheets and write to the output file. This component will be moderately time consuming, primarily because of the inclusion of the third party packages and the support for several file formats.

3. The third major component will be a link that connects the UI with the Python backend. This, in my opinion, will be relatively harder to develop among the all three components. Implementation strategy however, is straightforward. The two components will interact via interprocess communication (IPC). Now, if we would have been on linux, I wouldn't need to think twice about the IPC backend - we'd just use DBus. Unfortunately, we can't use DBus. Also, we can't use windows specific IPC libs either - since, as I understand, there's talk about porting the BuildmLearn toolkit to Linux (yay!). So, I explored this topic for a while and I've decided to go with zeromq. There are a few more things about zeromq that I'll about in the proposal.

That's it, I think. Those three components will form the application core and we can add bells and trinkets on top as we like - that's the good thing about using IPC, actually. Everything is loosely coupled and highly modularised so making changes-to/addition-of new components becomes very easy.

Anyway, that's what I've what I've come up with. I hope that with some refinement, we can reach a sturdy design and implementation strategy for this project. One more thing; since my application will contain a lot of the ideas already mentioned above, I think it should be fine to copy some of the text verbatim from this post to the application :) 

I'll post the first draft of the application soon.

Comments are welcome!

[Pankaj Nathani]

Hi Prasoon,

It seems you are assuming having a Python backend to support the interface of the tool. To clarify, the tool is a local Python utility.. which would of course use various REST APIs like Google, Bing, etc. for translation.. but there is no backend as such except these web services. 

So the file doesn't need to be uploaded.. it would be processed locally and the content would be translated using REST APIs. You may want to modify your approach accordingly. 

Anyway, that's what I've what I've come up with. I hope that with some refinement, we can reach a sturdy design and implementation strategy for this project. One more thing; since my application will contain a lot of the ideas already mentioned above, I think it should be fine to copy some of the text verbatim from this post to the application :) 
I'll post the first draft of the application soon.

Great, make sure you follow the instructions here: https://groups.google.com/d/msg/buildmlearn/droaQTxy7aU/L1aQ_aJYxSUJ

That's the way we're processing draft proposals. 

[Prasoon Shukla]

> So the file doesn't need to be uploaded.

Of course. I think I gave the wrong impression by using the words "upload widget". What I really meant was a file select widget.

Anyway, I'm halfway through my application. I'll post it tomorrow.