Apologies in advance if this would be more appropriate for mediawiki-
l, but since I discuss a possible modification to trunk, I thought
this would be the correct list.
In working on my UserRightsList extension, I encountered changes in
includes/SpecialUserrights.php that have me wondering if I'm missing
something really basic about oo programming and how I should have made
the extension. I originally wrote the Special page extension by
extending class SpecialPage and writing methods that largely
duplicated things in SpecialUserrights. For 0.5, I extended class
UserRightsPage (which didn't exist prior to 1.12) to be able to reuse
UserRightsPage::saveUserGroups( $username, $removegroup, $addgroup,
$reason = ''). This works in 1.12...
but no sooner did I announce it than I got a message that it didin't
work in 1.13a.
It turns out that in 1.13a, that UserRightsPage::saveUserGroups() no
longer passes the $removegroup and $addgroup arrays, it takes them
directly from $wgRequest.
Since I'm looping over a list of users, I patched the extension on
0.51 to modify $wgRequest->data for each iteration over the array of
users sent on execution. This strikes me as ugly, as it changes a
global that could contain information expected by something further
downstream (although I think it should be OK for the Userrights
hook). But I'm stumped about how else I could do this. It seems that
it isn't any better to have class UserRightsList extend SpecialPage
instead of UserrightsPage if all it means is instead of $this-
>saveUserGroups(), I use UserrightsPage::saveUserGroups(). That has
the same problem with the method params and that is actually worse,
since I have to load up the code with a bunch of things like:
function fetchUser( $username ) {
return UserrightsPage::fetchUser( $username );
}
just to get it to work. Would it be reasonable to suggest something
like changing SpecialUserrights.php to:
function saveUserGroups( $username, $removegroup = '', $addgroup =
'', $reason = '') {
...
if (is_array($removegroup) && is_array($addgroup) ){
foreach ($allgroups as $group) {
...
}
}
...
This would add a little overhead for the is_array checks, but would
ensure backward compatibility with anything else that calls the method
(perhaps that would only be me), and allow classes to extend class
UserrightsPage without modifying $wgRequest.
The larger questions:
- Should I be avoiding this approach (extending classes in includes)
altogether?
- If not, is there a way to tell whether the parameters/behavior are
likely to be stable?
- If yes, Is there a way I should be doing this to make it less likely
to break in future versions of MW?
- Was Userrights just an outlier because it needed refactoring and now
it should be stable?
Thanks,
JH
=====================================
Jim Hu
Associate Professor
Dept. of Biochemistry and Biophysics
2128 TAMU
Texas A&M Univ.
College Station, TX 77843-2128
979-862-4054
Hello!
There's a new extension called FileCheck that probably would be a good idea for wikipedia and/or wikimedia commons!
I noticed that MediaWiki doesn't check back if a file already exists on uploading. Of course, it checks if a file with the same name already exists, but not the exact same file even if its saved under another name. So I have written the FileCheck extension. It uses the SHA1 hashcode MediaWiki saves with every file (since MediaWiki 1.11) in the database. The extension checks back if the same hashcode is already in the database, and if so, ckecks back if the already uploaded file and the new file are one and the same. Since the SHA1 hashcode has an index in the database, it shouldn't be fast enough. If the extension finds the same file has already been uploaded, it prevents the uploading and prints out the name and link to the already existing file, along with an error message.
I think this would be a perfect extension to use on wikipedia and wikimedia commons. The preventing of duplicate uploads is certainly better than the tagging of and searching for duplicates like it's currently the case.
You'll find the MediaWiki extension page at:
http://www.mediawiki.org/wiki/Extension:FileCheck
And the projects homepage at:
http://www.chaosreligion.com
If you have any more questions or something else you want me to tell, just email me at echalone(a)hotmail.com
greetings from Austria,
Markus Szumovski
_________________________________________________________________
Sie haben nie Platz in Ihrer Inbox? Mit Windows Live Hotmail haben Sie jetzt 5GB Speicherplatz - gratis! Holen Sie sich hier Ihren neuen Windows Live Hotmail Account!
http://get.live.com/mail/overview
> 2. Currently it seems anyone cannot combine their accounts if one of
> them is blocked. I think it may cause some troubles (this year people
> can vote even if they have a blocked account, if they have a valid
> voting-eligible one on another wiki). Is it possible to change the
> current setting and allow them to unify their accounts?
>
http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/CentralAuth/Cent…
in function chooseHomeWiki( $migrationSet ),
why not check for blocked account like this?,
$maxEdits = -1;
$homeWiki = null;
foreach( $workingSet as $wiki => $local ) {
if( $local['editCount'] > $maxEdits && !$local['blocked'])
{ # <-- added code here
$homeWiki = $wiki;
$maxEdits = $local['editCount'];
}
}
Sorry to send yet another mail, but I made a little writing mistake in the mail: "FileCheck extension probably a good idea for wikipedia and/or commons"
It should be:
Since the SHA1 hashcode has an index in the database, it should (!!) be fast enough.
not "shouldn't be fast enough" as I wrote originally. Sorry for that! Since it has an index, it's of course faster... and that's what I ment. simple logic ;)
greetings,
Markus
_________________________________________________________________
Windows Live Spaces - Ihr Leben, Ihr Space. Hier klicken und informieren.
http://get.live.com/spaces/overview
Could someone please write up a few hundred words for the Wikimedia
blog (http://blog.wikimedia.org/) about Single User Login? It's been
long enough coming :-)
- d.
It's time to remember one of those English proverbs I leaned in high school: "Good things come in threes!"
1. After being enabled on the German language Wikipedia a few weeks ago[1], Flagged revisions is a hit. Over 255.000 content pages have been reviewed (a third of all content pages) by almost 3.000 users[2]. The in my humble opinion Wikipedia with the highest quality content, now ensures that anonymous readers get to read checked versions of content, reducing chances of innocent bystanders being confronted with all kinds of pranks and filth. Great stuff.
2. Three days ago a shell user created a large number (15) of new MediaWiki wikis (Thanks Tim!)[3]. Many of those in languages that did not have a Wikimedia project yet (9). Thanks to everyone who has taken and is taking the time to make Wikimedia projects even more omnipresent. Imagine a world in which every single human being can freely share in the sum of all knowledge.
3. Last Tuesday, the illustrious "Bug 57" was finally closed[4]. Using multiple Wikimedia projects has never been this easy before. Yay! for meta projects like Wikimedia Commons. Now where's that WYSIWYG editor so that the learning curve does not have to be this steep[5]? I am putting a EUR 1000,00 bounty on the first to get one working properly and approved by Brion before the end of 2008. Contact me for details if you are serious about working on this. I am certain there are more people that would chip in for this[6] - and MediaWiki needs it to stay an interesting wiki engine outside of the WMF projects.
4. As you may not know (who am I anyway), I am heavily involved in the MediaWiki localisation project, which tries to make MediaWiki available in as many languages as possible. In the end of 2007 I formulated four ambitious goals for the project[7]. By the end of the year, 120 languages should have a minimal localisation (proper localisation for 'read only', back then 48 languages), 90 languages should have a localisation for at least 90% of all MediaWiki messages (then 50), 50 should have a 90% localisation of extension messages used by Wikimedia (then 11) and 20 should have a 65% localisation of all extension messages supposed in the MediaWiki localisation project (then 7)[8]. In December 2007, I thought all of those goals would be just or well beyond reach. Well, impossible really. Today the first of the forementioned four goals was reached: 20 languages now have a 65% or more localisation of the 3,700 messages of the extensions supported by Betawiki. Translators for Esperanto and Vietnamese completed the 20 languages. MediaWiki now has minimal localisation for 112 languages, an excellent localisation exists for 65 languages, and 16 languages have excellent support for the extensions that the WMF uses[9,10]. Brilliant if you ask me. And still we need more. There are Wikimedia projects in over 270 languages (counting Incubator projects) and MediaWiki supports about 313 languages. The least we should do is offer language communities a user interface in the language their parents taught them - nothing better to feel at home.
Ouch. I have to learn how to count… And I was not even done yet. Just wanted to share my happiness :).
Siebrand
[1] http://lists.wikimedia.org/pipermail/foundation-l/2008-May/042705.html
[2] http://toolserver.org/~aka/cgi-bin/reviewcnt.cgi?lang=english
[3] http://lists.wikimedia.org/pipermail/wikitech-l/2008-May/038008.html
[4] http://leuksman.com/log/2008/05/28/bug-57-laid-to-rest/
[5] http://en.wikipedia.org/wiki/Learning_curve
[6] The bounty is made available through the 'MediaWiki accessibility project' of Stichting Open Progress (http://www.openprogress.org), subsidised by HIVOS (http://www.hivos.nl/). Acceptance criteria include a proper 'back and forth' conversion of 2,000 English language Wikipedia main namespace pages.
[7] http://lists.wikimedia.org/pipermail/translators-l/2007-December/000571.html
[8] http://translatewiki.net/wiki/Translating:Group_statistics_in_time
[9] http://translatewiki.net/wiki/Translating:Group_statistics
[10] the relatively low rise in localisation completeness for WMF extension is mainly due to the large increase in messages for CentralAuth and FlaggedRevs; translators need some time to catch up.
On Thu, May 29, 2008 at 9:01 PM,
<wikitech-l-request(a)lists.wikimedia.org> wrote:
> Send Wikitech-l mailing list submissions to
> wikitech-l(a)lists.wikimedia.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> or, via email, send a message with subject or body 'help' to
> wikitech-l-request(a)lists.wikimedia.org
>
> You can reach the person managing the list at
> wikitech-l-owner(a)lists.wikimedia.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Wikitech-l digest..."
>
>
> Today's Topics:
>
> 1. list rendering (Khachik Kocharyan)
> 2. Re: SUL homewiki selection question (Anon Sricharoenchai)
> 3. Re: SUL homewiki selection question (Anon Sricharoenchai)
> 4. SUL entry on Wikimedia blog? (David Gerard)
> 5. Wikimedia Foundation Blog (Jon)
> 6. Re: [Foundation-l] Fwd: [WikiEN-l] Bot policy for all wikis
> (David Gerard)
> 7. Re: [Foundation-l] Fwd: [WikiEN-l] Bot policy for all wikis
> (Max Semenik)
> 8. Re: $wgCentralAuthCreateOnView (Simetrical)
> 9. Re: [Foundation-l] Fwd: [WikiEN-l] Bot policy for all wikis
> (Nicolas Dumazet)
> 10. Re: [MediaWiki-CVS] SVN: [35553]
> trunk/extensions/Wikidata/includes/api (Roan Kattouw)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 29 May 2008 14:12:40 +0500
> From: Khachik Kocharyan <khachik(a)zenteq.am>
> Subject: [Wikitech-l] list rendering
> To: Wikitech-l(a)lists.wikimedia.org
> Message-ID: <945EAA37-F6B0-43D9-971D-902F843174CA(a)zenteq.am>
> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
>
> Hello,
>
> I want to place block-level elements in the definition list, but it
> is impossible. If I write
> <dl><dt>term <dd><pre>
> code here
> code here</pre></dl>
>
> I get (in ?action=render)
> <dl><dt>term <dd><pre>
> code here
> code here</pre></dl>
>
> which is not valid XML. If I write
>
> <dl><dt>term</dt> <dd><pre>
> code here
> code here</pre></dd></dl>
>
> I get
> <dl><dt>term</dt> <dd><pre>
> code here
> code here</pre></dd></dl>
>
> Placing <pre> (and other block-level elements) in ; term : definition
> returns invalid XML too.
> Wrote
> ;term : <pre>code1
> code2
> code3</pre>
>
> and got
>
> <dl><dt> term </dt><dd> <pre>code1
> </dd></dl>
> <p>code2
> </p>
> code3</pre>
>
> I use mediawiki 1.12.0.
>
> regards,
> Khachik
>
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 29 May 2008 16:19:47 +0700
> From: "Anon Sricharoenchai" <anon.hui(a)gmail.com>
> Subject: Re: [Wikitech-l] SUL homewiki selection question
> To: "Wikimedia developers" <wikitech-l(a)lists.wikimedia.org>
> Message-ID:
> <5914604b0805290219i3bbfc704u97d1aa3016706f87(a)mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On 5/29/08, Tim Starling <tstarling(a)wikimedia.org> wrote:
>> Anon Sricharoenchai wrote:
>> > Hi,
>> >
>> > 1. Why still we let the SUL to auto select the homewiki in Special:MergeAccount?
>>
>>
>> The "home wiki" is a concept used by SUL to improve the chances that the
>> most active user of an account name will obtain the global account for
>> that name. If the passwords don't match, only the user who has access to
>> the home wiki will be allowed to merge.
>>
>> After merge, the home wiki has no significance and is not displayed
>> publically.
>>
>
> The most active user on only one wiki doesn't mean that he deserve to
> get global account.
> The main objective of global account is to benefit the user that have
> accounts on many wikis. (Am I correct?)
> If Mr.A (see below) spread out his activeness across many wikis,
> comparing to Mr.B (see below) that only active on only one wiki, Mr.A
> will lose global account to Mr.B, since the activeness of Mr.A is
> divided into many wikis, while Mr.B focus only on one wiki, then win
> the edits count.
> Do you think that Mr.A will get more benefit from global account than Mr.B?
>
>>
>> > 2. Why not we let the wiki that do Special:MergeAccount as homewiki?
>> > Example,
>> > Assuming that it has user test123@testwiki (1000 edit counts) and
>> > test123@lowikibooks (500 edit counts)
>> > * If test123 do merge account at,
>> > http://test.wikipedia.org/wiki/Special:MergeAccount, then testwiki
>> > will be homewiki.
>> > * If test123 do merge account at,
>> > http://lo.wikibooks.org/wiki/Special:MergeAccount, then lowikibooks
>> > will be homewiki.
>>
>>
>> We don't do this because it would defeat the purpose of having a home wiki.
>>
>
> The purpose of home wiki is to estimate the activeness?
>
> Trying to do http://lo.wikibooks.org/wiki/Special:MergeAccount by user
> test123, is also the evidence that test123(a)lo.wikibooks is an active
> account.
>
>>
>> > 3. Why not prohibit creation of existing account that have not yet
>> > been merged on any wikis?
>> > Example,
>> > 1. Before SUL, if have test123 created on http://lo.wikipedia.org
>> > 2. test123@lowiki has not been merged on any wikis.
>> > 3. After SUL, should immediately prohibit the creation of test123
>> > account on any WM wikis. (even that test123 has not yet been merged
>> > to SUL)
>>
>>
>> This is already the case, but we have had some reports that this
>> protection sporadically stops working. If this is true, it should be fixed
>> soon.
>>
>
> You mean that this is a bug?
> The real intention is to also block account creation of unmerged username?
>
> My experience is that,
> 1. I have tried create new account named testwiki.test@testwiki
> 2. While there's no user named testwiki.test on any other wikis, why
> I'm not automatically get the global account for testwiki.test?
> 3. Why I still can create new account testwiki.test on lowiki?
>
> The next case,
> 1. User testxyz already exists on enwiki before SUL,
> http://toolserver.org/~vvv/sulutil.php?user=testxyz
> 2. After SUL, testxyz have not yet been merged.
> 3. However, why I still can create new account testxyz on enwikibooks?
>
> The above two cases is a bug?
>
>>
>> > 4. Considering the following situation,
>> > 1. Mr.A own "user123" at,
>> > * testwiki,meta,common,mediawiki: 100,500,500,500 edits count
>> > * enwikipedia,enwikibooks,enwikitionary,enwikisource,enwikinews:
>> > 100,100,100,100,100 edits count
>> > * lowikipedia,lowikibooks,lowiktionary,lowikisource,lowikinews:
>> > 500,100,100,100,100 edits count
>> > * totally, Mr.A has 3000 edits count
>> > 2. Mr.B own "user123" only at frwikipedia with 2000 edits count
>> > 3. When Mr.A use user123 on lowikipedia, and do
>> > http://lowikipedia/Special:MergeAccount, what will be the homewiki of
>> > user123?
>> > 4. Mr.A can successfully merge account?
>> > 5. If homewiki determined by the system is user123@frwikipedia,
>> > then what thing Mr.A could do to get his accounts merged?
>>
>>
>> The best idea is for Mr.A and Mr.B to have a friendly chat with each other
>> about who they think should get the global account. Then, depending on the
>> results of that conversation, either Mr.A can rename his many accounts to
>> some new, unique username; or Mr.B can rename his fr.wikipedia account and
>> Mr.A can get the global name.
>>
>> -- Tim Starling
>
>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 29 May 2008 16:32:45 +0700
> From: "Anon Sricharoenchai" <anon.hui(a)gmail.com>
> Subject: Re: [Wikitech-l] SUL homewiki selection question
> To: "Wikimedia developers" <wikitech-l(a)lists.wikimedia.org>
> Message-ID:
> <5914604b0805290232t53d4a3a8gdd180a216f1a7a9f(a)mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
>>
>> You mean that this is a bug?
>> The real intention is to also block account creation of unmerged username?
>>
>> My experience is that,
>> 1. I have tried create new account named testwiki.test@testwiki
>> 2. While there's no user named testwiki.test on any other wikis, why
>> I'm not automatically get the global account for testwiki.test?
>> 3. Why I still can create new account testwiki.test on lowiki?
>
> Sorry, I mean lowiki.test username,
> http://toolserver.org/~vvv/sulutil.php?user=lowiki.test
> 1. I first create on lowiki,
> http://lo.wikipedia.org/w/index.php?title=%E0%BA%9E%E0%BA%B4%E0%BB%80%E0%BA…
> 2. Then I still can create new one with the same name on testwiki,
> http://test.wikipedia.org/w/index.php?title=Special:Log&user=Lowiki.test
>
> Is this a bug?
>
>
>
> ------------------------------
>
> Message: 4
> Date: Thu, 29 May 2008 11:29:59 +0100
> From: "David Gerard" <dgerard(a)gmail.com>
> Subject: [Wikitech-l] SUL entry on Wikimedia blog?
> To: "Wikimedia developers" <wikitech-l(a)lists.wikimedia.org>
> Message-ID:
> <fbad4e140805290329r2ed13c9bpcaa5bec09629fc04(a)mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Could someone please write up a few hundred words for the Wikimedia
> blog (http://blog.wikimedia.org/) about Single User Login? It's been
> long enough coming :-)
>
>
> - d.
>
>
>
> ------------------------------
>
> Message: 5
> Date: Thu, 29 May 2008 06:52:47 -0500
> From: Jon <scream(a)datascreamer.com>
> Subject: [Wikitech-l] Wikimedia Foundation Blog
> To: wikitech-l(a)lists.wikimedia.org
> Message-ID: <483E990F.9070601(a)datascreamer.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> The Wikimedia foundation blog, is located at http://blog.wikimedia.org
>
> Information about this blog can be located at
>
> http://meta.wikimedia.org/wiki/Wikimedia_Blog
>
>
>
>
>
>
> The blog is currently encouraging suggested post drafts from the
> contributers on here at Wikimedia. Please check out the drafting
> instructions at
>
> http://meta.wikimedia.org/wiki/Wikimedia_Blog#Drafting_a_post
>
> Send in your material!
>
> An example of a post that could be drafted is the new SUL / Unified
> login system. Perhaps a contributer knowledgeable in that area could
> write something up. :)
>
> Very Best!
>
> Jon
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFIPpkP6+ro8Pm1AtURArnnAJ9fLIJMmbjW7XCw8lxrbenImv9SIwCbBlZJ
> N+EU4+iVE9taBB2IX2tr8dI=
> =1BDX
> -----END PGP SIGNATURE-----
>
>
>
> ------------------------------
>
> Message: 6
> Date: Thu, 29 May 2008 14:38:11 +0100
> From: "David Gerard" <dgerard(a)gmail.com>
> Subject: Re: [Wikitech-l] [Foundation-l] Fwd: [WikiEN-l] Bot policy
> for all wikis
> To: "Wikimedia Foundation Mailing List"
> <foundation-l(a)lists.wikimedia.org>, "Wikimedia developers"
> <wikitech-l(a)lists.wikimedia.org>
> Message-ID:
> <fbad4e140805290638r2e97d457hff318b539334b95f(a)mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> 2008/5/29 Andre Engels <andreengels(a)gmail.com>:
>
>> The current language order in the bot was done that way because we
>> were told to do so by the English Wikipedia. I'd happily change it,
>> but THE DECISION IS UP TO THE ENGLISH WIKIPEDIA, NOT TO YOU.
>
>
> The answer is surely to include interwiki-link ordering as a parameter
> that can be set for each wiki. That way, whatever order they're in at
> the end of the article, they show up in the correct order in the
> rendered page.
>
> The bug is: https://bugzilla.wikimedia.org/show_bug.cgi?id=2867
>
> Surely someone can get that patch into acceptable shape for the MediaWiki code?
>
> (unless there's some problem with it that isn't clear from the bug -
> cc to wikitech-l)
>
>
> - d.
>
>
>
> ------------------------------
>
> Message: 7
> Date: Thu, 29 May 2008 19:50:41 +0400
> From: Max Semenik <maxsem.wiki(a)gmail.com>
> Subject: Re: [Wikitech-l] [Foundation-l] Fwd: [WikiEN-l] Bot policy
> for all wikis
> To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
> Message-ID: <859926304.20080529195041(a)gmail.com>
> Content-Type: text/plain; charset=us-ascii
>
> On 29.05.2008, 17:38 David wrote:
>
>> 2008/5/29 Andre Engels <andreengels(a)gmail.com>:
>
>>> The current language order in the bot was done that way because we
>>> were told to do so by the English Wikipedia. I'd happily change it,
>>> but THE DECISION IS UP TO THE ENGLISH WIKIPEDIA, NOT TO YOU.
>
>
>> The answer is surely to include interwiki-link ordering as a parameter
>> that can be set for each wiki. That way, whatever order they're in at
>> the end of the article, they show up in the correct order in the
>> rendered page.
>
>> The bug is: https://bugzilla.wikimedia.org/show_bug.cgi?id=2867
>
>> Surely someone can get that patch into acceptable shape for the MediaWiki code?
>
>> (unless there's some problem with it that isn't clear from the bug -
>> cc to wikitech-l)
>
>
>> - d.
>
> Both major bot frameworks that may change the sort order of
> interwikis, pywikipedia and AWB, have a highly customizable sorter that
> follows http://meta.wikimedia.org/wiki/Interwiki_sort_order . If a
> wiki is handled improperly, people should file a request to
> http://sourceforge.net/tracker/?group_id=93107 or http://en.wikipedia.org/wiki/WP:AWB/B
> respectively instead of whinning about Teh Evil English Cabal.
>
> --
> Best regards,
> Max Semenik ([[User:MaxSem]])
>
>
>
>
> ------------------------------
>
> Message: 8
> Date: Thu, 29 May 2008 12:10:06 -0400
> From: Simetrical <Simetrical+wikilist(a)gmail.com>
> Subject: Re: [Wikitech-l] $wgCentralAuthCreateOnView
> To: "Wikimedia developers" <wikitech-l(a)lists.wikimedia.org>
> Message-ID:
> <7c2a12e20805290910q24a0fcd7m5121f02bf5670e23(a)mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On Thu, May 29, 2008 at 2:58 AM, Rotem Liss <rotemliss(a)gmail.com> wrote:
>> On the other hand, this causes problems when a user merges his accounts when
>> some of them have different names, and thus are not merged. For example:
>> User:Alpha@awiki and User:A@bwiki are the same user. User:A@bwiki merges his
>> accounts. The next time he visits awiki, User:A@awiki is created. He cannot use
>> User:Alpha@awiki any longer if he wants to use his global account, and accounts
>> keep created in every wiki, e.g. Meta (to which he comes to request deleting the
>> global account). This may cause problems if he wants to rename his old account
>> or so. This problem is not theoretical: users complained of it short after SUL
>> was enabled.
>
> Well, that will go away once all the accounts are merged. In the
> meantime we can put up a warning on MergeAccount saying not to merge
> your accounts if you want some to be renamed first.
>
>
>
> ------------------------------
>
> Message: 9
> Date: Thu, 29 May 2008 18:51:59 +0200
> From: "Nicolas Dumazet" <nicdumz(a)gmail.com>
> Subject: Re: [Wikitech-l] [Foundation-l] Fwd: [WikiEN-l] Bot policy
> for all wikis
> To: "Max Semenik" <maxsem.wiki(a)gmail.com>, "Wikimedia developers"
> <wikitech-l(a)lists.wikimedia.org>, foundation-l(a)lists.wikimedia.org,
> "Pywikipedia discussion list" <pywikipedia-l(a)lists.wikimedia.org>
> Message-ID:
> <1f077e770805290951t5552581ek283d5f9909fc8813(a)mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Thanks for the link to our sourceforge Max.
>
> Unless this feature is added to mediawiki core, yes - I'm speaking for
> pywikipedia here - report us any bug in the interwiki sorting, and I
> (we) will be happy to fix that for pywikipedia.
>
> We do agree that there are local policies to respect on each projects,
> and trust me, we try to work to comply with these rules. Sometimes we
> are mistaken (today several complaints about the interwiki sorting of
> sk: got raised, this should be fixed by now) but really, we are trying
> to help the community, not to enforce some foreign wiki rules in
> another.
>
> 2008/5/29 Max Semenik <maxsem.wiki(a)gmail.com>:
>
>> Both major bot frameworks that may change the sort order of
>> interwikis, pywikipedia and AWB, have a highly customizable sorter that
>> follows http://meta.wikimedia.org/wiki/Interwiki_sort_order . If a
>> wiki is handled improperly, people should file a request to
>> http://sourceforge.net/tracker/?group_id=93107 or http://en.wikipedia.org/wiki/WP:AWB/B
>> respectively instead of whinning about Teh Evil English Cabal.
>>
>> --
>> Best regards,
>> Max Semenik ([[User:MaxSem]])
>>
>>
>> _______________________________________________
>> Wikitech-l mailing list
>> Wikitech-l(a)lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>
>
>
>
> --
> Nicolas Dumazet ? NicDumZ [ nIk.d?ymz ]
> pywikipedia & mediawiki
> Deuxi?me ann?e ENSIMAG.
> 06 03 88 92 29
>
> ------------------------------
>
> Message: 10
> Date: Thu, 29 May 2008 21:00:23 +0200
> From: Roan Kattouw <roan.kattouw(a)home.nl>
> Subject: Re: [Wikitech-l] [MediaWiki-CVS] SVN: [35553]
> trunk/extensions/Wikidata/includes/api
> To: wikitech-l(a)lists.wikimedia.org
> Message-ID: <483EFD47.6030900(a)home.nl>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> kim(a)svn.wikimedia.org schreef:
>> Revision: 35553
>> Author: kim
>> Date: 2008-05-29 17:36:51 +0000 (Thu, 29 May 2008)
>>
>> Log Message:
>> -----------
>> Updated ApiWikiData to support voctrainer...
>> This is slightly dirty code still, I'll contact yuri for array format sometime soon.
> What about it. I doubt Yuri's gonna reply, he hasn't been active around
> here for months. Feel free to ask on the mediawiki-api list, though.
>
> Roan Kattouw (Catrope)
>
>
>
> ------------------------------
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
>
> End of Wikitech-l Digest, Vol 58, Issue 56
> ******************************************
>
kim(a)svn.wikimedia.org schreef:
> Revision: 35553
> Author: kim
> Date: 2008-05-29 17:36:51 +0000 (Thu, 29 May 2008)
>
> Log Message:
> -----------
> Updated ApiWikiData to support voctrainer...
> This is slightly dirty code still, I'll contact yuri for array format sometime soon.
What about it. I doubt Yuri's gonna reply, he hasn't been active around
here for months. Feel free to ask on the mediawiki-api list, though.
Roan Kattouw (Catrope)
2008/5/29 Andre Engels <andreengels(a)gmail.com>:
> The current language order in the bot was done that way because we
> were told to do so by the English Wikipedia. I'd happily change it,
> but THE DECISION IS UP TO THE ENGLISH WIKIPEDIA, NOT TO YOU.
The answer is surely to include interwiki-link ordering as a parameter
that can be set for each wiki. That way, whatever order they're in at
the end of the article, they show up in the correct order in the
rendered page.
The bug is: https://bugzilla.wikimedia.org/show_bug.cgi?id=2867
Surely someone can get that patch into acceptable shape for the MediaWiki code?
(unless there's some problem with it that isn't clear from the bug -
cc to wikitech-l)
- d.
brion(a)svn.wikimedia.org wrote:
> Revision: 35451
> Author: brion
> Date: 2008-05-27 23:46:55 +0000 (Tue, 27 May 2008)
>
> Log Message:
> -----------
> Add $wgCentralAuthCreateOnView config var to control the autocreation on page view for global sessions.
>
> It's a bit annoying at the moment; clogging logs and freaking people out as they gain accounts without realizing they're visiting various sites, such as CSS and JS pulled from shared sites.
>
> Would strongly prefer to reduce this to active behaviors at this time (edit, login, etc).
>
If it "clogs logs", then fix the logs. I don't buy these hand-wavy
arguments about it being "scary" or "active" or whatever.
You're introducing a concept of local account creation to the user which
I'd like to hide as much as possible. This is meant to be a central
account system. The idea of logging in once causing you to be logged in
everywhere is a simple one from the user perspective, but has been made
technically complex by the choice of architecture in CentralAuth.
Because of this architecture, we need to create a local user_id for each
user in order for them to appear to be logged in on a wiki. This is not
necessary in other implementations.
The reason the action is logged is because creation of a local user ID
has been conflated with access control and trusted user verification in
the MediaWiki core. But we don't have to expose this architectural
tragedy to everyone who logs in to the site, we only need to expose it
to people who are blocked from account creation, and to people
interested in creating blocks.
I think the user absolutely should be logged in on page view. When they
have a global account, they should see their name in the header wherever
they go. Their preferences, such as interface language, should be
immediately respected. They'll be freaked out because it'll be so great
and they won't believe we could make a login system that works so well.
-- Tim Starling