-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
robchurch(a)svn.wikimedia.org wrote:
> Move all watchlist editing into WatchlistEditor class, integrating
> "raw editing" from ExportWatchlist extension, per Brion. Spiffed up the
> existing editor and "clear" interface; all three editors better
> integrated from a UI perspective.
Looks good!
> + $titles = $this->extractTitles( $request->getText( 'titles' ) );
> + $this->clearWatchlist( $user );
> + $this->watchTitles( $titles, $user );
> + $user->invalidateCache();
This raw edit save will reset the last-seen timestamps for all watched
pages, which could hurt a bit for people using email notification.
Doing an array diff and only adding/removing the changed items should
work cleaner for that case, plus save some DB activity when making small
changes to a large watchlist.
[snip]
> + $rows[] = array(
> + 'wl_user' => $user->getId(),
> + 'wl_namespace' => ( $title->getNamespace() & ~1 ),
> + 'wl_title' => $title->getDBkey(),
> + 'wl_notificationtimestamp' => null,
> + );
> + $rows[] = array(
> + 'wl_user' => $user->getId(),
> + 'wl_namespace' => ( $title->getNamespace() | 1 ),
> + 'wl_title' => $title->getDBkey(),
> + 'wl_notificationtimestamp' => null,
> + );
This low-level code makes some surprises in corner cases. :)
If you pass a Special: or Media: title, it accepts them and treats them
as an article-talk pair. Interwiki titles are also accepted, treated as
normal pages.
Probably these unwatchable titles should get stripped out of the stream,
either here or at the high-level UI end.
I'd also recommend moving the low-level DB routines over to WatchedItem,
which IIRC already has some batch-change functions.
> + }
> + }
> +
> + /**
> + * Show the standard watchlist editing form
> + *
> + * @param OutputPage $output
> + * @param User $user
> + */
> + private function showNormalForm( $output, $user ) {
> + if( ( $count = $this->showItemCount( $output, $user ) ) > 0 ) {
> + $self = SpecialPage::getTitleFor( 'Watchlist' );
> + $form = Xml::openElement( 'form', array( 'method' => 'post',
> + 'action' => $self->getLocalUrl( 'action=edit' ) ) );
> + $form .= Xml::hidden( 'token', $user->editToken( 'watchlistedit' ) );
> + $form .= '<fieldset><legend>' . wfMsgHtml( 'watchlistedit-normal-legend' ) . '</legend>';
> + $form .= wfMsgExt( 'watchlistedit-normal-explain', 'parse' );
> + foreach( $this->getWatchlist( $user ) as $namespace => $pages ) {
> + $form .= '<h2>' . $this->getNamespaceHeading( $namespace ) . '</h2>';
> + $form .= '<ul>';
> + foreach( $pages as $dbkey => $redirect ) {
> + $title = Title::makeTitleSafe( $namespace, $dbkey );
> + $form .= $this->buildRemoveLine( $title, $redirect, $user->getSkin() );
The makeTitleSafe() reminds me of the possibility of invalid entries in
the watchlist table; those may not roundtrip nicely through the raw edit
form. Just something to consider... automatic cleanup (for instance when
namespaces change in weird ways) might be appropriate.
> +'watchlistedit-normal-explain' => 'Titles on your watchlist are shown below. To remove a title, check
> + the box next to it, and click Remove Titles. You can also [[Special:Watchlist/raw|edit the raw list]],
> + or [[Special:Watchlist/clear|remove all titles]].',
The mode links here feel buried in the UI text to me; it's not obvious
to me that it's there. It might be interesting to try a more tab-like
link here, maybe just simple links like on Special:Allmessages
- -- brion vibber (brion @ wikimedia.org)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGjQzrwRnhpk1wk44RAgkzAKCc3hHZ1cZ7bqyxP8cCfjKbkslSlACg1iK9
D8Yudgby5V+cIRFZkj3dHPY=
=AUVS
-----END PGP SIGNATURE-----
Dear Brion, Tim et al,
Just simple surveys:
1. Do you want to have a time slot to report/listen the result of
Hacking Days in main conference of Wikimania 2007?
2. If so, which one is preferred from 8/3, 8/4, and 8/5?
Tzu-Chiang Liu in the CC list is one of program committee this year, he
would like to know about it and to arrange
time and space for you.
Sincerely,
/Mike/
After a year of diligent effort, a group of nearly 50 dedicated users
and developers are proud to release WikiCreole 1.0. Creole is designed
to be a common wiki markup language which augments existing markup to
enable wiki users to transfer content seamlessly across wikis, a boon
to novice and expert users alike.
Creole, taking its name from the field of linguistics, a stable
language that originated from a combination of two or more languages.
As every wiki software has its own markup definitions, the differences
can make them difficult for novices to learn and experts to remember,
thus a common wiki markup lays the foundation for development of
cross-engine wiki software.
Full press release: http://www.wikicreole.org/wiki/WikiCreolePressRelease
Digg: http://digg.com/software/WikiCreole_1_0_a_common_wiki_markup
Best wishes,
Chuck Smith
Hi.
While I finish the standard edition of the WikiXRay Python parser (for general purposes like retrieving the whole text of each revision) I have improved the research version of the parser.
The new code is at: http://meta.wikimedia.org/wiki/WikiXRay_parser
Basically, I introduced a recipe from the Python Cookbook that speeds up the parsing process, filtering text events until the parsers has read the whole block of text between two tags.
Testing it against the tiny dump of furwiki, it reduced the processing time from 38.7 seconds to 15.019.
Maybe the speed up will be lower with big dumps, but I hope anyway it will be faster than the previous version.
Felipe.
---------------------------------
LLama Gratis a cualquier PC del Mundo.
Llamadas a fijos y móviles desde 1 céntimo por minuto.
http://es.voice.yahoo.com
For those interested in MediaWiki API, a new list has been set-up at
http://lists.wikimedia.org/mailman/listinfo/mediawiki-api
This list will be used to announce changes to the API or any API
related questions and discussion.
--Yurik
Hi,
I'm the Chief Web Opener at Opera. We've identified an issue with
the Wikipedia handheld media stylesheet that stops it from working in
browsers that support Handheld correctly. This is causing our
browser problems trying to render Wikipedia. Would it be possible to
get a developer contact where we can discuss the issue in detail and
suggest how to fix it? The basic issue is that it defines a 2 column
layout in the Handheld stylesheet, while browsers general expect a 1
column layout in handheld mode due to issues with horizontal
scrolling in many devices. Opera Mini 4 has a desktop overview mode
by default, but as wikipedia uses a handheld stylesheet then this
mode is disabled. Opera Mobile has similar issues. The easiest
solution would be to remove the handheld stylesheet or to edit it to
give a 1 column layout. We can help you fix the stylesheet if needed.
The other issue is an issue with our latest internal version of Opera
desktop, Opera kestrel. This has had a number of bug fixes to
increase our compatibility. Unfortunately a bug work around in
Wikipedia breaks in 9.5 and up as we don't have the bug it is trying
to fix any more. Would it be possible to do some versioning on the
bug fix to allow 9.5 Kestrel and above to get the regular FF/Safari
code? The issue is as follows:
Bug ID: 267448
URL: http://en.wikipedia.org/wiki/Main_Page
Issue: Text cut off on Wikipedia
Description:
The text in the "tabs" at the top (main page, discussion, view
source, history) is cut off at the bottom. The text is too far down
in the box compared to Firefox.
Reason:
http://en.wikipedia.org/skins-1.5/common/wikibits.js?73 contains
fixes for specific browsers. We've made changes to font-size
calculations in 9.5 that breaks these fixes
Fix: change the javascript that gives font-size fixes to Opera to
just give those fixes to Opera below version 9.5.
If you need any more information or have any Opera bugs you'd like to
discuss with us then feel free to email me. 9.5 has not been
released to the public yet, but it should be released as a weekly
build in the near future.
Thanks,
David Storey
Chief Web Opener
Opera Software
Oslo, Norway
W: http://my.opera.com/dstorey
✉ : david.storey(a)opera.com
✆ : +47 24 16 42 26
Although I've got a rough idea of what's involved in
setting up a Wikipedia mirror (e.g., install MySQL and
MW, download a WP dump file, stir slowly...), I'd like
to avoid some of the learning curve. Is there a HOWTO
(or whatever) that details the procedure?
In case it matters, the mirror will be installed on a
Mac OS X (10.4.9) machine. It can be relatively static
(e.g., refreshed every few months), as I'm just using
it as a research corpus.
-r
--
http://www.cfcl.com/rdm Rich Morin
http://www.cfcl.com/rdm/resume rdm(a)cfcl.com
http://www.cfcl.com/rdm/weblog +1 650-873-7841
Technical editing and writing, programming, and web development
Hi,
for a few weeks now I try to setup a local wikipedia-Server. For some
science reasons we need to import the german wikipedia with all history
information. I downloaded the compressed XML file, and used mwimport to
convert the XML data to a sql command file. The resulting file is about
500 MB and contains about 50 million lines of sql commands.
I pumped this file into a mysql command. The mysql server is running on
the same machine, 2GB of memory. I configured mysql to use 1.5 GB as
buffer for innodb (innodb_buffer_pool_size).
The mysql command runs for 2 weeks now and imported about 20 million of
29 million article revisions. This seems to be extremly slow for me. I
think I must be doing something wrong, but I cannot find a mistake.
A simple counting command takes between 3 and 7 hours:
mysql> select count(rev_id) from revision;
+---------------+
| count(rev_id) |
+---------------+
| 20923026 |
+---------------+
1 row in set (7 hours 5 min 53.40 sec)
How can that be? Any ideas how to improve the performance? Thanks a lot
in advance!
--
Regards
Christoph
________________________________________________________________________
Christoph Litauer litauer(a)uni-koblenz.de
Uni Koblenz, Computing Center, http://www.uni-koblenz.de/~litauer
Postfach 201602, 56016 Koblenz Fon: +49 261 287-1311, Fax: -100 1311
PGP-Fingerprint: F39C E314 2650 650D 8092 9514 3A56 FBD8 79E3 27B2
First of all, I want to mention that we have gone out of our way to
accommodate Mediawiki as much as possible in the making of Creole.
Often when we were at an impasse, we would just accept the MediaWiki
syntax (like for headings). It should also be noted that much of our
syntax coincided with Daniel Lee Crocker's reform proposal
(unfortunately no longer available online) for Mediawiki syntax. I'm
quoting from our ACM paper for WikiSym 2007:
2.1 Wiki Standardization Attempts
2.1.1 Mediawiki syntax reform draft
Seeing the difficulty and confusion of MediaWiki syntax, on
2005-Jun-10, Daniel Lee Crocker proposed a reform. This syntax has
many elements in common with Creole: headings, bold, italics and line
breaks. It is worth noting here that Crocker wanted to change the
"semantic" double and triple quote system of emphasis from Wikipedia
to the presentational double asterisk and double slash syntax [6].
[6] Crocker, Daniel Lee. New syntax proposal.
http://lists.wikimedia.org/pipermail/wikitech-l/2005-June/017806.html
-
>From reading the previous day's messages, I see there are some
misconceptions about WikiCreole. It is correct that WikiCreole was
not designed for EBNF, but rather it was optimized to be as easy to
learn and use as possible for the user. A wiki parser only needs to
be written once, but people need to use it everyday. However, there
was once an attempt to write a grammar for Creole:
http://www.wikicreole.org/wiki/Grammar and there is currently a
research paper in submission (not by our institute) to WikiSym in
regards to a formal grammar for Creole.
>From what I understand, there are no conflicts between MediaWiki and
WikiCreole. The idea was that Mediawiki would have a separate "Easy
Edit" button (http://www.wikicreole.org/wiki/EditCreoleMode), so that
new users would not have to deal with seeings things like
interlanguage links, templates and tables that often scare away
first-time non-techie users. However, I think there could be a motion
for a Mixed Mode editing (http://www.wikicreole.org/wiki/MixedMode)
where users could use Creole at the same time as Wikipedia markup.
Also note that Brion Vibber participated in the WikiCreole workshop in
Denmark and we have informed him of our decisions as well as asking
for his input along each step of the spec creation. When we
introduced the image syntax {{image.jpg}}, we asked him if that would
be a problem for MediaWiki and he said that MediaWiki would most
likely implement Creole in Easy Edit Mode, so that would not be an
issue.
I know this would be asking a lot, but I think a good way to go about
this would be little steps. For example, first changing the italics
syntax from '' to // and then seeing how that goes. I'm not sure if
this would be the right way to go, but it would be an interesting way
to incrementally move over to Creole and leave the complicated parts
of Mediawiki as they are.
There are also two ACM papers currently in the publication process for
WikiSym 2007 which I could try to provide to private individuals who
are interested in learning more about Wiki Creole. One is from our
institute which documents the hows and whys of Creole while another
not from our institute describes a possible grammar for Creole.
Please send me email privately if you wish to receive these papers.
In any case, we are happy to work with you and however you decide to
implement Creole is up to you.
Best wishes,
Chuck
Hi.
I've just released the 'research' version of the Python parser of WikiXRay. See additional details at http://meta.wikimedia.org/wiki/WikiXRay and http://meta.wikimedia.org/wiki/WikiXRay_Python_parser
This weekend, I'm uploading new graphics. I'm working on the 'plain' version of the parser, to serve as a standard info loader (including the text of all revisions, and only current versions of pages).
Felipe.
---------------------------------
¡Descubre una nueva forma de obtener respuestas a tus preguntas!
Entra en Yahoo! Respuestas.