The result of the debate was Support proposal. —spookywillowwtalk 04:06, 3 November 2024 (UTC)
So, as the mainspace sweep gets underway and we work out the kinks, it's come up that technically, the logic that C4-DE operates under when it comes to dashes is against the WP:DASH policy to only use the &xdash; form of dashes. The way I've coded it, and the way that I've seen on most articles, is that when it's a native wikilink to an article that includes the dash, like The High Republic — The Blade 1, it uses the actual — character and not the xdash form, as that's what you'd get if you typed in "The High Republic - The Blade" and let autosuggest complete the link for you. (this works with any dash too, thanks to Imp, I promise to automate this next week)
Personally, I find this to be convenient enough to warrant an exception to the dash policy, as autosuggest is the best way to make links. Autosuggest also does not work when you use the xdash format, as it's only converted to the proper character after page compilation when you view the page.
Therefore, I propose that the WP:MOS#Punctuation item about dashes be updated to the following, with new text in bold:
- To easily distinguish between hyphens and dashes in the editing interface, create em dashes and en dashes by typing "
—" and "–", not—and–, respectively, with the exception of em and en dashes that occur within wikilinks to Wookieepedia articles with dashes in their title. For such links and their appropriate pipelink formatting, the—and–characters should be used directly as provided by link autosuggestion.
Support
- As proposer. xdash format actively breaks autosuggest, and I can automate the maintaining of Imp's dash redirect project, so that autosuggest will work for all dash links with just hyphens; I think mandating xdash format specifically in links just leads to broken links and unnecessary complication for editors. Cade
Calrayn 19:24, 19 October 2024 (UTC)
- Imperators II(Talk) 21:43, 19 October 2024 (UTC)
- Still visually looks the same but definite agree on allowing autofill; has been somewhat the running standard for some time now even in spite of policy. Autofill saves people a lot of time, and having it this way for these links also makes any/all future bot work regarding these links much easier to update when page titles change, which is a concern for sources used a lot of places since we never really do large-scale work by hand anymore.—spookywillowwtalk 21:46, 19 October 2024 (UTC)
- NanoLuukeCloning Facility 21:49, 19 October 2024 (UTC)
- Makes sense to use the actual, direct text of the page title in links. Zed42
(talk) 22:00, 19 October 2024 (UTC)
- CometSmudge (talk) 22:22, 19 October 2024 (UTC)
- Although consistency is King, in this instance I think the convenience of the autosuggest and the fact that having to alter auto suggest links might confuse new users are reason enough for an exception. Ayrehead02 (talk) 10:11, 20 October 2024 (UTC)
- — Commander Bhatoa (talk) 01:00, 21 October 2024 (UTC)
- Fan26 (Talk) 03:18, 21 October 2024 (UTC)
- I think including the exact article title in links is the real Consistency™ here. Putting dash codes in links feels like stacking cards that might get swept away by a random Mediawiki or Fandom update. OOM 224 (he/him/they) 09:50, 24 October 2024 (UTC)
- - ThePedantry (talk) 21:54, 24 October 2024 (UTC)
- Master Fredcerique
(talk) (he/him) 23:47, 24 October 2024 (UTC)
- Booply (talk) 00:16, 27 October 2024 (UTC)
- Xd1358 (Talk) 20:54, 2 November 2024 (UTC)
Oppose
- I prefer consistency here. I use auto suggest, and then replace the dash as necessary to align with policy. NBDani
(they/them)Yeager's Repairs 21:39, 19 October 2024 (UTC)
- Per Dani, I think this creates needless inconsistency. I get from an editing point of view it's easier to stick with what autosuggest, well, suggests, but overall it creates a weird split across the site. I wouldn't necessarily be opposed to getting rid of these sorts of wikilinks fully, but in this capacity it's just creating inconsistency. Tommy-Macaroni (he/they) 21:46, 19 October 2024 (UTC)