Last modified: 2010-05-15 15:38: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 1668 - $wgUseDynamicDates should be split in two, $wgUseDynamicDates and $wgUseDates
$wgUseDynamicDates should be split in two, $wgUseDynamicDates and $wgUseDates
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Internationalization (Other open bugs)
1.5.x
All All
: Normal enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks: 248
  Show dependency treegraph
 
Reported: 2005-03-09 03:54 UTC by Ævar Arnfjörð Bjarmason
Modified: 2010-05-15 15:38 UTC (History)
0 users

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


Attachments
A (rough) proposal. (5.24 KB, patch)
2005-03-24 09:01 UTC, Ævar Arnfjörð Bjarmason
Details

Description Ævar Arnfjörð Bjarmason 2005-03-09 03:54:52 UTC
Note: this bug is not a duplicate of bug 248.

$wgUseDynamicDates should be split in two, $wgUseDynamicDates and $wgUseDates,
i.e. one for the whole [[January 1]] [[2005]] => [[2005]]-[[January 5|01-01]]
thing and another ($wgUseDates) for the "Date format" option in the preferences
which would only affect the output of the date(),time() and timeanddate()
functions in the language file. Both could then be switched on to achive the
current effect.

Ideally, from the $wgUseDates point of view this would be done by parsing the
$wgDateFormatsXx array, which is currently for english;

array( 'No preference', 'January 15, 2001', '15 January 2001', '2001 January
15', '2001-01-15' );

Just do array_shift and then use the numbers in a switch statement, this would
ensure that the array can be made smaller for languages who don't need such a
long format or larger for those that do.

$wgUseDates should probably be turned on in the language file rather than in
LocalSettings, this should be an interface feature like any other.
Comment 1 Rowan Collins [IMSoP] 2005-03-10 18:19:05 UTC
Just a comment that "$wgUseDates" doesn't seem like a very good variable name to
me - it makes me want to ask "use them for what"? What you seem to be asking for
is more along the lines of a "$wgUseDatePreferences", as in a feature to let
users specify how they want dates in the interface to appear (even if this
doesn't include automagically munging dates in the text); am I right?
Comment 2 Ævar Arnfjörð Bjarmason 2005-03-10 18:22:13 UTC
You're right on both accounts, that is what I want to do and
$wgUseDatePreferences is a much saner variable name.
Comment 3 Ævar Arnfjörð Bjarmason 2005-03-24 09:01:51 UTC
Created attachment 380 [details]
A (rough) proposal.  

A (rough) proposal.

A rough mockup of a proposal to solve this:
* date formats are read from $wgDateFormatsXx, this array should contain no
more than 100 items (10 is probably enough, please comment) where number 0 is
an indication of the default an 100 is the ISO 8601 formatted date. (perhaps it

would be better to not have it a number but iso => ...)
* The option is then set in the preferences which automatically display the
"Date format" option of the $wgDateFormatsXx array is not empty, however if the

language in question wishes to not use this at all they'll have to set
$wgDateFormatsXx = array();  because otherwise it'll be read from the parent
(usually Language.php)

Note that since the date format is set by numbers we could get drastic changes
between languages where e.g. item 3 in the array can mean something different
in de. and on en. and fo., I don't have a definite way solve this in a smart
manner we can'tguarentee that formats will be at all alike between languages
however this could be solved by using an associative array where some defaults
will always be the same:

$foo = array(
  default => something default here...
  long => "the standard long format for this language" (like en:"January 23,
2005" or is:"23. janúar 2005")
  abbrev => "the abbrivated format" (en:"Jan 23, 2005", "23. jan. 2005")
  numeric => "the standard numeric format: (en: 23.01.2005, is: 23/01/2005)
  iso => "the iso 8601 format" (all: 2005-01-23)
);

then of course each language could add something new using a key which is not
one of the reserved values.
Comment 4 Ævar Arnfjörð Bjarmason 2005-03-26 01:28:40 UTC
Fixed in HEAD (although the final implementation was different than the one
described here.)

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


Navigation
Links