Wikitech-l April 2009

wikitech-l@lists.wikimedia.org

91 participants
75 discussions

Open Document Format
by Lars Aronsson 18 May '09

18 May '09

Can someone explain why the Wikimedia Commons accepts uploads of printable PDF documents (e.g. brochures) but not the editable source version in Open Document Format (e.g. .ODT). This seems to violate the open source principle. This should be an FAQ but, but it isn't obvious from http://commons.wikimedia.org/wiki/Commons:File_types -- Lars Aronsson (lars(a)aronsson.se) Aronsson Datateknik - http://aronsson.se

11 25

Re: [Wikitech-l] Dealing with Large Files when attempting a wikipedia database download - Focus upon Bittorrent List
by Jameson Scanlon 15 May '09

15 May '09

Two separate sites indicate potential sources of torrents for *.tar.gz downloads of the en wikipedia database material : http://en.wikipedia.org/wiki/Wikipedia_database and http://meta.wikimedia.org/wiki/Data_dumps#What_about_bittorrent.3F (so far). Is it possible for anyone to indicate more comprehensive lists of torrents/trackers than these? Are there any plans for all the database download files to be available in this way (I imagine that there would also be some PDF manual which would go along with these to indicate offline viewing, and potentially more info than this). J On 4/15/09, Petr Kadlec <petr.kadlec(a)gmail.com> wrote: > 2009/4/14 Platonides <Platonides(a)gmail.com>: >> IMHO the benefits of separated files are similar to the disadvantages. A >> side side benefit if it would be that hashes would be splitted, too. If >> you were unlucky, knowing that 'something' (perhaps just a bit) on the >> 150GB you downloaded is wrong, is not that helpful. >> So having hashes for file sections on the big ones, even if not >> 'standard' would be an improvement. > > For that, something like Parchive would probably be better… > > -- [[cs:User:Mormegil | Petr Kadlec]] > > _______________________________________________ > Wikitech-l mailing list > Wikitech-l(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l

10 15

Different behaviour of getURL()
by Rudolf Großmann 05 May '09

05 May '09

Brion Vibber <brion <at> wikimedia.org> writes: > $wgUploadUrl is set incorrectly on this site to "images" instead of > "/ProjectWiki/images". > > This reliative URL is resolved by the browser from /ProjectWiki/index.php > ok, but not by anything else -- your code snippet simply adds a "/" on > the front, making it "/images". (Note this will also fail if > $wgUploadUrl is a fully-qualified URL, such as on sites which serve > their images from a separate domain.) > I think you mean $wgUploadPath instead of $wgUploadUrl. I found nothing about $wgUploadUrl at http://www.mediawiki.org/wiki/Category:Upload_variables Adding the starting slash if not existent was only a quick and dirty workaround, because at first the problem seemed to be a missing slash in the middle of the URL. Maybe no good idea. The Wiki sysop told me he had to set $wgUploadPath="/images" (or "images"?) to get another extension to work. I thought this would cause no problems: Uploads go to the new directory http://robertfant.com/images (or better, one of its subdirectories) and files are retrieved by getURL() from the same place. Seems not to be true. New uploads still go to http://robertfant.com/ProjectWiki/images/<subdir>/subdir>/... Why? Just for sake of clarity: What is the difference between $wgUploadPath="/images" and $wgUploadPath="images"? What will the Wiki sysop have to do that uploaded files go to the same place where my extension will retrieve them? Does it help to change both $wgUploadPath and $wgUploadDirectory? How did you know so quickly about the content of $wgUploadPath without access to LocalSettings.php? Maybe there is a Special:XYZ page showing the content of all $wgXYZ variables. --Rudi http://www.formelapplet.de

5 11

Re: [Wikitech-l] [Foundation-l] site notice not accessible to users with disabilities
by Aryeh Gregor 03 May '09

03 May '09

(replying to foundation-l post on wikitech-l) On Mon, Apr 27, 2009 at 12:45 PM, Brion Vibber <brion(a)wikimedia.org> wrote: > So far this is the best way to provide a dynamic notice to the majority > of our visitors without causing problems for others. If you have > technical suggestions for alternate implementations, they're welcome in > a more relevant channel such as wikitech-l. The only non-script solution that seems like it would work well is <iframe seamless> from HTML5: http://www.w3.org/TR/html5/embedded-content-0.html#attr-iframe-seamless This solves the current problem that <iframe>s must have a prespecified height, which is why we can't use them now. Of course, <iframe> isn't necessarily terribly well supported in weird browsers, but it would be better than JavaScript. One possible way we might have more graceful fallback now is to have some <noscript> content. One possibility would be an <iframe> containing the content (which might be the wrong height, but oh well); another would be to have a message pointing to the announcements. Of course, it would be non-dismissible without JavaScript, so it would be best to keep it less obtrusive if possible. So the message seems like a better idea.

3 3

date delinking principles relating to the technical community
by John Vandenberg 01 May '09

01 May '09

Hi, In the date delinking proposed decision I have added four principles that relate to the technical community. They are a draft only. If there any major objections here or on the talk page, I will drop them over on the Workshop page so discussion can occur there. http://en.wikipedia.org/wiki/Wikipedia:Requests_for_arbitration/Date_delink… ===MediaWiki developers=== 18) The projects run by the Wikimedia Foundation, such as the English Wikipedia project, are run on the MediaWiki software, which is an open source project hosted by the Wikimedia Foundation. As it is an open source project, anyone may participate in the improvement of the software, by way of patches, however these changes are subject to approval by the core MediaWiki development team. The MediaWiki development team are part of the Wikimedia community, however their development work is beyond the jurisdiction of the English Wikipedia community and its Arbitration Committee. The paid development team is answerable to the Foundation, and the Board influences the development priorities based on the needs of the projects, of which English Wikipedia is only one of many. The Wikimedia projects may, of course, question their decisions but must at all times respect those decisions. Bug reports, feature requests, complaints and concerns should be lodged at the appropriate forums, such as Bugzilla, mediawiki.org, mediawiki-l and wikitech-l, and foundation-l or meta for larger problems, with each of these forums having their own processes and customs which should be respected. ===System administrators=== 19) System administrators are responsible for the MediaWiki software configuration of the projects run by the Wikimedia Foundation, such as English Wikipedia. They make changes to configuration based on a mix of Wikimedia Foundation, technical and project considerations. While their decisions may affect the English Wikipedia, those decisions are beyond the jurisdiction of the English Wikipedia community and its Arbitration Committee. The local community may, of course, challenge these decisions, but must at all times respect them, Complains should be lodged at meta forums, such as Bugzilla, #wikimedia-tech, wikitech-l, foundation-l and meta, each having their own processes and customs which should be respected. ===Open source=== 20) The software used by the English Wikipedia project is open source and may be improved by anyone, by way of bug reports, design documents, code patches, technical documentation, etc. Fair criticism of open source software is acceptable, however it is incumbent on everyone to participate in [[wikt:build a better mousetrap|building a better mousetrap]]. Deriding the developers who are in short supply is not acceptable. Developers are volunteers, and at no time is it acceptable to expect them to fix non-critical problems. ===Deprecation of MediaWiki functionality=== 21) The MediaWiki software used on the Wikimedia projects, and configuration of that software, is the responsibility of the developers and system administrators. In the same way that system administrators are the decision makers to enable new functionality, deprecation or removal of MediaWiki functionality is a technical decision, and implementation of that decision may have technical implications that need to be considered. The project community should engage the technical team in decisions which relate to use the software. Policies, procedures and the manual of style may govern how and when the software may be used, however decisions to deprecate or disable software features are best left in the hands of the technical staff. Regards, John Vandenberg

3 3

Call to undefined method Article::getRawText()
by Micke Nordin 01 May '09

01 May '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello all! I have been writing an extension http://www.mediawiki.org/wiki/Extension:DynamicTabs that works just fine in my test-wiki. Now I have tried to install it on another wiki and the whole thing crash when I try to create the config page on wiki, called Mediawiki:DynamicTabs: *Fatal error*: Call to undefined method Article::getRawText() in */var/www/mickenordin/mediawiki/extensions/DynamicTabs/DynamicTabs.php* on line *85 * This is the relevant part of the code: $DynTabsPage = Article::newFromId(Title::newFromText("Mediawiki:DynamicTabs")->getArticleId()); if(isset($DynTabsPage)) { $DynTabsText = explode("*", $DynTabsPage->getRawText()); //Line 85* * *a bunch of other stuff here* I can't figure out what is wrong, so I thought I'd shoot you all an email to see if any one has some insight to share. The rest of the code of the extension can be found here: http://micke.googlecode.com/files/DynamicTabs-0.2.tar.gz Since Article::getRawText() clearly isn't undefined I must be doing something else wrong... Also it seems strange that the code works in one wiki, but not another set up on the same server. /Micke -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkn5zUMACgkQzdNqVVhZvLw5VACdGzS/rAbSQgSYSag+dBXXJA+n XosAniKhbb15tUIMaDBMUzcazeCgEr8+ =5FUW -----END PGP SIGNATURE-----

3 4

1.15 branched
by Tim Starling 01 May '09

01 May '09

I've created a branch for the eventual release of MediaWiki 1.15, based on r48811. Some bugfixes will need to be backported, we're keeping track of them at bug #18629. If you feel a need to commit directly to the 1.15 branch instead of adding a note to the bug report, can you please explain in your commit message why you think the change is important enough to require immediate release? In previous releases, figuring out why people were backporting things was a large part of the release workload. -- Tim Starling

2 1

Different behaviour of getURL()
by Rudolf Großmann 30 Apr '09

30 Apr '09

My GeoGebra extension helps to embed a GeoGebra Java applet into a MediaWiki page and to display a GeoGebra file. (GeoGebra is a dynamic geometry invironment.) In my extension I use $file->getURL() to retrieve the URL of a GeoGebra file (*.ggb) previously uploaded to the MediaWiki file repository. My extension works fine at four sites (three of them for testing only): http://wiki.zum.de/Hilfe:GeoGebra http://www.fuemo.de/wiki/index.php?title=Benutzer:Rudolf.Grossmann/GeoGebra… http://wiki.formelapplet.de/index.php5?title=GeoGebra-Demo Local installation of MediaWiki, using Apache, MySQL, PHP. My extension fails at: http://robertfant.com/wiki/index.php?title=Extension:GeoGebra http://robertfant.com/ProjectWiki/index.php?title=User:Rudolf.Grossmann/Tes… Here is a PHP code snippet: ************* // retrieve URL of *.ggb file $ggbBinary = htmlspecialchars(strip_tags($args['filename'])); $ggbFile = Image::newFromName($ggbBinary); if (!($ggbFile->exists())) { $error_message = "File " . $ggbBinary . " not found."; } else { $ggbURL = $ggbFile->getURL(); // if URL doesn't start with slash, add starting slash. if (substr($ggbURL, 0, 1) != '/'){ $ggbURL = '/' . $ggbURL; } $ggbURL = $wgServer . $ggbURL; } // Add URL of *.ggb file to tag $output = $output . '<param name="filename" value="' . $ggbURL . '">' . $CRLF; ********************** Searching for the file Winkelhalbierende.ggb using Special:ListFiles leads to the page http://robertfant.com/ProjectWiki/index.php?title=File:Winkelhalbierende.ggb and there is a link to http://robertfant.com/ProjectWiki/images/c/cc/Winkelhalbierende.ggb But my extension produces this output: <param name="filename" value="http://robertfant.com/images/c/cc/Winkelhalbierende.ggb"> This means, $ggbFile->getURL() results in a string where the leading "/ProjectWiki" is missing. Why does the extension work at 4 sites, but not at 2 other? Is there a better (more reliable) function to retrieve the URL of a file stored in a MediaWiki repository, given the filename? Thanks for help in advance, Rudi ******************************* GeoGebra: http://www.geogebra.org/cms/index.php?lang=en GeoGebra extension: http://www.mediawiki.org/wiki/Extension:GeoGebra

2 1

On extension SVN revisions in Special:Version
by Brion Vibber 29 Apr '09

29 Apr '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Special:Version displays SVN version numbers for extensions out of $wgExtensionCredits, which seems to be done with $LastChangedRevision$ keywords in the extension's entry point file. This produces massively incorrect numbers in many cases, since the entry point file is relatively rarely changed in non-trivial extensions consisting of multiple files. Updates to the body, class, i18n, and other files are not reflected. If we're running on a SVN checkout of the extension, we could check the directory for its current revision much as we do for MediaWiki itself; this would tell us for instance if an extension's subdirectory has been updated separately from the core MediaWiki. But if we aren't on a SVN checkout, or if individual files have been updated to different versions, this may or may not tell us anything useful. Anybody have a suggestion on how to best handle this? - -- brion -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAklb6VcACgkQwRnhpk1wk44MNACg2c0ztpocjHfsb5l+KxSu8e+I wXgAoMSrjFeTPzEnMY4904bxXZv+DiYf =GNqG -----END PGP SIGNATURE-----

9 24

Wikipedia - openID provider?
by Strainu 29 Apr '09

29 Apr '09

Hi Are there any plans to make Wikipedia a opneID provider? I would really be interesting if we could log on to wikipedia-replated sites with the same ID. Thanks, Andrei Cipu

7 13

2025

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 April 2009