Page MenuHomePhabricator

Allow links to editing help pages to depend on the user's editor (VE, wikitext, ProofreadPage etc.)
Closed, DeclinedPublic

Description

MediaWiki contains a gender magic word that can change text according to the gender of user set in his/her settings. Our community from cswiki would like to ask for similar magic word for VisualEditor. If user uses VE, the magic word would show text/link specially for VE, if user uses source, the magic word would show text specially for source.

Our community on cswiki would like to use this feature for linking between VE and source help pages on the top of those connected pages. The links between these could look like changing translated versions of a page on Meta/MediaWiki wikis, so the main help page would be for VE and the subpage (or page with identifier in parenthesis) would be for source. The purpose of this task is to automatically redirect user to the apropriate help page according to its VE/source setting. That could be done only with a knowledge of user interface setting, which could be provided by a magic word. It could look like this:

#REDIRECT [[Help:{{ve:UserName|Images|Images/source}}]]

Finally a question: Is there any possibility for achieving our intention without requested magic word?

Event Timeline

Dvorapa created this task.Apr 18 2016, 8:51 AM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptApr 18 2016, 8:51 AM
Dvorapa updated the task description. (Show Details)Apr 18 2016, 8:57 AM
Dvorapa updated the task description. (Show Details)
Dvorapa updated the task description. (Show Details)Apr 18 2016, 9:00 AM
Dvorapa updated the task description. (Show Details)
Aklapper renamed this task from Create Magic Word for VisualEditor to Create Magic Word for VisualEditor (to allow linking between VE and source help pages).Apr 18 2016, 9:05 AM
Aklapper added a subscriber: Elitre.
Blahma added a subscriber: Blahma.EditedApr 18 2016, 7:51 PM

I am afraid that "editor used by the currently viewing logged-in user" cannot be turned into a magic word, because that would require evalution at virtually every view (by many different editors) and would break the current practice of caching (with VE/wikitext, there would now be two possible renderings of the page, but more could come with more possible values in the future). The example in the top post would also make it impossible to tell generally (i.e. user-independently), where a page redirects to (which is necessary e.g. for fixing double redirects). Obviously, magic words would not work for this.

Instead, I propose this to be realized by means of a Special page, such as the current Special:MyLanguage, which redirects to a subpage based on the language currently used by the reader.

Also, I think this can be implemented only after "single tab" has been activated on the wiki – i.e. when there actually _is_ a setting that can be reflected in the magic word / special page. If you agree, please add the relevant blocking task if there is one.

JAnD added a subscriber: JAnD.Apr 18 2016, 8:59 PM
Restricted Application added a subscriber: TerraCodes. · View Herald TranscriptApr 19 2016, 7:06 PM
Jdforrester-WMF renamed this task from Create Magic Word for VisualEditor (to allow linking between VE and source help pages) to Create Special:MyEditor shortcut for the user's current editor, to allow linking VE, wikitext, ProofreadPage, etc. help pages.Apr 19 2016, 7:07 PM
Jdforrester-WMF triaged this task as Lowest priority.
Jdforrester-WMF moved this task from To Triage to Freezer on the VisualEditor board.
Dvorapa added a comment.EditedApr 21 2016, 11:10 AM

Special:MyEditor could be too, but @Blahma: is your suggestion also usable in case when we want to create editlink? E.g. cs.wikipedia.org/wiki/Wikipedie:Pískoviště?(ve)action=edit (sandbox page)? (if this functionality is also needed)

@Dvorapa: Edit links which are part of the (cached) rendered page need to be uniform - because of the caching. Single edit tab may change the behavior of what happens after you click a red link (action=edit) and might eventually navigate the user to VE if he prefers that one (but this is only my gues). Any absolute edit links you would like to generate yourself cannot be customized for each user, again because of the caching.

Special:MyEditor must have the same form in the code (for all users) and make a choice only when a particular user clicks on it. I can imagine it having a form like this:

[[Special:MyEditor/ve=Help:Foo/VE,wt=Help:Foo/Wikitext]]
[[Special:MyEditor/ve={{fullurl:Wikipedia:Sandbox|vaction=edit}},wt={{fullurl:Wikipedia:Sandbox|action=edit}}]]

The link target (especially in its expanded form) is getting quite lengthy, however, so this might not be the best approach (although this one would be easy to implement).

Dvorapa added a comment.EditedApr 21 2016, 12:59 PM

@Blahma: I see, like Special:MyLanguage, that could be better approach, you're right.

@Dvorapa: Making the behavior of edit links depend on user's choice of editor is being solved in T114531.
I would therefore prefer this issue to take care only of redirecting to page A or B depending on the editor, e.g. for two sets of help pages, as originally proposed.

Dvorapa added a comment.EditedApr 21 2016, 1:06 PM

@Blahma: Thank you for the link, I didn't know that issue is tracked already, I agree

Keep in mind that there can be various number of editors (Wikimedia sites ATM use four in default plus some of those sites have some additional due to installed extensions) so the solution has to be scalable.

Re the description: Per design, #REDIRECT[[...]] syntax has to be static and not dynamic. (= You can't provide the target by template or magic word etc...)

Removing unrelated projects (please see their descriptions).

Removing unrelated projects (please see their descriptions).

Not helpful. I've undone. Please don't do this again.

Flow does not provide a general-purpose editor for editing normal wikitext pages. So it can't plug into the general-purpose MyEditor.

However, it does support using either wikitext and VisualEditor for posting and editing comments. So if there were content-related documentation for Flow (here's how to suggest a reference on a talk page), the same concept could apply (different help pages for VE vs. wikitext).

This is stored in a preference (based on the last time you modified a Flow editor area (so just previewing in VE doesn't count alone):

This preference is 'flow-editor'.

jayvdb added a subscriber: jayvdb.Apr 29 2016, 7:12 PM

Ideally I can use different registered editors in different namespaces or content models, in which case Special:MyEditor doesnt make sense.

The original feature request was targeting newbies, i.e. people who may even not yet know that there are several editors to choose from. Today, most help pages are concerned with wikitext only, and even if we added VisualEditor alternatives everywhere, it would result in a nasty mixture. At the same, we do not want to force VisualEditor either as any default for those folks who prefer or want to learn wikitext. And it would be boring to need to answer to "which one do you prefer?" everytime before you can read a help page on any topic.

@Blahma, the 'help' problem for new users is a real problem, but magic words, special pages, etc doesnt feel like the right solution; or at least it solves only a tiny part of the problem which is 'getting to the front page of the relevant help pages', and it looks like a lot of technical debt will be created to achieve it this way.

Using a special page to deep link to subpages of the editor help system will require the two sets of help pages have a similar subpage naming convention, and will require some i18n support for the subpage names to enable deep linking. It would be good to see a more complete design if deep linking is an expected benefit of this task.

I cant yet see how ProofreadPage fits into this task; that editor is even more baked into a specific namespace than Scribunto for Module:, as it is basically impossible to edit that namespace without 'ProofreadPage', though soon hopefully there will be VE and SE modes for ProofreadPage. i.e. all user help in the Page: namespace must talk about ProofreadPage; there is no alternative.

Dvorapa added a comment.EditedApr 30 2016, 1:39 PM

@jayvdb There are two levels of this problem. The first is the original and urgent one: How to make MediaWiki redirect user to appropriate help page according to his/her editor settings (just and only VE or source, because they are contrary to each other). This should be somehow provisionally fixed right now (e.g. by Special page, Magic word or whatever).

The second is more important for the future, but less at the moment since we need solve the first one quickly at first in order not to confuse our users. After that we could discuss that second one: What could be the best way to redirect user to appropriate help page according to the editor (s)he's using right now. There comes a place for another ones – Scribunto, Flow, ProofreadPage, ContentTranslation etc. They have got their special use in certain namespace(s) and therefore they are not in straight conflict with each other. But we could discuss possibilities for them too, just later.

@Danny_B Like it is on metawiki, there would be better to make links/redirects like [[Special:MyEditor/Links]] which should link to [[Help:Links]] by default and if user changes an editor in his/her preferences, the link/redirect target will change to [[Help:Links (ve)]] or [[Help:Links/ve]] (it would depend on wiki/project's community naming conventions)

Lydia_Pintscher moved this task from incoming to monitoring on the Wikidata board.May 3 2016, 10:09 AM
Ltrlg added a subscriber: Ltrlg.May 5 2016, 11:32 AM

Is there any progress on this? The help pages on cswiki are still really outdated and this should be resolved at first to start work on new help pages oriented to VE on cswiki.

Dvorapa added a comment.EditedMay 21 2016, 9:18 AM

@jayvdb Can you think up any solution better than this special page/magic word/redirect linking in order to refer new users to the appropriate help page?

Dvorapa raised the priority of this task from Lowest to Medium.May 21 2016, 9:19 AM
Dvorapa added a comment.EditedMay 21 2016, 11:08 AM

@Danny_B Sorry, I didn't known about that.

Is there somebody who plans to work on it?

Danny_B added a comment.EditedMay 22 2016, 1:33 PM

@Danny_B Sorry, I didn't known about that.

Is there somebody who plans to work on it?

That's rather question for @Jdforrester-WMF, but since he already triaged it as lowest, I highly doubt about it for the moment.

Mind the blockers...

@jayvdb Can you think up any solution better than this special page/magic word/redirect linking in order to refer new users to the appropriate help page?

A special page feels like a completely broken design that will cause more problems than it solves, and it creates a special page which will be hard to kill later.

How is the special page going to work on multilingual wikis like meta, mediawiki, commons, etc where links need to be [[Special:MyLanguage/....]] to support I18n? I think [[Special:MyLanguage/Special:MyEditor/Help:Links]] is not acceptable. Will Special:MyEditor also do Special:MyLanguage? Is that feasible?

An 'editor' magic word feels more like it could be a workable design. A magic word is a simple tool that is usable for multiple purposes, and meet your needs if they work in your redirects. Whether those redirects are a good idea or not is something the community can experiment with. I expect that using the magic word in redirects will also be problematic; I would recommend that the magic word is used to customise user talk welcome/notice templates, and other larger chunks of prose, so that the user receives well-written messages designed for their chosen editor, rather than generic messages with editor-specific-redireted links to specific information.

A magic word can be more easily retired, or its usage restricted if it is causing problems.(e.g. the magic word will split the cache by VE vs SE editors, but on a few help redirects it wont be a problem, but if it is in a core UI message on every page then the operation engineers may object.)

I still feel that magic words are not the correct tool for this problem, but then we are misusing the {{int:}} magic word all over the place to achieve good results using the wrong tool.

I have no idea what "current editor" means. The projects associations for this task are also quite mysterious.

@Nemo_bis per original request it should be the editor user uses to edit main namespace. Yes, project associations are after some misunderstandings of the original request quite mysterious and I'd be glad if somebody will clean it up a little bit.

The projects associations for this task are also quite mysterious.

Yes, project associations are after some misunderstandings of the original request quite mysterious and I'd be glad if somebody will clean it up a little bit.

No they are not. They contain all projects involved in this request. See T132897#2251705.

I also don't see how ProofreadPage, CharInsert or Scribunto are relevant here. @Danny_B @Jdforrester-WMF I think you should justify every one of the projects this task is associated with (otherwise I'm going to remove them all).

I've originally removed projects. T132897#2251018 Then @Jdforrester-WMF readded them T132897#2251475 and asked me to add all projects which have their own editor or are editors themselves. All of those either do have their own editor (ProofreadPage, MediaWiki-extensions-Scribunto) or are editors themselves (CharInsert). The recently removed MassMessage actually also has its own editor.

I personally don't care wheter all such projects are attached or none. But it doesn't have a sense to have only part of them.

In any case it would be reasonable if you WMF guys could agree on something stable and not revert each other.

Well, ProofreadPage 'provides' a source (raw wikitext) editor for any title in the namespace managed by ProofreadPage. So I can see why one person might think it needs to be part of this proposal!
But if the user has chosen to use VE for ProofreadPage, they are still using ProofreadPage. There will be some help topics that need different Help pages, but it is source-editor-in-proofreadpage vs visualeditor-in-proofreadpage.

There is also huge differences between VisualEditor in namespace 0 and VisualEditor in the Page namespace on Wikisource. The screens will look very different. The current solutions proposed in this task cant assist when VE has different layout based on namespace. If it is just a magic word, wikisource will probably not use it, and can ignore and discourage it being used on wikisource. If it is a special page, it will almost certainly be a badly designed nusiance on Wikisource.

Nemo_bis renamed this task from Create Special:MyEditor shortcut for the user's current editor, to allow linking VE, wikitext, ProofreadPage, etc. help pages to Allow links to editing help pages to depend on the user's editor (VE, wikitext, ProofreadPage etc.).May 29 2016, 9:33 AM

I think this entire task is bad by design and would suggest to decline it.

How many pages would use such feature? A dozen? That's too low to be worth to work on such feature.

The proper solution is to have the help pages simply structured properly and create proper navigation between them. Have pages or sections of whatever is default editor to display as default (= link to them at first) and link to differences from there. Advanced users, who have been able to change the default behavior to something else, will definitely be able to lookup further in the help.

Note: Entire help area on cswiki is quite messy and no magic word (or other feature) will help it. It deserves complete restructuralization which would also solve this.

Nemo_bis closed this task as Declined.May 30 2016, 7:21 AM

I agree; closing per rationale above.

@Danny_B cca 50 help pages on cswiki and much more e.g. on enwiki and others. Yes, it is quite messy, but this could help to make it better. How can we than solve this issue on cswiki?

Dvorapa added a comment.EditedMay 30 2016, 5:33 PM

@Danny_B @Nemo_bis What if there is a help page, which is exactly the same for VE and SE, just there is a one button text, which is different for VE and SE (like Check changes vs Preview changes)? The magic word could help to resolve this issue easily. (Please see Nápověda:Pískoviště on cswiki. The button for showing changes is "Zkontrolovat změny" for VE and "Ukázat změny" for SE)...

GOIII moved this task from Backlog to Done on the ProofreadPage board.Jun 12 2016, 4:03 AM
Restricted Application added a subscriber: Liuxinyu970226. · View Herald TranscriptJul 22 2019, 4:46 PM
Restricted Application removed a subscriber: Liuxinyu970226. · View Herald TranscriptJul 22 2019, 8:21 PM
happy5214 moved this task from Backlog to Closed on the WikiEditor board.Aug 4 2019, 12:00 PM