Last modified: 2005-07-05 19:45:11 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.
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.
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.
(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.
(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.
(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>>
(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".
(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.
(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...
