Extension:Translate/Usability improvements 2014

Critical bug fixes for Translate extension

 * Public URL: https://www.mediawiki.org/wiki/User:Kunalgrover05/GSoc_Proposal
 * Bugzilla reports: Bug 35489, 51533,  37297 & 39415,  34098, 36298

Name and contact information

 * Name: Kunal Grover
 * Email: kunalgrover05@gmail.com
 * IRC Nick: kunalg on freenode, channels: #mediawiki and #mediawiki-i18n
 * Mediawiki User Profile:Kunalgrover05
 * GitHub page: Github page
 * Timezone:UTC+5:30 (IST - India)
 * Location:New Delhi, India
 * Typical working hours: 10 am - 4 pm and 8 pm - 12 am (IST) (Flexible to ensure deadlines are kept)

Current experience with Translate extension and Mediawiki

 * Setup the development and debug environment for working with Mediawiki core.
 * Installed and configured the Translate extension on my local machine.
 * Basic familiarity with code and coding conventions. Worked towards solving a few bugs.

Project outline and approach
The wiki page translation feature of the Translate extension has become really successful for multi-lingual wikis. It has been implemented in several wikis. There is a list of improvements which needs to be implemented in order to ensure smooth user experience and further expansion. The project aims at implementing all of these and make the Translate extension more efficient and even more amazing :)

Optionally translatable page title when using the Translate extension
The page title while using translate extension is always selected for translation. In a few cases, the title mightn't be relevant and it shouldn't be translated. So, it should be possible to choose whether to translate the page title or not, as it would save translators' time.


 * Requirement: Translating title of a page should be optional and it should be possible to select whether it should be translated while submitting the page for translation.


 * Approach: When submitting a translation, to implement a checkbox for the admin who can select whether to have it for translation or not. By default the checkbox should be unchecked ie title not selected for translation.


 * Comments: I feel it is a relatively easy bug. My current idea is to implement a checkbox on the page for Mark for Translation which I think needs to be implemented in SpecialPageTranslation.php. It can be kept as a Translatable page metadata similar to priority languages list. And only if it is true, the Special:Translate page should display the title for translation.

The page language for multilingual wikis should not be fixed
Currently the Translate extension assumes that the source language of the translation is the same as the content language of the wiki. The user is unable to set the page source language. It makes the extension less useful on wikis with multilingual content where content might be created in any language and the translation tool used to make it available in the other languages of the wiki.


 * Requirement: Ability to change the content language on a per page basis so that content can be created in any language. Translators should be able to see the page in a language of their preference if a translation exists and is reviewed.

The page can then be translated by translators into other languages. The translate extension should allow access to the page in the desired language to edit it.
 * Approach: The feature needs to be implemented in Mediawiki core. Each page should have a language selector which can be stored in the database as a property of the page so that content can be created in any language.


 * Comments: The feature has a dependency on core, so based on Nemo_bis suggestion, I will try to start working on the bug early and try to get it merged. After that, we can ensure its compatibility with the translate extension. I am planning to implement a language selector while creating a page to select the language for the page. After this, the language needs to be a property of the page stored in the database.

Translated page is not updated when moving or deleting translation units

 * If a single translation unit page is deleted, the translated page won't be updated to reflect it. Current work-around is to make a dummy edit on another translation unit page which is very inconvenient.
 * In case of moving a single translation unit page, the change doesn't show the change on either of the translated pages.
 * Example from Bugzilla: In case of translatable page A/zh, A/ja, Translation:A/str1/zh (Translation:A/str1/ja does not exist). If Translation:A/str1/zh is moved to Translation:A/str1/ja, neither A/zh nor A/ja is updated.


 * Requirement: When deleting or moving a page that is a unit in a translatable page, that translated page has to be updated.


 * Approach: The process can be fixed by having a hook to whenever a unit translation page is deleted or moved which runs the fuzzy bot to update the translated page.

Need to figure out if something similar to what happens when a translation is changed is possible or we can have FuzzyBot to update all translations triggered by a DeleteTranslation hook. I am slightly unsure of this and hence find it somewhat challenging.
 * Comments:

Redesign of interface on pages and language bar
The interface on pages has some issues which need to be addressed
 * Language selection takes too much space and is difficult to use in case of many languages.
 * Indicators
 * Completion indicators on page regarding translation being 100% complete and % of completion are unnecessary for most users.
 * Header 'This page is a translated version of...' is obtrusive for readers.
 * Integrating 'Mark page for translation' for administrators as well in language bar in order to reduce space required.
 * Indicator for page having been translated needn't be on top of page.
 * Need to manually add tag to the page.


 * Requirements:
 * Design a less bulky interface for translation and selecting language.
 * Integrate submitting for translation in the language bar.
 * Unnecessary indicators and headers should not be on top of page.


 * Approach:
 * Placement of Headers and Indicators
 * Header 'This page is a translated version of...' to be shifted to bottom of page.
 * Incomplete/Outdated translation indicator to be kept at top of page.
 * Indicators for translation % completion to be either removed or shifted to bottom of page.
 * Required to finalize the design for language bar after discussions. Possible solutions
 * Having just a Translate button(which links to translate the page) with a drop down list which opens up a language selector.
 * Wikipedia style language selection from sidebar.
 * Language bar should be integrated into every page and should contain a few commonly used languages. The list of languages can be accessed similar to the Translate extension language selector. Submitting for translation by clicking on 'Translate' button on language bar.

I personally feel that languages bar should be there in place of Wikipedia style language selection as the Wikipedia like language selection doesn't make a lot of sense for other websites which have other purposes. Having a minimalist languages bar with ability to add translations to the page seems a good idea. I am in favor of the design suggested by Pau Giner.
 * Comments:

The language bar design needs some CSS initially and also some JS for language selector.

Also I think it is not a good idea to display most of the current displayed messages. Only important messages such as translation being incomplete should be displayed. If possible, the translation bar should have a info button to display stuff such as % translation, source language etc.

Changes in Special:AggregateGroups

 * Currently, it is not possible to change an aggregate group description or group name on Special:AggregateGroups. The user has to delete the group and create a new one which is annoying and inefficient.
 * Special:AggregateGroups gives an error as output when permissions are not enough or users not logged in. Should have a read-only output(TODO in SpecialAggregateGroups.php)


 * Requirement:
 * Allow aggregate group name and group description to be changed on Special:AggregateGroups.
 * Make Special:AggregateGroups output a special page when permissions insufficient


 * Approach:
 * In Special:AggregateGroup page, for each group, beside the delete icon, an edit icon to edit the group name and/or description.
 * Display the same special page as output minus the editing and creation part

This is a simple bug in my opinion. These two features need to be implemented importantly. Both of them are to be implemented in SpecialAggregateGroups.php. I will be happy to implement any other features in the page if someone suggests.
 * Comments:

Tentative Timeline
This is an approximate timeline giving sufficient amount of time for each bug. It is flexible depending on the complexities that arise with each bug.

Mentors
Niklas Laxström and Robin are my mentors for this project.

About Me
I am Kunal Grover, from New Delhi, India. I am a second year undergraduate student from Indian Institute of Technology, Madras. I was passionate about programming since my High School. In my college, I got introduced to the world of Free Software which made me really interested to get involved in contributing to the community. I have been involved in a few hackathons held in my college. My enthusiasm in developing Free Software was intensified after interaction with Richard Stallman, the founder of the Free Software movement who was in my college recently for a talk. I started my journey in the world of Free Software by hacking with Mediawiki. I recently got involved in working with the Translate extension and found it to be a very amazing extension in terms of the purpose, the implementation and the TUX interface. I am interested to continue developing for Mediawiki after the end of the project as well.

Participation
The idea of free sharing of knowledge keeps me motivated into working with the Wikimedia community. I always try to stay logged into IRC(Channels #mediawiki, #mediawiki-i18n) during my working hours and will try to contribute back to the community as much as I can. I am regular in replying to emails. Testing and documentation updates will be added to the Wikitech Mail page. All source code written by me will be regularly published. I will keep my mentors updated about the progress through E-mails. All discussions regarding design and implementation will be public.

Past Experience in Programming and Open Source

 * I have been hacking with Mediawiki core for sometime now. I have worked towards solving bugs: Bug:17496 Bug:26032
 * I am currently working to implement a Special page for core listing Tracking categories. Bug:60333
 * I recently got involved in the Translate extension. I submitted a patch for Bug:57514

I have been involved in a lot of projects all of which are present on my Github page. Some of my favorite ones :) I was part of a Robotics team representing my college at a Nation-wide level. My job in the team was to develop and implement algorithms for the robots.
 * Chat-site: A P2P chat website using Node.js
 * Virtual mouse: Mouse pointer control on screen using camera.
 * Gesture recognition: Detect the number of fingers using camera tracking.
 * Atmega Motor controller: A electronics-cum programming project aimed at developing a reliable motor control system which can be implemented in the industry for speed as well as position control.

Microtasks

 * Patch for Bug:57514 in Extension:Translate.
 * Wrote Special:TrackingCategories to list tracking categories in Mediawiki.Bug:60333