[crossposted to foundation-l and wikitech-l]
"There has to be a vision though, of something better. Maybe something
that is an actual wiki, quick and easy, rather than the template
coding hell Wikipedia's turned into." - something Fred Bauder just
said on wikien-l.
Our current markup is one of our biggest barriers to participation.
AIUI, edit rates are about half what they were in 2005, even as our
fame has gone from "popular" through "famous" to "part of the
structure of the world." I submit that this is not a good or healthy
thing in any way and needs fixing.
People who can handle wikitext really just do not understand how
offputting the computer guacamole is to people who can cope with text
they can see.
We know this is a problem; WYSIWYG that works is something that's been
wanted here forever. There are various hideous technical nightmares in
its way, that make this a big and hairy problem, of the sort where the
hair has hair.
However, I submit that it's important enough we need to attack it with
actual resources anyway.
This is just one data point, where a Canadian government office got
*EIGHT TIMES* the participation in their intranet wiki by putting in a
(heavily locally patched) copy of FCKeditor:
http://lists.wikimedia.org/pipermail/mediawiki-l/2010-May/034062.html
"I have to disagree with you given my experience. In one government
department where MediaWiki was installed we saw the active user base
spike from about 1000 users to about 8000 users within a month of having
enabled FCKeditor. FCKeditor definitely has it's warts, but it very
closely matches the experience non-technical people have gotten used to
while using Word or WordPerfect. Leveraging skills people already have
cuts down on training costs and allows them to be productive almost
immediately."
http://lists.wikimedia.org/pipermail/mediawiki-l/2010-May/034071.html
"Since a plethora of intelligent people with no desire to learn WikiCode
can now add content, the quality of posts has been in line with the
adoption of wiki use by these people. Thus one would say it has gone up.
"In the beginning there were some hard core users that learned WikiCode,
for the most part they have indicated that when the WYSIWYG fails, they
are able to switch to WikiCode mode to address the problem. This usually
occurs with complex table nesting which is something that few of the
users do anyways. Most document layouts are kept simple. Additionally,
we have a multilingual english/french wiki. As a result the browser
spell-check is insufficient for the most part (not to mention it has
issues with WikiCode). To address this a second spellcheck button was
added to the interface so that both english and french spellcheck could
be available within the same interface (via aspell backend)."
So, the payoffs could be ridiculously huge: eight times the number of
smart and knowledgeable people even being able to *fix typos* on
material they care about.
Here are some problems. (Off the top of my head; please do add more,
all you can think of.)
- The problem:
* Fidelity with the existing body of wikitext. No conversion flag day.
The current body exploits every possible edge case in the regular
expression guacamole we call a "parser". Tim said a few years ago that
any solution has to account for the existing body of text.
* Two-way fidelity. Those who know wikitext will demand to keep it and
will bitterly resist any attempt to take it away from them.
* FCKeditor (now CKeditor) in MediaWiki is all but unmaintained.
* There is no specification for wikitext. Well, there almost is -
compiled as C, it runs a bit slower than the existing PHP compiler.
But it's a start!
http://lists.wikimedia.org/pipermail/wikitext-l/2010-August/000318.html
- Attempting to solve it:
* The best brains around Wikipedia, MediaWiki and WMF have dashed
their foreheads against this problem for at least the past five years
and have got *nowhere*. Tim has a whole section in the SVN repository
for "new parser attempts". Sheer brilliance isn't going to solve this
one.
* Tim doesn't scale. Most of our other technical people don't scale.
*We have no resources and still run on almost nothing*.
($14m might sound like enough money to run a popular website, but for
comparison, I work as a sysadmin at a tiny, tiny publishing company
with more money and staff just in our department than that to do
*almost nothing* compared to what WMF achieves. WMF is an INCREDIBLY
efficient organisation.)
- Other attempts:
* Starting from a clear field makes it ridiculously easy. The
government example quoted above is one. Wikia wrote a good WYSIWYG
that works really nicely on new wikis (I'm speaking here as an
experienced wikitext user who happily fixes random typos on Wikia). Of
course, I noted that we can't start from a clear field - we have an
existing body of wikitext.
So, specification of the problem:
* We need good WYSIWYG. The government example suggests that a simple
word-processor-like interface would be enough to give tremendous
results.
* It needs two-way fidelity with almost all existing wikitext.
* We can't throw away existing wikitext, much as we'd love to.
* It's going to cost money in programming the WYSIWYG.
* It's going to cost money in rationalising existing wikitext so that
the most unfeasible formations can be shunted off to legacy for
chewing on.
* It's going to cost money in usability testing and so on.
* It's going to cost money for all sorts of things I haven't even
thought of yet.
This is a problem that would pay off hugely to solve, and that will
take actual money thrown at it.
How would you attack this problem, given actual resources for grunt work?
- d.
Dear dev's,
I am wondering whether the Mediawiki db contains a foreignkey
relationship between a main namespace article and the associated talk
page (if present).
Having this information would greatly simplify analytic projects to
monitor editor behaviour and understanding revert behaviour (among
other topics).
Currently, I am manually matching these two sets of pages by matching titles.
I have two questions:
1) If this foreignkey does not exist, would it be worthwhile to create it?
2) If this foreignkey does exist, what would it take to expose this in
the XML dumps?
Best regards,
Diederik
I completed the translation of FlaggedRevs into Hebrew and i would
like to test it.
It is already installed on he.wikisource and the admins there agree
that i'll play with it and gave me reviewer rights.
My question is: Is there a proper manual test suite for FlaggedRevs,
which guides the tester through all the possible permutations of
revision levels and relevant messages? This must be manual, because
the translation uses many PLURAL tricks and there many messages that
are similar except small wording changes, but all of them must be
checked.
Thanks,
--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
"We're living in pieces,
I want to live in peace." - T. Moore
It looks like the Wikipedia database dump process is completely idle at
the moment, with nothing having changed since the crash.
Does anyone know when the dumps are likely to resume, or, if not, what
the current status of the work on the dump system is?
-- Neil
Hi everyone,
Here's a quick update on the 1.17 release of Mediawiki. The code
review group continues to make headway on the backlog of outstanding
checkins in "new" status. We peaked at 1400 unreviewed checkins back
in September, last month we were at 800, and now we're now under 300.
We *hope* this means we can push a 1.17 version of MediaWiki to
production sometime this month, with a tarball available some time
after that. That still looks like a bit of a stretch goal, but more
plausible now than the last time this came up.
The roadmap is more-or-less up-to-date at this point (though some of
the info from this mail should probably find its way onto the page:
http://www.mediawiki.org/wiki/MediaWiki_roadmap/1.17
As of earlier today, there's a tracking bug for the few bugs that
still need to be fixed (thanks bawolff!):
https://bugzilla.wikimedia.org/show_bug.cgi?id=26611
The trendline for 1.17 is looks pretty good for us to get through the
code review backlog for the most part:
http://toolserver.org/~robla/crstats/crstats.117branch.html
(focus on "new" hitting zero).
However, there's still much to do. We really should get a good grip
on testing this release. Roan set up a prototype wiki, and I did some
mucking with it[1], so it's somewhat similar to production:
http://prototype.wikimedia.org/deployment-en/Main_Page
Other languages are set up too (ar, de, es, fr, it, ja, ko, nl, pl,
ru, si, sr, zh). Links can be found on deployment-en's homepage.
Note that only the barest of spot checking was done, and it appears at
least one (ar) is broken as of this writing.
One known issue on deployment-en is that Pending Changes/FlaggedRevs
isn't configured properly (still looks like FlaggedRevs, so you'll see
"unchecked" at the top of all of the articles). Once we get things
set up a little better, it should be a good environment for testing.
Rob
[1] p.s. Roan: here's the mucking around that I did. I enabled
FlaggedRevs as noted above, and ran update.php. I disabled
LabeledSectionTransclusion because of an error in
LabeledSectionTransclusion::setup
According to its website, "phpQuery is a server-side, chainable, CSS3
selector driven Document Object Model (DOM) API based on jQuery JavaScript
Library."
I feel it will be very convenient if we introduce such jquery-like tools
into MediaWiki since we do have the need to parse HTML text. For example, I
can replace the awful regex part of LanguageConverter::autoConvert with
phpQuery.
So I want to ask is it possible to introduce phpQuery into MediaWiki?
sincerely,
Philip Tzou
The way you completely lose your page tabs when switching to
Special:MovePage has been a bother to me for awhile... it's bad
interface design to have a set of tabs linking to other pages with the
same set of tabs, but to have a single one of them strangely point to a
page where those tabs completely disappear.
1.18 has a new feature now. From a special page you can call
$skin->setRelatedTitle and $skin->setRelatedTitle. Calling
setRelatedTitle will mark a title as relevant to the current page, doing
so will cause some parts of the ui (namely the page tabs) to display
things relevant to that page. Calling setRelatedUser likewise will cause
some parts of the ui (namely the toolbox) to display things that they
would display if you were on the user's userpage. These methods are
currently used by Special:MovePage (title), Special:Undelete (title),
Special:Contributions (user), and Special:BlockIp (user). If you have
another special page you feel is relevant enough to use these methods
feel free to tweak it's code.
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
http://davidgerard.co.uk/notes/2011/01/04/what-you-see-is-for-the-win/comme…
Someone suggested this on my blog. It's an *excellent* idea and needs
a button added for it in the present Vector editor.
Jen says:
Wednesday 5th January, 2011 at 10:28 pm (Edit)
Re John Broughton’s idea for “a **single click** way of generating the
standard text/code for a footnote”…
Would there be any way to make a nice little bookmarklet so people
could drag a URL onto the button, and it would copy a wiki-citation to
the clipboard?
- d.
In the early years 2005-2007, lots of small articles were
created in the Swedish Wikipedia, assuming that they would
all grow with time (eventualism [1]) and the important thing
was to have many articles. Some articles were marked as stubs
or substubs, in a random and entirely subjective way. This
changed in 2008, when we started to count the length of
articles, to identify the shortest ones, and started to
systematically extend or merge them into better articles.
It's now much easier to identify a new article as being
far too short, and to treat this as an urgent problem.
Now, I'm feeling we're having the same problem with
categories. Some people create lots of subcategories
for ever more specialized subdivisions of a topic.
Especially, "companies established in 1974" gets
divided into subcategories for different businesses [2].
Many of the new categories have only very few members.
But we have no principles for understanding whether this
really is a problem and no tools to get an overview.
We have no way to assess the harm of subdividing
a category. If it was only me and my feeling, I would
tell them to stop doing this. But this is not enough
for a consensus decision.
What tools are there to count the number of categories,
sort them by the number of members (subcategories and
articles), and to determine which branches of the
category tree should be pruned?
As for "law firms established in 1974", one can't
remove that single category without reconsidering the
entire "law firms by year of establishment" structure.
So a tool should consider at least 2 levels.
Which languages of Wikipedia have best organized category
trees? I know the German Wikipedia is different. It is
often hard to make interwiki links to its categories, but
most of the rest seem to build on quite similar ideas.
[1] http://meta.wikimedia.org/wiki/Eventualism
[2] http://sv.wikipedia.org/wiki/Kategori:F%C3%B6retag_bildade_1974
--
Lars Aronsson (lars(a)aronsson.se)
Aronsson Datateknik - http://aronsson.se