Bugs, Repairs, and Internal Operational News

Vector rolled-out to more wikis, becomes default

This week saw the implementation of two stages in the replacement of the old default "Monobook" skin with the new "Vector" skin. Firstly, in a blog post the Wikimedia Foundation announced its intention to switch more of its wikis over:

“

We began with Wikimedia Commons and have since rolled out the interface to 10 Wikipedias. In the next phase of the roll-out, we are planning to target as many of the remaining Wikipedia projects as we can ... targeting June 30 for deployment.

We want to make sure that the Wikipedias ... are adequately translated before the features are introduced, [and those with] at least 80% of their user interface messages translated by June 28 will be included in the next phase of the roll-out.

”

The blog stated that as of June 21, some 60 Wikipedias meet that threshold, and that other Wikipedias will receive the new features in the final phase, currently scheduled for the end of July.

In the second stage, rolled out on June 25, all new private (non-WMF) wikis received Vector as their default skin, replacing Monobook. They retain the option to reinstate Monobook or to switch to a different skin altogether.

'RevisionMove' in development

In October last year, User:FT2 commented that:

“

With RevisionDelete in action, the only time that delete + partial undelete is needed is for complex history merges and fixing copy/paste moves. It seems cumbersome that admins must repeatedly delete and part-undelete to selectively move revisions and repair cut/paste moves. If there was a "selective revision move" feature that allowed administrators to select various revisions on a page and move them to another page somehow (in line with the needs of page merge and copypaste fixing), this would greatly simplify page merges and copypaste fixing.

”

It now seems that a new "RevisionMove" feature is now slowly working its way towards WMF wikis. Still in early development by User:Church of emacs, it is likely to require significant testing before it can be deployed to sites like the English Wikipedia. See bug #21312 for further discussion of the idea.

In brief

Note: not all fixes may have gone live to WMF sites at the time of writing, and some may not be scheduled to go live for many weeks.

The ability to redact edit filter logs has been added. The filter previously retained details of pages regardless of whether the page in question had ever existed, since been deleted, or even been oversighted (bug #18043).

Bug #23903 has been fixed, adding the new magic word {{#pagesusingpendingchanges}}.

With the closure of bug #4597 (an outstanding request from early 2006), users will get the option of filtering contributions lists based on whether or not that edit is still the most recent edit to a page.

noc.wikimedia.org, which provides up-to-date copies of files not included in the Wikimedia subversion (SVN) repository, now applies appropriate syntax highlighting to many of its files.

← Previous "Technology report"

Next "Technology report" →

In this issue

28 June 2010 (all comments)

Objectionable material

News and notes

In the news

Public Policy Initiative

WikiProject report

Features and admins

Arbitration report

Technology report

+ Add a comment

Discuss this story

These comments are automatically transcluded from this article's talk page. To follow comments, add the page to your watchlist. If your comment has not appeared here, you can try purging the cache.

"noc.wikimedia.org, which provides up-to-date copies of files not included in the Wikimedia subversion (SVN) repository, now applies appropriate syntax highlighting to many of its files." Maybe I'm missing something you're saying here, but the syntax highlighting is nothing new. ^demon^{[omg plz]} 13:24, 29 June 2010 (UTC)[reply]
- I think maybe it's more (?) syntax highlighting "07:38 JeLuF: enabled PHP modules on fenari so that noc.wikimedia.org deliveres syntax highlighted config files." - I was kinda guessing what he meant by "config", I assume a large number of files but it was just a guess. - Jarry1250 ^{[Humorous? Discuss.]} 19:11, 30 June 2010 (UTC)[reply]
Vector is terrible. I hops that it doesn't become the default on Wikibooks. Kayau Voting IS evil 13:02, 1 July 2010 (UTC)[reply]

Could somebody reply with a link to any actual statistics that conclusively show that Vector is liked by users more than Monobook? Has any usability study been done here? Jason Quinn (talk) 18:47, 2 July 2010 (UTC)[reply]
- Well, the usability study said "X, Y, and Z components of Monobook need improving". Vector is an attempt to ease that. Statistics exists for the number of people who opted-out of Vector; I can't recall the exact figure, but it was something like 10%. No-one has yet, to the best of my knowledge, asked the readers which they prefer. - Jarry1250 ^{[Humorous? Discuss.]} 19:21, 2 July 2010 (UTC)[reply]
  - Thanks, Jarry1250. I hadn't seen that number before. Ten percent actually sounds like an very large percentage to me. It seems to me like the bulk of users never go out of their way to change anything (think IE, etc.). Jason Quinn (talk) 23:42, 2 July 2010 (UTC)[reply]
    - Well maybe a better stat would be that 17% of users that opted in to the trial opted out again before Vector went live. Since both processes were one, possibly two clicks - and Vector has by most people's estimations got better since then - I think it's fair to draw the conclusion that most editors prefer Vector. Maybe not all, but most. - Jarry1250 ^{[Humorous? Discuss.]} 10:59, 3 July 2010 (UTC)[reply]