Wikitech-l December 2006

wikitech-l@lists.wikimedia.org

91 participants
156 discussions

Re: [Wikitech-l] [MediaWiki-CVS] SVN: [18296] trunk/phase3
by Brion Vibber 12 Dec '06

12 Dec '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 leon(a)svn.wikimedia.org wrote: > + * Is this a subpage? > + * @return bool > + * @access public > + */ > + function isSubpage() { > + global $wgNamespacesWithSubpages; > + return ( strpos( $this->getText(), '/' ) !== false && $wgNamespacesWithSubpages[ $this->mNamespace ] == true ); > + } $wgNamespacesWithSubpages is sparse; that is, not all namespaces will necessarily be listed in it. The check as written will produce an E_NOTICE-level warning when called on a page containing a slash whose namespace is not listed explicitly in $wgNamespacesWithSubpages. - -- brion vibber (brion @ pobox.com) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFfwrKwRnhpk1wk44RAvy4AJoDKV/X7W7+9MNZL4y5yBQBwsonwQCg0cFU aUR9rjORUlMvGSAtpweE1Vc= =823l -----END PGP SIGNATURE-----

1 0

Fwd: [Wmfcc-l] [Fwd: Re: Google Ads, Bubble, and Agreement]
by Brad Patrick 12 Dec '06

12 Dec '06

Per discussion about improving Google Earth/Wikipedia collaboration, technical contacts are below. ---------- Forwarded message ---------- From: Michael E. Jones <webtoe(a)google.com> Date: Dec 12, 2006 1:47 PM Subject: Re: [Wmfcc-l] [Fwd: Re: Google Ads, Bubble, and Agreement] To: Brad Patrick <bradp.wmf(a)gmail.com> Cc: Cris Castello <criscastello(a)google.com>, Jason Shields < shields(a)google.com> Hi Brad, Please direct technical comments and questions to Cris Castello and Jason Shields. Thanks, Michael On 12/12/06, Brad Patrick <bradp.wmf(a)gmail.com> wrote: > FYI. Where do comments go to your tech team? > > ---------- Forwarded message ---------- > From: Walter Vermeir <walter(a)wikizine.org > > Date: Dec 12, 2006 10:49 AM > Subject: Re: [Wmfcc-l] [Fwd: Re: Google Ads, Bubble, and Agreement] > To: Communications Committee <wmfcc-l(a)mail.wikimedia.org > > > Brad Patrick schreef: > > I am pleased to announce that Google Earth's new release, slated to > > happen before Christmas, will contain a Google-developed layer for > > Wikipedia. We are happy to see this from Google, and are sure it will > > drive our traffic even more for points of interest. A mockup is below > > in this thread which shows what an entry bubble will look like. All of > > the links are directly back to Wikipedia itself. Alas, this release is > > only in English. > > > > Press will need to be coordinated between the ComCom and Megan Quinn > > from Google (her address is attached as well). > > > > -Brad > > This is now public and live; > http://googleblog.blogspot.com/2006/12/opening-my-eyes-to-whole-new-world.h… > > Google earth exists for Win, MaxOS X and linux > > Go to: > layers -> Primary database -> geographic web -> wikipedia > > The result is that you will see the Wikipedia globe appear on certain > places. When you click on them you get information about the location. > > > It is nice but needs still a lot of work. > - many places from who there exist articles are not listed > - very small towns are displayed when you are at a very high altitude > instead of the larger ones > - the location of the icon can be on a pace of the map the is not > logical; like on the border of an other county the icon to give > information about a country. > - the zoomlevel needed to display information is not consistent and > mostly badly defined; often you need to zoom in highly before the icon > with the information about the county is shown. > - when watching the globe there are no icons for the earth itself, the > continents and the oceans. > > > -- > Contact: walter AT wikizine DOT org > Wikizine.org - news for and about the Wikimedia community > _______________________________________________ > Wmfcc-l mailing list > Wmfcc-l(a)mail.wikimedia.org > http://mail.wikipedia.org/mailman/listinfo/wmfcc-l > > > -- > Brad Patrick > General Counsel & Interim Executive Director > Wikimedia Foundation, Inc. > bradp.wmf(a)gmail.com > 727-231-0101 -- Michael E. Jones Data Acquisition Representative Google Inc. Building 45 217E 1600 Amphitheatre Parkway Mountain View, CA 94043 Email: webtoe(a)google.com Phone: 650.253.2095 earth.google.com -- Brad Patrick General Counsel & Interim Executive Director Wikimedia Foundation, Inc. bradp.wmf(a)gmail.com 727-231-0101

1 0

Re: [Wikitech-l] Wikitech-l Digest, Vol 41, Issue 24 (Category Intersections again)
by Aerik Sylvan 12 Dec '06

12 Dec '06

Rob Church and Timwi wrote (regarding frequency of edits that change categories): > > > > Probably higher than that, to be honest, especially with all those > > Wikipedians running around, dealing with Special:Uncategorisedpages, > > and correcting stub templates and so forth. > > Also don't forget about vandals just blanking a (categorised) page, plus > the immediately following revert. Okay, well, so that we have some quantified data and can think make a firm decision one way or the other about the suitability of a MyISAM table for category intersections, I'll take a random sample of edits (of some statistically significant size - doesn't take much) and see how many involve a category change and report back. And, as always, anybody else got any ideas? If this can't work, I can't think of anything else beside a separate Lucene index (which will then not be real time and have to be updated every so often) as I don't think excluding large categories from an intersection search is an acceptable solution. Thanks, Aerik

3 2

Javascript to make references work better?
by Steve Bennett 12 Dec '06

12 Dec '06

Hi, Would it be possible to improve the "user clicks on footnote" workflow by using JavaScript? Currently it goes something like this: 1) User clicks on a footnote in some text, like the [1] in "Wikipedia is great.[1]" 2) The view suddenly jumps down to the bottom of the page. 3) User attempts to remember the number of the footnote they clicked on, and locate the corresponding number in the list. In some cases, this footnote will be at the very top of the current viewing window. Text looks like "1. ^ http://www.someurl.com" 4) User clicks on a web link, if applicable. How about: 1) User clicks on a footnote in some text, like [1] 2) The footnote expands in place to contain the full text of the footnote: [1 - http://www.someurl.com] 3) User can click on the web link, if applicable 4) Clicking on the [1 -, or the trailing ] (hopefully in a different colour from the contents of the footnote) collapses it again. Is this desirable and possible? Steve

5 5

Re: [Wikitech-l] [Bug 8184] in so many crannies $wgSitename is cached
by Dan Jacobson 12 Dec '06

12 Dec '06

rebuildMessages.php --rebuild didn't help. The Main Page's {{SITENAME}} was still rendered as the former one. However "&action=purge" fixed it for now. Too bad I don't know how to do a "&action=purge" "to the maximum extent of the law on all places where the old {{SITENAME}} germs may be hiding. Ah ha. Finally reproduced something: $ echo -n 首頁|php deleteBatch.php $ php importTextFile.php --title 首頁首頁 and now {{SITENAME}} is rendering back to it former name! Well! I had better always do a &action=purge as a third step then when I update a page that way.

1 0

MediaWiki automated test run failure 2006-12-12
by brion＠pobox.com 12 Dec '06

12 Dec '06

An automated run of parserTests.php showed the following failures: Reading tests from "/home/brion/src/wiki/phase3/maintenance/parserTests.txt"... Running test TODO: Table security: embedded pipes (http://mail.wikipedia.org/pipermail/wikitech-l/2006-April/034637.html)... FAILED! Running test TODO: Link containing double-single-quotes '' (bug 4598)... FAILED! Running test TODO: Template with thumb image (with link in description)... FAILED! Running test TODO: message transform: <noinclude> in transcluded template (bug 4926)... FAILED! Running test TODO: message transform: <onlyinclude> in transcluded template (bug 4926)... FAILED! Running test BUG 1887, part 2: A <math> with a thumbnail- math enabled... FAILED! Running test TODO: HTML bullet list, unclosed tags (bug 5497)... FAILED! Running test TODO: HTML ordered list, unclosed tags (bug 5497)... FAILED! Running test TODO: HTML nested bullet list, open tags (bug 5497)... FAILED! Running test TODO: HTML nested ordered list, open tags (bug 5497)... FAILED! Running test TODO: Parsing optional HTML elements (Bug 6171)... FAILED! Running test TODO: Inline HTML vs wiki block nesting... FAILED! Running test TODO: Mixing markup for italics and bold... FAILED! Running test TODO: 5 quotes, code coverage +1 line... FAILED! Running test TODO: dt/dd/dl test... FAILED! Running test TODO: Images with the "|" character in the comment... FAILED! Running test TODO: Parents of subpages, two levels up, without trailing slash or name.... FAILED! Running test TODO: Parents of subpages, two levels up, with lots of extra trailing slashes.... FAILED! Running test TODO: Don't fall for the self-closing div... FAILED! Running test TODO: Always escape literal '>' in output, not just after '<'... FAILED! Reading tests from "/home/brion/src/wiki/phase3/extensions/Cite/citeParserTests.txt"... Passed 451 of 471 tests (95.75%)... FAILED!

1 0

ImportFreeImages Extension
by Travis Derouin 12 Dec '06

12 Dec '06

I've converted some code we've been using into an extension for importing properly licensed photos from flickr into a Mediawiki installation: http://www.mediawiki.org/wiki/Extension:ImportFreeImages It makes use of the phpFlickr package for the API calls. Feel free to play around with it here: http://wikidiy.com/mediawiki-1.8.2/index.php/Special:ImportFreeImages Travis

7 22

Password reset changes
by Brion Vibber 12 Dec '06

12 Dec '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've introduced new handling for e-mailed password resets in r18288. Previously, the random password generated at e-mail time was allowed to be used transparently for regular logins. Both the previous and the generated passwords would continue to be valid for logins until a new password was manually set at Special:Preferences. Now, use of the temporary password at Special:Userlogin will instead shunt over to a password-change form (via the new special-purpose Special:Resetpass). So: * The only thing you can do with an e-mailed password now is choose a new password * Once you've changed your password, both the previous password and the e-mailed temporary password are no longer valid for anything This should discourage people from using the e-mailed passwords permanently, and make password resets safer (since the old password will definitely no longer be valid once the person has logged in with the new one). Internally, User::setPassword() now does some validity checking, talks to $wgAuth directly, and throws PasswordError exceptions for failure cases. These can be caught for error reporting in the user interface. User::checkPassword() no longer returns true for the temporary password; use the separate User::checkTemporaryPassword() to check for a match there. LoginForm::authenticateUserData() returns a new error code for this case; the bot API may or may not need to be updated. - -- brion vibber (brion @ pobox.com / brion @ wikimedia.org) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFfjBLwRnhpk1wk44RAlQCAJ40AB8wmeasyP5bx1X9KGWup/rT6wCfeTpC WVU/FJQ68E8sC725EyEEcFc= =Ufdp -----END PGP SIGNATURE-----

1 0

Re: [Wikitech-l] [MediaWiki-CVS] SVN: [18274] trunk/phase3/includes/Parser.php
by Rob Church 12 Dec '06

12 Dec '06

On 11/12/06, sanbeg(a)svn.wikimedia.org <sanbeg(a)svn.wikimedia.org> wrote: > + $assocArgs = $this->createAssocArgs($args); If that's going to be a static function, it might be a bit nicer to call it as self::createAssocArgs( $args ); Use of the SRO reminds people reading the code that what's being called is static. Rob Church

1 0

Re: [Wikitech-l] [MediaWiki-CVS] SVN: [18256] trunk/extensions/ImportFreeImages/ImportFreeImages.php
by Rob Church 11 Dec '06

11 Dec '06

On 11/12/06, travis(a)svn.wikimedia.org <travis(a)svn.wikimedia.org> wrote: > -$wgFlickrAPIKey = ''; > +$wgIFI_FlickrAPIKey = ''; Might be an idea to change that back, since a Flickr API key could be useful for more than this extension. When I said change global names, I meant in terms of removing any ambiguities over a particular configuration variable's purpose. A Flickr API key is, quite plainly, a Flickr API key. Rob Church

1 0

← Newer
1
...
7
8
9
10
11
12
13
...
16
Older →

Jump to page:

2026

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 December 2006