User talk:GregU/dashes.js/archive

This tool will fix hyphens, dashes, and minus signs per MOS:DASH. It works better than the other tools I've heard of.

To install, add the following line to your personal JavaScript page:

importScript('User:GregU/dashes.js');

Then hit refresh in your browser. The installed script will add a "–" tab to the drop-down tab at the top, located between the 'watchlist star' and the search box (using the vector.js skin)

You can use the "–" tab when you're viewing an article or when you're already editing it. Pressing it will make the fixes, leaving you viewing the changes. You should review the changes because the tool will occasionally (rarely) make a mistake. You can undo changes or make your own changes, then hit "Save page" when done.

• If inside wikEd, you will need to hit the pencil icon to temporarily disable wikEd in order to use this tool.
• If using AutoEd, you will need to custom list your modules, including this script as one of the modules. It is currently not possible to use both AutoEd and dashes.js independently of each other.

See also:  hotkeys.js – Firefox tool for easily typing dashes (or other symbols or macros)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

p. 101-114 and em dashes

Hello again! I have another smallish feature request which you might wish to add: The tool corrects page ranges, such as "pp. 85-97" correctly. However, in cases like "p. 101-114", the hyphen is preserved. It is of course reasonable to expect that "p." is followed by a single page number, but unfortunately opposite cases are rather common. So my suggestion would be correcting the hyphen and also changing the "p." to "pp.".

This was on purpose, as there are some cases like p. 11-70 here where it really is a single 2-part page number which should remain hyphenated. The script uses the preceding p. or pp. as the hint for which case it is. (It does the same for no. and nos. — no. 3-20 probably an id number; nos. 3-20 probably a range.) Granted in most cases p. was probably used incorrectly, but I think it would be presumptuous to turn p. 11-70 into pp. 11–70 automatically. Having said that I agree this is probably the biggest remaining source of false negatives, and will give it some thought. —GregU (talk) 15:46, 17 October 2009 (UTC)

About the spaced em dash case – the reason I brought this up was the MOS statement: Em dashes should not be spaced. This is easy to fix by removing the spaces or converting the em dash to en dash. Also, I don't see much room for false positives, when this is done only between two words. They shouldn't occur inside templates, URLs, wikilinks or filenames. Do you find the use of spaced em dashes stylistically acceptable and not a real issue? This could of course be made an optional feature. I, however, don't see any reasons for this not be added. —Quibik (talk) 15:34, 16 October 2009 (UTC)

I agree spaced em dashes should normally be changed to either unspaced em dashes or spaced en dashes, per MOS:DASH. The problem I see is, they are best changed to unspaced em dashes in some cases, and best as spaced en dashes in other cases, and I'm not sure my script can make this determination. That's what I mean by false positives (perhaps the incorrect term), as adding this to the script will probably end up being the main thing that it guesses wrong on, in the eyes of an experienced editor. Links and URLs and such are not a problem, it's easy for the script to detect those.

For example, in Dilbert#Media I think spaced en dashes would be the way to go. (Or some editors may even say a MOS exception is warranted here because the list items are complicated enough that the longer spaced em dash looks clearer.) But in most other cases, unspaced em dashes are probably best. Perhaps this heuristic would be sufficient: If it's a list item and there's exactly one em dash, then change a spaced em dash to an en dash. For other cases, change to an unspaced em dash. —GregU (talk) 06:43, 26 October 2009 (UTC)

Another example is in featured article I Don't Remember. —GregU (talk) 03:42, 13 November 2009 (UTC)

Saw another example in featured article Blade Runner. —GregU (talk) 04:48, 6 December 2009 (UTC)

To do

• I don't see this addressed in WP:MOS, but I'm thinking it's best not to change double-hyphens to em dashes when they occur in the titles of works (inside <ref>), such as this. Same theory as not fixing misspellings or creating links inside of quotations. Though I do believe in converting to range dashes (e.g., 1885–1892) in the same. Thoughts?

  Some discussion here about this. —GregU (talk)

How to use it

Will you include a set of instructions, for wikidummies? Auntieruth55 (talk) 15:04, 4 November 2009 (UTC)

Sure, I've started some at the top of this page. Let me know if you have any questions. —GregU (talk) 15:50, 4 November 2009 (UTC)

OH This is really cool. do you have one that will add the spaces after numbers???? Auntieruth55 (talk) 16:45, 4 November 2009 (UTC)

I'm not sure what you mean. Please elaborate and I should be able to help. —GregU (talk) 21:40, 4 November 2009 (UTC)

one that adds the nonbreaking space wikiups. Auntieruth55 (talk) 23:21, 4 November 2009 (UTC)

You mean like (36&nbsp;km)? I'm surprised if there already isn't a script that does this, but I can't find it off-hand. I will whip something up, unless someone else points out an existing script that does this. —GregU (talk) 15:43, 5 November 2009 (UTC)

Book titles and web titles

I think this tool should not touch dashes in the title= or work= parameters of references to books, magazines, or any web-based resource. It is wrong to insert a particular type of dash where a different one exists in the original. --Simple Bob (talk) 10:28, 12 November 2009 (UTC)

I was a little concerned about this myself a while back, and in researching it I found that this issue has come up on the Manual of Style discussions. The consensus there was that this is more of a typographical change than a punctuation change, and it is standard practice among publishers to use a consistent house style when typesetting references. Another point was that online citations often already have dumbed-down the typography from that of the original source, so you're often just copying someone else's house style anyway rather than the original. —GregU (talk) 13:16, 12 November 2009 (UTC)

Understood. However, I don't think you should change web page titles, and I don't see why you feel the need to change web page titles. What is wrong with using exactly what is on the original? --Simple Bob (talk) 13:27, 12 November 2009 (UTC)

Well it's more that this is the default behavior, and is there a need to treat web page titles as a special case, making their style inconsistent with the other titles? I'm interested in hearing other input on this; perhaps a question better for WP:MOS. —GregU (talk) 14:34, 17 November 2009 (UTC)

Issues caused by the "standalone" addition

Hi. You added the "standalone" feature to the script nearly 2 weeks ago and this has been causing an unwanted side-effect for me since then. As I understand it, the "if (importScript("Wikipedia:AutoEd/core.js")" part is intended to return false and not continue, if the "AutoEd/core.js" has already been imported. Of course I am importing that script in my monobook.js as well. However, I am doing it the way the AutoEd scripts (for example Wikipedia:AutoEd/basic.js) implemented it: using full URLs. So the new feature is not working as intended for me. This not only adds an unnecessary extra button for me, but also hijacks the AutoEd button and converts it to a duplicate of the dashes.js one. Presumably, when the script is added to the core AutoEd functionality, full URLs will be used as well. So, I think this problem should be looked into. Perhaps moving the standalone button functionality to a separate script?

My script is only usable with AutoEd if you're customizing the modules, and the documentation for that says to use importScript() rather than the longer importScriptURI(). So if you follow that, it should work. (I can't easily make it work both ways.) I'm not sure why the presets like basic.js still use importScriptURI() as I don't see any advantage to it. Eventually I'll probably need to stop piggy-backing off the AutoEd framework...

Thank you. That fixed it for me. —Quibik (talk) 18:50, 18 November 2009 (UTC)

On another, slightly related topic: what do you think about changing the edit summary to "fixed [[MOS:DASH|dashes]] using a [[User:GregU/dashes.js|script]]? I am not particularly fond of using a linked em dash – it is hard to spot it as being a link to something (unless this was intentional, of course). —Quibik (talk) 22:28, 14 November 2009 (UTC)

I suppose you're right, the succinct version is just too awkward. Updated! —GregU (talk) 14:22, 17 November 2009 (UTC)

A case of unwanted behaviour

If you run the dashes.js on a revision of Stalinist architecture, then the script behaves unexpectedly. The problematic part is:

<gallery>
Image:Moscow_mokhovaya_3.jpg|[[Mokhovaya Street Building]], by [[Ivan Zholtovsky]], [[1931]]-[[1934]]
Image:Manege4.jpg|[[Moskva Hotel]], by [[Alexey Shchusev]], [[1932]]-[[1935]]
Image:Langman_sto.jpg|[[STO Building]], by [[Arkady Langman]], 1932-1935
Image:Moscow_Northern_river_terminal.jpg|[[Northern River Terminal]] of [[Moscow Canal]], by [[Alexey Rukhlyadev]], [[1937]]
</gallery>

The hyphens in the year ranges are corrected, as is expected. However, in the case of the wikilinked years, the right side of the dash is removed. —Quibik (talk) 16:51, 3 January 2010 (UTC)

Hi Quibik... I can't see or reproduce the problem. Note that the "Show changes" output is confusing when using it on an older revision, because it is not directly showing you what the tool changed in this case. It is comparing the changed older revision to the current revision. —GregU (talk) 05:13, 5 January 2010 (UTC)

Hmm... you could try running the script directly on that snippet of code? Running the script right here on the talk page worked for me. —Quibik (talk) 10:09, 5 January 2010 (UTC)

I still can't reproduce it. It changes the first two hyphens to dashes, but doesn't remove anything. —GregU (talk) 14:16, 6 January 2010 (UTC)

Indeed! I just tried it out on another version of the browser and it worked normally as well. So the real problem was the alpha version of Opera I was using rather than any scripts. A rather mysterious bug, but not really that surprising considering the instability and rawness of the release. Oh well, my apologies for bothering you unnecessarily; I'll be more cautious in the future. — Quibik (talk) 19:27, 6 January 2010 (UTC)

No problem. Best wishes. —GregU (talk) 12:51, 8 January 2010 (UTC)

Consistency with em dashes at Adolf Hitler

At MOS:DASH, for the purpose of expressing an interruption in a sentence, the guideline allows either an em dash without a space to either side or, to fill the exact same need, a spaced en dash. These two configurations are not supposed to be present in the same article—one of the two styles should be settled upon for consistency.

As well at MOS:DASH, the guideline allows absolutely no instance of a space before or a space after an em dash, including coded non-breaking spaces.

In this script-assisted edit by Mm40, the article about Adolf Hitler was given some corrections such as the changing of incorrectly used hyphens to dashes, but all of the existing em dashes with incorrect preceding or trailing spaces were allowed to retain them. Also, the article was allowed to retain its combination of em dashes and spaced en dashes that were used for the same purpose, a condition that existed before Mm40 started the script, but one which wasn't corrected. Shouldn't the script have prompted the editor to consolidate all the em dashes and spaced en dashes into one style, for consistency? If the editor then chooses em dashes, shouldn't the editor be prompted to eliminate all flanking spaces, including HTML-encoded non-breaking spaces? Binksternet (talk) 00:19, 8 January 2010 (UTC)

I think the problem is people tend to use em dashes for lots of purposes not outlined in MOS:DASH, such as in quotes and lists (perhaps incorrectly, not sure if the MOS is really clear about this). I like the idea of having the script check for consistency, but User:GregU would probably have to add that feature. –CWenger (talk) 19:23, 29 January 2011 (UTC)

Dashes in sports scores

The script has been pretty good about fixing ranges in sports scores, but for some reason it has not been fixing losses in NFL season pages. See for example 2009 Houston Texans season#Regular season, where the script fixed the scores marked with a "W" for win, but not those with a "L" for loss. Dabomb87 (talk) 21:39, 17 January 2010 (UTC)

This is fixed now. Sorry it took me so long. It was assuming the L was part of Pub.L. 107-006. I tightened up the pattern to distinguish the two cases. —GregU (talk) 07:32, 4 March 2010 (UTC)

Thanks. Dabomb87 (talk) 03:07, 7 March 2010 (UTC)

Substituting dashes with their written-out Wikicode equivalents

I was wondering if it would be more beneficial to, instead of replacing &mdash ; or the like with just a dash in the raw article (the one seen while editing), that this script could insert the Wikicode equivalents? (mdash, ndash). I think it would make editing easier for future editors, as they will be able to more clearly distinguish the different types of dashes. Regards, Airplaneman ^talk 01:23, 24 February 2010 (UTC)

Hi Airplaneman, sorry for the late response. Have just been busy. I've been giving this thought and finally commented on my talk page after someone else brought it up. I'll see what I can do. —GregU (talk) 15:04, 17 March 2010 (UTC)

HTML entities vs. bare characters

I noticed that this script replaces entities such as &endash; with the bare character such as –. The desirability of one variant over another isn't addressed in the MOS (unless I'm mistaken) so I respectfully ask: why make the change? —Notyourbroom (talk) 23:34, 7 April 2010 (UTC)

Sorry; before posting, I just ran a search for the stem "entit" to see if anyone else had mentioned HTML entities, but it didn't get a hit, so I went ahead with my note. I see now that this is an issue under discussion. —Notyourbroom (talk) 23:36, 7 April 2010 (UTC)

Only making minor changes

I think this tool should not be used to make an edit whereby the only change is to edit the appearance of the dashes e.g. [1]. Has any guidance been produced on use of this tool, and has this point been brought up before? Regards. Eldumpo (talk) 11:51, 28 January 2011 (UTC)

I have never seen a guideline (or a discussion) advising against edits like this. What do you suppose is the problem with making just minor changes? —Quibik (talk) 13:31, 28 January 2011 (UTC)

You may be aware that AWB already has rules against making minor edits only [2] on the grounds of 'wasting resources and clogging up watch lists' although my concern is more the latter. Is there any way that once an article has been checked and noted as needing dash changes that it could be parked and flagged for other bot programs, so as when some more edits are identified they can be done together? Alternatively could the changes be somehow automated to happen once the article has undergone any other change. That way people would only be seeing the dash change at the same time they were seeing the other change anyway. The bottom line is that these changes are very much cosmetic, yet at the same time bot/tool changes still need to be monitored which is time consuming. Eldumpo (talk) 14:30, 28 January 2011 (UTC)

Yes, I am aware of the AWB rule. I didn't find it applicable here as I'm not aware of anyone ever using this script on a massive scale (with AWB, for example). I have never found such small edits to be bothersome either, so I personally disagree with your ideas. Your propositions are obviously out of scope for the discussion of this single script, so I suggest you start a discussion regarding this at the Village pump instead. —Quibik (talk) 15:37, 28 January 2011 (UTC)

The rules for AWB are only against changes that do not affect what readers see. Changing a hyphen to en dash does not fall into this category. It might seem like a trivial difference but for perfectionists like myself it is a big deal, and this tool is invaluable. –CWenger (talk) 17:05, 28 January 2011 (UTC)

I need to learn how to use this, but I'm scared. how do I start?

I always just have other people run a script and fix my articles, but I should learn how to do this. What do I do? The code looks complicated.  :( TCO (talk) 06:30, 23 March 2011 (UTC)

It's easy actually. Open your personal JavaScript page. Opened? Then create that page or change and add to the bottom of the page the following code: importScript("User:GregU/dashes.js");

--Pelmeen10 (talk) 13:19, 24 March 2011 (UTC)

That's not the one that was changing hyphens in filenames to en-dashes, right? Mind, that wasa few years ago. Adam Cuerden ^(talk) 14:06, 24 March 2011 (UTC)

It definitley does not – this script has a very low false positive rate. —Quibik (talk) 23:02, 24 March 2011 (UTC)

OK. So I created that page (didn't have one). And then added that content.

It told me to hold control and click refresh button (IE). I did that. I assume by refresh button, the mean the in browser refresh, not some function key.

So, what do I do now? How do I act like Malleus and fix dashes in my articles?

TCO (talk) 20:39, 24 March 2011 (UTC)

Now, pick any article and look at the area above the title, particularly the right side. You should see "Read", "Edit", etc. and an arrow pointing down (I'm presuming you are using the newer Wikipedia skin). If you open it you should either find "auto ed" (WP:AutoEd) or "–" in the list. Click whichever one you see and that should be it. Enjoy your MoS-compliant article! —Quibik (talk) 23:02, 24 March 2011 (UTC)

Nice! Thanks for this, and the easy to use instructions above. Stephenjh (talk) 14:55, 12 November 2011 (UTC)

Userbox

Hello, I wanted to inform you all guys that you can use {{User Dashes script}} to show involvement and inform other editors. Thanks. Pelmeen10 (talk) 13:48, 24 March 2011 (UTC)

problems with dates?

Hi

Can anyone tell me if these edits are correct? [3]

It seems that the script is not changing mdashes to ndashes in date ranges. From the basic description it seems that the script is not designed to do that, is this correct?

If so, can someone tell me of a script that would do this? Chaosdruid (talk) 22:59, 28 April 2011 (UTC)

AutoEd help

Could instructions on how to use it with AutoEd be added? AutoEd page is of little help, it claims "selecting your own modules (sets of automatically-made changes) is actually pretty easy" - which is rubbish, as the "instructions" that follow are very much in some high codery that does not tell me how to use this script with AutoEd. --_{Piotr Konieczny aka Prokonsul Piotrus| talk} 16:13, 1 July 2011 (UTC)

If GregU could split this script into chunks, one that contains only the first function, and have the second import the first, then it would be easy. However, until that happens, it will require some extra code to restrict the scope to avoid the function name collision (as far as I can tell). Plastikspork _―Œ^(talk) 01:47, 4 July 2011 (UTC)

In another Wikipedia?

Is it possible to use this tool in another Wikipedia? If it's possible, how? This is a really handy tool! --Stryn (talk) 09:39, 1 August 2011 (UTC)

I need answer. --Stryn (talk) 08:32, 23 July 2012 (UTC)

Marking as minor edit

When nothing is changed, the script currently already suppressed the edit summary, but it still checks the "minor edits only" field. This should only happen if the user has changed part of the content with this script. Thanks, --The Evil IP address (talk) 20:50, 6 November 2011 (UTC)

• Maybe I don't under the question... If it's a null edit, no change is registered in the article history, irrespective if the edit summary and whether the edit is marked minor or not. So what precisely is the issue? --Ohconfucius ^¡digame! 01:40, 7 November 2011 (UTC)
  • It's certainly true what you say, but sometimes I do some edits on my own and then run the script. If the script then doesn't find anything, it shouldn't check the minor edit. --The Evil IP address (talk) 09:04, 11 November 2011 (UTC)

AutoEd

Even when following the instructions on custom listing AutoEd modules, I can't get dashes to run with AutoEd. I commented out dashes.js from my common.js and ran a test on my sandbox. It worked as I expected, fixing whitespace and HTML entities. I then added dashes.js back to my common.js and ran another test; this time it only fixed the dashes. I've previously asked for help at AutoEd. Importing dashes.js seems to exclude all other AutoEd modules. Should I change my configuration or is this a bug? Thanks! —danhash (talk) 20:08, 21 November 2011 (UTC)

Figured out this only happens on Chrome. When using Firefox, dashes and the other modules work; when using Chrome, dashes is the only module that works if it is enabled. —danhash (talk) 19:36, 26 January 2012 (UTC)

Does this mean only one of the modules will work on Chrome? (I'm experiencing the same problem.) Have you/anyone found a fix?--S. Rich (talk) 01:00, 25 July 2012 (UTC)

If dashes is enabled in AutoEd and you are using Chrome, the dashes module is the only one that will run; if you want to run the other modules in Chrome, you have to remove the dashes module. If you are using Firefox, all the modules seem to run just fine. —danhash (talk) 22:30, 7 August 2012 (UTC)

Work titles

The script shouldn't change the titles of works, for example as used in the cite templates, see this edit as an example. It's very annoying to revert these "fixes". --The Evil IP address (talk) 20:09, 23 December 2011 (UTC)

This is a real problem. I often have to change dashes back to hyphens before saving a page after the script has "fixed" them. —danhash (talk) 14:53, 15 February 2012 (UTC)

I'm not convinced it's really a problem. The titles of web pages placed in {{cite web}} are essentially quotations. If you accept this view, you can apply the first bullet of "Allowable typographical changes" in MOS:QUOTE to argue that the change to ndash is acceptable. --Stfg (talk) 11:19, 19 February 2012 (UTC)

Even if it can be changed, it's not simply an automatic change that every user may want to make. Fixing hyphens to dashes in lists of band members, for example (like in this edit), is an almost completely automatic procedure, but any change I make to a reference I look at with a higher degree of scrutiny. I don't really care about changing hyphens to dashes in the titles of works inside of references, because it simply doesn't really matter that much (to me at least). Wikipedia has its own style guide which may be very different from the style conventions of the work being cited, and I don't feel the need to go around changing the titles of other people's works when I cite them, even if I would have used a different style. The simplest solution would be for dashes.js to simply ignore everything inside <ref>...</ref> tags. —danhash (talk) 22:56, 15 March 2012 (UTC)

Manual of Style discussion. —danhash (talk) 19:19, 9 April 2012 (UTC)

Template:NHLPlayoffs

The actions of the script seems to create a dysfunction of above script. It causes a disruption in functioning of 'hide' boxes where one lines of once-hidden text renders on-screen and several disappear completely. See this edit. --Ohconfucius ^¡digame! 06:20, 5 March 2012 (UTC)

Does this work with Vector?

Hi,

I've installed the script as directed, but there is no tab at the top to call the script. How do I run it once it's installed?

Thanks, MathewTownsend (talk) 17:51, 5 March 2012 (UTC)

• I use it with vector.js, and it works fine. The button is located in the tab right next to the watchlisting star; it can be seen in the drop-down menu above the 'Move' button. --Ohconfucius ^¡digame! 11:36, 7 March 2012 (UTC)

• Thanks. I removed from javascript from the vector.js that wasn't working anyhow, and now your script works! Thanks, MathewTownsend (talk) 13:04, 7 March 2012 (UTC)

Interference with {{Bibleref}}

Please refer to this thread, which points out apparent undesirable change in functioning of external linking. --Ohconfucius ^¡digame! 22:43, 29 March 2012 (UTC)

Missed date range

Hi. This run of the script appears to have missed the hyphen in the last paragraph of the "Early and medieval age" of the article (975 -1187 CE). --Stfg (talk) 10:31, 15 April 2012 (UTC)

Infobox musical artist

It looks like this script plays badly with the "background" field in {{Infobox musical artist}}. The field takes its value from a predefined list of string tokens such as "solo_singer" and "non_performing_personnel", and removing the underscores breaks it. — Paul A (talk) 03:08, 30 April 2012 (UTC)

Nope, just tested, and it isn't this script that messed with "solo_singer". Looking at the diff you've given, it was either reflinks (unlikely) or Materialscientist manually (more likely) that messed with the infobox background. Hope that helps. Jenks24 (talk) 03:17, 30 April 2012 (UTC)

Yup, manual - I was blindly editing the code and thought "solo_singer" is a text entry rather than a parameter. Materialscientist (talk) 01:56, 15 May 2012 (UTC)

Breaking table syntax

This edit broke a row of a table. Can the script be updated to leave table syntax alone? Thanks, Melchoir (talk) 03:39, 17 May 2012 (UTC)

This is cool - going to toolserver?

Hi,

This is really cool and I'd like to use it but I'm not Java script savvy. Is it possible that this might become an app on the toolserver?

Great job!--CaroleHenson (talk) 01:48, 12 September 2012 (UTC)

• Doesn't require any savviness to operate. Just follow the installation instructions at the top of this page, and after refreshing your vector file, a button that looks like a dash will appear in the drop-down menu situated between the watchlist star and the WP search box. When you are at any page, in read or edit mode, 'Fixes dashes, hyphens and minus signs' will appear when hovering over the button. Click, and Bob's your uncle! -- Ohconfucius ^{ping / poke} 03:45, 12 September 2012 (UTC)

• Thanks! When I added the script to the .js file, I received the following message. "The accompanying .css page for this skin can be added at User:CaroleHenson/vector.css. "

• After following your instructions, the function for fixing dashes appeared in the down arrow that also has the "move" function, the "-" shows, but when I click on it, it brings up the User:CaroleHenson/vector.js in edit mode.

• Do I need a css file for it to run properly? Thanks so much, this is going to be very cool!--CaroleHenson (talk) 11:09, 12 September 2012 (UTC)

Oops, never mind! I went back to the upper instructions, then went to an article and it worked there.--CaroleHenson (talk) 11:12, 12 September 2012 (UTC)

Carole, the script will perform its work on whichever active window you happen to have open in your browser. If you click on the button whilst the vector.js page is active, it will attempt to change it. The script will remain in edit mode (and not save the change) because you are expected to inspect the changes you make before saving, failing which you are operating a bot. And no, you don't need a .css file to run dashes.js -- Ohconfucius ^{ping / poke} 07:18, 13 September 2012 (UTC)

Thanks!--CaroleHenson (talk) 13:39, 13 September 2012 (UTC)

Breakage of Project Gutenberg links

This tool breaks Project Gutenberg links which contain a string like "1612-1680". Graham87 04:54, 5 October 2012 (UTC)

Boeing etc. model designations

Various Boeing planes have numerical model designations that include hyphens (and I'm sure there are other companies using similar schemes). For example, the first extended-fuselage version of the Boeing 737 was designated the 737-200, at which point the original model became the 737-100. These are correctly written as 737hyphen200 and so on. They are not number ranges, so a dash is not appropriate. Likewise, in sections of text that refer frequently to the different model designations, editors often write something like "The -200 was an extended version of the -100" (hyphen200, and so on), eliding the repetition of "737". These are not negative numbers so a minus sign is not appropriate.

Please be careful to avoid introducing these errors when using the dashes script. Undoing these errors is time-consuming because it's hard to search for dashes and minus signs and because a default install of Firefox edits pages in a monospaced font that uses the same (or near-identical) glyphs for dashes, hyphens and minus signs. Dricherby (talk) 09:51, 17 October 2012 (UTC)

The BAC 1-11 would be another example of a plane with a hyphenated model description (though I don't see any use of the script on that page). Dricherby (talk) 09:58, 17 October 2012 (UTC)

The core bit of those 737- strings could be whitelisted. Otherwise, I avoid running the dash script on aviation articles, or take manual care of those items, which is sometimes quite a task. Tony (talk) 02:09, 19 October 2012 (UTC)

Whitelisting would be a good start, yes. Most of the other Boeing planes have hyphenated submodels, too, so perhaps even an "article whitelist" would be appropriate? One thing to note is that numerical ranges are always(?) ascending so, while 737-800 is a numerical range in most contexts, I can't think of any circumstances in which 737-100 could be a numerical range. (I await a deluge of counterexamples. :-) ) Dricherby (talk) 08:05, 19 October 2012 (UTC)

I'm confused. The script already appears to check that ranges are of the form low-high so it shouldn't be picking up 737-100 through 737-700. But it seems that it does. Bug? Dricherby (talk) 10:37, 28 October 2012 (UTC)

Can't see how to use this

I've just installed this, and I can see the minus sign in the tabs at the top. When I click on it, the article opens but nothing happens. No changes are made. Can someone advise? SlimVirgin ^(talk) 23:19, 18 October 2012 (UTC)

• I see that you have imported it into your monobook. If this is indeed the skin you are using (and not vector, for example), this image shows where you can expect the activation button to appear. Regards, -- Ohconfucius ^{ping / poke} 01:44, 19 October 2012 (UTC)
• Can you give examples of the articles where there is no effect? Is this universal? I've run this script on thousands of articles, and it's quite conceivable that no changes (per the script) are necessary... -- Ohconfucius ^{ping / poke} 04:34, 19 October 2012 (UTC)

• Hi, thanks the response. The article I tried to run it on was Bad Pharma, where there are a couple of hyphens between page ranges that would normally be en dashes. I've left them in to see whether the script changes them, but so far no luck. I click on the minus sign, the article opens, and then nothing. SlimVirgin ^(talk) 18:01, 19 October 2012 (UTC)

• I just did some troubleshooting. I tried it on another article; didn't work. I tried it with SlimVirgin and a different browser; didn't work. I logged into SlimVirgin II, added the script to the monobook.js; and it did work. So there must be something in SlimVirgin's preferences that is conflicting with it. I have no idea how to narrow it down. SlimVirgin ^{TALK|CONTRIBS} 18:29, 19 October 2012 (UTC)

• You're right there are a few hyphens which ought to have been dashes. If it still only works with SV II and not SV, then you've already narrowed the difference (SV II on the left). Seems like 'importScript("User:Shubinator/DYKcheck.js");' is the only line which is unique to the non-functioning monobook. Try removing it. -- Ohconfucius ^{ping / poke} 09:35, 20 October 2012 (UTC)

• Hi, thanks for that suggestion. I removed 'importScript("User:Shubinator/DYKcheck.js");' from SV but it didn't work. I'm thinking it might be something in SV's Wikipedia preferences. I set SV II up with different preferences for troubleshooting after one of the Foundation's centralized changes conflicted with something in SV's preferences, though I forget all the details. So it's probably something like that again. SlimVirgin ^(talk) 18:30, 20 October 2012 (UTC)

• Yes, your problem definitely doesn't reside at the level of the monobook. I tried importing the SV II monobook and I got it to work; I imported the SV monobook and I got it to work too. And to prove that I was indeed running your monobook, I see that all user talk page changes in your watchlist are highlighted in a turquoise colouring rectangle ;-) -- Ohconfucius ^{ping / poke} 01:52, 22 October 2012 (UTC)

Small Question ?

I have one small question/ something to say, in the edit when I edit it says : fixed dashes using a script wouldn't it be better if it says : Fixed dashes using a script. with a capital F ? Redalert2fan (talk) 19:37, 26 October 2012 (UTC)

27 October heads up

Dashes seems to be down for me right now. I know the techies have been doing a lot of tinkering the last couple of days. The problem seems to be related to changes to AutoEd Core or AutoEdFunction. -- Ohconfucius ^{ping / poke} 02:44, 27 October 2012 (UTC)

Same here (with monobook.js). -- Michael Bednarek (talk) 04:17, 28 October 2012 (UTC)

PS: Instead, I get a non-funtional tab "auto ed" (which is not mentioned in my monobook.js. -- Michael Bednarek (talk) 04:22, 28 October 2012 (UTC)

for me it also display "auto ed" but it does still work, you could try it out on your sandbox by typing a minus sign and see if it changes it to a dash. Redalert2fan (talk) 08:24, 28 October 2012 (UTC)

All I get with Firefox (after refreshing my cache and after logging out and in again) is "AutoEd/core.js: autoEdFunctions is undefined", but it works in Chrome and IE8 as you describe. Remember, I've never mentioned AutoEd in any .js file. Baffled, Michael Bednarek (talk) 10:21, 28 October 2012 (UTC)

I've also been having trouble with the dashes script on Firefox. User:GregU doesn't seem to be active on Wikipedia anymore (at least not using this account) so I'm not certain how we go about fixing it apart from switching browser. Del_♉sion23 (talk) 21:17, 30 October 2012 (UTC)

• I've been informed that this script is now back, after four days. -- Ohconfucius ^{ping / poke} 03:09, 1 November 2012 (UTC)

Here too. Any idea what happened? -- Michael Bednarek (talk) 06:09, 1 November 2012 (UTC)

One thing for sure is that it had nothing to do with the script itself. I suspect it was AutoEd, or most likely it was the system changes of our tech guys. -- Ohconfucius ^{ping / poke} 06:12, 1 November 2012 (UTC)

Does dashes seem to be down again right now? Fyunck(click) (talk) 11:36, 20 January 2013 (UTC)

• it's working for me as I write. -- Ohconfucius ^{ping / poke} 12:56, 20 January 2013 (UTC)
  • What seemed to not work was turning &ndash into – .... it used to for me. Fyunck(click) (talk) 19:31, 20 January 2013 (UTC)
    • Do you have a diff? It's working for me. What gives when you use it on 2010 Pittsburgh Pirates season? -- Ohconfucius ^{ping / poke} 04:27, 21 January 2013 (UTC)
      • Interesting... it shows up fine there but it wasn't working on a particular tennis page last night. Maybe temporary problem...maybe temporary insanity on my part. Thanks. Fyunck(click) (talk) 05:22, 21 January 2013 (UTC)

Redirects

If there's a redirect to a section name from another article and the tool changes that section name, does the tool search for the redirect and repair it? Or does it just silently break the redirect?—Kww(talk) 04:16, 24 April 2013 (UTC)

• The script acts only locally, but I have never observed it altering what's within the linking portion of wikilinks. Hope that answers your question. -- Ohconfucius ^{ping / poke} 07:11, 24 April 2013 (UTC)

• I'm afraid it does answer my question: the script should't change text in section headers, either, for exactly the same reason that it can't change text in wikilinks. If there's a section header that says something like "2004-07" in it and the script decides that it has the wrong type of short horizontal line and changes it, any wikilinks to that section in other articles will break. Breaking wikilinks for a purely cosmetic edit is a really bad idea.—Kww(talk) 15:48, 24 April 2013 (UTC)

• Worse yet: based on my reading, it intentionally changes the short horizontal lines used in the righthand side of a Wikilink (ie. [[article name#text containing horizontal lines]] but doesn't go to the target article and adjust the form of short horizontal line used in the redirect target. Running this script seems to break redirects in both directions.—Kww(talk) 19:02, 24 April 2013 (UTC)

I think it's misguided to blame the tool. Editors are expected to a) place a comment near a section header if it used as the target of a redirect; b) deal with the consequences of changing article text. Even if neither of those is done, what's the worst that can happen? The redirect jumps to the top of the target article where the interested reader will probably have no difficulty finding the section of interest. There are thousands of redirects where the target doesn't exist at all anymore, so this only a minor inconvenience, not a showstopper. -- Michael Bednarek (talk) 06:04, 25 April 2013 (UTC)

• With very few exceptions, the tool correctly changes hyphens to ndashes in compliance with WP:MOSDASH. Such changes are valuable, as it brings consistency to the project. There are already hundreds if not thousands of such non-compliant links created within many-a sports article. My only quibble with the tool is that it doesn't go far enough and change within a piped wikilink. This conservatism is no doubt to avoid changing or breaking links, but fails to account for the fact that these are often redirects that are not harmed by being replaced, so now I have to customise my own tool to finish off a half-finished job. And so what if it changes '2007-08 season' to '2007–08 season' within section headings? As MB says, there are plenty of such inadvertent cases all over the 'pedia. A potentially disrupted section link at the cost of MOS compliance is IMHO still a net gain, not the end of the world. -- Ohconfucius ^{ping / poke} 06:47, 25 April 2013 (UTC)

The changes are of no actual value whatsoever, the difference between an en-dash and a hyphen being nearly invisible and the semantics of the difference between the two being disputed. To break a wikilink or a redirect is far stronger negative than any positive impact of the few extra black or white pixels at the end of the punctuation. It's the responsibility of the editor changing the dashes and hyphens to compensate for the impact, and an automatic tool that breaks links without notifying the editor that he has done so is unacceptable.—Kww(talk) 07:20, 25 April 2

• That argument has zip to do with this script. Like the many who have preceded you in this line of discourse, you should take your gripes against the MOS to the rightful place. -- Ohconfucius ^{ping / poke} 08:45, 25 April 2013 (UTC)

• Actually, that argument has a lot to do with this script. Nowhere in WP:MOS does it say that correct use of dashes is more important than maintaining links between articles. Furthermore, WP:MOS:HEAD explicitly states "Before changing a section heading, consider whether you might be breaking existing links to that section. If there are many links to the old section title, create an anchor with that title to ensure that the links still work." Note also that WP:MOS is a guideline, not policy, which means that one should weigh the advantages and disadvantages before applying it. I love dashes (many of my own minor edits are replacing hyphens with dashes) but we shouldn't go around breaking links just to make the text look a tiny bit nicer. Dricherby (talk) 10:17, 25 April 2013 (UTC)

Who's going "around breaking links just to make the text look a tiny bit nicer"? Nobody, so that strawman can be disregarded. The difference between a hyphen-minus ("-"), an en-dash ("–") and an em-dash ("—") are (to me) very visible in rendered web pages. The first two convey distinct meaning (there's a joke in German-speaking countries where this is important when an Austro-Hungarian football match is discussed). This tool is not automatic; editors using it are presented with a diff and they are responsible for its effects. Where has this script's usage lead to breaking redirects? -- Michael Bednarek (talk) 13:17, 25 April 2013 (UTC)

The claim was that the script has broken links and/or redirects; I assume the claim was made in good faith. As I said, I much prefer to see the right kind of hyphen or dash but I disagree with the idea that it's worth breaking links for. Dricherby (talk) 19:18, 25 April 2013 (UTC)

I've noticed numerous broken wikilinks due to this kind of change. Can I swear that any of them were, in fact, caused by this script? No. Will this script cause the problem if it isn't modified? Yes.—Kww(talk) 20:09, 25 April 2013 (UTC)

• Dricherby sees my point. I've given up on the base issue: if people want to believe there's a substantial difference between dashes and hyphens, they are free to do so and I won't object. Once they start breaking functionality because of that belief, I'll object strongly. If this tool wants to change section headings, the tool needs to scan all incoming wikilinks and adjust them, too. Or leave them all alone. Changing one end of a two-way linkage is unacceptable behaviour. Did I read you right, OhConfucius? Did you create a modified version of this script specifically to bypass what safeguards it has against breaking links?—Kww(talk) 16:19, 25 April 2013 (UTC)

• On a constructive note, there is an actual solution to this problem. All this script has to do is add {{anchor|original heading}} after any heading it modifies. That way, incoming wikilinks of either format will still land in the right place. Note, for example

1. User:Kww/hyphentest#Subsection-1
2. User:Kww/hyphentest#Subsection–1
3. User:Kww/hyphentest#Subsection-2
4. User:Kww/hyphentest#Subsection–2

See how both versions of the Subsection 2 link work, while one of the Subsection 1 links doesn't work because of the difference? By the way, I have my text zoomed to 500%, and I still can't see a difference between the pairs of headers as I type. I can see a subtle difference in the rendered text, though. I guess the designers of the monospace font weren't informed that the characters are different.—Kww(talk) 20:09, 25 April 2013 (UTC)

Yes, when I'm editing text, I can't see the difference, either, but it's obvious in the rendered page. Modifying the script to add the suggested anchor tags would resolve my concerns with this issue. Dricherby (talk) 22:30, 25 April 2013 (UTC)

• It's frustrating that the differences aren't apparent in edit mode. It gives rise to some editors' impressions that there are no differences between the hyphen and dashes. -- Ohconfucius ^{ping / poke} 02:12, 26 April 2013 (UTC)

• So far, although there are allegations that the script might have caused broken redirects in the past and will do so in the future, the discussion is theoretical. I'm only a user and not the script programmer. The owner of the script isn't here to defend the script nor to fully describe how it works (in fact, he seems no longer to be active on the project). Some of the allegations also presuppose that the script will indiscriminately change hyphens for dashes or vice versa, but I do not believe that to be true. The script may look simple but I have found it to be highly sophisticated, it's not perfect (as I and others have documented in other sections above and at the user's talk page) but has been written in remarkable anticipation of many pitfalls. The allegations also presuppose that there are links to section headings and that these are altered by the script. I'm also pleased to inform you that the script alter any dash or hyphen on User:Kww/hyphentest.

  I did mention that I customised my tool to retrain certain links – specific instances where the articles all reside at the 'dash-ed' namespace (ie change '2007-08 season' to '2007–08 season'). Again, I don't see these specific targeted changes as being problematic; they are improved because it bypasses the redirect altogether. No links are "broken". -- Ohconfucius ^{ping / poke} 02:12, 26 April 2013 (UTC)

• Please give it a try. Run it on User:Kww/hyphentest and see whether it changes the section headings.—Kww(talk) 02:58, 26 April 2013 (UTC)

• I do see the point you are trying to make. I'm not saying there's no issue with disturbing potentially incoming links. It's obvious you wouldn't have asked the opening question if you hadn't thought there may have been an issue.

  Some editors add a marker of some sort adjacent to the header indicating an anchor to particular section headings, but many don't. I mean how is the average editor (even a very experienced one) ever to know, when changing any section heading for any reason (not just hyphens or dashes), that there is an 'incoming' section link in the absence of such declarations? Whilst it's de rigeur for a bot to be able to deal with such situations in an error-free manner, the same level of exigence has never been required for scripts as there is significant user judgement to be exercised.

  Things will happen every day through inadvertence. For example, how many times have you clicked on a link to not find the section you were looking for? Fact is, it will still land you on the same page, and you still manage to find the info you were after. There are also bots that go around fixing internal linkings. It's on that level that I'm commenting that the problem you describe seems to be overstated. -- Ohconfucius ^{ping / poke} 04:10, 26 April 2013 (UTC)

Do you have the script installed on your machine? If so, please test it on User:Kww/hyphentest and see if it modifies the headers or not.—Kww(talk) 06:37, 26 April 2013 (UTC)

• Kww, "a purely cosmetic edit"—it's certainly not purely cosmetic; there are several dimensions to the use of correct typography in this case. Tony (talk) 09:36, 26 April 2013 (UTC)

• It's absolutely a cosmetic edit, Tony. No doubt about that. The only doubt is whether the problem exists. Do you have this script installed? Will you run it on User:Kww/hyphentest and see what it does?—Kww(talk) 15:39, 26 April 2013 (UTC)

• We can argue about that until the cows come home, and still nothing will be resolved. As you've "noticed numerous broken wikilinks due to this kind of change", I would sincerely suggest you try to locate some of them to prove your point instead of using the theoretical case of the hyphens or dashes on your test page. -- Ohconfucius ^{ping / poke} 17:29, 26 April 2013 (UTC)

• Hours of work vs. seconds, OhConfucius. Why won't you do the simple task of opening the page and clicking your button? The question for this page is not whether it's a problem to break links, the question for this page is whether this script breaks links.—Kww(talk) 19:50, 26 April 2013 (UTC)

• And Ohconfucius's question is whether it's actually breaking links out in the wild, rather than just having the potential to do so. Dricherby (talk) 20:18, 26 April 2013 (UTC)

• I temporarily intalled this thing, and the answer is, yes, it modifies section headers, which will break any incoming links. OhConfucius's question is irrelevant, actually: a dangerous weapon is a dangerous weapon even before it has shot anyone. Since there's an actual technical solution to the problem that doesn't prevent it from making the modifications, I'll see if I can find someone that feels comfortable fixing the script so that it will make the modifications safely.—Kww(talk) 22:31, 26 April 2013 (UTC)

• Wikipedia:Village_pump_(technical)#Anyone willing and able to fix User:GregU.2Fdashes.js.3F—Kww(talk) 22:43, 26 April 2013 (UTC)

• Has it actually broken any links in any actual mainspace articles? Yes, it has the potential to do so but has it actually done it? Dricherby (talk) 23:48, 26 April 2013 (UTC)

• Why would you wait for something to be damaged before fixing the tool? I'm not asking for it to stop changing things to the format you prefer, only to add an anchor so that damage is avoided. I can certainly find wikilinks that are broken because of dash/hyphen differences. Trawling through edit histories to find out whether the editor that did so used AutoEd or this script to do so seems unncessary.—Kww(talk) 04:52, 27 April 2013 (UTC)

• This "weapon" is about as dangerous as a roll of masking tape. Sure, knock yerself out by adding an anchor if you must. -- Ohconfucius ^{ping / poke} 15:46, 28 April 2013 (UTC)

Gallery needs protecting

Please note that the script converts names of files with hyphens (to dashes) like it did here. -- Ohc ^¡digame!_{¿que pasa?} 17:22, 13 September 2013 (UTC)

I added gallery to the list with math, pre, etc. There is probably a smarter way to do this so that the script can still modify captions, and I'm not sure if it still breaks with {{gallery}} templates. Thanks! Plastikspork _―Œ^(talk) 16:46, 14 September 2013 (UTC)

Plastikspork, thank you indeed. Since GregU is no longer around, I'm sure all users of this valuable script are grateful for anything you're prepared to do in the way of maintenance or modification. Tony (talk) 19:19, 14 September 2013 (UTC)

Please don't edit links to Wikisource etc.

I am told that this script changes links that point to English Wikisource, and the example that I was given was some of the links for {{cite DNB}}. Can I ask that the relevant changes are made so that this does not happen. The script should not be changing links for interwiki, sister links or offsite urls, or templates that are used to for such urls/links. TIA for the relevant correction(s) to the script. — billinghurst sDrewth 13:31, 9 October 2013 (UTC)

• Please refer to the discussion about that and related issues here. The problems lie in the fact that there isn't the same degree of awareness at WS, and therefore different conventions adopted. I concur that following that advice and getting WS to adopt "correct" use of dashes would be the best course of action. -- Ohc ^¡digame!_{¿que pasa?} 13:45, 9 October 2013 (UTC)

Stops visual editor working

Hi Greg, great tool, but when I install it stops VE working. Any idea? Edgepedia (talk) 21:22, 30 January 2014 (UTC)

• That's indeed curious. I have dashes and more installed, and VE seems to load correctly and more or less work as described. It's possible that there may be some conflicts with another, or between more than one different elements added on, and there's no clear answer to your problem. You can try leaving dashes installed whilst removing the others one by one and see if anything changes. BTW Greg has been inactive for quite some time. Regards, -- Ohc ^¡digame! 23:48, 30 January 2014 (UTC)

What stops it from working here?

I use this a lot to fix simple hyphens and replacing ndash (thanks). But I'm noticing that certain pages cannot be fixed with this script. Most recently..1989 Virginia Slims Championships – Singles and 1987 Virginia Slims Championships – Singles with all their many ndashes. I've come across this from time to time and I'm wondering what it is with articles like these that will not allow your script to function. Thanks. Fyunck(click) (talk) 23:04, 24 February 2014 (UTC)

Minor issue with using the script on pharmaceutical/chemical articles

Correct CAS (before)

Identifiers
CAS Number	300-62-9

Broken CAS (after)

Identifiers
CAS Number	300–62–9

Hi GregU, thanks for your useful script. I wanted to bring to your attention an issue with using it on pages with a {{Drugbox}} (probably also ones with a {{Chembox}} as well). The script attempts to convert any dash it finds in a CAS number to an ndash. Unfortunately this breaks the CAS template link which recognizes only dashes in CAS numbers, as these are the convention for this system. E.g., using the script on amphetamine will break the CAS entry unless manually corrected (the problem is shown to the right - follow the CAS links).

Just thought you should know. Best regards, Seppi333 (Insert 2¢ | Maintained) 21:29, 21 May 2014 (UTC)

• @Seppi333: Thanks for your note. GregU has been inactive for some time. I will try and find somebody to patch the script to deal with the issue. Regards, -- Ohc ^¡digame! 04:05, 22 May 2014 (UTC)
  • @Seppi333 and Ohconfucius: Probably fixed here. Thanks! Plastikspork _―Œ^(talk)
    • @Plastikspork: Muchas gracias! -- Ohc ^¡digame! 01:55, 26 May 2014 (UTC)

Script breaks comments?

The script seems to have broken an HTML comment here.—Chowbok ☠ 18:59, 20 June 2014 (UTC)

Being told to stop using this scrip

I'm being told to immediately stop using this scrip, on my talkpage here. Can someone chime in, at that conversation? Tx. --Epeefleche (talk) 17:46, 26 September 2014 (UTC)

Using this script on the Welsh Wikipedia

Hi! This really is an excellent tool. Would it be possible for me to add the script to the Welsh Wikipedia? If so I would copy and paste the page, translating the names of the months but leaving the rest mostly as it is. Would this be acceptable or would it be too primitive? (I'm not an expert at Javascript.) The filename would be in my userspace unless you'd prefer to create an account yourself. Please ping me back here. Ham (talk) 14:24, 5 November 2014 (UTC)

Easy access

This is an excellent tool and will no doubt prove to be a great tome saver. My only query is whether it would be possible to relocate the link to invoke it to the sidebar instead of the "More" menu, as the latter is a little more fiddly to access, particularly on a touch-screen which requires more precise pointing to tap the icons. Other scripts provide uncluttering and en masse corrections (e.g., date format conversions) on the sidebar, so it would be convenient to have this one in the same place. Just a thought.

Thanks for the top work! —sroc 💬 17:42, 8 December 2014 (UTC)

Spaced en dashes

Would it be possible to use the {{snd}} template for spaced en dashes rather than using a soft space that could wrap around the line before the dash?

With a spaced en dash	With the {{snd}} template
This is what an example could look like – with an en dash on the next line.	This is what an example could look like – with an en dash on the same line as the previous word.

—sroc 💬 13:41, 10 December 2014 (UTC)

Anything that makes it easier to insert for those who don't readily have a key for it is a great idea. There's a place you can check on whether snd is already taken up (fingers crossed, and I can't remember where it is). Also, please can the template instructions hammer in that much usage of en dashes is unspaced. I see the template used particularly in navboxes for plain year-ranges. Thx. Tony (talk) 14:29, 10 December 2014 (UTC)

@Tony1: I think the issue about documentation is better raised at Template talk:Spaced ndash. —sroc 💬 15:51, 19 December 2014 (UTC)

I have updated the template documentation to include alternative uses with reference to MOS for proper use. —sroc 💬 16:14, 19 December 2014 (UTC)

AutoEd, dashes, and Chrome

Is it known what causes AutoEd not to function together with dashes in Chrome? --JorisvS (talk) 15:21, 19 December 2014 (UTC)

I've just used AutoEd, then activated dashes at my .js page, used it, and only then saved it. Is there a possible fix for this problem here? --JorisvS (talk) 12:13, 20 December 2014 (UTC)

I guess it needs a Bugzilla report. Tony (talk) 02:04, 21 December 2014 (UTC)

I don't understand the interactions. But looking at the code for this script, it seems that it makes calls to the AutoEd engine. -- Ohc ^¡digame! 23:05, 21 December 2014 (UTC)

Maybe I've just found out what's going on (in Chrome). If I've activated dashes.js alongside AutoEd, instead of a dash button next to the AutoEd button next to the history button, two dash buttons appear next to the history button. If I click on the first one, usually it runs dashes.js, but sometimes AutoEd; if I click on the other one it is the other way around. So it seems that activating dashes.js messes with the appearance of the AutoEd button, but that still one of the two is actually the AutoEd button, only it cannot be seen which one it is and it is not quite predictable. Knowing this, I can run both AutoEd and dashes.js to clean up a page in one edit without first running one and then (de)activating dashes.js at my common.js to run the other. --JorisvS (talk) 17:00, 5 January 2015 (UTC)

Ranges with ref tag inside

In ranges of the form XXX<ref>...</ref>-YYY(<ref>...</ref>), this script does not detect that the hyphen should be replaced with an endash. Is it possible to fix this? --JorisvS (talk) 11:53, 12 March 2015 (UTC)

Reporting a bug

During this edit using this script, it failed to find this hyphen to fix to an endash. --JorisvS (talk) 08:44, 22 May 2015 (UTC)

Breaks location maps

When JorisvS made this edit with this script, it resulted in the location map being entirely broken, since the template can't tell that the Unicode symbol that sort of looks like a negative sign is meant to be a negative sign. Can this be fixed? Thanks, Jackmcbarn (talk) 17:55, 25 May 2015 (UTC)

Actually, I did that part manually, because the script didn't take those and they are properly minus signs, not knowing that that would break the templates. The script is fine, but why doesn't template understand actual minus signs, only hyphens? --JorisvS (talk) 18:28, 25 May 2015 (UTC)

Another bug

At Scholz's star (among others, I've seen this before), it fails to find "|prop_mo_ra=-40.3 ± 0.2{{r|Burgasser2015|Mamajek2015}}" and "|prop_mo_dec=-114.8 ± 0.4{{r|Burgasser2015|Mamajek2015}}" to fix those hyphens to minus signs. --JorisvS (talk) 08:01, 28 May 2015 (UTC)

Book titles, web titles, and verifiability

I see this was topic that came up here in 2009, but wasn't sure it was addressed. I noticed today this script being used to change the titles of sources en masse, and I feel that goes against the principle of verifiability. I do feel that if a source has a misspelling in its title, we shouldn't correct it in our citations, or if it uses the wrong punctuation, that changing it makes less verifiable for current and future users. It is a bit of an issue of minutia, but I was wondering, has anyone had endeavored to ensure that this script doesn't affect hyphens/dashes inside a "title" field the way it won't change a URL or math equation?-- Patrick, _oѺ^∞ 17:25, 3 August 2015 (UTC)

My two cents For what it's worth, I don't see why the MoS should stop at sources' titles. If an article should be titled according to a certain style, then why not all of the internal material as well? I suppose it's possible that someone wouldn't be able to find a book entitled "Baseball from 1907-1908" if we used "Baseball from 1907–1908" but I don't see this as being a real problem. Does anyone have data on this? Guidelines from other publications? —Justin (koavf)❤T☮C☺M☯ 19:04, 3 August 2015 (UTC)

Dashes on ISBNs - is there a flaw in the tool?

Please see Jean Sibelius revert. @Mirokado: Just so you know, what happened on Jean Sibelius was this tool that I was using. It's a widely-used tool on Wikipedia. So if there is a flaw in how it's treating ISBNs, it needs to be logged here. If it was wrong on Jean Sibelius, the tool is wrong on countless other articles. I don't know what happened, but I've never seen the tool change ISBN numbers before. I've used this tool on hundreds of my own creations, and it never bothered with ISBN numbers on them. Strange occurrence. Please feel free to add your comments. — Maile (talk) 23:53, 8 December 2015 (UTC)

For comparison, I just ran the tool on St. Nicholas Hotel, which has several ISBN numbers. The tool made dash corrections, but never touched the ISBN numbers. Something odd happening, but at least it's a good idea not to save the changes before making sure it didn't change ISBN numbers. — Maile (talk) 00:08, 9 December 2015 (UTC)

Hi, I have also been checking that change. This ISBN 978-951-746-215-0 is resolved correctly by WorldCat. Of the two websites I use to hyphenate ISBNs, pcn.loc.gov fails to hyphenate it, but ISBN.org succeeds. I have noticed this occasionally with Scandinavian ISBNs. Since the script (which I also use from time to time) only zapped that one ISBN, I imagine it is also failing to parse it somehow. This will result in very occasional errors until it can be fixed. --Mirokado (talk) 00:14, 9 December 2015 (UTC)

Thanks for explaining that. I'm going to be extra-careful from now on before I save with this tool. — Maile (talk) 00:21, 9 December 2015 (UTC)

Appears to still be breaking at least some ISBNs. See this change that I just reverted (by hand). Unless there's a newer version of the tool than what was used there. --Floatjon (talk) 17:43, 27 October 2016 (UTC)

Page where this doesn't work

This usually works but I know there are some troublesome articles where hyphens and ndash-script don't get changed. One of them is 2006 Hastings Direct International Championships – Doubles. Why does it have trouble converting the &ndash:-script into a "–" on this article? Fyunck(click) (talk) 08:16, 5 February 2016 (UTC)

@Fyunck(click): The script will only change &ndash; to the unicode character when it is also changing at least one hyphen into a dash. Otherwise it's a largely pointless edit because the code &ndash; and the unicode character render exactly the same way for the reader. The script will work on that page if, for example, you change one of the &ndash; into a hyphen and then run the script. Jenks24 (talk) 15:39, 6 February 2016 (UTC)

Well heck, I never knew that. Thanks. Fyunck(click) (talk) 18:37, 6 February 2016 (UTC)

doi breakage

Just got a complaint. Tony (talk) 05:06, 6 April 2016 (UTC)

Likewise in [4]. Headbomb {t · c · p · b} 18:52, 2 May 2017 (UTC)

What to do? Can you help, Plastikspork? -- Ohc ^¡digame! 08:33, 4 May 2017 (UTC)

@Tony1, Headbomb, and Ohconfucius: I just made this change can you confirm that (1) I didn't make things worse, and (2) that it fixed the problem? Thanks! Plastikspork _―Œ^(talk) 00:35, 5 May 2017 (UTC)

What would we do without you, Plastikspork? I'll do a run in 15 hours' time and report back here. Tony (talk) 12:51, 5 May 2017 (UTC)

Should this page be linked to from MOS:DASH?

Should this page be linked to from MOS:DASH, perhaps in a 'See also' section? It would certainly make this script easier to find for those trying to look for it. (I went to MOS:DASH first trying to find this script, and was frustrated when it was [not] linked to from there...) --IJBall (contribs • talk) 23:02, 12 May 2016 (UTC)

I guess you meant "not linked to". Yes, I think it should be linked. Tony (talk) 03:52, 13 May 2016 (UTC)

 Fixed --IJBall (contribs • talk) 04:08, 13 May 2016 (UTC)

 Done. Linked to this, and Ohconfucius MOSDATE script, from the WP:MoS page (under new section 22.3, "Tools"). --IJBall (contribs • talk) 23:54, 13 May 2016 (UTC)

YYYY–present

A year ago, the use of "present" got added to MOS:DATERANGE. What got agreed on was whether or not a spaced endash was to be used, and that the lower case 'p' be used. You might want to consider adding this to the functionality of your script. The capital 'P' is quite common and should be simple to capture (says he who doesn't do any programming). Keep up your good work! Schwede66 20:09, 20 January 2017 (UTC)

Uppercase P is wrong. It needs to be corrected in all instances. The en dash needs to be closed (unspaced), unless a compound date is involved ("3 January – present"). I don't think I've seen that in infoboxes, though. Tony (talk) 02:43, 21 January 2017 (UTC)

Spaces in header/headline

Why is this necessary and can the code be tweaked so it doesn't do this? I'm talking about the spacing between equal signs and the header text. From MOS:HEAD: "Spaces around the Title (e.g. == Title ==) are optional and ignored." --Jennica✿ / ^talk 23:37, 14 March 2017 (UTC)

• Are you certain? I've never noticed that the script inserts (or removes) spaces. -- Ohc ^¡digame! 21:38, 15 March 2017 (UTC)

@Ohconfucius: I think I was mistaken. I use this one and the autoformatter. sorry! --Jennica✿ / ^talk 01:35, 16 March 2017 (UTC)

Nice update!

Hey, who coded "from X–Y" to change to "from X to Y", and "between X–Y" to change to "between X and Y".

Great work!

Tony (talk) 04:24, 25 March 2017 (UTC)

• This script hasn't been touched since 2014. Might be something in another script? -- Ohc ^¡digame! 09:57, 25 March 2017 (UTC)

Conflict with Score extension

This edit by Ham II indicates a conflict between this script and Extension:Score, which is used for generating musical scores (see also Help:Score). The score extension uses the -- syntax to indicate syllable divisions in lyrics, to place syllables against notes to which they are sung.

The edit changed -- to – within the score syntax, which had the effect of misplacing the words in the score displayed in the article.

The solution appears to be to change the script so that it does not make changes to score extension syntax, that is it should not make any changes between the <score and </score tags. Verbcatcher (talk) 16:08, 23 August 2017 (UTC)

Not working in some cases.

Not sure if this has been raised before, but it does not work in some cases, such as 2017–18 Calcutta Premier Division. There are a few instances of '2-1' on these pages, which are not converted while using the script. Coderzombie (talk) 15:42, 24 September 2017 (UTC)

Script question

I installed the script and got two dash tabs which pop up in different places each time I click on an article. Is this normal? Regards Keith-264 (talk) 21:49, 7 December 2017 (UTC)

Oh and auto ed has disappeared....Keith-264 (talk) 22:14, 7 December 2017 (UTC)

Chemistry environment

In this edit [5] by @Jerome Kohl: hyphens inside a <ce>...</ce> tag were changed to en-dashes. <ce> is basically another form of the <math> mode tag which needs hyphens for correct LaTeX processing. The same applies to <chem>. I think the lines

var m = string.slice(pos).search(/<\/?(math|pre|code|tt|source|syntaxhighlight|gallery)\b/i);
    if (m >= 0 && string.charAt(pos+m+1) == '/')
        return str;             // don't break a <math> equation, or source code

need to be changed to include the ce and chem tags.--Salix alba (talk): 05:53, 5 January 2018 (UTC)

False positive on Stoneman Douglas High School shooting

https://en.wikipedia.org/w/index.php?title=Stoneman_Douglas_High_School_shooting&type=revision&diff=828161467&oldid=828160309

Should not insert a space after a non-breaking space. AdA&D ★ 22:34, 28 February 2018 (UTC)

Not working

Not sure if it's just me but the script doesn't appear to be working anymore. Del_♉sion23 (talk) 20:02, 3 March 2018 (UTC)

It worked for me about 30 seconds ago on the article Daria Gavrilova. Fyunck(click) (talk) 20:17, 3 March 2018 (UTC)

I've worked out the problem. The dashes script is not currently compatible with the "Wikitext syntax highlighting" preference which is in Beta. Del_♉sion23 (talk) 18:53, 11 April 2018 (UTC)

User:Delusion23, thanks for alerting us. Anything for general users of the composite script to note? (I'm a tech dummy) Tony (talk) 06:00, 12 April 2018 (UTC)

I'm a tech dummy too. I just noticed that the dashes script had stopped working once I'd enabled the "Wikitext syntax highlighting" beta in my user preferences. I've now removed it as I need the dashes script more. I have raised the issue on MediaWiki. Del_♉sion23 (talk) 08:53, 13 April 2018 (UTC)

{{Drugbox}} |InChI= and |StdInChI= parameter exclusion

This script should ignore any dashes that are present in these template parameters. Can someone code an exclusion for this? An example edit where the script attempted to change these compound identifiers is Special:Diff/847232527/847232613. Seppi333 (Insert 2¢) 21:01, 23 June 2018 (UTC)

Bug: the script breaks chart templates

In the following revision the script was used to 'fix' hyphens in a Graph:Chart template: https://en.wikipedia.org/w/index.php?title=Venezuela&diff=796822938&oldid=796334411

The chart template expects a hyphen-minus, not a minus sign,for negative numbers, and replacing it will result in the numerical data being interpreted as categorical data.

Fnuciton (talk) 15:21, 25 October 2018 (UTC)

Why does the chart insist on breaking WP's manual of style? Tony (talk) 01:10, 23 June 2019 (UTC)

Bug

The script breaks interlanguage links. ([6]) Koopinator (talk) 09:08, 22 June 2019 (UTC)

Strangeness

When I add this near the top of User:SMcCandlish/common.js, I get the "-" for this item showing up twice under my "More ˬ" menu (in my top menu bar), and it also makes "auto ed" (normally the only item in that "More ˬ" menu) disappear.  — SMcCandlish ☏ ¢ 😼  07:42, 18 November 2019 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.