When VE is not installed, the text of the "edit" link in the topbar is defined by the skin, for instance by the message Vector-view-edit. When VE is installed, it adds a new button to the topbar for visual edits, so to have "edit" (= VE edit) and "edit source". VE defines the "edit source" message itself (it's Visualeditor-ca-editsource), but reuses the skin message for "edit" (in the example above, Vector-view-edit).
This means that it's not possible to change the topbar buttons to be e.g. "edit" for source editing and "visual edit" for VE edits: if you do so and a user disables VE in their preferences, then they'll only have a single button reading "visual edit" which will bring them to source edit mode.
Reusing message is seldom the right choice, and here VE should add its own message for "edit".
Description
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Stalled | None | T237847 Link "Edit" on the Chechen Wikipedia | |||
| Open | None | T219056 VisualEditor should use its own message for the "Edit" tab |
Event Timeline
For third-party wikis, you can actually configure it this way:
$wgVisualEditorTabMessages['edit'] = 'visualeditor-ca-ve-edit'; $wgVisualEditorTabMessages['create'] = 'visualeditor-ca-ve-create';
For Wikimedia wikis, I think it was an intentional decision not to do it – to promote visual editor as the "normal" editor. I am pretty sure it used configuration similar to the above once upon a time though, when it was being introduced as beta (alpha?) software, but it was changed after a few years. I can't find anything to confirm my memory though, so maybe I am imagining it…
I was suspecting something like that. Now I don't want to open a discussion about whether this is good, or if VE is better than source, or what should be pushed as default.
However, shouldn't it at least use a separate message?
This way, communities would be able to decide what to push as default (or just leave everything as it is). They may also want to have "edit source" and "visual edit" (so not to have a "preferred" one). However, this way they can do nothing with that message, and I think this isn't good. Unless they use some JS trick, of course, but that'd be a super-overkill.
So it's good that these can be overridden at all, but having this behaviour of changing the tabs around and hijacking and rewriting the default messages for the editsection links is still just not the right approach. Messages should only be reused when they are being reused for the same behaviour, or another of the same object. In this case, editing via VisualEditor is a completely new behaviour, and thus should only have a new message. (By all means default this to inheriting the default edit tab/whatever message content or whatever, but it still needs to only be a single, distinct thing.)
As an example, this causes problems with pages where there is only default editing, especially if they are not actually content models where users will be editing any source, or perhaps that even have a source/render distinction to begin with. To edit the page is to edit the page (we even reuse the edit action), and yet 'edit' still inexplicably becomes 'edit source'. Similarly, we cannot reuse the 'editsection' messages for section editing despite this actually being the same edit section action as the default, because, again, there is no source to edit, and the 'editsection' message has been hijacked to say something new, and thus we are forced by another extension's poor practice to create a new message for an instance where it actually would make sense to reuse it.
So to summarize, the request is: if VisualEditor is available for a given page, then instead of just not changing the "edit" tab text, we should wrap it in another message, so that this new message can be overridden on-wiki? (Something similar should probably be implemented for the section edit links.)
That sounds reasonable to me. Realistically, we're probably not going to work on this, but we'd be happy to review patches. You can find the relevant code in:
- For tabs: VisualEditorHooks::onSkinTemplateNavigation (PHP) and ve.init.mw.DesktopArticleTarget.init#setupMultiTabs (JS)
- For section edit links: VisualEditorHooks::onSkinEditSectionLinks (PHP) and ve.init.mw.DesktopArticleTarget.init#setupMultiSectionLinks (JS)
(The logic is duplicated in PHP and JS, because the PHP HTML output is cached for a long time for unregistered viewers on Wikimedia wikis, and when the configuration for this changes, it wouldn't be reflected immediately, so the JS code is able to fix it.)
I'm not sure if that's right or not (I honestly lost track of what all this task was/what the comments, including my own, were going for at this point when trying to reread it the other day), but that would definitely solve some of the problems we've run into.
Bear in mind too that changing the message keys using the array as you previously described also didn't seem to entirely work as expected either when I tried it earlier (I wish I had some actual information on what did happen, but I was tired enough that I just gave up at that point). So if anyone wants to retest that per the full doc onwiki and see if it's working now or could likewise be used to address the specific 'edit' message issue regardless (and add a specific example to the wiki if it does work for this?), that would also be useful.
Here, the editing link is called "Edit Visually" which does not correspond to reality. We participants in the Chechen Wikipedia are also waiting for the separation of these messages. We hope to correct soon.