Page MenuHomePhabricator

Preview tab has disappeared
Closed, DeclinedPublic

Description

The preview tab in WikiEditor (added from gadgets) has disappeared.
The gadget relay on - "ext.wikiEditor.preview".

I was told I could request it be reactivated. Can you help?

Event Timeline

TMagen created this task.Jan 23 2018, 7:53 AM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJan 23 2018, 7:53 AM
Aklapper changed the task status from Open to Stalled.Jan 23 2018, 1:53 PM

Hi @TMagen,
Thanks for reporting this. Please provide steps to reproducre the problem by following https://mediawiki.org/wiki/How_to_report_a_bug .
We do not know which MediaWiki version this is about, which website this is about, which exact gadget.

Also, see https://www.mediawiki.org/wiki/Help:Locating_broken_scripts how to find potential reasons.

  1. This is regarding HEWIKI
  2. Using either Chrome, Firefox or Internet Explorer
  3. Open any article
  4. Click Edit
  5. There is no preview tab

Also - I was sent by a programmer who said this is a known issue due to editing interface updates that rendered the mentioned gadget no longer supported, but that upon request you will re-enable it. So that is what I am requesting... Your help is greatly appreciated.

TMagen added a subscriber: eranroz.Jan 23 2018, 2:56 PM
eranroz changed the task status from Stalled to Open.Jan 24 2018, 7:58 AM
eranroz added a project: WikiEditor.
eranroz updated the task description. (Show Details)

Seems to be related to T165112

Jdforrester-WMF closed this task as Declined.Jan 24 2018, 4:14 PM
Jdforrester-WMF added a subscriber: Jdforrester-WMF.

Yes, this feature was unsupported and is now removed.

eranroz reopened this task as Open.Jan 24 2018, 6:00 PM

Yes, this feature was unsupported and is now removed.

This feature was supported and used by 150 active users (based on https://he.wikipedia.org/wiki/Special:GadgetUsage ).
Where is the discussion about removing it?

(This is apparently about the QPreview gadget: https://he.wikipedia.org/wiki/מדיה_ויקי:Gadget-QPreview.js)

I don't think we realized that someone has made a gadget to load this feature... it was disabled in WIkiEditor configuration for years (I think it was a "beta feature" for some time around 2010, and then it got disabled for good).

Note that MediaWIki now has a built-in quick preview feature, you can enable it in Preferences / Editing (last option on https://he.wikipedia.org/wiki/מיוחד:העדפות). Is that a satisfactory replacement?

@TMagen , I see matmarex give similar answer to what I explined on WP (in my talk page) except the comment about Beta feature which I wasn't aware of it. Presonally I prefer the built-in quick preview in mediawiki core. Does quick preview satisfy the needs? if not, can you explain why do you prefer preview tab?

TMagen added a comment.EditedJan 25 2018, 10:20 AM

I prefer the tab, because endless scrolling up and down is time-consuming, difficult physically (my carpal tunnel syndrome has flared up seriously in the past week, even though I'm now doing about 10% of my usual editing rate due to this change, and it isn't easy on the eyes either), and frustrating. The preview, whether above or below the editing window requires scrolling down to click the preview button, scrolling back up (or further down) to see the preview, and then back down (or up) to make necessary changes, and then all over again. When dealing with issue like references, which can be messed up by RTL - this is can be problematic. The tab lets me go back and forth with minimal scrolling, helping to ensure I get the right result.

Hi, I use this feature as well, and would much prefer its reinstatement. Cheers.

TheDJ closed this task as Declined.EditedJan 31 2018, 10:49 AM
TheDJ added a subscriber: TheDJ.

It won't be reinstated. If you want the software to do things that are not supported, you need to carry the maintenance load for that. So if you want to fix the gadget in question, by copying around code out of the old (now removed) module and you take responsibility for maintaining that code, then sure go ahead. But from the developer side, this was an unsupported feature, that caused us headaches and that's why it was removed. This ticket itself is evidence of that overhead headache.

"upon request you will re-enable it. So that is what I am requesting.."
Things can always be requested, and we welcome every request and question at all times. However, there should NEVER be an expectation that a request will always be fulfilled. That's not how this works :)

To answer by analogy: We are just a couple of juggers with 2 hands and 1000s of things to be juggled. We decided to drop this item from our juggling. If you want this thing to continue to be juggled, you will need to become a juggler and juggle it yourself. Otherwise, the item will continue to lay on the floor.

TMagen added a comment.Feb 4 2018, 9:41 AM

I'm pretty sure the snarky response is uncalled for. For one, when I as an editor select an option that is offered to me in the system, as far as I know it is supported. As a user, I cannot know and should not be expected to know, what you are juggling, and why, and how features are part of the interface but somehow in a "not supported" status. That's one. In addition, I asked about it in hewiki helpdesk, and was told that all I need is to ask for it to be reinstated, and that is what I did. If the information I received was wrong, or I misunderstood it - that is the only basis of any expectations, certainly not "expectations that a request will always be fulfilled". I'm still not sure what massive avalanche of expectations you are experiencing from that. It mostly seems as though all that was required of you was a response or two on a page. Oh my. Set up the guillotine, I guess. Third, if someone opening a ticket for an existing feature (as far as anyone can know) is "proof of a headache" that led to the feature being unsupported - that is circular logic, and I hope you aren't using it to code with. Also "this is a headache" kind of contradicts "we welcome every request and question at all times. Also - if you don't support something - you should remove it. Not the end user's responsibility. Finally, adding a :) to a not-nice response doesn't make it nice. You could have left it at: "We are unable to support this feature, sorry you were misled, we missed the fact that it was being offered on hewiki, and will make sure the options is removed." Have a nice day. :)

I do not see any snarky response in this task, just a clarification how things work.

TheDJ added a comment.EditedFeb 5 2018, 3:59 PM

@TMagen i think the confusion comes from the fact that Gadgets are not officially supported software elements (and this is why they differ for each language/sister version of the wiki's) even though they are available in the interface. This is well understood from a developer perspective, but indeed often poorly understood from user perspective. The same goes for anything on wmflabs.org. Not official software, support is on a basis of the goodwill of individuals. Yet tens of thousands of people use the stuff there. We allow for it, because it makes everyone more efficient, but when some of this stuff breaks, it does create communication problems.

Questions are always welcome, but responses can be terse and/or take long. Don't take offence, because offence is rarely intended. But this is not a commercial support desk for consumers that need frivolous sugar coating. :)

This specific feature was experimental and apparently disclosed through the he.wikipedia gadget system. We don't support it (we never have), that's why we removed it and we would expect gadget maintainers to remove this gadget from their list of Gadgets.

TMagen added a comment.Feb 5 2018, 4:07 PM

Thanks for the detailed explanation. I'll miss it. RIP.

Kghbln added a subscriber: Kghbln.
happy5214 moved this task from Backlog to Closed on the WikiEditor board.Aug 4 2019, 11:57 AM