On Tuesday 14 August 2007 21:08:07 Rob Church wrote:
> On 14/08/07, Tels <nospam-abuse(a)bloodgate.com> wrote:
> > Unfortunately, when I try to login, it tells me "there is no such
> > user "tels"' or Tels.
>
> You will need to *exist* for that wiki to be able to starting looking
> up merge data...
Aaaah, and of course, only after I setup my account, it told my that both my
email *and* my password have to match (but I decided to be clever and used
a different password for test.*).
But since the entire thing said "demo mode", I have no clue if this
now "did" something to unify my accounts, or not. Logging in my "home"
wikipedia.org didn't seem to change anything.
Addendum: Ok, changed the password for test.* and managed to unify stuff,
except someone already has the "tels" at pl.wikimedia.org (and I forgot if
that was me, nor does the userpage actually exist).
And the unify doesnt work since it is in demo mode anyway. Ah shoot.
So now I am still waiting for this feature to be complete, and can only hope
no more jokers manage to block my name in more wikiprojects until the merge
is finally possible....
All the best,
Tels
--
Signed on Tue Aug 14 22:54:03 2007 with key 0x93B84C15.
View my photo gallery: http://bloodgate.com/photos
PGP key on http://bloodgate.com/tels.asc or per email.
"Q: What do you get when you cross an insomniac, an agnostic, and a
dyslexic?
A: Someone who stays up all night wondering if there is a
Dog."
-- Groucho Marx
I'm getting a crazy amount of spam due to being the list administrator
for the daily-image-l list. Is there anything that can be done about
it or is this a drawback to all mailman lists?
thanks,
Brianna
Many people who run MediaWiki wikis have expressed interest in having
a Creole parser for their wikis, including Evan Podromou, one of the
admins of WikiTravel. Tim Starling wrote:
-
I am personally not intending to implement any kind of WikiCreole
support in MediaWiki, but I would welcome such support if someone
implemented it and submitted it. I support the model of having an
alternative parser as an installation option, not the "easy edit"
model.
-
So, I would like to ask, would anyone be interested in developing the
alternative Creole parser for MediaWiki? The idea is that admins of
MediaWiki wikis could decide when they set up a wiki whether they
would prefer to use traditional MediaWiki markup or Creole. If anyone
would be willing to write such a parser for us, we would greatly
appreciate it.
We have created a page at http://www.wikicreole.org/wiki/MediaWiki to
be used for discussions of planning an implementation of Creole for
MediaWiki.
Best wishes,
Chuck
Dear devs,
This is a list of things that I consider are tech/dev priorities for
Wikimedia Commons. Thanks for your attention.
(0. SUL)
1. Improved search.
Dumping Mayflower in there would be a great start:
http://tools.wikimedia.de/~tangotango/mayflower/
I suggest replacing the current search box with a Mayflower search
box, and moving the current text search box below the toolbox.
2. Backup.
No image dumps, still? This is quite worrying. To say the least.
3. Multilingual tagging system (ie categories).
I would prefer a system where a category has a 'preferred' or
'display' name able to be defined in each language, but also alternate
forms that can be used to access the category. So a category' might
have an alternate name in English might be [[category:Sydney,
Australia]]. Using this to tag an image will work. Also typing it in
a search box. But at the bottom of the image they will see a link to
the category using the display name [[category:Sydney]]. Users will
see the display name of the category according to their language
settings. If nothing else this is the most important part. We are
extremely hampered by not being able to use multilingual names for
categories. It's a blow for a site that wants to be multilingual and
serve all languages equally, to have no choice but to say 'sorry, you
have to do this part in English'.
3. Structured data.
This is basically needed to feed into the search engine. I don't know
how Mayflower does it but I suppose it's not ideal. At the moment we
use a [[template:information]] but it's not hugely well suited to it.
Fields include Description, Source, Permission, Date, License,
Geocode, Other_versions, etc etc etc.
4. Move/rename images function AKA image redirect capability
As Tim says, "How hard can it be?" :) This is only an issue because it
is such a common request.
5. Rating system
I would like a simple youtube-style 5star rating thing for image
pages, for logged-in users. More importantly it should be possible to
sort search results (and maybe categories?) according to rating. This
is important because, if you think about Wikipedia, any search query
likely has only half a dozen highly relevant results at most. Most I
would wager only have one. But on Commons, querying over individual
images, a reasonable search query can and often does have dozens or
even hundreds of results. The best way to sift through them would be
by ratings.
There is only so much manual rating we can do (and we are doing it).
As Commons grows this is only going to get worse. This may not seem
like a priority simply because we don't have the functionality now,
but I have a strong feeling this is the right direction.
6. Improved category handling
If the search was improved enough, it might make categories (and
galleries) more or less irrelevant. I can only pray. However for the
moment categories are often used for navigation. The bug of not
putting all subcats on the first page is a frequent problem. The
problem of not seeing the total number of items in the category is a
problem. The lack of ability to sort a category by, e.g. date item was
added to it, or date item was uploaded, is a problem. The lack of
ability to 'auto-flatten' a category is a problem.
7. Multilingual support.
There is one pretty big problem with how screwed up the interface is
for RTL languages. It's very weird for those users. The lack of
ability for anonymous users to choose a language and have it 'stick'
is also limiting. As I mentioned, lack of ability to display category
names in native languages is a problem. Lack of automatically
translating templates is a problem (we would like them to work as
MediaWiki messages do, more or less).
We seriously would like to be a multilingual wiki. But unfortunately I
can't really say we are at the moment.
------------------------------------------------------------------
OK those things are all my big-ticket items. These are some lower priority ones.
8. Playback support.
Been discussed a little. Still needs major improving.
9. RSS and InstantCommons, 'embedding' feature
These items are about making our content accessible and keeping the
tie to our site. Keeping the 'tie' gives us some more control, which
is necessary since I suspect the lifespan of an image is pretty
unpredictable. Maybe when image renames work it won't be so bad.
It would be nice for admins to be able to define RSS feeds, also to
have RSS feeds of items added to a category.
InstantCommons: Wikitravel, Wikia, Wikihow, etc etc etc etc etc would
love to be able to easily access our content. We can benefit from
their participation. I'm not sure where this is at now.
'Embedding' feature - I'm just thinking about the success of the Flickr API.
10. Global native MW Checkusage, CommonsTicker functionality.
Checkusage is an utterly vital tool for us. Since the toolserver seems
vastly improved of late this has dropped on my list. But I don't think
we should have such critical tools on the toolserver only. When
toolserver dies it's as if RC stopped existing for vandalfighters:
really, what can you do...
CommonsTicker could be an extension that each local wiki could alter
to their preferences, in terms of where and when they want
notification about images they are using. At the moment it's a bot
that can leave messages on the talk pages of articles where an image
is used, that is in danger of being deleted on Commons.
11. ImportFreeImages extension (importing images from Flickr).
This was high priority six months ago when I opened the bug request
(8854). Since nothing happened, we developed community and bot
processes to solve the problem of verifying Flickr licenses -- the
same problem this extension would solve.
------------------------------------------------------
Lowest priority -- things which we currently do with Javascript or
external tools, that would be nice to have as native functions.
12. Ability to move images from another Wikimedia wiki to Commons
13. User upload gallery function
14. Bulk upload function
15. Auto-resize galleries according to window size.
http://commons.wikimedia.org/wiki/MediaWiki_talk:ResizeGalleries.js
16. Category and gallery 'previews'
Example:
http://commons.wikimedia.org/wiki/Image:SWB9470_Puetzstrasse.jpg?withJS=Med…http://commons.wikimedia.org/wiki/MediaWiki_talk:Gallerypreview.js
This has improved usability so much even for me, an experienced user.
It just makes you so much more likely to explore. And that is
fantastic for how people should ideally use our site.
17. "Fotonotes".
http://commons.wikimedia.org/wiki/MediaWiki:ImageBoxes.js (a start,
but I think not totally user friendly yet)
Ability to put user annotations directly on an image. Another one of
those things that once we start using I'm sure we won't be able to do
without.
18. Special:Upload flexibility
Well, we are satisfied with our uselang hack so far, but if it kills
the cache and our toy gets taken away, that won't be so cool. So
that's your call I suppose (well, so is everything :)).
BTW I have a feeling these last ones are relatively easy to do,
especially since we have existing tools. So they might be nice
projects for beginning wannabe devs, or experienced devs who would
like a quick break from something more painful, etc. :)
Also some bugs are listed here:
http://commons.wikimedia.org/wiki/Commons:Bugs (some are parts of
above mentioned issues, some are not)
regards
Brianna
user:pfctdayelise
PS> I believe Wikisource also has some welldefined problems they
believe are priorities for them. Last I know is this one:
http://lists.wikimedia.org/pipermail/wikisource-l/2007-June/000294.html
BirgitteSB should be a good contact for a more up to date list.
--
They've just been waiting in a mountain for the right moment:
http://modernthings.org/
I want to do some work on the blocking system. Essentially, the idea
is to make blocking very flexible, whilst cleaning up some of the
flags that are used now.
Therefore, I want to replace the current ipb_address field with a
number of nullable fields, including address (username or IP address,
as it is now), namespace, page, exempted groups, and permission. If
all of the non-null fields match, the block will apply.
This will make blocking more flexible (resolves bugs 874, 1394, and
possibly others) - you will be able to place blocks as wide as the
current namespace protection, and as narrow as forbidding a certain
user from moving a certain page.
Additionally, some of the current fields can be cleaned up - blocking
account creation can be implemented by blocking the 'createaccount'
permission, and anonymous-only blocks can be implemented by adding
'users' as an exempted group.
Currently, I intend to modify the current table, and allow data of the
current schema to behave as normal, thus preventing any nasty
batch-conversion scripts for the many tens of thousands of blocks on
existing wikis.
This is a fairly major change, so I haven't started work on it.
Therefore, questions, comments, suggestions and ridicule are most
welcome.
--
Andrew Garrett
Now that the earlier DB outage is taken care of, I'm running the DB
schema changelets which have held back main code updates on the live
site since the week before Wikimania.
Updates to image, oldimage, and archive tables are being applied on the
slave servers. The new additions will:
* Speed up user renames
* Allow cleaner lookups of uploaded files by name
* Store of file content hashes for various purposes
* Store page_id of deleted pages for later use in restore or other
sorting out of fun situations
There will be intermittent slave lag while these run.
Once all the slaves are done, we'll have to swap masters and run them on
the old masters before updating code.
-- brion vibber (brion @ wikimedia.org)
Hi,
I've been using the existing Mediawiki search engine and implemented a
docfile search based on the filesearch extension (running the doc thru
antiword). I realize that wikipedia is now lucence, but I have some
suggestions to improve the mysql search.
First off I noticed the maintenance rebuildTextIndexes.php has a bug that it
doesn't index any namespace other than main. It also needs text on the page
so I make the following hack (line 59):
$u = new SearchUpdate( $s->page_id,
Title::makeName($s->page_namespace,$s->page_title), $revtext);
if($u->mNamespace == NS_IMAGE && !$u->mText )
$u->mText = "File"; // Always have some text for images
to force indexing
This allows it to index files with no text, and ensures the namespace.
Also the MySQL ranking is not working at the moment:
$m2 = str_replace(" IN BOOLEAN MODE", "", $match);
$m2 = str_replace("+", "", $m2);
SELECT page_id, page_namespace, page_title, {$m2} as relevance FROM $page,
.$searchindex WHERE page_id=si_masterid AND $match
I've replaced this query with a hacked multiwiki one that shows rank, so I
hope that makes sense!
This tip was from
http://dev.mysql.com/doc/refman/5.0/en/fulltext-search.html , the second
comment
Both might be a nice addition for the core engine, for people without
lucene...
Final fix was to the filesearch extension - it should return true, or
subsequent indexing extensions break extensions.
One last question: when updating the index, should I hook the ondeletepage
to remove an index or should there be another hook somewhere else?
Best regards,
Alex
--
Alex Powell
Exscien Training Ltd
Tel: +44 (0) 1865 920024
Direct: +44 (0) 1865 920032
Mob: +44 (0) 7717 765210
skype: alexp700
mailto:alexp@exscien.com
http://www.exscien.com
Registered in England and Wales 05927635, Unit 10 Wheatley Business Park,
Old London Road, Wheatley, OX33 1XW, England
On 8/11/07, Brion Vibber <brion(a)wikimedia.org> wrote:
> Worth taking a look at, though I wonder why the people working on
> Mayflower aren't:
>
> 1) Active in the development list or IRC channel
>
> 2) Committing their code to SVN
So how do you suggest a search for commons be integrated when it can't
work off the current production database alone?
Mayflower uses a periodic text extract from commons which is passed
through a stemmer, then the most frequent terms get stop-worded to
prevent index bloat. Incremental updates of the full text part of
MayFlower aren't possible as currently designed.
Since the start of Mayflower Tangotango and I have discussed moving
its backend to the search stuff I've been working on. The backend
stuff I'm using is far faster, doesn't fall over with overly frequent
keys, and handles incremental update just fine. I've finally gotten
around to putting up a web front end for my search stuff, check it
out, Commons version is at
http://tools.wikimedia.de/~gmaxwell/cgi-bin/cattersect.py, enwiki
version is at http://tools.wikimedia.de/~gmaxwell/cgi-bin/enwiki_cattersect.py
The problem there is that my backend stuff depends on PostgreSQL,
because postgresql provides the inverted indexing which is utterly
required for the qualities of my implementation. So on that case,
again we're in a situation where it's not as simple as "commit it so
SVN" since using that would require a non-trivial addition of software
infrastructure which would have to be carefully considered.
