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.

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

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.

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.

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

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.

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.

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

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

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)

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

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

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?

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.

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