Re: [Wikitech-l] Bug 189: Add a music wikimodule resolved/fixed
Le 23/04/13 04:27, MZMcBride a écrit : Add a music wikimodule https://bugzilla.wikimedia.org/show_bug.cgi?id=189 Congrats to all involved in getting bug 189 resolved! :-) I think that deserves an official press release by the WMF :-D Congratulations to everyone involved! -- Antoine hashar Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla Weekly Report
On Mon, Apr 22, 2013 at 5:00 AM, reporter repor...@kaulen.wikimedia.orgwrote: MediaWiki Bugzilla Report for April 15, 2013 - April 22, 2013 Fresh charts: http://www.mediawiki.org/wiki/Bugzilla_Weekly_Report Željko ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Wmfall] Announcement: Erik Bernhardson joins Wikimedia as Features Engineer
Before joining us, Erik was a web developer and operational jack-of-all-trades at Cite Media/Maverick Media which is a custom Symfony2 CRM working on “what the internet is for”[1]. There he worked on MySQL, Redis, Graylog2, ElasticSearch, Nginx w/PHP-FPM integration, phpUnderControl and capifony. He integrated dozens of different payment processors (shh… don’t tell FR-tech) and automated micro-site rollout for the clients using PHP integration into Chef. Six years ago, he became a PHP developer when he found out, while hacking his DVR that it had a PHP-based webserver. He still likes to do a lot of open-source work[2], and we found him because he was patching HipHop to add namespace support. Welcome! I look forward to seeing Bernhardson's addition to whatever parts of https://www.mediawiki.org/wiki/Developers/Maintainers he feels comfortable with. :-) Given that he is a HipHop contributor, maybe we could call him MC Erik? ;-) -- Sumana Harihareswara Engineering Community Manager Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Interested in contributing to jQuery.IME
Hello, I have found an issue with mediawiki jquery.IME and have reported it on Github. https://github.com/wikimedia/jquery.ime/issues/163 I am already working on it and will create a patch with my solution soon. On Mon, Apr 15, 2013 at 9:58 PM, KAUSHAL SINGH kaushal.sing...@gmail.comwrote: Hello, I am Kaushal, a student at the Indian Institute of Technology, BHU, Varanasi (B.Tech. 2014), in Electronics and Computer. I am experienced using Javascript/jQuery, PHP, HTML/5 and am a Web Application Development enthusiast. I came to know about Wikimedia via GSoC 2013 accepted organizations. I would like to work on idea of Extension/Plugin development for web Browsers and confidently submit an improvement proposal. I have already worked on few small extension development for Google Chrome. Have also gone through the jQuery Input Method Editor (jQuery.IME) on ' https://github.com/wikimedia/jquery.ime', and implemented on my local nginx server with PHP. Would also like to know and work on jQuery.IME next big improvements. I am familiar with: GIT, PHP, HTML, Database Systems (SQLite, MySQL, Postgres), virualenv, MVC design paradigm, OAuth2.0, ssl, linux, bash, also have good experience with Adobe Photoshop. I have a worked on quite much Web applications with complete frontend UI and backend management. I have an Amazon AWS account, and access to a VPS to deploy apps for demonstration. How can I start contributing to Wikimedia? Where do I carry out my subsequent communication, ask questions and share ideas? Looking forward to your response. My generic handle is: kaushal.singh07, kaushalsingh11, 'ksingh' on IRC -- With Kind Regards, Kaushal Kumar Singh B.tech Part III Electronics Engineering Indian Institute of Technology, B.H.U, Varanasi INDIA PIN-221005 Mo: +91 - 9839203380 E-Mail : kaushal.ksingh.ec...@itbhu.ac.in kaushal.sing...@gmail.com Skype : kaushal.singh07 -- With Kind Regards, Kaushal Kumar Singh B.tech Part III Electronics Engineering Indian Institute of Technology, B.H.U, Varanasi INDIA PIN-221005 Mo: +91 - 9839203380 E-Mail : kaushal.ksingh.ec...@itbhu.ac.in kaushal.sing...@gmail.com Skype : kaushal.singh07 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Interested in contributing to jQuery.IME
Thanks Kausal. Looking forward to your pull request! -- Siebrand Mazeland M: +31 6 50 69 1239 Skype: siebrand Op 23 apr. 2013 om 14:13 heeft KAUSHAL SINGH kaushal.sing...@gmail.com het volgende geschreven: Hello, I have found an issue with mediawiki jquery.IME and have reported it on Github. https://github.com/wikimedia/jquery.ime/issues/163 I am already working on it and will create a patch with my solution soon. On Mon, Apr 15, 2013 at 9:58 PM, KAUSHAL SINGH kaushal.sing...@gmail.comwrote: Hello, I am Kaushal, a student at the Indian Institute of Technology, BHU, Varanasi (B.Tech. 2014), in Electronics and Computer. I am experienced using Javascript/jQuery, PHP, HTML/5 and am a Web Application Development enthusiast. I came to know about Wikimedia via GSoC 2013 accepted organizations. I would like to work on idea of Extension/Plugin development for web Browsers and confidently submit an improvement proposal. I have already worked on few small extension development for Google Chrome. Have also gone through the jQuery Input Method Editor (jQuery.IME) on ' https://github.com/wikimedia/jquery.ime', and implemented on my local nginx server with PHP. Would also like to know and work on jQuery.IME next big improvements. I am familiar with: GIT, PHP, HTML, Database Systems (SQLite, MySQL, Postgres), virualenv, MVC design paradigm, OAuth2.0, ssl, linux, bash, also have good experience with Adobe Photoshop. I have a worked on quite much Web applications with complete frontend UI and backend management. I have an Amazon AWS account, and access to a VPS to deploy apps for demonstration. How can I start contributing to Wikimedia? Where do I carry out my subsequent communication, ask questions and share ideas? Looking forward to your response. My generic handle is: kaushal.singh07, kaushalsingh11, 'ksingh' on IRC -- With Kind Regards, Kaushal Kumar Singh B.tech Part III Electronics Engineering Indian Institute of Technology, B.H.U, Varanasi INDIA PIN-221005 Mo: +91 - 9839203380 E-Mail : kaushal.ksingh.ec...@itbhu.ac.in kaushal.sing...@gmail.com Skype : kaushal.singh07 -- With Kind Regards, Kaushal Kumar Singh B.tech Part III Electronics Engineering Indian Institute of Technology, B.H.U, Varanasi INDIA PIN-221005 Mo: +91 - 9839203380 E-Mail : kaushal.ksingh.ec...@itbhu.ac.in kaushal.sing...@gmail.com Skype : kaushal.singh07 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Project Idea for GSoC 2013 - Bayesian Spam Filter
Hey Quim, I have drafted my proposal on my User pagehttps://www.mediawiki.org/wiki/User:Anubhav_iitr. I have already opened a bug in mediawiki for the Extension request in bugzilla. Here is the linkhttps://bugzilla.wikimedia.org/show_bug.cgi?id=47207. I will be glad to have your feedback. Can you suggest me whom I should I ask to mentor me ? On Mon, Apr 15, 2013 at 10:50 PM, Quim Gil q...@wikimedia.org wrote: On 04/14/2013 06:34 AM, anubhav agarwal wrote: Hey Quim, Thanks for such a detailed response. Sorry for being inactive for these few days, I was undergoing some coursework evaluations. I hope they went well. First things first! You have some homework to do here as well. It is time to start drafting your application, open a related feature request in Bugzilla and find a mentor. See https://www.mediawiki.org/**wiki/Mentorship_programs/** Application_templatehttps://www.mediawiki.org/wiki/Mentorship_programs/Application_template -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/**User:Qgilhttp://www.mediawiki.org/wiki/User:Qgil __**_ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/wikitech-lhttps://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Cheers, Anubhav Anubhav Agarwal| 4rth Year | Computer Science Engineering | IIT Roorkee ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Special Page or Action
Hey, At the risk of starting an emacs vs vim like discussion, I'd like to ask if I ought to be using a SpecialPage or an Action in my use case. I want to have an extra tab for a specific type of article that shows some additional information about this article. This view is per article. It does not allow for making modifications to the article. Registering either an action or a special page will result in much the same behaviour for the user, with the exception of the URL structure, which is slightly different. For me as a developer there also is little difference, either I have some thing derive from Action and have 3 lines of code in it or from SpecialPage and have the lines here. Furthermore I've seen both approaches taken, and have taken both myself. So is one approach preferred? Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. -- ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Special Page or Action
Can it not in some way be included in action=info ? DJ On Tue, Apr 23, 2013 at 2:46 PM, Jeroen De Dauw jeroended...@gmail.comwrote: Hey, At the risk of starting an emacs vs vim like discussion, I'd like to ask if I ought to be using a SpecialPage or an Action in my use case. I want to have an extra tab for a specific type of article that shows some additional information about this article. This view is per article. It does not allow for making modifications to the article. Registering either an action or a special page will result in much the same behaviour for the user, with the exception of the URL structure, which is slightly different. For me as a developer there also is little difference, either I have some thing derive from Action and have 3 lines of code in it or from SpecialPage and have the lines here. Furthermore I've seen both approaches taken, and have taken both myself. So is one approach preferred? Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. -- ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Special Page or Action
Hey, Can it not in some way be included in action=info ? In this case: no. That is however sidestepping my question :) Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. -- ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Special Page or Action
On 23.04.2013 14:46, Jeroen De Dauw wrote: Hey, At the risk of starting an emacs vs vim like discussion, I'd like to ask if I ought to be using a SpecialPage or an Action in my use case. I want to have an extra tab for a specific type of article that shows some additional information about this article. I would use an action, for several reasons: * It's always *about* some page, it's something you do with a page. Which is what actions are for. * The action interface is newer and cleaner, special pages are rather messy. * Actions can easily be overloaded by the content handler. * It's consistent with action=history, action=edit, etc. Of course, Special:WhatLinksHere is used for extra info about a page too. I don't have a very strong preference, but I'd use an action. -- daniel ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Special Page or Action
On Tue, Apr 23, 2013 at 8:46 AM, Jeroen De Dauw jeroended...@gmail.com wrote: Hey, At the risk of starting an emacs vs vim like discussion, I'd like to ask if I ought to be using a SpecialPage or an Action in my use case. I want to have an extra tab for a specific type of article that shows some additional information about this article. This view is per article. It does not allow for making modifications to the article. Registering either an action or a special page will result in much the same behaviour for the user, with the exception of the URL structure, which is slightly different. For me as a developer there also is little difference, either I have some thing derive from Action and have 3 lines of code in it or from SpecialPage and have the lines here. Furthermore I've seen both approaches taken, and have taken both myself. So is one approach preferred? Special page, special page, special page. Actions suck. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Special Page or Action
Here's my take on it: From the design perspective, SpecialPages are superior. It's one of the most mature controlling units in MediaWiki, primarily because current special pages do so many complex things there has developed a need for abstraction that handles many use cases. Actions, on the other hand, are on the verge of deprecation. In fact, many of the Actions in MediaWiki right now are literally fancy wrappers for function calls on an Article object. However, from the URI perspective, Actions make sense. Since the information is directly related to the page, having the page's URI as the base makes logical sense. It's much better for the forms for deleting a page to be at http://mywiki/wiki/MyPage?action=delete then for it to be at http://mywiki/wiki/Special:Delete/MyPage, because the delete action is something be applied to the page, not the other way around. With that in mind, I strongly recommend using a SpecialPage, because the infrastructure is better and eventually plans will be implemented to make the URI scheme for page-centric special pages more logical. *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com On Tue, Apr 23, 2013 at 9:07 AM, Chad innocentkil...@gmail.com wrote: On Tue, Apr 23, 2013 at 8:46 AM, Jeroen De Dauw jeroended...@gmail.com wrote: Hey, At the risk of starting an emacs vs vim like discussion, I'd like to ask if I ought to be using a SpecialPage or an Action in my use case. I want to have an extra tab for a specific type of article that shows some additional information about this article. This view is per article. It does not allow for making modifications to the article. Registering either an action or a special page will result in much the same behaviour for the user, with the exception of the URL structure, which is slightly different. For me as a developer there also is little difference, either I have some thing derive from Action and have 3 lines of code in it or from SpecialPage and have the lines here. Furthermore I've seen both approaches taken, and have taken both myself. So is one approach preferred? Special page, special page, special page. Actions suck. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Special Page or Action
On Tue, 23 Apr 2013 05:46:31 -0700, Jeroen De Dauw jeroended...@gmail.com wrote: Hey, At the risk of starting an emacs vs vim like discussion, I'd like to ask if I ought to be using a SpecialPage or an Action in my use case. So is one approach preferred? Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. -- Make a SpecialPage. Actions only exist for legacy reasons. There is no reason to create anything as an action anymore. In fact there are some of us that want to eliminate the action system entirely. https://bugzilla.wikimedia.org/show_bug.cgi?id=41836 https://www.mediawiki.org/wiki/Requests_for_comment/Drop_actions_in_favour_of_page_views_and_special_pages -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/] ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Special Page or Action
On Tue, 23 Apr 2013 06:07:15 -0700, Daniel Kinzler dan...@brightbyte.de wrote: On 23.04.2013 14:46, Jeroen De Dauw wrote: Hey, At the risk of starting an emacs vs vim like discussion, I'd like to ask if I ought to be using a SpecialPage or an Action in my use case. I want to have an extra tab for a specific type of article that shows some additional information about this article. I would use an action, for several reasons: * It's always *about* some page, it's something you do with a page. Which is what actions are for. Actually actions are just a legacy system that existed before special pages came into play. Nothing was ever explicitly picked to be an action just because it related to a page. In fact we have a ancient action that isn't relevant to a page at all, action=ajax. * The action interface is newer and cleaner, special pages are rather messy. Mind pointing out what is messy about special pages? If you've got an actual issue with them some of us would probably like to actually fix it. Cause actions were in fact the older interface. Till one or two people attempted to bring them up to date with the SpecialPage system that superseded actions entirely. * Actions can easily be overloaded by the content handler. Has anyone actually made use of this feature? * It's consistent with action=history, action=edit, etc. Of course, Special:WhatLinksHere is used for extra info about a page too. Actually it's not consistent at all. As Krinkle notes: For example the following ones are all related to a page (query): * Special:WhatLinksHere * action=view * action=history * action=info And these as well (more manipulations of state, less information retrieval): * action=delete * Special:Undelete * Special:MovePage * action=purge * action=edit * action=protect The only reason any of these use an action is because they were originally written long ago, potentially before we even had special pages. I don't have a very strong preference, but I'd use an action. -- daniel -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/] ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Update to jQuery 1.9 and jQuery UI 1.9
On Thu, 2012-12-06 at 20:11 +0100, Jan Luca wrote: is there already a schedule to update jQuery and jQuery UI to 1.9 or are there problems at moment? I want to use the new tooltip widget of jQuery UI 1.9 [1]. FYI, the corresponding bug reports are: https://bugzilla.wikimedia.org/show_bug.cgi?id=44740 https://bugzilla.wikimedia.org/show_bug.cgi?id=47076 andre -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bug 189: Add a music wikimodule resolved/fixed
This is really amazing! Specially for Wikisource :-) Is multi-page score transclusion with Extension:Proofread page able to generate a global midi/score file or each page has to be treated as an independent entity? Micru On Tue, Apr 23, 2013 at 4:11 AM, Antoine Musso hashar+...@free.fr wrote: Le 23/04/13 04:27, MZMcBride a écrit : Add a music wikimodule https://bugzilla.wikimedia.org/show_bug.cgi?id=189 Congrats to all involved in getting bug 189 resolved! :-) I think that deserves an official press release by the WMF :-D Congratulations to everyone involved! -- Antoine hashar Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Etiamsi omnes, ego non ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Data-URI and WebP for thumbnails, a cute experiment
Apparently Facebook has been experimenting with sending WebP images in place of JPEG to some users... but there are some usability problems reported in the tech press http://arstechnica.com/information-technology/2013/04/chicken-meets-egg-with-facebook-chrome-webp-support/ Primary problem seems to be that folks saving images locally or sharing direct URLs get surprised when they don't work in other peoples' browsers or can't be opened in other programs. Not sure what's a good solution for this, other than a really good download/sharing UI on images... -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Data-URI and WebP for thumbnails, a cute experiment
I vaguely recall the first time I came across one of these newfangled PNG images that no viewer would display. What's wrong with GIF??? That will never stand! (yes, I know plenty is wrong with GIF, especially in those days...) Pixelmator on Mac already opens webp fine, didn't test saving though. If Wikipedia would offer it, everyone except Apple would just link the library to their code and be hip ;-) On Tue, Apr 23, 2013 at 6:45 PM, Brion Vibber br...@pobox.com wrote: Apparently Facebook has been experimenting with sending WebP images in place of JPEG to some users... but there are some usability problems reported in the tech press http://arstechnica.com/information-technology/2013/04/chicken-meets-egg-with-facebook-chrome-webp-support/ Primary problem seems to be that folks saving images locally or sharing direct URLs get surprised when they don't work in other peoples' browsers or can't be opened in other programs. Not sure what's a good solution for this, other than a really good download/sharing UI on images... -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Fwd: [WikimediaMobile] Rethinking MobileFormatter / Skins
For wider distribution! -- Forwarded message -- From: Jon Robson jdlrob...@gmail.com Date: Tue, Apr 23, 2013 at 5:13 AM Subject: [WikimediaMobile] Rethinking MobileFormatter / Skins To: mobile-l mobil...@lists.wikimedia.org I've been playing around with skins a lot recently. The MobileFrontend extension has had to do various transformations to the content pre-rendering to ensure certain things do not get rendered on mobile (for example table of contents) as well as allow us to do collapsible sections. When rendering content skins are currently limited to rendering the 'bodytext' key. They cannot retrieve the underlying content. I would like to remove restrictions to skin designers - for instance currently a skin designer has no control over where the table of contents should do. They could not easily put it in a side bar for instance. I was experimenting with using the onOutputPageParserOutput hook [1] (running based on the current skin) and think it might be a better approach to run the transformations on smaller chunks of data. For instance the table of contents is known to be in the lead section so it seems like it would be more efficient to look for it there rather than throughout the entire document. The solution is not complete but provides an approach that I think would be more efficient on the long term. It seems like a good idea to experiment with this approach in MobileFrontend extension with the goal to upstream it to core. Would appreciate comments from people who know this area of code rather well - Max comes to mind :) Thoughts welcomed! [1] https://gist.github.com/jdlrobson/5439509 ___ Mobile-l mailing list mobil...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l -- Yuvi Panda T http://yuvi.in/blog ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Project Idea for GSoC 2013 - Bayesian Spam Filter
On 04/23/2013 05:42 AM, anubhav agarwal wrote: Hey Quim, I have drafted my proposal on my User pagehttps://www.mediawiki.org/wiki/User:Anubhav_iitr. I have already opened a bug in mediawiki for the Extension request in bugzilla. Here is the linkhttps://bugzilla.wikimedia.org/show_bug.cgi?id=47207. I will be glad to have your feedback. Can you suggest me whom I should I ask to mentor me ? Chris is willing to co-mentor, but not alone. I asked another potential co-mentor but we are still waiting for his answer. Anybody interested? MediaWiki extension development skills required. In any case, please apply to GSoC formally. You don't need to have the mentors assigned to do this and you can keep improving your proposal until the deadline. -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Fwd: [WikimediaMobile] Rethinking MobileFormatter / Skins
I was experimenting with using the onOutputPageParserOutput hook [1] (running based on the current skin) and think it might be a better approach to run the transformations on smaller chunks of data. For instance the table of contents is known to be in the lead section so it seems like it would be more efficient to look for it there rather than throughout the entire document. The solution is not complete but provides an approach that I think would be more efficient on the long term. Not to nitpick, but in your particular example one can use the __TOC__ magic word you can place the table of contents wherever you want in the document.[0] At least in that case, parsing the entire document might be best. /me goes back to lurking. Thank you, Derric Atzrott [0]: https://www.mediawiki.org/wiki/Help:Magic_words ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] GSoC / OPW application period is open!
Thank you Teresa for your reply, spot on. On Mon, Apr 22, 2013 at 2:04 PM, Teresa Cho tcho...@gmail.com wrote: Mine is pretty sparse and not the best example of a good proposal. It was good enough to get you acepted in the previous OPW round. Thanks to Lydia we have now a link to a collection of real good GSoC proposals: https://docs.google.com/document/pub?id=1Iqk8MTix2CN1pAgqhZqhefKTwiA7P73zQH9N46lvyB0 http://www.google-melange.com/gsoc/events/google/gsoc2013 The deadline is May 3. In the meantime, the Outreach Program for Women application period is also open, until May 1. We recommend all candidates to apply soon and be ready to improve your project proposals fast based on feedback received. We have got 3 candidates already! MENTORS: Make sure your students are submitting their proposals through the GSoC tool AND make sure you are adding yourselves as wishing to mentors: http://en.flossmanuals.net/melange/student-application-phase/ Only then a project will have a mentor officially assigned, regardless of what you have agreed in other channels. Projects without mentors officially assigned have no chance after the deadline of May 3. -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Data-URI and WebP for thumbnails, a cute experiment
On Tue, Apr 23, 2013 at 7:45 PM, Brion Vibber br...@pobox.com wrote: Not sure what's a good solution for this, other than a really good download/sharing UI on images... Maybe the most obvious solution would be for Mozilla and Microsoft and the usual bunch of image editors to start supporting WebP. There are many opportunities for small tools that can help to make the transition smooth, including Save this JPEG as WebP, Save this WebP as JPEG and - most importantly - Save the uncompressed version of this thumbnail instead Mathias ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Nischay Nahata joins Wikimedia as Features Contractor
Hello everyone, I apologize. I didn’t realize that it helps to announce long-term contractors also. ;-) It’s with great pleasure that I’m announcing that Nischay Nahata has joined the Wikimedia Foundation as a Features Engineering Contractor (only six months ago). He expects to get his B.Tech from the National Institute of Technology Karnataka sometime this year. Before joining us, Nischay worked as a Google Summer of Code student on Semantic Mediawiki. Lately he’s been dealing with bugs in UploadWizard, MoodBar, PageTriage, LiquidThreads, Echo[1]. On the side, Nischay enjoys listening to music, he wishes to see Coldplay and Guns N’ Roses live before Armageddon. He also likes long midnight walks on his college beach. His first official day actually was November 1, 2012. Nischay was raised up in Assam and currently lives in Mangalore in India, he plans to move to Bangalore after graduation. Please join me in a belated welcome of Nischay Nahata to the Wikimedia Foundation. :-) Take care, Terry [1]: https://gerrit.wikimedia.org/r/#/q/owner:%22Nischayn22+%253Cnischayn22%2540gmail.com%253E%22,n,z terry chay 최태리 Director of Features Engineering Wikimedia Foundation “Imagine a world in which every single human being can freely share in the sum of all knowledge. That's our commitment.” p: +1 (415) 839-6885 x6832 m: +1 (408) 480-8902 e: tc...@wikimedia.org i: http://terrychay.com/ w: http://meta.wikimedia.org/wiki/User:Tychay aim: terrychay ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Fwd: [WikimediaMobile] Rethinking MobileFormatter / Skins
On Tue, 23 Apr 2013 11:06:13 -0700, Yuvi Panda yuvipa...@gmail.com wrote: For wider distribution! -- Forwarded message -- From: Jon Robson jdlrob...@gmail.com Date: Tue, Apr 23, 2013 at 5:13 AM Subject: [WikimediaMobile] Rethinking MobileFormatter / Skins To: mobile-l mobil...@lists.wikimedia.org I've been playing around with skins a lot recently. The MobileFrontend extension has had to do various transformations to the content pre-rendering to ensure certain things do not get rendered on mobile (for example table of contents) as well as allow us to do collapsible sections. When rendering content skins are currently limited to rendering the 'bodytext' key. They cannot retrieve the underlying content. I would like to remove restrictions to skin designers - for instance currently a skin designer has no control over where the table of contents should do. They could not easily put it in a side bar for instance. I was experimenting with using the onOutputPageParserOutput hook [1] (running based on the current skin) and think it might be a better approach to run the transformations on smaller chunks of data. For instance the table of contents is known to be in the lead section so it seems like it would be more efficient to look for it there rather than throughout the entire document. The solution is not complete but provides an approach that I think would be more efficient on the long term. Partially for other reasons I have contemplated making the TOC a post-parse task. A placeholder gets put into the skin where the TOC goes. Then the TOC is inserted afterwards. Though 'when' is a little different in the situation I'm thinking of. In that situation I'm just thinking of deferring it to ParserOutput::getText. The same way we defer the editsection link. It seems like a good idea to experiment with this approach in MobileFrontend extension with the goal to upstream it to core. Would appreciate comments from people who know this area of code rather well - Max comes to mind :) I haven't given that much thought to it as a part of core. But the idea of marking off various parts of the page content as components that can be considered separate from the content and removed is an interesting idea. Both TOC and parts of the content. I've actually hacked things like that into live sites. Blocks of mainpage content moved to the sidebar: http://www.dragonballencyclopedia.com/wiki/Dragon_Ball_Encyclopedia Infoboxes moved to the sidebar: http://www.dragonballencyclopedia.com/wiki/Son_Goku_%28anime_character%29 I also did it fairly recently for a client's (EAW's) wiki. But they don't appear to have updated their content to make it work yet. Thoughts welcomed! [1] https://gist.github.com/jdlrobson/5439509 It's not directly related but in my plins to rewrite the skin system I have considered something relevant. A little stale but somewhat readable. https://www.mediawiki.org/wiki/User:Dantman/Skinning_system/Regions https://www.mediawiki.org/wiki/User:Dantman/Skinning_system/New_skin_layout -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/] ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Fwd: [WikimediaMobile] Rethinking MobileFormatter / Skins
Thanks for pointing out the __TOC__ magic word. Out of interest - for what reason do we support this? It seems like a bad thing to allow inconsistencies between page content on the same wiki. If a table of contents is in the lead section for one article but in the third section for another article this is bad from a user experience point of view. One of my main pain points I have been experiencing in skin development is the 'bodytext' data value - it makes far too many assumptions about how the content should be rendered. On Tue, Apr 23, 2013 at 11:21 AM, Derric Atzrott datzr...@alizeepathology.com wrote: I was experimenting with using the onOutputPageParserOutput hook [1] (running based on the current skin) and think it might be a better approach to run the transformations on smaller chunks of data. For instance the table of contents is known to be in the lead section so it seems like it would be more efficient to look for it there rather than throughout the entire document. The solution is not complete but provides an approach that I think would be more efficient on the long term. Not to nitpick, but in your particular example one can use the __TOC__ magic word you can place the table of contents wherever you want in the document.[0] At least in that case, parsing the entire document might be best. /me goes back to lurking. Thank you, Derric Atzrott [0]: https://www.mediawiki.org/wiki/Help:Magic_words ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Jon Robson http://jonrobson.me.uk @rakugojon ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Fwd: [WikimediaMobile] Rethinking MobileFormatter / Skins
On Tue, Apr 23, 2013 at 2:52 PM, Jon Robson jdlrob...@gmail.com wrote: Thanks for pointing out the __TOC__ magic word. Out of interest - for what reason do we support this? It seems like a bad thing to allow inconsistencies between page content on the same wiki. If a table of contents is in the lead section for one article but in the third section for another article this is bad from a user experience point of view. I believe (anecdotally) that it's more often used on meta-style pages (policy and discussion) where you want a couple of sections before the TOC. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Fwd: [WikimediaMobile] Rethinking MobileFormatter / Skins
Daniel Great to hear I'm not alone in my thoughts. Things like the edit section link shouldn't have to be hacked in at the parser level - if the parser returned the components of a page it would be trivial for the skin to add these itself. The fact you are resorting to hacks to do things which should be trivial (the infoboxes is a great example) suggest that this is a smell that would be good to fix. I can't help but think of Wikipedia redefined [1] which had some interesting ideas that alas would be very hard to try out in the current setup. Another example I can give is in mobile is we render cleanup templates as an overlay as these can fill an entire mobile screen on certain articles making the content unreadable (very much against a world in which every single human being can freely share in the sum of all knowledge. :)). We have had to add some javascript which collapses them but it would be great to have a better solution for non-javascript users (maybe hide the cleanup templates or put them at the bottom of the page and create a link to that at the top for those who need them) as currently this a world in which every single human being ... with javascript .. can freely share in the sum of all knowledge. :) [1] http://www.wikipediaredefined.com/ On Tue, Apr 23, 2013 at 11:52 AM, Daniel Friesen dan...@nadir-seen-fire.com wrote: On Tue, 23 Apr 2013 11:06:13 -0700, Yuvi Panda yuvipa...@gmail.com wrote: For wider distribution! -- Forwarded message -- From: Jon Robson jdlrob...@gmail.com Date: Tue, Apr 23, 2013 at 5:13 AM Subject: [WikimediaMobile] Rethinking MobileFormatter / Skins To: mobile-l mobil...@lists.wikimedia.org I've been playing around with skins a lot recently. The MobileFrontend extension has had to do various transformations to the content pre-rendering to ensure certain things do not get rendered on mobile (for example table of contents) as well as allow us to do collapsible sections. When rendering content skins are currently limited to rendering the 'bodytext' key. They cannot retrieve the underlying content. I would like to remove restrictions to skin designers - for instance currently a skin designer has no control over where the table of contents should do. They could not easily put it in a side bar for instance. I was experimenting with using the onOutputPageParserOutput hook [1] (running based on the current skin) and think it might be a better approach to run the transformations on smaller chunks of data. For instance the table of contents is known to be in the lead section so it seems like it would be more efficient to look for it there rather than throughout the entire document. The solution is not complete but provides an approach that I think would be more efficient on the long term. Partially for other reasons I have contemplated making the TOC a post-parse task. A placeholder gets put into the skin where the TOC goes. Then the TOC is inserted afterwards. Though 'when' is a little different in the situation I'm thinking of. In that situation I'm just thinking of deferring it to ParserOutput::getText. The same way we defer the editsection link. It seems like a good idea to experiment with this approach in MobileFrontend extension with the goal to upstream it to core. Would appreciate comments from people who know this area of code rather well - Max comes to mind :) I haven't given that much thought to it as a part of core. But the idea of marking off various parts of the page content as components that can be considered separate from the content and removed is an interesting idea. Both TOC and parts of the content. I've actually hacked things like that into live sites. Blocks of mainpage content moved to the sidebar: http://www.dragonballencyclopedia.com/wiki/Dragon_Ball_Encyclopedia Infoboxes moved to the sidebar: http://www.dragonballencyclopedia.com/wiki/Son_Goku_%28anime_character%29 I also did it fairly recently for a client's (EAW's) wiki. But they don't appear to have updated their content to make it work yet. Thoughts welcomed! [1] https://gist.github.com/jdlrobson/5439509 It's not directly related but in my plins to rewrite the skin system I have considered something relevant. A little stale but somewhat readable. https://www.mediawiki.org/wiki/User:Dantman/Skinning_system/Regions https://www.mediawiki.org/wiki/User:Dantman/Skinning_system/New_skin_layout -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/] ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Jon Robson http://jonrobson.me.uk @rakugojon ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] My GSOC Project Proposal
For now my user page is under development. Please bear with this format ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Fwd: [WikimediaMobile] Rethinking MobileFormatter / Skins
It's an interesting idea. Though it won't be trivial. But we could start to express the parser output of pages as high level components nested in each other. Like a document with a TOC nested in it, as well as high-level headers (or maybe sections), emeded image frames, etc... where things like the headers and image frames are components with their own rendering that the skin could create components to replace the rendering for. And even strip the component out of the page and put it somewhere else. Though it can't be a simple list of components since many of these things have specific locations inside the content to go in. Then again. Ideas like this may just make VisualEditor/Parsoid harder. We might want to come back to this once Parsoid is done with it's dom, etc... On Tue, 23 Apr 2013 12:01:00 -0700, Jon Robson jdlrob...@gmail.com wrote: Daniel Great to hear I'm not alone in my thoughts. Things like the edit section link shouldn't have to be hacked in at the parser level - if the parser returned the components of a page it would be trivial for the skin to add these itself. The fact you are resorting to hacks to do things which should be trivial (the infoboxes is a great example) suggest that this is a smell that would be good to fix. I can't help but think of Wikipedia redefined [1] which had some interesting ideas that alas would be very hard to try out in the current setup. Another example I can give is in mobile is we render cleanup templates as an overlay as these can fill an entire mobile screen on certain articles making the content unreadable (very much against a world in which every single human being can freely share in the sum of all knowledge. :)). We have had to add some javascript which collapses them but it would be great to have a better solution for non-javascript users (maybe hide the cleanup templates or put them at the bottom of the page and create a link to that at the top for those who need them) as currently this a world in which every single human being ... with javascript .. can freely share in the sum of all knowledge. :) [1] http://www.wikipediaredefined.com/ -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/] ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] My GSOC Project Proposal
On 04/23/2013 03:23 PM, Vishal Thukral wrote: For now my user page is under development. Please bear with this format You didn't include a link to your user page. Matt Flaschen ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] GSoC / OPW application period is open!
On 04/23/2013 02:36 PM, Quim Gil wrote: Thanks to Lydia we have now a link to a collection of real good GSoC proposals: https://docs.google.com/document/pub?id=1Iqk8MTix2CN1pAgqhZqhefKTwiA7P73zQH9N46lvyB0 It's not critical. But of course it would also be nice to have some MediaWiki examples. Matt Flaschen ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Special Page or Action
On 04/23/2013 09:58 AM, Daniel Friesen wrote: Mind pointing out what is messy about special pages? If you've got an actual issue with them some of us would probably like to actually fix it. Cause actions were in fact the older interface. Till one or two people attempted to bring them up to date with the SpecialPage system that superseded actions entirely. The special page system clearly did not supersede actions entirely, or e.g. action=history would have become a special page. Matt Flaschen ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Testing and monitoring deployed code
Hello all, This message is for those of you who do deployments to the WMF cluster. On the [[How to deploy code]] wikitech page, there is a section on Testing your live code: https://wikitech.wikimedia.org/wiki/How_to_deploy_code#Test_your_code_live That's a pretty basic overview of it and it could be greatly improved with information like: * How to monitor specific parts of the cluster that are relevant to what you deployed * What general monitoring should be looked at after you deploy I know many of you already do much of this after you deploy, but the lack of documentation on *how* to do it was a recurring theme in the initial interviews I did with engineering teams when I first started. https://wikitech.wikimedia.org/wiki/Deployments/Features_Process/General_Feedback == The Ask == I'm asking you (you being those of you who have experience doing post-deploy monitoring) to please add more documentation to this section of the How to deploy code page: https://wikitech.wikimedia.org/wiki/How_to_deploy_code#Test_your_code_live I expect people from both engineering and ops will have feedback here. Also, those of you who don't know how to monitor/log things post deploy but you have specific questions, please ask here so that someone who does know can answer on the wiki. Thanks, Greg -- | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @gregA18D 1138 8E47 FAC8 1C7D | ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] GSoC / OPW application period is open!
On 04/23/2013 01:04 PM, Matthew Flaschen wrote: On 04/23/2013 02:36 PM, Quim Gil wrote: Thanks to Lydia we have now a link to a collection of real good GSoC proposals: https://docs.google.com/document/pub?id=1Iqk8MTix2CN1pAgqhZqhefKTwiA7P73zQH9N46lvyB0 Good point! And thanks to the prompt answers from Sumana we have now a couple of additional local suggestions at the GSoC page: https://www.mediawiki.org/wiki/User:Jarry1250/GSoC_2012_roadmap https://www.mediawiki.org/wiki/User:Drecodeam/GSoC_2012_Application Also, I got a good question on IRC: how do we know which students are working on proposals an which ones are still looking for a project? The question came from a promoter of a project that has a mentor but is missing a student. fair enough, now we have different sections under https://www.mediawiki.org/wiki/Summer_of_Code_2013#Students I can maintain the list of Confirmed candidates, since it's easy to check against the GSoC tool. There are about 50 students that added themselves to that list and (to the best of our knowledge) aren't working on proposals yet. Let's see if that list moves up during this week. -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Engineering] Testing and monitoring deployed code
On Tuesday, April 23, 2013 at 1:06 PM, Greg Grossmeier wrote: Hello all, This message is for those of you who do deployments to the WMF cluster. On the [[How to deploy code]] wikitech page, there is a section on Testing your live code: https://wikitech.wikimedia.org/wiki/How_to_deploy_code#Test_your_code_live That's a pretty basic overview of it and it could be greatly improved with information like: * How to monitor specific parts of the cluster that are relevant to what you deployed * What general monitoring should be looked at after you deploy MediaWiki exceptions / fatals are plotted in Ganglia now, though somewhat awkwardly under node vanadium.eqiad.wmnet (where they're getting tallied) rather than the node on which the error originated. I think the way it's done now deserves another thought (maybe this ought to go in graphite, instead?), but at the same time it is sufficiently intelligible to be of _some_ use, I think. The most useful view is the last two hour's worth of exceptions and misc. fatals (evergreen link): http://ganglia.wikimedia.org/latest/graph.php?r=2hrz=xlargetitle=MediaWiki+errorsvl=errors+%2F+secx=0.5n=hreg[]=vanadium.eqiad.wmnetmreg[]=fatal%7Cexceptiongtype=stackglegend=showaggregate=1embed=1 (The m is 'mili', so the current peaks correspond to one exception / fatal every 6-10 seconds.) I'll add it to the post-deployment instructions if people find it useful. -- Ori Livneh ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Special Page or Action
On Tue, 23 Apr 2013 13:07:20 -0700, Matthew Flaschen mflasc...@wikimedia.org wrote: On 04/23/2013 09:58 AM, Daniel Friesen wrote: Mind pointing out what is messy about special pages? If you've got an actual issue with them some of us would probably like to actually fix it. Cause actions were in fact the older interface. Till one or two people attempted to bring them up to date with the SpecialPage system that superseded actions entirely. The special page system clearly did not supersede actions entirely, or e.g. action=history would have become a special page. Matt Flaschen Fine, it's legacy, un-explicitly deprecated. Just like legacy skins based directly on Skin instead of SkinTempate was for years. And in the future action=history very likely WILL become a SpecialPage, or something like it. We just don't use actions for anything new we create, period. -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/] ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Special Page or Action
Hey, Perhaps I have some misconceptions here, but was the Action class not recently (~1.18) introduced, and is it not required to use actions to specify behaviours for alternate content models? Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. -- ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Ideating on GSoC project : Mobilize Wikidata
So I've been trying to implement the suggestions and I think I'm one step away from seeing results. I've got Wikibase and all its dependancies set up, I've got mobile frontend installed (but commented out for the moment). I can't figure out how to get some Wikidata style data on to my local installation to see how it looks on a mobile though! If somebody could point me in the right direction, I'll do that and will set up a local tunnel to share the results (if any!). That should give me some information and I should be able to draft a rough proposal with the project needs! On Fri, Apr 19, 2013 at 12:28 AM, Jon Robson jdlrob...@gmail.com wrote: Pragun: It's still a work in progress. I personally think it would be great to have different mobile skins as all our projects have different needs and don't necessarily need to/should look the same or behave the same. I'd happily work closely to you (help with code review etc) to support such a move. If you were to take this approach you'd create an extension that depends on MobileFrontend and extends SkinMobile / SkinMobileBase class overriding certain functions. In a LocalSettings.php you'd be able to configure it as the default mobile skin on your wiki. You can check out the current state of the code/my mind here: https://gerrit.wikimedia.org/r/#/c/58997/ On Thu, Apr 18, 2013 at 12:03 AM, Pragun Bhutani pragu...@gmail.com wrote: I'll go ahead and request that Wikilabs account then. If I get stuck somewhere, I'll revert back to you. Also Jon, could you tell me a little more about your work on the skin? Is it possible for me to view the code? On Wed, Apr 17, 2013 at 9:43 PM, Jon Robson jdlrob...@gmail.com wrote: I've been doing some work on refactoring the mobile skin. In theory when I'm done doing this (I need some help code reviewing) you would be able to write your own mobile skin with its own modules and own scripts simply by extending some classes in MobileFrontend extension. Does this sound appealing at all? On 17 Apr 2013 08:02, Brion Vibber br...@pobox.com wrote: What you probably want to do is *integrate with* MobileFrontend, but keep your code within WikiBase extension and friends. There's provisions now for specifying desktop or mobile targets separately in ResourceLoader, which will let you load either the same or different CSS and JS for mobile views. You could also format your special pages differently, but I recommend doing the differences in CSS and JS if you can, to keep things clean. But you could also detect that mobile view is in use and change the formatting of a Special: page directly, for instance. From what I remember, the base HTML of the data editing forms is relatively straightforward, but might not fit well on small screens, so definitely consider the user-interface needs of a ~320x480px screen when planning what to do. :) -- brion On Wed, Apr 17, 2013 at 1:47 AM, Denny Vrandečić denny.vrande...@wikimedia.de wrote: 2013/4/10 Pragun Bhutani pragu...@gmail.com Based on a discussion I had with YuviPanda and MaxSem on #wikimedia-mobile, I've got a few things to add: - It might be a good idea to let Wikidata detect when it's being accessed through a mobile device and then have it adjust the widths and such of the box-structures accordingly and then pass them to MobileFrontend. Maybe we can set up a Wikilabs instance with MobileFrontend like Quim Gil suggested and then we can see how much work there is involved with trying to make WIkidata mobile-friendly. If we can get it to work with MobileFrontend, that'll be excellent but if it turns out to be too complex or too dirty a solution, it would make more sense to make a completely new extension for it. I think that sounds like a good plan. Although the scope of the project is not very clear at the moment, I think that a feasible implementation plan could be worked out with respect to the GSoC timeline and if it's required, I can continue to work on the project after GSoC ends. I am glad to hear that. But I think it would be important to scope the project so that it can be finished in GSoC time - but obviously, further work on it afterwards will be gladly appreciated. So, let's consider what should be working: * create a mobile site for Wikidata * displays the content in a layout that is more adequate for mobile devices * retains different language versions * Bonus: easy to edit First step would be to figure out the exact technology to use, i.e. whether it would use the MobileFrontend or not, etc. We would help with setting it up on labs. Cheers, Denny On Tue, Apr 9, 2013 at 6:49 PM, Quim
[Wikitech-l] RFC on possible interproject link interfaces
Dear all, I have started a new RFC with some proposals for the interproject links and you can add more if you want. https://meta.wikimedia.org/wiki/Requests_for_comment/Interproject_links_interface It has been a long standing issue and one of the most voted enhancements in Bugzilla https://bugzilla.wikimedia.org/show_bug.cgi?id=708 To have the sister projects templates at the bottom of the page it is also one of the reasons why sister projects have been also so hidden from the eyes of the big public, and now with Wikidata also the issue of maintainability can be addressed as well (similar problem as with interlanguage links). Micru ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Google Summer of Code '13] Project Idea - Inspire Me Button
Thanks for all the feedback to my proposal. I really appreciate it. If we want to provide personalized recommendations, user data does need to be connected for the best results, and yeah things could probably get a little iffy with the privacy policy. In terms of gathering data for the recommender systems, I initially had three ideas: 1) Cookies (my least favorite) 2) Reading data saved in user accounts Because of the privacy policy, (1) and (2) are out of the game. The third one might get around this issue, though. 3) Facebook App By using Facebook, not only can we use collaborative filtering techniques, we can also use network-based techniques, and this is something unique with Facebook. The data is gathered by Facebook (and possibly the app), not Wikimedia, and this could be stressed with a disclaimer. This could be an app run in the Facebook core, but it might be better if it's run separately with a Facebook plugin. I'm just not sure if Wikimedia content can be used in apps like that. It could probably benefit a lot of people to have a personalized recommender, but I could see why privacy is a concern. I do realize that if this project is approved, it will become quite big. I plan to take a small portion of it for GSoC to get the project, and make it so that it can be continued in the future. Which portion I take will depend on what the final idea is. I looked into Special:GettingStarted. How does it gather data as it is right now? What else could be worked on? If Inspire Me cannot be done, this sounds pretty interesting as well. And lastly, to Daniel: No I haven't talked to anyone directly about this idea. Posting in this mailing list is the first thing I did to get some feedback, and I did get plenty of it. Sincerely, Cheng ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Support for multiple content languages in MW core
Hi folks, I'd like to start a broader conversation about language support in MW core, and the potential need to re-think some pretty fundamental design decisions in MediaWiki if we want to move past the point of diminishing returns in some language-related improvements. In a nutshell, is it time to make MW aware of multiple content languages in a single wiki? If so, how would we go about it? Hypothesis: Because support for multiple languages existing in a single wiki is mostly handled through JS hacks, templates, and manual markup added to the content (such as divs indicating language direction), we are providing an opaque, confusing and often inconsistent user experience in our multilingual wikis, which is a major impediment for growth of non-English content in those wikis, and participation by contributors who are not English speakers. Categories have long been called out as one of the biggest factors, and they certainly are (since Commons categories are largely in English, they are by definition excluding folks who don't speak the language), but I'd like to focus on the non-category parts of the problem for the purposes of this conversation. Support for the hypothesis (please correct misconceptions or errors): 1) There's no consistent method by which multiple language editions of the same page are surfaced for selection by the use. Different wikis use different templates (often multiple variants and layouts in a single wiki), different positioning, different rules, etc., leading to inconsistent user experience. Consistency is offered by language headers generated by the Translate extension, but these are used for managing translations, while multilingual content existing in the same wiki may often not take the form of 1:1 translations. Moreover, language headers have to be manually updated/maintained, consider the user-friendliness of something like the +/- link in the language header on a page like https://commons.wikimedia.org/wiki/Commons:Kooperationen which leads to: https://commons.wikimedia.org/w/index.php?title=Template:Lang-Partnershipsaction=edit Chances are that a lot of people who'd have the ability to provide a version (not necessarily a translation) of the page in a given language will give up even on the process of doing so correctly. 2) There's no consistent method by which page name conflicts (which may often occur in similar languages) are resolved, and users have to manually disambiguate. 3) There are basic UX issues in the language selection tools offered today. For example, after changing the language on Commons to German, I will see the page I'm on (say English) with a German user interface, even if there's an actual German content version of the page available. This is because these language selection tools have no awareness of the existence of content in relevant languages. 4) In order to ensure that content is rendered correctly irrespective of the UI language set, we require content authors to manually add divs around RTL content, even if that's all the page contains. 5) It's impossible to restrict searches to a specific language. It's impossible to restrict recent changes and similar tools to a specific language. I'll stop there - I'm sure you can think of other issues with the current approach. For third party users, the effort of replicating something like the semi-acceptable Commons or Meta user experience is pretty significant, as well, due to the large number of templates and local hacks employed. This is a very tricky set of architectural issues to solve well, and it would be easy to make the user experience worse by solving it poorly. Still, as we grow our bench strength to take on hard problems, I want to raise the temperature of this problem a bit again, especially from the standpoint of future platform engineering improvements. Would it make sense to add a language property to pages, so it can be used to solve a lot of the above issues, and provide appropriate and consistent user experience built on them? (Keeping in mind that some pages would be multilingual and would need to be identified as such.) If so, this seems like a major architectural undertaking that should only be taken on as a partnership between domain experts (site and platform architecture, language engineering, Visual Editor/Parsoid, etc.). I'm not suggesting this should be done in the very near term, but I'd like to at least start talking about it, hear if I'm completely off base (and if there are simpler ways to improve on current state), and explore where it could fit in our longer term agenda. Relevant existing code: * https://www.mediawiki.org/wiki/Extension:Translate - awesome for page and message translation, but I'm not clear that it can help for the other multilingual content scenarios and problems * Others: https://www.mediawiki.org/wiki/Category:Internationalization_extensions Thanks, Erik -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation
Re: [Wikitech-l] Special Page or Action
On Tue, 23 Apr 2013 16:02:56 -0700, Jeroen De Dauw jeroended...@gmail.com wrote: Hey, Perhaps I have some misconceptions here, but was the Action class not recently (~1.18) introduced, and is it not required to use actions to specify behaviours for alternate content models? Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. Actions have existed for a long time before the Action class was created. The Action class basically migrated a bunch of actions we already had. And created yet another way of defining an action. 1.4+ hack into the UnknownAction hook 1.12+ use them MediaWikiPerformAction hook 1.18+ define an Action subclass ((Yes, all three of these still work)) ;) and for bonus points even though we have action classes now. The code for a number of these actions is STILL inside the Article class. The Action class basically made it in besides a number of us objecting, groaning, and *facepalm*ing at the idea. As for requiring actions for alternate content models. That was just a plain bad idea. -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/] ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Google Summer of Code '13] Project Idea - Inspire Me Button
On 04/23/2013 07:35 PM, Cheng Xing wrote: Because of the privacy policy, (1) and (2) are out of the game. The third one might get around this issue, though. 3) Facebook App From a privacy point of view a Facebook is a lot worse, since your data goes to a 3rd party instead of staying in Wikimedia servers. Also we have a NO to proprietary APIs policy for mentorship projects like GSoC. https://www.mediawiki.org/wiki/Summer_of_Code_2013#Your_project I'm not saying your project is not interesting (it could be an interesting 3rd party app and it could help getting a richer Wikipedia experience for Facebook users) but as it is it would fall out of scope for GSoC. -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] 'Please - Help ' (GSOC)
I am wishing to propose a project that needs Wikipedia and I discussed about it a little on IRC. I wish to know that Wikimedia will not consider any Wikipedia related project as idea’s page says or if somehow I am able to demonstrate that I will be able to complete it in summer they can consider it then. Sent from Windows Mail ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] 'Please - Help ' (GSOC)
On 2013-04-24 1:34 AM, hungers.to.nurt...@gmail.com wrote: I am wishing to propose a project that needs Wikipedia and I discussed about it a little on IRC. I wish to know that Wikimedia will not consider any Wikipedia related project as idea’s page says or if somehow I am able to demonstrate that I will be able to complete it in summer they can consider it then. Sent from Windows Mail ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l Its kind of hard to give a full response as your mail did not include details of what you are proposing (and im too lazy to go digging through the irc logs) In general though: convincing wikipedians that something is a good idea is like hearding cats-it can be difficult. Thus projects that would be useful to a wide variaty of wikis are preferred. If after all is said and done wikipedia ends up not liking the results then someone else may use it. Something usable by many wikis may also solve a more generic problem and be more generally useful. The last thing we want is for someone to do a project and their target audiance respond with why would anyone want such a thing There have been succesful projects from previous years that targetted a specific project - for example one year someone made a bot to import legal judgements into wikisource. If you are doing such a project I think the key point is to demonstrate beyond a shadow of a doubt that the community in question actually wants your project. This will probably be hard to do unless you are already a member of the community in question. -bawolff ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Support for multiple content languages in MW core
Erik Moeller wrote:
I'd like to start a broader conversation about language support in MW
core [...]
Mailing lists are good for conversation, but a lot of your e-mail was
insightful notes that I want to make sure don't get lost. I hope you'll
eventually put together an RFC (https://www.mediawiki.org/wiki/RFC) or
equivalent.
[...]
I'll stop there - I'm sure you can think of other issues with the
current approach. For third party users, the effort of replicating
something like the semi-acceptable Commons or Meta user experience is
pretty significant, as well, due to the large number of templates and
local hacks employed.
Well, for Commons, clearly the answer is for everyone to write in glyphs.
Wingdings, Webdings, that fancy new color Unicode that Apple has.
Meta-Wiki, on the other hand, now that's a real problem. ;-)
Would it make sense to add a language property to pages, so it can be
used to solve a lot of the above issues, and provide appropriate and
consistent user experience built on them? (Keeping in mind that some
pages would be multilingual and would need to be identified as such.)
If so, this seems like a major architectural undertaking that should
only be taken on as a partnership between domain experts (site and
platform architecture, language engineering, Visual Editor/Parsoid,
etc.).
I'm not sure I'd call what you're proposing a major architectural
undertaking, though perhaps I'm defining a much narrower problem scope.
Below is my take on where we are currently and where we should head with
regard to page properties.
We need better page properties (metadata) support. A few years ago, a
page_props table was added to MediaWiki:
* https://www.mediawiki.org/wiki/Manual:Page_props_table
Within the past year, MediaWiki core has seen the info action resuscitated
and Special:PagesWithProp implemented:
* https://www.mediawiki.org/w/index.php?title=MediaWikiaction=info
* https://www.mediawiki.org/wiki/Special:PagesWithProp
That is, a lot of the infrastructure needed to support a basic language
property field already exists, in my mind.
However, where we currently fall short is providing a reasonable interface
for adding or modifying page properties. Currently, we use the page text
to set nearly any property, via magic words (e.g., __NEWSECTIONLINK__ or
{{DISPLAYTITLE:}}). The obvious advantage to doing this is the
accountability, transparency, and reversibility of using the same system
that edits rely on (text table, revision table). The obvious disadvantage
is that the input system is a giant textarea.
If we could design a sane interface for modifying page properties (such as
display title and a default category sort key) that included logging and
accountability and reversibility, adding page content language as an
additional page property would be pretty trivial. (MediaWiki could even do
neat tricks like take a hint from either the user interface language of
the page creator or examine the page contents themselves to make an
educated guess about the page content language.) And as a fallback, I
believe every site already defines a site-wide content language (even
Meta-Wiki and Commons). The info action can then report this information
on a per-page basis and Special:PagesWithProp can allow lookups by page
property (i.e., by page content language).
MZMcBride
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
