Profile Information
Name: Abhishek Mittal
Email: abhishekmittaliiit@gmail.com
IM networks/handle(s): darkdragon09
Web Page: https://web.iiit.ac.in/~abhishek.mittal/
Portfolio: http://54.148.146.38/
Resume: https://web.iiit.ac.in/~abhishek.mittal/abhi_resume.pdf
Location: Hyderabad (Telangana), India
Typical working hours: 40 hours/week
Possible Mentors
@Yaron_Koren, @Nemo_bis, @Nikerabbit
Introduction
Hi, I am Abhishek Mittal. Currently, I am in 4th year, pursuing B.Tech in CSE from International Institute of Information Technology Hyderabad. I would like to spend this summer working as part of MediaWiki Development team and contribute my bit in the development of the project.
Synopsis
The aim of the project is to add multilingual-capabilities to Semantic MediaWiki, such that it supports various languages out of the box, thus removing the overhead of configurations that are required to make MediaWiki multilingual. Thus the new Semantic MediaWiki would be now MultiLingual Semantic MediaWiki as demonstrated in the following links :-
This would make the process of creating new multilingual semantic Wiki’s faster and easier and also make Wiki’s more easily reachable to people of different language groups.
Deliverables
This project has a number of intricacies involved and the completion of the project in the given time seems to be a bit difficult. Therefore, my major focus would be deliver and develop modules that are easily integrable with the SMW core. The goal of the project is to develop a technique such that properties can be made multilingual. The idea suggested by @mwjames is to introduce a monolingual texttype which would allow to annotate a property with different labels in different languages such as [[Has property label::en:Foo]] [[Has property label::ja:テスト]] etc., which happens entirely within the property namespace. Here "Has property label" is the monolingual texttype used for annotations.
Now a query can be created to lookup the correct label for a property using PropertyLabelLanguageFallbackLookup which is injected into the PropertyLabelFinder.
Since all Phases are independent, my main focus would be Phase 3 of the project and would spend considerable time finishing it.
Key Deliverables
- Code for a monolingual texttype which would allow to annotate a property with different labels
- Documentation of technique used
- Demonstration video of the multilingual capabilities of the project
Detailed Project Description and Plan of Action
In order to make SMW multilingual, we need to do the following steps :-
Phase 1. Enhance Features
Enhance Special:CreateForm and friends (all the Special:Create* special pages by Semantic Forms) to create forms that are already i18n -ed (localized), with placeholders and message group for the Translate extension.
The main components of Semantic Forms functionality are form definition pages, which exist in a new namespace, 'Form:'. These are pages consisting of markup code which gets parsed when a user goes to add or edit data. Since forms are defined strictly through these definition pages, users can themselves create and edit forms, without the need for any actual programming.
The Semantic Forms extension enforces the use of templates in creating semantic data. It does not support direct semantic markup in data pages; instead, all the semantic markup is meant to be stored indirectly through templates. A form allows a user to populate a pre-defined set of templates and sections for a page (behind the scenes, the template data is turned into semantic properties once the page is saved).
Subtask 1. We need to extend semantic forms, by extending the templates, such that option to translate property names is provided to the users creating the form. A separate module that provides the interface, perhaps a button, that can be put against each property name, can be written in order to make the translation process easier. This button would work similarly as the translate link works at the top of page.
Subtask 2. Send the required information to the translation extension, that provides the interface for translation
Phase 2. Make possible to send strings for translation to Translate message groups
Make it possible to define translation for properties and create a message group for Translate extension, similar to what CentralNotice does (sending strings for translation to Translate message groups).
In order to achieve goals of this phase, we need to do the following :-
- Explicitly tie a language dependent label to property key (a user-property created in a specific language) where the label is being fed as alias to a property key (the property-key stays as unique identifier).
- Introduce a monolingual texttype which would allow to annotate a property with different labels in different languages such as [[Has property label::en:Foo]] [[Has property label::ja:テスト]] etc., this happens entirely within the property namespace
- Create a query to lookup the correct label for a property using PropertyLabelLanguageFallbackLookup which is injected into the PropertyLabelFinder.
- Replace the text (property key) within a query based on a language key (or {{int}}) will not work as the identifier (property key/label) the value was stored needs to be used. The text presentation of a property can only be replaced after a query result has been generated.
Translate extension would provide the translation interface. SMW would register a message group(s) to Translate. One of these groups would contain all the *name* of the properties known to exist in the Wiki.
Phase 3. Handle translations of properties where ever used
There are lot of places where properties are displayed: many special pages, queries, property pages. We need to find out a sensible way to handle translations on all these places. In most wikis, properties names are supposed to be hidden to the user, e.g. queries results are usually shown in infobox-like templates (whose labels could in theory be localised as all templates).
This part would be difficult to implement, but by starting things one at a time we can achieve some considerable goals.
Translate would be fed with the strings in need of translation. Localised strings/messages would be displayed based on the interface language, that in core every user can set on Special:Preferences and with ULS is made way easier to pick for everyone including unregistered users.
Phase 4. Fix Issues that prevent full Localisation
Fixing the issues that prevent full localisation of Semantic Forms (T49736: Unable to use {{int}} inside {{for template}}).
This is important as Localisation is the first step to enable multilingual translations. All translation of MediaWiki user interface messages go through translatewiki.net and not committed directly to code. Only the English messages and their initial documentation must be done in the source code. This process is Localisation. Once the messages and documentation are available in English then they are translated.
Therefore, fixing the existing issues that prevent full localisation of Semantic Forms becomes must, to add multilingual capabilities to SMW.
Major Hurdles
The hardest part of the project is to use the translations for properties in various places. Most cases are probably easy to change, but there can be a lot of them and some of them might be difficult because of caching or other issues.
Project Timeline
- Before 25th May :- Design a comprehensive implementation strategy for the project and get a better understanding of the project.
- 25th May - 5th June :- Internship Begins, Start Phase One - Subtask 1 of the project. Integrate interface for translation of properties in semantic forms.
- 5th June - 15th June :- Phase One - Subtask 2. Link the interface with the translation extension.
- 15th June - 25th June :- Phase Three. Start this subtask and understand the design strategy
- 25th June - 2nd July :- - 3rd July :- Midterm Evaluations
- 4th July - 20th July :- Continue Phase 3 of the project.
- 20th July - 5th Aug :- Phase Three of the project. Handle translations of properties where ever used
- 6th Aug - 10th Aug :- Phase Four of the project.
- 11th Aug - 15th Aug :- Testing and Bug Fixing
- 15th Aug - 22nd Aug :- Documentation Related Stuff
Further Questions and more about myself
Q. Why you’d like to execute on this particular project and the reason you’re the best individual to do so.
I think this project has a great scope for learning. This project has been proposed for GSOC twice before, but has yet to be tried. The project appears to quite challenging and unique, and if deployed the project can be integrated easily with the existing Semantic Wiki’s as well, which need translation for properties. It makes the process of making providing multilingual capabilities to Semantic Wiki easy and appears to a great opportunity to learn and enhance my development skills.
I think that I am the best individual to do so because of my past experience of Web Development and a never ending thirst to explore and try new stuff. Moreover this project needs triage, and requires a good amount of exploring for completion and I don’t easily give up on projects once started.
Hits and Trials since the last month
In order to get hold and better understanding of this project, I tried to solve the following bugs :-
- T49510: SF & translate extension : "Save page" button does nothing (saves nothing) :- This bug appeared resolved in the new versions of MediaWiki. Things were working fine when I tried to reproduce the bug.
- T85924: SVG upload should have more specific error (warning) message when blocking :- Submitted a patch for resolving the bug, the patch is under review.
- T48995: Username validation message does not describe failure reason, only "You have not specified a valid username" :- Currently I am working on resolving this issue.
Public Contributions/Development Experience
- Codemirror (online text editor for programming languages, open source project) :- Reported and Submitted a patch for bug fix to Codemirror.
Pull Request :- https://github.com/codemirror/CodeMirror/pull/2663 Bug Report :- https://github.com/codemirror/CodeMirror/issues/2662
- OmniSharp (autocomplete demon for C#, open source project) :- Reported and Submitted a patch for bug fix to Omnisharp.
Commit :- https://github.com/OmniSharp/omnisharp-server/commits?author=abhishekmittal09
- Mediawiki (engine that supports wikipedia, open source project) :- Submitted a patch fix for Bug in mediawiki, backend engine hosting wikipedia.
Link for bug fix :- https://gerrit.wikimedia.org/r/194466 Bug :- https://phabricator.wikimedia.org/T85924
Q. How my progress can be tracked?
I plan to write weekly blogs to update my status and progress made each week. The blog will contain the details of the hurdles that I experienced and the method used to tackle them.
Q. Do you have other obligations from late May to early August (school, work, etc.)?
No I donot have any other obligations besides pursuing internship during summers. I’ll try my best to finish this project in time.