It seems that people want the article on the recent attacks in Madrid to be at [[11 March, 2001 Madrid attacks]] rather than [[March 11, 2001 Madrid attacks]]. Myself, I don't care about the date format itself, but I hate that this could create inconsistency with the [[September 11, 2004 attacks]].
Shouldn't we be consistent in this respect across at least one Wikipedia?
Timwi wrote:
It seems that people want the article on the recent attacks in Madrid to be at [[11 March, 2001 Madrid attacks]] rather than [[March 11, 2001 Madrid attacks]]. Myself, I don't care about the date format itself, but I hate that this could create inconsistency with the [[September 11, 2004 attacks]].
Shouldn't we be consistent in this respect across at least one Wikipedia?
Well, we Americans (er, I mean U.S. residents) being so imperialistic, we have a long tradition on Wikipedia of forcing our conventions on the rest of the world. I'm joking of course.
In the tables for [[Montana]] (a state in the United States) and [[Germany]] (the country in Europe), we learn that Montana is 381,156 km^2 and Germany 357,022 km^2. To Americans such as myself, these numbers have no intuitive meaning. I know via conversion factors how long a kilometer is, if I stop to think about it, but still the numbers mean nothing.
This bugs me, but I consider that particular argument to have been lost a long time ago, and with good reason I suppose. (Although I think in the case of km^2, it would be sensible to express both numbers and not omit mi^2.)
As for the Madrid date, I express no opinion other than a fervent desire that we not get too heated up about it.
--Jimbo
On Monday 22 March 2004 15:04, Jimmy Wales wrote:
In the tables for [[Montana]] (a state in the United States) and [[Germany]] (the country in Europe), we learn that Montana is 381,156 km^2 and Germany 357,022 km^2. To Americans such as myself, these numbers have no intuitive meaning. I know via conversion factors how long a kilometer is, if I stop to think about it, but still the numbers mean nothing.
This bugs me, but I consider that particular argument to have been lost a long time ago, and with good reason I suppose. (Although I think in the case of km^2, it would be sensible to express both numbers and not omit mi^2.)
It is possible to change the software in such a way that, for example, {{num:km2:357022}} would render as 357,022 km<sup>2</sup> for users and visitors from Europe and as whichever mi<sup>2</sup> for users and visitors from the US.
On 03/23/04 05:59, Nikola Smolenski wrote:
It is possible to change the software in such a way that, for example, {{num:km2:357022}} would render as 357,022 km<sup>2</sup> for users and visitors from Europe and as whichever mi<sup>2</sup> for users and visitors from the US.
This is not a good idea. It will lead to silly pseudo-accuracy, of the sort often seen in sloppy journalism: where "a thousand miles" in a US wire report is carefully translated to "1.609 km" in an Australian newspaper article.
- d.
On Tuesday 23 March 2004 10:16, David Gerard wrote:
On 03/23/04 05:59, Nikola Smolenski wrote:
It is possible to change the software in such a way that, for example, {{num:km2:357022}} would render as 357,022 km<sup>2</sup> for users and visitors from Europe and as whichever mi<sup>2</sup> for users and visitors from the US.
This is not a good idea. It will lead to silly pseudo-accuracy, of the sort often seen in sloppy journalism: where "a thousand miles" in a US wire report is carefully translated to "1.609 km" in an Australian newspaper article.
Well, I doubt that this could be a problem. If the exact number is unimportant, the {{num:}} would simply not be used. If someone uses it wrongly, someone else would revert. Finally, there could be workaround for this, for example, {{num:~mi:1000}} might get out as "1600 km" (converted, then rounded to a precision of, say, original number/10).
Nikola Smolenski wrote:
On Tuesday 23 March 2004 10:16, David Gerard wrote:
On 03/23/04 05:59, Nikola Smolenski wrote:
It is possible to change the software in such a way that, for example, {{num:km2:357022}} would render as 357,022 km<sup>2</sup> for users and visitors from Europe and as whichever mi<sup>2</sup> for users and visitors from the US.
This is not a good idea. It will lead to silly pseudo-accuracy, of the sort often seen in sloppy journalism: where "a thousand miles" in a US wire report is carefully translated to "1.609 km" in an Australian newspaper article.
Well, I doubt that this could be a problem. If the exact number is unimportant, the {{num:}} would simply not be used. If someone uses it wrongly, someone else would revert. Finally, there could be workaround for this, for example, {{num:~mi:1000}} might get out as "1600 km" (converted, then rounded to a precision of, say, original number/10).
A better idea IMHO would be to guess the number of significant figures in the original number and to convert it to another number with the same accuracy. I saw in New Scientist recently "up to 3000 K (2737 C)", I have to say it annoys the hell out of me.
A possible algorithm would be that in a number with rightmost zeros left of the decimal point, or in a number with one significant figure, use one extra significant figure. In a number with no rightmost zeroes left of the decimal point but more than 1 sig fig, use the same number of significant figures. Finally, if the result is more than 20% different to the true value, extra digits are added to bring it to the appropriate accuracy.
So 3000 K becomes 2700 K due to the extra sig fig, 1 K becomes -273 C due to the 20% rule, 1.0 miles becomes 1.6 km, 1.000 miles becomes 1.609 km.
-- Tim Starling.
Nikola Smolenski wrote:
On Tuesday 23 March 2004 10:16, David Gerard wrote:
On 03/23/04 05:59, Nikola Smolenski wrote:
It is possible to change the software in such a way that, for example, {{num:km2:357022}} would render as 357,022 km<sup>2</sup> for users and visitors from Europe and as whichever mi<sup>2</sup> for users and visitors from the US.
This is not a good idea. It will lead to silly pseudo-accuracy, of the sort often seen in sloppy journalism: where "a thousand miles" in a US wire report is carefully translated to "1.609 km" in an Australian newspaper article.
[...] there could be workaround for this, for example, {{num:~mi:1000}}
Actually, I think a much better idea would be to stick to kilometers and other international standard metric units, and hope for the best that the US abandon their weird units in the long run...
Timwi wrote:
Actually, I think a much better idea would be to stick to kilometers and other international standard metric units, and hope for the best that the US abandon their weird units in the long run...
:-)
Not until my generation is dead and buried, at least. Back when I was in grade school in the 70s, they tried to teach us the metric system (which is clearly inferior and incomprehensible, by the way!) but it didn't take. Being an educated person, I can do the conversions, but I have no intuitive grasp of Celcius temperatures, nor do most Americans.
Seriously, though, at the present time there is no significant movement afooot to change our measurement system, nor does anyone seem to particularly care.
--Jimbo
--- Nikola Smolenski smolensk@eunet.yu wrote:
On Tuesday 23 March 2004 10:16, David Gerard wrote:
On 03/23/04 05:59, Nikola Smolenski wrote:
It is possible to change the software in such a
way that, for example,
{{num:km2:357022}} would render as 357,022
km<sup>2</sup> for users and
visitors from Europe and as whichever
mi<sup>2</sup> for users and
visitors from the US.
This is not a good idea. It will lead to silly
pseudo-accuracy, of the
sort often seen in sloppy journalism: where "a
thousand miles" in a US
wire report is carefully translated to "1.609 km"
in an Australian
newspaper article.
Well, I doubt that this could be a problem. If the exact number is unimportant, the {{num:}} would simply not be used. If someone uses it wrongly, someone else would revert. Finally, there could be workaround for this, for example, {{num:~mi:1000}} might get out as "1600 km" (converted, then rounded to a precision of, say, original number/10).
Why not use a conversion syntax that allows a question mark for one of the values, which then gets converted and replaced in the actual markup code. The editor could then correct the converted value for the context.
For example, {{num:mi:1000:km:1600}} would show "1000 miles" (or whatever) for a US user, and would show 1600 km for everyone else.
If the editor entered {{num:mi:1000:km:?}}, then it would be converted in the markup text as {{num:mi:1000:km:1609}}. The editor could then change that to read as the first example above, if desired. Similarly, the editor could express the value in km and leave the mi as a question mark...
This would allow a preference of either unit, or both.
By the way, I'm not at all stuck on this syntax -- I haven't given those details much thought. It the concept that I want to contribute.
-Rich Holton (Rholton)
__________________________________ Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. http://taxes.yahoo.com/filing.html
Last night while attempting to edit, Wikipedia kept going down several times. Or at least, I kept getting "Page cannot be found", and I had to keep Refreshing until it came back up. This morning I have tried to get on and have been unable to do so. I still get "Page cannot be found" and Refreshing is doing no good.
Is this something that only I am experiencing, or is it general?
RickK
Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time.
On Mar 22, 2004, at 9:04 AM, Jimmy Wales wrote:
In the tables for [[Montana]] (a state in the United States) and [[Germany]] (the country in Europe), we learn that Montana is 381,156 km^2 and Germany 357,022 km^2. To Americans such as myself, these numbers have no intuitive meaning. I know via conversion factors how long a kilometer is, if I stop to think about it, but still the numbers mean nothing.
This bugs me, but I consider that particular argument to have been lost a long time ago, and with good reason I suppose. (Although I think in the case of km^2, it would be sensible to express both numbers and not omit mi^2.)
I posted an idea to solve this problem at http://meta.wikipedia.org/wiki/ MediaWiki_feature_requests_and_bug_reports#Conversion_syntax, but I got no response (hint, hint...), so I don't know if it's feasible.
Peter
-- ---<>--- -- A house without walls cannot fall. Help build the world's largest encyclopedia at Wikipedia.org -- ---<>--- --