Last modified: 2011-06-22 20:02:53 UTC
Many months of debate, and there clearly will never be agreement. A technical
solution is required.
Just as the software currently recognizes wikified dates with years, it should
recognize trailing "BC" or "BCE" or "CE" after a number (as a year) or the word
"century", and recognize a leading "AD" before a number (as a year) or trailing
after the word "century".
A user preference would needed. It should default to "no translation", with the
options of "BCE/CE" and "BC/AD".
Problem needs to simultaneously address yyyy-mm-dd preferences. All dates of the
form yyyy-mm-dd ([[dd mmm]][[yyyy]], etc.) have to be wikified anyway. For BCE,
all the dates have the BC/BCE in them, so using the display parser will be the
natural place to handle preferences for both types.
Don't forget that "nth century BCE" has to be handled as well.
For current era dates, almost all can be left alone. The only time that AD/CE
dates are displayed is a change in era. This is a rather rare occurrence.
Therefore, why not a single template:
Template:Era is already defined, but not used, so it could be reused. It would
be used immediately following the BCE date, generate the ndash, then wikidate
format for AD/CE. The parser would handle the preference display, just as it
Other possible names for the Template could be "Era change" or "Era range", but
that's more to type and editors are often lazy.
* All BCE dates wikified.
* All era ranges wikified.
* No change to common era, other than to remove extraneous "A.D." or "CE"
according to MoS.
This should probably allow conversion with the least amount of manual work.
hmmm, that text didn't flow well. Not eating our own dog food?
*** Bug 5090 has been marked as a duplicate of this bug. ***
*** Bug 5091 has been marked as a duplicate of this bug. ***
*** Bug 7239 has been marked as a duplicate of this bug. ***
Bug 7239 (marked as a duplicate) has a regex patch of '/includes/DateFormatter.php' by Bill Clark that seems to partially work.
I'm going to be bold and WONTFIX this. The automagic date formatting stuff is not being expanded to non-English locales (see the WONTFIX on bug 248), and we're now floating the idea of removing automagic date stuff entirely (see bug 29472).
Doing stuff like this just fragments the parser cache. More specifically to this bug, we're unlike to provide a technical solution to what is really a social problem.