User talk:Lightmouse/Archive/2007Oct

Monobook code question about square meters
Lightmouse,

I've been tinkering with the monobook code a little, but I haven't had much time lately. My question is: How do I get the code to recognize 'sq m' (square meter) without recognizing 'sq mile' or 'sq mi'? Take a look a my monobook when you get a chance. &mdash;MJCdetroit 16:42, 18 September 2007 (UTC)


 * Will do later, but I am dashing out now. Lightmouse 16:49, 18 September 2007 (UTC)


 * Quick thought. You can do a NOT using '[^i]'. Lightmouse 16:53, 18 September 2007 (UTC)


 * I took a quick look. Where you have:
 * sq(?:\s|-| )m(?:\s|-| )([^\(]{2})/gi
 * Replace it with:
 * sq(?:\s|-| )m([^i\(]{2})/gi
 * This will add a NOT at the end that tests for the presence of the 'i' character. It also tests for the presence of an open parenthesis character '\('. This necessary because you don't want to run it if the conversion is already there. The square brackets '[ ]' define the legal characters in the test. The up arrow '^' makes it a NOT. The '{2}' bit simply runs the test twice. I took out the '(?:\s|-| )' because that is looking for separators and is not needed there. Lightmouse 17:16, 18 September 2007 (UTC)


 * Actually, this is better:
 * sq(?:\s|-| )m(\W[^\(])/gi
 * The '\W' tests for a character that is not alphabetical. I can still foresee some false positives but let me know how you get on with that. Lightmouse 17:25, 18 September 2007 (UTC)


 * Thanks, I will when I get a chance. I guess you didn't like my humor above :(   &mdash;MJCdetroit 18:57, 18 September 2007 (UTC)


 * Aha. I see now that I deleted a comment of yours. Sorry. It was not deliberate. It was as a result of an edit conflict and focussing on this section only. Lightmouse 21:28, 18 September 2007 (UTC)


 * I still couldn't get it to work. It kept taking sq miles and replaced it with m²iles in Healy, Alaska and in List of islands in lakes it did this. Any thoughts? &mdash;MJCdetroit 03:44, 20 September 2007 (UTC)

There are two errors. Firstly, the square metre code is not being told to detect the end parenthesis '\)' character. That is easy to fix, you just add it to the NOT section. Thus [^i\(] should be [^i\(\)].

Secondly, it should not be converting text with the letter 'i' and that is also the problem with 'm²iles'. I can't see why you are getting that problem with [^i] or with \W.

Let's simplify it and test the function of NOT for the 'i' character. We will forget about nbsp and hyphens. We will only deal with integers up to 999 sq m. Try the following code:
 * txt.value=txt.value.replace(/([^\d,\.])(\d{1,3})\ssq\sm([^i\(\)]{2})/gi, '$1$2 sqm$3');

Run it on this page for: It should do something bad on '700 square meters'. Lightmouse 15:10, 21 September 2007 (UTC)
 * The areas are 37 sq m and 978 sq m. The annex is 16 sq m with a rug of 9 sq m. The region is 90 square miles. Each house has an area of 700 square meters.


 * The city is 90 sq miles. Trying a different test. &mdash;MJCdetroit 15:56, 21 September 2007 (UTC)


 * Sq miles is still getting confused for sq m (see the diff). Check out the first few lines of the 'square metre' section in my code.  Maybe the m²iles in Healy, Alaska is coming from the sq (m|metres|meters|metre|meter)/gi part. Also, was this the appropriate line to replace my code &mdash;MJCdetroit 16:19, 21 September 2007 (UTC)


 * The (m|metres|meters|metre|meter) will definitely cause the symptoms. You need to stop that bit of code working before you can test the rest. I do not know about the appropriate line, it seems fine to me. Incidentally, you can comment code out temporarily by adding '//' at the beginning of the line, you will see plenty of examples of that. Lightmouse 16:33, 21 September 2007 (UTC)


 * Thanks, like I said before, I know nothing, I mean nothing about these scripts. I stole/borrowed them from you, who appears to have taken a big chunk from User:Bobblewik's code.  In any case you know more than I, so any advise or knowledge passed on helps.  What I meant by the appropreiate line was that I wasn't sure if the line I replaced was the "integers up to 999" line or not.  Now, I have to get back to work :( and make some money. &mdash;MJCdetroit 16:47, 21 September 2007 (UTC)


 * As you say, the code is not original. I am one page in the book ahead of you but only because I have done patch&mend and trial&error. As far as the appropriate line is concerned, I suggest that you delete the entire square metre section and just have that one test line. Lightmouse 17:48, 21 September 2007 (UTC)


 * Commenting out the first few lines and changing the sq m lines to use your suggestion of sq(?:\s|-| )m(\W[^\(])/gi seems to have done the trick. Please copy the square meter section of my code and test it out. &mdash;MJCdetroit 19:58, 22 September 2007 (UTC)


 * I have tested it and have the following comments:
 * The precision needs adjusting. The original code (sq ft -> sq m) deliberately reduces significant figures by one. This is because 100 sq ft is only about 10 sq m. You are going the other way so you need to increase it by one. This means that the code may actually be two sig fig wrong when applied to sq m. It is, of course, up to you but you might want to look at that in your own testing. I made a request for the convert template to look at sig fig and do this automatically.
 * You have a trailing spaces in the code ' (metres|meters|metre|meter)/gi' and 'replace(/(\d) sq (metres'. They are bad. On that side of the expression you cannot have spaces like that. If you really want a space character, you must use: '\s'.
 * You have a trailing space in the code 'sp=us }}' that appears unnecessary. It seems harmless, but I did not test it.
 * Congratulations on getting it working. As you know, I prefer not to run code converts metric into non-metric. Now that I have tested it, I will take it out again. I hope you don't mind. Lightmouse 09:35, 23 September 2007 (UTC)

A few suggestions for your monobook code

 * 1) Change the 'gen fixes' to something more specific.  I changed this in my code to Format per WP:MOSNUM-- units and/or dates.  Gen fixes seems too vague.
 * I changed it to "wp:mosnum format: units and/or dates". I think lower case is friendlier. I also worded it to make it as short as possible. This is to make it less intrusive when it appears several times in the recent changes list.


 * 1) Place a non-breaking space between your direct value replacements like (1.9 km), (1 m), and (76 mm)
 * I ensure that a space is present but I not a fan of the non-breaking space code. I think the pain of prevention is worse than occasional encounters with the disease. At your suggestion, I have added them to a few cases but I hope you don't mind if I opt out of it later. Once a space of some kind is there, it is relatively easy for anyone more enthusiastic about it than I am to change the space to a different type of space.


 * 1) Is this a typo or done on purpose:     //mi([^l²\(\)]{2})al mile? It struck me as odd.
 * It is a typo. It must be as a result of sloppy global search and replace. Thanks for spotting it. Fixed now.


 * 1) Add a few lines to the top of the square miles section to change incorrect abbreviations (miles², mi²) to sq mi.  See my square mile section.
 * Done. Thanks.


 * I am still getting some errors relating to 'feet' and 'square feet'. If the text has ft², my code will not see the superscript ². It will make the incorrect conversion for linear feet. For some reason I can't get the NOT code working properly. Watch out for that one with squares/cubes and for feet/metres. Lightmouse 09:35, 23 September 2007 (UTC)

&mdash;MJCdetroit 19:58, 22 September 2007 (UTC)

Another suggestion, kt is short for kiloton (nuclear weapon power) as well as knot (nautical mile per hour) I would suggest you remove that part of your script or make it optional as it has already affected at least one page http://en.wikipedia.org/wiki/Armament_of_the_Iowa_class_battleship. You might also want to check to see if the script has been used on any of the nuclear weapon articles as it could probably do quite a bit of damage there. 70.70.136.240 07:20, 26 September 2007 (UTC)


 * FYI, that IP address posting above was NOT made by me. I think that it would be clear when something is being discussed in knots or kilotons. &mdash;MJCdetroit 13:21, 26 September 2007 (UTC)


 * I am aware that kt is short for kiloton. I had forgotten about it when focussing on knots. Perhaps that is a clear argument against using kt for knots. Thanks for spotting the incorrect change and fixing it. I will watch for out for them and try to ensure it does not happen again. Thanks again for picking it up. Lightmouse 08:27, 28 September 2007 (UTC)

monobook script question involving commas
In the monobook script, how do you get the code to do unit conversions when there is a comma after an abbreviation? For example: 30 mi, but 18 mi long, but 20 miles, will convert. I think adding a \W after will help, but I am not positive. Any thoughts. &mdash; MJCdetroit 20:39, 26 September 2007 (UTC)

\W didn't work well. However, this statement seems to do the trick: mi(\,|\s[^\(\/]{2}) ... &mdash;MJCdetroit 20:40, 27 September 2007 (UTC)


 * Your code looks good to me. You might want to do something similar with other punctuation characters such as a period, but take it one step at a time. The period character sometimes means multiplication or unit combination:
 * mi(\,|\.|\s[^\(\/]{2})
 * Congratulations on fixing it. Lightmouse 08:31, 28 September 2007 (UTC)

Your wp:mosnum edits
I noticed that many of your recent edits have been mass reformats of (most of) the numerical links on a single page, and your edit description has cited wp:mosnum. As far as I can see, wp:mosnum actually discourages these kinds of edits. In the introduction, the wp:mosnum page says :
 * ... (W)hen either of two styles is acceptable, it is inappropriate for an editor to change an article from one style to another unless there is a substantial reason to do so ... If an article has been stable in a given style, it should not be converted without a style-independent reason. Where in doubt, defer to the style used by the first major contributor.

For example, on the Metropolitan Museum of Art page, you un-linked a large number of year dates in a single edit. I'm unclear as to why you did this, since the wp:mosnum page does state that these kinds of mass style edits are to be discouraged. Usually, multiples of the same wikilinked item in a single article are "consolidated" by retaining only the first appearance in the text, and unlinking any subsequent repetitions of the same item, but this wasn't the case for these dates. If I'm misinformed about your rationale for these edits, please respond either here or on my talk page and we can clear this up. Best, -- Docether 15:25, 5 October 2007 (UTC)


 * wp:mosnum does not entirely define my edits. The edit summary statement is formatted like that because somebody asked me to use it.
 * Those links seem to me to be just like plain english words. If somebody really wants to know what happened in one of the years like 1993, they can simply type the four digits into the search box. Links to museum related topics such as Cesnola Collection and Beaux-Arts are more relevant.
 * You will notice that I also provided a unit conversion.
 * However, if you have an alternative view of how the article should be, feel free to edit the article whichever way you think best. Regards Lightmouse 16:11, 5 October 2007 (UTC)

Template:Unit acre using hectares or km²
Hi Lightmouse, I'm thinking of changing Unit acre to output km² instead of hectares. What do you think of this? Do you always convert acres to km² even for small acre values e.g. 1 acre? Thanks, PatLeahy (talk) 02:34, 10 October 2007 (UTC)


 * I am delighted that you are thinking of this. Hard coding a word-for-word translation is always going to be a limitation. This applies to languages and to measurement systems. It is easy to identify the same issue with weight units and volume units.


 * Going down to 0.1 seems unremarkable to me. Therefore I support any plan you have to go down as far as 0.1 km². Coming up from the bottom you have m² and there appears to be no upper limit on that. A value expressed as 900,000 m² is also unremarkable to me. If I saw "0.004 km²", I would probably want to edit it into 4,000 m².


 * I believe that all conversion templates should permit the user to select the output unit. That is one of several reasons why I like the 'convert' template. I definitely support your thoughts that the 'Unit acre' template should be updated. If you were to make it permit the user to choose an output of ha, m² or km² (as the 'convert' template does), I think that would address the problem that you have identified.


 * I would go further and suggest an 'area' template where the input and output units are selectable. Keep an eye on the discussions on the 'convert' template talk page (I am sure you already do). People are discussing rationalising the whole series of templates and I think this is a worthy thing to do. Lightmouse 10:12, 11 October 2007 (UTC)


 * I think one of the benefits of Unit acre and its friends is that editors not familiar with different systems don't have to know what is the appropriate secondary unit. I'll follow up these issues at Template talk:Convert. -- PatLeahy (talk) 19:35, 11 October 2007 (UTC)


 * I made this change to . You might want to consider not replacing  with undefined undefined from now on.
 * By the way, having the output unit change depending on the side of the input may make it confusing for people to figure out a good rounding argument. -- PatLeahy (talk) 06:40, 12 October 2007 (UTC)


 * I understand that a default word-for-word translation helps novices. My concern was for instances where the default is not appropriate. The 'convert' template has options with no default. The 'Unit' series has defaults with no options. We could have the best of both if it retains the default and also has options for non-novices. This could work just the same as the existing methods for 'lk=on' and 'sing=on'. That would satisfy the needs of novices and everyone else.


 * The new default operation is very welcome for me. To reassure you, I see no reason to replace any instance of the current version of 'Unit acre' with 'Convert'. Unfortunately, I think others will complain that some instances of the template's choice are not right for the context. Personally, I cannot see any solution whereby advanced users will not want to adjust the default output. I am keen to see what feedback arises with the recent change. Thanks for putting your efforts into this. You are doing great work. Lightmouse 09:30, 12 October 2007 (UTC)

Script breaks link to shaft horsepower
Hey Lightmouse! Hope everything is going well. This morning I noticed a small error caused by your script. On Bayern class battleship, in the Propulsion field of the infobox, "shp" previously linked to the shaft horsepower section of the horsepower article. However, your edit added a space where it didn't belong and broke the link so that it only goes to the top of the horsepower article. TomTheHand 13:20, 18 October 2007 (UTC)


 * Thanks for the feedback. I should have spotted that by eye. I am not sure if a script can avoid that specific error although I am working on an improvement that should greatly reduce false positives. Regards. Lightmouse 13:26, 18 October 2007 (UTC)


 * One possibility might be for your script to look for things like .28 and .29 inside a link, to the left of the pipe |, and replace them with ( and ). TomTheHand 13:36, 18 October 2007 (UTC)


 * Very interesting. I did not notice that the .28 and .29 were parentheses. I can do it locally in my script and will do so later. Thanks for the suggestion. However, the problem will still exist elsewhere. It seems that is work for a bot to search and replace throughout Wikipedia. I have asked at wp:botreq and I hope you will add a supporting comment. Regards. Lightmouse 13:51, 18 October 2007 (UTC)


 * I have now amended my script. I have not used it on the Bayern article because I want the people at wp:botreq to see the .28 and .29 still there. Lightmouse 14:22, 18 October 2007 (UTC)


 * I have, however, fixed the broken link. Thanks again. Lightmouse 14:24, 18 October 2007 (UTC)

conversion style
The template seems to be doing one thing better than many other comparable editing conventions: it's much easier to read customary unit (SI conversion) than the unfortunate customary unit/SI conversion. Howard C. Berkowitz 17:32, 19 October 2007 (UTC)


 * That is a good point. I had not thought about it. Perhaps I will suggest recommending the parentheses style at wp:mosnum. Lightmouse 19:01, 19 October 2007 (UTC)

Unit conversion
Hello lightmouse. I see you have been very busy adding unit conversions, good effort! However, the script / template / or however you go about it is having 2 effects I thought I should draw your attention to; You may wish to incorporate these thoughts into your editing machine, otherwise, keep up the good work. Emoscopes Talk 18:58, 18 October 2007 (UTC)
 * 1) it is putting spelled out units in (e.g. knots), where wp:mosnum says that the abbreviation should be used in infoboxes and tables.
 * 2) it is breaking the links to the abbreviated units; particularly knots and nautical miles, which to many users might be unfamiliar quantities that are useful to be linked to in the first instance.


 * Thanks for the feedback.
 * Knots. There are many different abbreviations (e.g. 'kts' 'kt', 'knt', 'kn') with a variety of permutations of upper and lower case. The script eliminates the inconsistency. This is a good thing. However, I would like to use an abbreviation, as you suggest. Unfortunately, the abbreviation has been discussed many times but no stable agreement exists for the whole of Wikipedia. As soon as I know the correct abbreviation, I will update the script. I would be delighted if you would contribute to the current discussion about this.
 * Removed links to common units. I think links to common units (e.g. mile, foot, km, kg) are excessive. However, I can understand that links are useful if a conversion is not provided. If the conversion is provided right there beside the unit, then such links are no longer necessary.
 * Removed links to uncommon units. I agree with you that links to uncommon units (e.g. knot, nautical mile) might provide more information than conversion e.g. background, history etc. I would like to leave these links untouched and add an unlinked conversion. Unfortunately, the convert template cannot link knot but not km/h. There is a live request to change the convert template so that it will do what you ask. Please feel free to add a supporting comment for that feature.
 * I appreciate your feedback. Lightmouse 15:29, 19 October 2007 (UTC)


 * If you look at articles of mine in a variety of topics, ranging from computer networking to intelligence technologies, you will find that I routinely use SI. I do not, however, find it useful to find conversions that show false precision, with decimal digits following the conversion of an integer value of a customary unit. About the only place where I use customary units is in nautically-related articles, where there is a reason for the use of knots and nautical miles, especially where they are the exclusive units in treaty language ratified by SI-using countries. Ordnance is another area where I would see a value to customary units, to give the flavor, for example, of arguments over capital ship gunnery in such things as the battle between Fisher and Beresford. An infobox, perhaps, but if anyone is going to read beyond the article in those matters, they are going to need to know the customary units.


 * It's not that SI is unambiguous. There are MKS and CGS conflicts, and molar versus weight conflicts. In medicine, it is essential to provide both of the latter, even though I still thing of blood sugar in milligrams. Howard C. Berkowitz 21:52, 22 October 2007 (UTC)


 * Hi Lightmouse. May I add by ha'penny worth regarding I think links to common units (e.g. mile, foot, km, kg) are excessive? With km and kg I agree, but you've probably noticed I like linking foot and mile on 1st use. Here's why:
 * The foot is an everyday unit for native English speakers, but I believe that Wikipedia should cater for non-native speakers too, and I know several (fluent) non-native speakers who go running for a units converter whenever I mention this unit. It is for these non-native speakers that I link the foot.
 * The mile is ambiguous except on land, so it first needs to be specified whether it's nautical or statute. At the mention of either adjective even native speakers of English go running for a dictionary.
 * Thunderbird2 15:51, 21 October 2007 (UTC)


 * I agree that non-metric units are obscure for many. To suit the needs of those that "go running for a units converter", there are three options:
 * convert (do the work for the reader)
 * link (let the reader do the work)
 * link and convert (do the work for the reader and let the reader do the work)
 * I am merely suggesting that if the reader has the conversion, the need to "go running for a units converter" is eliminated. There may be other reasons for a link, but the need to convert that specific value has gone. Lightmouse 21:26, 22 October 2007 (UTC)


 * Don't get me wrong - you're doing a sterling job.
 * For the foot I agree with you - if a conversion is provided, there is no longer an obvious need for a link, though it does no harm either. For the mile I think it depends on context, but basically we agree I think :) Thunderbird2 21:50, 22 October 2007 (UTC)


 * Yes. I think we agree. And thanks for the praise. I agree that the mile is more ambiguous than the foot. Ironically, I have seen more unnecessary linking of (unambigous) metric units such as km than of (ambiguous) non-metric units such as mile. Lightmouse 22:00, 22 October 2007 (UTC)