Last modified: 2005-07-05 19:45:11 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 2687 - need a way to provide alternate content for users with different date/time/measurement prefs
need a way to provide alternate content for users with different date/time/me...
Status: RESOLVED DUPLICATE of bug 235
Product: MediaWiki
Classification: Unclassified
User preferences (Other open bugs)
unspecified
All All
: Normal enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-07-03 18:30 UTC by Ryan Kaldari
Modified: 2005-07-05 19:45 UTC (History)
1 user (show)

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


Attachments

Description Ryan Kaldari 2005-07-03 18:30:23 UTC
Right now MediaWiki has a rather crude method of allowing users to view dates in
their preferred format. It would be quite useful if this system were replaced
with a system of specifying alternate content that was tied to a users
preferences, for example:

the plane was shot at ~~time|21:30|9:30 pm~~ on ~~date|15 January|January 15~~
causing the loss of ~~measurement|89 liters|23 gallons~~ of fuel.

Each user could then specify their preferred format:
time: 24-hour clock
date: European format
measurement: metric

This would solve several problems:
* The 12-hour/24-hour time debate (see Manual of Style (dates and numbers))
* Would no longer have the awkward convention of making all dates into links
just they are formatted a certain way
* Would no longer have to show both standard and metric measurements everywhere
in article contents, which makes them far less easy to read.
Comment 1 Ryan Kaldari 2005-07-03 18:40:21 UTC
Actually, I suppose you could implement it in the existing double-bracket or
double-brace markup (similar to how images or templates work):

the plane was shot at {{time|21:30|9:30 pm}} on {{date|15 January|January 15}}
causing the loss of {{measurement|89 liters|23 gallons}} of fuel.
Comment 2 Rowan Collins [IMSoP] 2005-07-04 03:05:06 UTC
I know you are suggesting slightly more than bug 235, in that you suggest
changing the existing behaviour of dates, but  most of the discussion taking
place or referenced there is very much to the point (especially the discussion
referenced in the bug 235 comment 14)

*** This bug has been marked as a duplicate of 235 ***
Comment 3 Tim Starling 2005-07-04 09:10:51 UTC
How is the current method crude? Formatting unlinked dates is just a matter of
adding a few extra rules to the list in DateFormatter.php, no markup change is
required. Adding a 12/24 hour preference is not much harder. The only one that
really does require wikitext clutter is measurement.
Comment 4 Rowan Collins [IMSoP] 2005-07-05 18:03:45 UTC
(In reply to comment #3)
> How is the current method crude? Formatting unlinked dates is just a matter of
> adding a few extra rules to the list in DateFormatter.php, no markup change is
> required.

Was there a reason this wasn't done in the first place? The thing that makes the
current date-formatter *seem* crude is that it forces you to link every single
date, because that's what triggers the voodoo; that means making an exception
for dates in any policy on when and when not to link, because even if it's
irrelevant or ugly, every date must get linked so people can customise it.
Comment 5 Rowan Collins [IMSoP] 2005-07-05 18:24:17 UTC
(In reply to comment #3)
> The only one that really does require wikitext clutter is measurement.

Oh, and I'm not convinced that's true, either. If it's reasonable to
automatically convert instances of the string "9:00 PM" to "21:00" if the user
desires it, surely it's just as reasonable to spot and convert "9 metres" to "10
yards" or "30 feet". I don't see that any of these conversions is more likely to
pick up false positives than the others, so either we always need markup to
trigger conversion/formatting, or we never do. Something like "9m" might be a
problem, but then so would "9 in the morning" or "the 9th of March", or anything
else which didn't happen to be covered in the input rules - whether or not it
was surrounded by "wikitext clutter".

(In reply to bug 235 comment #16)
> I do not believe that Bug 2687 is a duplicate [of bug 235], as it has nothing
to do with automatic unit conversion. Rather it is 
> a more generic suggestion to implement content substitution based on use prefs
(without any kind of 
> calculations or lookups).

It seems illogical to me to force an editor to first work out what the various
formattings/conversions of something are, then put them in the right order and
markup, just so that all but one can be hidden for any given user, when the
first step can more simply and reliably be left to the software itself. Doing it
"without any calculations or lookups" seems to me like asking for trouble: to
use your example syntax, what if someone puts ~~time|21:30|6:00 AM~~, or even
just forgets the syntax and puts ~~time|9:20 PM|21:00~~? One of the great
advantages of having the software deal with these issues *at all* is that it can
deal with them comprehensively: have as many variants as seem sensible, but with
minimal markup; automatically work out the appropriate conversions/formatting;
and even be more sane about levels of accuracy than many editors - I was pleased
to see that Matt Wright's implementation [1] didn't make the mistake many humans
do of suggesting that "300 metres" is equivalent to "328.08 yards".

Without that unnecessary manual-ness, your suggestion boils down to implementing
unit conversion (bug 235) + changing the syntax required for automatic date
formatting (essentially a separate request). [So I guess only half of it's a
duplicate, but there's no way of indicating that in Bugzilla other than opening
another bug for the other half :)]

[1] See http://mail.wikimedia.org/pipermail/wikitech-l/2005-June/030170.html and
replies
Comment 6 Ryan Kaldari 2005-07-05 18:45:15 UTC
Perhaps you are right that it makes more sense to do conversions automatically, although this does limit the 
flexibility of the solution. However, I would like to point out that the unit, date, and time problems are 
essentially 3 different versions of the same problem, and thus should be dealt with in the same fashion, 
whatever fashion that is. Having 2 or 3 different kludges for these problems isn't that helpful, IMO. The problem 
of user-specific content is a fundamental problem of wikis, and needs to have a fundamental solution.
Comment 7 Ryan Kaldari 2005-07-05 18:53:19 UTC
BTW, your last reply contained an excellent example of why automatic conversions
aren't necessarily a good solution:
in an American article you would want "10 yards" converted to "9 meters", but in
a British article you would want "10 yards" converted to "9 meters". Notice the
different spelling of meter.
Leaving it up to the article editors is more flexible and more closely mirrors
how it is done now (where alternate units are specified in parenthesis by the
editor.
Comment 8 Ryan Kaldari 2005-07-05 18:54:10 UTC
oops, I meant:
in an American article you would want "10 yards" converted to "9 meters", but in
a British article you would want "10 yards" converted to "9 metres".
Comment 9 Tim Starling 2005-07-05 18:58:38 UTC
(In reply to comment #4)
> Was there a reason this wasn't done in the first place? The thing that makes the
> current date-formatter *seem* crude is that it forces you to link every single
> date, because that's what triggers the voodoo; that means making an exception
> for dates in any policy on when and when not to link, because even if it's
> irrelevant or ugly, every date must get linked so people can customise it.

Sure, the reason was that the manual of style at the time was quite clear that
all dates should be linked. I was doing my bit to encourage compliance.
Comment 10 Rowan Collins [IMSoP] 2005-07-05 19:06:28 UTC
(In reply to comment #9)
> > Was there a reason this wasn't done in the first place?
> Sure, the reason was that the manual of style at the time was quite clear that
> all dates should be linked. I was doing my bit to encourage compliance.

Oh, fair enough. I'd always assumed the causality had flowed the other way, so
to speak.(In reply to comment #9)
Comment 11 Ryan Kaldari 2005-07-05 19:16:50 UTC
It seems odd that we ever encouraged people to always link dates. Apart from the formatting function I don't 
see any reason for it. As such, I would also hate to see us implement a solution that required linking all 
measurements and/or times. Surely, there must be a cleaner solution, automatic or not. Perhaps template tags 
would be a better way to go, or heaven forbid, a new syntax :)

manual template implementation {{time|15:30|3:30 pm}} {{date|4 July|July 4}}
automatic template implementation {{time|15:30}} {{date|4 July}}
new syntax implementation <<15:30 pm>> <<4 July>>
Comment 12 Rowan Collins [IMSoP] 2005-07-05 19:26:26 UTC
(In reply to comment #6)
> Perhaps you are right that it makes more sense to do conversions
automatically, although this does limit the 
> flexibility of the solution.

Actually, I rather think it *increases* the flexibility of the solution, since
making users explicitly enter all the valid variants immediately limits how many
there can be - or makes the syntax extremely unwieldy. By default, the existing
date formatter actually has 4 options, so your example would actually be
~~date|January 15, 2001|15 January 2001|2001 January 15|2001-01-15~~; and,
presumably, in that precise order (here's an experiment - look away and
reproduce that from memory, and see if you get the right formats in the right
places). 

> However, I would like to point out that the unit, date, and time problems are 
> essentially 3 different versions of the same problem, and thus should be dealt
with in the same fashion, 
> whatever fashion that is. Having 2 or 3 different kludges for these problems
isn't that helpful, IMO. The problem 
> of user-specific content is a fundamental problem of wikis, and needs to have
a fundamental solution.

Yes, that seems fair enough. Currently, we only solve one of them, so in a sense
we do have a uniform solution. But I certainly agree that that solution should
be generalised, rather than reinvented, if we want other similar features.
Whether we need special markup or not is a slightly different question; I'm
beginning to think not, as long as there's a way of overriding the behaviour
when really necessary (<nowiki>, probably).

(In reply to comment #8)
> in an American article you would want "10 yards" converted to "9 meters", but in
> a British article you would want "10 yards" converted to "9 metres".

Actually, the convention of using different spellings for different pages is
only a kludge because we can't agree on another kind of "user-specific content",
namely automatic translations between English dialects. If you were giving
people the option of selecting "metric" versus "imperial", why not also let them
choose "metric (UK spelling)" versus "metric (US spelling)"? I have no
particular desire to see "9 meters" just because I'm reading a US article, I
simply put up with it being there as a compromise; "9 metres of colored fabric"
might look slightly odd if you were copyeditting thoroughly, but I wouldn't give
up the ability to have "metres" just because I couldn't also have "colour".
Comment 13 Rowan Collins [IMSoP] 2005-07-05 19:27:59 UTC
(In reply to comment #11)
> manual template implementation {{time|15:30|3:30 pm}} {{date|4 July|July 4}}
> automatic template implementation {{time|15:30}} {{date|4 July}}
> new syntax implementation <<15:30 pm>> <<4 July>>

Or none of the above - if, as Tim says, dates are only linked because they
already were, why not let the parser spot "15:30 pm" and "9 yards" of its own
accord?
Comment 14 Ryan Kaldari 2005-07-05 19:37:09 UTC
That's an interesting proposition, although it brings up 2 questions:
1. how much of a server load would that be?
2. how much would automatic conversion confuse or bewilder editors (especially
new ones)

On point 2, I can see an easy solution: have the default preference for date,
time, and units be set to "No conversion" for all new accounts.
Comment 15 Rowan Collins [IMSoP] 2005-07-05 19:45:11 UTC
(In reply to comment #14)
> That's an interesting proposition, although it brings up 2 questions:
> 1. how much of a server load would that be?

How much load would what be? Having a slightly more complex regex to spot the
items-to-be-converted, rather than relying on /<<(.*?)>>/ or whatever? I guess
it would add something, but presumably the date code does something not all that
far off already...


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


Navigation
Links