Extension:Translate/Usability improvements 2014
 | This page is obsolete. It is being retained for archival purposes. It may document extensions or features that are obsolete and/or no longer supported. Do not rely on any information on this page. This was a Google Summer of Code/2014 project/proposal. |
Usability improvements for the Translate extension[edit]
- Public URL
- https://www.mediawiki.org/wiki/User:Kunalgrover05/GSoc_Proposal
- Bugzilla reports
- Bug 35489, 51533, 37297 & 39415, 34098, 36298
Name and contact information[edit]
- Name
- Kunal Grover
- 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[edit]
- 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[edit]
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 changes and features which need to be implemented in order to make user experience smoother and to increase use cases. These bugs range from moderate to hard level, and most of them have a high importance in terms of inconvenience caused to the user. The project aims at fixing a selection of these bugs and make the Translate extension more efficient and even more amazing :).
After discussions with my mentors, we decided to split the project into 3 major goals:
1 - Add features for user and translation administrator efficiency. One of the feature improvements is for MediaWiki core.
- Add an option to set translation of the page title to optional. Currently it is always part of the regular messages of a message group. (#Optionally translatable page title when using the Translate extension.)
- Add a page content language selector when marking a page for translation, to allow translations from any source language to other language irrespective, of the content language of a wiki. (#The page language for of translatable pages should not be fixed.)
- Make it possible to change group label and group description on Special:AggregateGroups.(#Changes in Special:AggregateGroups)
- Create a read-only version of Special:AggregateGroups to allow interested non-administrator parties to view the configuration. (#Changes in Special:AggregateGroups.)
2 - Fix bugs that may cause confusion for translators.
- A translated page is not updated when translation units are moved or deleted. (#Translated page is not updated when moving or deleting translation units.)
3 - Usability improvements in the interface of translatable page.
- Redesign the interface of translatable pages to reduce clutter and improve usability. (#Redesign of interface on translatable pages and language bar.)
Optionally translatable page title when using the Translate extension[edit]
The page title while using translate extension is always selected for translation. Often, the title may not be relevant and there is no need for it be translatable. 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
- Add a checkbox when marking a page for translation, so that the translation administrator can select whether to have it for translation or not. By default the checkbox should be checked, i.e. title 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 of translatable pages should not be fixed[edit]
- See also User:SPQRobin/Page language.
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 can't be directly 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.
- 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.
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.
- 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[edit]
- 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 isn't shown 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.
- Comments
We can achieve something similar to what happens when a translation is changed if possible. Another approach is we can have FuzzyBot to update all translations triggered by a DeleteTranslation hook. I find this bug somewhat complex and am planning to give it some good amount of time.
Redesign of interface on translatable pages and language bar[edit]
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 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 <language /> 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 button which opens up a language selector.
- Wikipedia style language selection from sidebar. It has been successfully incorporated on all Wikipedia pages.
- 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.
- Comments
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 are meant for 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. Also, the languages by default in the language bar should be commonly used languages by the user if possible. The language bar redesign needs to be implemented at ext.translate.css and the language bar output needs to be changed at tag/PageTranslationHooks.php where it is implemented as a hook.
The language bar design needs some CSS initially and also some JavaScript for the 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[edit]
- 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
- Comments
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.
Project output[edit]
The project output would be to make the Translate extension more convenient to use and improving the features in the extension. The project involves the following sub-tasks:
- Discuss design
Discussions regarding how the features should be implemented such that it is comfortable and intuitive for the user. Also addition of ideas that seem possible and relevant.
- Implementation features
- (Priority-Highest)
For these feature improvements, currently there are some ideas about how to proceed and implement them. After implementation, depending on the feedback, there can be required modifications or improvements. One of the improvements has a dependency on MediaWiki core and hence it is an important task to make the fix for the core merged. Another aim of the sub-task is to restructure the Special:AggregateGroups page and add a few improvements to it.
- Fix bugs
- (Priority-High)
This is a bug that limits the Translate extension. There is a clear aim regarding how things should be as an outcome of the bug fix.
- Redesign UI translatable pages
- (Priority-Medium)
This part of the project aims at revamping the interface for the Translate extension to make it less cluttered and easier to use. The tasks involved will be implementation of the preliminary discussed design and modifications based on feedback.
Tentative timeline[edit]
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.
| From-To Date | Timeline |
|---|---|
| Apr 22 - May 18 | Reading documentation and getting familiar with all the codes. Discussions for finalizing design for language bar for pages and for page content language selector.
Discussions for feature requirements for Special:AggregateGroups. Ideating and discussing implementation for updating Translatable page on deletion of a translate unit page. |
| May 19 | Official GSoC coding period begins. |
| May 19 - June 9 (3 weeks) | Starting off with solving lesser challenging bugs:
Implementing optional title translation for pages Working to make Special:AggregateGroups more featured. |
| June 9 - June 23 (2 weeks) | Implement language selector for core and get it merged with core. |
| June 24 | Midterm Evaluation |
| June 24 - July 12 (2.5 weeks) | Checking language selector work-ability with Translate extension.
Make translation page update on page moves of translatable units. |
| July 13 - July 27 (2 weeks) | Implementing language bar and translate extension interface for pages. |
| July 28 - August 12 (2 weeks) | University starts-Work hours shifted to evening and night
Fixing any TODOs Final phase of the project-documentation and fixing any bugs reported. |
| August 12 - August 18 | Pencils down period. |
| August 22 | Submitting the project for final evaluation. |
Mentors[edit]
Robin and Siebrand are my mentors for this project.
About Me[edit]
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[edit]
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 the mailing list. 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[edit]
- I was always enthusiastic about programming and Mediawiki was my entry into the work of FOSS
- I have been hacking with Mediawiki core for sometime now. I have worked towards solving bugs: Bug:17496 Bug:26032
- I worked 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 interesting projects all of which are present on my Github page. Some of my favorite ones :)
- Chat-site: A P2P chat website built using Node.js and Socket.io
- Virtual mouse: Mouse pointer control on computer screen using computer vision using OpenCV libraries.
- Othello bot: Bot created by me implementing Artificial Intelligence to play othello.
- Gesture recognition: Detect simple hand gestures using camera tracking. Implemented using MATLAB Image Processing toolbox.
- Atmega Motor controller: An electronics-cum programming project aimed at developing a reliable DC motor control system which can be implemented in the industry for precision speed as well as position control.
I was member of a Robotics team representing my college at a Nation-wide robotics competition ABU Robocon. My job in the team was to develop and implement algorithms for the robots to interface them with the physical world.