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.
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
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
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
>
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
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
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.
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?
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