User talk:Geo Swan/archive/2012-02

This user is one of the 400 most active English Wikipedians of all time.

If you are considering initiating an xfd on material I started

2004, 2005, 2006-01--2006-06, 2006-07--2006-10, 2006-10--2005-12, 2007-01--2007-06, 2007-07--2007-09, 2007-10--2007-12, 2008-01--2008-06, 2008-07--2008-09, 2008-10--2008-12, 2009-01--2009-03, 2009-04--2009-06, 2009-07--2009-09, 2009-10--2009-12, 2010-01, 2010-02, 2010-03, 2010-04, 2010-05, 2010-06, 2010-07, 2010-08, 2010-09, 2010-10, 2010-11, 2010-12, 2011-01, 2011-02, 2011-03, 2011-04, 2011-05, 2011-06, 2011-07, 2011-08, 2011-09, 2011-10, 2011-11, 2011-12, 2012-01, 2012-02, 2012-03, 2012-04, 2012-05, 2012-06, 2012-07, 2012-08, 2012-09, 2012-10, 2012-11, 2012-12, 2013-01, 2013-02, 2013-03, 2013-04, 2013-05, 2013-06, 2013-07, 2013-08, 2013-09, 2013-10, 2013-11, 2013-12, 2014-01, 2014-02, 2014-03, 2014-04, 2014-05, 2014-06, 2014-07, 2014-08, 2014-09, 2014-10, 2014-11, 2014-12, 2015-01, 2015-02, 2015-03, 2015-04, 2015-05, 2015-06, 2015-07, 2015-08, 2015-09, 2015-10, 2015-11, 2015-12, 2016-01, 2016-02, 2016-03, 2016-04, 2016-05, 2016-06, 2016-07, 2016-08, 2016-09, 2016-10, 2016-11, 2016-12, 2017-01, 2017-02, 2017-03, 2017-04, 2017-05, 2017-06, 2017-07, 2017-08, 2017-09, 2017-10, 2017-11, 2017-12, 2018-01, 2018-02, 2018-03, 2018-04, 2018-05, 2018-06, 2018-07, 2018-08, 2018-09, 2018-10, 2018-11, 2018-12, 2019-01, 2019-02, 2019-03, 2019-04, 2019-05, 2019-06, 2019-07, 2019-08, 2019-09, 2019-10, 2019-11, 2019-12, 2020-01, 2020-02, 2020-03, 2020-04, 2020-05, 2020-06, 2020-07, 2020-08, 2020-09, 2020-10, 2020-11, User Talk:Geo Swan/archive/list

Davenport Road

Davenport Road is one of the very oldest roads in Ontario, some say it is part of the oldest road in Ontario, since it dates back to a First Nations' trail that predated contact with Europeans.

Davenport Road runs parallel to a notable scarp that was once the shore of glacial Lake Iroquois.

There are hundreds of roadways in Toronto. For many of those roadways the only notable thing about them is that they are used for transportation. I have no objection to not having individual articles about those roadways -- they probably wouldn't have any WP:RS anyhow. I have no objection to listing the arterial roads with no other notability in a list article.

Another contributor and I have had a disagreement over whether Davenport Road should be a separate article -- or a redirection to a list article. I have separate concerns over redirection to subsection headings within articles, which I will describe later.

But Davenport Road is not notable only for transportion. That other contributor asserted that redirection would not result in the loss of any content. However content is far from the only question here.

A famous jazz great siad that to really appreciate jazz one should listen to the space between the notes.

To really appreciate the potential power of the wikipedia one has ot understand the power of links in general and wikilinks in particular. One could take a paper encyclopedia, cut every page from its volume with a razor blade, scramble the order of all the pages -- and still argue that no content was deleted.

Information you can't find might as well not exist. A deeply interlinked wiki makes it much easier to find the content we want. So, for wikis like the wikipedia, content is not the only important thing. The content and the organization that allows us to find the information we want are both important. In my opinion, after a lot of thought, I think the organization is actually more important. In my opiniona wikipedia where all the content had been rewritten, to feature article quality, but where none of the links worked, would be less useful than a wikipedia, where all the links worked, but all the articles were stubs.

The article Davenport Road lies at a nexus -- a crossroads. It is historically notable and geographically notable, in addition to being useful for people interested in transportation in Toronto. I think the contributor who disagrees with me has forgotten readers whose interest in Davenport Road is not related to transportation.

The information about Davenport Road's connection to the retreat of the Laurentide Glaciation are poorly served by having the details hidden away in a list article. A limited amount of information about the glaciation connection may survive in a list article on transportation -- or it may not. It may trimmed down or totally excised, as "off-topic". Same with historical information. The solution is not to move the information from the list article on transportation to the glaciation article, or to an article on the history of Upper Canada. Instead all of those articles should have just enough content to provide context, and should then have a link to the article on Davenport, which should have all the rest of the details.

This is a general principle that should be applied when anyone suggests merging and redirecting the content of an article to a more general article, when their are multiple credible targets for that redirection. All such articles are at a crossroads. Geo Swan (talk) 07:40, 1 February 2012 (UTC)[reply]

There are certainly no rules against linking to subsections of articles. It is encouraged where it aids reader navigation. A separate article on Davenport Road is NOT going to describe the Lake Iroquois Glaciation, as the road has little to do with it and its completely inappropriate for the article to go off on a tangent about geological processes that led to the geography of the Toronto area, which itself is responsible for the behaviour of early natives and their trail-making practises. Its just one of many contour roads in Toronto that follow the path of least resistance as opposed to a rigid grid-plan; however, I fail to see the connection between having the content amongst other road articles for Toronto (where one can quickly access all the other roads whose history the reader may be interested in, such as Dupont Street) and the content being limited in any way. If and when this article does contain enough properly organized information, it can always be broken out into a separate article, but right now it's an excessively wordy stub and it makes sense to have a comprehensive article rather than a spider web of stubs, if the readers interests are truly at heart. - ʄɭoʏɗiaɲ ^τ _¢ 14:40, 1 February 2012 (UTC)[reply]

I am going to address your counterpoints, in order, giving them a number:

1	In the section below I offered some of my general objections wikilinking subsection headings within articles.
2	As to whether it "aids reader navigation" -- I sure don't see it that way. As I noted below, key features of navigating via wikilinks are not supported for wikilinks to subsection headings. These links are fragile, vulnerable to breaking. This do, es not "aid reader navigation". Some time ago I created an article on the phrase "There is a sucker born every minute". In 2007 it was nominated for deletion. I wasn't that familiar with the usual arguments offered by those who identify themselves as "mergists", prior to this discussion My efforts to offer counter-arguments helped crystalize my concerns. Those favoring merge were positive the phrase didn't deserve an article of its own, and should, instead, be redirected to the article on P. T. Barnum. Some mergists argued for redirection because "everyone knew" PT Barnum coined the phrase. Other mergists argued for redirection because the phrase was routinely attributed to PT Barnum. I was surprised by mergists who seemed unconcerned by references that questioned whether Barnum coined the phrase, or stated outright that Barnum did not coin the phrase. Some mergists wanted a section within the Barnum article that addressed whether Barnum did or didn't utter the statement. But since Barnum almost certainly didn't utter the phrase, that section would be at constant risk of excision, as off-topic. Material documenting the other more-likely candidates for having coined the phrase would be off-topic in the PT Barnum article. I spent a couple of hours researching this phrase. My conclusion was that there were three kinds of references to the phrase. Some references to the phrase didn't even mention Barnum. These references were written by authors that assumed every well-educated person was familiar enough with the phrase that they didn't have to explain what it meant of provide any context. Some authors who used the phrase baldly repeated that Barnum coined the phrase. The remainder were more cautious, and merely said that the phrase was often credited to Barnum. After reading dozens of these references I found the ones written by authors who baldly repeated the misconception Barnum coined the term were cliche-ridden, shallow, full of other lazy thinking. The references written by cautious authors, who stopped short of repeating the misconception, were better written, more thoughtful, more interesting and more useful. The situation of a redirect of Davenport Road to the list of roads and the redirect of the phrase to the PT Barnum article are similar. If the {{afd}} on the phrase had resulted in a merge to Barnum, it is very likely the material on the phrase would have been deleted. So, someone not familiar with the phrase, would look up the phrase on wikipedia, and end up at an article about a 19th century impressario. This would be the very opposite to "an aid to navigation".
3	you write "A separate article on Davenport Road is NOT going to describe the Lake Iroquois Glaciation, as the road has little to do with it..." I did not suggest that Davenport Road describe glacial Lake Iroquois in inappropriate detail. If you research the glacial lake you will find many sources refer to how Davenport Road follows the foot of the scarp left by the ancient shoreline. So, someone familiar with, or learning about, the lake, who knows nothing about the path of the roadway want enough detail in the article on the lake to know how the roadway is connected with the lake. The details of the path belong in Davenport Road. Similarly, Davenport Road should provide just enough context for readers who might be interested in the glaciation to know what they might find if the clicked on Laurentian glaciation. Brief context of what to find when one clicks a link is not inappropriate detail.
4	You write: "...a tangent about geological processes that led to the geography of the Toronto area, which itself is responsible for the behaviour of early natives and their trail-making practises..." I disagree that this is a tangent. Perhaps it is an aspect of the topic Davenport Road that may not interest you? But I want to respect our readers. I want to respect their intelligence. I want to respect that their interests may trigger them to follow a path of links, and reading article in an order that never would have occurred to me. I don't mean to be offensive, particularly since quite a few contributors share the view that we should be (unnecessarily) channeling our reader's paths through the vast tree of human knowledge, that certain routes are more legitimate than others. Our readers should get to choose their own path. This is enabled when articles are small, and focussed on a single topic. This is impeded when multiple related topics are shoehorned into huge omnibus article.
5	You write: "Its just one of many contour roads in Toronto that follow the path of least resistance as opposed to a rigid grid-plan" What do you mean "just"? There are a handful of roads that wiggle because they predate the layout of the grid. Kingston Road, Dundas Street, Weston Road being some other examples. I suggest when WP:RS explain why a road doesn't follow the grid this is sufficient to make the road notable enough for its own article.
6	You write: "...however, I fail to see the connection between having the content amongst other road articles for Toronto (where one can quickly access all the other roads whose history the reader may be interested in, such as Dupont Street..." Ideally the list article should have only a limited amount of information about each road, as, when some entries in the list become longer than the others they make finding the shorter entries more difficult. You asserted that accessing the information on the other roadways is easier when all the roadways have their information in the omnibus article -- but you didn't say why. However, I suggest, navigating within a large article, through scrolling, or through using a search feature, is more difficult than simply clicking on a link to the relevant other articles. You click on a link, find it is not interesting after all, you click back, and you are back where you started. However, in the approach you advocate, if you scroll or search within a large article for information on some other road, if you find it is not what you are interested in, you have to go to the effort of scrolling or searching for where you were originally. The changes I introduced already introduced links to Kington Road and Dundas Street. If Davenport Road and Dupont Street share elements in common then the article on Davenport Road should provide brief context, and link to the Dupont Street, and vice versa. This is preferable to your suggestion that the reader should scroll around in an omnibus article for information about Dupont.
7	You write: "...and the content being limited in any way. If and when this article does contain enough properly organized information, it can always be broken out into a separate article..." With regard to limiting content -- some of the information the wikipedia should contain about Davenport Road is offtopic for an article listing east-west roads. I have pointed this out before, and I don't understand why you haven't addressed this point. With regard to "enough* properly organized information"* -- you write this as if there was some valid reason to object to smaller articles. What do you consider "enough"? One big advantage of small, focussed articles that I think you keep overlooking is that a watchlist are much more useful when the articles we place on them are small and focussed. When Davenport Road is a separate article, I can put it on my watchlist, and be informed when someone adds, subtracts, or changes the information the wikipedia has on Davenport Road. If I am not interested in Toronto's other roads I don't put them on my watchlist. But, with your approach, it Davenport Roard is merged with the big list article, I have to put the list article on my watchlist, generating a massive number of watchlist advisories to changes to all those other roads I am not interested in. As per our policies it is topics that are notable. A topic is notable without regard to someone considers the currest state of an article too brief. I think you already agreed that Davenport Road's notability was already established.
8	You write: "...but right now it's an excessively wordy stub..." Excessive wordiness is not grounds for deletion. If this is a concern you are serious about would you consider being specific about what you consider "excessively wordy"? Maybe I will agree with you? Maybe more specific comments will suggest to me a different wording we will both agree is superior.
9	You write: "...and it makes sense to have a comprehensive article rather than a spider web of stubs, if the readers interests are truly at heart..." I have no objection to having a list article, that supplies brief context to wikilinks to the roadways notable enough for standalone articles, and supplies all the content for the less notable roads. But I fail to see why a list article precludes standalone articles on the more notable roads. What serves our readers' interests is to respect our readers' intelligence, and provide the most choices for them to navigate through the corpus of the wikipedia. A greater number of smaller, focussed articles will best utlize the organizational structure the WMF software provides, and is thus in our readers' best interest. Some contributors try to set themselves up as gatekeepers, act as is their judgment as to which paths through the corpus should be enabled and that some should be obfuscated.

Cheers Geo Swan (talk) 22:30, 1 February 2012 (UTC)[reply]

I guess I'll reply in order. The stuff below is better for the village pump, as until you convince the community that's not how we do things: links to subsections are encouraged to direct readers to the proper location. They're used quite extensively with disambiguation pages, directing users to the correct category, for example, when they go to Wish You Were Here (song) and get taken to the song section of the DAB page. Good luck convincing people that such practise is bad or has a negative impact, because this isn't Xanadu.

1: Err... there is no 1 :p

2: Wikilinks are not fragile. If the section header is changed, the link still goes to the article. Editors are encouraged, on target articles, to leave hidden notes beside section headings alerting other that the heading is the target of a link. However, I fail to see the point you are trying to make here. While your phrase could be attributed to several people, possibly not the person that it was being merged with, there was certainly a risk of content being disregarded. This isn't the case with the roads in Toronto, almost all of which were merged together into these lists because they were two sentence stubs. In this case, all the content applicable to Davenport is fine to go there, and then when the article gets too long (a point you've essentially gotten it to NOW), you fork it out, and leave a summary and hatnote on the list article. I've done a similar thing with highways in northern Ontario that are surrounded by bush and rock (see List of secondary highways in Kenora District for an example). The only content I'll delete is irrelevant superfluous details (ie a house on a road being burnt down, which has little impact on the history of the road, even though it was important in the context of an event that occurred throughout the city) and utter nonesense, since I've extensively researched what I edit.

3:Indeed. However, Davenport doesn't just follow the foot of the escarpment. East of Poplar Plains Road, it zigzags south and eventually becomes the north-south Church Street. It's one thing to say "Davenport Road follows the foot of the escarpment between Jane Street and east of Spadina Road. This escarpment formed the shoreline of the ancient Lake Iroquois and provided a path-of-least resistance for early native settlers, eventually becoming a permanent trail." - But going into unneccessary details makes the article read poorly.

4:Not at all. Things have a place in their appropriate article, and trying to just put in content because of a thin bit of relevance leads to an article that reads off-topic and doesn't stick to the point. I am certainly interested in the history of Toronto streets, and until two very hardcore "every topic with one sentence MUST have its own article" editors came in and stopped how I was reorganizing content in order to stick a bunch of pictures in and detail the TTC bus routes. However, I don't care for the insertion of events that have no connection to the road, aside from happening next to it. Example being Birchmount Road, which was created to describe how the residents of the neighbourhood adjacent to it fought to have a railway that crosses the road not run after midnight. Another example is the fire at Yonge and Davenport. That fire is not relevant to Davenport Road; its important in the context of the Mackenzie Rebellion, but that rebellion was centred on Yonge Street from Queen up to Sheppard, not Davenport Road.

5:That a road doesn't follow the grid system laid out by John Graves Simcoe in 1794 doesn't make it notable. Reliable sources do. However, neither WP:RS nor WP:GNG say that meeting the criteria alone is justification for a unique article. WP:DEADLINE, in my view, says to wait until you have something worthy of submitting before submitting. Again, a merged article precludes a separate article by keeping similar information grouped. No content is lost, just this romantic notion of a unique title.

6:"as, when some entries in the list become longer than the others they make finding the shorter entries more difficult."... that's why there is a table of contents at the top of the article and why the unique titles for those roads redirect to the subsection, and not the top of the list. An omnibus article is better because it links all the facets of a topic (roads in Toronto) together in one place. Generally, when a person is interested in the history of a road, they're interested in the history of one road in particular, but will browse other roads in their area. An omnibus also encourages comprehensive content creation, as editors who have an expertise on one road may have some notes for several roads, and because it keeps the information together rather than segregated. You need one teacher in a class of 30 students, but three teachers in three classes of ten. It is not preferable nor practical nor good writing practise to have each individual topic discuss the myriad of similar topics. If you look at the article I gave you as an example, Mount Pleasant Road, you'd see how to organize the content so that you can link to Dupont where appropriate, rather than trying to link two pieces of pavement together through some history that doesn't actually link them together. I don't see where scrolling comes into play. We have plently of long articles, and so does the internet. Your argument could be used to limit the content of an article for fear that a reader will lose their place. Again, the table of contents at the top more than rectifies the issue with finding the right subsection, not to mention that they are in a specific geographic order from south to north.

7:None of the content regarding Davenport Road is inappropriate for its entry amongst other east-west roads in Toronto. If it is, it's also inappropriate for Davenport Road. This is a straw man argument. I consider "enough" to be several paragraphs. It's hard to describe, as with many facets of technical editing... but when you read something you know when it merits separation. There is a valid reason to object to smaller articles: They make our encyclopedia look unreliable. For years, Wikipedia has had a reputation as being completely unreliable. This has been changing slowly because the attitude shifted from covering every topic conceivable to making quality articles. In addition, when a smaller stub is created over a redirect to a longer list entry, then it misleads readers. As I mentioned above, notability doesn't imply that a topic deserves its own article (take a look at WP:GNG), it just implies that its notable enough to be mentioned, period. The watchlist argument is rather moot; these articles are rarely edited, and the subsection being edited will appear in the edit summary.

8:No, but I'm not going to go in and completely rewrite what you've got there just yet, because we are debating. Afterwords, perhaps. Example: "In 1896 The Daily Mail and Empire published a letter from a reader responding to recent article on roads requiring repair in Toronto described Davenport as being in "simply disgraceful condition".[6] The reader described Davenport Road, and several other roads, as being "block paved", and complained "this kind of pavement is anything but durable" -- due either to Toronto's climate, or poor construction."

Myriad of grammatical and flow errors aside, try "By 1896, Davenport Road was block paved, raising ire from local residents. One local described the road as being in "simply disgraceful condition", likely a result of poor construction or the actions of Toronto's cold climate.[6]"

9:All contributors are gatekeepers. We're writing an encyclopedia and not a compendium of every known trivial fact. Readers should be directed to the single article that will provide the best understanding of a topic. This is irrelevant as to that information being in its own article or as part of a larger omnibus. As I mentioned above, my reasoning for not creating unique articles is WP:DEADLINE and quality versus quantity. - ʄɭoʏɗiaɲ ^τ _¢ 15:14, 3 February 2012 (UTC)[reply]

Redirection to subsection headings -- a bad idea for article space

I realize, as my correspondent wrote above, "There are certainly no rules against linking to subsections of articles." Unfortunately this technique is not deprecated.

Nevertheless, in my opinion, it should be deprecated. Wikilinks, when properly used, are an incredibly powerful feature.

Unlike the uni-directional links used on regular world-wide web pages, the wikilinks enabled by the wikimedia software used by wikis like wikipedia are bidirectional. This is a powerful feature.
A perenial problem on the world wide web is that links break, all the time. Links breaking on the world-wide web doesn't necessarily mean the page was deleted. Trivial changes to the location of the page, including very minor changes to spelling or punctuation, break the www style links. However, on the wikipedia, moving a page creates a redirect. Readers can count on being taken to the page they want, even if the article's name is modified.
Web page creators on the world wide web have no way of knowing how many pages link to the pages they are responsible for.

However, these features are not supported for wikilinks to subsection headings within a wiki article. A wiki contributor, who is considering correcting a minor spelling, grammar or punctuation issue in a subsection heading has no way or determining whether there are wikilinks out there that are anchored to the current wording of the subsection heading. They can innocently make that correction and have no way of knowing that they broke a link, or a lot of links.

Another powerful feature, that I am concerned is not properly appreciated by those who favor merging, is the power of watchlists. Watchlists tell us wh

Name-dropping time, when I was an undergrad in 1979 I took a term off to work, as an intern, on the project of one of my heroes, Ted Nelson, American genius, and who, with Doug Engelbart, is credited with first thinking up the idea of a hypertext. Ted coined the term hypertext. Ted was incredibly foresightful. Hypertext was an incredible invention. Ted described hypertext in the early 1960 -- decades before Tim Berners-Lee created HTML at Cerne. Ted expressed his regret over the limited nature of HTML. One of its chief drawbacks being the uni-directional nature of its fragile links.

The hypertext that Ted dreamed of Project Xanadu had bi-directional links, like the wikipedia. It had features like our "what links here" and our watchlists. Links didn't break. Readers could go back ot earlier versions. It included every advance the wikipedia has over regular www pages.

It included other features, not supported by the wikimedia software. One feature present in Ted's vision that we haven't implemented is a smaller granularity of the target of links. Our wikilinks really only work properly on an artle to article level. This is because each article is really an old-fashioned traditional file in an old-fashioned traditional filesystem.

What I would like to see is a feature that allowed us to select text, maybe with a mouse-sweep, and make a link to only that selection of text.
Similarly, I would like to be able to put only a selection of text on our watchlists.
Finally, I would like a choice available to skip clicking on the edit button next to a section heading, or at the top of an article, in order ot edit some text. Instead, or rather in addition, I would like to be able to select some material, and then indicate that I wanted to edit this and only this material. The wikimedia software allows some limited uses of transclusion Transclusion is a powerful feature, and I can see how it could be tricky to fully support it. When we use a template material elsewhere is fetched from elsewhere, possibly expanded, and included in the current rendering of the current page. It is tricky for contributors, who mya want to edit not the current article, but rather the transcluded material. However, when the editor opens they can't find the text they want to edit. If we implemented a facility to sweep over and select some material one wants to edit, and then indicate one wants to edit that, the system should determine whether anything rendered in the selected text had been transcluded from elsewhere, and if so an editor should be opened to the source of the transcluded material, or alternately they would have some way of choosing to edit or view the source of the transcluded material. Geo Swan (talk) 16:23, 1 February 2012 (UTC)[reply]

While I acknowledge the problems with links to section headers, I don't think, they should become deprecated. Without a feature like this, we would have to split a lot of stuff into separate articles. What I don't like about hashed links is their current implementation in the Wikimedia software, however, I think, this can be solved over time. At present, the implementation is broken. If you click on a redirect pointing to a section or anchor in the target page, you will be brought to the start of the article rather than the corresponding section if you happen to have JavaScript disabled. (A lot of people have JavaScript disabled for security reasons, and some browsers even don't support it.) The problem is down to the way how the Mediawiki software deals with hashed links on redirect pages. Apparently it strips off the hashed part. If it would not touch the hashed part for the non-JavaScript path of execution, links to section headers should work fine all the time.

The problem of accidently breaking links by changing section titles is real, that's why we have a convention to add a hidden < !-- HTML comment -- > indicating that a particular title is used in links so that editors can search for and fix them up as well. Such comments could be automatically implanted by bots, but I am not currently aware of a bot doing this.

It is also possible to use the {{anchor}} template in section headers and use anchors instead of section titles in the redirects. The usage of the anchor template implies that there are links to it, so we don't need the HTML comment. However, the anchor name must never be the same as the section title, as this would create a double anchor, which forms invalid HTML. This causes some level of inconsistency when using anchors.

Redirect pages to section titles or anchors should be added to special categories for possible future automated maintenance. At present we use {{R to section}} and {{R to anchor}} for this. It would be possible for a bot to check for changes of section titles / anchors on a page and then recursively look up the pages pointing to that page and fix up the hash links there automatically. This way, we could use hashed links without their headaches.

Of course, with some changes in the Mediawiki database and implementation, it would be possible to integrate this directly into the Mediawiki software so that hashed links are implicitly fixed up on the fly when an editor hits the Save button - without the need for bots, which can only try and correct things after the fact.

(BTW, a edit-by-clicking-on-it feature, as proposed by you above, exists in some forum software, for example in Invision Power Board. If you click on a section of text for about a second, it will become editable if you have the proper rights for editing this section. However, this requires JavaScript to work and therefore is only an optional feature. It would be possible to implement a similar feature in the Mediawiki as well, of course.)

--Matthiaspaul (talk) 12:10, 4 February 2012 (UTC)[reply]

Disambiguation link notification

Hi. When you recently edited Aziz Abdul Naji, you added a link pointing to the disambiguation page Reprieve (check to confirm | fix with Dab solver). Such links are almost always unintended, since a disambiguation page is merely a list of "Did you mean..." article titles. Read the FAQ • Join us at the DPL WikiProject.

It's OK to remove this message. Also, to stop receiving these messages, follow these opt-out instructions. Thanks, DPL bot (talk) 10:31, 4 February 2012 (UTC)[reply]

Adolfo Pablo Borraza Chaple

In the journalist's article, you referred to him as Chaple. It's Spanish/Latin custom to use the first surname as their commonly known surname. This would make him be referred as Borraza or Borraza-Chaple. (First surname comes from the father, second surname comes from the mother) I Couldn't see anything from refs, so I changed the article to refer him as Borraza-Chaple. I'm writing in case I have made an error and he does indeed go by Chaple. Bgwhite (talk) 01:16, 8 February 2012 (UTC)[reply]

Sounds tricky. I'll defer to your judgment here. Cheers! Geo Swan (talk) 10:48, 9 February 2012 (UTC)[reply]

Nomination of Sajeel Shahid for deletion

A discussion is taking place as to whether the article Sajeel Shahid is suitable for inclusion in Wikipedia according to Wikipedia's policies and guidelines or whether it should be deleted.

The article will be discussed at Wikipedia:Articles for deletion/Sajeel Shahid until a consensus is reached, and anyone is welcome to contribute to the discussion. The nomination will explain the policies and guidelines which are of concern. The discussion focuses on good quality evidence, and our policies and guidelines.

Users may edit the article during the discussion, including to improve the article to address concerns raised in the discussion. However, do not remove the article-for-deletion template from the top of the article. Youreallycan 17:26, 9 February 2012 (UTC)[reply]

Disambiguation link notification

Hi. In your recent article edits, you've added some links pointing to disambiguation pages. Such links are almost always unintended, since a disambiguation page is merely a list of "Did you mean..." article titles. Read the FAQ • Join us at the DPL WikiProject.

Jack Nevin (check to confirm | fix with Dab solver)

added links pointing to Washington, J.D., Pierce County and Army War College

Lisa M. Schenck (check to confirm | fix with Dab solver)

added a link pointing to Jason Jones

Sajeel Shahid (check to confirm | fix with Dab solver)

added a link pointing to The Herald

It's OK to remove this message. Also, to stop receiving these messages, follow these opt-out instructions. Thanks, DPL bot (talk) 10:42, 11 February 2012 (UTC)[reply]

AFD and PROD notifications

Hey there GS. Back in November, you got either an AfD or PROD notification, and it was during one of the template testing project's experiments. If you could go here and leave us some feedback about what you think about the new versions of the templates we tested (there are links on the page), that would be very useful. (You can also email me at swallingwikimedia.org if you want.) Thanks! Steven Walling (WMF) • talk 22:39, 17 February 2012 (UTC)[reply]

Disambiguation link notification

Hi. When you recently edited Vagina dentata, you added a link pointing to the disambiguation page Macmillan (check to confirm | fix with Dab solver). Such links are almost always unintended, since a disambiguation page is merely a list of "Did you mean..." article titles. Read the FAQ • Join us at the DPL WikiProject.

It's OK to remove this message. Also, to stop receiving these messages, follow these opt-out instructions. Thanks, DPL bot (talk) 19:38, 18 February 2012 (UTC)[reply]

Talkback

Hello, Geo Swan. You have new messages at Wikipedia:Administrators'_noticeboard/Incidents.
Message added 07:55, 22 February 2012 (UTC). You can remove this notice at any time by removing the {{Talkback}} or {{Tb}} template.

You asked for evidence regarding Epeefleche ignoring WP:BEFORE. I have provided three exampes (among many) where he nominated articles within 60-120 seconds of each other and that, further, he nominates at such a pace (up to 40 per day) that WP:BEFORE could not be reasonably performed. ˜danjel [ talk | contribs ] 07:55, 22 February 2012 (UTC)[reply]

Disambiguation link notification

Hi. When you recently edited Charles E. Merriam Award for Outstanding Public Policy Research, you added links pointing to the disambiguation pages Thomas H. Johnson and Michael Doyle (check to confirm | fix with Dab solver). Such links are almost always unintended, since a disambiguation page is merely a list of "Did you mean..." article titles. Read the FAQ • Join us at the DPL WikiProject.

It's OK to remove this message. Also, to stop receiving these messages, follow these opt-out instructions. Thanks, DPL bot (talk) 10:18, 28 February 2012 (UTC)[reply]