Wikitech-l August 2008

wikitech-l@lists.wikimedia.org

71 participants
87 discussions

Re: [Wikitech-l] [MediaWiki-CVS] SVN: [38837] branches/REL1_13/phase3
by Simetrical 08 Aug '08

08 Aug '08

On Fri, Aug 8, 2008 at 12:02 AM, <tstarling(a)svn.wikimedia.org> wrote: > Log Message: > ----------- > Backported the following: > ... > * r38111: __STATICREDIRECT__ Now that we have __STATICREDIRECT__, do we still need the checkbox on every move? The complexity difference on Special:MovePage between three checkboxes and two, or four and three, is substantial, and we shouldn't have the extra one if it's not warranted.

4 7

Moving the search box up
by Tim Starling 08 Aug '08

08 Aug '08

It's now possible to move the search box up in the sidebar, above links generated by [[MediaWiki:Sidebar]]. This is done by adding a section called "SEARCH" (case-sensitive) to [[MediaWiki:Sidebar]], in the location you think it should be. For instance: * SEARCH * navigation ** mainpage|mainpage ** Portal:Contents|Contents ** Portal:Featured content|featuredcontent ** currentevents-url|currentevents ** randompage-url|randompage It's also possible to move the languages box and the toolbox in the same way, using LANGUAGES and TOOLBOX. Do not put second-level links under the special headings: * SEARCH ** Don't add a line like this It doesn't do anything useful (yet). -- Tim Starling

14 25

removing obsolete extensions
by Robert Stojnic 07 Aug '08

07 Aug '08

Were these necessary given that we already had the OBSOLETE file in them? These extensions now cannot be downloaded with Special:ExtensionDistributor, and all old links pointing to SVN locations stopped working (e.g. links on mw.org). I think there are still plenty of people out there that might have older MediaWiki installs and might want these or other obsolete extensions. r. ------------------------------------------------------------------------ r38458 | siebrand | 2008-08-03 01:30:40 +0200 (Sun, 03 Aug 2008) | 1 line Changed paths: D /trunk/extensions/Userip Remove Userip. Obsolete since 29 December 2007 (r29006). Last available code can be found in 1.13 branch. ------------------------------------------------------------------------ r38457 | siebrand | 2008-08-03 01:29:00 +0200 (Sun, 03 Aug 2008) | 1 line Changed paths: D /trunk/extensions/SubpageList Remove SubpageList. Obsolete since 10 February 2008 (r30807). Last available code can be found in 1.13 branch. ------------------------------------------------------------------------ r38456 | siebrand | 2008-08-03 01:26:56 +0200 (Sun, 03 Aug 2008) | 1 line Changed paths: D /trunk/extensions/LuceneSearch Remove LuceneSearch. Obsolete since 22 March 2008 (r32332). Last available code can be found in 1.13 branch. ------------------------------------------------------------------------ r38455 | siebrand | 2008-08-03 01:23:52 +0200 (Sun, 03 Aug 2008) | 1 line Changed paths: D /trunk/extensions/AutomaticGroups

2 1

Re: [Wikitech-l] SVN: [38751] trunk/phase3/languages/messages/MessagesEn.php
by Daniel Friesen 07 Aug '08

07 Aug '08

Do you think we could at least use some sort of $wgUseUnicodeLinktrail and default it to false until we find a good way to test if it is supported? ~Daniel Friesen(Dantman, Nadir-Seen-Fire) of: -The Nadir-Point Group (http://nadir-point.com) --It's Wiki-Tools subgroup (http://wiki-tools.com) --The ElectronicMe project (http://electronic-me.org) --Games-G.P.S. (http://ggps.org) -And Wikia ACG on Wikia.com (http://wikia.com/wiki/Wikia_ACG) --Animepedia (http://anime.wikia.com) --Narutopedia (http://naruto.wikia.com) tstarling(a)svn.wikimedia.org wrote: > Revision: 38751 > Author: tstarling > Date: 2008-08-07 04:32:46 +0000 (Thu, 07 Aug 2008) > > Log Message: > ----------- > (Bug 15035) Revert linkTrail to /^([a-z]+)(.*)$/sD, as it was before r36253. Multiple reports of breakage due to old (pre-5.0) PCRE libraries, both bundled with PHP and packaged with distros such as RHEL. > > Modified Paths: > -------------- > trunk/phase3/languages/messages/MessagesEn.php > > Modified: trunk/phase3/languages/messages/MessagesEn.php > =================================================================== > --- trunk/phase3/languages/messages/MessagesEn.php 2008-08-07 04:25:55 UTC (rev 38750) > +++ trunk/phase3/languages/messages/MessagesEn.php 2008-08-07 04:32:46 UTC (rev 38751) > @@ -443,7 +443,7 @@ > * Regular expression matching the "link trail", e.g. "ed" in [[Toast]]ed, as > * the first group, and the remainder of the string as the second group. > */ > -$linkTrail = '/^(\p{L&}+)(.*)$/usD'; > +$linkTrail = '/^([a-z]+)(.*)$/sD'; > > /** > * List of filenames for some ui images that can be overridden per language >

2 2

Next/previous articles
by Stig Meireles Johansen 06 Aug '08

06 Aug '08

I'm posting this question here as it's kind of specific to wikipedia/media as well as it's a possible mediawiki-feature-request. Would it be possible to add some kind of feature or extension which enables users to either; - get a list of the next/previous articles alphabetically (a short index) in a separate box/window, or - get a summary of the next articles at the bottom of current article (to simulate a book) There has been some suggestions to add a transcluded Special:Prefixindex/{{PAGENAME}} to the stub-templates, but I have warned them off with a possible hit in uncacheable pages.. Adding some AJAX-functionality would also need some kind of uncacheable special-page output. I guess there's always a way to do a quick hack of this, but doing it in a way that's cacheable and meaningful is another problem. Stigmj@nowiki

5 9

WikiTimeLine Extension possibly a good idea for implementation on Wikipedia or sister projects
by M Sz 06 Aug '08

06 Aug '08

Hi! The MediaWiki extension WikiTimeLine version 1.0 is released. It displays events, people, and such on an interactive timeline. Its working with JavaScript (client side, so it doesn't but load on the server) and its pretty interactive (moving around, zooming, clicking on events on the timeline). If you add WikiTimeLine tags with a start and end date to an article, you'll get a link in that article, and if you click on that link you'll add event to the timeline. So its totally real-time. Unlike easytimeline which is creating pictures when the article is created, WikiTimeLine is controlled by the reader of the article, not the writer. So everyone can put together their own timeline to see how things went in history. It also allows ongoing events (that have not yet stopped) and alternative begin or end dates. I think this would be a great extension for Wikipedia or one of its sister projects. Any interest in that? greetings, Markus _________________________________________________________________ Sie haben nie Platz in Ihrer Inbox? Mit Windows Live Hotmail haben Sie jetzt 5GB Speicherplatz - gratis! Holen Sie sich hier Ihren neuen Windows Live Hotmail Account! http://get.live.com/mail/overview

4 7

Dumps Still Stuck (since 7/1)?
by yegg＠alum.mit.edu 06 Aug '08

06 Aug '08

The database dumps (http://download.wikimedia.org/backup-index.html) don't seem to have made any progress since 7/1. I realize they can appear stalled in the normal process (http://meta.wikimedia.org/wiki/Data_dumps#Schedule), but in the recent past (as far as I know) they have not been stalled this long without there being something actually wrong. Are they indeed still stuck (http://lists.wikimedia.org/pipermail/wikitech-l/2008-July/038625.html)? And is there anything I (or other community members) can do about it? Thank you for your time.

7 13

Re: [Wikitech-l] [MediaWiki-CVS] SVN: [38677] trunk/phase3
by Simetrical 06 Aug '08

06 Aug '08

On Tue, Aug 5, 2008 at 10:18 PM, <dantman(a)svn.wikimedia.org> wrote: > Revert r38675: > This commit was clearly not thought out and poorly implemented. > * The Sanitizer has not been used > * Proper implementation of this would follow the same convention as the other classNames and have a 'skin-' prefix > Consistency in the code organization wasn't even kept, a bit of code was just lazily tacked onto the end of another line. The Sanitizer doesn't need to be used, since any valid PHP identifier is a valid CSS class. The point about the prefix is valid. Also, we need to carefully think about how many new classes we want to spam onto the body element. What's the use-case here? CSS is loaded conditionally based on skin already, and for JavaScript I'm pretty sure it's already provided in a variable.

3 3

Re: [Wikitech-l] [MediaWiki-CVS] SVN: [38704] trunk/extensions/Translate/MessageChecks.php
by Rotem Liss 06 Aug '08

06 Aug '08

nikerabbit(a)svn.wikimedia.org wrote: > Revision: 38704 > Author: nikerabbit > Date: 2008-08-06 10:57:38 +0000 (Wed, 06 Aug 2008) > > Log Message: > ----------- > * Revert r38702 > Warning: array_splice() [function.array-splice]: The first argument should be an array in /var/www/sandwiki/extensions/Translate/TranslateEditAddons.php on line 263 > Warning: Missing argument 2 for wfMsgExt() in /var/www/sandwiki/includes/GlobalFunctions.php on line 613 > Notice: Undefined variable: options in /var/www/sandwiki/includes/GlobalFunctions.php on line 620 > Notice: Undefined variable: options in /var/www/sandwiki/includes/GlobalFunctions.php on line 621 > Where (i.e. in which page exactly) are the errors shown?

2 2

Wikimedia foundation, wikipedia and google
by Andrew Cates 06 Aug '08

06 Aug '08

Sorry if this is slightly off topic but people on this list are most likely to know the answer. It would help a lot fundraising for the Wikimedia foundation if google threw some searches like "educational charity", "endow education" or "donate now" onto the WMF site. I know from my day job there are tens of millions of dollars of donations just being guided by google main search results. But google doesn't put wmf high up, and AFAICT is doing something odd, examples: 1) en has a site wide link to "privacy policy" on the wikimedia foundation site but google even prefers the actual article on privacy policy (a crappy stub) on en in its search results. This article has a much smaller number of inlinks from a subset of the pages, and official links from another website should be more influential than internal links. This comparison is still true if you do "allinanchor" on google too so it isn't a page content issue. 2) With firefox "google toolbar" I can see that every internal sitewide link on en has a page rank of at least 8 but the WMF ones are 6 or 7, even though they have links from all the other projects as well. This has been the case for ages even when page ranks all around the place have changed. My theory: The links to WMF are not marked "nofollow" by wikipedia but google has done some sort of manual nofollow on them because they do not like (and have said they don't like) the fact wikipedia blanket nofollows and does not differentiate good and back links. Ok, its a theory and another reason (yawn) for implementing a greenlist as was proposed 18 months ago (see http://en.wikipedia.org/wiki/User:BozMo/greenlist). Alternatively, WP should change the links to an internal link and do the jump out using a permanent divert which will probably fix it if we only need to do it for the WMF pages and don't care about wikia etc. Other theories: ? I would be very interested to know. BozMo

1 0

← Newer
1
2
3
4
5
6
7
8
9
Older →

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 2008