User:Grv99

Hi!
 * This is my project proposal for Google Summer of Code 2013.

 Note: If you are here for WikIcards (my previous project for gsoc2013), please click here.

Identity
Name: Gaurav Chawla Email: grviitr@gmail.com Project title: jQuery.IME extensions for Firefox and Chrome

Contact/working info
Timezone: Indian Standard Time (UTC+5:30 hours) Typical working hours: 10:00am to 2:00am (IST) (flexible) IRC or IM networks/handle(s): grv99

Project summary
jQuery.IME provides a multilingual input method editor in around 150 (and counting..) languages.It is the jQuery version of the input method tool, Narayam, that powers nearly all the input boxes on wikipedia. Providing it as a complete offline solution, in the form of browser extensions will enable its usage on any website across the web and will attract more developers and users to this awesome, small but powerful open source IME. It will be ported completely to the client-side and hence, it will not have to be pulled from Wikimedia servers every time, reducing the load on servers.

In this project, I will be porting jQuery.IME to Mozilla Firefox and Google Chrome (two of the major browsers) for complete offline access implementing on-demand injection and automatic updates. It is filed in bugzilla at.

The main purpose of this WMF project is to provide language technology tools to wider audience outside the Wikimedia universe. And providing browser extensions will strongly support its motive.

Required deliverables

 * Fragment the code and identify the parts to be loaded dynamically and others that should always be loaded.
 * Implement the basic UI and must have parts(that will always be loaded).
 * Implement on-demand-loading of only the required parts (ie. the different languages, loaded only when needed)
 * Make a handler to convert the updates made in the main source code to the browser extension version.
 * Automize this process of converting as much as possible, with just some buttons to be pressed after each update.
 * Will develop a script to test the extension updates for different browser versions after any new updates are made and rollback if tests fail, (there are tests already present to check the consistency of updates of core jQuery.IME code, but I will extend it to include the checks for the extensions too).
 * Create full documentation.

If time permits
If time permits, I will like to add these features, in the same order as listed:
 * Internationalize the app for publishing in various languages, to increase its rank in respective region's web stores (will need community support for this)
 * Generalise the handler layer (the layer between jQuery.IME and browser), to make it use only the most common browser APIs, and hence make it possible to port to any of the major browsers (IE, safari, opera), with minimal change in the code. //for different browsers.
 * Port it to other major browsers too, viz. Internet Explorer, Safari and Opera. (this would be easier after handler generalisation)
 * Try for any UI improvements possible that can make it even easier and powerful to use.

Post GSOC

 * Long term support for maintenance of the extensions and updates, and documentation.
 * All the remaining deliverables from "if time permits" section.

Community bonding Period

 * Identify the parts to be loaded dynamically and others that should always be loaded.
 * Make sample submissions (2 or 3 each) to both the browsers' extension web stores (See "Any other info" section below)

Work Period
Milestones (These are the days I will need for both the extensions combined)
 * 1) Implement the basic UI and must have parts (12 days)
 * 2) Implement on-demand-loading of only the required parts (12 days)
 * 3) Make an update handler (12 days)
 * 4) Automize this process of updating as much as possible (7 days)
 * 5) Develop scripts for testing compatibility/consistency of updates (12 days)
 * 6) Documentation (5 days)

My holidays are beginning from 15th May, so I will start the work that time itself. So that, for the midterm evaluation (on 28th July), I can give the first three (or maybe 4) deliverables. And rest all will be for the second phase.

About you
I am an undergraduate student at IIT Roorkee, India. I am a social, eager kind of student, who loves to keep things as simple as possible. I code in my free time. The reason I chose this project is that its unique and very different from other Wikimedia projects. (that fascinates me!) Also, because its new and a potential future requirement. Hence, I want to improve it as much as I can. I have all the required skills for this project and also have past experience in making browser extensions.

Participation
I plan to make a more comprehensive list of short steps, maybe 20-25 steps for the whole project, and keep it updated on my user sub-page. I will use github to maintain my code, so that my mentor can keep track of the updates and give feedbacks/reviews. I will be online on GTalk and IRC, and will be cordially communicating to the community and my mentor, throughout the project.

Past open source experience
No. I had no experience in working for an open source community project, till now. But, in last two weeks, while I was proposing my previous GSOC project (WikIcards), I got the taste of FOSS development (long useful discussions, feedbacks, willing contributers, and more). I have made the wikIcard extension, its still work in progress, and needs code review and clean up (and documentation as well).

Any other info

 * One of the main reasons of delays in such projects (extension development) are delays due to extension review process. To avoid the known delays of review process,I will do both the browsers in parallel. This will allow me to submit the extension for one browser and without waiting for the review to be completed, I can continue my work on the other browser, and after first one gets its review completed, I will submit this browser's extn for review, and continue with other browser's extension.


 * The scripts used by google for reviewing the extensions are not documented anywhere, for security reasons. So, I will follow all their extension policies to the fullest at every step of my development and then, debug the extension manually and only then submit it for review. This will increase the success rate of my submissions.


 * No. of submissions I am planning to make:
 * Within first 5 days I will make a sample submission for both the browsers, just to get the rough estimate of the time it takes for the app to get reviewed. I may use three different accounts for both (browsers), to ensure results' consistency.
 * And then, every 10 days, I will make a submission, until the extension gets fully ported. The first real review will be a full review(takes more time), and subsequent updates may be submitted as alternatively, preliminary (relatively quick) and full review.
 * I will follow this pattern while submitting the extension for reviews:
 * full, preliminary, preliminary, full, preliminary, preliminary, full,...


 * For firefox, I will use their offline Add-on Validator to check the extension before staging for review.
 * For chrome, manual debugging will be done.


 * I expect to give more priority and time to chrome, as their review process is slower (since,its bit more comprehensive) than firefox.


 * To make it more approachable, I will support only two versions of each browser, with highest market share,
 * For chrome, two major versions 24.0 and 25.0 will be supported.
 * For firefox, 19.0 and 18.0 will be supported.


 * PS: This won't mean that the extensions will not run on other versions, actually they will, but, they will not be tested for compatibility (as part of GSOC project).

Contact
Feel free to start a discussion on my talk page (|talk) or mail me at grviitr@gmail.com with "gsoc" as subject.

Let's be friends on Facebook.