I think that perhaps there is an opportunity to implement a more broadly useful feature here: content substitution based on user prefs. What if we came up with a more generic way to implement this type of behavior which could also be applied to other situations in which content is region or preference specific? Besides units of measurement, this could also be applied to date and time formats. 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 so 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.
Of course how or if this feature is actually used would be up to each wiki, but I imagine it could find a lot of different uses. Just a thought.
Ryan Kaldari
On 05/07/05, Ryan Kaldari kaldari@monsterlabs.com wrote:
I think that perhaps there is an opportunity to implement a more broadly useful feature here: content substitution based on user prefs.
One argument that somebody will no doubt bring up against this is that for server performance reasons, it is desirable to have as few things varying per user in this way as possible (since you can't serve a page cached with metric measurements to someone wanting imperial ones). Of course, we already do have this for dates, and I for one would certainly prefer "<date>15 January 2005</date>" to the current voodoo of "[[15 January]] [[2005]]".
I'm not usually keen on doing things client-side that can be more reliably done on the server, but I can see that there would be advantages to having a JavaScript implementation of these kind of variables. Perhaps some code could be written that by default served everyone the same page, with a personalised JavaScript inclusion, but somehow spotted JavaScript failure and fell back on a personalised rendering? I'm not sure how that would work, but it would certainly be handy - the alternative would be to simply deny such configuration to anyone without suitable JavaScript, which would be a shame.
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.
Just a quick qestion: if you have an automatic conversion system, why would you have a syntax that required specifying the data in more than one way? I know this is just an example, but it seems an odd one - especially since there are far more than two ways of formatting a date.
I was pleased to note that the test implementation someone posted to the list a while ago actually dealt with accuracy better than some users - it didn't make the mistake of turning "300 metres" into "328.08 yards", which is extremely unlikely to be true.
Interestingly, this example also alerted me to the fact that if we were to have an automatic unit converter, it might as well deal with the spelling of the units while it's at it: "liter" vs "litre", "metre" vs "meter", etc [Of course, some American units aren't the same as their Imperial counterparts anyway...]
wikitech-l@lists.wikimedia.org