need a way to provide alternate content for users with different date/time/measurement prefs
Closed, ResolvedPublic

Description

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.


Version: unspecified
Severity: enhancement

bzimport added a subscriber: wikibugs-l.
bzimport set Reference to bz2687.
kaldari created this task.Via LegacyJul 3 2005, 6:30 PM
kaldari added a comment.Via ConduitJul 3 2005, 6:40 PM

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.

bzimport added a comment.Via ConduitJul 4 2005, 3:05 AM

rowan.collins wrote:

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 ***

tstarling added a comment.Via ConduitJul 4 2005, 9:10 AM

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.

bzimport added a comment.Via ConduitJul 5 2005, 6:03 PM

rowan.collins wrote:

(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.

bzimport added a comment.Via ConduitJul 5 2005, 6:24 PM

rowan.collins wrote:

(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

kaldari added a comment.Via ConduitJul 5 2005, 6:45 PM

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.

kaldari added a comment.Via ConduitJul 5 2005, 6:53 PM

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.

kaldari added a comment.Via ConduitJul 5 2005, 6:54 PM

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".

tstarling added a comment.Via ConduitJul 5 2005, 6:58 PM

(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.

bzimport added a comment.Via ConduitJul 5 2005, 7:06 PM

rowan.collins wrote:

(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)

kaldari added a comment.Via ConduitJul 5 2005, 7:16 PM

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>>

bzimport added a comment.Via ConduitJul 5 2005, 7:26 PM

rowan.collins wrote:

(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".

bzimport added a comment.Via ConduitJul 5 2005, 7:27 PM

rowan.collins wrote:

(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?

kaldari added a comment.Via ConduitJul 5 2005, 7:37 PM

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.

bzimport added a comment.Via ConduitJul 5 2005, 7:45 PM

rowan.collins wrote:

(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...

Add Comment

Column Prototype
This is a very early prototype of a persistent column. It is not expected to work yet, and leaving it open will activate other new features which will break things. Press "\" (backslash) on your keyboard to close it now.