User:Ryan Postlethwaite/Date linking RfC

Please add comments and suggestions about the formatting of a potential RfC at Wikipedia:Date linking request for comment/Call for participation.

This page in a nutshell:

To provide background knowledge to the community, who will be participating in the RfC – many editors will have no knowledge of the date-linking/autoformatting dispute and will not fully understand the concept of date linking/delinking or autoformatting.
To provide advantages and disadvantages of date linking/autoformatting to inform people for individual proposals.

What is date linking/delinking?

I know what it is and you know what it is, but as the wider community may not be familiar with the concept, a description of the process and of the overall dispute provides the background before any voting/comments section here.

What is a 'date'?

date: either a particular day of the year, such as August 1, or a particular year, such as 2003, or both, e.g. August 1, 2003.
day article: a Wikipedia article that covers notable historical events that occurred on a particular day of a year, e.g. March 1 or August 1, 2003.
year article: a Wikipedia article that covers notable historical events that occurred on a particular calendar year, e.g. 2006.

What is date linking?

Date linking is the practice of linking dates (including month-day fragments, years and other chronological items) that appear in Wikipedia articles to articles about those dates (such as 18 December 1477). The purposes usually cited for date linking include: a) to provide historical context for articles, b) to provide another method of browsing Wikipedia articles and c) to utilize the date autoformatting system available on Wikipedia since 2003. Up until recently it was mandated that all chronological items (dates and years) be linked to take advantage of the autoformatting system.

What is date delinking?

Date delinking is the manual, semi-automated, or fully automated process of removing links to Wikipedia articles about chronological items from other articles. These links may be to day/month combinations (e.g., March 26), to years (e.g., 1345), and to "year-in-subject" articles (e.g., 1936 in sports). Delinking may be done for the purpose of addressing overlinking, or for the purpose of removing links that were put in place only because of the system of date autoformatting.

The history of the dispute

The following section's wording or inclusion in this policy or guideline is disputed or under discussion. Please see the relevant talk page discussion for further information.

A straw poll at WT:MOSNUM in August 2008 led to the deprecation of date linking for autoformatting purposes. Some editors then moved forward with a large-scale manual, automated and semi-automated removal of date links. A number of editors indicated their opposition to this change at both WT:MOSNUM as well as at the talk pages of the delinking editors. Discussion continued at WT:MOSNUM on whether a large enough number of editors had previously participated to accurately represent community consensus. Toward the end of November, two parallel RFCs on the subjects of date-linking/unlinking and autoformatting were launched, receiving input from hundreds of editors:

While the RFCs offered guidance on a number of important points, there is disagreement as to whether that guidance has resolved all aspects of the debate. This proposed RfC would seek to clarify under which conditions date linking should be used, and whether a form of date autoformatting is desired.

Month-day markup

Advantages

Provides easy access to date articles.
Clearly indicates which strings are actual dates (as opposed to, e.g., quotations of dates.)
Simplifies automated processing of article text (i.e. gathering metadata).
Populates "what links here" pages with possibly relevant data.

Disadvantages

A vestige of the old autoformatting system.
Leads to overlinking, thus diluting high-value links.
Little proven relevance to the topic of an article, with the possible exception of contexts in which anniversaries are at issue.
Complicates the syntax for editing pages.
Possible "metadata" from linking chronological items is unspecified and of unclear value.
Search box can be used as an alternative to the "What links here" function to generate information for chronological articles
"What links here" often generates many false positives and/or sources of questionable utility or relevance.

Year markup

Year markup can be done with a year link (1987) or a pipe (here 1987 links to a topic-specific article).

Advantages

Provides easy access to year articles.
Clearly indicates which strings are actual dates (as opposed to, e.g., quotations of dates.)
Simplifies automated processing of article text (i.e., gathering metadata).
Populates "what links here" pages with possibly relevant data.

Disadvantages

The following section's wording or inclusion in this policy or guideline is disputed or under discussion. Please see the relevant talk page discussion for further information.

If added thoughtlessly to articles, year links
- can lead to overlinking and dilution of high-value links
- can populate "what links here" pages with irrelevant data

Full date markup

Some proponents of date linking have suggested links to the full date (i.e. including the day, month, and year in a single link) be used rather than two different links with one to the day-month combination and another to the year.

Advantages

Makes date links more relevant.

Disadvantages

Requires a larger number of date articles.
Differs from existing convention
- Millions of linked dates would need to change.
- Editors would need to be made aware of the change in convention.
Complicated editing syntax

Possible exceptions in which parties may desire linked dates

If a general reader is likely to be suprised that a date even exists, it may be linked (e.g. February 30, January 0).
Articles/templates about chronological items should be able to link to other dates (e.g. templates may have navigation for 1309 and 1310, or for April 1 and April 2.)
See also sections (e.g. Other significant events in 1944 or Timeline of the Second World War)

Autoformatting/Autolinking

What is date autoformatting?

Date autoformatting is a system that reformats marked-up dates into a specified format.

The current system of date autoformatting allows registered users who have logged in to set a date format preference (for example, dd Month YYYY or Month dd, YYYY). Unregistered users (aka "I.P. users") and registered users who have not set their user preferences see dates in the format that was entered in the article. Dates that are entered in plain text (without markup) are not changed by the date autoformatting system.

What is date autolinking?

Date autolinking is a system that creates links to dates or parts of dates, based on some form of syntactic markup.

The current system of date autolinking is combined with the date autoformatting system in such a way that the only dates subject to autoformatting are those that have been marked up with a link-like syntax, which also results in the parts (the year and the month-day combination) being linked.

Advantages of autoformatting in general

Presents a consistent date format for at least some readers.
Allows at least some readers to see most (possibly all) dates in their preferred format.

Advantages of autolinking in general

Provides ability to link to year articles for easier browsing.
Provides ability to link to month/day articles for easier browsing.

Advantages specific to the current system

Provides a consistent date format for registered users who have set a date preference.
Allows individual registered users to see most dates in the format they prefer.

Disadvantages of the current system

Use of the YYYY-MM-DD format can cause confusion when this format is understood to be ISO 8601-compliant. ISO 8601 compliance implies use of the proleptic Gregorian calendar which might not be the case in all uses.
According to various style guides, full dates written in MDY format included in running text should always be followed by a comma, so as to make the year parenthetical. Dates written in DMY format require no such comma, and so automatic conversion between these formats can result in grammatical errors.
Date ranges currently require a cumbersome (and repetitive) syntax. (See: Wikipedia:Date formattings#Date ranges.) For example, date ranges must currently be written as [[January 1]] – [[January 2]], [[2008]] rather than the otherwise preferred [[January 1–2]], [[2008]]. This syntax does not work for readers who have selected YMD as their preferred format, as they will see 1 January-2008 January 2. The only way to mark up a date range to suit all date preferences is to write out both dates fully linked for autoformatting: [[January 1]], [[2008]] – [[January 2]], [[2008]].
Similar difficulties apply to overnight dates such as "the night of 1/2 January 2008"
Because anonymous readers (or registered users who have selected "No preference" in their date settings) see dates in the format in which they appear in the raw article text, they may be presented with an inconsistent format within a given article. Registered users who have set a date format preference only see these inconsistencies while editing a page, not while reading it.
There is currently no way to have a date autoformatted without also having it linked.
Since all autoformatted dates are linked, for all users, this raises the issue of overlinking.

Objections to autoformatting in general

In general, objections to autoformatting come in one of two varieties: Those which involve the (necessary) markup syntax used to identify reformattable dates, and those that involve the differences in format/linking seen by different readers.

Markup-based objections

Any form of autoformatting (other than those already ruled out by Brion VIBBER) would require that dates be identified by marking them up with some kind of special syntax. All of these objections would (in theory) apply to any autolinking system , as well as any autoformatting one.

The extra markup complicates editing syntax and presents an obstacle to new editors.
Since Wikipedia's use of both of the most popularly-used date formats (9 April 2007 and Apri 9, 2007) causes minimal confusion to our readership, the extra editing burden of autoformatting would address only a style issue. However, it would perform its special style-changing action only for some registered editors; I.P. users (the vast majority of our readership) would see only a default, which is addressed simply with written-out, fixed text.
The terminal comma problem may affect any system that converts MDY into DMY; it must decide whether a terminal comma is parenthetical or required by the syntax of the whole sentence.
- This can be avoided by special markup, something like "On [[September 11]], [[2001]],, the World Trade Center...", which uses a double comma for a parenthetical and syntactical comma, but unintuitive markup is itself a cost. Other syntaxes could be used (such as only specifying which dates shouldn't have a parenthetical comma following the year in MDY format, since there'd be far fewer of those cases) but the point remains that it would require a special (potentially unintuitive) syntax.

Display-difference-based objections

Autoformatting prevents registered editors who have set their date preference from seeing when default date formats in articles are inappropriate for that article.

Unique/Stand-alone objections

The problem of proleptic Gregorian calendar dates will affect any system that outputs ISO numerical dates.

Demonstration/Test system

Several editors (including several software developers) have been working to develop a new date autoformatting/autolinking system. One of the developers has established a test wiki at dates.xoom.org to demonstrate how a proposed software patch might work. (Note that this site is not affiliated with Wikipedia or the Wikimedia foundation; please exercise caution when submitting personal information to a third-party website, or creating an account on any such system.)

The new date autoformatting/autolinking system is intended to work in a similar fashion to the current system. However, unregistered readers would see a default date format, tentatively similar to 19 February 2009, rather than a potential mismatch of formats.

Advantages

It presents a consistent date format to anonymous readers, while allowing registered users to customize date display and turn date links on/off via Special:Preferences.
It uses the existing date autoformatting syntax, but adds support for date ranges.
It retains the ability to create intentional date links where consensus dictates.
It provides a finer granularity on date preferences, so that registered users can specify their preferences independently for date formats, per-page date formats, and date linking.

Disadvantages

The proposed system will continue to rely on a syntax similar to the standard wikilinking syntax to mark up dates, but does not necessarily create a link. This may confuse some editors.
The standard autoformatting syntax is inherently confusing - the elements of the date (day, month, year) are reformatted as a whole, but they have to be linked separately as [[day, month]] and [[year]]
Since some editors would not see formatted dates as links (thus making them indistinguishable from plain text) it will require an extra step for those editors to determine if all of an article's dates are surrounded by the appropriate markup syntax.

Important considerations

The system is still under active development and should not be considered complete.
A full software specification has not yet been agreed upon.
Once complete, the system would still need to undergo (possibly extensive) testing by other developers and the systems administrators of the Wikimedia servers, before it could be put into use. That testing process would happen independently of any community decision amongst Wikipedia editors, and it may turn out that the software solution is rejected (for technical reasons) despite strong community support.

Proposed wording to identify the nucleus of the disagreement

User:Greg L

I’ve added this section to provide another way to identify the points of agreement and disagreement. The wording of the following two RfC proposals are notional and may have biased wording which can be revised to a more neutral tone. These proposals are intended as a mechanism to help focus on the crux of the dispute.

When to link to date articles

Question–Should the following MOSNUM guideline be adopted: Date articles should not be linked on Wikipedia unless the date article to which is being linked has content that predominantly shares a common theme (besides the fact they share a common day or year) that is particularly germane and topical to subject of the linking article. For instance, Timeline of World War II (1942) may be linked to from another article about WWII, and so to may 1787 in science when writing about a particular development on the metric system in that year.

Link to talk page for discussion on this.

Autoformatting of dates

Question–Should the following MOSNUM guideline be adopted: To ensure the highest quality Wikipedia articles and to make editing as simple as possible, registered editors should always see the same article content as I.P users see. To further this principle, editors shall not use date formatting tools that provide custom date formats for registered editors but which provide only a default date format for I.P. users (e.g. either "March 1, 2006" or "1 March 2006"). Rather, it is preferable that the date format most suitable for the article be chosen per applicable WP:MOSNUM guidelines, and dates shall be simply written in fixed text so they appear the same to all users—registered editors included.

Link to talk page for discussion on this.

User:Arthur Rubin

Project consensus

Question-Should the following MOSNUM guideline be adopted: Consensus within a WikiProject may specify year links which should be included in articles. For example Wikipedia:WikiProject Biography could estabish a consensus that birth and death years should be linked.

Voters' pamphlet method to resolving autoformatting

How about this: In the U.S., voters pamphlets on voters’ initiatives and new proposals from the legislature have the following:

a nutshell overview of the proposed law, written by the secretary of state,
an expanded explanation of the effect of the law, written by the secretary of state,
a position statement in support written by the proponents of the initiative,
a position statement against written by opponents of the initiative, and,
two short rebuttals of by each side to counter assertions in the others’ position statements.

I (Greg L) propose that a simple ArbCom-monitored RfC be conducted which uses all of the above five components. It would simply ask something like this:

Request for comment: Shall regular body-text dates on Wikipedia be autoformatted?
Effect if approved: Articles would be header-tagged at the top with a special command that would set the default format for that article. Further, editors would write dates with brackets like {{January 1, 2007}} or {{1 January 2007}}.
Regardless of the format within the brackets, the effect would be that all bracketed dates would, for I.P. users, consistently default to the format established by the header tag. Thus, an article on, for instance, the Chicago Cubs would have all dates default to American-style dates, January 1, 2007 regardless as to how the editor coded the date within the double-brackets.
However, Wikipedia users who are A) registered editors, and who B) have set their user preferences on date format to something other than “No preference” will see the dates formatted in their format of choice. Thus, even if Chicago Cubs is tagged to default to American-style dates for regular I.P. users, registered editors who have set their user preferences setting accordingly, could see Euro-style dates if they chose (1 January 2007).

Or some similar wording may be used. I might have some details incorrect above, but this illustrates the technique. Then…

There would be a 500-word statement by each camp both for and against (or some other agreed-to limit that applies equally). There would also be a 150-word rebuttal of the others’ position statement (or other number of words, so long as it applies equally).

How say ye all to this?

Link to talk page for discussion on this.

Link to another discussion thread on the same page.