Privacy Policy Cookie Policy Terms and Conditions Wikipedia:Quick and dirty Checkuser policy/proposal - Wikipedia, the free encyclopedia

Wikipedia:Quick and dirty Checkuser policy/proposal

From Wikipedia, the free encyclopedia

This Wikipedia page is currently inactive and is kept primarily for historical interest. If you want to revive discussion regarding the subject, you should ask for broader input, for instance at the village pump.

Proposed: The community can grant administrators the permission to use the m:CheckUser interface solely for the purposes of tracing the source of persistent vandalism by showing consensus in favour with an WP:RfA-like vote. Any users granted the CheckUser right in this way may not use the checkuser privilege for anything other than tracing the source of persistent vandalism unless further policy on the matter allowing to use it for other purposes is created.

The CheckUser facility may also be used for investigating matters of interest to the Arbitration Committee at an arbitrator's request.

Contents

[edit] Rationale

As those of you regular to RC patrol may have noticed we have been visited by some vandalbots lately. Blocking these has either caused temporary blocks of dynamic or proxy IPs (which should be unblocked as soon as possible to avoid collateral damage), or of open proxies, which should be blocked indefinitely and would serve as good seeds for the open proxy blocker bot.

Since the stewards are not willing to give users the checkuser privilege without policy on the matter (I cannot say I blame them), and there's an obvious urgent need for more people to do IP checks to combat vandalism, I am proposing the above checkuser policy for en:. There is probably also a need for more extensive CheckUser usage, but this is supposed to be a proposal we can all agree on quickly so that we can find people to handle at least these cases.

You can see how CheckUser works at meta:Help:CheckUser.

[edit] Comments

Comments go on talk, amendments or changes should be made here but remember to keep it short and something we can all agree on.


[edit] Straw poll

To assess support for this proposed policy a vote will be held. It will be considered accepted if it receives more than 80% support in the next five day period (ending 21:52, 18 October 2005 (UTC)), provided it has received at least 40 votes. If it has not, it will be considered accepted if it has 80% support at the time it reaches 40 votes.

The straw poll is now closed (as of 18 Oct 2005, 20:27), having passed with a narrow 80.4%.

Contextual Note: There is not uniform acceptance among the persons voting here as to the validity of this straw poll as a method for reaching agreement on the policy being proposed. (note added by Courtland 17:11, 16 October 2005 (UTC))

Clarification: Even if accepted, this proposed policy would NOT give CheckUser access to all administrators.

[edit] Support

  1. --fvw* 21:52, 13 October 2005 (UTC)
  2. Martin 22:02, 13 October 2005 (UTC)
  3. Shimgray | talk | 22:03, 13 October 2005 (UTC)
  4. -Splashtalk 22:09, 13 October 2005 (UTC)
  5. Support. Tintin 22:12, 13 October 2005 (UTC)
  6. Radiant_>|< 22:14, 13 October 2005 (UTC)
  7. Carbonite | Talk 22:22, 13 October 2005 (UTC)
  8. GraemeL (talk) 22:23, 13 October 2005 (UTC)
  9. Hall Monitor 22:28, 13 October 2005 (UTC)
  10. Greg Asche (talk) 22:35, 13 October 2005 (UTC)
  11. WikiFanaticTalk Contribs 17:41, 13 October 2005 (CDT)
  12. ABCD 22:43, 13 October 2005 (UTC)
  13. Carnildo 22:49, 13 October 2005 (UTC)
  14. Titoxd(?!?) 23:48, 13 October 2005 (UTC)
  15. cohesion | talk 00:08, 14 October 2005 (UTC)
  16. Kirill Lokshin 00:46, 14 October 2005 (UTC)
  17. *drew 05:08, 14 October 2005 (UTC)
  18. David Gerard 08:58, 14 October 2005 (UTC) Oh yes please.
  19. Cryptic (talk) 11:30, 14 October 2005 (UTC)
    • BMIComp (talk, HOWS MY DRIVING) 18:26, 14 October 2005 (UTC) After some thought I've decided to oppose. I think we need to grant more trusted users with Checkuser permission, but I don't think RfA style voting is the best way of selecting such users. Popularity amongst administrators does not necesarily mean an administrator is necesarily trustworthy. -- BMIComp (talk, HOWS MY DRIVING) 23:07, 19 October 2005 (UTC)
  20. --Doc (?) 18:50, 14 October 2005 (UTC) (we need to do this immediately, but a fuller policy with checks and ballances must also be developed ASAP)
  21. pgk(talk) 19:08, 14 October 2005 (UTC) as per Doc, needs a full policy and audit
  22. Scimitar parley 21:31, 14 October 2005 (UTC)
  23. I support this, but as others have said, a fuller policy is needed as asap on when adn how this use is sanctioned, adn some sort of publicly visible log should IMO be created that would at least list who is using the tool and how often. Ideally it would indicate what USER IDs hav been checked (but not which IPs to avoide privicy-vioating correlations). DES (talk) 21:50, 14 October 2005 (UTC)
  24. the wub "?!" 22:32, 14 October 2005 (UTC)
  25. Who?¿? 16:09, 15 October 2005 (UTC)
    • As long as a log of such queries is made and a page is made (The one on meta is okay) which explicitly says when it is okay to use this power. I'll always vote to give myself more power. :) Broken S 17:59, 15 October 2005 (UTC) I'm going neutral. I think a log is necessary and the privacy policy should be revised before this is implememnted. Broken S 00:51, 19 October 2005 (UTC)
  26. Dpbsmith (talk) 19:26, 15 October 2005 (UTC)
  27. Ryan Delaney talk 19:41, 15 October 2005 (UTC)
  28. Mgm|(talk) 22:03, 15 October 2005 (UTC) Yes, David and a few developers who spend more time on the software, don't scale. More people need to be given access to this tool to speed up the process of checking IDs. Having an accessible log of such activities is a good idea to enforce accountability. Who should be given access should be the subject of a more detailed proposal.
  29. Weak Support as long as we quickly set up a policy detailing checks and balances, and gain consensus on who would be entrusted with this feature without compromising users' privacy. Zzyzx11 (Talk) 01:30, 16 October 2005 (UTC)
  30. JAranda | watz sup 02:02, 16 October 2005 (UTC)
  31. --Celestianpower hablamé 14:51, 17 October 2005 (UTC)
  32. Unbelievably strong support for this policy. Checkuser is a needed tool. Andre (talk) 17:08, 17 October 2005 (UTC)
  33. Access to be granted, but very sparingly. — Dan | Talk 01:30, 18 October 2005 (UTC)
  34. What Rdsmith4 said. I find it odd that many of the oppose voters clearly haven't read the proposal, as it says nothing about giving it to all admins. Ambi 01:37, 18 October 2005 (UTC)
  35. Giving CheckUser to those who can utilize it is a no-brainer. - RoyBoy 800 01:46, 18 October 2005 (UTC)
  36. Absolutely. We need to shut down vandalbots and rampant abusive sock creators; as we grow it's only going to get worse. Antandrus (talk) 01:49, 18 October 2005 (UTC)
    And what recent vandalbot hasn't been jumping IPs? Our obligation to be honest with our users about their level of privacy far outweighs dealing with minor nuisances. --Gmaxwell 15:00, 18 October 2005 (UTC)
    If you think those vandalbots are "minor" nuisances I don't think you do much RC patrol. For another, patterns of jumped IPs can be extremely significant, and a human can see them. Geographical locations of IPs, for example, are an important bit of evidence. Antandrus (talk) 02:41, 19 October 2005 (UTC)
  37. Support, with a few caveats I consider obvious: the logs of who used the priviledge and when are available to at least all admins and the logs of what was checked are available to at least a few people, maybe all bcrats and arbcom members. Overall if we have an RFA style process, I'm sure the standards for this will be very high. - Taxman Talk 12:01, 18 October 2005 (UTC)
    Then shouldn't you vote neutral, as AFAICS nobody with the power to do so has shown any indication that they will actually make a log available? ~~ N (t/c) 14:50, 18 October 2005 (UTC)
  38. Sure. Ryan Norton T | @ | C 18:09, 18 October 2005 (UTC)

[edit] Oppose

  1. Oppose - this widens the base of users who have access to this information, and who are expected to make sense of it. From what I gather from reading David Gerard's various notes on it, the output of the Checkuser extension is not exactly easy to interpret. We could have administrators bringing up false positives and so forth, based on shoddy guesswork arising from not understanding the output correctly. In addition, we have a duty to protect privacy, and I don't feel the proposal is rationalised well enough; the scope of use is too broad, for one thing. I worry also that this creates another procedure not unlike requests for adminship which in turn could bring problems. Rob Church Talk | FAD 23:34, 13 October 2005 (UTC)
    Just because it is complicated doesn't mean we can't train those given this power on how to interpret it. -Greg Asche (talk) 23:55, 13 October 2005 (UTC)
    We don't need to. We've got plenty of technically competent admins to do the job. --fvw* 23:57, 13 October 2005 (UTC)
    If someone understands networks and IP numbers, it's not that hard to learn. I am also very happy to spend time teaching others how to do it - that would actually make the task scale! I could probably teach you in not too long, for instance - David Gerard 08:58, 14 October 2005 (UTC)
    I'll take that as blatant flattery. Thanks. :-) Rob Church Talk | FAHD 16:05, 15 October 2005 (UTC)
     :-) Check m:Help:CheckUser - basic network competence, some clue as to the behaviour of trolls and great respect for the privacy policy is about all it takes. I'm adding to the "Hints and Tips" as I think of 'em - David Gerard 15:40, 17 October 2005 (UTC)
  2. Courtland 23:36, 13 October 2005 (UTC) I have read through some of the discussion here and at the meta site and agree with User:Grace Note in the commentary under m:CheckUser#Do you think this feature should be made more widely available?
    We're not only dealing with trolls here. We're dealing with people who hear about the size of Wikipedia and try to find a way to make our life impossible just because they feel like it. There's not much we can do against those external threats but block them. Titoxd(?!?) 23:59, 13 October 2005 (UTC)
  3. Strongly oppose admins getting checkuser capabilities. It should be limited to Stewards, or Stewards and a few respected Bureaucrats and Arbcomm members. No matter who gets the capability, there should be a log records ALL checkuser checks. BlankVerse 16:41, 14 October 2005 (UTC)
    This proposal only says some people should be given access and suggests it might be done using an RFA type vote. It didn't say this should be given to all admins, just to more people in general. - Mgm|(talk) 22:01, 15 October 2005 (UTC)
    As it stands, this proposal lacks many of the details necessary to make a proper decision. It also has a very rushed feel to it, as if there has been an attempt to stack the support votes before there is greater publicity for the proposal. BlankVerse 10:55, 16 October 2005 (UTC)
  4. Oppose with prejudice; poorly thought out proposal open to abuse. I would trust David Gerard and a number of highly regarded bcrats with this function, but that is all. Erwin
  5. Oppose until an more thorough system of checks and balances can be established. I fully agree with the need for such an ability and would like to see repeat vandals possibly perma banned, yet am concerned on how we enforce the rule that admins will only use the tool when prescribed. A less vague set of standards which increase the checks and balances on Admins as to when and where the ability is to be incorporated would possibly change my vote to support.--MONGO 06:01, 16 October 2005 (UTC)
    MONGO, the approval of this proposal means that a permanent policy will immediately be drafted and set for approval. Titoxd(?!?) 04:46, 17 October 2005 (UTC)
  6. No way. Admins are supposed to be ordinary users. If they are given the ability to pry into personal information, this is totally unacceptable. Too much time is already wasted on witchhunting sockpuppets, which gives them more incentive to troll you in the first place. This and the plain fact that it would be abused, just as all other admin powers are, make me strongly oppose this proposal. Revert vandals, ignore insults, don't feed the trolls. Do those three things and this wouldn't even be a problem. It is without question the behaviour that is always the menace, not the person, so deal with the behaviour. Grace Note 23:53, 17 October 2005 (UTC)
  7. Strong Oppose we need to change the privacy policy before we even consider anything like this. The current privacy policy is already out of date with established practices. Users already do not have the privacy we imply they have. --Gmaxwell 00:07, 18 October 2005 (UTC)
  8. Oppose Admins should have the minimum possible privileges. Some of them are prone to thinking of themselves as special, but they should simply be seen as normal uses who do certain dull administrative tasks. CalJW 00:50, 18 October 2005 (UTC)
  9. Strong oppose per Gmaxwell and BlankVerse. --Blackcap | talk 01:03, 18 October 2005 (UTC)
  10. Oppose - I can hardly think people will understand the technicalities of Dynamic IP addressing. As an added extra the fast-slow change stuff. There are an *amazing* number of ISPs, to "learn" how fast or slow they change their IPs is downright impossible. --Msoos 15:35, 18 October 2005 (UTC) [not an admin]

[edit] Other/Neutral

  1. Will support if and only if a full checkuser log (i.e., including everything but IP address) is visible to all users and IPs, and a policy is implemented imposing desysopping and a long ban for inappropriate use of checkuser powers. I see no reason why either of these conditions would be harmful, aside from the time taken to code the first if it does not already exist. However, unless these precautions are taken, people should not be given powers with potential off-Wiki consequences based only on on-Wiki trust. ~~ N (t/c) 00:05, 14 October 2005 (UTC)
    As I mentioned on talk, people already have the power to find a logged-in user's IP. This would merely add permission to do so and a method of going back in time a little. --fvw* 00:08, 14 October 2005 (UTC)
    Well, they should not be given those things without caution, and ideally the current ability shouldn't be there. Also, the Javascript method is logged - not easy to find, but logged nonetheless. And it can be gotten around by disabling Javascript (which anyone really serious about online privacy will hopefully do (although this should not be taken to say that those who don't know how to do not deserve privacy)). And the permission part is just as worrisome as the technical ability. ~~ N (t/c) 00:18, 14 October 2005 (UTC)
    Even assuming javascript is disabled, you can still modify the mediawiki plain html variables; unless you turn off CSS, embedded media, images, and frames too you're pretty much chanceless against an admin who wants your IP. Even if it was noticed, I think with a little effort you could even make it look like an honest mistake to someone who assumes good faith, if you registered the appropriate typo of wikipedia.org.
    As for the permission, why do you think we need to protect the privacy of persistant vandals like the vandalbot or willy on wheels? If you're afraid it would be used against others and you have a stricter definition of who can be checked to propose I'm all for it. --fvw* 00:23, 14 October 2005 (UTC)
    I don't care about Willy's privacy, but the problem is that checkuser ability can self-evidently be used against anyone. It also takes no technical skill (unlike the Javascript method), and unless the log is made public (which was my main condition for supporting) its use is hidden. That's my biggest problem - I'd be fine with giving checkuser to a fairly broad range of people if its usage were transparent.
    Besides, if getting the IP is so easy already, why have this policy? ;-) ~~ N (t/c) 00:32, 14 October 2005 (UTC)
    Partially because not only technical access is needed but also permission to do so, and partially because as the accounts are probably bot-run they won't run javascript, and using a more brute-force method would be necessary (like including off-site CSS). This would reveal the IPs of all users reading wikipedia at that time, not just the vandals. --fvw* 00:36, 14 October 2005 (UTC)
    Yes, but once you're approved you have that technical access until it's revoked. So there needs to be a codified punishment for misuse, as well as a public log of all uses. ~~ N (t/c) 00:39, 14 October 2005 (UTC)
    If you don't want to expand anyone's privileges I'd be fine with requiring everyone who gets this priv to demonstrate that they're able to find someone's IP without it beforehand if you want :) --fvw* 00:37, 14 October 2005 (UTC)
     :) ~~ N (t/c) 00:39, 14 October 2005 (UTC)
    Nick has a point. If we implement it, we can make Special:Checklog or something like that, where CheckUser queries would be stored (much like the Block log and others). Titoxd(?!?) 00:42, 14 October 2005 (UTC)
    I'm all for it, I'd just rather not have this policy depend on that technical issue being resolved as in my experience it takes absolutely ages, and I'd like to get this through quickly. --fvw* 00:49, 14 October 2005 (UTC)
    If the point is only to deal with the current vandalbot attack, then there's no need to make it this general. Why not just have a vote on "should users X, Y, and Z get checkuser", where X, Y, and Z are extremely trusted long-term users (preferably already bureaucrats)? It'd go through faster (because there would be no need for separate approval of the policy and of each user), and I would be willing to support users that I strongly trusted even if there were no log feature or formal revocation procedure. ~~ N (t/c) 00:54, 14 October 2005 (UTC)
    Perhaps, but basicly I want access to checkuser myself and I didn't want to propose policy to give myself extra permissions, at least not directly :-) --fvw* 00:59, 14 October 2005 (UTC)
    Well, as I said before, that's to iron out once we get the permanent policy for vote. Titoxd(?!?) 01:03, 14 October 2005 (UTC)
    Such a log might itself give away far more information than the privacy policy allows. "Oh, Bob checked User:Querulous at 5:46pm, and IP 111.222.333.444 at 5:47pm. Bet they're the same, or related." - David Gerard 08:58, 14 October 2005 (UTC)
    Then it should only log checks on usernames, as abusive checks are much more likely to be of that form. ~~ N (t/c) 13:27, 14 October 2005 (UTC)
    The log could display data as simple as the CheckUser user (not the username being checked) and a timestamp. This would allow evertyone to see how much certain users are accessing CheckUser. Users with CheckUser access would be able to see the full logs and make sure that the function wasn't being abused. Wider access to CheckUser means better oversight. Carbonite | Talk 13:57, 14 October 2005 (UTC)
    I agree with Carbonite on this. The CheckUser log could say 15:44, 14 October 2005 (UTC): Titoxd accessed the IP database or something. Then, we can ask people why they did so. Titoxd(?!?) 15:44, 14 October 2005 (UTC)
    Including the ability to leave an "edit summary" here - as with blocking, for example - might be helpful, and forestall a lot of oversight questioning. Shimgray | talk | 18:45, 14 October 2005 (UTC)
  2. It should be noted that those signed up for the m:Toolserver and request for database access will have the same power to check a user's info by querying the database directly. I think. --AllyUnion (talk) 09:32, 14 October 2005 (UTC)
    Eeeeek!!! Please check if this is the case! - David Gerard 13:00, 14 October 2005 (UTC)
    This is not currently the case. Right now the toolserver db isn't linked to the live databases at all. Once the link is established it will be via a special tool, not via replication, so we can filter what is provided. However, it is likely that some applications developed on the toolserver will require information that we would otherwise filter. Amusingly, users with toolserver access seeing the data would be in greater conformance with the privacy policy than what this proposal is proposing, since toolserver users could be seen as an extended community of developers. --Gmaxwell 14:45, 18 October 2005 (UTC)
    i should note that this will never be the case. the only Wikimedia information which will be available via m:Toolserver is data which already exists in the public database dumps. the server is entirely separate from the normal cluster and there is no kind of mutual access for any users. kate.
  3. Something should be added to the policy about disclosure of the information. We could simply say "disclosure that X=Y is ok, but no disclosure of IPs is allowed", but too often it's obvious that "1.2.3.4=X" because he forgot to log in one time or another. Taw 17:46, 14 October 2005 (UTC)
    I'm not sure that this accomplishes much, for example, if Y admited to being anon 1.2.3.4 earlier, than X=Y tells you X=1.2.3.4. Furthermore, for we've been telling people for some time if they want to edit without people using the spectrum of their edits to tie their pseudonym to a person to split their editing into multiple users by subject area. Allowing people to carelessly disclose such information will break peoples expected privacy. Also, just because two users have edited from the same IP doesn't mean they are the same user. In such cases the output of a sockcheck would do much to reveal the identy of the suspected sock to anyone else who has edited from the same IP. Finally, the sockcheck tool only gives x=y, not x=1.2.3.4, already. :) --Gmaxwell 15:53, 18 October 2005 (UTC)
  4. Support iff privacy policy is updated. Pakaran 01:59, 18 October 2005 (UTC)

[edit] Post closure

Comments and votes made after the closure of the straw poll.

[edit] Support (post closure)

  1. Merovingian (t) (c) (e) 01:16, 20 October 2005 (UTC)
  2. Neutralitytalk 01:32, 20 October 2005 (UTC)
  3. ClockworkSoul 16:11, 28 December 2005 (UTC)

[edit] Oppose (post closure)

  1. Oppose, just because I think there's always a developer on hand to ask, and that should only happen when there's a lot of evidence. So for now I'll have to concur with Gmaxwell. Redwolf24 (talk) 02:40, 19 October 2005 (UTC)
  2. Oppose. I want to see more than a beauty contest for this kind of power. --Tony SidawayTalk 04:44, 19 October 2005 (UTC)
  3. Oppose, this needs to be kept in the hands of very few people; say by special appointment only. Make it too easy and trolls in disguise will get their hands on it. — Davenbelle 11:19, 19 October 2005 (UTC)
  4. After some thought I've decided to change my vote to oppose. I think we need to grant more trusted users with Checkuser permission, but I don't think RfA style voting is the best way of selecting such users. Popularity amongst administrators does not necesarily mean an administrator is necesarily trustworthy. -- BMIComp (talk, HOWS MY DRIVING) 23:07, 19 October 2005 (UTC)
  5. Oppose, secondarily because I agree that this power with potential off-Wiki consequences cannot be granted by a popularity contest, and primarily because it seems nobody is interested in implementing a publically visible log of checkuser usage. ~~ N (t/c) 23:51, 19 October 2005 (UTC)
  6. Oppose - too many loopholes and unanswered questions at the moment I think. --HappyCamper 01:12, 20 October 2005 (UTC)
  7. Oppose. Not convinced there are enough safeguards in place. --Maru (talk) 18:13, 22 October 2005 (UTC)
  8. Oppose — sorry, but after the "fiasco" (as described on the mailing list), I'm convinced we're rushing too fast into deep waters. Flcelloguy | A note? | Desk | WS 22:02, 20 October 2005 (UTC)
  9. Oppose due to it being used for possible abuse methods, and also I see this proving more harm than useful. Zach (Sound Off) 02:08, 23 October 2005 (UTC)
  10. Oppose not enough safegards. While it may be sensible to give more people this power those people should be chosen by the foundation (not by a by a popularity contest) and they should have a legal duty to protect privacy. Andreww 05:07, 23 October 2005 (UTC)
THIS WEB:

aa - ab - af - ak - als - am - an - ang - ar - arc - as - ast - av - ay - az - ba - bar - bat_smg - be - bg - bh - bi - bm - bn - bo - bpy - br - bs - bug - bxr - ca - cbk_zam - cdo - ce - ceb - ch - cho - chr - chy - closed_zh_tw - co - cr - cs - csb - cu - cv - cy - da - de - diq - dv - dz - ee - el - eml - en - eo - es - et - eu - fa - ff - fi - fiu_vro - fj - fo - fr - frp - fur - fy - ga - gd - gl - glk - gn - got - gu - gv - ha - haw - he - hi - ho - hr - hsb - ht - hu - hy - hz - ia - id - ie - ig - ii - ik - ilo - io - is - it - iu - ja - jbo - jv - ka - kg - ki - kj - kk - kl - km - kn - ko - kr - ks - ksh - ku - kv - kw - ky - la - lad - lb - lbe - lg - li - lij - lmo - ln - lo - lt - lv - map_bms - mg - mh - mi - mk - ml - mn - mo - mr - ms - mt - mus - my - mzn - na - nah - nap - nds - nds_nl - ne - new - ng - nl - nn - no - nov - nrm - nv - ny - oc - om - or - os - pa - pag - pam - pap - pdc - pi - pih - pl - pms - ps - pt - qu - rm - rmy - rn - ro - roa_rup - roa_tara - ru - ru_sib - rw - sa - sc - scn - sco - sd - se - searchcom - sg - sh - si - simple - sk - sl - sm - sn - so - sq - sr - ss - st - su - sv - sw - ta - te - test - tet - tg - th - ti - tk - tl - tlh - tn - to - tokipona - tpi - tr - ts - tt - tum - tw - ty - udm - ug - uk - ur - uz - ve - vec - vi - vls - vo - wa - war - wo - wuu - xal - xh - yi - yo - za - zea - zh - zh_classical - zh_min_nan - zh_yue - zu

Static Wikipedia 2008 (no images)

aa - ab - af - ak - als - am - an - ang - ar - arc - as - ast - av - ay - az - ba - bar - bat_smg - bcl - be - be_x_old - bg - bh - bi - bm - bn - bo - bpy - br - bs - bug - bxr - ca - cbk_zam - cdo - ce - ceb - ch - cho - chr - chy - co - cr - crh - cs - csb - cu - cv - cy - da - de - diq - dsb - dv - dz - ee - el - eml - en - eo - es - et - eu - ext - fa - ff - fi - fiu_vro - fj - fo - fr - frp - fur - fy - ga - gan - gd - gl - glk - gn - got - gu - gv - ha - hak - haw - he - hi - hif - ho - hr - hsb - ht - hu - hy - hz - ia - id - ie - ig - ii - ik - ilo - io - is - it - iu - ja - jbo - jv - ka - kaa - kab - kg - ki - kj - kk - kl - km - kn - ko - kr - ks - ksh - ku - kv - kw - ky - la - lad - lb - lbe - lg - li - lij - lmo - ln - lo - lt - lv - map_bms - mdf - mg - mh - mi - mk - ml - mn - mo - mr - mt - mus - my - myv - mzn - na - nah - nap - nds - nds_nl - ne - new - ng - nl - nn - no - nov - nrm - nv - ny - oc - om - or - os - pa - pag - pam - pap - pdc - pi - pih - pl - pms - ps - pt - qu - quality - rm - rmy - rn - ro - roa_rup - roa_tara - ru - rw - sa - sah - sc - scn - sco - sd - se - sg - sh - si - simple - sk - sl - sm - sn - so - sr - srn - ss - st - stq - su - sv - sw - szl - ta - te - tet - tg - th - ti - tk - tl - tlh - tn - to - tpi - tr - ts - tt - tum - tw - ty - udm - ug - uk - ur - uz - ve - vec - vi - vls - vo - wa - war - wo - wuu - xal - xh - yi - yo - za - zea - zh - zh_classical - zh_min_nan - zh_yue - zu -

Static Wikipedia 2007:

aa - ab - af - ak - als - am - an - ang - ar - arc - as - ast - av - ay - az - ba - bar - bat_smg - be - bg - bh - bi - bm - bn - bo - bpy - br - bs - bug - bxr - ca - cbk_zam - cdo - ce - ceb - ch - cho - chr - chy - closed_zh_tw - co - cr - cs - csb - cu - cv - cy - da - de - diq - dv - dz - ee - el - eml - en - eo - es - et - eu - fa - ff - fi - fiu_vro - fj - fo - fr - frp - fur - fy - ga - gd - gl - glk - gn - got - gu - gv - ha - haw - he - hi - ho - hr - hsb - ht - hu - hy - hz - ia - id - ie - ig - ii - ik - ilo - io - is - it - iu - ja - jbo - jv - ka - kg - ki - kj - kk - kl - km - kn - ko - kr - ks - ksh - ku - kv - kw - ky - la - lad - lb - lbe - lg - li - lij - lmo - ln - lo - lt - lv - map_bms - mg - mh - mi - mk - ml - mn - mo - mr - ms - mt - mus - my - mzn - na - nah - nap - nds - nds_nl - ne - new - ng - nl - nn - no - nov - nrm - nv - ny - oc - om - or - os - pa - pag - pam - pap - pdc - pi - pih - pl - pms - ps - pt - qu - rm - rmy - rn - ro - roa_rup - roa_tara - ru - ru_sib - rw - sa - sc - scn - sco - sd - se - searchcom - sg - sh - si - simple - sk - sl - sm - sn - so - sq - sr - ss - st - su - sv - sw - ta - te - test - tet - tg - th - ti - tk - tl - tlh - tn - to - tokipona - tpi - tr - ts - tt - tum - tw - ty - udm - ug - uk - ur - uz - ve - vec - vi - vls - vo - wa - war - wo - wuu - xal - xh - yi - yo - za - zea - zh - zh_classical - zh_min_nan - zh_yue - zu

Static Wikipedia 2006:

aa - ab - af - ak - als - am - an - ang - ar - arc - as - ast - av - ay - az - ba - bar - bat_smg - be - bg - bh - bi - bm - bn - bo - bpy - br - bs - bug - bxr - ca - cbk_zam - cdo - ce - ceb - ch - cho - chr - chy - closed_zh_tw - co - cr - cs - csb - cu - cv - cy - da - de - diq - dv - dz - ee - el - eml - en - eo - es - et - eu - fa - ff - fi - fiu_vro - fj - fo - fr - frp - fur - fy - ga - gd - gl - glk - gn - got - gu - gv - ha - haw - he - hi - ho - hr - hsb - ht - hu - hy - hz - ia - id - ie - ig - ii - ik - ilo - io - is - it - iu - ja - jbo - jv - ka - kg - ki - kj - kk - kl - km - kn - ko - kr - ks - ksh - ku - kv - kw - ky - la - lad - lb - lbe - lg - li - lij - lmo - ln - lo - lt - lv - map_bms - mg - mh - mi - mk - ml - mn - mo - mr - ms - mt - mus - my - mzn - na - nah - nap - nds - nds_nl - ne - new - ng - nl - nn - no - nov - nrm - nv - ny - oc - om - or - os - pa - pag - pam - pap - pdc - pi - pih - pl - pms - ps - pt - qu - rm - rmy - rn - ro - roa_rup - roa_tara - ru - ru_sib - rw - sa - sc - scn - sco - sd - se - searchcom - sg - sh - si - simple - sk - sl - sm - sn - so - sq - sr - ss - st - su - sv - sw - ta - te - test - tet - tg - th - ti - tk - tl - tlh - tn - to - tokipona - tpi - tr - ts - tt - tum - tw - ty - udm - ug - uk - ur - uz - ve - vec - vi - vls - vo - wa - war - wo - wuu - xal - xh - yi - yo - za - zea - zh - zh_classical - zh_min_nan - zh_yue - zu