Page MenuHomePhabricator

Provide preference-based autoformatting for unlinked dates
Closed, ResolvedPublic

Assigned To
Authored By
bzimport
Jan 12 2006, 9:20 PM
Referenced Files
F2575: patch.txt
Nov 21 2014, 9:03 PM
F2574: diff.txt
Nov 21 2014, 9:02 PM
F2573: diff.txt
Nov 21 2014, 9:02 PM
F2572: diff.txt
Nov 21 2014, 9:02 PM

Description

Author: Siegel

Description:
As recently discussed on the EN village pump (proposals), please create syntax for
marking dates to be rendered subject to date preferences that does not overload the
[[]] link syntax, adn does not create a link. This could help avoid the perrenial
debate on overlinking of dates
User:DESiegel


Version: unspecified
Severity: enhancement
URL: http://en.wikipedia.org/wiki/Wikipedia_talk:Date_debate

Details

Reference
bz4582

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

A little note.

While we are discussing ways to display different formats the world moves on, in particular the US does. Whilst the majority of US usage seems still to be month-first - "April 10" - the proportion of day first - "10 April" - is increasing, or so I read in a well-known on-line encyclopaedia. The US military use day-first, and the US courts to some extent (I know not how extensively). For this reason I feel that tying date format to reader locale is dubious at best (as is referring to the date format as "US"). If, however, it were possible to know the system date format it might be more apposite.

billclark wrote:

(In reply to comment #194)

I feel that tying date format to reader locale is dubious at best
(as is referring to the date format as "US"). If, however, it were
possible to know the system date format it might be more apposite.

There might be ways of getting such information using Javascript, but it would be very platform-dependent and is bordering on invasion of privacy issues, since it's not information that's normally transmitted with web requests (as opposed to the Accept-Language, which is.)

I'm also not sure if it's really worth the trouble. Remember, using Accept-Language is just a ''guess'' at the date format the reader expects, just as using "strong national ties" for the article subject was simply a ''guess'' at the majority readership (and thus an even worse guess as to the expected date format.) As long as the majority of readers that have "en-US" set as their Accept-Language expect "Month Day, Year" format, then we're fine in using that as the default for those users (and FAR better off than we are now.)

The best solution for format issues is for a reader to register and set a format preference themselves. The only problem with that currently is that setting that preference then hides inconsistencies in format from the editor who sets a preference -- but if there were no inconsistencies in format (because we use some reasonably default instead of "no default") then that would no longer be an issue, and we could then ''encourage'' people to set a date format preference.

Also, just as an aside, I happen to greatly prefer dates in "big-endian" format (i.e. YYYY-MM-DD format, which I DO NOT consider to be ISO, despite what Wikipedia labels it) and find that format both easier to read and more logical. I'm mentioning this mostly because a lot of people here and on Wikipedia seem to take it as a given that big-endian format is "unreadable" and that nobody wants it. I'm also far from alone, since a LOT of programmer-types prefer that format (mostly because alphanumeric sort order then corresponds to chronological order) so we shouldn't make too many assumptions about the popularity of various date formats and how it relates to the depth of feeling that people have on the matter.

-Bill Clark

s.r.e.turner wrote:

(In reply to comment #195)

Also, just as an aside, I happen to greatly prefer dates in "big-endian" format
(i.e. YYYY-MM-DD format, which I DO NOT consider to be ISO, despite what
Wikipedia labels it) and find that format both easier to read and more logical.
I'm mentioning this mostly because a lot of people here and on Wikipedia seem
to take it as a given that big-endian format is "unreadable" and that nobody
wants it.

I think the "given" is a weaker one: that it shouldn't be presented to users who haven't explicitly chosen that format, certainly in normal prose. So, given the current code, no-one should write "the Second World War started on [[1939-09-03]]", because unregistered and new users will see the date in that format: worse, regular users won't even realise that that's what most people are seeing.

(In reply to comment #196)

(In reply to comment #195)
I think the "given" is a weaker one: that it shouldn't be presented to users
who haven't explicitly chosen that format, certainly in normal prose...

I think that the YYYY-MM-DD format shouldn't be presented
to readers who haven't explicitly chosen that format (in normal
prose), and further, the readers should be explicitly warned
at the time of making the choice
that dates in that format do not conform to ISO 8601, and
that they are a simple substitition and reordering of the date
that was originally written by the editor who wrote it, without
consideration of what calender it might be in. This would
require a change to the preference menu where the format
is selected.

I also think there should be different preference choices for
articles vs. system information, because I'd like to see
system information (e.g. the items in my watch list) in
the YYYY-MM-DD format but I don't want to see it in articles.

cyp wrote:

Returning to the subject at hand...

Assuming that there is any interest in preserving the potentially valuable markup, there are only two issues that /need/ to be taken care of *RIGHT NOW*.

  1. The seas of blue,
  2. the YYYY-MM-DDs.

These are the two basic issues addressed by MOSNUM's deprecation of date linking.

  • The first issue requires merely requires standard [[date]] syntax to not be a link.
  • The second issue merely requires dates to be converted for anons too.

If/When/How an alternate date-formatting markup is implemented does not have anything to do with [[date]] syntax and accordingly is not a solution for the "seas of blue". The "seas of blue" problem has to be resolved one way or another, and given that we already have bots and users running around stripping dates of their markup, the "seas of blue" problem has to have priority over everything else.

The 'accept-language' method is -- _for_the_moment_ -- sufficient to guess what an anon's preferred date format might be. All the other preference detection is non-crucial "nice-to-have" stuff that neither affects a majority of the readership, nor will it be "missed" since it wasn't there to begin with. And all of the other preference detection depends on whether wikis will provide something that can be detected to begin with. It is accordingly pointless to discuss it here and now. Nice-to-have thingies should be filed elsewhere as "Requests for enhancement" after discussion at the village pumps. It was precisely this sort of brainless "exception ABC needs solution XYZ" narcissism that led to there being no sensible default for anons.

A patch is available, and although incomplete because it doesn't resolve the default-for-anons problem, it is a first step, and imminently commit-able. The fatal problem then is that devs with commit privileges don't care to commit it. AND THEY WON'T as long as people bicker about _future_enhancements_ as if such features would solve the bugs. The only thing that these requests-for-enhancement do is indicate that a solution is not in sight.

If there is no interest in preserving the potentially valuable markup, then there is no need to discuss /anything/ date-formatting related. The [[date]]s will vanish eventually, and MOSNUM has deprecated any further markup. So this bug report will eventually become obsolete, and with it all the blocking requests-for-enhancements. The stalling over added functionality allows date-formatting to destroy itself.

If Bill Clark would upload a patch that does what his [[:]] patch theoretically did, then the REASON FOR THIS BUG REPORT is solved. This bug could then be reassigned to Tim (or another dev) and marked _FIXED_. MOSNUM's other technical issue is the date-format for anons, and if this patch could infer a sensible default then that problem would be solved too. Aside from these two issues there is nothing else that "must" be taken care of _now_.

billclark wrote:

(In reply to comment #198)

If Bill Clark would upload a patch that does what his [[:]] patch theoretically
did, then the REASON FOR THIS BUG REPORT is solved. This bug could then be
reassigned to Tim (or another dev) and marked _FIXED_. MOSNUM's other technical
issue is the date-format for anons, and if this patch could infer a sensible
default then that problem would be solved too. Aside from these two issues
there is nothing else that "must" be taken care of _now_.

Good point.

This is a busy week for me at my real life job, but I can probably rework the patch by the weekend. The only complicated part (I think) is tying it in with the cache stuff, since I think the anon default would need to be worked into the user preferences so the cache checking code knows which version of the page to retrieve. At least, I ''think'' that's how the cache code works (one pre-processed version of the page is cached for each user preference option) but I'll poke through the code to be sure, when I get some time. I may be able to do at least that much today.

It may actually be simpler (and less efficient) than that, if it's not tied into the cache checking code, in which case I'll be able to provide an updated patch within the next few days.

-Bill Clark

cyp wrote:

(In reply to comment #199)

It may actually be simpler (and less efficient) than that, if it's not tied
into the cache checking code, in which case I'll be able to provide an updated
patch within the next few days.

DateFormatter is indeed not tied to the cache. Which is why there is lots of room to making it more efficient ;)

There is only one version in the cache, and links (of all kinds) are not pre-processed into <A>s. This expansion occurs in the very last stage of wiki->html conversion, and needs to be done post-cache so that links are sensitive to state (user and dependencies). I.e., a user's [[Special:]] links at the top-right of each page need to be correct, redlinks/purplelinks/bluelinks state needs to be marked up with the appropriate css classes, and so on.

billclark wrote:

unlinks dates, preserves markup, uses Accept-Language for defaults (or DMY)

Attached:

billclark wrote:

I've uploaded a modified version of my second patch.

It uses the current date markup ([[ ]]) and will reformat dates according to user preferences, but WITHOUT making them into links. Dates that should be linked can use the [[:]] format and they will be linked and left in their raw format (same as now.) Users with "No preference" or anon users will either see marked-up dates in MDY format (if the string "en-US" appears in the "Accept-Language" header sent by their browser) or DMY format (aka "International format") otherwise.

billclark wrote:

(In reply to comment #202)

Users with "No preference" or anon users

Hmm.. it just occurred to me that maybe these two should be handled differently? The most recent patch will basically force all properly marked-up dates to appear in a consistent format for all users. But perhaps logged-in users who have specified "No preference" might actually want to see the (possibly inconsistent) raw format, for some reason?

It's currently recommended practice to have "No preference", because anon users see dates in raw format.. but since (with this patch) anon users will see either MDY or DMY format consistently, should "No preference" users see the same thing as anons, or should "No preference" continue to mean "raw" format?

s.r.e.turner wrote:

Doesn't "no preference" really mean that the new editor hasn't found the preferences page yet? In which case, I think they should be treated the same as anons.

There could alternatively be another option to distinguish the two cases: "guess from my locale" (default) vs "no transformation". (Better names needed!).

cyp wrote:

Well done Bill (technical observation/suggestion follows by e-mail)

Apropos 'Accept-Language' for "No preference" or anon users: The rationale behind currently recommended practice to have "No preference" is to see dates as anons see them. Since anons are now going to see something other than YYY-MM-DD, then having "No preference" should do the same.

Stephen's "no transformation" is a good idea for an /additional/ option, but getting that added to the prefs page is going to be another ball of wax altogether. Bill could of course preempt that addition by adding that functionality to DateFormatter now, but I think it would be a bit premature to change the list of 'const'ants right now.

cyp wrote:

Bill, I'm not sure if this matters, but there is a discrepancy in the dates of the version that you are diff'ing against.

Your diff is against some version from October 23
The version on svn (revision 36353) is dated June 16

Concerning whether a logged in user with no preferences should see what an
anonymous reader sees, or should see an untransformed date, making no
preferences equal the same as anonymous reader removes function, and
makes it impossible to see untransformed dates. Function should not
be removed, especially because a significant number of editors would
rather see harmony between the style of the article and the style of the
dates, rather than one fixed choice.

Further, the present preference selection menu is inadequate, and for
best chance of acceptance of this change, it should be changed as
follows:

-An explicit warning that dates presented in the format that looks
like ISO 8601 do not always conform to that standard

-Replace "No preference" with two items, "Default" and "No transformation"

-Separate the choice for the realm where the date autoformatting presently
occurs (articles, talk pages, Wikipedia space, user pages, help pages, etc.)
with the choice for system messages (such as what appears on watchlists
and history pages). This would provide the advantage that system messages
in the YYYY-MM-DD format include seconds, while other formats do not, so
separating the choices would allow people to see seconds in system messages
and at the same time article dates that include spelled-out months. (Not
that people usually want to see seconds, but it may be useful on occasion.)

MediaWiki wrote:

I would like to second Jerry's suggestions from c207, with a question about ISO 8601 dates. As I understand it, the issue arises with dates in the Julian calendar. Since dates on talk pages, system messages, and such shouldn't be anything but Gregorian, would the "explicit warning" only apply to the option for content-namespace dates?

I agree with Voyagerfan5761 that system generated times, which will neither have problems with being in a non-Gregorian calendar, nor have a problem with years greater than 9999, will conform to ISO 8601. It might be more expedient to just say dates in that format don't conform to the standard, rather than trying to explain when the standard is obeyed and when it isn't. People will understand 21st century dates even if we make no claim about conforming to the standard.

cyp wrote:

In response to Comment #207, Comment #208, Comment #209:

"making no preferences equal the same as anonymous reader removes function".

What function?
Doing nothing (not doing anything) is not a function. Consequently,
doing anything (not doing nothing) isn't a loss of function.

"impossible to see untransformed dates"

The purpose of linking dates is to see them transformed. There is no purpose to linking dates that are not to be transformed.
The condition is reversable; the condition that makes them transformable can be removed to make them untransformable. Therein lies the solution for "impossible to see untransformed dates".
Also, it seems that date transformation no longer occurs in previews, so there you go.

An explicit warning that dates presented in the format that looks like ISO 8601 do not always conform to that standard

This is not the right place to complain about the perceived abuse of the term "ISO". Regardless of the potential for abuse, the term "ISO" is a handy moniker for "YYYY-MM-DD". Come up with something else and then go preach it with the world (after solving some more concrete crises perhaps). Dateformatter doesn't care what you call it. Dateformater does not have fireside chats, leave alone chit-chat about cerebral abstractions.

Julian calendar

DateFormatter does not care a hoot about the validity of a date or what calendar is being followed. For all it cares, there are a bazillion months in the year, 99 days in every month, and every 42 years is a leap year. Accordingly, February 92 is just as (in)valid as February 29. Garbage in, garbage out. This approach has not been a problem in the past, and there is no point to making it a problem now.

Replace "No preference" with two items, "Default" and "No transformation"

Adding a new date pref option is far beyond the scope of this bug report. Its not even DateFormatter's business to generate the prefs page. It also has ramifications far beyond DateFormatter. If you want such changes, you need to file another bug report.

smccandlish wrote:

The most recent patch will basically force all properly marked-up

dates to appear in a consistent format for all users. But perhaps logged-in
users who have specified "No preference" might actually want to see the
(possibly inconsistent) raw format, for some reason?

Logged-in "no preference" users should continue to see the raw format, if possible, as this helps us to identify inconsistencies and fix them (inconsistencies of that level of geekiness are probably only going to be noticed during featured article reviews, but still). We also need to keep in mind that WP content can be repurposed in multiple ways, including database dump and import into other wikis that may have different settings (i.e., might not be doing autoformatting tricks), so ultimately consistency is non-trivial.

The rationale

behind currently recommended practice to have "No preference" is to see dates
as anons see them. Since anons are now going to see something other than
YYY-MM-DD, then having "No preference" should do the same.

Not really. Some have stated it that way, but it is a misstatement. The rationale is actually to *see what is really there* so that consistency problems are easy to spot and resolve. Before this patch, that happened to equate to seeing what anons see, but the relationship is one of coincidental correlation, not causation.

There could alternatively be another option to distinguish the two cases:

"guess from my locale" (default) vs "no transformation". (Better names
needed!).

That compromise works for me, other than I would reverse the default. If someone has an account, they are most probably an editor, and (MOS collectively feels, anyway) that they *should* be seeing the real deal, for the reasons given above.

Function should not

be removed, especially because a significant number of editors would
rather see harmony between the style of the article and the style of the
dates, rather than one fixed choice.

That, too. And this is another reason to add the new choice, and invert the suggested "guess" default.

Therein lies the solution for "impossible

to see untransformed dates".

Cypsy, I don't think you grokked the argument that was being made; I think I may have explained it better here. The really short version is: When I (logged in) go to an article on, say, a thoroughly American topic, like [[Rudoloph Wanderone, Jr.]], and see an int'l.-formatted date, as an editor I know immediately that this article has at least one inconsistency in it and needs proofreading (and being an active and compulsive editor, I will be very likely to do that proofread and cleanup).

Further, the present preference selection menu is inadequate, and for

best chance of acceptance of this change, it should be changed [...]

I tend to agree, but reiterate cypsy's logical (if forceful) comment that *this is not what this bug report is about*; that's a new feature request. Even some of what we're talking about here technically consists of new feature requests but can arguably be included here because without that "cleanup" the simpler changes that would resolve this bug in theory wouldn't do so in spirit or in functional practice. But this does not apply, that I can see, to these add'l. feature requests. KISS principle, then: Only do what we have to, to resolve this bug, then open a new feature request ticket for expanded date formatting options (and warnings, and so forth).

All that said, I agree with everything else so far. The [[:]] trick will do what MOS needs, and the HTTP headers trick will also solve the YYYY-MM-DD problem for anons. Huzzah!

s.r.e.turner wrote:

(In reply to comment #211)

The rationale
behind currently recommended practice to have "No preference" is to see dates
as anons see them. Since anons are now going to see something other than
YYY-MM-DD, then having "No preference" should do the same.

Not really. Some have stated it that way, but it is a misstatement. The
rationale is actually to *see what is really there* so that consistency
problems are easy to spot and resolve. Before this patch, that happened to
equate to seeing what anons see, but the relationship is one of coincidental
correlation, not causation.

I tend to agree with the grandparent post not the parent post here. The most important reason for an editor to see the raw dates is because that's what most readers see. If most readers no longer see that, the reason is removed. Maybe there are other reasons -- such as worrying about reuses that don't do date formatting -- but they seem minor to me, and I'm far more concerned about editors who've never gone into their preferences page and chosen their favourite settings. As a geek, I usually do that straight away in a new program, but as a software author I've discovered that lots of people don't. My main worry is people who create an account, and suddenly all the dates -- which worked when they were an anon -- go wrong.

cyp wrote:

Cypsy, I don't think you grokked the argument that was being made;

The really short version is: When I (logged in) go to an article on,
say, a thoroughly American topic, like [[Rudoloph Wanderone, Jr.]],
and see an int'l.-formatted date, as an editor I know immediately
that this article has at least one inconsistency in it and needs
proofreading

Let me reiterate to see if I understand it right this time:

An editor-with-"no preference"-pref (i.e. no transform) visits an article with a strong US tie. That being a "US article", the raw wiki dates should all have been written as [[M d, Y]] already and will so appear in that form for editor-with-"no preference"-pref. But an inconsistency, say, a [[YYYY-MM-DD]] date, will stick out.

Is that correct? If so, does it make any difference if raw wiki dates were not already [[M d, Y]]? After all, the output -- regardless of how the raw wiki dates are written -- would still be uniform, right?

As I understand it, the consistency/national ties issue is moot when all dates in an article are linked. A visitor to [[Rudolf Wanderone]] with intl pref (or defaulting to intl pref) will see all linked dates as intl dates, no matter how these are formatted in the raw text.
Similarly, a visitor with US pref (or defaulting to US pref) will see all linked dates as US dates, no matter how these are formatted in the raw text.
Since the output will always match the pref/autopref of the visitor, it wouldn't really matter anymore how dates in the raw wiki text are formatted. Right?

Secondly, normalizing the dates to an internally consistent format must be a truly onerous task.
Surely this can be automated?

billclark wrote:

(In reply to comment #213)

Since the output will always match the pref/autopref of the visitor, it
wouldn't really matter anymore how dates in the raw wiki text are formatted.
Right?

It wouldn't matter for WP, but as others have pointed out, it could matter for mirror sites and for people downloading database dumps.

Secondly, normalizing the dates to an internally consistent format must be a
truly onerous task.
Surely this can be automated?

It can only be automated if the dates are marked-up. It's significantly more difficult to identify dates that aren't surrounded by markup (mostly because of variations of date ''ranges'' that contain substrings that look like stand-alone dates) but that's not the worst part. The worst part is that there's no way for a script to know if a non-marked-up date string is within a ''quotation'' and should thus NOT be normalized, because there is no consistent way of identifying quotations (some articles use quote marks or templates, but some just indent the text or change the size/style or make it italic.)

So yes, it's possible to automatically correct dates that are marked up with [[ ]] (or any other syntax) but any dates that have already been de-linked (or were never linked in the first place) will need to be checked manually, to make sure they're not within a quotation.

-Bill Clark

If "no preferences" is to be reinterpreted as "format according to my browser language setting" and the preference menu is to remain untouched, this bug should be rejected. It is not acceptable to prevent signed in users to indicate they wish to see marked-up dates as they were entered in the article (with the sole exception of inserting a comma between the day and month in a case like [[January 1]] [[2008]], due to the historical behavior of date autoformatting.

smccandlish wrote:

If "no preferences" is to be reinterpreted as "format according to my browser

language setting" and the preference menu is to remain untouched

That's what I've been arguing against. Editors SHOULD see the date as it is entered, unless they elected to see a specific date format, otherwise they are not aware of article inconsistencies.

this bug should be rejected.

No need to be hyperbolic.

It is not acceptable to prevent signed in users to indicate

they wish to see marked-up dates as they were entered in the article

Right. But if we just make that the default behavior, there's no need for further alteration of the prefs menu.

If people do insist on browser lang. settings being the default, then, yes, that menu will need changing, but only in that case, unless I'm misunderstanding something.

cyp wrote:

Ok, assuming that Bill will return to old "no preferences" behavior for logged-in users, is the patch acceptable to everyone?

s.r.e.turner wrote:

(In reply to comment #217)

Ok, assuming that Bill will return to old "no preferences" behavior for
logged-in users, is the patch acceptable to everyone?

I wouldn't veto it, even if I had such a thing as a veto! But I do still have some worries about the case I raised in comment #212:

My
main worry is people who create an account, and suddenly all the dates -- which
worked when they were an anon -- go wrong.

Is there anything we can do to address that?

cyp wrote:

(In reply to comment #218)

My
main worry is people who create an account, and suddenly all the dates -- which
worked when they were an anon -- go wrong.

Is there anything we can do to address that?

Not if the logged-in default is "no transform" (the alternative is to disable autodates for anons, which I don't think anyone considers an "option").

Since we back on that subject ([*sigh* deeply here])...

Since the output will always match the pref/autopref of the visitor, it
wouldn't really matter anymore how dates in the raw wiki text are formatted.
Right?

It wouldn't matter for WP, but as others have pointed out, it could matter for
mirror sites and for people downloading database dumps.

ok, lets automate that then (see next point). Given (what must be) thousands of pages with inconsistent date formatting, this should be handled by bot even if the logged-in default is "no transform".

Secondly, normalizing the dates to an internally consistent format must be a
truly onerous task. Surely this can be automated?

It can only be automated if the dates are marked-up.

Um. Those are the only kind of dates under discussion. If they weren't marked up, they would not be subject to transformation. When they are not subject to transformation, they are also not influenced by whether the logged-in default was "no transform" or "from locale".

See Bug 16337 that points to a discussion article and proposal on Meta, for a new very versatile ParserFunction whose style will adopt the syntax of ParserFunctions, and of template parameters (it may look like an extension of template parameters, except that they are modifiable and don't have to be necessarily passed on template invokation (because the block of context variables is passed implicitly).

The discussion on Meta relates existing problems on Multilingual projects like Commons and Wiktionary (or even Meta itself). It can be used to manage multiple sort keys in Wiktionary, instead of just a single default one (the alternative being to pass extra values as parameters to all subtemplates used in a page within some context of use, like the current language code, and the current sort key for that language, to use during categorization of pages using utility templates like the grammatical type templates, or translation templates on Wiktionary.

[[Meta:GlobalContextVariables_Extension]]

catlow wrote:

Can I vote against this bug? There are so many useful things developers could be doing to improve the software, I don't see any reason to be wasting time on such a pointless issue. No-one needs dates to be formatted in a particular way - it's a non-problem. If text is to be presented to readers in different ways depending on some option or IP range, then start with different spellings like color/colour, or synonyms like football/soccer. However we don't do that, and we don't do metadata either - just let editors write dates as they want them to appear, linked or unlinked according to principles decided by their particular project, and everyone (once they've got over the recent changes in appearance) will be happy. (Kotniski from en.WP)

Note that the way Wikimedia's caching works, anons will only be able to see one style of date links without significantly reducing the effectiveness of caching. Wikimedia uses a [[Squid cache]], which means that for anonymous users, the process to get a page from the server works something like:

  1. Is the page in the cache? a. If so, and the cache hasn't expired, return the cached version b. Otherwise, continue
  2. Start up MediaWiki to get the page a. Is the page in the parser cache? If so, return that version b. If not, get the text from the database and reparse

For anon users to have multiple options for date formatting, the number of cache misses would likely rise significantly, especially at first, and the size of the cache could potentially be multiplied by the number of formatting options.

billclark wrote:

(In reply to comment #222)

Note that the way Wikimedia's caching works, anons will only be able
to see one style of date links without significantly reducing the
effectiveness of caching.

Yep. That's pretty much a show-stopper, too. At best we'd be able to "fool" the squid cache into treating the MDY and DMY versions of a page as two different pages (with which to display determined by the HTTP headers sent by the browser) but that would still cut the cache efficiency in half, which is too much of a performance hit for too little gain.

I'm giving up on this bug and recommending that it be closed.

A javascript-based approach would still work, but that's well beyond the scope of this request and a new one should be opened if people want to pursue that route.

This also means that anyone who wants to keep Date Autoformatting should start reverting the work of Tony, et. al. with their date unlinking, since it doesn't look like a technical fix is in the works after all, and the only reason some of us have been holding off on the reverts is because we'd been hoping for a better (technical) solution.

-Bill

masem01 wrote:

FWIW, in reply to Bill's comment on closing the bug, I will point out a current RFC where it was asked if editors feel Date Autoformatting is desirable, see http://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style_(dates_and_numbers)/Date_Linking_RFC#Is_some_method_of_date_autoformatting_desirable.3F

The answer seems to be leaning to "no", so closing the bug and giving up on fixing it would seem to be agreeable.

ui2t5v002 wrote:

(In reply to comment #223)

Yep. That's pretty much a show-stopper, too. At best we'd be able to "fool"
the squid cache into treating the MDY and DMY versions of a page as two
different pages (with which to display determined by the HTTP headers sent by
the browser) but that would still cut the cache efficiency in half, which is
too much of a performance hit for too little gain.

We've been through this already. The default format for all unregistered users should be "28 May 1996" as per RFC 2822. Then you only need to cache one version of the page.

But the dates should be given a class name like <span class="localizedate">, so that third-party tools can recognize from the HTML which dates should be left verbatim and which can be localized.

This offloads the formatting for anons into a javascript, which can be written at any later date and doesn't have anything to do with Mediawiki itself.

smccandlish wrote:

(In reply to comment #225)

We've been through this already. The default format for all unregistered users
should be "28 May 1996" as per RFC 2822. Then you only need to cache one
version of the page.

But the dates should be given a class name like <span class="localizedate">...
...and doesn't have anything to do with Mediawiki itself.

Exactly. This should not be a WONTFIX candidate at all! I don't know why every time I come back to this page, the KISS principle has gone out the window and people are trying to complicate the matter. This could have been fixed with patches already posted quite some time ago.

So this request is to just change the default date preference formats on the English Wikipedia ($wgDefaultUserOptions), and have the parser wrap them in a span?

smccandlish wrote:

(In reply to comment #227)

So this request is to just change the default date preference formats on the
English Wikipedia ($wgDefaultUserOptions), and have the parser wrap them in a
span?

No. I think you need to read up on a lot more of the discussion. The defaults are a minor side point. This bug is to make [[date]] stop autoformatting, and have [[:date]] do that instead.

Okay, nobody's going to do this if they have to read through 2 years worth of comments to figure out what's going on. When I first saw this, the plan seemed to be to modify the software to give some sort of date formatting for anon users.

This bug has more than 3 times as many comments than bug 57 - the bug for single-user-login!

Please, someone just summarize what the request here actually is, then there is a chance that it might get resolved sometime this century.

Why not have a special syntax for date formatting << >> which would be auto formatted to a certain style (ISO 8601 maybe?) for uses that aren't logged in or don't have it set in their preferences and then it formats the dates according to their preference.

For example this is how it might be written in WikiCode: "The show premiered on <<2006-02-17>> and has since produced 50 episodes," and this is how some date formats might display it:

  1. The show premiered on 17/02/2006 and has since produced 50 episodes,
  2. The show premiered on 17 February 2006 and has since produced 50 episodes,
  3. The show premiered on 02/17/2006 and has since produced 50 episodes

catlow wrote:

<rant>Why not just NOT DO THIS? What is the problem it's trying to solve? I'm just amazed that a colour-of-the-bikeshed discussion about date formats should grow to such grotesque proportions. Can anyone explain why this (whatever "this" currently is) is even being considered? (Or, for that matter, why the original date autoformatting function was even considered?) Developers don't have time for many of the genuinely useful feature requests or minor bugs that are being reported here all the time; why should they be wasting their time over this? </rant>

s.r.e.turner wrote:

The request is to separate the syntax for date autoformatting from the syntax for linking. At the moment they both use the same syntax, so it's impossible to have one without the other.

I agree that that sentence doesn't form a plan of action, and the reason this bug is so long is that people have different ideas about how to solve it. But there is a genuine user problem here.

catlow wrote:

It's possible to have linking without autoformatting (using colons or pipes).

If the only problem is that it's not possible to have autoformatting without linking, then that should be fairly trivial to fix (just rewrite whatever code does the autoformatting so that it's triggered by some formatting feature other than links, like a CSS style).

Is there anything else?

cyp wrote:

(In reply to comment #233)

then that should be fairly trivial to fix (just rewrite whatever code
does the autoformatting so that it's triggered by some formatting feature other
than links, like a CSS style).

just add the necessary <span class="x"> to Bill's patch.

Is there anything else?

Nope. As for "Developers don't have time": Bill has already done the work. Its /done/. Devs just need to pick it up. Someone needs to give tstarling a wake-up call; its his baby.

Mr Z-man's comment re squid caching for anon users is not a reason why date formatting cannot default to a human-readable format (instead of self::NONE, which -- because of "ISO" date usage -- is a disaster).

billclark wrote:

(In reply to comment #234)

Mr Z-man's comment re squid caching for anon users is not a reason why date
formatting cannot default to a human-readable format (instead of self::NONE,
which -- because of "ISO" date usage -- is a disaster).

No, but it IS a reason why date formats for anons can't be different based on the browser settings indicated by the Accept-Language header. All anons would need to see the same date format, which is fine by me (just make the default the "international" format of DMY and screw any jingoist Americans who are confused or offended by that, or let them register and set a preference) but that has already been soundly rejected by the community, multiple times.

To clear a few things up, this ticket is NOT asking to allow for linked dates that bypass autoformatting, because that's already a standard feature (just use the [[:]] format of link) and it's not asking to change the meaning of [[:]] formatted dates so that they autoformat but don't link (which would reverse the current intent of linked dates and thoroughly confuse people.)

Unless people can agree that ALL anons should see the same date format (presumably DMY) or somebody provides a Javascript-based solution that will do date formatting client-side, this ticket is not able to be resolved. It should be closed and a new one started that takes into account everything that's been discussed (and rejected) here so far, and asks for a more workable outcome.

...or if you really want to have the sysadmins (why does everybody call them "developers" when WE are just as much "the developers" as they are?) apply one of the patches already submitted, that will basically have the effect of disabling date autoformatting and autolinking (leaving [[:]] dates untouched in terms of format and link) for all users. I guess that's better than manually unlinking dates (since it leaves the markup in place for possible future use) but not by much.

-Bill

(In reply to comment #234)

(In reply to comment #233)

then that should be fairly trivial to fix (just rewrite whatever code
does the autoformatting so that it's triggered by some formatting feature other
than links, like a CSS style).

just add the necessary <span class="x"> to Bill's patch.

Which patch? There's 4. And CSS classes shouldn't trigger the parser to do things, that's just incorrect on multiple levels. CSS classes should be used for CSS styling or to help JavaScript find the right objects, that's pretty much it. It needs to be some sort of syntax that isn't already reserved for something else (like CSS styling or normal links). That needs to be decided before anything is done.

Is there anything else?

Nope. As for "Developers don't have time": Bill has already done the work. Its
/done/. Devs just need to pick it up. Someone needs to give tstarling a wake-up
call; its his baby.

People aren't just going to grab a patch and commit it. Especially when the last patch seems to be entirely different from what's being requested in these past several comments.

Mr Z-man's comment re squid caching for anon users is not a reason why date
formatting cannot default to a human-readable format (instead of self::NONE,
which -- because of "ISO" date usage -- is a disaster).

I never said it was. Its the reason why there can only be one default. Defaulting to a different version depending on what the browser language is won't work for anons. The actual default can be changed, as long as there's only one default.

billclark wrote:

(In reply to comment #236)

Which patch?

To clarify what they are:

"diff -u for includes/DateFormatter.php"

This patch satisfies the ORIGINAL request for this ticket, which was to autoformat dates even when they're not marked up with link syntax. This was a BAD IDEA and this patch should NOT be applied under any circumstances (in fact I think it makes mistakes with some date ranges, because of the difficulty in identifying dates that lack markup.)

"Simpler patch, just eliminates links"

This patch could be applied if desired, because it works the same as the current autoformatting except that dates aren't linked, just formatted. Note that there is a vocal group on MOSNUM that is opposed to ANY date autoformatting, so this patch will probably not be acceptable to them.

"Eliminates links, leaves date format untouched"

This patch is the most likely to be applied, because it essentially nullifies date autoformatting. Dates that are marked up with regular link syntax ([[]] but NOT [[:]]) are left untouched -- no formatting change, no link. This patch does automatically what people like Tony, Lightmouse, et. al. are doing manually. Applying this patch would be the same as manually unlinking every [[]] linked date on WP, except that it would leave the markup in place for possible future use.

"unlinks dates, preserves markup, uses Accept-Language for defaults (or DMY)"

This patch should not be applied, because the squid cache makes it unworkable.

-Bill

I strongly support the removal of the request. Autoformatting dates (or numbers, currency amounts, percentages, zip codes and phone numbers if there are some...) according to user preferences at the server level is a very bad idea.

Autolinking dates is a separate issue that is not to be done in MediaWiki but based on community decision on each Wiki project, and implemented in utility templates if really needed, and used according to local usage policies.

Removing autolinked dates could however be performed on the server as it will not be dependant on user preferences: however this should be done by a configuration PHP hook to enforce a local policy decision (so the existing templates trying to bypass this limitation would stop working, or a complex utility template would have to be designed to tweak and complicate the syntax so much that the PHP hook will not detect it, but at the same time the usage of such utility template could be monitored.

My view about it is just that the default dates generated for example in user signatures with tildes, should JUST be surrounded by something indicating this is a date and giving its effective numeric value in abbreviated ISO format (in Zulu timezone). This can be done just by generating (example on French Wikis):

<span class=date"id="date-20081126T184500">mercredi 16 novembre 2008, 20:45:00 CET</span>

instead of just the date and time formatted with the SINGLE DEFAULT format that has been set according to the local Wiki localisation settings (and not accoriding to user preferences). This will be useful for example when someone that can't read Arabic or Farsi goes there to discuss something and has to reply in some local discussions: even if the discussion is made in English, the defautl signature will appear formatted in a way that is impossible to read by most non-readers of Arabic (but a gadget selection and user preference settings should help those users see the dates in a way they can read, and formatted at times accurate for their local timezone (instead of the timezone of the server).

With this type of code, connected users could still use a gadget to transform those dates and interpret the signature dates (notably in discussion pages) accordingto their curerntly selected locale in their preference (the transform would NOT be performed by the server but locally by the user's browser, using the Javascript loaded from the gadget). Nothing should be done for dates inserted in articles.

This would just concern the way the MediaWiki parser transforms four-tildes and five-tildes into formatted current dates...

Nothing is needed for all other dates, that articles will specify directly using a single locale setting (users editing articles to insert dates manually or defisigning templates computing and displaying dates on the Wiki should use only a format suitable for the localization of the current wiki project (but if they want, they may insert the same markup as the one used by MediaWiki for the substitution of tildes. Note that this won't work completely for such dates (with the markup above) occuring in section titles : only the section title will be converted by the Javascript gadget running in the user's browser, but not the formatted date visible in the TOC. I don't think this is a problem.

Also I don't support the unneeded special wiki syntax for formatting dates. This is not needed at all !

Writing <<2008-11-26>> is just a shortcut for generating a single format that you can also generate using existing templates like: {{DateFormat|2008|11|26}}. It is as much readable than the proposed syntax, and not surprising for editors if the template is given a meaningful name... And what the template will generate and the kind of aditional HTML markup it can provide to help a user gadget interpret and reformt the date itself on the user's browser is in full control of the template, without any addition to the Wiki syntax.

billclark wrote:

(In reply to comment #239)

Also I don't support the unneeded special wiki syntax for formatting dates.
This is not needed at all !

Using an alternate markup syntax was suggested when we were discussing server-side date processing to be done in DateFormatter.php, but that's not a viable approach any longer.

So you're correct that the currently proposed solution (using Javascript to do client-side date formatting) can make do with a template. That's very different than what was being discussed before, and in the server-side approach, a new syntax would have been better than using a template. That's why it was being proposed, although it's no longer under consideration.

-Bill

s.r.e.turner wrote:

(In reply to comment #238)

I strongly support the removal of the request. Autoformatting dates (or
numbers, currency amounts, percentages, zip codes and phone numbers if there
are some...) according to user preferences at the server level is a very bad
idea.

I have a lot of sympathy for this point of view. However, we already have date autoformatting. It can be argued that that was a mistake. The particular implementation was certainly a mistake (IMO). So the question now is how to make it suck less, especially given the articles that already use it.

That's simple: if you implemented user-specific data formatting, keep the syntax you have adopted for Wiki, but make it generate a generic format that will be handled now with Javascript (and well, ignore anonymous users without preferences in some user account...).

Anyway, I have made some other suggestions on Madiawiki to help servers reduce the load of Wikimedia Squid caches and PHP servers. Basically, it's time to think about creating a locally deployable proxy version of the MediaWiki software, implementing the PHP MediaWiki PHP code, the PHP engine and the web server, and also working as the proxy that a local browser (or a new dedicated MediaWiki browser with extra editing tools) could connect to instead of connecting directly to the online service. I suggested that this type of deployment cuold also be part of a CD/DVD distribution and would allow eliminating the need to preview before sending edits.

Instead I spoke about the possibility of the locally deployed proxy to be able to have its own local cache, communicating with the online server only with pages in raw format (much less load on Wikimedia PHP servers, because much less work to do in PHP for formatting pages, just the need to manage the history and control the access rights, and the possibility to inform the conencted users about incoming messages).

The locally deployed proxy would be able to load pages from a locally installed database (from a dump stored on a CD/DVD or downloaded onto a harddisk) and filter out the edits made by the local user(s) that could mange a queue of updates to send (in a private, corporate or shoold environment, it would be possible to support a supervizion for pages sent/edited from the local network through the proxy storing the list of locally edited pages, if local users are not directly granted the right to commit their pages online without permission or basic monitoring anf history.

I spoke also about the fact that this would also allow Wikipedia and similar collaborative projects to be able to better control the level of vandalism made mostly anonymously from school/university networks (no more need to ban the entire school or university, if it has firewalled Wikiemdia servers but routed them through a MediaWiki proxy managing the supervision: the school or corporate network would be able to submit updates through public online accounts managed by supervizors that are contactable and can act locally about the vandalism or breach of copyright by one of their supervized local users (that may be connected to the local proxy using a strong and verifiable identity that does not need to be transmitted online, so it can also improve their online privacy).

Finally, the whole set: a dedicated MediaWiki browser application and a local proxy could become the prefered way to work with Wikipedia: all would be integrated including the management of the submission queue and a local supervizion of the queue by the user itself, managing himself the pririty of queues. As it would embed a local cache, it would perform much less traffic with the online server.

The Wikimedia's Squid proxies would still be used, but onlyto cache the much smaller raw pages instead of the large HTML pages. The Wikimedia's own MEdiaWiki servers would also see much less traffic and would caould satisfy more users with limited local cache of pre-generated HTML pages (without the user-specific additions like messages), because all locally deployed proxies would only communicate with them in raw format.

So that's a way to control for a longer term the problem of the explosion of traffic and of server costs to manage this traffic. You would not necessarily need the same explosion in terms of number of squid servers needed to cache the full HTML pages (they would still be needed to cache the images, because, by default, the image thumbnails should be generated centrally and cached centrally to avoid sending them always in full resolution to every user of a proxy version of MediaWiki...

Well all this goes too far way from the current problem of date formatting. I realize that the fact you have eimplemented it is causing problems wiith more traffic generated, but it should be easily reverted before its use becomes widespread, or the onli ne preformances will suffer. I suggest the simple solution of generating a single HTML code for your existing syntax, and then let a Javascript gadget perform the actual formatting. Your squid servers will appreciate !

smccandlish wrote:

Re:

No, but it IS a reason why date formats for anons can't be different based on

the browser settings indicated by the Accept-Language header. All anons would
need to see the same date format, which is fine by me (just make the default
the "international" format of DMY and screw any jingoist Americans who are
confused or offended by that, or let them register and set a preference) but
that has already been soundly rejected by the community, multiple times.

I'm not so sure. I'm unaware of anyone actually involved in the discussion, here or at w:en:WP:MOSNUM, upset by the idea any longer. It clearly would have the benefit of consistency over the current practice, which is willy-nilly and confusing even to editors, much less readers. PS: I am an American. Non-Yank date formatting doesn't bother me at all, and anyone upset to apoplexy about it needs to find a new hobby or something. ANY change to the way MW works generally, and more specifically how it works at WP, will ruffle a few people's feathers, but it chills out quickly and life goes on.

cyp wrote:

(In reply to comment #237)

(In reply to comment #236)

Which patch?

#1 is out of the question, as Bill points out.
#2, #3 and #4 all prevent linked dates from being links. So they all fix the "seas of blue" problem.

#4 also fixes the "ISO cruft for anons/noprefset" problem. The objection that "the squid cache makes [#4] unworkable" is not the whole story. Squid caching only applies to anons, so #4 still works fine for the noprefset registered users. And even *if* the patch were not modified to deal with anons some other way (eg comment #243), then anons would get to see whatever it was that the last anon who caused a fetch from MW saw. Which A) is still a whole sight better than seeing ISO cruft, B) a pretty good weighted-random choice of which dateformat to display for anons.

The bottom line is that *something* needs to be done at DateFormatter too, otherwise the "seas of blue" will continue to exist, and people will continue to go around removing date links, which is inherently destructive. Although there is a Javascript solution available, its not a viable solution unless DateFormatter adds the appropriate markup /and/ the admins make the Javascript site-wide, which is unlikely to happen because -- as we see from the interminable "discussions" elsewhere -- common-sense is in short supply.

Objecting all very well and good, but #3 and #4 are a GoodThing, and if there are problems with them, then these can be fixed or compensated for. Squid et al are not the show-stoppers that they being treated as.

For those joining the discussion late (e.g. Mr. Z Man and Philippe Verdy): the title of this bug only tells half the story. This bug is in effect the search for a technical solution to the perennial discussions at en:wp, which are provoked by A) the eyesore caused by the linked dates also appearing as links; B) the fact that only very few dates actually need to be links; C) the inconsistencies that appear in an article if not every date is linked; D) the cruft that anons and editors without a datepref get to see, E) the (preservation of) meta information present in [[date]]s but not in plain text.

Patch #3 addresses issues A, B, C, E. Patch #4: A, B, C, D, E.

(comment #236)

People aren't just going to grab a patch and commit it. Especially when the
last patch seems to be entirely different from what's being requested in these
past several comments.

This comment borders on stupidity. All the issues noted above are already mentioned in the top 10 comments on this page, which are from Jan-March *2006*. That these issues have not been addressed (and in fact the reason why this bug was once closed for equally ignorant and stupid reasons) is due solely to dev apathy and their inability to read (evident again in a recent email). One need only follow Tony Souter's (en:User:Tony1) comments on this page -- from engaged and supportive (comment #14) to disillusioned (comment #158) -- to recognize how destructive dev negligence has been.

(In reply to comment #244)

(In reply to comment #237)

(In reply to comment #236)

Which patch?

#1 is out of the question, as Bill points out.
#2, #3 and #4 all prevent linked dates from being links. So they all fix the
"seas of blue" problem.

#4 also fixes the "ISO cruft for anons/noprefset" problem. The objection that
"the squid cache makes [#4] unworkable" is not the whole story. Squid caching
only applies to anons, so #4 still works fine for the noprefset registered
users. And even *if* the patch were not modified to deal with anons some other
way (eg comment #243), then anons would get to see whatever it was that the
last anon who caused a fetch from MW saw. Which A) is still a whole sight
better than seeing ISO cruft, B) a pretty good weighted-random choice of which
dateformat to display for anons.

As I said, the default can be changed rather easily. It can even be changed for en.wikipedia without a change to the software. But having anons see either of 2 date formats depending on the location of the last person who caused a cache update, is just ugly.

The bottom line is that *something* needs to be done at DateFormatter too,
otherwise the "seas of blue" will continue to exist, and people will continue
to go around removing date links, which is inherently destructive. Although
there is a Javascript solution available, its not a viable solution unless
DateFormatter adds the appropriate markup /and/ the admins make the Javascript
site-wide, which is unlikely to happen because -- as we see from the
interminable "discussions" elsewhere -- common-sense is in short supply.

I really don't like the idea of having normal wikilink syntax do something, but not actually make a link. It adds even more complexities to wikitext and inconsistencies in parser output. This would probably need approval from Tim/Brion and would probably need a config option to enable it.

Objecting all very well and good, but #3 and #4 are a GoodThing, and if there
are problems with them, then these can be fixed or compensated for. Squid et al
are not the show-stoppers that they being treated as.

4 will not work correctly with squid caching. I'm not going to introduce code into MediaWiki that I know will be partially broken for Wikimedia.

For those joining the discussion late (e.g. Mr. Z Man and Philippe Verdy): the
title of this bug only tells half the story. This bug is in effect the search
for a technical solution to the perennial discussions at en:wp, which are
provoked by A) the eyesore caused by the linked dates also appearing as links;
B) the fact that only very few dates actually need to be links; C) the
inconsistencies that appear in an article if not every date is linked; D) the
cruft that anons and editors without a datepref get to see, E) the
(preservation of) meta information present in [[date]]s but not in plain text.

Patch #3 addresses issues A, B, C, E. Patch #4: A, B, C, D, E.

A is basically a matter of personal opinion.
B is a local style issue. Just because the English Wikipedia decided it doesn't think dates should be linked anymore, doesn't mean we should force that on every user of MediaWiki.
As for C, the patches that simply remove the link wouldn't really address it, since the autoformatting would still happen.
Changing the default preference will also mostly fix D (it won't affect existing accounts) without pointless inconsistencies for anon users.

(comment #236)

People aren't just going to grab a patch and commit it. Especially when the
last patch seems to be entirely different from what's being requested in these
past several comments.

This comment borders on stupidity. All the issues noted above are already
mentioned in the top 10 comments on this page, which are from Jan-March *2006*.
That these issues have not been addressed (and in fact the reason why this bug
was once closed for equally ignorant and stupid reasons) is due solely to dev
apathy and their inability to read (evident again in a recent email). One need
only follow Tony Souter's (en:User:Tony1) comments on this page -- from engaged
and supportive (comment #14) to disillusioned (comment #158) -- to recognize
how destructive dev negligence has been.

Insulting the people trying to help isn't really going to get them to help. There's hundreds of other open bugs I can work on where I won't be called stupid, ignorant, apathetic, and negligent when I try to figure out WHAT PEOPLE ACTUALLY WANT NOW. Not what people want 2 years ago. Not what people wanted last month. Not things where it has been established won't work. This is basically what I've seen in the few days I've been commenting here:

*We want different formatting depending on browser language
That won't work
*Well we didn't want that anyway. Just a change to the default and create an easy way to change them with JS
Okay, that sounds easy enough
*No, we want [[date]] to not autoformat and have [[:date]] do it instead
Okay
*No, we want a completely new syntax for date links
That'll be a little harder
*No, we want to wrap dates in a span if we want them to be autoformatted
That's just ugly
*Well what we actually want is for [[date]] to not create a link
And that's where we're basically at now.

The actual request seems to vary significantly depending on who's making the comment.

smccandlish wrote:

Just because the English Wikipedia decided it doesn't

think dates should be linked anymore, doesn't mean we should force that on
every user of MediaWiki.

It's really the opposite, though. Someone, back when, decided it would be a good idea to operator overload linking and date autoformatting, and this was pushed on user of WP and every other MW installation. Today, virtually everyone who has thought about it agrees that it was a bad idea.

Insulting the people trying to help isn't really going to get them to help.

I absolutely agree, and want to point out that not everyone involved here is being negative. I appreciate the time and analysis you've put into this, and fully understand that you cannot just go implement something without understanding its ramifications, nor implement "something A" when "something B" and "something C" have also been proposed.

I really don't like the idea of having normal wikilink syntax do something, but

not actually make a link.

Strikes me as a non-issue, since [[image]] and [[category]] already do non-linky things. I think it is more accurate to think of [[something]] as "take an action" code. That "action" is most commonly creating a wikilink, but for a very long time has obviously also had alternative meanings depending upon context. This wouldn't be any different, and having [[date]] not create a link but do autoformatting instead, and [[:date]] create a link, is actually more, not less, consistent with this [[something]] model. In very, very few cases is there any need for a date to actually be linked; probably far fewer cases than there are cases (e.g. on "Wikipedia:"-namespace pages where images and categories are being discussed) of categories and images needing to be wikilinked to instead of being inlined or being added as a category to a page, respectively.

alexfusco5 wrote:

How about this setup:
*All dates with [[]] will be autoformatted but not linked
*All dates with [[:]] will be autoformatted and linked
*Autoformating is set to a default global configuration option so that the display of dates is consistent
*If its desirable, a magic word can be set up to change the default on a page by page basis (I would put this at the lowest priority)
Thats my 2 cents here. The first 3 should solve many of the outstanding problems about date format and the 4th would make certain pages that have a good reason to be formatted differently from the default. Obviously 3 and 4 would not override user preferences

(In reply to comment #247)

*All dates with [[:]] will be autoformatted and linked

Isn't that sort of the opposite of current behavior? I thought currently [[:date]] is used for linking without autoformatting. If we change it so that it does autoformatting it will potentially break existing uses, or at least be confusing.

Remove ALL this autoformatting mess from the [[]] syntax.

For me, [[2000-12-31]] is ONLY creating a link to an article named "2000-01-01" (with no attempt to interpret it as a date, and NO attempt to reformat it as it breaks data tables where they are NOT dates)

For me [[:2000-12-31]] is ALSO creating a link to the same article name, but explicitly in the default namespace (and here also, it MUST not attempt to reformat it).

Those that want autoformatting (according to the default locale set on the server for the WHOLE Wiki project only, but NOT according to user preferences) should have their own syntax, but if needed they can still use a template to do that if there's no syntax support, like {{Date|2000|12|31}}.

If a syntax like <<2000-01-01>> is supported for autoformatting, it should NOT create any link: liks should have to be spacified by users themselves like this: [[2000-12-31|<<2000-12-31>>]], or using a template that performs both, like {{DateLink|2000|12|31}} that can be defined as

[[{{{prefix|}}}{{{3}}}-{{{4}}}-{{{5}}}{{{suffix|}}}|{{{prefix|}}}<!--
--><span class="formated date" id="date-ymd-{{{3}}}-{{{4}}}-{{{5}}}"><!--
--><<{{{3}}}-{{{4}}}-{{{5}}}>><!--
--></span><!--
-->{{{suffix|}}}]]<!--

Such example template above performs three things:

  • formatting the date for the DEFAULT display according to server-side Wiki project defaults (3rd line);
  • surrounding the DEFAULT disply format by enough HTML to allow user-level preferences on the CLIENT side (via a Javascript gadget) (2nd and 4th lines);
  • linking to an article (whose prefix and suffix part of the name can be given, see 1st and 5th line), but whose format used in the target article name is predictable and will not change even if the server's default format changes).

Now don't implement or remove date linking automatically from the [[ymd]] or [[:ymd]] syntax!
This is not the role of MediaWiki to take such uninformed decision, but the role of a community decision, only as a general rule where there may exist exceptions for some famous dates, or within some namespaces or categories related to content management and maintenance.

alexfusco5 wrote:

@MrZman:
Yeah that would pretty much work correctly because autoformatted links can be created via [[[[:]]]]
@Philippe:
This is not just about the English Wikipedia, many other websites use Mediawiki and this feature may be useful to them

I did not speak specifically about English Wikipedia (in fact I did not know (or noticed) that you had implemented autoformatting there. I hope it was not deployed too on French Wikipedia because I doubt that this "autoformatting" will work correctly there and that you really know how French dates are formatted !

For me, autoformatting dates is silly and this has to be at least fully disabled as needed, i.e. everywhere its "guess" (about what is a date or not or if this formatting is desired) is completely wrong, because the syntax it recognizes is completely equivalent to the syntax used for normal links. Then if you need a special keyword in the page to disable this guess and so to disable autoformatting in links, you've done a wrong job: in fact the syntax chosen for autoformatting was badly chosen.

Suggestion for the choice of the syntax (that DOES NOT create a link): {{#2000-12-31}}. No conflict there because it uses the prefix for parser functions, and no parser function can have a name starting by a digit... But I wonder why you absolutely want a short syntax for dates specifically but not for other features that may want a shorter syntax that would be much more useful.

The need for autoformatting would mean that the writer of an article does not know how to format a date in the SINGLE main language of the target Wiki (or page or section, if a page can be marked specifically as using another target language, something that is possible with the "xml:lang=" attribute name, which is also already recognized by MediaWiki as the "lang=" atttribute name of HTML elements). If that writer does not know that, what is the meaning of the rest of the page, beside this isolate date? Can't the editor directly format the date himself (including in templates that would like to format computed dates)?

On the same front, trying to remove links generated by the [[]] syntax should not depend on the presence or not of the leading ":" because it is also part of the syntax to separate the root (anonymous) namespace space before the article name.

Yeah! Two hacks introduced recently in English Wikipedia (and badly documented), two errors, and now you're thinking about compatiblity elsewhere ? No. you shoulmd revert this "support", as it is completely UNNEEDED and generates more problems than what it is supposed to solve.

(In reply to comment #250)

@MrZman:
Yeah that would pretty much work correctly because autoformatted links can be
created via [[[[:]]]]

What? That doesn't make any sense at all. Ideally, if anything is done as a result of this bug, partially reversing current behavior won't be part of it. AFAIK, [[:date]] is currently used to link a date *without formatting it.* If all of a sudden they start autoformatting, its going to break every every existing use.

I did not speak specifically about English Wikipedia (in fact I did not know
(or noticed) that you had implemented autoformatting there. I hope it was not
deployed too on French Wikipedia because I doubt that this "autoformatting"
will work correctly there and that you really know how French dates are
formatted !

Date autoformatting in MediaWiki has been around since 2003. There are 5 different options and the default is no autoformatting.

Suggestion for the choice of the syntax (that DOES NOT create a link):
{{#2000-12-31}}. No conflict there because it uses the prefix for parser
functions, and no parser function can have a name starting by a digit... But I
wonder why you absolutely want a short syntax for dates specifically but not
for other features that may want a shorter syntax that would be much more
useful.

I agree a parser function would be better than creating a whole new syntax, or breaking existing syntax to do it.

The need for autoformatting would mean that the writer of an article does not
know how to format a date in the SINGLE main language of the target Wiki (or
page or section, if a page can be marked specifically as using another target
language, something that is possible with the "xml:lang=" attribute name, which
is also already recognized by MediaWiki as the "lang=" atttribute name of HTML
elements). If that writer does not know that, what is the meaning of the rest
of the page, beside this isolate date? Can't the editor directly format the
date himself (including in templates that would like to format computed dates)?

No, it means people may not want the normal style of dates used on the wiki. Using the English Wikipedia as the obvious example, British users may want the "date month year" format, American users the "month date year" format. Others may want the ISO 8601 format.

Yeah! Two hacks introduced recently in English Wikipedia (and badly
documented), two errors, and now you're thinking about compatiblity elsewhere ?
No. you shoulmd revert this "support", as it is completely UNNEEDED and
generates more problems than what it is supposed to solve.

What? As I said, date autoformatting has been around for 5 years.

(In reply to comment #252)

Date autoformatting in MediaWiki has been around since 2003. There are 5
different options and the default is no autoformatting.

If I'm not mistaken, the autoformatting is only supported for the English localization. In other locales, the date format option in [[Special:Preferences]] only affects MediaWiki's interface, not the wiki's content.

alexfusco5 wrote:

@MrZman that was the point, [[:]] only creates a link and if its wrapped in [[]] (the link syntax that is) its both linked and autoformatted.

smccandlish wrote:

Yeah! Two hacks introduced recently in English Wikipedia (and badly

documented), two errors, and now you're thinking about compatiblity elsewhere ?
No. you shoulmd revert this "support", as it is completely UNNEEDED and
generates more problems than what it is supposed to solve.

Exactly. Calling date linking+autformatting as currently implemented a "feature" is disingenuous. The ranty earlier message about it being oh-so-important to preserve all of this and introduce some new <<date>> syntax (or {{#date}}, I think someone else suggested along the same lines) seems to me to be missing the point and unnecessarily complicating the issue.

We don't really seem to be getting anywhere here, I think at the least we need to summarize the options. Here's a list of the ones I've noted, some can be combined with others:

  1. Remove date autoformatting entirely (rather than removing the option entirely from code, this could most easily be accomplished by setting $wgUseDynamicDates to false for enwiki)
  2. Keep the current syntax, remove the links: [[date]] would continue to autoformat, but it wouldn't create a link, [[:date]] would continue to work as it currently does
  3. Remove autoformatting and linking, "[[date]]" would be parsed as "date" - no link, no formatting
  4. Create a new syntax for date autoformatting (a parser function, some new syntax, etc), [[date]] would work the same as any other normal link, [[:date]] would continue to work as it currently does
  5. Wrap dates in a <span> for client-side customization with JavaScript
  6. Change the default date format preference from "no preference" to something more sensible

Option 1 would obviously be the simplest, though a combination of options 4, 5, and 6 would also remove most of the problems I think. I really don't care for option 2, and option 3 is pretty terrible IMO.

smccandlish wrote:

That list seems to be missing the main one proposed, for which a patch has already been written:

  1. [[date]] would autoformat but NOT link, just as [[image]] and [[category]] do something special and don't make a link, while [[:date]] would link but not autoformat (just as [[:image]] and [[:category]] create links but don't do anything special). If someone wants to link AND autoformat, which frankly would be kind of weird, they can use template code, examples of which have already been posted.

I think it is important to keep in mind that the main impetus behind this bug report is the "sea of blue" problem. I think few of us would cry if the autoformatting just plain stopped, but I don't think many have been actually asking for that, and resolving the sea-of-blue problem doesn't require that, nor require new features, like a new <<date>> or {{#date}} or {{DATE:date}} syntax.

Imagining some wiki where linking to actual articles on every conceivable date would make sense AND where autoformatting is important (I cannot think of any practical application of this, but let's pretend), this can just be handled with templates. Enwiki is awash in useless, reader-distracting date links (I want to point out that the frequent kvetching against Tony1 about that here is a red herring; many, many users have been removing such date links), and as the most-used wiki in the world, by several orders of magnitude, not to mention the Wikimedia flagship and thus the source of funding for MediaWiki to even have this site to argue about bugs, I don't feel we can just throw up our hands and not resolve this, in an enwiki-favorable manner.

My vote is to just do #7, and keep this as simple as possible, so that it actually proceeds instead of sitting here as a languishing bone of contention for another 2 years.

alexfusco5 wrote:

I like a combination of 2 and 6, but 4 can be used in place of 2. It would probably solve most outstanding problems and I'd say 6 is a must do

(In reply to comment #257)

That list seems to be missing the main one proposed, for which a patch has
already been written:

  1. [[date]] would autoformat but NOT link, just as [[image]] and [[category]]

do something special and don't make a link, while [[:date]] would link but not
autoformat (just as [[:image]] and [[:category]] create links but don't do
anything special). If someone wants to link AND autoformat, which frankly
would be kind of weird, they can use template code, examples of which have
already been posted.

That would be #2, "Keep the current syntax, remove the links: [[date]] would continue to autoformat, but it wouldn't create a link"

MediaWiki wrote:

(In reply to comment #259)

(In reply to comment #257)

That list seems to be missing the main one proposed, for which a patch has
already been written:

  1. [[date]] would autoformat but NOT link, just as [[image]] and [[category]]

do something special and don't make a link, while [[:date]] would link but not
autoformat (just as [[:image]] and [[:category]] create links but don't do
anything special). If someone wants to link AND autoformat, which frankly
would be kind of weird, they can use template code, examples of which have
already been posted.

That would be #2, "Keep the current syntax, remove the links: [[date]] would
continue to autoformat, but it wouldn't create a link"

So if #7 is the same as #2, and #7 already has a patch written for it, #2 already has a patch written. Since #(7|2) is also "the main one proposed", is there any reason the patch shouldn't be applied to allow this bug to be finally closed for good?

(In reply to comment #260)

(In reply to comment #259)

(In reply to comment #257)

That list seems to be missing the main one proposed, for which a patch has
already been written:

  1. [[date]] would autoformat but NOT link, just as [[image]] and [[category]]

do something special and don't make a link, while [[:date]] would link but not
autoformat (just as [[:image]] and [[:category]] create links but don't do
anything special). If someone wants to link AND autoformat, which frankly
would be kind of weird, they can use template code, examples of which have
already been posted.

That would be #2, "Keep the current syntax, remove the links: [[date]] would
continue to autoformat, but it wouldn't create a link"

So if #7 is the same as #2, and #7 already has a patch written for it, #2
already has a patch written. Since #(7|2) is also "the main one proposed", is
there any reason the patch shouldn't be applied to allow this bug to be finally
closed for good?

Because A) it doesn't solve all the problems (crappy default being the big one) B) its not clear if that's what people actually want, hence my summary of the multitude of options. C) Many of the options are easy, Option 1 for example doesn't need a patch at all, its a matter of removing 1 line from the Wikimedia config files. Just because option 2 happens to have had code written for it first doesn't mean its the best option. D) I'm not entirely convinced its a good idea to use link syntax for a non-link. Category and Image links don't create normal links, but they do create links. E) I haven't tested it yet.

VoyagerFan5761 asks why not do #7. Discussion on the English Wikipedia "Manual of Style (dates and numbers)" seems to be building a consensus to not do autoformatting, especially if non-logged-in readers do not benefit. If eventually autoformatting is no longer done, and gradually all autoformatting markup is removed, then someone who wants to link to an article about a date for some reason will have to use the odd syntax [[:February 30]], and since there will be few examples of autoformatting markup around, the reason for this odd syntax will not be apparent. This does not compare to the unusual syntax for images, because the current form of image linking does not seem to be going away.

smccandlish wrote:

Not to be overly argumentative, but re: #2/#7:

2 and 7 weren't identical, since 2 did not address [[:date]], only [[date]], but whatever.

it doesn't solve all the problems (crappy default being the big one)

Refresh my memory; what's the crappy default? If it's that crappy, then just fix that, too, and we're done, right? I've seen [D]D Month YYYY suggested as the proper default, with little if any objection, including from Americans (like myself); we may not be globally popular folks right now, but we aren't retarded, and understand that format just fine.

B) its not clear if that's what people actually want, hence my summary of the

multitude of options.

From my reading, it's the most-sought solution, and it would comport with MOSNUM's consensus, which took years to arrive at, meanwhile I don't think I've seen a credible, non-hypothetical reason not to go that direction, only "what-ifs" like "maybe there's a wiki somewhere where having all dates linked and autoformatted is useful".

C) Many of the options are easy, Option 1 for example

doesn't need a patch at all, its a matter of removing 1 line from the Wikimedia
config files. Just because option 2 happens to have had code written for it
first doesn't mean its the best option.

The opposite is also true. I never suggested that the other options are impossible, only that we are in a good position to implement the one that seems to have the most favor, and have been for some time.

D) I'm not entirely convinced its a good idea to use link syntax for a non-link.

Moot point, for all practical purposes, given both images and categories, which use "link syntax" (better thought of as "do something" syntax) to show a picture and put an article in a category, respectively. #2/#7 is just "do something, different in this case". (More accurately, it's "stop doing two things - linking and autoformatting - the latter of which is something different, and only do the one different thing".)

Category and Image links don't create normal links, but they do create links.

That's picking nits; they would not actually have to - one could easily create a [[foo:...]] that did not create any form of link but did something else entirely, such as applying a CSS class or whatever. And [[date]] formatting could conceivably create some kind of "non-normal link", in some manner on the page somewhere, such as an entry in a (presently nonexistent) article timeline sidebar feature, or whatever. (For this reason, I faintly agree that dates should remain marked up with [[date]] formatting, rather than have the [[ and ]] removed by bots or by individuals with too much time on their hands.)

E) I haven't tested it yet.

True of all options, no?

All that said, I'll ultimately be satisfied with any solution that ends the sea of useless blue date links, really.

smccandlish wrote:

Discussion on the English Wikipedia "Manual

of Style (dates and numbers)" seems to be building a consensus to not do
autoformatting, especially if non-logged-in readers do not benefit. If
eventually autoformatting is no longer done, and gradually all autoformatting
markup is removed, then someone who wants to link to an article about a date
for some reason will have to use the odd syntax [[:February 30]], and since
there will be few examples of autoformatting markup around, the reason for this
odd syntax will not be apparent.

That's a cart-before-the-horse issue, really. MOSNUM is castigating autoformatting because it creates a sea of blue. If THAT problem is solved, then there is no particular reason to oppose autoformatting, and as others have pointed out here there are other potential uses for autoformatting more generally (color/colour, etc.), if it doesn't overload the wikilinking function.

alexfusco5 wrote:

(In reply to comment #264)

Discussion on the English Wikipedia "Manual

of Style (dates and numbers)" seems to be building a consensus to not do
autoformatting, especially if non-logged-in readers do not benefit. If
eventually autoformatting is no longer done, and gradually all autoformatting
markup is removed, then someone who wants to link to an article about a date
for some reason will have to use the odd syntax [[:February 30]], and since
there will be few examples of autoformatting markup around, the reason for this
odd syntax will not be apparent.

That's a cart-before-the-horse issue, really. MOSNUM is castigating
autoformatting because it creates a sea of blue. If THAT problem is solved,
then there is no particular reason to oppose autoformatting, and as others have
pointed out here there are other potential uses for autoformatting more
generally (color/colour, etc.), if it doesn't overload the wikilinking
function.

2 things need to be noted.

  1. The English Wikipedia is not the only website using mediawiki
  2. There is also probably going to be a configurable default set

catlow wrote:

Seems to me that all the devs need to do is to provide a magic word for user locale (value dependent on user preference or browser information); it would then be up to individual wikiprojects to decide whether to use it and how. If they did decide to use it it would be easy to make parser-function-based templates to do date autoformatting, spelling autoformatting and whatever else, without the need for any more software enhancements. (I don't know how the caching problem would be solved, but presumably in whatever way it's currently solved with date autoformats.)

cyp wrote:

(In reply to comment #266)

Seems to me that all the devs need to do is to provide a magic word for user
locale

Notwithstanding that magic words cannot be made subject to user, this bug is evidence that per-user content is a terrible idea. Besides, /articles/ that are locale-specific (cf. ENGVAR), not users.

(In reply to comment #256)

[list of options]

If MediaWiki were wikipedia-specific, option #2 would be fine. But MediaWiki is used by other sites too, who may be expecting dateformatting to work as it has done so far. Among the listed options, the only realistic options is #1 since that does not affect anything but en.wiki. But the resultant "seas of red" will of course not be an improvement over "seas of blue".

(In reply to comment #264)

That's a cart-before-the-horse issue, really. MOSNUM is castigating
autoformatting because it creates a sea of blue.

True, but it is not /just/ that the seas of blue exist, but that there is no alternative and -- to judge from this bugzilla ticket -- no hope that an alternative will be forthcoming. Once editors/bots begin mass de-linking dates (and the RFCs indicate that this is going to happen) there will be no horse to put the cart before.

billclark wrote:

(In reply to comment #267)

Once editors/bots begin mass de-linking dates (and the RFCs indicate
that this is going to happen) there will be no horse to put the cart
before.

It's not just "going to happen" -- it's already happening. That's what got me involved in this bug in the first place, since Tony (et al.) were refusing to hold off on delinking, and used the "lack of response" on this bug as an excuse. By their own estimates, they've already delinked tens of thousands of dates in thousands of articles. The RFCs are an attempt to get them to stop, or to at least get some GENUINE consensus support for their actions.

I'd prefer to keep date autoformatting and actually LIKE the date links (I don't agree that "overlinking" is EVER an issue.. I'd prefer to see MORE links in articles, not fewer) but more importantly I want to see the markup left in place so that we have the option of doing something more useful with it in the future. With the markup, it would be trivial to have a bot replace the [[]] with a template or new syntax or whatever... but without the markup, all of that would need to be done manually, to confirm that we're not dealing with a date in a quote, or odd formatting edge cases like "On March 1, 500 people were killed" which could either mean that 500 people were killed on March 1 or that some unspecified number of people were killed on March 1, 500 A.D.

If the consensus is that date autoformatting should be done away with and dates should not (usually) be linked, then I'd prefer to have that enforced by applying the third patch, since it would leave all the markup in place (and we could then proceed to start working on an improved date autoformatting for some future release). It would also accomplish the goal of Tony and his cohorts right away, without them having to edit untold number of articles. Everybody wins.

-Bill

cyp wrote:

... used the "lack of response" on this bug as an excuse.

Its a valid point. Cf. comment #35 of 16 December 2006

Lack of response is also a response. Its not an unjustifiable position either, after all "if X is causing a problem then X should be removed." Since X is local to en.wiki, its up to en.wiki to remove it.

Everybody wins.

Its a well-known fact that everybody wins with patch #3. There is however no indication that it will in fact be implemented. Indeed, the opposite is true.

smccandlish wrote:

I can resignedly go along with Bill's idea (third patch), though it doesn't seem optimum to me. I can't agree with the idea that the sea of blue isn't a real problem and we need more and more links. Overlinking is a well-studied problem in usability circles, and has been since the mid-1990s, with a lot of data backing up the concerns. It's not a WP issue, but a general one with regard to hypertext media as a class.

catlow wrote:

Everyone wins with the third patch? Forgive me if I've misunderstood, but the third patch means not linking dates that are enclosed normally in [[...]], right? I can't see how ordinary editors can be said to "win" by being prevented from making links to dates in the normal way they make links to everything else; nor is it the developers' job to forcibly delink *all* existing dates (which would be the consequence of this patch - again unless I've misunderstood).

Seems the optimum solution is to give up all futile attempts at social engineering and simply turn off the current autoformatting, allow dates to be linked or not just like anything else, and (when ready, if at all) introduce a simple new syntax (if not "magic word" then something else, doesn't really matter, obviously it is feasible since the current autoformatting does it) for producing alternative text output depending on user preference (/locale). Then the projects could decide whether to use this syntax for dates, for alternative spellings, alternative meanings of words or whatever. Or (preferably) not use it at all.

billclark wrote:

(In reply to comment #270)

I can resignedly go along with Bill's idea (third patch), though it doesn't
seem optimum to me. I can't agree with the idea that the sea of blue isn't a
real problem and we need more and more links. Overlinking is a well-studied
problem in usability circles, and has been since the mid-1990s, with a lot of
data backing up the concerns. It's not a WP issue, but a general one with
regard to hypertext media as a class.

Just in case there's any confusion, the third patch DOES eliminate links on [[]] formatted dates (leaving [[:]] or "piped" [[|]] dates alone) so it solves the "sea of blue" problem. My personal preference would have been to keep the links, but I wrote the patch to do what (I think) other people want, not what I want.

As for usability studies, I'd take them with a grain of salt. I had a boss that was fond of pointing to usability studies to "prove" that serif fonts were easier to read than san-serif fonts (he came from the newspaper industry and insisted on serif fonts on all our websites.) Then, about ten years ago, the numbers started to shift -- and nowadays, san-serif fonts are preferred something like 2-to-1 over serif fonts. What changed? More people started reading text on computers, which are more likely to us san-serif fonts.

Usability studies measure what people are *familiar* *with*, not what is "inherently" easier to use. As people gain more exposure to hyperlinked text, their "tolerance" for hyperlinks will increase. Plus, there are always people in any usability study that deviate from the norm. My point in saying that *I* don't mind the hyperlinks is that the choice of whether or not to link a date should be one left up to the *reader* in most cases. Some people don't like an abundance of links, and they should have the option of turning off the links. Some people like having links, and they should have the option of turning them on.

-Bill

billclark wrote:

(In reply to comment #271)

I can't see how ordinary editors can be said to "win" by being prevented
from making links to dates in the normal way they make links to everything
else; nor is it the developers' job to forcibly delink *all* existing dates
(which would be the consequence of this patch - again unless I've
misunderstood).

Dates that use the [[:]] or [[|]] style of markup will still be linked but not autoformatted, just as they are now. It's only the dates with [[]] markup that will appear unlinked (and in "raw" format) on the page.

Presumably some of the [[]] dates are ones that really *should* remain linked, and editors will need to change those to [[:]] or [[|]] format to re-enable the links after (if) the patch is applied.

It's important to note that there are a number of editors that are manually removing ALL of the [[]] markup around links, RIGHT NOW. They've already removed thousands, perhaps tens of thousands, of such links. In doing so they're also eliminating valuable markup that could be put to better use, or (if consensus dictates) re-enable date linking/autoformatting. The proposed (third) patch accomplishes the same goal as these editors -- eliminate date linking and autoformatting for [[]] dates while leaving [[:]] and [[|]] ones untouched -- but in a way that happens immediately and which is completely reversible.

So instead of writing "everybody wins" I should have written "the people currently removing link syntax win, and the people (including me) who want to develop an improved parser function that depends on date markup don't lose quite as badly as they otherwise would." That better?

-Bill

catlow wrote:

Well, other losers seems to be (1) the editor population at large (who would have to learn a different linking syntax specially for dates, and - if your preservation programme is to have any value - be expected to use a counterintuitive syntax even for unlinked dates); (2) those who wish to retain existing linked dates in many articles (such as the chronological articles themselves). I'm personally all in favour of the delinking, but I don't see a need to do it by brute force in a way that leaves a pointless syntactical complication for editors frozen in for the foreseeable future.

billclark wrote:

(In reply to comment #274)

who would have to learn a different linking syntax specially for dates

There's *already* a different linking syntax for dates, and it's the same as for links to categories and for images (and inter-wiki links for that matter.) The patch doesn't change that.

If I wanted to link to a specific date *currently* I would still need to use the [[:]] or [[|]] syntax to do it, otherwise my link would automatically be broken into a link to the day-month combination and a different link to the year.

So the patch has nothing to do with the weird date linking syntax.

those who wish to retain existing linked dates in many articles
(such as the chronological articles themselves).

If those dates aren't already marked up using either the [[:]] or [[|]] syntax, then editors like Tony and Lightmouse are going to delink them (if they haven't done so already.) They're using a Javascript tool that does the delinking automatically and (if the number of complaints on their talk pages are any indication) they aren't being too careful about which dates they're delinking.

I'm personally all in favour of the delinking, but I don't see a
need to do it by brute force in a way that leaves a pointless syntactical
complication for editors frozen in for the foreseeable future.

I don't see the need to do it by "brute force" (which applies more to what Tony and others are doing rather than the proposed patch) in a way that makes the decision (reached without proper consensus) hard to reverse.

Bear in mind that the patch is meant as a temporary measure. Applying it would allow us to do *instantly* what Tony and others will take months or years to do by hand, and to gauge reader response right away. If readers complain about the change, it's trivial to remove the patch and revert the instructions on MOSNUM to how they were for the past few years (i.e. encourage date linking for autoformatting.) If readers applaud the change, then the manual delinking could still occur (or a bot could take over) to clean up the now-obsolete linking syntax, and THEN the patch could be removed.

Either way, the patch will eventually no longer be needed, either because an improved date autoformatting function has been created or because readers show that they really do want date linking and/or autoformatting.

-Bill

billclark wrote:

(In reply to comment #275)

Either way, the patch will eventually no longer be needed, either because an
improved date autoformatting function has been created or because readers show
that they really do want date linking and/or autoformatting.

Sorry.. that last part should read: "or because readers show that they really DON'T want date linking and/or autoformatting."

-Bill

smccandlish wrote:

Bill says:

Presumably some of the [[]] dates are ones that really *should* remain linked,

and editors will need to change those to [[:]] or [[|]] format to re-enable the
links after (if) the patch is applied.

Right. There are so few dates that actually should be linked that this is a really trivial matter.

Since this tweaks around markup, it really needs some parser test cases.

MacGyverMagic wrote:

It's a nice addition for templates, but not suitable for use in regular articles because it uses unneccesarily complicated formatting. The perceived problem with regular linking of dates is that it caused irrelevant links in whatlinkshere, but it's format is highly superior. Can't we just choose how to format a date in our preferences without the requirement for any extra coding at all?

parser test cases were done ages ago.

wclark wrote:

This wikitext:

Produces this page text:

January 1, 5

Surely that's not correct.

(In reply to comment #282)

This wikitext:

Produces this page text:

January 1, 5

Surely that's not correct.

Quoted from my talk page, on this matter:

If you're interested in fixing the problem with yearless dates, it's an interesting one. When you strip out the [[ ]] syntax, you end up leaving " *,? *" as the only thing separating the day from the year, and since that regex matches the empty string, the parser function thinks the first digit of a two-digit day is the day, and the second digit is the year (or the other way around, depending on what the "raw" format is.) Fixing it is non-trivial because while the simple and obvious fix is to use " *,? +" (or " *,? *" for the non-perl-compatible regex) that will introduce annoying edge cases where the comma is misplaced (handled correctly by the standard autoformatting) or where the year is on a new line in the wikitext. I'm not sure if those edge cases are worth worrying about though. --UC_Bill (talk) 18:30, 10 March 2009 (UTC)

Maybe "( ,)+" would be better.. except that will allow [[15 January]],,,,,,,,[[2009]] to be matched (which may or may not be a problem) and would require some corresponding changes to the "keys" array in DateFormatter to tell it to ignore the new match register. --UC_Bill (talk) 18:41, 10 March 2009 (UTC)

Why not simply: "( *, *| +)" ?
This seems a trivial change that explicitly wants a single comma with optional surrounding spaces, or at least one space.

In other words:

  • trunk/phase3/includes/parser/DateFormatter.php (revision 48249)

+++ trunk/phase3/includes/parser/DateFormatter.php (revision ?????)
@@ -50,3 +50,3 @@

  1. Real regular expressions

+ $this->regexes[self::DMY] = "/{$this->prxDM} *,? *{$this->prxY}{$this->regexTrail}";

  • $this->regexes[self::DMY] = "/{$this->prxDM}( *, *| +){$this->prxY}{$this->regexTrail}";

Fixed, with a parser test case in r49794.

wclark wrote:

The most recent changes break existing autoformatting for linked dates (not those in {{#formatdate}}) -- badly. The problem is that by putting an additional () grouping into the regexes, the characters of $this->keys no longer correspond to the correct groups.

This will fix it:

Index: includes/parser/DateFormatter.php

  • includes/parser/DateFormatter.php (revision 50326)

+++ includes/parser/DateFormatter.php (working copy)
@@ -59,10 +59,10 @@

    1. Extraction keys
    2. See the comments in replace() for the meaning of the letters
  • $this->keys[self::DMY] = 'jFY';

+ $this->keys[self::DMY] = 'jF Y';

$this->keys[self::YDM] = 'Y jF';
  • $this->keys[self::MDY] = 'FjY';
  • $this->keys[self::YMD] = 'Y Fj';

+ $this->keys[self::MDY] = 'Fj Y';
+ $this->keys[self::YMD] = 'Y Fj';

$this->keys[self::DM] = 'jF';
$this->keys[self::MD] = 'Fj';
$this->keys[self::ISO1] = 'ymd'; # y means ISO year

HOWEVER, I think it would be better to simply revert ALL of the changes associated with this bug, and to close the bug as "WONTFIX" since the recent ArbCom-sponsored poll determined that the existing autoformatting is to be eliminated anyway.

I agree with Bill and am closeing the bug. See https://bugzilla.wikimedia.org/show_bug.cgi?id=18479 for the request to turn off autoformatting on en:WP.

I don't care whether English Wikipedia wants to use it or not. There is useful functionality in MediaWiki that needs to be fixed.

Please don't decide on my behalf that I'm not going to work on a feature unless your name is Brion Vibber.

Siegel wrote:

(In reply to comment #287)
...

HOWEVER, I think it would be better to simply revert ALL of the changes
associated with this bug, and to close the bug as "WONTFIX" since the recent
ArbCom-sponsored poll determined that the existing autoformatting is to be
eliminated anyway.

MediaWiki is uised on sites other than en.wp. Even if the poll indicates that this functionality will never be used on the en wikipedia, it may well be useful on other mediawiki sites.

Of course, for many such sites, the original request of new syntax to accomplish formatting *without* linking would be preferable, and i think simpler to code, since detectign existing date formats would not be an issue.

mxn added a subscriber: mxn.