This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 115 | ← | Archive 117 | Archive 118 | Archive 119 | Archive 120 | Archive 121 | → | Archive 125 |
Whenever I ask this question, no one addresses it. Do we really think our readers and editors are so inflexible (or moronic) that it matters? Why is that people want to go to such extraordinary lengths to fix something that is not a problem in the first place. The primary purpose of the silly date-autoformatting that was so unwisely adopted by us Internet innocents back in 2003 was to "prevent edit-warring over which date format would be used in an article". We have grown up since then, having developed very workable, well-accepted systems for ENGVAR (article-consistent) and article date-format choice (also article-consistent). There were a few little scraps involving User Pete a while ago over the latter (apparently no longer an issue), but generally speaking, what I see is remarkably little debate over which format to use in which article, let alone tension. The edit-warring thing is a complete non-issue, and WPians seem to accept without a blink the absence of a hi-tech toy to mess with the order of month/day; I note that there's still a residual group of computer programmers that cannot bear to see the demise of a programming toy. Sorry, we don't need it, it's not a problem, thanks. Nor do we need autoformatting for colour/or, traveling/lling et al. English-speakers on the Internet find it all rather easy to read these minor, easily recognisable differences.
I can think of a LOT of better things to do with our time; like helping out at WikiProject Years to bring our year-articles out of the doldrums. Tony (talk) 11:09, 22 January 2009 (UTC)
Mirror. "Disparaging" is your spin-word. The only thing I disparage are claims that the RfC data you are trumpeting are meaningful. Tony (talk) 06:08, 23 January 2009 (UTC)
Articles not closely associated with American topics such as Italy, Austria, Basilica di Saccargia and Kilogram have a pronounced non-American readership. Regardless of the dialect of English used by the editor of that article, we should be thinking foremost about our readers. So in articles on general or European subjects (articles clearly not associated with the U.S.), we would simply use Euro-style dates.
Conversely, for articles on, or closely associated with American topics, such as Spokane River Centennial Trail; Coeur d'Alene, Idaho; American Revolution; and New York Yankees, they have a preponderance of American readers and the date format that is most natural for those readers is the American-style date.
It is an utterly trivial matter to simply use the date format that is most natural for the likely readership. I would propose this simple guideline:
For articles on, or strongly associated with, the following countries and territories: The United States, American Samoa, Guam, Northern Mariana Islands, Puerto Rico, U.S. Virgin Islands, Wake Island, Republic of the Marshall Islands, Federated States of Micronesia, and Republic of Palau; editors should use the U.S.-style date format (“February 2, 2008”), otherwise, editors should use the international date format (“2 February 2008”) in articles.
Picked up an Australian newspaper lately? Tony (talk) 06:12, 23 January 2009 (UTC)
The current autoformat linking system links dates always to the same page, regardless of initial format. So all of the following link the month part to page "January 2":
[[January 2]]
:
January 2[[2 January]]
:
2 January [[2008-01-02]]
:
2008-01-02Any new system to have any use, must have the same behaviour. The current test system does not do this. − Woodstone ( talk) 19:02, 23 January 2009 (UTC)
In the test system I still see [[:January 2]]
linking to "Januari 2" and [[:2 January]]
linking to "2 Januari". Since it is awkward to have an article name starting with a number, the date articles are named like "Januari 2". Even when the format (or source) is in the form "2 Januari", or "2008-01-02", it should still link to "Januari 2". And with the current system, they do. −
Woodstone (
talk) 20:24, 23 January 2009 (UTC)
:
prefixed dates shouldn't also be auto formatted. If someone wants to intentionally format a date a certain way they can override that via pipes. For example:
[[January 1]], [[2009]]
should be unlinked and auto formatted.[[:January 1]], [[2009]]
should be linked and auto formatted.[[January 1|January 1]], [[2009]]
should be linked and not auto formatted.January 1, 2009
should be unlinked and not auto formatted.:
) to imply an intentional link with auto formatting, and a date without a colon to imply a date that's not linked but is auto formatted as well. For cases where you want the link and a specific date format you can do it by hand with the pipe. —
Locke Cole •
t •
c 00:46, 24 January 2009 (UTC)I have finished a demo version of the new Date Autoformatting code, and made it available for public viewing here:
IMPORTANT NOTE REGARDING PRIVACY: I have access to the server logs on the above server, which means that (in theory) I can find out the IP address used to access that website. If you create an account on that wiki for testing (which is encouraged) you should NOT use any personally identifying information such as your real name or your Wikipedia username. Also feel free to connect through whatever proxy you like, to further protect your own identity.
The main page of that demo wiki contains examples in all the major date formats. While viewing the page as an anon user, you will note that all of the links in the first section are in a consistent format (DMY with the month spelled out — so-called "International" format) and are not linked. If you create an account and set your "Date and time" preferences you will notice an option for "Date linking" that can be set to "Do not link dates" (the default) or "Link dates" at your choice. I've tested each combination of date format and linking option myself (and haven't noticed any problems) but I'm only human so please check for any mistakes I may have missed. Additional comments are welcome.
Note that I have not (yet) put any disclaimers regarding ISO formatting, nor have I made a separate set of options for in-article dates versus mediawiki dates (i.e. page last updated, etc.) because although those may be desirable features, they introduce more complications than I'd like to deal with in this first round. The separate preferences in particular may prove problematic, since those are actually implemented by two different PHP functions within the code. That said, I recognize the value of those suggestions and will gladly work to incorporate them at a later date.
I'm not sure how long I'll be keeping the demo site active, since I'll eventually need to take it down once I need that server for some projects related to my actual job :) -- UC_Bill ( talk) 23:38, 22 January 2009 (UTC)
__FORMAT_DATES_MDY__
and __FORMAT_DATES_DMY__
). That should be enough to take this live. Later we can add an option in preferences to link or not link dates. —
Locke Cole •
t •
c 23:50, 22 January 2009 (UTC)I'm actively working on the site, so if it's broken try back later. -- UC_Bill ( talk) 00:16, 23 January 2009 (UTC)
I've added support for a new magic word that allows you to specify a default format on a particular page. For example, you can make a page use MDY format instead of the default DMY by adding this: {{DATEFORMAT:MDY}}
I'm through editing the site for the day, so there won't be any additional changes. Feel free to play around on the demo site and try to break things, and please share any feedback you have here (not on the demo wiki.. it'll be erased once testing is done.) -- UC_Bill ( talk) 01:24, 23 January 2009 (UTC)
[[January 17-22]], [[2008]]
; it should be simple enough to look for the dash), but it's something we should consider before seeing about getting this added. —
Locke Cole •
t •
c 02:02, 23 January 2009 (UTC)(Outdent) I'm sorry Gerry, I misunderstood your point. Different date ranges would be broken with the new DA. But perhaps more importantly, articles that currently have linked dates like [[September 11]], [[2001]] with a clear US emphasis would suddenly appear as 11 September 2001 — which is good in that it gets rid of the bluelink (although in this case I guess the date probably should be linked.. bad example, but you get the idea) but is probably not in the preferred format. On the plus side, the new DA would mean you just add {{DATEFORMAT:MDY}} to the page and all the autoformatted dates would switch to the correct format. But somebody would still need to add it, and until then the format would be "wrong" for anons and "no preference" people. -- Sapphic ( talk) 03:52, 23 January 2009 (UTC)
Tony, overcoming the "bias" is as simple as adding {{DATEFORMAT:MDY}} to any page that needs it. Gerry raises a valid point though, with regards to the editors having no way to have both forced-linking and autoformatting at the same time. (Of course the current DA only "allows" this because it forces all marked-up dates to be linked, but still..) This could be fixed by modifying the date markup syntax slightly, by either making it more similar to either category syntax or image syntax. Image syntax would probably be easier to remember, since it's wordier. For example, image syntax is [[Image:Kentikian-hokmi.png|thumb|Kentikian (right) in her rematch with Nadia Hokmi, December 2007]] (note the "thumb") and the equivalent syntax for a date in the new DA could be [[September 11|link]], [[2001]]. This would take away the ability of editors to have a link to a date with the link text of "link" but that's an utterly trivial restriction and is similar to the inability of editors to have an image with a caption of "thumb" as is currently the case. So in that example, the link would be both autoformatted and linked for everyone, and it uses a syntax that people are already familiar with for images. -- Sapphic ( talk) 15:36, 23 January 2009 (UTC)
This doesn't work. The standard American sentence
translates into British (and Australian)
and the other way around.
Note the comma which appears and disappears before wreaked, (but remains in both sentences before New York). The autoformatter does not handle this correctly or tolerably in either direction. I think this is an irremediable defect, since avoiding it would require the autoformatter to parse the sentence. Septentrionalis PMAnderson 16:26, 23 January 2009 (UTC)
September 11, 2001, wreaked massive destruction is not sound American English. A comma only follows a date if it's part of a subordinate clause, as in On September 11, 2001, massive destruction was wreaked. In other varieties of English, the comma following the subordinate clause is optional if the clause ends with a date (and maybe other times, I only know about the situation with dates). If we always follow a subordinate clause with a comma, then there's no inconsistency. -- UC_Bill ( talk) 17:22, 23 January 2009 (UTC)
I have evidence that it's actually correct usage ( here) which I find to be absurd, since I've never seen anybody write it that way. The page I just referenced claims it's done for "typographical reasons" but doesn't mention anything about it being an American variation. I'll look into it though, to see what the deal is. -- UC_Bill ( talk) 17:33, 23 January 2009 (UTC)
(Edit conflict) And actually upon closer reading, it does mention "International format" which covers the non-American variants. Apparently it's because surrounding the year with commas on either side is supposed to make it set off from the rest. It only applies to full dates as well, according to that page. Anyway, since it does seem to be an official style guideline it's easy enough to support by putting the comma inside the square brackets. I'll update the demo code accordingly. -- UC_Bill ( talk) 17:33, 23 January 2009 (UTC)
Oh! I get why they put the comma there. It's because they're treating the mention of the year as an aside, similar to: Bob Smith, my brother, is tall So the comma before the year is actually doing "double duty" by acting as part of the date format and as a way of indicating that the year is a subclause. I think that's overly confusing (especially since they don't do it for DMY format) but like I said, it's easy enough to support in the new DA code so no worries. -- UC_Bill ( talk) 17:38, 23 January 2009 (UTC)
There's no need for a working proof-reader. The first example could be written "[[April 5]], [[2001,]] was just a working day for the crew" and would be rendered as "April 5, 2001, was just a working day for the crew" in MDY and "5 April 2001 was just a working day for the crew" in DMY. The second example could be written "Early in the morning of [[April 5]], [[2001]], the crew put their boat into the water" and would be rendered as "Early in the morning of April 5, 2001, the crew put their boat into the water" in MDY and "Early in the morning of 5 April 2001, the crew put their boat into the water" in DMY. Very simple. If the comma is supposed to be autoformatted, it goes inside the square brackets. If it's not part of the autoformatting, it goes outside the square brackets. there's no need for proofreading because editors can control how the comma is handled. -- UC_Bill ( talk) 18:03, 23 January 2009 (UTC)
I think maybe I figured out what you were getting at. Did you mean that examples like "The best of times was [[10 September]] [[2001]]; the worst of times began the next day" should be rendered as "The best of times was September 10, 2001; the worst of times began the next day" in MDY and not as "The best of times was September 10,2001,; the worst of times began the next day" as might be the case if the comma was always added after MDY dates? If that's what you were discussing, then rest assured that it works fine on the demo system. Please continue making comments in the new section below, since we're now dealing with an updated version of the software (and this section is way too long). -- UC_Bill ( talk) 21:07, 23 January 2009 (UTC)
As a suggestion, and wherever a specific date is not required, it would be better to use an example date in which the day number is greater than 12. For example, on the demo page, 2009-01-31 would be better as an example than 2009-01-01. In that way, there will never be an example where the resulting day and month can be confused—resulting in a tighter specification. HWV258 01:19, 24 January 2009 (UTC)
The demo code has been updated to deal with the comma issues pointed out above:
IMPORTANT NOTE REGARDING PRIVACY: I have access to the server logs on the above server, which means that (in theory) I can find out the IP address used to access that website. If you create an account on that wiki for testing (which is encouraged) you should NOT use any personally identifying information such as your real name or your Wikipedia username. Also feel free to connect through whatever proxy you like, to further protect your own identity.
I've put some comma-related examples on the main page of the demo site, but haven't exhaustively tested every combination of formats with every combination of preferences, so if you notice any misformatting please share it here. Make sure to include the example wikitext that formats incorrectly, as well as the preference settings you were using. -- UC_Bill ( talk) 19:43, 23 January 2009 (UTC)
The rule exception for comparative quantities has bugged me for a long time. Why does it exist? In my humble view, it serves no purpose other than unnecessarily complicating the writing of sequences of objects. I'm referring to the exception that doesn't allow "32 dogs and five cats" and asks that it be written as "32 dogs and 5 cats". JKBrooks85 ( talk) 00:09, 25 January 2009 (UTC)
Brought to attention by some (good) edits by User:TechControl:
Should MOSNUM be changed? Shreevatsa ( talk) 22:43, 23 January 2009 (UTC)
I object to basing Wikipedia writing guidelines on expensive standards that are not available for free on the Internet. -- Gerry Ashton ( talk) 17:25, 24 January 2009 (UTC)
NIST's Guide for the Use of the International System of Units (SI) (p. 9) shows bit as the symbol for the word bit. It indicates that bit and other information technology units given in ISO 31, its successor ISO/IEC 80000-1—ISO/IEC 80000-15, and IEC 60027 parts 1 through 4 may be used with SI units. -- Gerry Ashton ( talk) 20:14, 24 January 2009 (UTC)
NIST is only US related, IEEE is international.
5.1.3 Units from International Standards There are a few highly specialized units that are given by ... ISO or ... IEC and which in the view of this Guide are also acceptable for use with the SI. They include the octave, phon, and sone, and units used in information technology, including the baud (Bd), bit (bit), erlang (E), hartley (Hart), and shannon (Sh)3. It is the position of this Guide that the only such additional units NIST authors may use with the SI are those given in either the International Standards on quantities and units of ISO (Ref. [4]) or of IEC (Ref. [5]).
Ref 4 = ISO 31, Ref 5 = IEC 60027. But Bit#Obsolete_definitions says IEC is obsolete. Can we stop referring to these obsolete standards? TechControl ( talk) 21:16, 24 January 2009 (UTC)
Shall we have Wikipedia:Manual of Style (dates and numbers)/Proposal on bit symbol ? We now already have two bit symbol threads in this page and lot of talk about date formatting floating around. TechControl ( talk) 21:32, 24 January 2009 (UTC)
It doesn’t matter what all these standard bodies say. To minimize confusion and communicate clearly, Wikipedia should follow the practices observed in current, most-reliable literature on the subject. If we wanted to follow what the BIPM says, we’d put a space before a percent symbol,like At least 99 % of readers ignore the BIPM and follow real-world practices, rather than what everyone actually writes: At least 99% of readers ignore the BIPM and follow real-world practices. And MOSNUM, here, follows the real-world practice with respect to the percent symbol and ignores the BIPM on this issue (*sound of audience gasp*).
We have got to stop acting like Talk:MOSNUM is a venue where the Mr. Spock in us all can glom onto each and every cool proposal that comes along and make Wikipedia ready to join the United Federation of Planets. If we did that, only about 2 centiuno of our readership would understand what is written here.
It’s simple: Editors should simply look towards current literature on the subject; each and every issue doesn’t have to come here for discussion and debate about “what’s the best way to do something in a utopian world.” We follow the proposals of standard bodies only after they are widely followed in the real world. Always. Greg L ( talk) 01:07, 26 January 2009 (UTC)
Actually we do write KiB (follow the link). This is standard writing. And so is b for bit. I quote ISO/IEC 80000:
International standard ISO 80000 or IEC 80000 (depending on which of the two international standards bodies International Organization for Standardization and International Electrotechnical Commission is in charge of each respective part), successor of ISO 31 and partially of IEC 60027, is the most widely respected style guide for the use of physical quantities and units of measurement, and formulas involving them, in scientific and educational documents worldwide. In most countries, the notations used in mathematics and science textbooks at schools and universities follow closely the guidelines given by these standard.
Another thing I found: The chairman of IEC TC 25, Anders J. Thor, has pointed out that there are four systems of writing that bridge all linguistic barriers regardless of the alphabet used. These systems are:
The fundamental importance of ISO/IEC 80000 is obvious because the first three systems will be given in this standard. It is only music that will be outside the scope of the future ISO/IEC 80000.
Source: http://www.iec.ch/zone/si/si_present.htm
To declare bit to be the symbol for bit will not help in education, it will prevent spreading good knowledge.(Strike, because not clear what IEC says!) New: IMO WP should help spreading good knowledge and not an average of magazines and computer ads.
TechControl (
talk) 13:47, 26 January 2009 (UTC)
When used to express a storage capacity or an equivalent binary storage capacity, the bit and the octet (or byte) may be combined with SI prefixes or prefixes for binary multiples. In English, the name byte, symbol B, is used as a synonym for octet. Here byte means an eight-bit byte. However, byte has been used for numbers of bits other than eight. To avoid the risk of confusion, it is strongly recommended that the name byte and the symbol B be used only for eight-bit bytes. The symbol B for byte is not international and should not be confused with the symbol B for bel.
The demo code has been updated to deal with various issues discussed above:
Changes in this version:
I changed the default for anon users in this version because that seemed to be what people wanted when I first started making updates.. but in the meantime it seems that popular opinion is swinging back the other way, and people may want anons to have a DMY default so they see a consistent format. I'll leave it as "no autoformatting" for now, but it can be switched to whatever we want, once we've had a look at all the options. Similarly for the "date linking" and "per-page overrides" options, which can be set however we like for anons.
I'll work on autoformatting for date ranges next, as well as whatever other bugfixes people point out in this version. I'll also make the source code available soon, but given the four other now-obsolete patches I submitted for this project already, I'd rather just wait until it's pretty much done and submit the final version. -- UC_Bill ( talk) 21:04, 26 January 2009 (UTC)
I've set the default for anons to "DMY, per-page overrides allowed, no automatic links" on the demo site. The benefit to anons is that they will see a consistent format, specifiable on a per-page basis (or defaulting to DMY if no per-page format is set) and regardless of how the dates appear in the raw wikitext. That last point means that there would be no need to police the pages to enforce consistency, so if an editor adds a (marked-up) date to a page in a different format than what the format "should" be for that page, it will be automatically corrected. -- UC_Bill ( talk) 23:54, 26 January 2009 (UTC)
What you have Bill, is a technical solution in search of a problem to fix. Sparing a handful of registered editors the shock of having to look at a date format that our regular I.P. editors see (99.9% of our readership), is not a legitimate problem worth fixing. It’s a waste of time. We should all simply look at what our I.P. users look at. If we can’t bear to face the shear terror of that (seeing what everyone else see), then there’s something wrong with the rules for determining the date format to use in our articles and should improve those rules and have respect for them. Greg L ( talk) 00:30, 27 January 2009 (UTC)
Autoformatting is mass medication. Everybody is being forced to take a complicated cure even if they don't have the disease. Who benefits from all the editing burden? Answer: only a few. Autoformatting is frequently broken, it is inherent in all the systems proposed. All the systems proposed require effort on the part of those that can live without it. If you want to spend your own money that is fine by me, but once you propose supporting your system by a tax on all of us, you need a better reason than "some voters say they want it". Lightmouse ( talk) 01:51, 27 January 2009 (UTC)
Your tactics here are childish and tedious (like renaming my ANI against you from “Disruption by Locke Cole ” to “Trouble with new RFC at MOSNUM ”. In the ANI over your little stunt, you pulled out your boilerplate rant of [Greg was] incivil to me, personally attack me. It is tedious and no one bought into it. There, Seicer fairly warned you [4] and [5] that you can't accept the fact that the community has voiced its opinion, that you are disrupt[ing] Wikipedia to make a point, and that persisting as you have could land you with additional blocks. I suggest you take his advise. Greg L ( talk) 03:37, 27 January 2009 (UTC)
The point of course is that the status is not "RESOLVED" (and never was during the time of the
RfC). I hope it is obvious to everyone that a "patch" is not ready to implemented until it is finished, and the continuing discussion (73 posts at the Bugzilla
site) clearly indicates that it was not finished (and still isn't). During the three-year debate at Bugzilla, the status was changed to "RESOLVED" four times and I see no evidence of anything having been "committed to the MediaWiki code". The main point being that nothing can be committed to MediaWiki while the bug is still unresolved. Thanks for pointing that out with the link in your previous post—it conclusively proves that the patch is not ready (and certainly wasn't ready at the time the misleading comment was placed at the head of the RfC). Here are the relevant posts to the RfC:
And unfortunately for the RfC, that's how the tainting statement remained. The problem with all the above can be seen by looking at the timeline at the bug's activity log. On 2008-10-24 10:35:45, the status of the bug was changed from "RESOLVED" to "REOPENED", and the resolution of "FIXED" was removed. The status of the bug has remained in "REOPENED" ever since (and therefore throughout the period of the edits detailed above). I sincerely hope that it is now beyond doubt that, at the time of the wording of the RfC, no release-ready patch was available for use by the WP community. I now humbly request the results of the RfC (containing the statement "Mediawiki's software developers have created a patch to correct problems with the current method of date auto-formatting") be nullified. HWV258 22:36, 27 January 2009 (UTC)
The demo code has been updated to deal with various issues discussed above:
The biggest change in this version is the addition of autoformatting for date ranges. A feature summary (and comparison with the old DA and the option of using plain text dates) is as follows:
Feature | Current DA | New DA | Plain text |
---|---|---|---|
Dates are not linked by default | No | Yes | Yes |
Consistent date format for anons | No | Yes | Manual |
Per-page default formats for dates | No | Yes | Manual |
Registered users can pick a date format | Yes | Yes | No |
Registered users can turn autoformatting off | Yes | Yes | Always off |
Registered users can turn date linking on | Always on | Yes | No |
Registered users can turn date linking off | No | Yes | Always off |
Date ranges handled correctly | No | Yes | Manual |
Parenthetical years in MDY handled correctly | No | Yes | Manual |
The benefit to registered users of the new DA over plain text can be seen in the two options that plain text doesn't support. The benefit to anon users is that there is no need for manual enforcement to keep formats consistent — with the new DA, an anon user would never see an article in an inconsistent format (unless of course such inconsistencies were intentionally introduced by using piped links, as might be the case with dates like September 11, 2001 appearing in an article otherwise using the DMY format). That benefit would be delivered to all anon users the moment the new DA was installed onto Wikipedia, without any additional effort required on the part of editors. Similarly, adding the {{DATEFORMAT:MDY}} magic word to an article would guarantee that from that point forward, all autoformatted dates in the article would always be in the correct format. Changes to a page's format could be made by changing the magic word, without having to edit each and every date on the page. -- UC_Bill ( talk) 20:22, 27 January 2009 (UTC)
More importantly, editors with modest experience at editing, who can recognize an inappropriate date format that doesn’t fit with the others, can easily correct fixed-text dates without any understanding whatsoever of magic words; with 47,390,762 editors on en.Wikipedia, there is an army of them out there with this moderate level of experience. I suggest we harness that immense power of the larger Wikipedian community and not make things more complex with a magic word that would make any programmer proud. It’s hard enough just to get novice editors to put a non-breaking space before a unit symbol.
Finally—and most important of all, really—is there seems to be a developing community consensus now that it is a disadvantage, not an advantage, to have registered editors looking at article content that is different from what everyone else sees. I know I can handle seeing some articles with dates that look like “July 4, 1776” (American Independence) and still other articles that are formated like “17 January 1793” (Louis XVI of France condemned to death). I don’t mind it at all. The above RfC makes it clear that the community consensus feels this way too.
It’s not a big deal. Not worth the effort. More than that, it’s better if we don’t even head down this path of giving registered editors a special view of article content that no one else can see. Greg L ( talk) 21:56, 27 January 2009 (UTC)
Further, you stated that you disagreed with my claim that there seems to be a developing community consensus now that it is a disadvantage, not an advantage, to have registered editors looking at article content that is different from what everyone else sees and then attempted to buttress your point by extolling the virtues of autoformatting. Let’s parse that sentence: the ‘subject’ is “community consensus”, not “different view of article content” and the wisdom of same. What you see as the virtues of default tags for articles, magic words, and autoformatting that gives registered editors a special view of article content has nothing whatsoever with what what community consensus is on this matter. That is the only thing that matters and the community consensus seems to be developing here that they think it is best when registered editors see what everyone else sees.
I can see there is no point to you and I further trying to debate this issue. We will have to agree to disagree. Goodbye. Greg L ( talk) 22:46, 27 January 2009 (UTC)
I think this is probably the least confusing syntax, because it mirrors the way category syntax works. However, I'm not sure whether "marked" dates should be written as [[:January 30]], [[2009]] or [[:January 30]], [[:2009]] or whether both should be allowed. I could see the second being used to "mark" a link for both the month-day and the year, while the first would only "mark" the month-day and leave the year unlinked (except for registered users who chose the "more links" setting). I'm not sure if giving editors the ability to enable autoformatting on the full date but only link for the month-day is worth the extra syntax. I'm also not sure what others think about using category-like syntax for this, since some people (Sapphic) have suggested using image-like syntax instead. Thoughts? -- UC_Bill ( talk) 23:50, 27 January 2009 (UTC)
I think, for those values that the {{ val}} template doesn’t work on, that we delimit long numbers with CSS span tags so they have narrow gaps that don’t do line-end wraps and can be copied into Excel without bringing along spaces that have to be deleted. All they need to do is code as follows:
Specification discussion moved to
Wikipedia talk:Manual of Style (dates and numbers)/Specification for 'son of autoformatting'
Lightmouse (
talk) 11:02, 31 January 2009 (UTC)
It just dawned on me that the people opposing the new DA system really don't care about DA per se, since the new system can reproduce all the same behavior as their "plain text" alternative, with one exception — the need to use square brackets [[ ]] (or some kind of special markup) to indicate which dates are actually dates and not a part of some quotation of a date (or otherwise must be handled specially.) No DA system, no template system, no Javascript system — none of them can work without that special markup around dates. And it's ultimately that markup that the opponents of DA are really against. And I don't think they'd deny it (and I suppose I don't need to ask you to correct me if I'm wrong there) although they might not have put it quite that way, or necessarily realized how central an issue that is. The markup represents information added by human editors, making very complex judgments about the context of the string-that-might-be-a-date in the body of text as a whole, and deciding whether it represents an actual date or a quotation (or whatever.) The point is that it's something that a computer program can't easily add (because it requires too much "understanding" of the text) but which countless editors have already added and will presumably continue to add, given the opportunity. Since there's no need to "delink" dates in order to display them to readers minus the actual link (and in any variety of formats and defaults we so choose) it really boils down to those four little brackets: [[ ]] -- Sapphic ( talk) 03:25, 28 January 2009 (UTC)
...actually, there is a way to distinguish between dates (which are reformattable) and quotations of dates (which are not) without having to markup dates — markup the quotations of dates (and any other date-like strings that need to be displayed literally) instead. There are far fewer of those, and they're already special cases so it's more acceptable to have a special syntax. So we have DA work on anything that looks like a date except stuff inside <nowiki> tags, and the default for anons is no autoformatting with no automatic links — i.e. plain text. Editors write dates in plain text (except inside quotations or other special cases where the format itself is part of the content) and see them in the format they're written (or a site-wide default if we want) unless there's a {{DATEFORMAT:XXX}} tag that specifies a per-page format, and users that specify a preference can still see them as links and in their local format. Everybody gets pretty much everything they want, and the only "cost" is having to put <nowiki> tags around quoted (etc.) dates. -- Sapphic ( talk) 05:52, 28 January 2009 (UTC)
:
(colon) prefix to actually make a link). —
Locke Cole •
t •
c 07:04, 28 January 2009 (UTC)Which part of the RFC constitutes consent for mass-taxation of those that don't want the feature? Lightmouse ( talk) 13:31, 28 January 2009 (UTC)
Sapphic, you're underestimating the amount of work that the human brain does in interpreting those strings-that-might-be-dates. Consider the following sentence:
Does it mean:
Or:
Grammatically, it should be the first version (since if 850 is a year and thus part of the prepositional phrase, it should have a comma following it... not even considering the comma required by style guides to make the year parenthetical in MDY format) but is it a grammar mistake or not? Without additional context (which only a human is currently able to provide) there's no way to tell.
By using some kind of markup (we happen to use square brackets because that's how categories and images already work in similar situations, but it could be anything really) we could distinguish more easily:
I'll try to come up with a better example that doesn't depend on the grammar mistake of leaving out the comma, but the point remains the same — it's a non-trivial task to identify where dates begin and end, without some kind of markup on actual dates. Having a markup on non-dates isn't a viable alternative. -- UC_Bill ( talk) 17:41, 28 January 2009 (UTC)
I missed the whole discussion, and apologize if I'm raising issues that have been discussed and dealt with before.
{{some text}}
" typically shows up as "some other text", often not a link, whereas "[[some text]]
" usually displays as the same "some text" and usually is a link.{{January 1, 2000}}
" or "{{1 January 2000}}
".{{[[January 1]], 2000}}
" would link to
January 1, {{January 1, [[2000]]}}" would link to the year
2000, and {{[[January 1, 2000]]}}" would link to the page
January 1, 2000 – but possibly be displayed as "
1 January 2000".88.234.217.196 ( talk) 12:14, 29 January 2009 (UTC)
Above I have given the following two examples of the kind of inconsistent text that date autoformatting will produce:
The discussion was derailed by my introducing an unreleated idea in the same comment. But I would really like to hear from the proponents of date autoformatting:
Thank you. -- Hans Adler ( talk) 13:49, 29 January 2009 (UTC) Edited after Sapphic pointed out there were commas missing. -- Hans Adler ( talk) 15:48, 29 January 2009 (UTC)
I don't see the inconsistency. I see a missing comma in both cases, but it's missing in the text, so that's editor error, not DA error. Written this way:
The sentence will appear to those with MDY as:
...and those with DMY as:
Isn't that correct? Am I missing something about arcane comma rules in DMY that requires there be no comma there, or something? -- Sapphic ( talk) 15:30, 29 January 2009 (UTC)
First off, it's a preference or recommendation that articles about "American" topics be formatted in MDY, not any sort of grammatical requirement. And the only reason it's a preference is because we don't have any better way of guessing what the majority of readers of that article may be expecting. It's a hack, and a bad one at that. American readers (or more accurately, anyone that prefers MDY format) should see all articles in that format, ideally. Similarly, those that prefer DMY should see all articles in that format, regardless of the topic. Since that's not feasible given the way Wikipedia is set up from a cache server standpoint, the next best option is to use the topic of the article as a rough way of guessing at the preferences of the readership.
Secondly, the new DA system handles those cases just fine anyway. Add {{DATEFORMAT:DMY}} or {{DATEFORMAT:MDY}} to an article that MOS or ENGVAR says "should" be in a particular format, and it'll format that way for most users (the exception being registered users who have specifically chosen to override those defaults, which is their prerogative). -- UC_Bill ( talk) 16:30, 29 January 2009 (UTC)
(ec with UC Bill and others) Locke Cole, I agree that this error existed in the date-linking system. Otherwise I am genuinely surprised by your answer. It seems there may have been some miscommunication, perhaps because I missed some points in previous discussions, and I would like to clear that up completely. Is the following a correct description of your vision for date-autoformatting?
Can we agree that it doesn't make much sense to override an article's choice of date format in the first two cases, at least not enough sense to warrant the use of date-autoformatting? Then for the majority of dates in an article (those which don't come from a template) it would seem easiest to just enter them manually, in the correct format.
In a discussion further above, which perhaps we should continue here instead, you said: "No, the purpose of date auto formatting is to make dates more consistent within articles, offer choices to editors (and later, readers) and unlink dates without having bots/scripts needlessly unlinking them by hand (which could take years)." It seems to me that a much more elegant way of making the dates more consistent within an article is to just do it by hand. Sometimes it may not be clear which style is preferred for an article, but this is exactly the same problem as for WP:ENGVAR. If we don't solve that by throwing technology at it, why should we do it for this? What I would certainly support is a standardised comment, or even a new kind of markup, for identifying style preferences of an article. E.g. the first significant author of the article Nuclear submarine could have added the following:
As for date unlinking: I believe this has already been mostly done, and my point is exactly that this kind of markup needs to be removed because it is distracting. There is a lot of semantic markup that could in principle be added to our articles, but we shouldn't do it because it's too distracting. I am sure most of us don't want to have source code like the following:
The reason writing Wiki code is so much easier than writing HTML is that it's so intuitive and much of it is derived from what we naturally do in plain text. Our source code looks very much like the displayed article. If we prescribe writing "[[1 April]]" or something similar to get "1 April", the source code becomes less intuitive for no good reason. And if we allow writing "[[April 1]]" to get "1 April" it becomes even worse.
By the way, do you still maintain the parenthetical "and later, readers"? Do readers have a choice in a meaningful way? How? -- Hans Adler ( talk) 16:36, 29 January 2009 (UTC)
Hans Adler wrote "American readers should see all articles in US spelling and MDY format." Actually, it is much more subtle than this. There are many usage differences between US and UK English that go beyond spelling, for example:
(I hope I got the UK examples correct; it isn't easy for a US-based editor.)
We will always have trouble getting a consistent tone in articles written by an internatioal set of editors, but automated spelling changes will make it worse, not better. -- Gerry Ashton ( talk) 18:10, 29 January 2009 (UTC)
Sorry for the yelling (well, bold all-caps text really) but since this has come up multiple times now, I want to make sure everybody sees it: NOBODY IS CURRENTLY PROPOSING ANY AUTOMATED SPELLING CHANGES, NOR DOES THE NEW DA SYSTEM HAVE THAT AS A FEATURE. -- UC_Bill ( talk) 18:20, 29 January 2009 (UTC)
I am glad that Gerry Ashton is making it clear that he understands my main point, because I was beginning to despair. Am I really hiding it so well? I'll try again using other words: It is unprofessional to mix US English with day-month dates outside certain specific contexts (NATO?), and it is equally unprofessional to mix UK English with month-day dates outside perhaps other specific contexts. As a result, the entire date autoformatting infrastructure, which has been described as "taxation" because it requires all of us to tolerate the additional markup, has only very limited benefit: On an extremely limited number of articles (those that use US English and the date-year format apparently used by the US military) it can be used to choose between two professional looking appearances. Everywhere else it is useless, unless you abuse it to produce unprofessional, inconsistent text such as my two lift/elevator examples above. Do you really want software extensions and markup for every date just in order to accommodate people who want to translate articles into an inconsistent language variant/date format mix? I would like to hear a clear "yes" or "no" to this question from UC Bill and Locke Cole. -- Hans Adler ( talk) 15:20, 30 January 2009 (UTC)
Why do people keep asserting that there is a preferred format for dates in different articles? If US format is appropriate to US articles, and UK for UK, then what date format will you use for an article about Indonesia?
Just (although I am aware of the dangers of the word "just") write a template that accepts all the common date formats.
...et cetera. Regular expressions can cope.
Registered users could set a preferred display format in their preferences. If they didn't, they would see unmodified article text. Unregistered users would also see unmodified text. (Consider this another encouragement to register.) Once a date is templated in this fashion, it would never need to be format-changed again. If the date needs to be linked, the template could take a parameter.
"Impediment to new editors" is sometimes raised as an objection to this sort of thing. Well, all of our markup is an impediment to new users. I remember well the old days when people could create totally unsophisticated and poorly-written stubs, and people would fix them up; I was under the impression that this is how it was supposed to work. Let people write dates in plain English, and bots or AWB users will inevitably do all the templating conversions. No big deal.
A benefit of this approach is that when people export our articles, say for printing or CD-ROM, they will be able to programatically achieve date format consistency across the entire article corpus. — Hex (❝?!❞) 19:09, 29 January 2009 (UTC)
There is currently a discussion about whether or not to enhanced the versatility of the {{ fact}} template here. Since this is of general MOS interest, I'm notifying the MOS people. Headbomb { ταλκ κοντριβς – WP Physics} 17:18, 29 January 2009 (UTC)
(*Sigh*) Let’s tackle this one again. I make frequent use of some special characters to ensure line-end word-wraps look appropriate in all cases. They are the non-breaking hyphen, which has the ISO Latin-1 code ‑
, and the non-breaking space, which has the HTML Entity name
.
Pretty much everyone knows what the non-breaking space is for: you can code Then add a 25 kg sack of
and it will appear as Then add a 25 kg sack of… without worrying that it will do a line-end word wrap, like this:
Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Then add a 25
kg bag of enim ad minim veniam, quis nostrud exerci back-strainuneum.
Similarly, the non-breaking hyphen, ‑
, prevents instances like this:
Lorem ipsum dolor sit amet, consectetuer adipiscing elit. The United States’ F-
22 fighter plane enim ad minim veniam, quis nostrud exerci tation kickbuttotis.
My trouble here is with User:SmackBot. It replaces the code with the rendered characters. The trouble with this is that other editors—even myself—can no longer see where these special characters are being used and copy them for use elsewhere in an article. Worse still, it appears that when some users copy swaths of text for editing in a text editor using various Barbarian OS machines, the special nature of the non-breaking characters is lost when they paste back into the article.
Now, at $100 per terabyte, the server cost of leaving these special characters as their code names is an average of about 6×10−8 ¢ per occurrence. All hundred of these special characters that I might use over a period of several months, still might be a “Greg L overhead” of 6×10−6 ¢. Multiplied by the 1000 or so like-minded editors who might be inclined to do as I do, we’re still talking 6×10−3 ¢. So cost isn’t a factor here; less than a penny.
It would be far easier for other editors—particularly less experienced ones—if they wade into our
F-22 Raptor (for instance), if they can actually see F‑22
nearby and take a hint to copy and paste the thing instead of pounding away on the keyboard. And it would be infinitely easier for the editors who put them there in the first place and are still editing the article.
Don’t get me wrong here. I am all for having bots do cleanup where the rendered character is visually distinctive and identifiable and doesn’t have a visually identical cousin that functions differently. For instance, it is just fine if a bot converts the “Identical to” sign ≡
to the easy-to-distinguish ≡ character (enlarged here for detail). You can see, copy, and paste the rendered character just fine. I’m talking about just a very special, small class of characters, where bots should not be changing the non-breaking space and the non-breaking hyphen to their rendered character because they are indistinguishable from their identical-looking regular-functioning counterparts. Can we obtain a consensus on this?
Greg L (
talk) 03:37, 30 January 2009 (UTC)
{{htmlentity|nbsp}}
would produce a single non-breaking space. —
Locke Cole •
t •
c 04:36, 30 January 2009 (UTC)Like many things on Wikipedia, there is often more than one way to skin a cat. I rather like all the above proposals. I’ve contacted the operator of smackbot. Hopefully, he will tweak it to leave the non-breaking characters alone. Further, I didn’t know about the {{ nbsp}} template (thank you Locke) and would like to see a {{ nbhyph}} version since I can never remember ‑ and have been disinclined to make a macro and assign it to a key on my keyboard. Then editors would be free to use the rendered character, the ISO code, the HTML entity name, or the templates. Greg L ( talk) 05:21, 30 January 2009 (UTC)
{{spaces|N}}
?
Greg L (
talk) 05:34, 30 January 2009 (UTC)
Question: In the Kilogram article referenced above, what is the purpose of the nbsp inside of the nowrap? Is it safe to have my script change those to spaces? I can see a distinction if there are repeated nbsp. Thanks! Plastikspork ( talk) 22:30, 30 January 2009 (UTC)
Maybe the opponents of date linking would be happier with date links to the full date instead of one link to the month-day and another to the year? I'm sure that could be added to the new DA system pretty easily, if it was desirable. I can understand why people consider the month-day links to be "useless trivia" (even if I happen to find them interesting and not trivial at all.. of course I'm also a big fan of "this day in history" calendars and the like) but it's harder to make the argument that the specific full date mentioned in an article isn't relevant to that article's topic. Even if it's something as "trivial" as the publication date of a book, it's still relevant to know what else happened on that particular date, to put things in context. Is this something that should be considered? -- Sapphic ( talk) 23:01, 30 January 2009 (UTC)
In the case of years that are linked, there are times when directing readers to these might make sense in intrinsically historical articles. But even then, a much better way to let readers know of the availability of articles like this is well-aliased or informative entries in See also sections, such as
“•
1775 for a list of other notable events of that year”, or a well-aliased entry titled
• [[1775|Other notable historical events of 1775]]
and which will appear like “•
Other notable historical events of 1775”.
-- Sapphic ( talk) 01:29, 31 January 2009 (UTC)
Tony, please actually read what people write instead of just giving one of your standard rants as a reply. We're specifically talking about links to full dates here, not year-only links. The question is whether links to dates (even ones made intentionally, outside the context of any DA) should usually be to the full date rather than one link to the month-day combination and another to the year. There's a second question as to whether such linking should be the default in any new DA system. We all know your answer to the second question, but you might have some new insight into the first that it would be good to share. -- Sapphic ( talk) 16:45, 31 January 2009 (UTC)
Although I wouldn't support it, it's probably worth considering a third option between using "plain text" dates to effectively bypass autoformatting and replacing the current DA with a new one — removing the current DA code from the MediaWiki software entirely, and not replacing it with anything. That would disable autoformatting instantly, without having to delink any dates at all (though most likely anyone who supported this option would want to delink most of the dates anyway) and it would simplify the syntax for dates that should be linked (they wouldn't need a pipe or colon to be a non-autoformatted link.) -- Sapphic ( talk) 23:06, 30 January 2009 (UTC)
Yes, that is a defect in the current autoformatting. It is important that avoidance of this defect is included in the Specification. Lightmouse ( talk) 11:19, 31 January 2009 (UTC)
You misunderstand what we are saying by error. If an error means a failure to autoformat, then that error must be evident. The trouble with the current system is that errors are not evident. There are currently only two ways to detect broken autoformatting:
There are many ways in which this problem presents itself. Just look at the following four formats:
Autoformatting is 'broken' for three of those formats. It does not autoformat. Ordinary editors don't fix these errors because they aren't aware of them. If you want an autoformatting system, then you need to ensure it works. Lightmouse ( talk) 12:55, 1 February 2009 (UTC)
So maybe the answer to the DA issue really is all tied up with spelling variations and other stuff at ENGVAR in such a way that it makes the most sense to solve them with a single solution. And this disagreement over the markup and how it shouldn't be complicated further with DA and may be too complicated already, etc. has me thinking maybe there's a better way forward: move everything but the simplest formatting syntax (e.g. bullets, headers) into a completely separate parallel copy of the article, which can be used or not depending on the choice of the editor (anon or otherwise.) We're talking a different page entirely here, to mess with all the markup syntax. Editors would write plain text in the normal edit window, using just the most basic wiki syntax possible, probably getting rid of links entirely. Everything more complicated would be made available in a completely different screen that anyone could use (no special treatment for registered users here!) that would allow for all kinds of markup. Keeping the two in sync would be easily automated because the plain text content of each would remain identical, although any plain text added through the "novice" interface would be lacking in markup until some more experienced editor added some in the "advanced" interface (or in some cases be auto-applied, if possible and it makes sense.) Markup of any kind could be added in either interface, but on submit the system will always update both copies of the article in the database anyway, so it's no big deal to strip out any markup from the version that gets saved as the "plain text" version, even if that markup was added in the "novice" interface. -- Sapphic ( talk) 00:19, 31 January 2009 (UTC)
I have a request for data:
Lightmouse ( talk) 11:14, 31 January 2009 (UTC)
How do I talk to Wikimedia sysadmins? Lightmouse ( talk) 03:19, 2 February 2009 (UTC)
I'm not sure I agree with moving it off to a subpage that's not on anyones watchlist, but I won't move it back and urge people to add this subpage to their watchlist. — Locke Cole • t • c 21:06, 31 January 2009 (UTC)
WP burnt its fingers badly in blindly accepting a tech-toy back in 2003. Six years later, we have finally gotten rid of what is now widely regarded as a fault-ridden disaster. If we now sat by passively watching another attempt to introduce an elaborate solution where no one—repeat, no one—can identify the problem (see my two latest pleas on this page), we would have less excuse: as more sophisticated Internet/wiki users, we could not excuse ourselves so easily.
I appreciate the work a few editors seem to be putting into trying to develop another system to shield our precious eyes from corrosion by one or the other month-day/day/month order. However, the community now takes a conservative line on both DA and the linking of chronological items. This much is clear from the RfCs, especially here and here, analyses of the "detailed" RfCs above, and the large body of evidence that has accumulated elsewhere (links supplied on request to anyone who missed the numerous relevant pages).
Gerry and others have already raised the same old dangers that will inevitably accompany a new-fangled experiment that would again wrest from article editors the control and maintenance of date formats by the re-introduction of some kind of tech-bulldozer; it would cause no end of problems for no apparent gain (whether blue-wash or black, underlined or free of underline), and we would be foolish to agree to it.
Witness the circular tap-dance at Bugzilla for three years, trying to move towards a solution to the previous DA mechanism, with diddly-squat progress towards just removing the blue-wash and underlining from the program. These are just two of many problems. I'm not saying "don't program", but why we'd want to expose our project to that kind of disruption quite unnecessarily is beyond my imagination. If a gigantic company such as Microsoft gets so many things wrong with its operating systems and applications (OMG, look at Vista and Word), it points to systemic dangers of programming, in which there is a vanishingly small likelihood that there wouldn't be bugs and bad design. You might do it for Word or LaTeX or OSX—they're essential to many people's lives, and are necessary risks in the commercial world. And those companies employ huge numbers of well-resourced programmers to fix the glitches; they sell to long-suffering consumers who have little choice but to grit their teeth and wait for the design to improve and the bugs to be ironed out with each new wave. By contrast, WP relies on volunteers, and while I appreciate that they're skilled in real-life, expecting the professional dedication over a long period to see us through the inevitable mess is unfair to them, the community, and hundreds of millions of our readers. You wouldn't put yourself through that for fun, or for the kind of satisfaction some people get from doing a crossword puzzle. This crossword puzzle would require pain-killers all-round for an extended period.
May I also point to the fact that WP needs to stay on top of things to retain its privileged ranking on the Internet; there are sharks in the waters, and we must ensure that our wonderful project is not disrupted to this major extent with no clear point. Manually controlled dates are now well-accepted and liked. FAC didn't even blink, and over there, the engine-room of "our very best work", they are probably gobsmacked that this debate is still going on. Tony (talk) 14:51, 24 January 2009 (UTC)
Tony, why the persistent fear-mongering? This is a user-interface enhancement, in line with countless other innovations in technology that allow end users to have some measure of control over their viewing environment. It is being discussed, bugs, flaws, and possible glitches are being weeded out, and the community is fully involved in the development. The developer is eager to assist, and concerns raised in the RfCs and in previous discussions are being addressed. If we were to instead subscribe to the rhetoric in your post ("dangers", "burnt its fingers badly", "inevitable mess" to list but a few) we would never have moved past pen and paper. (How, for example, can you describe a technical feature like date formatting as a "risky experiment" when the entire body of information on this wiki is based on the premise that "anyone can edit"?) Again, if you do not want to use the feature, you can always disable it in your preferences. Meanwhile, those who do value such a feature are free to take advantage of it. -- Ckatz chat spy 20:11, 24 January 2009 (UTC)
For those who vehemently disagree with me on this, please present your *I am so really, really special* license for inspection and then let’s hear your sob story about how developers should make special tools just you can be spared the shock of being exposed to a date written out in your less-than-desired format. Greg L ( talk) 01:29, 26 January 2009 (UTC)
You also ignored the part where I wrote “For those who vehemently disagree with me on this, please present your *I am so really, really special* license for inspection”. Ain’t seen it yet and am baffled why anyone on Wikipedia should lift a finger to make extra effort to code dates just you can be spared the shock of being exposed to a date written out in your less-than-desired format. No sense at all. You know why? Because authoring Wikipedia is about our readership, not editors—or you. Greg L ( talk) 01:55, 26 January 2009 (UTC)
Further, there would be actual harm to doing as you would like. Once editors responsible for article content can no longer see when the default format in our articles are wrong, these problems can’t be fixed. We’ve already had editors come here writing about an “ugly mishmash of date formats” in articles and a bunch of us here were clueless because our date preferences setting was masking our ability to see what I.P. editors see. Unless we are in edit mode, editors—even really really special registered editors such as yourself—should always, always be looking at precisely the same article content everyone else sees. If we can’t agree to do that, then our guidelines for determining article content need fixing. Either that, or editors here need to stop acting like babies who need special treatment that I.P. editors don’t deserve. Forget that. Greg L ( talk) 02:30, 26 January 2009 (UTC)
My "I am special" license is at the end of every comment I post here. Being a registered user makes it possible to store user-specific preferences. That's all the specialness that's required. If we could have IP address or browser-setting-specific defaults for anons, we would. It's not technically feasible, given the way the cache is set up for Wikipedia's servers, and so we're left with a single default for anons. That default is currently "no autoformatting, with automatic linking turned on" on Wikipedia and "DMY unless there's a per-page override, with no automatic links" on the demo system, but it can easily be any way we want. -- Sapphic ( talk) 17:04, 26 January 2009 (UTC)
Greg, note that some of the participants here are using "incivility" as a political tool, by defining it extremely broadly to include anything they don't like and that rises a millimetre out of the bland. That is a slippery slope to attempting to win debates through censoring people who dare to express what to them are unpleasant or inconvenient matters.
The exchanges above are yet more evidence that this is a complicated marsh, exclusive in a number of ways, and of no benefit, except to a small band of WPian editors who've got it into their heads that January 3 and 3 January are from Mars and Venus, respectively. If this excursion into programming cuckoo-land is merely a diversionary hobby for the general amusement of a few people (like a crossword puzzle), sure, just as long as it's never going to be let loose on WP. The result would be an unmitigated disaster. Tony (talk) 12:22, 26 January 2009 (UTC)
If you ask people "would you like xxx", many will answer "yes please". If you ask people for a means of automatically converting 'color' into 'colour', many people would say "yes please". Lightmouse ( talk) 14:47, 26 January 2009 (UTC)
It's not yet clear that the solution is any better than the non-problem that UC Bill is attempting to provide lines of code to. Nobody, but nobody, has demonstrated how one date format (US or International) disadvantages or confuses readers. All this talk about providing autoformatted dates to readers is like 'techies' looking for a problem to solve. If "the community" actually cared about readers, it would probably have decided long ago that the encyclopaedia's interests would be better served by having a single date format, and would have sent bots around to unify them across the whole of WP. This rather anarchistic proliferation of articles in all/any formats is proof that editors have chosen their own, rather than those of the readership when there is a conflict of interests. Ohconfucius ( talk) 16:15, 26 January 2009 (UTC)
Autoformatting is incompatible with date ranges. Users really don't understand what they are doing and produce formats such as '12 January - 17'. That is worse than nothing at all. It is not difficult to create code that will work with date ranges but it is difficult to create code that is easy for users and doesn't require fixing by those of us that don't like broken autoformats. I wonder why complaints about the broken autoformats were rare and efforts to fix broken autoformats were rarer. Lightmouse ( talk) 13:11, 26 January 2009 (UTC)
The RFC section that received roughly equal amounts of support and oppositon was
The ability for the Mediawiki to convert dates into a form either appropriate for the page, or to user-defined preferences, is desirable, and the MediaWiki developers should be encouraged to find a solution that works without the problems of the current date autoformatting system.
This should be understood to mean a system that works for anon readers as well as logged-in readers. Since the proposed replacement for autoformatting presents the same format to all anon readers, and since it works no better for per-page formatting than just writing the dates in the appropriate format to begin with, it really does not satisfy the need expressed by some people in the RFC, and that RFC section should not be cited to support the proposal. -- Gerry Ashton ( talk) 18:37, 26 January 2009 (UTC)
It is clear that most of that modest majority of editors who expressed a desire in the RfC for a date formatting tool thought technology could offer something that gave everyone the same view and would give I.P. readers a date formated per their preference setting (or appropriate to the country from which their I.P. address hails). Alas, no such technology is in the offing. No one in their right mind thought some one would propose tools that give a default that 99.9% of our readership sees and is only to avoid having “distasteful” date formats darken the doorstep of some registered editors on Wikipedia (0.00001% of Wikipedia’s readership). The proponents of this can’t see that there is no support for this half-baked idea and it’s futile.
If they want to continue to do as they’ve long done: tendentiously and endlessly hound us until the cows come home that the RfCs somehow support their absurd proposal, then the solution is simple: a short RfC that clarifies the community consensus on this one issue. There is one, fundamental principle that Jimbo holds dear: the community consensus is always right. To the extent that some editors here would like to misrepresent the community consensus, we simply clarify what it truly is on this absurdity. There is absolutely no point to their claiming that the past RfCs supports their desires; a new RfC will throw cold water all over that notion. Greg L ( talk) 20:31, 26 January 2009 (UTC)
As for a technology that would allow regular I.P. editors (99.9% of our readership) to benefit, and with particular regard to how this technology can, as you say, can come later, well, that’s the key point; let us know when that happens. Until then, drop it please and please stop endlessly repeating the same misinformation that it does work for anon readers. No one believes that because the simple facts prove otherwise. Greg L ( talk) 00:24, 27 January 2009 (UTC)
The original post is full of bizarre nonsense, and seems to be predicated on FUD (i.e. "OMG, OUR SOFTWARE MIGHT HAVE BUGS"). If that's the case, we may as well uninstall MediaWiki. Virtually zero disruption is caused by software bugs, a lot less than, say, somebody posting bizarre uninformed rants. My favourite sentence is, of course, "If a gigantic company such as Microsoft gets so many things wrong with its operating systems and applications (OMG, look at Vista and Word), it points to systemic dangers of programming, in which there is a vanishingly small likelihood that there wouldn't be bugs and bad design." At first, I thought it was a joke.
I'm going to implement a date-formatting parser function for reasons unconnected to this dispute (I want it on my MediaWiki site), which will, of course, be usable on MediaWiki sites next week. — Werdna • talk 03:31, 5 February 2009 (UTC)
This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 115 | ← | Archive 117 | Archive 118 | Archive 119 | Archive 120 | Archive 121 | → | Archive 125 |
Whenever I ask this question, no one addresses it. Do we really think our readers and editors are so inflexible (or moronic) that it matters? Why is that people want to go to such extraordinary lengths to fix something that is not a problem in the first place. The primary purpose of the silly date-autoformatting that was so unwisely adopted by us Internet innocents back in 2003 was to "prevent edit-warring over which date format would be used in an article". We have grown up since then, having developed very workable, well-accepted systems for ENGVAR (article-consistent) and article date-format choice (also article-consistent). There were a few little scraps involving User Pete a while ago over the latter (apparently no longer an issue), but generally speaking, what I see is remarkably little debate over which format to use in which article, let alone tension. The edit-warring thing is a complete non-issue, and WPians seem to accept without a blink the absence of a hi-tech toy to mess with the order of month/day; I note that there's still a residual group of computer programmers that cannot bear to see the demise of a programming toy. Sorry, we don't need it, it's not a problem, thanks. Nor do we need autoformatting for colour/or, traveling/lling et al. English-speakers on the Internet find it all rather easy to read these minor, easily recognisable differences.
I can think of a LOT of better things to do with our time; like helping out at WikiProject Years to bring our year-articles out of the doldrums. Tony (talk) 11:09, 22 January 2009 (UTC)
Mirror. "Disparaging" is your spin-word. The only thing I disparage are claims that the RfC data you are trumpeting are meaningful. Tony (talk) 06:08, 23 January 2009 (UTC)
Articles not closely associated with American topics such as Italy, Austria, Basilica di Saccargia and Kilogram have a pronounced non-American readership. Regardless of the dialect of English used by the editor of that article, we should be thinking foremost about our readers. So in articles on general or European subjects (articles clearly not associated with the U.S.), we would simply use Euro-style dates.
Conversely, for articles on, or closely associated with American topics, such as Spokane River Centennial Trail; Coeur d'Alene, Idaho; American Revolution; and New York Yankees, they have a preponderance of American readers and the date format that is most natural for those readers is the American-style date.
It is an utterly trivial matter to simply use the date format that is most natural for the likely readership. I would propose this simple guideline:
For articles on, or strongly associated with, the following countries and territories: The United States, American Samoa, Guam, Northern Mariana Islands, Puerto Rico, U.S. Virgin Islands, Wake Island, Republic of the Marshall Islands, Federated States of Micronesia, and Republic of Palau; editors should use the U.S.-style date format (“February 2, 2008”), otherwise, editors should use the international date format (“2 February 2008”) in articles.
Picked up an Australian newspaper lately? Tony (talk) 06:12, 23 January 2009 (UTC)
The current autoformat linking system links dates always to the same page, regardless of initial format. So all of the following link the month part to page "January 2":
[[January 2]]
:
January 2[[2 January]]
:
2 January [[2008-01-02]]
:
2008-01-02Any new system to have any use, must have the same behaviour. The current test system does not do this. − Woodstone ( talk) 19:02, 23 January 2009 (UTC)
In the test system I still see [[:January 2]]
linking to "Januari 2" and [[:2 January]]
linking to "2 Januari". Since it is awkward to have an article name starting with a number, the date articles are named like "Januari 2". Even when the format (or source) is in the form "2 Januari", or "2008-01-02", it should still link to "Januari 2". And with the current system, they do. −
Woodstone (
talk) 20:24, 23 January 2009 (UTC)
:
prefixed dates shouldn't also be auto formatted. If someone wants to intentionally format a date a certain way they can override that via pipes. For example:
[[January 1]], [[2009]]
should be unlinked and auto formatted.[[:January 1]], [[2009]]
should be linked and auto formatted.[[January 1|January 1]], [[2009]]
should be linked and not auto formatted.January 1, 2009
should be unlinked and not auto formatted.:
) to imply an intentional link with auto formatting, and a date without a colon to imply a date that's not linked but is auto formatted as well. For cases where you want the link and a specific date format you can do it by hand with the pipe. —
Locke Cole •
t •
c 00:46, 24 January 2009 (UTC)I have finished a demo version of the new Date Autoformatting code, and made it available for public viewing here:
IMPORTANT NOTE REGARDING PRIVACY: I have access to the server logs on the above server, which means that (in theory) I can find out the IP address used to access that website. If you create an account on that wiki for testing (which is encouraged) you should NOT use any personally identifying information such as your real name or your Wikipedia username. Also feel free to connect through whatever proxy you like, to further protect your own identity.
The main page of that demo wiki contains examples in all the major date formats. While viewing the page as an anon user, you will note that all of the links in the first section are in a consistent format (DMY with the month spelled out — so-called "International" format) and are not linked. If you create an account and set your "Date and time" preferences you will notice an option for "Date linking" that can be set to "Do not link dates" (the default) or "Link dates" at your choice. I've tested each combination of date format and linking option myself (and haven't noticed any problems) but I'm only human so please check for any mistakes I may have missed. Additional comments are welcome.
Note that I have not (yet) put any disclaimers regarding ISO formatting, nor have I made a separate set of options for in-article dates versus mediawiki dates (i.e. page last updated, etc.) because although those may be desirable features, they introduce more complications than I'd like to deal with in this first round. The separate preferences in particular may prove problematic, since those are actually implemented by two different PHP functions within the code. That said, I recognize the value of those suggestions and will gladly work to incorporate them at a later date.
I'm not sure how long I'll be keeping the demo site active, since I'll eventually need to take it down once I need that server for some projects related to my actual job :) -- UC_Bill ( talk) 23:38, 22 January 2009 (UTC)
__FORMAT_DATES_MDY__
and __FORMAT_DATES_DMY__
). That should be enough to take this live. Later we can add an option in preferences to link or not link dates. —
Locke Cole •
t •
c 23:50, 22 January 2009 (UTC)I'm actively working on the site, so if it's broken try back later. -- UC_Bill ( talk) 00:16, 23 January 2009 (UTC)
I've added support for a new magic word that allows you to specify a default format on a particular page. For example, you can make a page use MDY format instead of the default DMY by adding this: {{DATEFORMAT:MDY}}
I'm through editing the site for the day, so there won't be any additional changes. Feel free to play around on the demo site and try to break things, and please share any feedback you have here (not on the demo wiki.. it'll be erased once testing is done.) -- UC_Bill ( talk) 01:24, 23 January 2009 (UTC)
[[January 17-22]], [[2008]]
; it should be simple enough to look for the dash), but it's something we should consider before seeing about getting this added. —
Locke Cole •
t •
c 02:02, 23 January 2009 (UTC)(Outdent) I'm sorry Gerry, I misunderstood your point. Different date ranges would be broken with the new DA. But perhaps more importantly, articles that currently have linked dates like [[September 11]], [[2001]] with a clear US emphasis would suddenly appear as 11 September 2001 — which is good in that it gets rid of the bluelink (although in this case I guess the date probably should be linked.. bad example, but you get the idea) but is probably not in the preferred format. On the plus side, the new DA would mean you just add {{DATEFORMAT:MDY}} to the page and all the autoformatted dates would switch to the correct format. But somebody would still need to add it, and until then the format would be "wrong" for anons and "no preference" people. -- Sapphic ( talk) 03:52, 23 January 2009 (UTC)
Tony, overcoming the "bias" is as simple as adding {{DATEFORMAT:MDY}} to any page that needs it. Gerry raises a valid point though, with regards to the editors having no way to have both forced-linking and autoformatting at the same time. (Of course the current DA only "allows" this because it forces all marked-up dates to be linked, but still..) This could be fixed by modifying the date markup syntax slightly, by either making it more similar to either category syntax or image syntax. Image syntax would probably be easier to remember, since it's wordier. For example, image syntax is [[Image:Kentikian-hokmi.png|thumb|Kentikian (right) in her rematch with Nadia Hokmi, December 2007]] (note the "thumb") and the equivalent syntax for a date in the new DA could be [[September 11|link]], [[2001]]. This would take away the ability of editors to have a link to a date with the link text of "link" but that's an utterly trivial restriction and is similar to the inability of editors to have an image with a caption of "thumb" as is currently the case. So in that example, the link would be both autoformatted and linked for everyone, and it uses a syntax that people are already familiar with for images. -- Sapphic ( talk) 15:36, 23 January 2009 (UTC)
This doesn't work. The standard American sentence
translates into British (and Australian)
and the other way around.
Note the comma which appears and disappears before wreaked, (but remains in both sentences before New York). The autoformatter does not handle this correctly or tolerably in either direction. I think this is an irremediable defect, since avoiding it would require the autoformatter to parse the sentence. Septentrionalis PMAnderson 16:26, 23 January 2009 (UTC)
September 11, 2001, wreaked massive destruction is not sound American English. A comma only follows a date if it's part of a subordinate clause, as in On September 11, 2001, massive destruction was wreaked. In other varieties of English, the comma following the subordinate clause is optional if the clause ends with a date (and maybe other times, I only know about the situation with dates). If we always follow a subordinate clause with a comma, then there's no inconsistency. -- UC_Bill ( talk) 17:22, 23 January 2009 (UTC)
I have evidence that it's actually correct usage ( here) which I find to be absurd, since I've never seen anybody write it that way. The page I just referenced claims it's done for "typographical reasons" but doesn't mention anything about it being an American variation. I'll look into it though, to see what the deal is. -- UC_Bill ( talk) 17:33, 23 January 2009 (UTC)
(Edit conflict) And actually upon closer reading, it does mention "International format" which covers the non-American variants. Apparently it's because surrounding the year with commas on either side is supposed to make it set off from the rest. It only applies to full dates as well, according to that page. Anyway, since it does seem to be an official style guideline it's easy enough to support by putting the comma inside the square brackets. I'll update the demo code accordingly. -- UC_Bill ( talk) 17:33, 23 January 2009 (UTC)
Oh! I get why they put the comma there. It's because they're treating the mention of the year as an aside, similar to: Bob Smith, my brother, is tall So the comma before the year is actually doing "double duty" by acting as part of the date format and as a way of indicating that the year is a subclause. I think that's overly confusing (especially since they don't do it for DMY format) but like I said, it's easy enough to support in the new DA code so no worries. -- UC_Bill ( talk) 17:38, 23 January 2009 (UTC)
There's no need for a working proof-reader. The first example could be written "[[April 5]], [[2001,]] was just a working day for the crew" and would be rendered as "April 5, 2001, was just a working day for the crew" in MDY and "5 April 2001 was just a working day for the crew" in DMY. The second example could be written "Early in the morning of [[April 5]], [[2001]], the crew put their boat into the water" and would be rendered as "Early in the morning of April 5, 2001, the crew put their boat into the water" in MDY and "Early in the morning of 5 April 2001, the crew put their boat into the water" in DMY. Very simple. If the comma is supposed to be autoformatted, it goes inside the square brackets. If it's not part of the autoformatting, it goes outside the square brackets. there's no need for proofreading because editors can control how the comma is handled. -- UC_Bill ( talk) 18:03, 23 January 2009 (UTC)
I think maybe I figured out what you were getting at. Did you mean that examples like "The best of times was [[10 September]] [[2001]]; the worst of times began the next day" should be rendered as "The best of times was September 10, 2001; the worst of times began the next day" in MDY and not as "The best of times was September 10,2001,; the worst of times began the next day" as might be the case if the comma was always added after MDY dates? If that's what you were discussing, then rest assured that it works fine on the demo system. Please continue making comments in the new section below, since we're now dealing with an updated version of the software (and this section is way too long). -- UC_Bill ( talk) 21:07, 23 January 2009 (UTC)
As a suggestion, and wherever a specific date is not required, it would be better to use an example date in which the day number is greater than 12. For example, on the demo page, 2009-01-31 would be better as an example than 2009-01-01. In that way, there will never be an example where the resulting day and month can be confused—resulting in a tighter specification. HWV258 01:19, 24 January 2009 (UTC)
The demo code has been updated to deal with the comma issues pointed out above:
IMPORTANT NOTE REGARDING PRIVACY: I have access to the server logs on the above server, which means that (in theory) I can find out the IP address used to access that website. If you create an account on that wiki for testing (which is encouraged) you should NOT use any personally identifying information such as your real name or your Wikipedia username. Also feel free to connect through whatever proxy you like, to further protect your own identity.
I've put some comma-related examples on the main page of the demo site, but haven't exhaustively tested every combination of formats with every combination of preferences, so if you notice any misformatting please share it here. Make sure to include the example wikitext that formats incorrectly, as well as the preference settings you were using. -- UC_Bill ( talk) 19:43, 23 January 2009 (UTC)
The rule exception for comparative quantities has bugged me for a long time. Why does it exist? In my humble view, it serves no purpose other than unnecessarily complicating the writing of sequences of objects. I'm referring to the exception that doesn't allow "32 dogs and five cats" and asks that it be written as "32 dogs and 5 cats". JKBrooks85 ( talk) 00:09, 25 January 2009 (UTC)
Brought to attention by some (good) edits by User:TechControl:
Should MOSNUM be changed? Shreevatsa ( talk) 22:43, 23 January 2009 (UTC)
I object to basing Wikipedia writing guidelines on expensive standards that are not available for free on the Internet. -- Gerry Ashton ( talk) 17:25, 24 January 2009 (UTC)
NIST's Guide for the Use of the International System of Units (SI) (p. 9) shows bit as the symbol for the word bit. It indicates that bit and other information technology units given in ISO 31, its successor ISO/IEC 80000-1—ISO/IEC 80000-15, and IEC 60027 parts 1 through 4 may be used with SI units. -- Gerry Ashton ( talk) 20:14, 24 January 2009 (UTC)
NIST is only US related, IEEE is international.
5.1.3 Units from International Standards There are a few highly specialized units that are given by ... ISO or ... IEC and which in the view of this Guide are also acceptable for use with the SI. They include the octave, phon, and sone, and units used in information technology, including the baud (Bd), bit (bit), erlang (E), hartley (Hart), and shannon (Sh)3. It is the position of this Guide that the only such additional units NIST authors may use with the SI are those given in either the International Standards on quantities and units of ISO (Ref. [4]) or of IEC (Ref. [5]).
Ref 4 = ISO 31, Ref 5 = IEC 60027. But Bit#Obsolete_definitions says IEC is obsolete. Can we stop referring to these obsolete standards? TechControl ( talk) 21:16, 24 January 2009 (UTC)
Shall we have Wikipedia:Manual of Style (dates and numbers)/Proposal on bit symbol ? We now already have two bit symbol threads in this page and lot of talk about date formatting floating around. TechControl ( talk) 21:32, 24 January 2009 (UTC)
It doesn’t matter what all these standard bodies say. To minimize confusion and communicate clearly, Wikipedia should follow the practices observed in current, most-reliable literature on the subject. If we wanted to follow what the BIPM says, we’d put a space before a percent symbol,like At least 99 % of readers ignore the BIPM and follow real-world practices, rather than what everyone actually writes: At least 99% of readers ignore the BIPM and follow real-world practices. And MOSNUM, here, follows the real-world practice with respect to the percent symbol and ignores the BIPM on this issue (*sound of audience gasp*).
We have got to stop acting like Talk:MOSNUM is a venue where the Mr. Spock in us all can glom onto each and every cool proposal that comes along and make Wikipedia ready to join the United Federation of Planets. If we did that, only about 2 centiuno of our readership would understand what is written here.
It’s simple: Editors should simply look towards current literature on the subject; each and every issue doesn’t have to come here for discussion and debate about “what’s the best way to do something in a utopian world.” We follow the proposals of standard bodies only after they are widely followed in the real world. Always. Greg L ( talk) 01:07, 26 January 2009 (UTC)
Actually we do write KiB (follow the link). This is standard writing. And so is b for bit. I quote ISO/IEC 80000:
International standard ISO 80000 or IEC 80000 (depending on which of the two international standards bodies International Organization for Standardization and International Electrotechnical Commission is in charge of each respective part), successor of ISO 31 and partially of IEC 60027, is the most widely respected style guide for the use of physical quantities and units of measurement, and formulas involving them, in scientific and educational documents worldwide. In most countries, the notations used in mathematics and science textbooks at schools and universities follow closely the guidelines given by these standard.
Another thing I found: The chairman of IEC TC 25, Anders J. Thor, has pointed out that there are four systems of writing that bridge all linguistic barriers regardless of the alphabet used. These systems are:
The fundamental importance of ISO/IEC 80000 is obvious because the first three systems will be given in this standard. It is only music that will be outside the scope of the future ISO/IEC 80000.
Source: http://www.iec.ch/zone/si/si_present.htm
To declare bit to be the symbol for bit will not help in education, it will prevent spreading good knowledge.(Strike, because not clear what IEC says!) New: IMO WP should help spreading good knowledge and not an average of magazines and computer ads.
TechControl (
talk) 13:47, 26 January 2009 (UTC)
When used to express a storage capacity or an equivalent binary storage capacity, the bit and the octet (or byte) may be combined with SI prefixes or prefixes for binary multiples. In English, the name byte, symbol B, is used as a synonym for octet. Here byte means an eight-bit byte. However, byte has been used for numbers of bits other than eight. To avoid the risk of confusion, it is strongly recommended that the name byte and the symbol B be used only for eight-bit bytes. The symbol B for byte is not international and should not be confused with the symbol B for bel.
The demo code has been updated to deal with various issues discussed above:
Changes in this version:
I changed the default for anon users in this version because that seemed to be what people wanted when I first started making updates.. but in the meantime it seems that popular opinion is swinging back the other way, and people may want anons to have a DMY default so they see a consistent format. I'll leave it as "no autoformatting" for now, but it can be switched to whatever we want, once we've had a look at all the options. Similarly for the "date linking" and "per-page overrides" options, which can be set however we like for anons.
I'll work on autoformatting for date ranges next, as well as whatever other bugfixes people point out in this version. I'll also make the source code available soon, but given the four other now-obsolete patches I submitted for this project already, I'd rather just wait until it's pretty much done and submit the final version. -- UC_Bill ( talk) 21:04, 26 January 2009 (UTC)
I've set the default for anons to "DMY, per-page overrides allowed, no automatic links" on the demo site. The benefit to anons is that they will see a consistent format, specifiable on a per-page basis (or defaulting to DMY if no per-page format is set) and regardless of how the dates appear in the raw wikitext. That last point means that there would be no need to police the pages to enforce consistency, so if an editor adds a (marked-up) date to a page in a different format than what the format "should" be for that page, it will be automatically corrected. -- UC_Bill ( talk) 23:54, 26 January 2009 (UTC)
What you have Bill, is a technical solution in search of a problem to fix. Sparing a handful of registered editors the shock of having to look at a date format that our regular I.P. editors see (99.9% of our readership), is not a legitimate problem worth fixing. It’s a waste of time. We should all simply look at what our I.P. users look at. If we can’t bear to face the shear terror of that (seeing what everyone else see), then there’s something wrong with the rules for determining the date format to use in our articles and should improve those rules and have respect for them. Greg L ( talk) 00:30, 27 January 2009 (UTC)
Autoformatting is mass medication. Everybody is being forced to take a complicated cure even if they don't have the disease. Who benefits from all the editing burden? Answer: only a few. Autoformatting is frequently broken, it is inherent in all the systems proposed. All the systems proposed require effort on the part of those that can live without it. If you want to spend your own money that is fine by me, but once you propose supporting your system by a tax on all of us, you need a better reason than "some voters say they want it". Lightmouse ( talk) 01:51, 27 January 2009 (UTC)
Your tactics here are childish and tedious (like renaming my ANI against you from “Disruption by Locke Cole ” to “Trouble with new RFC at MOSNUM ”. In the ANI over your little stunt, you pulled out your boilerplate rant of [Greg was] incivil to me, personally attack me. It is tedious and no one bought into it. There, Seicer fairly warned you [4] and [5] that you can't accept the fact that the community has voiced its opinion, that you are disrupt[ing] Wikipedia to make a point, and that persisting as you have could land you with additional blocks. I suggest you take his advise. Greg L ( talk) 03:37, 27 January 2009 (UTC)
The point of course is that the status is not "RESOLVED" (and never was during the time of the
RfC). I hope it is obvious to everyone that a "patch" is not ready to implemented until it is finished, and the continuing discussion (73 posts at the Bugzilla
site) clearly indicates that it was not finished (and still isn't). During the three-year debate at Bugzilla, the status was changed to "RESOLVED" four times and I see no evidence of anything having been "committed to the MediaWiki code". The main point being that nothing can be committed to MediaWiki while the bug is still unresolved. Thanks for pointing that out with the link in your previous post—it conclusively proves that the patch is not ready (and certainly wasn't ready at the time the misleading comment was placed at the head of the RfC). Here are the relevant posts to the RfC:
And unfortunately for the RfC, that's how the tainting statement remained. The problem with all the above can be seen by looking at the timeline at the bug's activity log. On 2008-10-24 10:35:45, the status of the bug was changed from "RESOLVED" to "REOPENED", and the resolution of "FIXED" was removed. The status of the bug has remained in "REOPENED" ever since (and therefore throughout the period of the edits detailed above). I sincerely hope that it is now beyond doubt that, at the time of the wording of the RfC, no release-ready patch was available for use by the WP community. I now humbly request the results of the RfC (containing the statement "Mediawiki's software developers have created a patch to correct problems with the current method of date auto-formatting") be nullified. HWV258 22:36, 27 January 2009 (UTC)
The demo code has been updated to deal with various issues discussed above:
The biggest change in this version is the addition of autoformatting for date ranges. A feature summary (and comparison with the old DA and the option of using plain text dates) is as follows:
Feature | Current DA | New DA | Plain text |
---|---|---|---|
Dates are not linked by default | No | Yes | Yes |
Consistent date format for anons | No | Yes | Manual |
Per-page default formats for dates | No | Yes | Manual |
Registered users can pick a date format | Yes | Yes | No |
Registered users can turn autoformatting off | Yes | Yes | Always off |
Registered users can turn date linking on | Always on | Yes | No |
Registered users can turn date linking off | No | Yes | Always off |
Date ranges handled correctly | No | Yes | Manual |
Parenthetical years in MDY handled correctly | No | Yes | Manual |
The benefit to registered users of the new DA over plain text can be seen in the two options that plain text doesn't support. The benefit to anon users is that there is no need for manual enforcement to keep formats consistent — with the new DA, an anon user would never see an article in an inconsistent format (unless of course such inconsistencies were intentionally introduced by using piped links, as might be the case with dates like September 11, 2001 appearing in an article otherwise using the DMY format). That benefit would be delivered to all anon users the moment the new DA was installed onto Wikipedia, without any additional effort required on the part of editors. Similarly, adding the {{DATEFORMAT:MDY}} magic word to an article would guarantee that from that point forward, all autoformatted dates in the article would always be in the correct format. Changes to a page's format could be made by changing the magic word, without having to edit each and every date on the page. -- UC_Bill ( talk) 20:22, 27 January 2009 (UTC)
More importantly, editors with modest experience at editing, who can recognize an inappropriate date format that doesn’t fit with the others, can easily correct fixed-text dates without any understanding whatsoever of magic words; with 47,390,762 editors on en.Wikipedia, there is an army of them out there with this moderate level of experience. I suggest we harness that immense power of the larger Wikipedian community and not make things more complex with a magic word that would make any programmer proud. It’s hard enough just to get novice editors to put a non-breaking space before a unit symbol.
Finally—and most important of all, really—is there seems to be a developing community consensus now that it is a disadvantage, not an advantage, to have registered editors looking at article content that is different from what everyone else sees. I know I can handle seeing some articles with dates that look like “July 4, 1776” (American Independence) and still other articles that are formated like “17 January 1793” (Louis XVI of France condemned to death). I don’t mind it at all. The above RfC makes it clear that the community consensus feels this way too.
It’s not a big deal. Not worth the effort. More than that, it’s better if we don’t even head down this path of giving registered editors a special view of article content that no one else can see. Greg L ( talk) 21:56, 27 January 2009 (UTC)
Further, you stated that you disagreed with my claim that there seems to be a developing community consensus now that it is a disadvantage, not an advantage, to have registered editors looking at article content that is different from what everyone else sees and then attempted to buttress your point by extolling the virtues of autoformatting. Let’s parse that sentence: the ‘subject’ is “community consensus”, not “different view of article content” and the wisdom of same. What you see as the virtues of default tags for articles, magic words, and autoformatting that gives registered editors a special view of article content has nothing whatsoever with what what community consensus is on this matter. That is the only thing that matters and the community consensus seems to be developing here that they think it is best when registered editors see what everyone else sees.
I can see there is no point to you and I further trying to debate this issue. We will have to agree to disagree. Goodbye. Greg L ( talk) 22:46, 27 January 2009 (UTC)
I think this is probably the least confusing syntax, because it mirrors the way category syntax works. However, I'm not sure whether "marked" dates should be written as [[:January 30]], [[2009]] or [[:January 30]], [[:2009]] or whether both should be allowed. I could see the second being used to "mark" a link for both the month-day and the year, while the first would only "mark" the month-day and leave the year unlinked (except for registered users who chose the "more links" setting). I'm not sure if giving editors the ability to enable autoformatting on the full date but only link for the month-day is worth the extra syntax. I'm also not sure what others think about using category-like syntax for this, since some people (Sapphic) have suggested using image-like syntax instead. Thoughts? -- UC_Bill ( talk) 23:50, 27 January 2009 (UTC)
I think, for those values that the {{ val}} template doesn’t work on, that we delimit long numbers with CSS span tags so they have narrow gaps that don’t do line-end wraps and can be copied into Excel without bringing along spaces that have to be deleted. All they need to do is code as follows:
Specification discussion moved to
Wikipedia talk:Manual of Style (dates and numbers)/Specification for 'son of autoformatting'
Lightmouse (
talk) 11:02, 31 January 2009 (UTC)
It just dawned on me that the people opposing the new DA system really don't care about DA per se, since the new system can reproduce all the same behavior as their "plain text" alternative, with one exception — the need to use square brackets [[ ]] (or some kind of special markup) to indicate which dates are actually dates and not a part of some quotation of a date (or otherwise must be handled specially.) No DA system, no template system, no Javascript system — none of them can work without that special markup around dates. And it's ultimately that markup that the opponents of DA are really against. And I don't think they'd deny it (and I suppose I don't need to ask you to correct me if I'm wrong there) although they might not have put it quite that way, or necessarily realized how central an issue that is. The markup represents information added by human editors, making very complex judgments about the context of the string-that-might-be-a-date in the body of text as a whole, and deciding whether it represents an actual date or a quotation (or whatever.) The point is that it's something that a computer program can't easily add (because it requires too much "understanding" of the text) but which countless editors have already added and will presumably continue to add, given the opportunity. Since there's no need to "delink" dates in order to display them to readers minus the actual link (and in any variety of formats and defaults we so choose) it really boils down to those four little brackets: [[ ]] -- Sapphic ( talk) 03:25, 28 January 2009 (UTC)
...actually, there is a way to distinguish between dates (which are reformattable) and quotations of dates (which are not) without having to markup dates — markup the quotations of dates (and any other date-like strings that need to be displayed literally) instead. There are far fewer of those, and they're already special cases so it's more acceptable to have a special syntax. So we have DA work on anything that looks like a date except stuff inside <nowiki> tags, and the default for anons is no autoformatting with no automatic links — i.e. plain text. Editors write dates in plain text (except inside quotations or other special cases where the format itself is part of the content) and see them in the format they're written (or a site-wide default if we want) unless there's a {{DATEFORMAT:XXX}} tag that specifies a per-page format, and users that specify a preference can still see them as links and in their local format. Everybody gets pretty much everything they want, and the only "cost" is having to put <nowiki> tags around quoted (etc.) dates. -- Sapphic ( talk) 05:52, 28 January 2009 (UTC)
:
(colon) prefix to actually make a link). —
Locke Cole •
t •
c 07:04, 28 January 2009 (UTC)Which part of the RFC constitutes consent for mass-taxation of those that don't want the feature? Lightmouse ( talk) 13:31, 28 January 2009 (UTC)
Sapphic, you're underestimating the amount of work that the human brain does in interpreting those strings-that-might-be-dates. Consider the following sentence:
Does it mean:
Or:
Grammatically, it should be the first version (since if 850 is a year and thus part of the prepositional phrase, it should have a comma following it... not even considering the comma required by style guides to make the year parenthetical in MDY format) but is it a grammar mistake or not? Without additional context (which only a human is currently able to provide) there's no way to tell.
By using some kind of markup (we happen to use square brackets because that's how categories and images already work in similar situations, but it could be anything really) we could distinguish more easily:
I'll try to come up with a better example that doesn't depend on the grammar mistake of leaving out the comma, but the point remains the same — it's a non-trivial task to identify where dates begin and end, without some kind of markup on actual dates. Having a markup on non-dates isn't a viable alternative. -- UC_Bill ( talk) 17:41, 28 January 2009 (UTC)
I missed the whole discussion, and apologize if I'm raising issues that have been discussed and dealt with before.
{{some text}}
" typically shows up as "some other text", often not a link, whereas "[[some text]]
" usually displays as the same "some text" and usually is a link.{{January 1, 2000}}
" or "{{1 January 2000}}
".{{[[January 1]], 2000}}
" would link to
January 1, {{January 1, [[2000]]}}" would link to the year
2000, and {{[[January 1, 2000]]}}" would link to the page
January 1, 2000 – but possibly be displayed as "
1 January 2000".88.234.217.196 ( talk) 12:14, 29 January 2009 (UTC)
Above I have given the following two examples of the kind of inconsistent text that date autoformatting will produce:
The discussion was derailed by my introducing an unreleated idea in the same comment. But I would really like to hear from the proponents of date autoformatting:
Thank you. -- Hans Adler ( talk) 13:49, 29 January 2009 (UTC) Edited after Sapphic pointed out there were commas missing. -- Hans Adler ( talk) 15:48, 29 January 2009 (UTC)
I don't see the inconsistency. I see a missing comma in both cases, but it's missing in the text, so that's editor error, not DA error. Written this way:
The sentence will appear to those with MDY as:
...and those with DMY as:
Isn't that correct? Am I missing something about arcane comma rules in DMY that requires there be no comma there, or something? -- Sapphic ( talk) 15:30, 29 January 2009 (UTC)
First off, it's a preference or recommendation that articles about "American" topics be formatted in MDY, not any sort of grammatical requirement. And the only reason it's a preference is because we don't have any better way of guessing what the majority of readers of that article may be expecting. It's a hack, and a bad one at that. American readers (or more accurately, anyone that prefers MDY format) should see all articles in that format, ideally. Similarly, those that prefer DMY should see all articles in that format, regardless of the topic. Since that's not feasible given the way Wikipedia is set up from a cache server standpoint, the next best option is to use the topic of the article as a rough way of guessing at the preferences of the readership.
Secondly, the new DA system handles those cases just fine anyway. Add {{DATEFORMAT:DMY}} or {{DATEFORMAT:MDY}} to an article that MOS or ENGVAR says "should" be in a particular format, and it'll format that way for most users (the exception being registered users who have specifically chosen to override those defaults, which is their prerogative). -- UC_Bill ( talk) 16:30, 29 January 2009 (UTC)
(ec with UC Bill and others) Locke Cole, I agree that this error existed in the date-linking system. Otherwise I am genuinely surprised by your answer. It seems there may have been some miscommunication, perhaps because I missed some points in previous discussions, and I would like to clear that up completely. Is the following a correct description of your vision for date-autoformatting?
Can we agree that it doesn't make much sense to override an article's choice of date format in the first two cases, at least not enough sense to warrant the use of date-autoformatting? Then for the majority of dates in an article (those which don't come from a template) it would seem easiest to just enter them manually, in the correct format.
In a discussion further above, which perhaps we should continue here instead, you said: "No, the purpose of date auto formatting is to make dates more consistent within articles, offer choices to editors (and later, readers) and unlink dates without having bots/scripts needlessly unlinking them by hand (which could take years)." It seems to me that a much more elegant way of making the dates more consistent within an article is to just do it by hand. Sometimes it may not be clear which style is preferred for an article, but this is exactly the same problem as for WP:ENGVAR. If we don't solve that by throwing technology at it, why should we do it for this? What I would certainly support is a standardised comment, or even a new kind of markup, for identifying style preferences of an article. E.g. the first significant author of the article Nuclear submarine could have added the following:
As for date unlinking: I believe this has already been mostly done, and my point is exactly that this kind of markup needs to be removed because it is distracting. There is a lot of semantic markup that could in principle be added to our articles, but we shouldn't do it because it's too distracting. I am sure most of us don't want to have source code like the following:
The reason writing Wiki code is so much easier than writing HTML is that it's so intuitive and much of it is derived from what we naturally do in plain text. Our source code looks very much like the displayed article. If we prescribe writing "[[1 April]]" or something similar to get "1 April", the source code becomes less intuitive for no good reason. And if we allow writing "[[April 1]]" to get "1 April" it becomes even worse.
By the way, do you still maintain the parenthetical "and later, readers"? Do readers have a choice in a meaningful way? How? -- Hans Adler ( talk) 16:36, 29 January 2009 (UTC)
Hans Adler wrote "American readers should see all articles in US spelling and MDY format." Actually, it is much more subtle than this. There are many usage differences between US and UK English that go beyond spelling, for example:
(I hope I got the UK examples correct; it isn't easy for a US-based editor.)
We will always have trouble getting a consistent tone in articles written by an internatioal set of editors, but automated spelling changes will make it worse, not better. -- Gerry Ashton ( talk) 18:10, 29 January 2009 (UTC)
Sorry for the yelling (well, bold all-caps text really) but since this has come up multiple times now, I want to make sure everybody sees it: NOBODY IS CURRENTLY PROPOSING ANY AUTOMATED SPELLING CHANGES, NOR DOES THE NEW DA SYSTEM HAVE THAT AS A FEATURE. -- UC_Bill ( talk) 18:20, 29 January 2009 (UTC)
I am glad that Gerry Ashton is making it clear that he understands my main point, because I was beginning to despair. Am I really hiding it so well? I'll try again using other words: It is unprofessional to mix US English with day-month dates outside certain specific contexts (NATO?), and it is equally unprofessional to mix UK English with month-day dates outside perhaps other specific contexts. As a result, the entire date autoformatting infrastructure, which has been described as "taxation" because it requires all of us to tolerate the additional markup, has only very limited benefit: On an extremely limited number of articles (those that use US English and the date-year format apparently used by the US military) it can be used to choose between two professional looking appearances. Everywhere else it is useless, unless you abuse it to produce unprofessional, inconsistent text such as my two lift/elevator examples above. Do you really want software extensions and markup for every date just in order to accommodate people who want to translate articles into an inconsistent language variant/date format mix? I would like to hear a clear "yes" or "no" to this question from UC Bill and Locke Cole. -- Hans Adler ( talk) 15:20, 30 January 2009 (UTC)
Why do people keep asserting that there is a preferred format for dates in different articles? If US format is appropriate to US articles, and UK for UK, then what date format will you use for an article about Indonesia?
Just (although I am aware of the dangers of the word "just") write a template that accepts all the common date formats.
...et cetera. Regular expressions can cope.
Registered users could set a preferred display format in their preferences. If they didn't, they would see unmodified article text. Unregistered users would also see unmodified text. (Consider this another encouragement to register.) Once a date is templated in this fashion, it would never need to be format-changed again. If the date needs to be linked, the template could take a parameter.
"Impediment to new editors" is sometimes raised as an objection to this sort of thing. Well, all of our markup is an impediment to new users. I remember well the old days when people could create totally unsophisticated and poorly-written stubs, and people would fix them up; I was under the impression that this is how it was supposed to work. Let people write dates in plain English, and bots or AWB users will inevitably do all the templating conversions. No big deal.
A benefit of this approach is that when people export our articles, say for printing or CD-ROM, they will be able to programatically achieve date format consistency across the entire article corpus. — Hex (❝?!❞) 19:09, 29 January 2009 (UTC)
There is currently a discussion about whether or not to enhanced the versatility of the {{ fact}} template here. Since this is of general MOS interest, I'm notifying the MOS people. Headbomb { ταλκ κοντριβς – WP Physics} 17:18, 29 January 2009 (UTC)
(*Sigh*) Let’s tackle this one again. I make frequent use of some special characters to ensure line-end word-wraps look appropriate in all cases. They are the non-breaking hyphen, which has the ISO Latin-1 code ‑
, and the non-breaking space, which has the HTML Entity name
.
Pretty much everyone knows what the non-breaking space is for: you can code Then add a 25 kg sack of
and it will appear as Then add a 25 kg sack of… without worrying that it will do a line-end word wrap, like this:
Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Then add a 25
kg bag of enim ad minim veniam, quis nostrud exerci back-strainuneum.
Similarly, the non-breaking hyphen, ‑
, prevents instances like this:
Lorem ipsum dolor sit amet, consectetuer adipiscing elit. The United States’ F-
22 fighter plane enim ad minim veniam, quis nostrud exerci tation kickbuttotis.
My trouble here is with User:SmackBot. It replaces the code with the rendered characters. The trouble with this is that other editors—even myself—can no longer see where these special characters are being used and copy them for use elsewhere in an article. Worse still, it appears that when some users copy swaths of text for editing in a text editor using various Barbarian OS machines, the special nature of the non-breaking characters is lost when they paste back into the article.
Now, at $100 per terabyte, the server cost of leaving these special characters as their code names is an average of about 6×10−8 ¢ per occurrence. All hundred of these special characters that I might use over a period of several months, still might be a “Greg L overhead” of 6×10−6 ¢. Multiplied by the 1000 or so like-minded editors who might be inclined to do as I do, we’re still talking 6×10−3 ¢. So cost isn’t a factor here; less than a penny.
It would be far easier for other editors—particularly less experienced ones—if they wade into our
F-22 Raptor (for instance), if they can actually see F‑22
nearby and take a hint to copy and paste the thing instead of pounding away on the keyboard. And it would be infinitely easier for the editors who put them there in the first place and are still editing the article.
Don’t get me wrong here. I am all for having bots do cleanup where the rendered character is visually distinctive and identifiable and doesn’t have a visually identical cousin that functions differently. For instance, it is just fine if a bot converts the “Identical to” sign ≡
to the easy-to-distinguish ≡ character (enlarged here for detail). You can see, copy, and paste the rendered character just fine. I’m talking about just a very special, small class of characters, where bots should not be changing the non-breaking space and the non-breaking hyphen to their rendered character because they are indistinguishable from their identical-looking regular-functioning counterparts. Can we obtain a consensus on this?
Greg L (
talk) 03:37, 30 January 2009 (UTC)
{{htmlentity|nbsp}}
would produce a single non-breaking space. —
Locke Cole •
t •
c 04:36, 30 January 2009 (UTC)Like many things on Wikipedia, there is often more than one way to skin a cat. I rather like all the above proposals. I’ve contacted the operator of smackbot. Hopefully, he will tweak it to leave the non-breaking characters alone. Further, I didn’t know about the {{ nbsp}} template (thank you Locke) and would like to see a {{ nbhyph}} version since I can never remember ‑ and have been disinclined to make a macro and assign it to a key on my keyboard. Then editors would be free to use the rendered character, the ISO code, the HTML entity name, or the templates. Greg L ( talk) 05:21, 30 January 2009 (UTC)
{{spaces|N}}
?
Greg L (
talk) 05:34, 30 January 2009 (UTC)
Question: In the Kilogram article referenced above, what is the purpose of the nbsp inside of the nowrap? Is it safe to have my script change those to spaces? I can see a distinction if there are repeated nbsp. Thanks! Plastikspork ( talk) 22:30, 30 January 2009 (UTC)
Maybe the opponents of date linking would be happier with date links to the full date instead of one link to the month-day and another to the year? I'm sure that could be added to the new DA system pretty easily, if it was desirable. I can understand why people consider the month-day links to be "useless trivia" (even if I happen to find them interesting and not trivial at all.. of course I'm also a big fan of "this day in history" calendars and the like) but it's harder to make the argument that the specific full date mentioned in an article isn't relevant to that article's topic. Even if it's something as "trivial" as the publication date of a book, it's still relevant to know what else happened on that particular date, to put things in context. Is this something that should be considered? -- Sapphic ( talk) 23:01, 30 January 2009 (UTC)
In the case of years that are linked, there are times when directing readers to these might make sense in intrinsically historical articles. But even then, a much better way to let readers know of the availability of articles like this is well-aliased or informative entries in See also sections, such as
“•
1775 for a list of other notable events of that year”, or a well-aliased entry titled
• [[1775|Other notable historical events of 1775]]
and which will appear like “•
Other notable historical events of 1775”.
-- Sapphic ( talk) 01:29, 31 January 2009 (UTC)
Tony, please actually read what people write instead of just giving one of your standard rants as a reply. We're specifically talking about links to full dates here, not year-only links. The question is whether links to dates (even ones made intentionally, outside the context of any DA) should usually be to the full date rather than one link to the month-day combination and another to the year. There's a second question as to whether such linking should be the default in any new DA system. We all know your answer to the second question, but you might have some new insight into the first that it would be good to share. -- Sapphic ( talk) 16:45, 31 January 2009 (UTC)
Although I wouldn't support it, it's probably worth considering a third option between using "plain text" dates to effectively bypass autoformatting and replacing the current DA with a new one — removing the current DA code from the MediaWiki software entirely, and not replacing it with anything. That would disable autoformatting instantly, without having to delink any dates at all (though most likely anyone who supported this option would want to delink most of the dates anyway) and it would simplify the syntax for dates that should be linked (they wouldn't need a pipe or colon to be a non-autoformatted link.) -- Sapphic ( talk) 23:06, 30 January 2009 (UTC)
Yes, that is a defect in the current autoformatting. It is important that avoidance of this defect is included in the Specification. Lightmouse ( talk) 11:19, 31 January 2009 (UTC)
You misunderstand what we are saying by error. If an error means a failure to autoformat, then that error must be evident. The trouble with the current system is that errors are not evident. There are currently only two ways to detect broken autoformatting:
There are many ways in which this problem presents itself. Just look at the following four formats:
Autoformatting is 'broken' for three of those formats. It does not autoformat. Ordinary editors don't fix these errors because they aren't aware of them. If you want an autoformatting system, then you need to ensure it works. Lightmouse ( talk) 12:55, 1 February 2009 (UTC)
So maybe the answer to the DA issue really is all tied up with spelling variations and other stuff at ENGVAR in such a way that it makes the most sense to solve them with a single solution. And this disagreement over the markup and how it shouldn't be complicated further with DA and may be too complicated already, etc. has me thinking maybe there's a better way forward: move everything but the simplest formatting syntax (e.g. bullets, headers) into a completely separate parallel copy of the article, which can be used or not depending on the choice of the editor (anon or otherwise.) We're talking a different page entirely here, to mess with all the markup syntax. Editors would write plain text in the normal edit window, using just the most basic wiki syntax possible, probably getting rid of links entirely. Everything more complicated would be made available in a completely different screen that anyone could use (no special treatment for registered users here!) that would allow for all kinds of markup. Keeping the two in sync would be easily automated because the plain text content of each would remain identical, although any plain text added through the "novice" interface would be lacking in markup until some more experienced editor added some in the "advanced" interface (or in some cases be auto-applied, if possible and it makes sense.) Markup of any kind could be added in either interface, but on submit the system will always update both copies of the article in the database anyway, so it's no big deal to strip out any markup from the version that gets saved as the "plain text" version, even if that markup was added in the "novice" interface. -- Sapphic ( talk) 00:19, 31 January 2009 (UTC)
I have a request for data:
Lightmouse ( talk) 11:14, 31 January 2009 (UTC)
How do I talk to Wikimedia sysadmins? Lightmouse ( talk) 03:19, 2 February 2009 (UTC)
I'm not sure I agree with moving it off to a subpage that's not on anyones watchlist, but I won't move it back and urge people to add this subpage to their watchlist. — Locke Cole • t • c 21:06, 31 January 2009 (UTC)
WP burnt its fingers badly in blindly accepting a tech-toy back in 2003. Six years later, we have finally gotten rid of what is now widely regarded as a fault-ridden disaster. If we now sat by passively watching another attempt to introduce an elaborate solution where no one—repeat, no one—can identify the problem (see my two latest pleas on this page), we would have less excuse: as more sophisticated Internet/wiki users, we could not excuse ourselves so easily.
I appreciate the work a few editors seem to be putting into trying to develop another system to shield our precious eyes from corrosion by one or the other month-day/day/month order. However, the community now takes a conservative line on both DA and the linking of chronological items. This much is clear from the RfCs, especially here and here, analyses of the "detailed" RfCs above, and the large body of evidence that has accumulated elsewhere (links supplied on request to anyone who missed the numerous relevant pages).
Gerry and others have already raised the same old dangers that will inevitably accompany a new-fangled experiment that would again wrest from article editors the control and maintenance of date formats by the re-introduction of some kind of tech-bulldozer; it would cause no end of problems for no apparent gain (whether blue-wash or black, underlined or free of underline), and we would be foolish to agree to it.
Witness the circular tap-dance at Bugzilla for three years, trying to move towards a solution to the previous DA mechanism, with diddly-squat progress towards just removing the blue-wash and underlining from the program. These are just two of many problems. I'm not saying "don't program", but why we'd want to expose our project to that kind of disruption quite unnecessarily is beyond my imagination. If a gigantic company such as Microsoft gets so many things wrong with its operating systems and applications (OMG, look at Vista and Word), it points to systemic dangers of programming, in which there is a vanishingly small likelihood that there wouldn't be bugs and bad design. You might do it for Word or LaTeX or OSX—they're essential to many people's lives, and are necessary risks in the commercial world. And those companies employ huge numbers of well-resourced programmers to fix the glitches; they sell to long-suffering consumers who have little choice but to grit their teeth and wait for the design to improve and the bugs to be ironed out with each new wave. By contrast, WP relies on volunteers, and while I appreciate that they're skilled in real-life, expecting the professional dedication over a long period to see us through the inevitable mess is unfair to them, the community, and hundreds of millions of our readers. You wouldn't put yourself through that for fun, or for the kind of satisfaction some people get from doing a crossword puzzle. This crossword puzzle would require pain-killers all-round for an extended period.
May I also point to the fact that WP needs to stay on top of things to retain its privileged ranking on the Internet; there are sharks in the waters, and we must ensure that our wonderful project is not disrupted to this major extent with no clear point. Manually controlled dates are now well-accepted and liked. FAC didn't even blink, and over there, the engine-room of "our very best work", they are probably gobsmacked that this debate is still going on. Tony (talk) 14:51, 24 January 2009 (UTC)
Tony, why the persistent fear-mongering? This is a user-interface enhancement, in line with countless other innovations in technology that allow end users to have some measure of control over their viewing environment. It is being discussed, bugs, flaws, and possible glitches are being weeded out, and the community is fully involved in the development. The developer is eager to assist, and concerns raised in the RfCs and in previous discussions are being addressed. If we were to instead subscribe to the rhetoric in your post ("dangers", "burnt its fingers badly", "inevitable mess" to list but a few) we would never have moved past pen and paper. (How, for example, can you describe a technical feature like date formatting as a "risky experiment" when the entire body of information on this wiki is based on the premise that "anyone can edit"?) Again, if you do not want to use the feature, you can always disable it in your preferences. Meanwhile, those who do value such a feature are free to take advantage of it. -- Ckatz chat spy 20:11, 24 January 2009 (UTC)
For those who vehemently disagree with me on this, please present your *I am so really, really special* license for inspection and then let’s hear your sob story about how developers should make special tools just you can be spared the shock of being exposed to a date written out in your less-than-desired format. Greg L ( talk) 01:29, 26 January 2009 (UTC)
You also ignored the part where I wrote “For those who vehemently disagree with me on this, please present your *I am so really, really special* license for inspection”. Ain’t seen it yet and am baffled why anyone on Wikipedia should lift a finger to make extra effort to code dates just you can be spared the shock of being exposed to a date written out in your less-than-desired format. No sense at all. You know why? Because authoring Wikipedia is about our readership, not editors—or you. Greg L ( talk) 01:55, 26 January 2009 (UTC)
Further, there would be actual harm to doing as you would like. Once editors responsible for article content can no longer see when the default format in our articles are wrong, these problems can’t be fixed. We’ve already had editors come here writing about an “ugly mishmash of date formats” in articles and a bunch of us here were clueless because our date preferences setting was masking our ability to see what I.P. editors see. Unless we are in edit mode, editors—even really really special registered editors such as yourself—should always, always be looking at precisely the same article content everyone else sees. If we can’t agree to do that, then our guidelines for determining article content need fixing. Either that, or editors here need to stop acting like babies who need special treatment that I.P. editors don’t deserve. Forget that. Greg L ( talk) 02:30, 26 January 2009 (UTC)
My "I am special" license is at the end of every comment I post here. Being a registered user makes it possible to store user-specific preferences. That's all the specialness that's required. If we could have IP address or browser-setting-specific defaults for anons, we would. It's not technically feasible, given the way the cache is set up for Wikipedia's servers, and so we're left with a single default for anons. That default is currently "no autoformatting, with automatic linking turned on" on Wikipedia and "DMY unless there's a per-page override, with no automatic links" on the demo system, but it can easily be any way we want. -- Sapphic ( talk) 17:04, 26 January 2009 (UTC)
Greg, note that some of the participants here are using "incivility" as a political tool, by defining it extremely broadly to include anything they don't like and that rises a millimetre out of the bland. That is a slippery slope to attempting to win debates through censoring people who dare to express what to them are unpleasant or inconvenient matters.
The exchanges above are yet more evidence that this is a complicated marsh, exclusive in a number of ways, and of no benefit, except to a small band of WPian editors who've got it into their heads that January 3 and 3 January are from Mars and Venus, respectively. If this excursion into programming cuckoo-land is merely a diversionary hobby for the general amusement of a few people (like a crossword puzzle), sure, just as long as it's never going to be let loose on WP. The result would be an unmitigated disaster. Tony (talk) 12:22, 26 January 2009 (UTC)
If you ask people "would you like xxx", many will answer "yes please". If you ask people for a means of automatically converting 'color' into 'colour', many people would say "yes please". Lightmouse ( talk) 14:47, 26 January 2009 (UTC)
It's not yet clear that the solution is any better than the non-problem that UC Bill is attempting to provide lines of code to. Nobody, but nobody, has demonstrated how one date format (US or International) disadvantages or confuses readers. All this talk about providing autoformatted dates to readers is like 'techies' looking for a problem to solve. If "the community" actually cared about readers, it would probably have decided long ago that the encyclopaedia's interests would be better served by having a single date format, and would have sent bots around to unify them across the whole of WP. This rather anarchistic proliferation of articles in all/any formats is proof that editors have chosen their own, rather than those of the readership when there is a conflict of interests. Ohconfucius ( talk) 16:15, 26 January 2009 (UTC)
Autoformatting is incompatible with date ranges. Users really don't understand what they are doing and produce formats such as '12 January - 17'. That is worse than nothing at all. It is not difficult to create code that will work with date ranges but it is difficult to create code that is easy for users and doesn't require fixing by those of us that don't like broken autoformats. I wonder why complaints about the broken autoformats were rare and efforts to fix broken autoformats were rarer. Lightmouse ( talk) 13:11, 26 January 2009 (UTC)
The RFC section that received roughly equal amounts of support and oppositon was
The ability for the Mediawiki to convert dates into a form either appropriate for the page, or to user-defined preferences, is desirable, and the MediaWiki developers should be encouraged to find a solution that works without the problems of the current date autoformatting system.
This should be understood to mean a system that works for anon readers as well as logged-in readers. Since the proposed replacement for autoformatting presents the same format to all anon readers, and since it works no better for per-page formatting than just writing the dates in the appropriate format to begin with, it really does not satisfy the need expressed by some people in the RFC, and that RFC section should not be cited to support the proposal. -- Gerry Ashton ( talk) 18:37, 26 January 2009 (UTC)
It is clear that most of that modest majority of editors who expressed a desire in the RfC for a date formatting tool thought technology could offer something that gave everyone the same view and would give I.P. readers a date formated per their preference setting (or appropriate to the country from which their I.P. address hails). Alas, no such technology is in the offing. No one in their right mind thought some one would propose tools that give a default that 99.9% of our readership sees and is only to avoid having “distasteful” date formats darken the doorstep of some registered editors on Wikipedia (0.00001% of Wikipedia’s readership). The proponents of this can’t see that there is no support for this half-baked idea and it’s futile.
If they want to continue to do as they’ve long done: tendentiously and endlessly hound us until the cows come home that the RfCs somehow support their absurd proposal, then the solution is simple: a short RfC that clarifies the community consensus on this one issue. There is one, fundamental principle that Jimbo holds dear: the community consensus is always right. To the extent that some editors here would like to misrepresent the community consensus, we simply clarify what it truly is on this absurdity. There is absolutely no point to their claiming that the past RfCs supports their desires; a new RfC will throw cold water all over that notion. Greg L ( talk) 20:31, 26 January 2009 (UTC)
As for a technology that would allow regular I.P. editors (99.9% of our readership) to benefit, and with particular regard to how this technology can, as you say, can come later, well, that’s the key point; let us know when that happens. Until then, drop it please and please stop endlessly repeating the same misinformation that it does work for anon readers. No one believes that because the simple facts prove otherwise. Greg L ( talk) 00:24, 27 January 2009 (UTC)
The original post is full of bizarre nonsense, and seems to be predicated on FUD (i.e. "OMG, OUR SOFTWARE MIGHT HAVE BUGS"). If that's the case, we may as well uninstall MediaWiki. Virtually zero disruption is caused by software bugs, a lot less than, say, somebody posting bizarre uninformed rants. My favourite sentence is, of course, "If a gigantic company such as Microsoft gets so many things wrong with its operating systems and applications (OMG, look at Vista and Word), it points to systemic dangers of programming, in which there is a vanishingly small likelihood that there wouldn't be bugs and bad design." At first, I thought it was a joke.
I'm going to implement a date-formatting parser function for reasons unconnected to this dispute (I want it on my MediaWiki site), which will, of course, be usable on MediaWiki sites next week. — Werdna • talk 03:31, 5 February 2009 (UTC)