Extensions access only:
* Arthur Richards (awjrichards): Fundraising (WMF staff member)
* Frank Dengler (fde): Semantic Result Formats, other SMW extensions
Access upgraded from extensions to core:
* Jeroen De Dauw: New installer
-- Tim Starling
Hi folks,
I wanted to highlight bug 24124, because there's a possible fix for it, and
I'm hoping we can get a lot of eyes on this one and then hopefully
fast-track it into production if that's possible.
Here's the link:
https://bugzilla.wikimedia.org/show_bug.cgi?id=24124
The problem: diffs are taking 10 to 20 seconds to load on large pages. This
problem doesn't appear to be caused by the FlaggedRevs extension, but it
becomes a lot more noticeable when the extension is enabled. Diffs are
pretty central to the workflow of the feature, and many people have
complained that the feature isn't very usable in its current state.
Chad and Aaron spent some time investigating this problem, and figured out
that we're not using the cache where we probably should be. Chad just
checked in a patch that fixes this:
http://www.mediawiki.org/wiki/Special:Code/MediaWiki/69191
Please take a look at this one, and let us know if we have a fix.
Thanks!
Rob
> Message: 7
> Date: Mon, 5 Jul 2010 09:50:30 +0200
> From: Alex Brollo <alex.brollo(a)gmail.com>
> Subject: Re: [Wikitech-l] [Wikisource-l] Wikisource bugs
> To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
> Message-ID:
> <AANLkTikVqqg2--7_Emi0m5l6Mg3JP8qwulFE-tA1pHd-(a)mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Far from the idea of splitting down wikisource family into fighting groups,
> the post of Helder underlines how much would be important to keep in contact
> different projects and to find common troubles and strategies.
>
> Another example is the use of *DynamicPageList extension*: it is used into
> wikinews only, but it would be great into wikibooks and wikisource too to
> produce good, updated lists by "virtual categories intersection".
>
> Alex
Note, Wikibooks actually does have DynamicPageList.
Cheers,
Bawolff
On 07/05/2010 10:45 AM, ThomasV wrote:
> I do not agree with you on namespaces.
>
> I think that the "Page" namespace is the
> best way to handle the separattion between
> the physical object (a book and its pages)
> and the logical object that we present to
> readers (the text, divided in sections or chapters)
I agree that having two structures (physical pages
and chapters) is a challenge (I even wrote a paper
about this, eleven years ago), but the introduction
of the Page: namespace is not without problems.
Moving the physical structure to its own namespace is
based on the assumption that a separate presentation
structure (the chapters of the book) exists and is the
more important one. But for odd formats such as
dictionaries or newspapers, this is far from obvious.
Should each dictionary entry become a chapter of its own?
One dictionary might have 150,000 entries.
For newspapers, it's easy to agree that each major news
article can be a chapter of its own. But maybe not each
small advertisement? Should the whole ad section be one
chapter? People might want to search these ads. They can
be far more important to current readers than the news.
So treating them as whitespace is not a solution.
In such cases, it might be best to just proofread the
physical page and keep it as it is. Even for ordinary
books, while they are being proofread, which can extend
for months or years, only the physical structure exists.
But then the Page: is what will be exposed to the public
reader. So maybe it should be dressed up with the green
{{header}} to look nicer?
Already today, we have the problem that searches
using the site's own search box will show content in
the Page: namespace, rather than the transcluded
chapters in the main namespace (related to
https://bugzilla.wikimedia.org/show_bug.cgi?id=18861 )
and there are no links from the found Page: to the
chapters that transclude its text, unless you bother
to use "what links here".
Wikistats (Erik Zachte) also reports user activity based on
the main namespace. It's odd that on Wikisource, the "other"
namespaces have far more editing activity than the main one.
For a dictionary, creating 150,000 tiny pages that each
transclude 2 lines of text is not a good match for the
current wiki technology. Having dozens of <section.../>
tags in each page, will also look very clumsy. It would
be comfortable if the section markers were much smaller,
and treated like anchor points. Search should also
return the closest preceding anchor point (even if that
is on a preceding page), rather than the page URL.
The Bible, being one of the oldest texts on Wikisource,
is a good test case. It consists of 2 testaments, 66 books,
1189 chapters and 31,103 verses. When printed on paper,
it typically fits on 1200 physical pages. Today we typically
create one wiki page per book or per chapter, e.g.
http://en.wikisource.org/wiki/Bible_(King_James)/Matthew
and this is what turns up in searches, since it was imported
from existing e-texts, rather than being proofread in Wikisource.
These 66 or 1189 wiki pages have headlines for each chapter
and anchor points for each verse, but these are not presented
in the search results. Imagine you could search "candle under bushel"
and up comes "Matthew 5:15", even if you had a proofread
but not yet transcluded version divided into 1200 wiki
pages in the Page: namespace. Today search turns up things
such as "Page:The Granite Monthly Volume 5.djvu/82",
which simply isn't pretty.
In my eyes, this means: 1) many problems (e.g. search) are
generic problems, not connected with ProofreadPage, and
2) the existing ProofreadPage (PR2) may work okay for
traditional books with chapters, but it can also co-exist
with an alternative ProofreadPage that works better for
dictionaries and newspapers.
Next, consider digitizing old maps with Wikisource, and
matching them (through coordinate transformation) with
OpenStreetMap.
--
Lars Aronsson (lars(a)aronsson.se)
Aronsson Datateknik - http://aronsson.se
On 07/01/2010 12:22 PM, ThomasV wrote:
> I apologize for the length of my answer. I wish to thank those who
> have had the patience to read this entire post.
The problem is not a long post or two, but the fact that
you seem to have locked yourself to this single issue.
I'd like to discuss some far more visionary changes
in how Wikisource works, but all you can talk about are
these two stages of proofreading.
Let me start from another angle: Does anybody have
experience from teaching beginners how to contribute
to Wikisource? What are the hardest concepts to explain?
I think we should compile and rank the current obstacles
to the growth of Wikisource.
Just as one example, I would put the multiple namespaces
(Index: and Page:) pretty high on that list, and I think
that a redesign could do away with them. There was indeed
a bug report filed for something similar, from the Polish
community, that wanted to disconnect the naming of Index
pages from the naming of PDF/Djvu files:
"<pagelist> should have file parameter",
https://bugzilla.wikimedia.org/show_bug.cgi?id=21398
ThomasV replied with "WONTFIX", which is understandable
since this is not a simple bug fix, but a more complicated
change of architecture. The problem is that this
architecture was never documented, so we don't know
which the design decisions are. Or was it?
This is just one example of how Wikisource is really
overly complicated, putting extra burden on newcomers,
and where Wikisource would benefit from a redesign.
But my suggestion is that we start to compile a catalog
of such problems, rather than submitting bug reports.
Where is a good place to start?
--
Lars Aronsson (lars(a)aronsson.se)
Aronsson Datateknik - http://aronsson.se
On 4 July 2010 21:20, William Pietri <william(a)scissor.com> wrote:
> No, which makes it especially worth appreciating, on three levels.
> First, is says something good about the person. Second, it can really
> move a discussion along. And third, it serves as an example for future
> discussions, like begetting like. So thanks!
I can't promise not to be a [[m:DICK]] in the future, because I have a
horrible susceptibility to it. Oh well. (This is why I smell funny,
have no mates and am dressed by my mother.)
The best thing to answer de:wp's original concern is: fix the specific
problems in Vector very quickly indeed. (Does it work on old
Blackberrys yet?) Because Vector is test-proven to actually be a
better skin for the newbie. But we need to do all the long-tail stuff
too. As people know already.
Does de:wp have a list of specific problems with the current version of Vector?
(I may be biased, as I switched to Vector the moment the beta was
announced and have loved using it since.)
- d.
On 4 July 2010 00:34, Liam Wyatt <liamwyatt(a)gmail.com> wrote:
> You have started with a theoretical question that is complex and interesting
> - about the languages/project's relationship to the MediaWiki skin. You have
> received a very thorough and well reasoned answer from both the head
> software developer and deputy director of the WMF answering this question
> with nuance. You can't ask an "open" question and expect/demand a "closed"
> response.
Well. not really. He's asking the same question Greg Maxwell and I
asked last month about the language list defaulting to open rather
than closed: If a wiki voted for it, would that override the usability
team's dictates? That was a straight "yes or no" question, like this
is, and we only got weaseling too.
I asked on internal-l and couldn't get a straight answer there either.
Straight answer, anyone?
- d.
Hey,
I would like to have core commit access. I have requested this in the past,
but did not get it. I see no reason for this, as you can revert any change I
make, and can also revoke my access when I'm messing up things, which I do
not intend to do. I have not been able to make a few dozen small
improvements and fixes all over the code because of this. So can someone
please give me access, preferably before the heat death takes place?
Cheers
--
Jeroen De Dauw
* http://blog.bn2vs.com
* http://wiki.bn2vs.com
Don't panic. Don't be evil. 50 72 6F 67 72 61 6D 6D 69 6E 67 20 34 20 6C 69
66 65!
--
Regarding:
https://secure.wikimedia.org/wikipedia/en/w/index.php?title=Wikipedia:Pedop…
How is it that user Kotniski (autopatrolled, reviewer, rollbacker)
can currently edit a page which is full protected at the moment:
(del/undel) 20:52, 29 June 2010 Georgewilliamherbert (talk | contribs
| block) changed protection level of Wikipedia:Pedophilia [edit=sysop]
(expires 09:42, 2 July 2010 (UTC)) [move=sysop] (expires 09:42, 2 July
2010 (UTC))
Am I missing something, or did the protection permissions get borken
at some point?
--
-george william herbert
george.herbert(a)gmail.com