It has been one great and challenging ride through the GSoC period through which I got to meet some eminent coders and had a wonderful experience working with the Wikimedia team, who were extremely helpful and responsive at all times. Not to mention the immense amount of learning that had happened over the span of three months, it was indeed a pleasure working on some major issues and resolving it with the help of the Mediawiki community. I am sure to continue contributions to the open source world and The Wikimedia foundation in the coming future.
The project that I had taken initiative to do was based on the general improvement and enhancement of Wikisource and the ProofreadPage extension that was intended to allow easy comparison of text to the original and allow rendering of a text in several ways without duplicating data. The three tasks that I had completed over this span is:
- Creation of an auto-validation privilege – The task was to implement a privilege that was exclusively accessible only by the admins. This allows them to validate the pages they have proofread (which was not possible, if not for this right). This right proves useful for those running small wikis, as they need not call a third person or someone not related to the topic to validate the proofread page, they can now do the validation by themselves if they possess this right. The task involved the general changes in the extension, implementing some tests and then its documentation all of which can be found in this merged Gerrit-task.
- Migration of ProofreadPage zoom feature to OOjs – Here the job was to completely port the zoom feature implemented in jQuery to OOjs. At first, the task seemed a little challenging, as there were quite some lines of code to be ported and the zoom feature itself was a little complicated. But with the advantage of a well-documented code and the help of my mentor, I was sailing through the task. After the code was wholly converted to OOjs, the code was submitted for review and the necessary changes were made as according to the requirements. The change is yet to be merged as the DOM added is not yet updated to the Gerrit-change.
Last week I had added improvements to the previous patchset, still it wasn’t at its 100 percent, still some bugs and more functions to better and constructors to convert to OOjs. Since its working is quite complicated, changing its dependencies and converting the code was not that an easy task. Took me quite a while to even figure out the processes the functions do.
With the third patchset it was a green signal from my mentor as the code was moving forward but still not yet good to go as a working zoom widget, the hard part was finding documentations and similar widgets that has kind of the same working. Though I found one, it was pretty basic so I had to code from scratch mostly myself hence the outcome had some bugs and now trying to fix that.
Some errors still seems to persist related to the widget, trying to figure that out now. After its completion, will move on to the next task that will be Load a higher resolution scan image when zooming in. This issue is also related to Page: pages editing form, hence it would be better to convert the code first and then make changes to support a better quality image while zooming in.
Glad that I made through the first evaluation, it was time to move on to a different task. Now that the Index: pages editing form has been converted to OOjs UI and corresponding improvements have been made on the patchset to make the code shorter and more neater the change was merged the last week and the task was closed.
The next one was also based on OOjs UI, but what the difference this time is that I am now dealing with a feature implemented in JQuery rather than PHP. It took me a while to learn the methods that should be used to code the Button Widget into the file. I was good to go now and I had started off with the coding, so that I could finish this task within a week or two and move on to the remaining two.
I am trying to improve the pace of my coding, since the task is bigger and I have been playing around with OOjs for quite some time now and am good to go with it.
With the finishing of the patch that was set for the task T153120 , I had uploaded the change for review. Though the basic UI, was good to go, some issues still persisted. The first one was the width of the form, it was too wide for bigger screens, the labels were actually far off from the text boxes. But this was easily solved using a ‘max-width’ in CSS.
The next one I dealt with was the issue of empty help widgets. The reviewer and my mentor Thomas, suggested to work the help widgets with infusion, since the process of infusion was very well documented by Mediawiki, coding it in was not that hard. Now, some minor beautification and more love was required for the JS side of the code.
As the minor fixes won’t require much time, I hope to close the task as soon as possible and get going with the next one.
With the completion of my very first task for this project, gladly I moved on to the second one. This dealt with Object Oriented JS, as I haven’t coded using that before, I took some time to read the documentation and understanding its usages. Now that I was good to go, I analyzed the things I should be working on and what to convert to OOjs UI.
Here my task was to convert the editing interface of Index: pages to OOjs UI, it consisted of mainly text boxes and buttons. In OOjs UI, these were readily available as widgets and I just need to add them to the code. Once I found out the places that the code should be converted, I started coding as according to the documentation given for OOjs in Mediawiki. By the end of the week I was almost ready to upload a patch.
Now that the first week of coding had begun, it was time to get working. As I had mentioned in my earlier post, I had started off with creating a right for the unrestricted edits in the page-quality flag. The page-quality validation is a two-step process in which involves first the manual proofreading done by a user and then it should be validated by someone else. Now this will be an issue in small Wikis, which don’t have many users, so here the admin has to pull in people who may not even be related to it, to validate it.
My task was to solve this issue. When I discussed with my mentor, the solution for this will be creating a new right for admins that allows the ‘sysop’ to override the existing rules to make changes in the page quality the way they wish to change.
So, that was when I created the right called ‘pagequality-admin’ exclusively for the ‘sysop’ or the admins of Mediawiki. Since Mediawiki has excellent documentation for different purposes, creating the right and establishing it went on smoothly with the help of the author of the ‘ProofreadPage’ extension and my mentor Thomas. This would prove very helpful to those running small Wikis once it is implemented in the next release.