Wikitech-l August 2011

wikitech-l@lists.wikimedia.org

122 participants
123 discussions

Missing Section Headings
by Marc Riddell 13 Sep '24

13 Sep '24

Hello, I have been a WP editor since 2006. I hope you can help me. For some reason I no longer have Section Heading titles showing in the Articles. This is true of all Headings including the one that carries the Article subject's name. When there is a Table of Contents, it appears fine and, when I click on a particular Section, it goes to that Section, but all that is there is a straight line separating the Sections. There is also no button to edit a Section. If I edit the page and remove the "== ==" markers from the Section Titles, the Title then shows up, but not as a Section Heading. Also, I don't have any Date separators on my Want List. This started 2 days ago. Any thoughts? Thanks, Marc Riddell [[User:Michael David]]

10 11

MediaWiki to Latex Converter
by Hugo Vincent 18 Jun '12

18 Jun '12

Hi everyone, I recently set up a MediaWiki (http://server.bluewatersys.com/w90n740/) and I need to extra the content from it and convert it into LaTeX syntax for printed documentation. I have googled for a suitable OSS solution but nothing was apparent. I would prefer a script written in Python, but any recommendations would be very welcome. Do you know of anything suitable? Kind Regards, Hugo Vincent, Bluewater Systems.

6 13

About to commit improved DB2 database support
by Leons Petrazickis 21 Dec '11

21 Dec '11

I've been informally mentoring André, Tiago, Diego, and César. They are four students at Minho University who are currently working on a project to improve DB2 database support in MediaWiki. So far, they've: - Fixed several outstanding issues with DB2 support involving character encoding, Windows vs Linux, etc - Added DB2 support to the new MediaWiki 1.17 Installer and Updater - Put in the appropriate Updater sql patches to reflect database schema changes since 1.14 MediaWiki already had some DB2 support, but it's been broken since 1.15 and never complete. As a result of their work, it's now possible to successfully install MediaWiki on DB2 out of the box and to use the core wiki features. I'll shortly commit their first patch using my SVN account (leonsp). I've taken some care to look over the code and make sure it abides by the MediaWiki code guidelines. Regards, Leons Petrazickis http://lpetr.org/blog/

7 9

RFC: Should we drop the rendering preferences for math?
by Brion Vibber 29 Nov '11

29 Nov '11

Bug 24207 requests switching the math rendering preference default from its current setting (which usually produces a nice PNG and occasionally produces some kinda ugly HTML) to the "always render PNG" setting. I'd actually propose dropping the rendering options entirely... * "HTML if simple" and "if possible" produce *horrible* ugly output that nobody likes, so people use hacks to force PNG rendering. Why not just render to PNG? * "MathML" mode is even *MORE* limited than "HTML if simple", making it entirely useless. * nobody even knows what "Recommended for modern browsers" means, but it seems to be somewhere in that "occasionally crappy HTML, usually PNG" continuum. So we're left with only two sane choices: * Always render PNG * Leave it as TeX (for text browsers) Text browsers will show the alt text on the images, which is... the TeX code. So even this isn't actually needed for its stated purpose. (Hi Jidanni! :) lynx should show the tex source when using the PNG mode.) It's conceivable that a few folks really honestly prefer to see the latex source in their graphical browsers (should at least do a quick stat check to see if anybody uses it on purpose), but I wouldn't mind removing that either. Fancier rendering like MathJax etc should be considered as a separate thing (and implemented a bit differently to avoid parser cache fragmentation!), so don't let future mode concerns worry y'all. Any thoughts on whether this makes sense to do for 1.18 or 1.19? https://bugzilla.wikimedia.org/show_bug.cgi?id=24207#c9 -- brion

9 12

Adding MD5 / SHA1 column to revision table (discussing r94289)
by Diederik van Liere 28 Nov '11

28 Nov '11

Hi! I am starting this thread because Brion's revision r94289 reverted r94289 [0] stating "core schema change with no discussion" [1]. Bugs 21860 [2] and 25312 [3] advocate for the inclusion of a hash column (either md5 or sha1) in the revision table. The primary use case of this column will be to assist detecting reverts. I don't think that data integrity is the primary reason for adding this column. The huge advantage of having such a column is that it will not be longer necessary to analyze full dumps to detect reverts, instead you can look for reverts in the stub dump file by looking for the same hash within a single page. The fact that there is a theoretical chance of a collision is not very important IMHO, it would just mean that in very rare cases in our research we would flag an edit being reverted while it's not. The two bug reports contain quite long discussions and this feature has also been discussed internally quite extensively but oddly enough it hasn't happened yet on the mailinglist. So let's have a discussion! [0] http://www.mediawiki.org/wiki/Special:Code/MediaWiki/94289 [1] http://www.mediawiki.org/wiki/Special:Code/MediaWiki/94541 [2] https://bugzilla.wikimedia.org/show_bug.cgi?id=21860 [3] https://bugzilla.wikimedia.org/show_bug.cgi?id=25312 Best, Diederik

19 28

On third-party users of MediaWiki and collaboration with upstream
by Jack Phoenix 28 Sep '11

28 Sep '11

Hi all, while MediaWiki has been and is developed primarily with Wikimedia Foundation's interests in mind, there are some big third-party users of MediaWiki out there; while Wikia and wikiHow are the biggest and most well-known, they certainly aren't the only ones. What's common to third-party users of MediaWiki is not just custom extensions, but sadly core changes, or as they're better known, core hacks -- unsupported changes to the core of the MediaWiki software. I think that everyone will agree with me when I say that we will want to reduce the amount of core hacking by third-parties and instead increase collaboration with us, the upstream developers of MediaWiki. Reducing the amount of core hacks is generally a good idea for third parties, because it will allow them to upgrade to the latest stable version of MediaWiki easily and things like new hooks can and in many cases are useful to other users of MediaWiki. For example, the MakeGlobalVariablesScript hook ( http://www.mediawiki.org/wiki/Manual:Hooks/MakeGlobalVariablesScript) was originally introduced by Wikia (under the name 'ExtendJSGlobalVars'); in r38397 I added the hook into core under its current name and right now there are many extensions using the hook, including ones used by Wikimedia Foundation sites (see http://www.mediawiki.org/wiki/Category:MakeGlobalVariablesScript_extensions). This is a fine example of how a third-party core hack became a part of the MediaWiki core and thus something useful to other users of MediaWiki, including the Wikimedia Foundation. Another factor to take into account is security. According to the Version lifecycle page on MediaWiki.org (see http://www.mediawiki.org/wiki/Version_lifecycle), "The release manager has also issued a strong recommendation that versions not listed above as current version or legacy version should not be used in a productive environment. They may contain critical security vulnerabilities and other major bugs, including the threat of possible data loss and/or corruption". For example, wikiHow is running MediaWiki 1.12.0, which was released on 21 March 2008 -- over three years ago. While I'm sure that the wikiHow developers have applied plenty of the more modern security patches, there's still a possibility that they may have missed one patch -- and even if not, MediaWiki 1.12.0 doesn't have all the cool new features that MediaWiki 1.17.0 has. :-) Essentially I'd like to see all major third-party users contributing code to the upstream version of MediaWiki and everyone keeping their copies of MediaWiki on the official MediaWiki Subversion repository at svn.wikimedia.org. Maybe we could have a branch for each third party under /mediawiki/branches/ or if that's unacceptable, then maybe even a whole new repository (like how we currently have mediawiki, mysql, pywikipedia and wikimedia -- see http://svn.wikimedia.org/viewvc), although I must admit that it sounds a bit overkill to me. I know from experience that many third parties have written some awesome code and that there are many other people interested in third-party code, but usually getting third-party code to run requires plenty of knowledge about PHP and MediaWiki as the extensions and core changes have usually been designed to work with one site or one farm. I want to change that and bring more extensions available to the general public -- after all, there are many people out there who run a MediaWiki wiki yet they aren't very PHP-savvy. The official MediaWiki Subversion repository is also well-known and it can also act as a "backup" of some kind. I'm sure that most people and companies have extensive backup systems in place, but everything is still possible. For example, the social wiki/blog hybrid site ArmchairGM, where the SocialProfile extension ( http://www.mediawiki.org/wiki/Extension:SocialProfile) and many other, equally cool and interesting extensions were developed, had its own codebase. While the main Wikia codebase has been open source for years, the ArmchairGM codebase was only recently (1 August 2011) open-sourced with the kind help of Sean Colombo -- and for a rather long while, it seemed that ArmchairGM's unique skin and the unique extensions had been lost; now that would've been a major loss for the open source community. Tens of thousands of lines of code, dozens of unique features and some pretty skins were nearly lost; I think that it's in everyone's best interest to prevent such incidents from happening and that is possible by keeping the code free and open. I've CC'd this message to Sean Colombo of Wikia, Jack Herrick and Reuben Smith of wikiHow, Joachim Bode of Twoonix Software GmbH and Markus Glaser of Hallo Welt! -- please let me know your thoughts about this idea and how your company would be able to contribute. Thanks and regards, -- Jack Phoenix MediaWiki developer

4 4

Phonegap and Wikimedia mobile apps
by Tomasz Finc 27 Sep '11

27 Sep '11

I've been asking around on IRC but thought it would be good to open up to a larger audience. Has anyone here used PhoneGap (http://www.phonegap.com/) for mobile app development? I'm eager to get your thoughts and potentially brainstorm some new ideas. I'll have a longer mail about this later but since its taken too long to draft it .. i thought i'd just send this snippet now to start the conversation. --tomasz

6 12

Announcing Wikihadoop: using Hadoop to analyze Wikipedia dump files
by Diederik van Liere 14 Sep '11

14 Sep '11

Hello! Over the last few weeks, Yusuke Matsubara, Shawn Walker, Aaron Halfaker and Fabian Kaelin (who are all Summer of Research fellows)[0] have worked hard on a customized stream-based InputFormatReader that allows parsing of both bz2 compressed and uncompressed files of the full Wikipedia dump (dump file with the complete edit histories) using Hadoop. Prior to WikiHadoop and the accompanying InputFormatReader it was not possible to use Hadoop to analyze the full Wikipedia dump files (see the detailed tutorial / background for an explanation why that was not possible). This means: 1) We can now harness Hadoop's distributed computing capabilities in analyzing the full dump files. 2) You can send either one or two revisions to a single mapper so it's possible to diff two revisions and see what content has been addded / removed. 3) You can exclude namespaces by supplying a regular expression. 4) We are using Hadoop's Streaming interface which means people can use this InputFormat Reader using different languages such as Java, Python, Ruby and PHP. The source code is available at: https://github.com/whym/wikihadoop A more detailed tutorial and installation guide is available at: https://github.com/whym/wikihadoop/wiki (Apologies for cross-posting to wikitech-l and wiki-research-l) [0] http://blog.wikimedia.org/2011/06/01/summerofresearchannouncement/ Best, Diederik

4 3

Google tech talk last week
by Erik Moeller 13 Sep '11

13 Sep '11

Hi folks, as a quick update, Alolita, Rob & I presented a tech talk at Google Mountain View last Thursday. The slides are up at: http://wikitech.wikimedia.org/view/File:Infrastructure_of_Collaboration.pdf They're not terribly self-explanatory, so you'll want to see the video to make sense of them -- should go up soon on http://www.youtube.com/user/GoogleTechTalks The intent of the talk was to give a quick all-round update across Wikimedia's engineering projects, to help refresh the understanding of Googlers and anyone else who might be watching. It's good for us to do these once a year to keep folks up-to-date, and get some of them excited about helping :-) Cheers, Erik -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

3 4

Ramping up to MobileFrontend production switch over
by Tomasz Finc 09 Sep '11

09 Sep '11

After last weeks successful triage and the large amount of work that everyone has been doing were getting pretty close to having MobileFronted production ready. We've spent the last week not only resolving current bugs but also taking a couple of passes through the code so that its far similar to the rest of our extensions. I think our velocity is pretty good and were shooting to start switching over the week of 9/5. But we still have a couple more bugs that we could use some help with TestMe https://bugzilla.wikimedia.org/show_bug.cgi?id=27718 - Broken file description pages using Wikipedia Mobile Bugs https://bugzilla.wikimedia.org/show_bug.cgi?id=22014 - Caching problems with mobile_main_page https://bugzilla.wikimedia.org/show_bug.cgi?id=29505 - Removing dependance on jQuery for devices using NetFront https://bugzilla.wikimedia.org/show_bug.cgi?id=30406 - MobileFrontend extension outputting invalid HTML in footer Feature https://bugzilla.wikimedia.org/show_bug.cgi?id=30551 - Create a simple feedback option for mobile users Blocking but being worked on https://bugzilla.wikimedia.org/show_bug.cgi?id=29517 - Allow client side folding in Opera Mini https://bugzilla.wikimedia.org/show_bug.cgi?id=30356 - New gateway has broken layout for opera mini Thanks for any help you can give on these bugs --tomasz

1 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Wikitech-l August 2011