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.
After the community bonding period ending on the 30th of May, it was a great working with the Mediawiki team. For me it was a tremendous learning experience the whole month, talking to people, understanding the code-base and working with different aspects of Mediawiki.
Right from setting up the localhost to working with different extensions, I was guided throughout out by the community whom I was familiar with, from a couple of months. As I now had gotten the hang of things, it was time to start working on it. Since the schedule of work had already been chalked out, I was ready to go.
I will start off with the fast task assigned, which is to create a right that overrides the pagequality-right in ProofreadPage extension, I will be detailing on this in the next blog post.