Heya, I suspect a certain editor on en: could be a sockpuppet for
another editor. The meta pages do say that one of the devel tasks is
sockpuppet detection, but don't say whether anyone can request this or
wheter it requires a poll or even an ArbCom decision to check. Could
someone enlighten me as to current policy?
--
Frank v Waveren Fingerprint: BDD7 D61E
fvw(a)[var.cx|stack.nl] ICQ#10074100 5D39 CF05 4BFC F57A
Public key: hkp://wwwkeys.pgp.net/468D62C8 FA00 7D51 468D 62C8
When I visit www.wikimedia.org, two of the four images
do not load. Specifically, the logos for Wikipedia and
Wiktionary don't appear.
I'm not sure if there's something wrong there, or if
it's something between there and my eyes. Perhaps
someone else can check?
-Rich Holton (en.wikipedia:user:rholton)
__________________________________
Do you Yahoo!?
Jazz up your holiday email with celebrity designs. Learn more.
http://celebrity.mail.yahoo.com
I've been waiting for ages to use <chem>, <music>, and <svg>.
Everything seems to work at http://wikisophia.org/wiki/Wikitex , so why has
this not been implemented yet?
It does not (as I for some reason had assumed) seem to be part of MediaWiki
1.4. Is this being saved for 2.0?
-- mav
__________________________________
Do you Yahoo!?
Yahoo! Mail - Helps protect you from nasty viruses.
http://promotions.yahoo.com/new_mail
----- Original Message -----
From: "Alan Wessman" <alanyst(a)gmail.com>
To: "Wikimedia developers" <wikitech-l(a)wikimedia.org>
Subject: [Wikitech-l] Preview with diff?
Date: Thu, 16 Dec 2004 00:30:45 -0700
>
> Hello developers,
>
> I have an itch that I'm interested in scratching. When editing but
> before saving changes, I find myself wishing I could see a diff
> between the current version and my revision, so I can more accurately
> state for the edit summary what I had changed.
> [...]
>
I like that.
Schewek
--
______________________________________________
Check out the latest SMS services @ http://www.linuxmail.org
This allows you to send and receive SMS through your mailbox.
Powered by Outblaze
Hello developers,
I have an itch that I'm interested in scratching. When editing but
before saving changes, I find myself wishing I could see a diff
between the current version and my revision, so I can more accurately
state for the edit summary what I had changed.
I'm thinking of a "Preview with diff" feature that would let me see my
changes not only in terms of what the page will look like but also in
terms of what the diff will be, before the page is saved. In other
words, invoking the feature would show the tentative diff above and
the tentative changes below, in the same manner that actual diffs are
shown.
This feature might be integrated as a user preference so that a new
button doesn't have to be added to the editing interface; enabling
this feature would cause all invocations of the Preview feature to
include the diff. (There may be better ways of providing access to
this feature; this is just what came to mind first.)
I didn't spot this idea mentioned in previous discussions on this list
or wikimedia.org when I briefly searched for it. Has this been
considered before? If so, please point me to the pertinent discussion
so I can understand the issues involved. If not, what are your
thoughts about this--does it sound useful? What are some of the
potential pitfalls?
If this idea sounds reasonable to members of this list, I'm willing to
try to implement it myself, although any help would of course be
welcome.
Best wishes,
Alan
Walter Vermeir wrote:
> This sounds fermilliar. Is that policy of wikimedia to only pay when the
> expire?
<irony>
The official policy is to allow squaters take over domains, and then use large part of funds to buy them back or redirect sites to other, not so easy to remember domains.
</irony>
If there's a trouble, why would you need to mock at guys, running the sites? Sure, there was an error, registrars are not always as user friendly, as they could be. People are not always as attentive, as they could be. Errors do happen. Why didn't you notice that yourself (as you're on wikitech-l as well) before?:)
I've seen large GSM/net operators and various other enterprises with expired core domains, where their hosting, dns and mail servers reside. Just a short list:
- hotmail.co.uk
- mp3.com
- washpost.com
...
Domas
Could someone fix the 1.4 so that we could sysop and
unsysop people as soon as possible on meta ?
Meanwhile, could a developer take care of requests for
such issues
http://meta.wikimedia.org/wiki/Requests_for_permissions.
Just need to check the page from time to time ?
Thanks
Anthere
__________________________________
Do you Yahoo!?
Yahoo! Mail - You care about security. So do we.
http://promotions.yahoo.com/new_mail
Hi all
As you may now, there is some discussion about wether to use page to
form galleries on the commons, or to use the new
thumbnails-in-categories feature of 1.4 to do that. Both have their pros
and cons, and no real solution has yet been found for this question (see
http://commons.wikimedia.org/wiki/COM:VP for some discussion).
I would like to propose to simply do away with the difference between
pages and categories (see
http://commons.wikimedia.org/wiki/COM:VP#Categories_or_.27normal.27_pages:_…)
by treating every page as a category. That is, IMHO it would be best to
drop the "Category:" namespace and list articles and images the contain
a category link like [[category:Foo]] directly at the bottom of page
"Foo". This way, pages can be used as a structured article or as an
unstructured category, as need be. The category-ish list at the bottom
could also serve as a todo-list of stuff that need to be integrated into
a structured page.
This would resolve the problem that categories aren't readily found by a
simple search, and that there often is a category and a page for the
same topic, containin different but overlapping sets of images, which
would need to be kept in sync manually. This is annoying when looking
for images about a specific topic.
I would like to make all pages categories for the commons - maybe the
same thing would be a good idea for the wikipedias, too, but i'm not yet
sure about this.
I had a conversation about his with Jamesday on IRC the other day, i'll
try to summary some of the concerns and my answers below.
Q: List-Articles would still be needed, because categories can only show
articles that exist.
A: We could still do that, either by simply not using the
category-aspect of the respective page, or be keeping the missing things
at the top and the existing ones in the category-ish listing.
Q: Replication is a good thing, so users have a choice of how to ciew a
gallery.
A: Keeping the different views in sync is tedious and unrealistic. We
already have a lot of images on the commons that can't be found because
they are on no page and in no category. In cases where both exist, they
are nearly never in sync, and they often do not link to each other. The
entire structure is very inconsistent, and the distinction between pages
and categories only makes things worse.
Q: Galleries can not represent internal structure.
A: In cases where internal structure is needed, just don't use the
category-aspect of the page, or use it as a todo-list.
A feature that allows for structure in categories is a different
matter: maybe we could have sections in categories, using a syntax like
[[Category:Foo#section-name]] or something. Or we could have a switch
the shows sub-categories "inlined". Also, it would be extremely useful
to show the link-text after the "|" in the category link (now only used
for sorting) as the image-label in categories. But this does not really
touch my idea.
Q: Categories can be very lagre. This would hinder the loading / viewing
of the respective Articles.
A: In most cases, large categories (just like large pages) should be
split into subcategories - that would resolve this isse in most cases.
Bot some categories are large by nature, especially ones that are
used for tagging images with copyright-information, etc. Those
categories do not have a meaningfull article associated with them, they
are simply very long lists, and it does not matter in which namespace
they show.
Keep in mind that categories are simply pages that are filled in a
diferent way and have no internal structure. With regards to the
commons, there is no "logical" difference: they both consitute galleries.
In a nutshell: I can see only advantages to showing things in category
"Foo" at the bottom of page "Foo". The distinction between articles and
categories seems artificial and unneccessary, at least for the commons.
I was thinking about submitting this as a feature request - but i'm not
sure if this would be the right way to go, as this is not only a little
software feature, but a request for a structural change, too. So i'd
like to discuss it here first - and maybe on some of the other mailing
lists? I'm not sure which one would be most appropriate.
--
Homepage: http://brightbyte.de