I've only seen one instance of this, but it seems like something that
really shouldn't happen, so I thought I'd report it.
On [[en:Talk:Politics of Japan]], an anon had blanked the page a while
back with nobody noticing; yesterday I noticed and hit "rollback".
Instead of my rollback adding a new revision after the anon's, it seems
like it actually *deleted* the anon's revision from the article
history... so it looks like I'm making a null-edit, with an edit summary
claiming to be reverting a non-existent edit. The page-blanking edit is
still listed in the user's edit history though
([[en:Special:Contributions/198.169.169.32]]), so the article and user
edit histories are now inconsistent.
-Mark
On Sun, 20 Feb 2005 22:54:42 +0100, James R. Johnson
<modean52(a)comcast.net> wrote:
> Hey,
>
> Is there any way to alter the alphabetical order used to sort
> lists of articles? In the OE wiki, the letter æ (a and e together) should
> be alphabetized after a, so that "áetan, ániman, æfter" show up in that
> order, and ð and þ are arranged after d and t, respectively. There are also
> accented vowels that should show up in their unaccented versions as well, so
> that and, ániman, and ánlíepig are all under the letter "A".
>
> James
>
> _______________________________________________
> Wikipedia-l mailing list
> Wikipedia-l(a)Wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikipedia-l
>
The zh community have a more serious problem: they want different
sorting orders for Traditional and Simplified Chinese...
So I was looking at the related code, and it seems not too hard to
implement specific (but fixed) sorting order within one language.
However I only have limited time to work on this right now, and I
don't fully understand how the category thing works.So I put up a test
site with the basic implementation at http://tinyurl.com/5l24b. The
test site is in English, and the sorting order is altered so that x,
y, z come first, followed by a, b, c, etc.
The categorylinks tables will have to be rebuilt if this is to be
deployed at the live sites. Not sure how expensive that will be.
Interested parties please visit the test site and provide comments
either at the site or this list. If this seems to be a reasonable
solution I will check it into cvs. Test site is running 1.4 from cvs.
--
zhengzhu
Brion Vibber wrote:
>I think it's disingenuous to speak of "the will of the community"
>What do you suggest?
Brion, I apologize if I sounded a little too awkwardly pompous. Like
others, I was a bit confused about the right procedure to follow
during all this.
To clarify, I meant the "will" only in the Rousseauian sense of an
election result, which is always imperfect. Perhaps it would have
been better to state that: "it was *not* the will of the community to
implement nofollow, as it currently is available, until a better
option is available"
I agree with you, in that there is a wide range of opinion, but I
believe it is possible to reach a broad consensus with the right
engineering. My impression, shared and expressed by others, is that
if a software feature were available such that links could mature
into being "rewarded", then I think this would almost certainly gain
a broad consensus to implement.
There will certainly remain a group of users who are, on principle,
against sharing pagelink no matter what, but I think (this is just a
guess) this groups comprises maybe half of the "keep" voters in the
recent vote. Others opposed it purely on spam-related reasons, and
more than a few have expressed a desire for this kind of system. If a
software feature were available, it would become a matter of how long
to let links mature.
In regards to the software option, just thinking off the top of my
head, it would obviously necessitate the creation an additional
database field, say 'externallinks', and that the parser would pull
these links out, like it does category links right now. There would
obviously be a timestamp assigned for each new link, as well as
perhaps the user who added it (perhaps useful for quick rollbacks of
spamlinks). Perhaps interwiki links could be identified as such.
One can imagine right away such cases as a vandal blanking an
establshed page, which in the simplest case would reset the clock.
This is hardly ideal, of course, but dealing with such cases might
come down the road as the refined. A more sophisticated version might
pull out the domain name of the link, and that domains which mature
can be whitelisted for links across the board.
>From these database fields, there could obviously be searchable
special pages, where one could pull up external links and display
them, alphebetized, or by adding user, by namespace, or domain, etc.
This actually might be a very useful thing to have, overall, and
become a popular feature of the software. Just a hunch. Other
boutique-type special pages might display "most linked to domains",
etc., if there was a desire for it.
One benefit of having such special pages would be to allow easy
checking for stale external links across many pages.
I personally am a big believer in interwiki communication and
colloboration, and of having software features that enhances it, so I
would personally enjoy using and having such features in the
software, but I'm a nutcase, so I can't speak for others :)
Matt
Hi,
This is my first ever patch submission for Wikipedia. I have been
reading the source to get my head around it, before I try to add any
major features :)
This is a minor fix to remove a function call, and to get rid of some
comments in CategoryPage.php that were copied and pasted from
ImagePage.php.
Patch is against 1.4rc1
Best Regards,
Marc O'Morain
--- includes/CategoryPage.php 2005-02-03 08:39:50.000000000 +0000
+++ includes_modified/CategoryPage.php 2005-03-06 21:42:48.730722000 +0000
@@ -18,17 +18,16 @@
class CategoryPage extends Article {
function view() {
- if ( NS_CATEGORY == $this->mTitle->getNamespace() ) {
+
+ $show_category = NS_CATEGORY == $this->mTitle->getNamespace();
+
+ if ($show_category) {
$this->openShowCategory();
}
Article::view();
- # If the article we've just shown is in the "Image" namespace,
- # follow it with the history list and link list for the image
- # it describes.
-
- if ( NS_CATEGORY == $this->mTitle->getNamespace() ) {
+ if ($show_category) {
$this->closeShowCategory();
}
}
Hi, I just tried to insert an image from commons into it.wikibooks.org -
using [[Media:nameofimage.jpg]] and I also tried
[[Media:nameofimage.jpg|200px]] and inserting the external link of the
image. But the image just doesn't show up.
I noted that the images used for wikijunior on en.wikibooks.org are
images uploaded on en.wikibooks.org.
Maybe commons does not work for wikibooks? Or is there something wrong
with my links?
Thanks for any hint!
Ciao, Sabine
David Gerard wrote:
>
> Just had the following conversation with Tim Starling on
> #mediawiki. Log quoted with permission.
>
> Basically: there is a feature. Present version is unsubtle
> in its restriction (last 10% of created accounts, which is
> possibly a bit harsh to get consensus. A timed version
> would be nice, but someone interested in it will have to
> write the code.
>
> Of course, if that restriction isn't considered too onerous
> for the moment, it can just be switched on, and it will stop
> Willy On Wheels! in his tracks.
[snip IRC log]
Block only the last 1% (we currently have over 200,000 users on en:, so
that would be approximately the last 2,000), and turn on the
user-account-creation throttling? At the current growth rate, that would
mean that a user would pass this threshold in about a month from
creating their account, and we'd still have all the sysops, and over
2000 "very active Wikipedians" as well as about 196,000 less active ones
able to move pages on en: for users who cannot yet move pages for
themselves.
-- Neil
David Gerard wrote:
>
> Just had the following conversation with Tim Starling on
> #mediawiki. Log quoted with permission.
>
> Basically: there is a feature. Present version is unsubtle
> in its restriction (last 10% of created accounts, which is
> possibly a bit harsh to get consensus. A timed version
> would be nice, but someone interested in it will have to
> write the code.
>
> Of course, if that restriction isn't considered too onerous
> for the moment, it can just be switched on, and it will stop
> Willy On Wheels! in his tracks.
[snip IRC log]
Block only the last 1% (we currently have over 200,000 users on en:, so
that would be approximately the last 2,000), and turn on the
user-account-creation throttling? At the current growth rate, that would
mean that a user would pass this threshold in about a month from
creating their account, and we'd still have all the sysops, and over
2000 "very active Wikipedians" as well as about 196,000 less active ones
able to move pages on en: for users who cannot yet move pages for
themselves.
-- Neil
Hi, before I upload words to wiktionary I normally create tables with
the terms and then with mailmerge I create the pages to upload. In this
way it is quite easy to create glossaries together with wiktionary
contents and we have at least a double use.
Now creating the texts of Wikijunior in Italian (to have it then
translated by one of my pupils into German) I created a short list of
the big cats in English/German/Italian - Gerard already passed me the
terms in Dutch. Now what would be really great is to edit this list
online - so that many people could contribute. Then have the possibility
to export into csv-format (with utf-8 coding).
Is there a software around that already does that? I could install it on
my server for now - and of course any wikipedia project could use the
contents as license would always be GNU FDL.
It would be the fastest way to create contents... can you help me with this?
Thank you for any hint!
Ciao, Sabine
--
Sabine Cretella
s.cretella(a)wordsandmore.it
Meetingplace for translators
http://www.wesolveitnet.com
*****
Vuoi la parola del giorno nella tua casella di posta?
Invia un'e-mail vuota a:
laparoladelgiorno-subscribe(a)yahoogroups.com
Recently an open vote was held on the English wikipedia regarding
whether or not to use the 'rel="nofollow"' attribute in external
links. As many of you know, the attribute was recently created by
google as a possible means of controlling spam. As you know, use of
the attribute is controlled by a boolean flag in the MediaWiki
software.
http://en.wikipedia.org/wiki/Wikipedia:Nofollow
Following the advice of the developers, community vote was set up. It
was open for two weeks and had spirited debate about the use of
"nofollow". The result of the vote was
Remove "nofollow" -- 61% (85 votes)
Keep "nofollow" -- 39% (55 votes)
A strong majority of the voters would prefer that the attribute be
removed for the English Wikipedia.
I'm reporting this knowing that it's up the developers to implement
the will of the community. I know there is support among some the
developers for the continued use of this attribute on all the
wikimedia projects, but those of us who voted on the English
wikipedia did so in the belief that the decision in this case was up
to the community. As such, this is not meant as a discussion of the
attribute itself, only a notification fo the community decision for
the english wikipedia.
I've personally gotten ambiguous and imcomplete feedback from the
user who set up the vote, so I hope this can clear things up. As I
side note, some of the 'keep' voters expressed the desire to see the
attribute removed if the software could parse external links based on
an aging process. I know that since the software does not record
external links separately, this would be probably be a rather complex
modification of the code that would be a long time in development,
given other priorities. In the meantime, however, a strong majority
of the voters have voted "remove".
Best wishes and with great respect for your efforts,
Matthew Trump
.jpg){kind=link}