Wikimedia Forum/Archives/2012-02

citing on wikipedia is difficult and time-consuming-technical barrier-suggestion

As a new contributor to wikipedia, I want to raise the issue that citing on wikipedia is complicated, difficult and time-consuming. It is a technical barrier to contribution. It can certainly be overcome by a drop-like system. Google scholar can detect automatically the characteristics of a reference (author, journal, etc...), why not wikipedia?

If your question is specific to Wikipedia, can I suggest you post it here? This is where new ideas for Wikipedia are discussed (on the English Wikipedia. There will be different pages for other language projects). QU TalkQu 21:20, 13 January 2012 (UTC)
I recommend you try our tool for this, ProveIt. I think it could ease your citation work. Superm401 | Talk 05:16, 9 February 2012 (UTC)

opendata

Shoulden't there be a site opendata here, as a 'focus' to things related to this term within wikimedia? --Itu 17:00, 31 January 2012 (UTC)

Can you explain what you are meaning. What sort of examples of information are wishing to see? billinghurst sDrewth 03:54, 3 February 2012 (UTC)
I do not know in detail what there should be written or explained. But i feel this is an really important issue with close relationship to a 'all-over'-open-content-organisation like wikimedia.... --Itu 04:13, 8 February 2012 (UTC)

interwiki's

There is something strange going on with the iw's at wiktionary Jcwf 00:17, 1 February 2012 (UTC)

The problems is in all projects----Antur 00:21, 1 February 2012 (UTC)
Yes, it seems... A software problem?? Jcwf 00:24, 1 February 2012 (UTC)
Interwiki map was updated very recently, techs are working to see what has gone wrong. billinghurst sDrewth 00:28, 1 February 2012 (UTC)
Thanks Jcwf 00:30, 1 February 2012 (UTC)
There back. If a page is broken, purge the page, and if it continues, please report back here. billinghurst sDrewth 00:36, 1 February 2012 (UTC)

They are broken again. --birdy geimfyglið (:> )=| 19:35, 1 February 2012 (UTC)

People are working on it at the moment. It´s known. --WizardOfOz talk 19:50, 1 February 2012 (UTC)
  Fixed --WizardOfOz talk 20:23, 1 February 2012 (UTC)

Number of active users equal to -1

Why number of active users is equal to "-1" for some Wikipedias? For example, for Polish: (pl:Special:Statistics) or Northern Sotho (nso:Special:Statistics). -- Ace111 01:38, 3 February 2012 (UTC)

Looks like something screwy in the database. If it really bothers you, feel free to lodge it within bugzilla:. If you are only after the stats then please look at http://stats.wikimedia.org/EN/SummaryPL.htm billinghurst sDrewth 03:51, 3 February 2012 (UTC)
The problem seems to be discussed already for 3 years: https://bugzilla.wikimedia.org/show_bug.cgi?id=20017. -- Ace111 10:34, 3 February 2012 (UTC)
)-: Special:Statistics has dodgy bits, the article count per use is wrong, so not much we can do until the MediaWiki programmers prioritise it. Bugzilla is that tool, and not much we can do from in here. billinghurst sDrewth 12:06, 3 February 2012 (UTC)

Expanding the abilities of global countervandalism on Wikimedia

Hello all, I present you with a proposal that I've been considering putting forward for a few months now. Over a year of countervandalism on Wikimedia has taught me two things; we don't have enough stewards and global sysops, and we don't have many good tools for fighting vandalism and spam across many wikis. Since it is pretty clear that the lack of stewards and global sysops isn't going to change quickly (only 10 steward candidates up for election this year), I'd suggest that we instead focus on improving the countervandalism tools available to stewards, global sysops and I'd even say global rollbackers. Below are sections for two extensions which would drastically improve our response to cross-wiki countervandalism. Feel free to add another section if you know of a tool or extension which would also help.

Please note that this is not a vote for whether or not we enable these; this is a proposal to see if the current global community would be accepting of them. If there is a good response here, I will organize or help to organize a global vote on this matter. Ajraddatz (Talk) 18:48, 4 February 2012 (UTC)

SpamRegex

SpamRegex is an old extension used by Wikia to block abused text and links in page content, edit summaries and move summaries. Essentially acting as a global AbuseFilter, SpamRegex would allow a user with access to it to block the word hello from being added to any page on any Wikimedia site. I would suggest that this extension be used only in emergencies, to block phrases which are being spammed crosswiki on a temporary basis. An example of when this could be used is when a cross-wiki vandal with lots of proxies is adding Ajraddatz is funny looking to many pages across many wikis. Instead of waiting for the vandal to get tired of creating new accounts, simply add that sentence to the SpamRegex and it is blocked from use everywhere. More info can be found on the extension page linked to above.

Benefits
  • Better response to cross-wiki vandalism and spam.
  • Easier than needing to block IP after IP or user after user.
  • Doesn't require sharedDB, meaning we could actually use this in its present state.
  • Could replace the spam blacklist, allowing for easier logging and expanded functionality.
Could be considered as either benefit or disadvantage
  • Currently does not have a public log - This could be good in that vandals couldn't see how to bypass the extension, though bad for transparency. Solution could be making a semi-public log viewable by autoconfirmed, or just a public log.
Disadvantages
  • Older extension, obsolete on many wikifarms and *could* need some work before being enabled here. At the same time, this is more modern than what we use.

I would recommend that this be available to stewards and global sysops (though I doubt anyone will support it for gs). Even without a public log at this point (which is easily fixed), there is a list of all blocked phrases so abuse of this isn't really an issue here. Please discuss. Ajraddatz (Talk) 18:48, 4 February 2012 (UTC)

Discussion

Global AbuseFilter

Global AbuseFilter would give us all of the functionality of SpamRegex, and even more. It is the AbuseFilter, but on a global level. It would be used to prevent cross-wiki vandalism.

Benefits
  • All of the benefits of local AbuseFilters, but global!
Disadvantages
  • Not fully developed.
  • Lack of active development and bug fixing (?) / Sometimes a bit complicated to program. [added by MarcoAurelio (talk · contribs)]

This needs a bit of work before it can be used, but I am more than willing to contact the required people and get the ball rolling on this if consensus is achieved. I recommend that it be available to stewards and global abusefilter editors (and global sysops if possible). We could also use SpamRegex until global AbuseFilter becomes available. Please discuss. Ajraddatz (Talk) 19:32, 4 February 2012 (UTC)

Discussion

  • Support using SpamRegex until global AbuseFilter becomes available. Ajraddatz (Talk) 19:32, 4 February 2012 (UTC)
  • Approach with extreme caution. If global work has taught me something, is that regexes that may be "bad" in some language not rarely match harmless and frequently in other languages. There's for example english regexes filtering new account names and regularly they trigger common usernames on spanish.
Moreover, within a single language, only very specific and limited regexes have neglibible false positives. Add a few hundred languages andyou're up for blocking a lot of good contributions. So this only would work if blockings were extremely narrow both in scope and time. Otherwise, better not. es:Magister Mathematicae 21:18, 4 February 2012 (UTC)
You bring up a great point, and I agree. Policy around the use of these tools should reflect a very short time-frame and a very specific target. Ajraddatz (Talk) 21:21, 4 February 2012 (UTC)
  • I would support global abuse filters, but I do not know how developed they are + I'd like to know if anybody is currently working activelly on the extension. There's currently ~95 open bugs regarding this extension. AbuseFilter is one of the best antiabuse tools I've used, but it can turn into a nightmare if we enable it at a global level and there's nobody there working on the bugfixing thing. Thanks. —Marco Aurelio (Nihil Prius Fide) 22:42, 5 February 2012 (UTC)
  • I've contacted the person who made abusefilter, and he tells me that global filters are indeed possible and viable. I am now asking him if there is any way for communities to locally disable a global filter. Ajraddatz (Talk) 19:26, 7 February 2012 (UTC)
  • I think this is a good idea, and that it would be very helpful in combatting cross-wiki spam/vandalism. I have some questions:
    1. Does this mean we need a new group for global abusefilter management?
    2. How can we override/disable these locally? Can we?
    3. How stable is this? Is it ready at its current state?
Also, the proposal above looks ok. πr2 (tc) 03:17, 10 February 2012 (UTC)

RegexBlock

RegexBlock uses a sharedDB to block either an exact username, or a regex from editing all Wikimedia projects. That means that instead of locking KittiesOnFire1568, KittiesOnFire1567, and KittiesOnFire1542, stewards could just regexblock KittiesOnFire with the correct regex and be done with it. This would not only prevent quite a bit of abuse, but it would allow for stewards to more efficiently deal with cross-wiki vandals.

Benefits
  • Allows for regex and exact match blocking.
  • Actually shows the blocked user a reason, instead of CentralAuth's password not accepted message.
Could be considered as either benefit or disadvantage
  • Currently does not have a public log - One could be made.
Disadvantages
  • Doesn't currently work with CentralAuth, meaning that we would either need to start using a sharedDB (yes, I know the technical complications) or modify it to work with CentralAuth. The latter is more practical I bet.
  • RegexBlock does not allow for oversighting of usernames - CentralAuth would still need to be used for that, or local oversighting.

I would recommend that this be enabled (when ready) for stewards and global sysops, though again I doubt anyone will support it being enabled for global sysops. Please discuss. Ajraddatz (Talk) 18:48, 4 February 2012 (UTC)

Discussion

  • I'd say that it's well worth the time put in to modifying the extension, as it takes us out of the dark ages in terms of global blocks and locks. Ajraddatz (Talk) 18:48, 4 February 2012 (UTC)
  • Hello Ajraddatz. Thanks for proposing this move. I don't say it won't be useful, but quite frankly there are far more things to do before this to improve the way stewards work... A global title blacklist still exists but is never used : if we forbid the creation of user accounts including the name "KittiesOnFire", this vandal will simply move to an other username and we will no more be able to detect it. But this present several disadvantages as it will higher the delay pages are loaded.
    There are several bugs, even critical bugs with the CentralAuth extension. Sometimes we check the "oversight" box and things are not oversighted. But nobody wants to handle that, apparently. That's the same as global blocks, stewards would really need a way to autoblock IPs globally when locking an account. But this does not seems to be a priority for coders as only 40 people are needing it... -- Quentinv57 (talk) 20:45, 4 February 2012 (UTC)
    Part of the current problems is that everything is spread out - we have two interfaces for gblocking users and IPs, the spam blacklist is not available to all stewards and not used as it should be. I am going to be spending some time over the next few months creating a large initiative to "fix" global countervandalism. This is what I see as a temporary first step, to temporarily solve some of these problems without needing to redo the system. Ajraddatz (Talk) 20:52, 4 February 2012 (UTC)
  • While this is not as problematic as content filtering in the previous section (usernames are much less likely to cause false positives), there is already a system for blocking username creations based on regexes. That is, if we determine any username matching a regex is to be blocked, we simply forbid creating matches on that regex instead of allowing creation and then blocking it if matches. es:Magister Mathematicae 21:20, 4 February 2012 (UTC)
I notice that you have some misunderstandings as well. This is *NOT* the spam blacklist. And yes, all stewards have access to both blacklists. es:Magister Mathematicae 21:23, 4 February 2012 (UTC)
I know this isn't the spam blacklist, it's the Title blacklist which is the candle to this extension's electric light. There are some stewards who aren't local admins, and because of the grey area in scope there it could be suggested that they can't use it. My point is that this extension will combine the title blacklist with an effective global blocking system that shows users why they were blocked. Ajraddatz (Talk) 21:26, 4 February 2012 (UTC)
  • Note - Actually, after further research and organizing of my thoughts I don't think that this extension is what we need. This only includes aspects of what we need, not all of the functionality such as autoblocking on user blocks, etc - as such, consider the regexblocking proposal withdrawn. Ajraddatz (Talk) 22:10, 4 February 2012 (UTC)
  • Ideally we need the abusefilter on a global level, but I'm quite happy with these proposals. It will make the stewards' role somewhat easier, if used with caution. PeterSymonds (talk) 20:04, 5 February 2012 (UTC)
  • Opposed to any of this. Local control is always superior. Seb az86556 23:29, 5 February 2012 (UTC)
    This isn't changing anything in terms of local control. All that is proposed is already possible through various global tools, the point here is consolidating some of them for efficiency and expanded functionality. Ajraddatz (Talk) 23:38, 5 February 2012 (UTC)
    I don't think so. You want a global filter which will of course override local filters lest it will be useless. Seb az86556 00:53, 6 February 2012 (UTC)
    We already use the spam and title blacklists which override local blacklists - these filters are not much more than those. That being said, your concern is definitely a valid one. If any of these are enabled, there needs to be a clear method of reporting false positives and the filters themselves need to be very specific and only enabled as long as they need to be. However, upgrading our current methods of fighting crosswiki vandalism is important - ultimately, we need to recognize that preventing crosswiki abuse can come before giving local communities complete control of what links and content is blocked.
    Allowing projects to disable a global filter locally would be a great addition that would solve this problem. I am looking into the technical feasibility of this. Ajraddatz (Talk) 02:36, 6 February 2012 (UTC)

Notification about block expiries

Hi,

I see open proxies beeng blocked for a year, after what they should be reviewed. Is there any mechanism for tracking their expiry? Now I am able to send various notifications about expiring local blocks with my bot, and will soon be able to do the same with global blocks. Is anyone interested in such a bot? What would the correct place for such notifications be? Bináris tell me 10:20, 7 February 2012 (UTC)

I discontinue watching this section, should anyone be interested or want to tell that the idea is useless, please write to my talk page. Bináris tell me 21:02, 10 February 2012 (UTC)

Renaming of the Local Embassy

I have proposed a renaming on the Village Pump of the English Wikipedia of this useful but misnomered program. Here's the text of the proposal and the comments posted by other editors, who suggested that it be placed here. I am the user identified as DCItalk. DCI2026 20:23, 8 February 2012 (UTC)

I am not sure how difficult a task this would be, but I am suggesting that the "local embassy" feature on Wikipedia be renamed to a less confusing title. Currently, despite the numerous disclaimers, there are still visitors who post comments that might be expected at a foreign nation's embassy or consulate. Wikpedia is not a governmental institution of any kind, and does not need to have a program called the "local embassy," in my opinion. Below are two ideas for a new title:

  • Inter-language assistance
  • Multilingual Help Desk

These are not ideal titles, but could do as temporary ones until a better name could be selected, or a reversion to the "local embassy" title could be put in place. I'm venturing into fairly unfamiliar territory here, but, from my experiences, a renamed program would be more efficient and understandable. Thanks, DCItalk 04:05, 4 February 2012 (UTC)

Two questions. (i) shouldn't all embassies be renamed then (cf Wikimedia Embassy)? (ii) does the thing actually serve any purpose in its current form? A bot-maintained list of active users (perhaps based on the Babel templates + users who express interest) would be a meaningful directory of welcoming volunteers ordered by language. This manual thing, full of inactive and barely active users and contradictions between the supposed "master" list at Wikimedia Embassy and local equivalents, seems like it needs a lot more attention than just a name change. Not that a name change wouldn't help: call it "multilingual volunteer directory" and you have a purpose that you can focus on meeting. Rd232 02:57, 11 February 2012 (UTC)

Dear the Wikipedians, I want to say something. I saw User: Erik Evermtus has been approved for release tuh global block here: Steward_requests/Global/2012-01#Global_block_for_Erik_Evermtus But strangely not be opened until today. In fact in favor of a steward named user:Vittuzu. I have contacted to the proposer and the blocker Vittuzu user:PeterSymonds to ask him to open the global block Evermtus status but no reply let alone implemented. So again I say that hope quickly open the blocked status Evermtus because it is clear already been approved by the steward Vittuzu. Mahali syarifuddin 09:29, 11 February 2012 (UTC)

It was not approved; the steward evidently misinterpreted the request and thought it was a lock request. The lock had been performed by myself, so it was marked as done. However, there has never been any agreement to unlock this user or any of his sockpuppets. PeterSymonds (talk) 14:14, 11 February 2012 (UTC)

MediaWiki 1.19

(Apologies if this message isn't in your language.) The Wikimedia Foundation is planning to upgrade MediaWiki (the software powering this wiki) to its latest version this month. You can help to test it before it is enabled, to avoid disruption and breakage. More information is available in the full announcement. Thank you for your understanding.

Guillaume Paumier, via the Global message delivery system (wrong page? You can fix it.). 15:10, 12 February 2012 (UTC)

(Technical/Where should I ask?) Chrome browser Talk TOC link problem

I noticed some TOC link's seem to be going to the wrong place on the page when clicked in Chrome (but not in Firefox). I've never tried to report a browser issue, and surely don't know if the problem is all Google's, or something in the html here (or a combination of both)which must be addressed.

Is there a specific place on meta I should mention this? (Or all Google's issue, etc) -- Proofreader77 01:04, 15 February 2012 (UTC)

I've noticed this as well. Sometimes Chrome even reloads the entire page, then drops down to that section rather than just dropping down to the anchor point. Killiondude 05:49, 15 February 2012 (UTC)
Thanks for confirming, Killiondude. (Not just my computer having the problem. Windows 7.) Is there any place I should mention this other than this forum? (Or ask someone specific, e.g. MZ?) -- Proofreader77 07:26, 15 February 2012 (UTC)
If the page is not fully loaded (even though it looks like it is) then it will restart from scratch. If the page contains banners or collapsed sections then the browser tries to locate the anchor before JavaScript has finalized the page layout. (I get this all the time in IE7.) These are known issues, but if are experiencing a new problem you can report it at Bugzilla. ~ Ningauble 21:30, 15 February 2012 (UTC)
Many thanks, Ningauble. (And I had used Bugzilla long ago, and forgot all about it.)
m:Tech. I think I've had this issue as well (in Chrome). --MZMcBride (talk) 23:43, 16 February 2012 (UTC)
Thanks, MZ! ... Have been meaning to stop by to purchase some spare wit and charm, but have heard your supplies may be running a bit low of late. ;-) Cheers. -- Proofreader77 (talk) 02:07, 17 February 2012 (UTC)

Commons:Category:Freedom of speech - Crosswiki Sister Link project coordination

I'm doing a cross-collaboration project as a crosswiki sister project coordination at Commons:Category:Freedom of speech. Please feel free to help populate the category there, or add additional language interwiki links, that'd be most appreciated. ;) Cheers, -- Cirt (talk) 09:26, 17 February 2012 (UTC)

document.write() not only discouraged, it doesn't work

I've seen two requests today for help with that ended up in fixing the importAnyScript() function in a user's global.js so that it didn't use document.write() and, instead, uses mw.loader.load(). Check your javascript, and, if it uses document.write(), change it like the fix for this bug. -- MarkAHershberger(talk) 03:15, 18 February 2012 (UTC)

What is Meta For?

As I understand it, Meta used to cover some things which are now covered elsewhere:

  1. "meta" stuff about Wikipedia project operation, which is handled in Wikipedia: namespace on local projects.
  2. tech: wikitech.wikimedia.org
  3. MediaWiki documention: MediaWiki.org
  4. WMF stuff: wikimediafoundation.org
  5. ? others

So what is Meta for today? According to Meta:About Meta

Meta-Wiki currently serves several distinct roles:

  1. Discussion and formulation of the Wikimedia projects, and in particular policy discussion relevant to all projects, such as open content licensing
  2. A forum for personal essays about the Wikimedia projects (as these are usually not delivered from a neutral point of view, they should be summarized on neutral issues pages from multiple point of view using formats like TIPAESA or its subset IPA)
  3. A place to discuss interlanguage co-ordination issues concerning the Wikimedia projects, including discussion in languages other than English

Oddly, this doesn't mention global policies (Meta:Policies and guidelines) or Steward action coordination (Stewards policy), or the various Wikimedia committees.

Anyway, my basic concern is this: most fundamentally, Meta is about multilingual coordination across WMF projects, yes? Yet the multilingualism seems generally quite poorly developed compared to Commons (where it isn't exactly stellar, but certainly better). A lot of the backend of templates and the like is just outdated or non-existent. So... Devil's Advocate: why not get rid of Meta as a separate wiki? Whatever isn't better merged to other wikis (like WMF) can be merged to a Meta namespace at Commons. Then there will only be one multilingual infrastructure to maintain. And whilst the move would be quite a lot of effort, the shakeout would make it clearer what Meta is really for... Rd232 04:55, 7 February 2012 (UTC)

Meta primarily serves as a place for requesting help from users with global rights, requesting global rights, seeking a second opinion in terms of local blocks or crosswiki issues, coordinating fundraisers/elections/etc. Quite honestly, meta could be divided into three wikis - one for a Global Requests Committee if that is ever made, one for global requests and one for coordination. However, meta is actually working quite well even if what actually goes on here isn't apparent to "outsiders". I would be rather opposed to moving parts of meta to content wikis. One of the great parts of meta is that it can act outside of local drama for the most part. Ajraddatz (Talk) 05:25, 7 February 2012 (UTC)
"meta is actually working quite well ..." - for speakers of English? Or for everyone? And if the reason it works "quite well" is obscurity (only insiders know what and how it works or bother to engage with it when not absolutely necessary), I'm not sure that's much of a recommendation for something of meta's purpose. PS I'd hope that at least this thread might lead to improvement of meta:About Meta. So - add a point 4. on Global Rights? Rd232 05:53, 7 February 2012 (UTC)
Meta undertakes the global coordination of the wikimedia product too (miscellany, administrata and administrivia) so it is the host of the global blacklists, title lists, and all the other things that you want to do cross wiki that are cross wiki and need a home. It hosts numbers of gadgets that are project neutral, can be excluded from global blocks, and allows a central coordination. It is that drawer at your desk where you put all those important things that you want to keep but don't fit in the order of any other drawer. 121.79.17.54 11:39, 7 February 2012 (UTC)
Yes, sure. What I'm trying to get at is that it's not really obvious what the added value is to having Meta and Commons as separate wikis. If multilingualism were not such an issue, it wouldn't matter much; but maintaining two sets of multilingual infrastructures is inefficient at best (and it seems to me Meta is quite lacking there). Commons, by virtue of being Wikimedia's central media repository, is already a place where multilingualism is very important and reasonably well-developed; I'm looking for some idea of why a merge of Meta into a Meta namespace at Commons (let's call the concept Meta@Commons, say) would not (in the long-run - leaving aside transition issues) make Meta perform its coordination role better. Rd232 23:22, 7 February 2012 (UTC)
  • It seems you're attacking the problem with the wrong solution. Commons is about creating a free file repository. Meta-Wiki is about interwiki coordination and communication. Meta-Wiki is also the former home of a bunch of projects, as you note, and continues to serve as an incubator for others. And Meta-Wiki serves as a Meatball Wiki of sorts. Among other things. Is there overlap in the two wikis' needs in terms of multilingual support? Of course. They're both used by people speaking different languages and they run literally the exact same software (MediaWiki). There's going to be some overlap in their needs. But the answer isn't to try to merge the two sites. High-level content separation is a good thing. One site is devoted to free media. One is devoted to being a catch-all and global (Wikimedia) wiki.

    For what it's worth, I think most people agree with you that Meta-Wiki is heavily focused on English and that Meta:About Meta is in need of improvement. Workable solutions for either of those problems is, of course, always welcome. :-) --MZMcBride 05:24, 8 February 2012 (UTC)

    • Thanks for your reply, but that's not really entirely convincing, because Commons isn't just "a free file repository"; by its nature it involves some coordination across projects because of the way other projects rely on it for some or all of their media. "High-level content separation is a good thing." Sure, but why can't a "Meta" namespace on Commons do that job? Or even something more radical, like a "Meta" namespace which exists simultaneously on all projects through some sort of transclusion or mirroring? Anyway, I'm not really expecting anything to happen here, I just want to prompt some people to think about these things. And possibly improve the About page. Rd232 19:54, 8 February 2012 (UTC)
Commons is a big project in its own right, so if we merged Meta into it the likelihood is that commonistas would have undue influence in future Meta debates. Where I think we went wrong was in hiving off Strategy, Outreach and ten as standalone wikis rather than projects or namespaces within Meta. Ten is now closed but unless we get Global watchlists, Strategy and Outreach should be merged back here where they naturally belong. When you subdivide clouds you eventually find there is a flipside to the wisdom of crowds. WereSpielChequers (talk) 08:48, 18 February 2012 (UTC)
I support this. I participated in the Strategy wiki until the plan was written, but them I left it since I find separate watchlists and especially liquid threads inconvenient. I woud definitely resume the participation if it gets back here. I hope Philippe is reading this.--Ymblanter (talk) 09:40, 18 February 2012 (UTC)
re Strategy wiki location: (serio-humorously) Strategic planning/design should always be carried out on a different planet where discussion takes the form of "farts and tap dancing."[1] -- Proofreader77 (talk) 11:05, 18 February 2012 (UTC)

Please see Proposals for closing projects/Closure of meta-wiki, which pursues this idea further. Rd232 (talk) 16:10, 19 February 2012 (UTC)

Picture of Peter Cooper from FDR

  The Picture depicting Peter Cooper from the FDR drive is actually Stuyvasnt town.

  The apartment buildings' in 'Stuy Town' have twelve floors. Peter Cooper has fourteen floors.

   Just to let you know.. Rod Beaton — The preceding unsigned comment was added by RodBeaton (talk)

Not sure what you are trying to ask Rod. Images can be found at Commons: and the encyclopaedia at wikipedia: billinghurst sDrewth 09:51, 21 February 2012 (UTC)

Please Don't Remove My Picture From WikiMedia!

Please don't remove my picture from WikiMedia because it's from my own personal scrap book and I want it to be a part of my infomation on Wikipedia.

Answered on user's page. billinghurst sDrewth 09:47, 21 February 2012 (UTC)

Problem in Vepsian Wikipedia

What's happened with article-count? It shows that this Wiki contains 54 (!) articles. It's wrong: Vepsian Wikipedia should/must has 528+54=582. Does anyone know how to fix it? Best regards, --U.Steele (talk) 10:39, 22 February 2012 (UTC)

I requested to update to wrong statistics some weeks ago, but instead they were set to 0: bugzilla:34184#c2 Merlissimo (talk) 12:53, 22 February 2012 (UTC)


black out

Thank You for bringing my direct attention to a situation that is important. I would have other wise not felt it's importance! Again Thank You!!!!!

Blackflag

See Talk:Wikimedia News.

Can we make a news.Can we make a thing which is non-existent. This news is the relation between u and me. News: new+s: new+ sense. A news: a new sense. This is the news. A black flag to All who oppose a news. Gd Mn — The preceding unsigned comment was added by Ansha (talk) 07:19, 18 January 2012 (UTC)


Pledges for SOPA Strike

I pledged a dollar if Wikipedia was blacked out in protest of SOPA and E-Parasite. I just donated $20 because of how pleased I am with Wikipedia's efforts in raising this issue's visibility.