Aryeh Gregor | 1 Jan 02:10 2009
Picon

Re: Deprecate 'sysop' throughout MediaWiki?

On Wed, Dec 31, 2008 at 6:00 PM, Chris Down
<neuro.wikipedia <at> googlemail.com> wrote:
> As far as I am aware, the term 'sysop' is only used on more behind the
> scenes places - places where the average Wikipedia editor or reader is not
> likely to go. Sysop is, at least in my opinion, the more technically adept
> term, but I suppose the traditional meaning of it does not describe the job
> of a Wikipedia administrator correctly.
>
> I think a wide consensus needs to be gathered before such a change is made,
> even if it is perhaps considered relatively minor.

Note that individual wikis could change back if they liked it.  We're
talking about the software defaults here, not enwiki or any other
single wiki.
Brion Vibber | 1 Jan 03:13 2009
Picon

Last code update of 2008!


Code Review Tuesday took a little extra long this week. ;) But it's
still 2008 here in California, so let's get this party started!

http://www.mediawiki.org/wiki/This_week%27s_updates to r45274 now live...

And in the next couple days I plan to start rolling out some things that
have been in testing, and rolling out new tests of things we didn't
quite get enabled on test yet:

http://www.mediawiki.org/wiki/Things_to_start_testing_in_2009
(this list will expand over the coming days)

We'll also start firming up a roadmap for coming activity... 2009's
gonna be sweet!

-- brion
Siebrand Mazeland | 1 Jan 16:54 2009
Picon
Picon

An update on localisation in MediaWiki (2008)

On 31 December 2007 I sent an e-mail, to which this is a follow up[1].

First things first, because not everyone reads e-mails completely:
* MediaWiki localisation (that is the translation of English source messages
to
  other languages) depends on you! If you speak a language other than
English,
  care about this and like translating, go to http://translatewiki.net,
register
  a user and start contributing translations for MediaWiki messages and
  extension messages. When your localisation is complete, keep coming back
  regularly to re-complete it and do quality control. Thank you in advance
for
  all your contributions and effort.
* The i18n and L10n area of MediaWiki requires continuous efforts. If this
area
  of FOSS has your interest, please do not hesitate and offer your
development
  skills to further MediaWiki's i18n and L10n capabilities[5,6].

All statistics are based on MediaWiki 1.14 alpha, SVN version r45277
(1 January 2009). Comparisons are to MediaWiki 1.12 alpha, SVN version
r29106
(31 December 2007).

==Introduction==
* Localisation or l10n - the process of adapting the software to be as
familiar
  as possible to a specific locale (in scope)
* Internationalisation or i18n - the process of ensuring that an application
(Continue reading)

Juliano F. Ravasi | 1 Jan 19:38 2009

Re: On extension SVN revisions in Special:Version

Brion Vibber wrote:
> 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.

Yes, this is the biggest argument against the use SVN keywords. SVN
keywords exist mostly for compatibility with CVS, otherwise, their use
is highly discouraged. If you need really want to use such type of
version numbering, you should consider creating some code that runs
'svnversion' and use its output as the version number. 'svnversion'
number also reflects working copies with mixed revisions and in modified
state.

But 'svnversion' itself has other problems. It has to quickly recurse
into all subdirectories in order to calculate the revision number. If
run once every (standalone) application startup, it is ok... for not for
a web application.

But the whole idea of using SVN version numbering for something outside
revision control is still problematic.

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

This brings another set of problems. Check this for example:

	http://juliano.info/en/Special:Version
(Continue reading)

Chad | 2 Jan 01:22 2009
Picon

Re: On extension SVN revisions in Special:Version

Perhaps ditching the absolutely useless svnversion param to
$wgExtensionCredits entirely. Its redundant to version and provides (as
mentioned) nothing of any real use.

-Chad

On Dec 31, 2008 4:54 PM, "Brion Vibber" <brion <at> wikimedia.org> wrote:

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

(Continue reading)

Mark Clements (HappyDog | 2 Jan 17:15 2009
Picon

Re: Deprecate 'sysop' throughout MediaWiki?

"Remember the dot" <rememberthedot <at> gmail.com> wrote in message 
news:17aa57b60812311420t3b3f548dj58ca1b6c992c4ee2 <at> mail.gmail.com...
> For what it's worth, I agree that the term "administrator" should be
> consistently used in MediaWiki instead of using both "administrator" and
> "sysop".
>

I agree.  To me, a wiki administrator is someone with full privileges on the 
wiki, and a sysop is someone with server privileges who can do all the 
technical back-end bits e.g. installing extensions, running maintenance 
scripts, modifying LocalSettings.php, etc.  Using sysop within the software 
implies more powers than are actually available, at least it does to me.

In software I have developed, we tend to use sysadmin and techadmin to 
differentiate the two.

- Mark Clements (HappyDog). 
Ángel | 2 Jan 17:35 2009
Picon

MediaWiki offline reader

I'm hereby presenting a new Offline Reader for MediaWiki. Already
presented last year
on another mailing list, here it is explained in depth, for the
technical community.

The impatients can go directly to
http://www.wiki-web.es/mediawiki-offline-reader/
and download some samples.

Note: Almost all docs are in Spanish only, so if you have an special
interestest
on some of them, or don't mind on them not being in English, just ask. :-)

The application works from the wiki text found in XML dumps, and
includes MediaWiki
to parse them. Unlike other existing programs[1], MediaWiki isn't
working in a web server
fashion, the whole app is written in PHP, using PHP-GTK [2]. MediaWiki
is run as a
subquery, using the runkit extension [3]. The html result is fed back to
GtkIEEmbed for the
display.
The format for the files, is the same XML as the dumps, and the problem
of bzip files being
too big [5] is overcome by using separated borrow-wheels blocks (in
fact, for easiness I'm
using full bzip2 files concatenated) each N articles. Similar to the
(independent) approach
taken by Thanassis Tsiodras (ttsiod) on [6]. However, instead of
splitting the existing files,
(Continue reading)

David Gerard | 2 Jan 19:00 2009
Picon

There's hack value ...

... and then there's Dangerously Batshit Insane.

https://dgl.cx/wikipedia-dns

- d.
Ilmari Karonen | 2 Jan 20:18 2009
Picon

Re: There's hack value ...

David Gerard wrote:
> ... and then there's Dangerously Batshit Insane.
> 
> https://dgl.cx/wikipedia-dns

:)  Well, on the subject of abusing DNS...

http://dnstunnel.de/

--

-- 
Ilmari Karonen
Aryeh Gregor | 2 Jan 22:12 2009
Picon

Re: Section anchor encoding

Current status on this in trunk:

1) All links that I tested work on Firefox 3, IE5, IE5.5, IE6, and at
least one version of recentish Opera.  Still needs testing on IE7, IE8
beta, WebKit, and older Firefox.

2) There are no legacy anchors in place.  In other words, old links
will all break.  This should be reasonably easy to fix, although more
than two or three lines (need to maintain and check a second array in
Parser::formatHeadings() to get the numbering right).

3) Redirects to section after edit work in Firefox, but fail in IE5,
5.5, and 6, whether the HTTP response URL is urlencoded or not.  With
(2) fixed, these could redirect to the legacy anchor in known broken
user agents.  This might require some refactoring.

Gmane