User:Grv99/gsoc2013

Hi!

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

Updates on this project

Updates and the current status of this project - jQuery.IME extensions' status.

jQuery.IME extensions for Firefox and Chrome

• Public URL: http://www.mediawiki.org/wiki/User:Grv99
• Bugzilla report: https://bugzilla.wikimedia.org/show_bug.cgi?id=46647
• Announcement: http://lists.wikimedia.org/pipermail/wikitech-l/2013-April/068474.html

Synopsis

Tracked in Phabricator
Task T48647

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.

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.

Mentors: Santhosh Thottingal and Amir E. Aharoni.

Deliverables

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:

• Allow the user to selectively choose, when to load-and-call (or disable) the IME, for ex, by putting some triggers (ctrl-ctrl or ctrl+shift+ <some key>) to activate/deactivate the IME on any text input field, rather than just adding it to every input area on page.(this may not require much time, but still I am keeping this in 'If time permits' section to focus on creating the main app first)
• Make the on-demand injection intelligent, by

• remembering the languages used on a site
• automatically injecting the languages based on the content (language) of the webpage

and then listing these in the top half (suggested/ most used) part of the IME's menu.(again this may not require much time, but still I am keeping it in this section to focus on creating the main app first)

• 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.

Project schedule

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. Also, because its new and a potential future requirement. Hence, I want to improve it as much as I can.
I have good understanding of Java, PHP, MySQL (,postgreSQL, mongoDB), python, javascript ,jQuery ,AJAX, HTML/CSS/XML and also have past experience in making browser extensions. These are some of my related work experiences - related work experiences.

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 mentors can keep track of the updates and give feedbacks/reviews.
I will be online on GTalk and IRC, and will be cordially communicating with the community and my mentors, throughout the project.

Past open source experience

No. I had no experience in working for an open source community project, till now. But, last month, 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). The code and wikicards chrome extension is available at https://github.com/grv99/wikicards.

Any other info

/** to be removed... donot consider this as part of proposal. will be removed before final submission. Thanks Yuvipanda for suggesting this edit. See the discussion page.
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.

• I plan to make frequent submissions for extension review, to ensure I am following the extension policies at every step. This will also make it easier to debug any failed attempt of extension submission.

• No. of submissions I am planning to make:
  

Within first 5 days I will make a sample submission for both the browsers.

And then, every 10 days, I will make a full review 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 alternately, preliminary (relatively quicker) 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.

• In addition to this, I will be using https://groups.google.com/a/chromium.org/forum/#!forum/chromium-extensions (for chrome) and #amo-editors irc channel (for firefox) for any discussions regarding the review of my submissions during the project.

• 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 or mail me at grviitrgmail.com with "gsoc" as subject.