User talk:Lightmouse: Difference between revisions

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Content deleted Content added
Line 171: Line 171:
::::*I don't see how delinking articles at a slower pace represents any less of a [[fait accompli]] strategy, but ok. cheers, –<font face="Verdana">[[User:Xeno|<font color="black">'''xeno'''</font>]] ([[User talk:Xeno|<font color="black">talk</font>]])</font> 19:46, 10 February 2009 (UTC)
::::*I don't see how delinking articles at a slower pace represents any less of a [[fait accompli]] strategy, but ok. cheers, –<font face="Verdana">[[User:Xeno|<font color="black">'''xeno'''</font>]] ([[User talk:Xeno|<font color="black">talk</font>]])</font> 19:46, 10 February 2009 (UTC)
::::Perhaps a request for clarification should be made... –<font face="Verdana">[[User:Xeno|<font color="black">'''xeno'''</font>]] ([[User talk:Xeno|<font color="black">talk</font>]])</font> 17:48, 10 February 2009 (UTC)
::::Perhaps a request for clarification should be made... –<font face="Verdana">[[User:Xeno|<font color="black">'''xeno'''</font>]] ([[User talk:Xeno|<font color="black">talk</font>]])</font> 17:48, 10 February 2009 (UTC)
:::::What about edits to articles in which there are no linked dates, and the edits are only done to make the date format consistent? [[User:Dabomb87|Dabomb87]] ([[User talk:Dabomb87|talk]]) 23:06, 10 February 2009 (UTC)


== Google Street View bot? ==
== Google Street View bot? ==

Revision as of 23:06, 10 February 2009

Miles at sea

Hi. I would not be as quick as you to assume that "miles" in ship articles, when based on naval sources, are statute miles (1.61 km) by default, rather than nautical (1.85 km). E.g. [1], [2], [3], [4].
—WWoods (talk) 19:36, 6 February 2009 (UTC)[reply]

One of the problems with the old system is that ambiguity is concealed. For some readers, the word 'mile' means statute, for others it means 'nautical', for others is means 'Scottish'. The author cannot blame the reader for the original ambiguity. The benefit of metric units is that it removes the concealed ambiguity. The benefit of the conversion template is that it is easy to change. I would be delighted if somebody improved the articles by eliminating the original ambiguity. Perhaps this could be discussed in one of the project talk pages, or at mosnum. Lightmouse (talk) 10:11, 7 February 2009 (UTC)[reply]
The trouble is, the ambiguity is real. I think those are nautical miles, but I don't know. Therefore it seems better to me not to tacitly assert that they're statute miles by converting them as such. If you still want to convert them, why not assume they're nautical miles and use that conversion?
—WWoods (talk) 18:07, 7 February 2009 (UTC)[reply]

Question

Hi Lightmouse, hope you are doing well. About a month ago, I created this proposal as a way to settle the dispute about when to link dates. After the Arbcom case picked up steam, I sort of left it by the wayside. However, recently, Greg L seized on the idea with much gusto, and others have warmed to it as well. Greg asked if it was possible for you to configure your bot (or script) to those guidelines, with a reasonably low false positive rate. I completely understand if it is not possible, as some of the proposals are very detailed, but it would be interesting it have your feedback all the same. Cheers, Dabomb87 (talk) 05:02, 7 February 2009 (UTC)[reply]

Part of it is easy:
Part of it is difficult, if not impossible:
  • Holidays: It is difficult for a bot to know what is a holiday. You gave the example of April Fools' Day as a holiday, but I would not have guessed that it was. The same applies to your other two examples. I don't want to get into a dispute about which days are holidays in which regions and religions. This could be solved by having a list of articles for the bot to avoid.
  • 'Global' or 'historical' context. It is difficult for a bot to decide. This could be solved by having a list of articles for the bot to avoid.
  • Birth and death dates. It is difficult for a bot to determine that a date is a birth or death date. This could be solved by having a list of articles for the bot to avoid.
I think your idea has a future. I hope that helps. Lightmouse (talk) 10:29, 7 February 2009 (UTC)[reply]

There is absolutely no consensus that dates of birth and death should be linked. This is a zany idea put about by those who want a foot in both camps. Since most visitors and, indeed, Wikipedians, do not consult MOSNUM et al, but follow what they see in existing articles, linking the opening two dates in our many biographical articles will result in many many editors' believing that all dates should be autoformatted. In addition, extended blue-wash right at the opening of an article typically runs up against other, high-value links; sometimes it places them directly adjacent to these low-value date-links. It is a bad idea indeed, and I would be one of many people to object to it. Tony (talk) 13:41, 7 February 2009 (UTC)[reply]

I never proposed that birth and death dates be linked. If you see, the proposal merely says "under discussion". Dabomb87 (talk) 14:14, 7 February 2009 (UTC)[reply]
Tony, can you point me to a study that shows that date links "devalue" other "high value" links? I see this assertion made repeatedly (here, at MOSNUM and at the ArbCom case) but I've never seen anything definitive and unbiased to back it up. —Locke Coletc 12:07, 8 February 2009 (UTC)[reply]
Any grant body that funded a study for that purpose would be laughing stock, since it doesn't take Einstein to realise such an obvious fact. But now you raise it, I suspect that the field of perception (within psychology) is replete with data that show an analogous dilution effect over a number of modes—one of them colour. I might follow this up with User:Holcombea, a notable scientist in this field, although it hardly seems necessary under the circumstances. Tony (talk) 12:39, 8 February 2009 (UTC)[reply]
If I understand the issue correctly, it is a matter of eyes trying to detect a signal within noise. That is why animals make themselves look the same as the background. If you raise the noise, the signal detection rate goes down. It is not a linear effect and I believe there can be reversals when signals are extremely low (e.g. detecting bombs in luggage, rare cancers in medical images) but that doesn't apply here. There are plenty of resources on signal to noise theory available for anyone that doubts that noise causes problems in signal detection. Lightmouse (talk) 12:52, 8 February 2009 (UTC)[reply]
Yet but if there's no quantifiable impact on our readers it seems we're much ado about nothing. Have readers complained about the date links impacting their ability to recognize non-date links? Have they complained about the impact of "trivia" articles being linked next to other highly relevant links? I guess my question is two fold: where does this idea come from, and how did it spring to mind? Surely someone complained somewhere to set this off? —Locke Coletc 15:26, 8 February 2009 (UTC)[reply]
  • But how are the "readers" to complain? The millions of "readers" each day of Wikipedia are almost entirely unregistered and do not have a clue how to "complain" to Wikipedia if they wanted to do so. Even for a "member of the Wikipedian community", it is difficult to know where to "complain" about some things. How to complain? Submit a "policy" suggestion somewhere? Post on AN/I? Complain on various talk pages and have an RFC? Go to ArbCom? From my experience reviewing hundreds of GANs, the vast number of Wikipedian editors do not prefer date linking to years. However, there is no data regarding the views of Wikipedia editors in general because there is no means of obtaining it. In any case, this does not apply to Wikipedia's vast, anonymous, worldwide readership. —Mattisse (Talk) 15:57, 8 February 2009 (UTC)[reply]
  • Exactly. Our readers do not "complain" about redundancy, poor grammar and organisational problems in our writing; nor copyright infringements in our images and sound bites. This is irrelevant to the making of a superb information source. Tony (talk) 16:00, 8 February 2009 (UTC)[reply]
The original question was whether eliminating low value links has an effect on high value links. The response was that as you increase the noise, the signal to noise ratio falls. Human performance is affected by signal to noise ratio. I assume that we are in agreement about that. If we aren't in agreement, then it is such a big challenge to the science that it belongs on another page, not my talk page.
We now have an entirely new thread about user complaints. That is nothing to do with the science of signal to noise ratio. Why are we talking about this on my talk page? Lightmouse (talk) 16:35, 8 February 2009 (UTC)[reply]
Because Tony states these things as fact on your talk page, then runs with them. At least I now understand that he has no direct complaints from our readership to base his claims on, I wasn't aware of that. We're in this situation because of his assumptions. —Locke Coletc 09:01, 10 February 2009 (UTC)[reply]
OK, I hope that is the end of this thread on my talk page. Lightmouse (talk) 09:56, 10 February 2009 (UTC)[reply]

Dabomb87, 'Category:Births by year' and 'Category:Deaths by year' are relevant to the debate about birth and death years. I can't see any mention of these categories. I didn't want to mess up your page by adding something myself. Could you mention those please? Lightmouse (talk) 14:41, 7 February 2009 (UTC)[reply]


  • Linking dates of birth? I missed that *under discussion* biz in Dabomb87’s Summary. The linking of dates of birth was the primary reason we are all bogged down in this holy war. It’s time to break out of unnecessary logjams.

    Dabomb87’s summary is supposed to be a summary of the RfC consensus and I see no basis for thinking the RfC results says that the linking birth dates is allowable. If one is reading up on Angela Lansbury, who is an actress born in 16 October 1925, and you click on that year (or God forbid, the day), there is nothing in the 1925 article that is germane and topical to the subject of “Angela Lansbury” except for her birth date; the reader already knew that before clicking the link. Again, links should be topical and germane to the subject matter and shouldn’t be used as an invitation for what editors think might be a fun treasure hunt on matters entirely unrelated to the subject. Greg L (talk) 16:58, 7 February 2009 (UTC)[reply]

    • I put that little note there after a discussion with Locke Cole on the talk page. Clearly, I was wrong. Dabomb87 (talk) 18:09, 7 February 2009 (UTC)[reply]
  • That explains a lot. No harm. Given that date linking is such a gray area, your very comprehensive, detailed proposed guideline is just the sort of specificity that might resolve this dispute. I note above that Lightmouse is saying that there are several classes of dates where date linking would be appropriate and it would be quite difficult to avoid those with a bot. Does anyone have an idea how many there would be of such appropriately linked dates as compared to all the ones that need to be de‑linked? If it is wildly lopsided, then it makes far more sense for a bot to go do its thing and manual re-link. Greg L (talk) 19:22, 7 February 2009 (UTC)[reply]

Greg, my comments should not be considered as endorsement of date links. I am merely suggesting boundary rules for an unsupervised bot. By definition, it has to be much more cautious than a human. Rather like archaeologists getting a local firm with a motorised digger to remove 80% of the top soil, then students using trowels for 80% of whats left, then archaelogy specialists using toothbrushes. In the end, only the important stuff will remain. Lightmouse (talk) 19:57, 7 February 2009 (UTC)[reply]

If you want to estimate the number of articles in need of delinking, one method might be to look at articles that link to todays date and see for yourself how many look like bot fodder. Lightmouse (talk) 20:17, 7 February 2009 (UTC)[reply]
  • Well that was an interesting experiment. I did as you suggested and looked at the first ten links and the last ten links (a total of 20). In every single case where the date was used in body text, it was just a plain old link to the date for the sake of autoformatting and/or linking to dates for the sake of linking to dates (where the link is not topical or germane to the subject matter). There were about five cases in the last set of ten that were all like these two: Luke McLean, and Marian Pop. They have some sidebars with “this was retrieved on” or “this was fetched on” templates. I assume it would be a no-brainer to avoid those. I am concluding, from these 20 semi-randomly chosen articles, that if you can avoid the sidebars, then the number of false-positives would be a very small portion (comparatively speaking) to all the links that properly need to be de-linked. Do you concur? Greg L (talk) 03:24, 8 February 2009 (UTC)[reply]

I don't know what you mean by 'sidebar'. I had forgotten that the wikiterm is “info boxes”. In print, all those sort of things are called sidebars. Greg L (talk) 16:25, 8 February 2009 (UTC)[reply]

  • I looked at your example of Luke McLean. It had the term 'Retrieved on' followed by the unlinked text '8 February 2009'. So it is not a special case. Perhaps you are talking about the date '2008-11-08' prior to it. That is linked but as a human editor, I would delink it. That doesn't seem particularly special to me either. In in the infobox, it contained '29 June 1987' (not linked) and '8 February 2009' (not linked). I can't see anything special about those.
  • I looked at your example of Marian Pop. It didn't contain the term 'Retrieved on' or 'Fetched on'. In in the infobox, it contained 'January 15, 1990' (not linked) and 'February 7, 2009' (linked). I can't see anything special about those.

In summary, I can't see any dates in those two articles that require links. I would be interested to hear the views of the citation people, they have been working on date linking policy for some time and were going to update citation templates Real soon now. Lightmouse (talk) 11:18, 8 February 2009 (UTC)[reply]

  • Just to clear something up: I think dabomb's "summary" was—in its frame—an excellent piece of work. It's the kind of thing I might have attempted myself (perhaps not as well). I held off assessing the summary in my own mind until I'd had a look at the long-winded, voluminous RfCs at issue. It was only when I did that I realised that the data were contaminated in the first place, in some cases fatally. This is why my analyses targeted an earlier "link in the chain". Tony (talk) 11:57, 8 February 2009 (UTC)[reply]
  • It seems we are homing in on a workable, specific solution to propose to ArbCom for the arbitrators to consider. My question of you, Lightmouse, is this: If you were to take the first ten and last ten articles that link to today’s date and apply Lightbot to them in a way that is as compliant as you can reasonably make it with Dabomb87’s proposed guideline, how many false-positives would there be? I note that some of yesterday’s articles contained multiple date fragments (both years and days) per article. So even if the false-positive count is one or two, the number of properly de-linked dates would likely be something on the order of 24. I’m not seeing a problem at all here if that would prove to be the true ratio across a larger population; it would be far, far more laborious to manual de-link dates than it would be to restore the wildly smaller number of false positives. Greg L (talk) 16:25, 8 February 2009 (UTC)[reply]

The first ten articles that link to todays date are:

  • April - would not be parsed by bot: all 12 'month' articles would be avoided
  • August - would not be parsed by bot: all 12 'month' articles would be avoided
  • April 6 - would not be parsed by bot: all 366 'month+day_number' articles would be avoided
  • April 12 - would not be parsed by bot: all 366 'month+day_number' articles would be avoided
  • April 15 - would not be parsed by bot: all 366 'month+day_number' articles would be avoided
  • April 30 - would not be parsed by bot: all 366 'month+day_number' articles would be avoided
  • August 22 - would not be parsed by bot: all 366 'month+day_number' articles would be avoided
  • August 27 - would not be parsed by bot: all 366 'month+day_number' articles would be avoided
  • August 6 - would not be parsed by bot: all 366 'month+day_number' articles would be avoided
  • August 9 - would not be parsed by bot: all 366 'month+day_number' articles would be avoided

The last ten articles that link to todays date are:

  • Jean-Achille Benouville - All linked dates would be delinked. I count 2 linked dates and several unlinked dates.
  • Nicholas Byron Cavadias - All linked dates would be delinked. I count 1 linked date and several unlinked dates.
  • Kazutsugi Nami - All linked dates would be delinked. I count 9 linked dates and several unlinked dates.
  • List of Cabinets of Iceland - All linked dates would be delinked. I count 93 linked dates and 1 unlinked date.
  • Murray Takes It To The Next Level - All linked dates would be delinked. I count 2 linked dates and 3 unlinked dates.
  • List of The Veronicas tours - All linked dates would be delinked. I count 89 linked dates and several unlinked dates.
  • Institute for Health Freedom - All linked dates would be delinked. I count 10 linked dates and no unlinked dates.
  • 2009 in British music - would not be parsed by bot: all '<year> in <subject>' articles would be avoided
  • Il Giorno (newspaper) - All linked dates would be delinked. I count 2 linked dates and several unlinked dates.
  • The Fat Tail: The Power of Political Knowledge for Strategic Investing - All linked dates would be delinked. I count 3 linked dates and several unlinked dates.

I hope that helps. Your point about 'sidebar' and 'infobox' being synonyms noted. Lightmouse (talk) 18:14, 8 February 2009 (UTC)[reply]


'Holidays'

When I say "holiday", I mean an annual event that occurs on the same day every year. Dabomb87 (talk) 14:16, 7 February 2009 (UTC)[reply]

The requirement to avoid 'annual events' is a larger scope for exclusion than holidays. But perhaps this is such a simple issue, it isn't a problem. When we talk about exclusions from bot scope, we have two aspects:

  • links *within the article*
    • A bot will remove links within articles about annual events. It has no way of knowing that Burning Man is an annual event. It will delink dates in that article, just as it would in Burning Wheel. If such articles are to be excluded, then it needs to be given a list. It can also work with simple rules (e.g. any article with '<space>Day' in the title - note upper case 'D').
  • links *to an article*
    • A bot is unlikely to remove links to annual events. This is not a deliberate action, it is just how it works i.e. the software has not been created to find square brackets around text 'Burning<space>man' or 'April<space>Fool's<space>Day'.

I hope that helps. Lightmouse (talk) 14:41, 7 February 2009 (UTC)[reply]

      • Here, I am only talking about links to, say, January 1 in New Years Day or December 25 in Christmas. I wasn't talking about removing links to holidays themselves. Dabomb87 (talk) 18:10, 7 February 2009 (UTC)[reply]
      • I suppose I could provide a list. Dabomb87 (talk) 18:11, 7 February 2009 (UTC)[reply]

An alternative to providing a list of articles to avoid is for Lightbot and/or Lightmouse's script to honor the {{Bots}} template. The documentation for the template explains how bot code can be modified to honor the template. --Gerry Ashton (talk) 18:31, 7 February 2009 (UTC)[reply]

I don't know how the script could do it. But Lightbot could do it with that template or any other. Lightmouse (talk) 20:05, 7 February 2009 (UTC)[reply]
That would just be licensing anyone who wants to ignore the MoS and do things their own way to slap a ((bots)) template on all the articles they feel they 'own'. A related but much more selective approach is the suggestion I've made in the RfAr workshop: a template that could be used as a protective wrapper on any individual linked date, so that the unlinking bot would bypass it. The template syntax would require a reason to be provided, so other editors could discuss whether the protection was desirable, and future editors could understand the reason for protection without having to comb through reams of old discussions. Colonies Chris (talk) 13:34, 8 February 2009 (UTC)[reply]
Further, I believe that Chris probably has in mind not any old reason pasted in from some rotated list of generic "reasons", but one that specifically relates to the actual context of the article. Is that right, Chris? Tony (talk) 13:58, 8 February 2009 (UTC)[reply]
That's right. The template would be to protect specific special cases that can't be readily categorised in a way that the bot could be programmed to avoid. (And to avoid article 'ownership' issues, claims such as "local consensus to do things differently here" would need to be supplemented with evidence that at least two active editors in that field support the supposed consensus). Colonies Chris (talk) 16:57, 8 February 2009 (UTC)[reply]
I want to be even-handed about this. Proposals to keep date links in the hope that some day date autoformatting might be improved carry no weight with me, because there is no clear plan on how to do it, and no commitment to implement the plan. Similarly, a proposal to wrap individual dates carries no weight with me until there is a clear enough plan that the template can be written, and a commitment that the bots approval group will not approve any date-delinking bot that does not honor the new template. --Gerry Ashton (talk) 17:17, 8 February 2009 (UTC)[reply]
What's "active editors in that field" supposed to mean and who decides whether they exist? Of course, you entirely miss the point about article-consensus prevailing over the mere recommendations of the Manual of Style, and your proposal would only lead to more edit warring. Tennis expert (talk) 23:28, 8 February 2009 (UTC)[reply]
  • I think this is unworkable: two "active" editors "in the field"? Never would it have been so easy to generate supposed consensus. That's Tennis expert and one other person he finds, overruling all of his colleagues at the WikiProject. Naaaah. Tony (talk) 23:53, 8 February 2009 (UTC)[reply]
Ah, now WikiProjects are relevant to you. Thanks for finally recognizing that the Manual of Style is merely a set of recommendations that may be ignored by local consensus. We're making progress. Tennis expert (talk) 00:41, 9 February 2009 (UTC)[reply]
  • Incorrect. Tony said Tennis expert and AN Other do not constitute 'local consensus'. TE do not even have the support of his fellows at WP:Tennis even when he is editing "normally", as there are ample comments which testify to this on his own talk page. Ohconfucius (talk) 01:46, 9 February 2009 (UTC)[reply]
The requirement for two active editors isn't intended to be decisive, it's a minimum to have such a claim even taken seriously. I make this proposal in the full knowledge that Tennis expert can't find even one other editor to support his spurious claims of 'local consensus'. Could that be why he's opposed to it? Colonies Chris (talk) 08:26, 9 February 2009 (UTC).[reply]

Hope

I have no longer been following the complicated delinking arbcom case, but I hope you are doing well and not feeling put down by it all. My interactions with you have always been extremely pleasant, and I have enjoyed you script immensely (although now I am afraid to use it!) I'm hoping arbcom will see the light and understand that the problem is not you or your script. The problem is that there is no good rationale for linking to random years. Regards, —Mattisse (Talk) 15:28, 7 February 2009 (UTC)[reply]

Thank you. One kind comment like that is antidote against a thousand hostile comments. I really appreciate it. Lightmouse (talk) 15:36, 7 February 2009 (UTC)[reply]

Issue with commas in unit conversion

I made this edit to fix an error in unit conversion on Oroville Dam. The commas in the original value were producing 'Expression error: Unrecognised punctuation character ","' in the converted value. Removing the commas fixed it without affecting how the original value was displayed. Either your script will need to strip commas in the original values or the code which performs the actual unit conversion will need to be updated to handle them. —Preceding unsigned comment added by DonovanHawkins (talkcontribs) 18:45, 7 February 2009 (UTC)[reply]

Thank you. I will investigate and fix the problem. Thanks for the feedback. Lightmouse (talk) 19:44, 7 February 2009 (UTC)[reply]

The Palace Hotel On 1st St and Cook Ave. in New Mexico

Hi,Im new to this so please bear with me. I've seen your name on the discussion list and was wondering if you care to assist me in any way.Please understand that I take no offense if this is not possible.

I am looking for information on the Palace Hotel located in the Historical District in Raton. It is listed as number 23 and is located on the corner of 1st street and Cook ave. Between 1975-77. I was a teenager and live and worked there. I am now researching the building's history and appreciate anything you can provide.

Thank you in advance. —Preceding unsigned comment added by Susanjxp (talkcontribs) 23:36, 7 February 2009 (UTC)[reply]

I am sorry I can't help you. Lightmouse (talk) 10:50, 8 February 2009 (UTC)[reply]

The Gram(me)y awards

Thanks for the tip. I'm sending you this direct because the archive is closed, and I have no urgent need to start a new topic on the overloaded current page as opposed waiting for someone else to raise the question anew.

I have a slight general bias towards British spelling and usage since I grew up in London, moved to Rhode Island when I was six, moved back when I was eight, and moved back to the States for good when I was eleven, at which point I resisted re-Americanization. However there also are many U.S. usages which I prefer on the basis of logic, clarity, ease or style (e.g. NATO over Nato, acknowledgement over acknowledgment). In the case of meter/metre, the need to avoid confusion with meters and micrometers argues for ~metre, and in the MOSNUM discussion of this, someone said that for that reason, ~metre is now the preferred scientific usage. In the case of ~gram(me), I'd think that people (and thus readers) in Anglo-French bilingual countries, of which the most prominent is Canada, would prefer to just use ~gramme and ~metre in English as it's already used in French (e.g. on packages). On the theoretical level, some argue that meter, liter and gram are closer to the original Greek (not written in our alphabet), but after all the French, who did invent the metric system, seem just as deserving of credit. —— Shakescene (talk) 05:34, 9 February 2009 (UTC)[reply]

Date format

In November you contacted me regarding the use of your tool to change date formats to dmy or mdy etc. Just recently there seems to be a change in the result so that a comma appears in the dmy format, giving 9 February, 2009 rather than the correct format 9 February 2009. Is this a temporary glitch or has there been some significant change of which I'm not aware? Daemonic Kangaroo (talk) 22:39, 9 February 2009 (UTC)[reply]

The code is updated with from time to time. It is possible that one of the updates has caused that. In response to your feedback, I have made a change that should fix the issue. Please clear your cache and try again. If the problem still exists, please give me an example page and I will investigate further.
P.S. A tip is to add User:Lightmouse/monobook.js/script.js to your watchlist. Each time you see it updated, clear your cache. This will ensure that your computer is working with the latest version.
Thanks for letting me know. Lightmouse (talk) 23:25, 9 February 2009 (UTC)[reply]

That all seems OK now. Cheers. Daemonic Kangaroo (talk) 08:54, 10 February 2009 (UTC)[reply]

  • I find it rather irresponsible, Lightmouse, that you neglected to point out that there is currently an injunction against mass unlinking dates in this manner. Please disable the unlinking function of your script while the injunction is active. –xeno (talk) 13:41, 10 February 2009 (UTC)[reply]
  • There is no injunction against individual editors using Lightmouse's tool via User:Lightmouse/monobook.js/script.js on individual articles. I asked about this at the delinking Arbcom case. The individual use of user scripts is permitted. This is the way Lightmouse's script is mostly used. It seems like Daemonic Kangaroo was using it this way. —Mattisse (Talk) 16:28, 10 February 2009 (UTC)[reply]
  • There is an injunction against a mass program and the above user seems to be using it on all articles he is working on, "en-masse". Can you point me to the clarification? –xeno (talk) 16:30, 10 February 2009 (UTC)[reply]
  • The injunction specifically mentions "scripts", and as the proposer of the injunction I explicitly had Lightmouses script in mind. —Locke Coletc 17:10, 10 February 2009 (UTC)[reply]
  • But I believe I was told that the injunction did not apply to individual editors working on individual articles, not "en masse". Not having Lightmouse's script is a huge burden on us. I believe Karanacs also brought up the importance of Lightmouse's script for this use in the delinking Arbcom. Disabling it would be a huge burden on copy editors such as we are. —Mattisse (Talk) 17:39, 10 February 2009 (UTC)[reply]
  • Yes, I've been using it as I work on articles. I'm trying to bring several articles close to FAC status, and they must meet the MOS, thus no date links. Karanacs (talk) 18:14, 10 February 2009 (UTC)[reply]
  • Why would featured articles need to meet a MOS guideline which is presently disputed (and under arbitration, at that)? —Locke Coletc 18:23, 10 February 2009 (UTC)[reply]
  • I don't see how delinking articles at a slower pace represents any less of a fait accompli strategy, but ok. cheers, –xeno (talk) 19:46, 10 February 2009 (UTC)[reply]
Perhaps a request for clarification should be made... –xeno (talk) 17:48, 10 February 2009 (UTC)[reply]
What about edits to articles in which there are no linked dates, and the edits are only done to make the date format consistent? Dabomb87 (talk) 23:06, 10 February 2009 (UTC)[reply]

Google Street View bot?

Do you think it would be possible to design a bot that if a landmark has the address listed in the infobox, and the location is covered by Google Street View, that an external link to that location on Street View would automatically be placed on the page? I have been trying to place Google Street View links on the pages of many landmarks, but there are perhaps millions around the world, and I can never get to them all. I don't know of any one else who is actively doing this. Sebwite (talk) 01:04, 10 February 2009 (UTC)[reply]

I don't know how to do it. But you could ask at Wikipedia:Bot requests. Regards Lightmouse (talk) 08:46, 10 February 2009 (UTC)[reply]