Last modified: 2011-06-22 20:02:53 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 5089 - Era preference for BC(E) and AD/CE
Era preference for BC(E) and AD/CE
Status: RESOLVED WONTFIX
Product: MediaWiki
Classification: Unclassified
Parser (Other open bugs)
unspecified
All All
: Low enhancement with 2 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
: 5090 5091 7239 (view as bug list)
Depends on:
Blocks: 5090 5091
  Show dependency treegraph
 
Reported: 2006-02-25 21:23 UTC by William Allen Simpson
Modified: 2011-06-22 20:02 UTC (History)
3 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description William Allen Simpson 2006-02-25 21:23:30 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:

    * {Era|year|month|day}

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
does now.

Other possible names for the Template could be "Era change" or "Era range", but
that's more to type and editors are often lazy.

Summary:

    * 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.
Comment 1 William Allen Simpson 2006-02-25 21:35:52 UTC
hmmm, that text didn't flow well.  Not eating our own dog food?
Comment 2 Rob Church 2006-04-21 06:05:54 UTC
*** Bug 5090 has been marked as a duplicate of this bug. ***
Comment 3 Rob Church 2006-04-21 06:06:09 UTC
*** Bug 5091 has been marked as a duplicate of this bug. ***
Comment 4 Jesse (Pathoschild) 2007-06-27 04:15:29 UTC
*** Bug 7239 has been marked as a duplicate of this bug. ***
Comment 5 Jesse (Pathoschild) 2007-06-27 04:17:04 UTC
Bug 7239 (marked as a duplicate) has a regex patch of '/includes/DateFormatter.php' by Bill Clark that seems to partially work.
Comment 6 Chad H. 2011-06-22 20:02:53 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links