Last modified: 2014-06-20 00:15:06 UTC
HOver on a blue link that points to a disambiguation page - card is blank. We need to figure out what to do here.
Created attachment 15265 [details] screenshot of an disambig link Screenshot of a link to [[Test]], using Hovercards.
Created attachment 15266 [details] Screenshot of a disambig link in navpopups Same link, as seen with default navpopups. It includes a bit more text, but only because there's content above the first ==Heading==.
Created attachment 15267 [details] screenshot of disambig link in navpopups with popupFixDabs=true Same link, as seen in navpopups, but configured with the option: "popupFixDabs=true;" This includes an alphabetical list of all wikilinks on the page. (And enables 1-click fixing of the link.)
If the Popup is blank it won't get generated after the recently merged code is deployed.
(In reply to Prateek Saxena from comment #4) > If the Popup is blank it won't get generated after the recently merged code > is deployed. They generally won't be blank, per my example. I'm not sure what link Vibha was looking at that displayed as blank. (Always include examples! :) Detection: Disambig pages should all have a template on them that includes the "__DISAMBIG__" magicword. Details at [[mw:Extension:Disambiguator]]. Hopefully we can use that to detect these pages, and then format the results in a different way? If so, what are our options? Expectation: For now, I'd like to see something like: 1) "Test" is ambiguous. 2) "Test" is a disambiguation page. 3) "Test" is ambiguous. There are [n] pages listed. As seen in Comment #3 and attachment 15267 [details], there is a good possibility of using these cards as a "call to action" for micro-contributions, per https://trello.com/c/mneeekec/49-fix-disambiguations - That's probably a feature for much later in time, but it's good to keep in mind.
Created attachment 15274 [details] Hover over SoundOFMusic(Disambiguation)
The important case that needs cover here is - Links in the disambiguation text which typically sits in the lead section or a different section. I think we should turn links off for these. There is not much more we can add in a hover card that the sentence isn't already saying. For Example - For other uses, see The Sound of Music (disambiguation).
Nick, Are there other use cases where links appear without the preceding part of the statement?
(In reply to Vibha Bamba from comment #6) > Hover over SoundOFMusic(Disambiguation) [[The Sound of Music]] (wikilinks work as expected in bugzilla ;) Ah, so the Hovercard there isn't /empty/ - it's just not useful. (In reply to Vibha Bamba from comment #8) > Nick, Are there other use cases where links appear without the preceding > part of the statement? See https://en.wikipedia.org/wiki/Wikipedia:HATTEST We have a /lot/ of templates, and they're not always used - Editors sometimes just format the indent+italics manually. Every language will have different wording for their template(s), and might edit it at any time, so we can't use that as a detection method. There are 2 fairly common CSS classes (dablink and rellink), but again, the languages vary. I checked a few, and they use a variety of CSS class names, or no CSS-class at all. Eg. [[fr:Table]], [[et:Laud]], [[nn:Bord]], [[es:Mesa]], [[gl:Mesa]], [[pl:Stół]], [[de:Tisch]], [[tl:Hapag]], [[uk:Стіл]], [[he:שולחן]], [[ru:Стол]], [[ms:Meja]], etc. --- Therefor, it's /possible/ to use this (if we researched & listed all the languages, or convinced them all to standardize) but not easy. Lastly, the links-within-the-hatnote are often not targeting a Disambiguation Page. They often target articles. Eg. [[Abacus]]. Therefor, I still suggest that a translatable string is best. I'd also suggest that something is generally better than nothing, because Inconsistent Behaviour should be avoided whenever possible. HTH.
Do we feel the disambiuation text will help people understand the context any more? My intuition says no, eventually bring able to quickly fix disambiuation links (when the should be fixed) sounds like a great microcontribution but maybe out of scope for the current interation of hovercards
(In reply to Jared Zimmerman (WMF) from comment #10) > Do we feel the disambiuation text will help people understand the context > any more? My intuition says no, Is it better for a reader to hover over a link, expecting something to happen, but getting nothing? If bug 63792 gets fixed (which is necessary for Wiktionary deployment and/or integration), and anything else necessary for getting "content after a ==heading== into the summary", then there shouldn't be very many "empty" hovercards left at all. Therefor, not getting a hovercard for disambig-links would be highly inconsistent. > eventually bring able to quickly fix > disambiuation links (when the should be fixed) sounds like a great > microcontribution but maybe out of scope for the current interation of > hovercards Yup, that's what I said in comment #5, "That's probably a feature for much later in time, but it's good to keep in mind." :) That's a good point, that not all disambig-links should be fixed. The CSS classes in some hatnotes /might/ be the best or only option, for detecting those. Otherwise, it would need a cautionary note in the microcontribution interface. </notesforlater>
