Wikipedia talk:AutoWikiBrowser/Typos

message: I was recently doing page clean-up with AWB, and AWB suggested changing "Academy Award–winning" (with an en dash) to "Academy Award-winning" (with a hyphen) on the article "Society of the Snow" (see this edit). User Nardog noticed my edit and reverted it citing MOS:SUFFIXDASH. I started a discussion about this (see: Wikipedia talk:Manual of Style#Clarification on the use of a hyphen or an en dash for "Academy Award winning"), and it appears all users who commented are in agreement that en dashes should be used in these situations and not hyphens. Thanks! Wikipedialuva (talk) 09:45, 27 January 2024 (UTC)
replies: text: When using the typo fixes, it's important to not save it unless you know it is correct. The typo list should be thought of as suggestions that are usually correct but cannot foresee all scenarios. That said, I've probably saved this with a hyphen forgetting the guideline. At any rate, this may or may not be fixable in the typo rules because not all of these scenarios can be covered programmatically with Regular Expressions. My hunch is we can make it pass by more of these false positives than before. Stefen Towers among the rest! Gab • Gruntwerk 09:55, 27 January 2024 (UTC)
replies: text:  Thanks for looking into this. I want to acknowledge that I understand that the user is ultimately responsible for the edits made with AWB and that this erroneous edit was my fault for saving the edit. As was noted on MOS talk, violations of the MOS:SUFFIXDASH rule in regards to awards are extremely widespread on the project (extending into article titles, which I have been working on fixing). I also understand that it will be impossible to try to come up with every possible variation of this rule. I don't know if it would be appropriate or even possible to try to make a rule for some of the most common awards that cause the error or not. Thanks again for responding and looking into the issue! Wikipedialuva (talk) 10:24, 27 January 2024 (UTC)
replies: text: I'm glad there is understanding of the use of AWB Typos and how it works but to the crux of the matter, perhaps if we didn't place the hyphen when "Award" is capitalized and preceded by another capitalized word, it would cut out most false positives. That should be a simple fix. Stefen Towers among the rest! Gab • Gruntwerk 20:58, 27 January 2024 (UTC)
replies: text: @Wikipedialuva  The simple fix I described is now complete. Stefen Towers among the rest! Gab • Gruntwerk 00:47, 28 January 2024 (UTC)
replies: text:  Fix works great! Thanks for you help!  Wikipedialuva (talk) 07:56, 28 January 2024 (UTC)
thread_title:  Incorrectly changing en dashes to hyphens in violation of [[MOS:SUFFIXDASH]] 

message: Greetings! I'm recycling AWB regexes in a script that can efficiently scan database dumps on Linux. The use of backspaces in word="you'(d\ve\re\ll)_" creates some weird escaping issues. Any objection to rename it "you'(d/ve/re/ll)_"? That seems more like standard slash usage to me anyway. Thanks, Beland (talk) 01:05, 29 January 2024 (UTC)
replies: text: That shouldn't cause any issues. I believe AWB itself doesn't use the names for anything. -- John of Reading (talk) 07:42, 29 January 2024 (UTC)

text: As John of Reading said, changing this won't impact AWB typo correction. I wish the rule name did display in the log, but alas it does not (I need to request that :) ). Stefen Towers among the rest! Gab • Gruntwerk 08:43, 29 January 2024 (UTC)
replies: text:  Thanks for the quick fix! -- Beland (talk) 20:17, 29 January 2024 (UTC)
thread_title:  Backspace in regex name 

message: 1-1, 2-2, etc. scores are being overlooked for ndash replacement and with all the sports articles I work on, this is getting a little too frustrating.  - I found out you had made a change to make this a false positive in March 2020. Is there any way this can be made to bypass fewer of these (i.e. look for additional text to match)? A *lot* of tie scores aren't getting a correction (unless I catch it and perform the correction manually). Stefen Towers among the rest! Gab • Gruntwerk 23:02, 3 February 2024 (UTC)
replies: text: the relevant part of rule "0–0", (?<!\b\1[-—]\1\b), was moved the next day into rule "2–1", precisely so that "0–0" can find draws and ties. If "0–0" isn't finding ties now, it's not because of that lookbehind; it's because "0–0" needs to be expanded with more relevant keywords.   ~ Tom.Reding (talk ⋅dgaf)  13:33, 4 February 2024 (UTC)
replies: text:  Thanks for the reply. (?<!\b\1[-—]\1\b) is still in "2–1", and stopping corrections of draws/ties that don't meet "0–0". "0–0" currently doesn't cover a lot of scenarios I'm seeing in my typo correction work, but I don't know why the draws/ties need to be avoided in "2–1" 's general case in the first place. Is there any harm from removing that code? That's what I'm driving at. Stefen Towers among the rest! Gab • Gruntwerk 17:37, 4 February 2024 (UTC)
replies: text:  the reason that lookbehind exists is because the rule was incorrectly catching journal volume numbers, e.g. "Some Journal 5-5", preceded by "5-4" and succeeded by "5-6" etc., which should not be changed/en-dashed.   ~ Tom.Reding (talk ⋅dgaf)  17:46, 4 February 2024 (UTC)
replies: text: I can see why we don't want a journal volume number en-dashed, but I don't quite understand why volume numbers that look like draws/ties are more problematic than those where the numbers aren't equal (e.g. "5-4"). If the "5-4" is in the middle of the series instead of "5-5", wouldn't it be falsely corrected? Stefen Towers among the rest! Gab • Gruntwerk 17:58, 4 February 2024 (UTC)

text:  Is it that a draw/tie is guaranteed to not be a number range if referring to a volume? If that's the case, I understand it better now after thinking more about it. At any rate, I am working on more cases to convert the ties to use ndash outside of this false positive check. But I wish this check wasn't needed - we really miss a lot of genuine draws/ties as it stands. Stefen Towers among the rest! Gab • Gruntwerk 00:01, 5 February 2024 (UTC)
replies: text:  do you have a list of pages where ties are known to have been missed?   ~ Tom.Reding (talk ⋅dgaf)  11:59, 5 February 2024 (UTC)
replies: text: @Tom.Reding I don't keep a list of these. I just keep seeing these missed, and I have to correct them manually. It's any draw/tie that the "2–1" rule would ordinarily catch but doesn't due to the false positive catch. If you run AWB typo checks in sports articles especially, it can get rather frustrating. Stefen Towers among the rest! Gab • Gruntwerk 16:26, 5 February 2024 (UTC)

text: Here is an example. While it shows "17-17" and "7-7" being corrected, that happened only because I saw in my AWB viewer they weren't corrected, and I manually placed the en dash there. Stefen Towers among the rest! Gab • Gruntwerk 16:56, 5 February 2024 (UTC)
thread_title:  Tie scores being treated as false positives 

message: Vice-President gets corrected to Vice-president, should be Vice President or vice president (I think) DarmaniLink (talk) 18:13, 11 February 2024 (UTC)
replies: text: With respect to companies/organizations, I defer to them using a hyphen in the title per their choice. At the same time, titles like "Vice President of the United States" definitely don't have a hyphen. At any rate,  created rules related to this, so maybe he has some thoughts here. In the meantime, feel free to skip any typo corrections you don't feel comfortable with, or do a manual edit if you so choose. Stefen Towers among the rest! Gab • Gruntwerk 17:38, 12 February 2024 (UTC)
replies: text: Stefen is correct. Note that in Europe the hyphen is generally used, while in the US it is less often used, but this has to be handled case by case. Chris the speller yack 02:06, 13 February 2024 (UTC)
replies: text: Is it "Vice-president" or Vice-President" for  british english/europe? DarmaniLink (talk) 02:09, 13 February 2024 (UTC)
replies: text: Most resources seem to suggest that for 'Vice President' both are capitalized when used as a title. Neils51 (talk) 23:54, 13 February 2024 (UTC)
thread_title:  False Positive