Talk:2017 wikitext editor/2016

Hi, thanks for your interest in the 2017 wikitext editor. Please post all feedback at 2017 wikitext editor/Feedback, in any language. Thank you!

Compatibility with current editor behaviour

There's a debate at Talk:Wikimedia Product which seems to be going nowhere because it is not clear what the planned behaviour of the new editor is with respect to previewing.

Is it planned that the new editor should be capable of rendering what the current editor renders, and in the same way? That's a design decision that will have been taken early on. However the WMF interprets "Agile" (and I think the prevailing interpretation is not an entirely productive one), the answer to this cannot reasonably be, let's write some code and see whether it does or not. That decision, and those differences, will have to have been made clear early on, so that the community can decide whether it is a blocker (see discussions around Technical Collaboration Guideline/Community decisions) and if it is agreed by the community that they are willing in principle to accept differences in behaviour, and agreed the scope and scale of the differences proposed, then there needs to have been a discussion leading to a clear description of what will and will not be rendered the same way by the two software systems. It would now be useful to see the records of those discussions and those decisions.

In the case of the specific debate I mentioned, there is a non-meeting of minds because these issues have not yet been surfaced, and the the resolution has to be that if the new editor is supposed to render HTML in the same way as the current one, then the behaviour reported is simply wrong. If the new editor is supposed to render some input the same and some differently, then the behaviour here may or may not be wrong, depending on the proposals for the scope of the differences to be tolerated between the two rendering engines.

So: is the new editor supposed to render the same code in the same way as the old one? If not, what is the scale and the scope of the difference? Simple questions. I hope someone can publish the clear, definitive and agreed answers. Rogol Domedonfors (talk) 07:25, 9 October 2016 (UTC)

+1, and thanx Rogol for bringing the discussion from Talk:Wikimedia Product to here.

I think accurate previews is a critically important issue for community acceptance of the new editor. Experienced editors expect the wikitext editor to give accurate previews, and new editors would be particularly harmed by inaccurate previews. A critical reason wiki has been successful is because a new user can just jump in, try stuff, and preview to see how it works. Inaccurate previews will confuse them and undermine their ability to figure out what's going on, and why.

The current version of the new editor clearly uses Parasoid for previews. This results in many random inaccuracies in how preview are rendered. It seems obvious that the wikitext editor should use the same (PHP) render engine that article pages use, just like the current wikitext editor does. This automatically gives accurate previews. This also ensures that previews and article views always stay in sync "for free" when any update is made to article rendering.

Can someone from this team answer whether you'll fix this? If there is any question whether this is a significant issue, I can open a community process to get you feedback on whether the community considers this an important blocker. Alsee (talk) 15:41, 9 October 2016 (UTC)

We continue to iterate both parsers towards the same output for the same input. Any differences between them should be filed in Phabricator so that they can be fixed. Jdforrester (WMF) (talk) 15:27, 11 October 2016 (UTC)

Parasoid is clearly not ready for this purpose. It can't even display red/blue/black/external links properly, sometimes it can't track refs properly, and there's an unknown but vast number of random things it gets wrong. I'm just one editor making occasional exploration of the issue, and I continually find new random issues in Parasoid renders.

So back to my question, is the WMF willing to switch New Editor to use the article-parser for previews?

If there is any question whether this is a significant issue, I can open a community process to get you feedback on whether the community considers this an important blocker. I expect the community is going to want any New Wikitext editor preview to be as accurate as the current wikitext editor preview. I expect the community won't want new editors getting a sabotaged/broken wikitext environment.

I think this is going to be a blocker. Alsee (talk) 02:32, 13 October 2016 (UTC)

@Jdforrester – This is a fine aspiration, but I find it hard to believe that they will ever be completely and reliably identical. The issue is larger than the occasional unintentional differences and synchronization errors. The Visual "WYSIWYG" editor has a fundamental requirement to render something amenable to editing. "Preview" has a fundamental requirement to render exactly what will be seen when the page is saved. These are different requirements.

In the visual editing environment, if What You See Is sometimes not exactly What You Get, whether due to incompleteness, or error, or some practical compromise by design, it is a feature of that editing environment, and needs to be dealt with or accommodated or endured in that environment. The purpose of a "Preview" function is to step away from the editing environment and display what you will actually get when the page is saved.

Whatever advantages may be perceived in using the Visual "WYSIWYG" engine in both environments, they cannot be allowed to override the fundamental purpose of a "Preview" function. It is not to view what you would see in another editing environment, but to view what you will actually get in the reading environment.

For a Preview function to fulfill its fundamental purpose it is clearly logically sufficient to use the same engine that renders saved pages in reading mode. I think it is also pretty obviously logically necessary because in the real world, unlike the world of aspirations, it must be expected that differences can and will creep in between What You See when editing and What You actually Get upon saving.

Any other approach, however well intentioned, must miss the mark and ought to be a blocker. Ningauble (talk) 15:02, 17 October 2016 (UTC)

Ping Jdforrester (WMF). Can we get a response here? Alsee (talk) 19:30, 20 October 2016 (UTC)

Thanks for that clarification. It has been said elsewhere that "the goal is to have a single parser for all editing tools and all platforms" which is a stronger assertion (but consistent with it of course). Is it currently intended that Parsoid will be that product? Please indicate the location where we can see the high-level plan (roadmap, stragegy, whatever you like to call it) which makes things like this clear, so that we don't waste your time asking questions like this. Rogol Domedonfors (talk) 17:11, 11 October 2016 (UTC)

Well, the principal declaration was in this year's annual plan (https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2016-2017/Final, specifically [1] " we will unify around a single Wikitext parser for both reading and editing" and "We will modernize the wikitext format to be more powerful and predictable, using a robust testing system to guide our work. This will include minor syntax changes and improved templates, making them simpler by restricting the technical impact on the output of the page.".

Individual work against this is generally tracked in the quarterly reviews and Phabricator. The current major area of work is replacing Tidy and better native support for various things like <gallery> so that they work identically. Jdforrester (WMF) (talk) 18:57, 11 October 2016 (UTC)

Thanks, although that declaration is very high-level indeed. The new Technical Collaboration Guideline implies that lack of a dedicated project or product page is a blocker ipso facto. Presumably such a page will be created for the single parser project when those Guidelines come into force? Rogol Domedonfors (talk) 08:33, 12 October 2016 (UTC)

I thought that this page is that. In what ways do you think it fails to be a page dedicated to the project? What is missing that we can improve? Jdforrester (WMF) (talk) 20:33, 12 October 2016 (UTC)

It seems unlikely that a page titled "2017 wikitext editor", and on which the word "parser" does not appear, is a page dedicated to the project of unifying around a single wikitext parser. It may well be a page dedicated to a new editor, and the new editor may well be connected with the unified parser project, but that does not make this page the page dedicated to the unified parser project. Rogol Domedonfors (talk) 21:40, 12 October 2016 (UTC)

Oh, sorry, I didn't understand your meaning. I think you want Parsoid, a project that's been underway since 2011. Jdforrester (WMF) (talk) 22:49, 12 October 2016 (UTC)

No, I am talking about the parser unification project or single parser project, which, as you pointed out was foreshadowed in the 2016/2017 annual plan, and which, according to your comment, is currently documented in a disparate collection of internal reports and Phabricator tasks. It is not, as far as I can tell, documented in a project page or plan of its own, which is odd for a project specifically mentioned in the annual plan. Parsoid is a piece of software which as you point out has been around for some time (and which I am aware of, thank you very much). It is a parser but not a parser unification project. Parsoid might be the parser around which you propose to unify, I don't know. There needs to be a page explaining, for the benefit of the participants in this project, in related projects, and the developer and user communities at large, what this parser unification project is, what it aims to do, how in broad terms it aims to do it, who is involved, what steps are being taken, what the timeline is, and all the other information that is needed to get a satisfactory community engagement around it. This is not a matter of satisfying my personal curiosity, but a matter of good community engagement. Indeed, as I have pointed out, the Technical Guidelines under discussion right now suggest that the absence of this sort of communication is a blocker in itself.

So please either point to the page that fulfills that role for the parser unification project, or, if there is no such page, just say so, and say what steps you propose to take to ensure it is delivered. Rogol Domedonfors (talk) 04:10, 13 October 2016 (UTC)

The "parser unification project", as you put it, is part of the work of the Parsing team and captured on Parsoid, as I said. Jdforrester (WMF) (talk) 19:11, 28 October 2016 (UTC)

I am referring, as I am sure you are perfectly well aware, to Meta:Wikimedia Foundation Annual Plan/2016-2017/draft#Program 4: Maintain and improve content creation and editing tools which states as "Goal 1: Maintain and incrementally improve current content creation and curation interfaces" / Objective 1 In support of these changes, unify around a single Wikitext parser for both reading and editing. Do you seriously challenge my calling this the parser unification project? Do you seriously maintain that as Product Manager of the Editing Department, you are not thoroughly familar with the nature and content of this Objective? Do you deny that you could provide more details if you wanted to?

More seriously, there is no mention of a proposal to unify around a single wikitext parser on the page Parsoid and I fail to understand why you suggest there is. Indeed, I am unaware of any more detailed description in the public arena of this component of this objective than the single sentence I have quoted above. If you can point to such a document then please do so, and if there is no such description then please say so. Simply repeating an unhelpful comment is unhelpful. Rogol Domedonfors (talk) 21:07, 28 October 2016 (UTC)

Rogol, the Technical Collaboration Guideline is a set of recommendations. Even when published officially, not having a product page is not an automatic blocker because the TCG is not a part of a product's development process - it's suggested best practices. Please don't try to use it against product teams in this manner. Keegan (WMF) (talk) 19:29, 20 October 2016 (UTC)

Do understand, it is a best practice to publish this information on a wiki page, it's great for community engagement, but my point is that I don't want the TCG to be used as points against product teams. It weaponizes what can otherwise be a positive, cultural influence internally. I'd like to focus on doing things better with it. Keegan (WMF) (talk) 19:55, 20 October 2016 (UTC)

Firstly, I'm baffled by what practical value you expect the TCG as a set of recommendations or suggestions for best practice to have if you expect no one to point out when a project is not conforming with them. I too am anxious that the WMF and the community should do things better together, which is why I am disappointed to hear that this new project is starting off in a way that is not apparently consistent with what will shortly be proposed as best practice, but far more importantly, in a way which runs the risk of failing to involve the community of editors and readers who are going to use the product when it arrives. These are not disjoint issues. The object, which I applaud, of the Guidelines, is to increase the level of productive engagement. To use the language of "weaponization" is unhelpful and I am disappointed that you should have done so.

Secondly, please would you be so kind as to give the answer to my question, which I presume to be a simple "yes" or "no", as to whether the parser unification project or single parser project, as foreshadowed in the 2016/2017 annual plan, currently has a single project page or plan which can be exhibited to editors and readers?

Thirdly, as a follow-up, if the answer is currently "no", please would you be so kind as to say whether it is proposed to provide one, and if so what steps are being taken to deliver it? On the other hand, if the answer is "yes", please be so kind as to indicate its location. Rogol Domedonfors (talk) 20:00, 20 October 2016 (UTC)

JavaScript and load time

Firstly, I like that you are trying to update look and feel of standard editor and bring more functions to it. However, I would go on on a bit of rant and say that this initiative brings concerns, rather than solves any inconvenience of current editor.

Visual editor, despite all of its features, is still an unoptimised beta-monster. Current load time for an article about Socialist International is astonishing 20 seconds on Firefox 47 (Windows 8.1), and I can’t complain about resources of my computer. With comparison to load time of standard editor, which is just 4 seconds, it raises an important question: would it rely entirely on capabilities and downsides of JavaScript? Or would it be a server-generated (therefore, faster) editor? As currently seems from given examples, it’s rather prior.

I really hope that your initiative, which is made probably in good faith, would not introduce us to another unoptimised monster. If we would have to wait for minute or two to make a minor edit, I think that Wikimedia movement would be able to live without a new shiny editor.

I hope my concerns would be at least mentioned in some form when Wikimedia Foundation, in its ‘usual authoritarian and bossy manner’, will (without any doubts and questions) roll out this editor to communities, because users are becoming more and more tired of forced unpolished features that are being spat out in existence by Wikimedia Foundation developers. stjn^[ru] 19:38, 12 October 2016 (UTC)

The new editor is based on JavaScript, yes.

I agree that four seconds is shocking and terrible performance; the load of that page is ~3s with JavaScript and ~1s without in the 2010 wikitext editor for me. That page is 82KiB, which is a lot more than the old guideline of articles not extending beyond 32KiB, and has lots of unnecessary tables, but we need to make performance better, yes. FWIW, it's about 17s in VE and the 2017 wikitext editor. Jdforrester (WMF) (talk) 20:31, 12 October 2016 (UTC)

I suppose that affecting to believe that the original comment was a complaint about the slowness of the old editor might have been considered somewhat amusing, but jokes by staff at the expense of volunteers trying to make a comment about the new editor, or the still far from ideal state of the relationship between the staff and the volunteer community, however trenchant those comments may be, are likely to divert the conversation down unhelpful channels. Please try to treat serious comments seriously.

Do you consider it satisfactory that the new editor apparently takes five times longer to load a page than the old one? If not, what action is proposed to make it faster? Rogol Domedonfors (talk) 21:45, 12 October 2016 (UTC)

Regarding your last question "If not, what action is proposed to make it faster?", Jdforrester already wrote "we need to make performance better, yes." Malyacko (talk) 08:27, 13 October 2016 (UTC)

Firstly, the recognition that something needs to be done is not an answer to a question asking what thing it is that is going to be done. Secondly, the comment "we need to make performance better" was part of a comment about the old editor. My questions were about the new editor. Are you able to answer the question, what action is proposed to make [the new editor] faster? Rogol Domedonfors (talk) 16:27, 13 October 2016 (UTC)

Software speed is a valid concern and developers in this discussion have stated that they are well-aware of the concern. As with any software program that exposes unwanted behavior, the action that needs to be done is to analyze code and then change code. I'm honestly not sure what else you expect as an answer here in this early stage; maybe you could clarify. Malyacko (talk) 19:56, 15 October 2016 (UTC)

What I expect is an answer that actually addresses the plain meaning of the comment and engages with its substance. What I do not expect is an answer that mocks the concern expressed by purporting to misunderstand it and use that pretended misunderstanding to as an evasion to answer some other question instead which is clearly not the one proposed; I equally do not expect members of the staff with a remit to "to help make sure the Editing department understand what the community wants and needs" to consciously and deliberately try and obscure the issue; nor do I expect paid staff to use the time paid for by donor's money to make fun of volunteers.

Your statement that "developers in this discussion have stated that they are well-aware of the concern" does not appear to be correct. As I pointed out, the single response was a non-answer to a non-question. It is not clear that your second sentence is a specific answer to the specific question of what is happening to improve performance of this product, rather than a statement of general principle that might or might not be in operation here.

What I do expect is plain answers to plain questions. In this case, do developers of the 2017 wikitext editor reagrd its performance, as described here, as satisfactory and if they do not what action do they propose to improve it. I can see no good reason to avoid addressing these simple, clear and highly relevant issues. Rogol Domedonfors (talk) 21:25, 15 October 2016 (UTC)

4 seconds is not terrible performance (and it really depends on gadgets and everything) if you can actually use a form while editor is still loading (and you can in current environment). 20 or 17 seconds to wait while being completely unable to edit is terrible performance. I really hope new editor would not bring such inconvenience since it’s based on JavaScript and visual editor’s annoying progress bars.

On page size: you should acknowledge that vast majority of quality content in Wikipedia exceeds the point set in ‘old guideline’. In Russian Wikipedia, for example, you will not find a featured article in that sort of size, nor a good one (can’t be sure about latter though). If you develop a tool which would in some turn of events replace current editor, you should aim for excellent (= comparable with standard editor) performance up to 250 kB, not up to 32 kB. stjn^[ru] 20:55, 12 October 2016 (UTC)

I'm in the US, I have broadband cable internet, I have Win7 with a quad-core 64bit CPU that was mid-to-high-end in 2012. Although I work with a large number of browser tabs open.

Visual Editor took FORTY ONE seconds to load for me, on Socialist International. The normal javascript wikitext editor took 2 or 3 seconds. (A moment more for the toolbars to finalize, but that doesn't block editing.)

That is somewhere around 14x to 20x load time difference. If that is going to be the load time for New Wikitext Editor then it is effectively unusable. This is just one of the reasons that it is vile that you want to set Visual Editor as the default-first editor that loads first for all new users on all wikis. That is a nasty nasty way to drive off new editors. Alsee (talk) 23:04, 12 October 2016 (UTC)

Hooks for gadgtes and user scripts?

Current wiki-code editor has some scripts written for it. Might be as simple as a button that does something with currently selected wiki-code. Will you be making hooks and tutorials that will allow easy creation of a user-scripts?

I'm asking because I was just trying to extend VisualEditor and it took me something like 2 intense days of digging to be able to simply add a button. Even worse. I didn't really found a way to nicely hook into on some on-ready event. I had to overwrite (proxy) one of methods of existing classes (specifically I had to wirite a proxy for `ve.ui.FindAndReplaceDialog.prototype.onFindChange`).

VE docs are nice I give you that. But they lack recipes... Or maybe I missed them. Good thing docs are linked with source code. Helped a lot when I noticed this...

So to conclude - if you are going to replace current editor please add in-docs examples of hooking into the editor toolbar and such and please add hooks for user-scripts. Nux (talk) 20:03, 17 October 2016 (UTC)

I agree – I found it hard as well to understand how VE works and how I can attach scripts; it is nice to have the API documentation, however, without some introduction, examples or tutorial it is almost impossible to extend it or contribute to it. Simulo (talk) 10:00, 18 October 2016 (UTC)

They have promised me that it will be easy to add buttons (and similar things), and that they will produce some documentation and example(s) about how to do so.

On the less-happy side, they have also promised that all of the scripts used with the 2010 wikitext editor will be incompatible, and they have not promised a specific date by which the docs will be published.  So I think this adds up to "good news for the future" rather than "good news for today". Whatamidoing (WMF) (talk) 21:13, 20 October 2016 (UTC)

There is VisualEditor/Gadgets where is some information for writing gadgets, but in example complete list of hooks are missing. Also some basic information like how to detect when user is switching to visual editing or to wikicode and what should do when that happens. Zache (talk) 09:23, 10 November 2016 (UTC)

Editpage.js

What is written locally in the MediaWiki:Editpage.js may cause issues with this editor? Sunpriat 21:52, 21 October 2016 (UTC)

It probably could. @Matma Rex might know the answer to your question off the top of his head. Are you concerned about the Russian Wikipedia, or another site? Whatamidoing (WMF) (talk) 03:37, 23 October 2016 (UTC)

Yes ru:MediaWiki:Editpage.js Sunpriat 07:08, 23 October 2016 (UTC)

Probably not. Looking at ru:MediaWiki:Common.js, Editpage.js is only loaded for the current wikitext editor (search for importMW( 'Editpage' )). Matma Rex (talk) 08:35, 23 October 2016 (UTC)

But in wmflabs 2017_wikitext_editor does action=edit (like wikitext editor) https://en.wikipedia.beta.wmflabs.org/w/index.php?title=World&action=edit Sunpriat 06:42, 25 October 2016 (UTC)

Hmm. In this case, I have no idea. I'd expect that the new wikitext editor will not be affected even if the Editpage.js script fails, but I haven't tested it. Matma Rex (talk) 15:18, 25 October 2016 (UTC)

Well we also load VE from ?action=edit, so this wouldn't be a new issue. It looks like most versions append stuff near the edit <textarea> which we hide anyway. ESanders (WMF) (talk) 18:14, 27 October 2016 (UTC)

VE has a special ?veaction=edit and ?action=edit&veswitched=1

In General, I mean, what if I don't use the old editor and his gadgets, I don't need to download action=edit Editpage and its importMW chain every time... how to avoid it? Because for the new editor, we will add the same gadgets but it seems by the other way (2017_wikitext_editor way). Sunpriat 19:16, 27 October 2016 (UTC)

Demo today

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

At CREDIT, according to info available at https://etherpad.wikimedia.org/p/CREDIT . Elitre (WMF) (talk) 14:38, 7 December 2016 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

End of edit?

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

I tried it, and changed in visual editor part of page. Then I save it... and [2]:

• Window title is still "Editing page XXX"
• There are no categories visible
• there are no gadget outputs (OSMap)

After reload is everything OK

Then I tries edit of another page but without savig. When I canceled edit (by esc key, there is nowhere [cancel] button?) I got message on the top: "this is archived version of page.." JAn Dudík (talk) 09:31, 15 December 2016 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

2 little bugs

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

1. editing a specific section doesn't add the section title automatically in the edit summary.
2. after saving and edit done with the new wikitext editor and trying to re-edit the same page (without reloading the page), the system opens the standard editor, not the new wikitext editor. Mannivu · ✉ 10:08, 15 December 2016 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Too complicated

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

When I have as default wikitext editor, I must switch to visualeditor and then switch to 2017 editor. What If I want to have 2017 for less clicking? JAn Dudík (talk) 12:51, 15 December 2016 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Ein interesanter Ansatz aber...

Der Editor sollte ein Ersatz für den VE und nicht für den Texteditor sein. So unbrauchbar da man mit ihm noch nicht mal unterschreiben kann. Mauerquadrant (talk) 16:03, 15 December 2016 (UTC)

Unterschreiben: Bearbeiten --> Einfugen --> Mehr --> Deine Unterschrift. :) (und, https://phabricator.wikimedia.org/T153255 .) Elitre (WMF) (talk) 16:22, 15 December 2016 (UTC)

Ein klick zu vier Klicks das ist keine Verbesserung. Mauerquadrant (talk) 19:53, 15 December 2016 (UTC)

Syntax highlighting

I am deeply disappointed that this new editor does not have syntax highlighting. This was the killer feature I expected. I will keep on copy-pasting into a syntax-highlighting capable editor like gedit or vim. EdouardHue (talk) 19:09, 15 December 2016 (UTC)

Wait for the wishlist implementation :-). IKhitron (talk) 19:22, 15 December 2016 (UTC)

I agree, syntax highlighting would be an awesome feature. Innosflew (talk) 00:34, 16 December 2016 (UTC)

it should be adopted immediately. Motoko C. K. (talk) 08:08, 17 December 2016 (UTC)

regarding complexity, can't you just restrict the highlighting to a certain depth? Most wikitext is not that complex and should be Ok to highlight. really complex stuff is an edge case. syntax highlighting is a must. Guccisamsclub (talk) 00:01, 22 December 2016 (UTC)

Using it now on my own wiki?

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Is there a way to enable this now for every user on my wiki without using the beta features extension? (I have the 1.29.0-alpha version of mediawiki) Innosflew (talk) 00:33, 16 December 2016 (UTC)

I believe if you edit your LocalSettings.php to set $wgVisualEditorEnableWikitext and $wgDefaultUserOptions['visualeditor-newwikitext'] to true, it should be available to all users. Jdforrester (WMF) (talk) 05:17, 16 December 2016 (UTC)

Thank you :) Innosflew (talk) 10:31, 16 December 2016 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Feedback link

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

When I click on my wiki to [beta] and then to [talk] near this WE17 I am on page Talk:2017 wikitext editor. And because most users are not familiar with Flow, they will write feedback here instead of 2017_wikitext_editor/Feedback. Should link from beta be changed? JAn Dudík (talk) 07:36, 16 December 2016 (UTC)

As far as I know a patch has already been written after I reported the issue. Maybe it's just not live yet, @Jdforrester (WMF)? Elitre (WMF) (talk) 07:51, 16 December 2016 (UTC)

Yeah, it's not going to go live until January, I'm afraid. :-( Jdforrester (WMF) (talk) 16:52, 16 December 2016 (UTC)

Ouch! We'll survive. Next time at our meeting I'll make extra sure I explained myself well. Elitre (WMF) (talk) 17:20, 16 December 2016 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Preview

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Using the 2017 Wikitext Editor in namespaces where Visual Editor is disabled (f.e. talk pages) you don't have any kind of previewing changes (since you cannot switch to VE and there is no Preview button). Geraki (talk) 09:53, 16 December 2016 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

hotcat

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

I looked up what the HotCat tool is and it's supposed to be, and if I looked up the right thing then it's for adding categories, right? Why not use the category tool of the visual editor instead:

Innosflew (talk) 09:17, 17 December 2016 (UTC)

OK thanks Motoko C. K. (talk) 11:28, 17 December 2016 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Unique identifier

What is actually the ID for this sub-project in unique spelling?

• WikitextEditor
• wikitexteditor
• wikitextEditor
• WikiTextEditor
• WikiText

or what else? PerfektesChaos (talk) 09:33, 17 December 2016 (UTC)

I don't understand your question. What are you trying to do? Whatamidoing (WMF) (talk) 18:29, 17 December 2016 (UTC)

I am going to to create a documentation page in German, and I want to be able to refer to this “Something”. And would like to be able to mention this “Something” in a long-term precise manner in correct spelling.

Examples:

• Extension:WikiEditor
  • ID=WikiEditor
• en:User:Cacycle/wikEd
  • ID=wikEd

It is hard to believe that 2017 wikitext editor is supposed to be the final ID of the “Something”, even more since it is used in 2016 right now.

What is actually the Phabricator ID for this particular thing? Is it somewhere in the middle of all VisualEditor stuff? That would be rather confusing for people referring to it.

How do you expect users to communicate about this “Something”? — Use the VisualEditor source code editing! — No, I do not like VisualEditor for this task, since I need access to source code which VisualEditor does not handle correctly. — No, I mean you should use that unnamed VisualEditor component which can be used in source code editing that has been made available in 2016 but is called 2017. — You are kidding. Please do not waste my time. EOD. PerfektesChaos (talk) 10:42, 18 December 2016 (UTC)

We've spent a lot of time talking about this problem. The main bits seem to be this:

• Almost nobody knows the names of the existing editors.
• Inexperienced editors are confused by naming them (for example, they'll ask if "WikiEditor" is something they need to download and install on their own computers).
• But experienced editors find it difficult to communicate without them.

After all, if you're reporting a problem, then everybody needs to know which of the many editing systems you're talking about, right? Also, IMO it's almost impossible to write documentation without having some reliable method of identfying which piece of software you're talking about.

However, despite the clear need, there is no "official" name today. There are currently two relatively popular approaches to identifying it:

• The software itself is part of Extension:VisualEditor, so "the wikitext mode of VisualEditor" is an accurate choice, and has the minor virtue of being especially clear to devs. This is the language used in the Beta Features description.
• I have suggested "2017 wikitext editor" as a way of differentiating it from the three other wikitext editors in widespread use on the desktop system. (At least one of them also appears to lack a name.) That means that there are wikitext editors from 2003, 2006, 2010, and 2017. (These dates approximately indicate when they came into general use, not when they were first available for testing.) This is also the name that you want if you are filing a bug in Phab:, because the project is (currently) named VisualEditor-MediaWiki-2017WikitextEditor.

I request that you avoid naming it "New Wikitext Editor". On average, someone has made another wikitext editor every four years. Therefore, I think we can reasonably expect that there will be yet another one in about four years or so. We will all be unhappy if that future one has to be called the "New-New Wikitext Editor" to differentiate it from the "old New Wikitext Editor".  :-) Whatamidoing (WMF) (talk) 03:25, 20 December 2016 (UTC)

Indeed, I do not appreciate software tools named “enhanced thing”, “extended thing”, “improved thing”, “next generation thing”.

However, “2017” is not really a good qualifier for eternal verity, since it will look outdated in 2018, and we are still in 2016 — marketing would prefer a more dense eye-catcher.

Since the something appears to be indissoluble part of VE, perhaps VisualWikitextEditor might be a sustainable brief unique description of that mode and software? Or shorter as WikitextVE? PerfektesChaos (talk) 09:18, 20 December 2016 (UTC)

I am occasionally amused by the idea of naming "$Thing", to indicate that the name is variable. But this would be too confusing.

I wonder if anyone else would like to make suggestions or be involved in the discussion. Whatamidoing (WMF) (talk) 16:48, 20 December 2016 (UTC)

@Whatamidoing (WMF)

HNY.

I just happened to stumble across rEVED/betafeatures-icon-WikitextEditor-ltr.svg. This is one possible ID I mentioned first in the list of possible IDs when opening this thread, but the image name does not contain “VE” and a consistent scheme should be used for such naming. PerfektesChaos (talk) 09:08, 2 January 2017 (UTC)

Given that this is a sub-part of a larger piece of software, and given that almost nobody knows the names of any of these tools, I think it's important that the name, if any, be reasonably descriptive – or "unique", to use the thread's title.  :-)

All of the examples given at the start are easily confused with both WikiEditor (the 2010 version) and with wikitext editors in general, so I think editors will find them frustrating. Imagine asking someone, "Are you using WikiEditor or WikiTextEditor?" I estimate that 99% of experienced editors could not answer that question without first consulting documentation pages. Whatamidoing (WMF) (talk) 20:12, 7 January 2017 (UTC)

The "Unique Wikitext Editor"! Elitre (WMF) (talk) 11:09, 19 January 2017 (UTC)

Errors en la signatura i a l'hora d'enganxar URLs

Correcte en general, enhorabona. El problema és que a ca.wikiquote es fa impossible enganxar URLs de pàgines externes a l'hora de citar la bibliografia. També hi ha problemes per inserir la signatura a ca.wikipedia i que la previsualització està força amagada: has de clicar abans a "desa la pàgina" (per tant 2 clics i menys navegabilitat) i la visualització de la prèvia no és massa amigable i no reflecteix del tot el resultat final. Aviam si ho podeu arreglar. Gràcies! Xavier Dengra (talk) 11:07, 17 December 2016 (UTC)

Thank you for this information.

• Can you please give me a diff of what you want to see at ca.wikiquote?
• I tested the signature at ca.wikipedia. It works for me.[3] Can you show me a diff with a problem? Whatamidoing (WMF) (talk) 18:47, 17 December 2016 (UTC)

I can't show you diffs because the copy-paste of some URLs and the signature literally don't work. I've tried in Firefox (I usually edit in Safari) and I think it's due to the browser (?). Thank you for your quick response and your great job. I'll wait for the next update of the editor. Xavier Dengra (talk) 21:13, 17 December 2016 (UTC)

I want to see if I can get this to work. I need to see a "good example", so I'm testing the right thing.

(You can leave a note on my talk page at ca.wikiquote or any Wikipedia, if you prefer.) Whatamidoing (WMF) (talk) 07:31, 18 December 2016 (UTC)

rollback

Rollback did not work for me. If it is not supported yet, it is a feature that should be part of the 2017 wikitext editor. FocalPoint (talk) 12:24, 17 December 2016 (UTC)

Hi FocalPoint,

What does "did not work" mean? Did nothing happen, or did it take you to the wikitext editor that you had been using previously? Whatamidoing (WMF) (talk) 18:31, 17 December 2016 (UTC)

Hi, before answering, I turned the new editor on again and tried some rollbacks. They all worked. This is weird. Anyway, the answer to your question is that when I tried the one-click roll back, it just did not work. Nothing moved. When I did "undo", it worked fine.

And a question: Where is the signature button? Is it just before me and I cannot see it? Honestly I am looking and I do not see it there! FocalPoint (talk) 22:41, 17 December 2016 (UTC)

I forgot to mention that all this refers to my contributions in el-wiki. FocalPoint (talk) 23:14, 17 December 2016 (UTC)

The signature item is in the Insert menu. (Insert > More > Your signature). Most of our users have English keyboards, so they tend to type the four tildes directly instead of clicking a button.

I've had a few instances in which the new wikitext mode simply didn't open. It looks like perhaps a third of my edits in Firefox have had this problem. What web browser are you using? Whatamidoing (WMF) (talk) 07:27, 18 December 2016 (UTC)

I am using Firefox.

I found the signature, hidden, in the menu you showed. It clearly needs to be in the very front when in discussions. It can remain hidden when editing articles. If all this is to much of a hassle to program, please put it in the front anyway.

I always use the button, but I cannot account for everybody else - maybe you know better, but unless we give a button to the newcomer, how will he/she know? FocalPoint (talk) 09:30, 18 December 2016 (UTC)

It looks like the use of the signature button may depend upon the language (or the language for your computer's keyboard). See the later comments at phab:T153255 for a proposed solution. Whatamidoing (WMF) (talk) 00:23, 20 December 2016 (UTC)

The statistics obviously refer to existing users (who gradually go away). I do care, however, also for new users. How will the new users know about it? Are we trying to improve editing or are we trying to make it worse? I saw the proposal, but my answer is clear: KIS Keep It Simple. Keep it as it was before - how difficult can this be? Keep the experience the same. FocalPoint (talk) 05:51, 20 December 2016 (UTC)

I think you're right: if the button is "buried" in a long menu, then most new editors will not see it.

The goal isn't to keep it the same as the previous desktop editors. The goal is to give editors (approximately) the same experience on talk pages as they have in articles. At the Greek Wikipedia, less than half of edits by new users are using one of the "old" desktop wikitext editors.

But those "old" editors are only option for talk pages. These new editors want the same experience on the talk pages that they have in articles. (But perhaps it should not be a completely identical experience, since the important actions are not identical.) Whatamidoing (WMF) (talk) 20:41, 20 December 2016 (UTC)

No internal link during editing (Wikipedia in French)

In this article, I selected "Équateur", clicked on the icon, selected the right article to link at ("Équateur (pays)"), clicked on "Terminer", and... nothing happened. :/ Could it come from the active gadgets? J. N. Squire (talk) 14:17, 17 December 2016 (UTC)

It worked for me (in Safari 10 and Firefox 50).

How many scripts and gadgets are you running at the moment? Whatamidoing (WMF) (talk) 00:51, 20 December 2016 (UTC)

27 activated gadgets. I don't remember the number of scripts ^^;

My config: Opera 42.0 (Chromium-based), Windows 10

May it works if I deactivate gadgets? J. N. Squire (talk) 14:53, 20 December 2016 (UTC)

Maybe. I wonder if we could find another Opera/Windows user to test it first, though.

Also, it's probably easier to blank your common.js and vector.js (or monobook.js if you're still using the Monobook skin) files at the French Wikipedia than to de-activate and re-activate all of your gadgets.

But, the simplest first step may be to try it on a wiki that you rarely visit. Just go to, I don't know, https://br.wikipedia.org/wiki/Dibar:Penndibaboù#mw-prefsection-betafeatures and opt-in, and then use Special:Random to pick a page for a test edit (no need to save your change). The Breton Wikipedia has no gadgets enabled by default, and you have no scripts installed there. Whatamidoing (WMF) (talk) 19:17, 20 December 2016 (UTC)

I followed your advice and just tested on the Breton Wikipedia with complicated copy-pasted texts (multiple styles and from a taxobox). Everything worked.

So either it's related to the specific infobox, either it's caused by scripts/gadgets, I guess ?

Is there an easy way to check which one causes the issue? J. N. Squire (talk) 20:55, 20 December 2016 (UTC)

Thanks. I'm guessing that it's a script. Do you know how to open your browser console? It might have useful error messages. Whatamidoing (WMF) (talk) 22:52, 20 December 2016 (UTC)

Here are the messages I got on the next article of my list (3 warnings and 1 error) :

• This page is using the deprecated ResourceLoader module "jquery.ui.position".

(anonymous) @ VM115:1

/wiki/Gymnopithys:182

• Gadget "newCollapsible" styles loaded twice. Migrate to type=general. See <https://phabricator.wikimedia.org/T42284>.

(anonymous) @ VM118 Gymnopithys:182

/wiki/Gymnopithys:182

• Gadget "DeluxeHistory" styles loaded twice. Migrate to type=general. See <https://phabricator.wikimedia.org/T42284>.

(anonymous) @ VM118 Gymnopithys:182

(unknown)

• JavaScript parse error: Parse error: Missing ; before statement in file 'Utilisateur:Feldo/vector.js' on line 6 J. N. Squire (talk) 21:02, 26 December 2016 (UTC)

Alright, I've removed some inactive bits of code from my vector.js and linking seem to works, now. I will let you know if I still have troubles with it after longer use of the editor. J. N. Squire (talk) 22:03, 26 December 2016 (UTC)

Thank you. (I have several of these "loaded twice" errors in my volunteer account. I should figure out what's causing them.) Whatamidoing (WMF) (talk) 06:43, 28 December 2016 (UTC)

Bug: Ctrl+V doesn't work (Wikipedia in French)

Another bug that happened in this article. I tried to copy-paste captions of the picture from the Wikipedia in English and Dutch. However, I could only paste it through Right click→Paste as text only. Ctrl+V didn't work at all, although I noticed it did some kind of processing (trying to convert HTML style in wikitext, maybe?). J. N. Squire (talk) 14:21, 17 December 2016 (UTC)

Shouldn't it be Ctrl-Shift-V? IKhitron (talk) 14:26, 17 December 2016 (UTC)

Paste does not work in el-wiki either. Not even with right click. FocalPoint (talk) 23:16, 17 December 2016 (UTC)

If you are trying to paste something that is 'complicated' (e.g., contains illegal formatting), then the paste will fail. Can you please try to paste something again, using plain old text?

The pasting the caption works for me: Greek and French. Feldo, if that's not exactly what you were trying to paste, then please let me know where you copied it. I was using Safari 10 on macOS 10.12.1. Whatamidoing (WMF) (talk) 07:50, 18 December 2016 (UTC)

I am trying to replicate the problem today, but it always worked !

Anyway, fyi, yesterday, in some cases it was working if I would clear any formatting (pasting in the search box and then copying again.

Weird stuff. FocalPoint (talk) 09:32, 18 December 2016 (UTC)

Thank you for the update. My guess is that it disliked the formatting.

But, this would be a very annoying problem. If it happens again, especially if it happens with plain text, then please let me know about it. I want to know as much detail about what you were doing, to see if we can figure out a pattern.

(But, let us hope that it will always work for you now.  :-) Whatamidoing (WMF) (talk) 00:16, 20 December 2016 (UTC)

I have disabled it. Too much hassle, waiting each time to load up the page and also, I do not like bugs. I did my bit helping the developers. I will enable it again whenever it becomes better. Best wishes for improvements to come. FocalPoint (talk) 05:55, 20 December 2016 (UTC)

Thank you for your help. I truly appreciate it. Yes, the devs have a pile of things to work on now!

I'm planning to send around another message (Village Pumps, etc. – same as before) to let people know when the devs want people to have another go at it. I think that will be a couple of months from now, but however you heard about it this time will probably be the place to watch for an update.

And thank you – ευχαριστώ. Whatamidoing (WMF) (talk) 20:23, 20 December 2016 (UTC)

Hello again. As you will see above, I had to turn on the feature against my will, as it was not allowing me to save. So... here we are again: I copied the name of an article and I tried to paste it in the editing of another article. It does not work. FocalPoint (talk) 17:45, 23 December 2016 (UTC)

Did you copy the name of an article from a wikitext page, or from a source that you wanted to cite?

Most people are complaining about copying article titles from Wikipedia pages and getting a mess:

☀
= Sandbox =

Whatamidoing (WMF) (talk) 19:32, 26 December 2016 (UTC)

I copied the name of an article from the top of the article page, not from the article text.

In other cases, when it worked, I got the image you give. In the case I wrote to you about, nothing was coming in. Weird. And one might think that we, people, are unpredictable. Software is getting close to human behaviour ! No 1+1=2 stuff. Rather 1+1 most of the time =2. FocalPoint (talk) 20:05, 26 December 2016 (UTC)

I'm waiting for the day when computers reliability DWIM (Do What I Mean – not what I told it to do).

I've started the description of this problem at phab:T154162. If you could remind me of your web browser and OS, that would be helpful. Whatamidoing (WMF) (talk) 20:47, 26 December 2016 (UTC)

Alright, I've removed some inactive code from my vector.js and Javascript now works!

Howevers, when I pasted in an article in French some code from its English counterpart (more precisely, from the taxobox) with bold and italics, I got weird symbols before and after:

☀'''''Gymnopithys'''''☂

Config: Win 10, Opera 42.0 J. N. Squire (talk) 21:33, 26 December 2016 (UTC)

That one is phab:T153247. Usually, I'm seeing either the black sun or the umbrella. Occasionally, I get them both, but usually just one.

(They're used as temporary characters that are used to 'store' the character formatting on, when the software is magically shuffling bits around in the background. When you can see them, it is always a bug.) Whatamidoing (WMF) (talk) 06:48, 28 December 2016 (UTC)

Signature button less available

I wish that on talk pages the signature button would be easier accessible (like in the old editor) instead of under Insert > More > Your signature. Ainali (talk) 11:29, 19 December 2016 (UTC)

Thanks, Jan; it's always good to hear from you.

Ideas are being collected at phab:T153255. On a related point, I believe that enwiki was talking about an auto-signing script last year. I wonder whether that worked out. Whatamidoing (WMF) (talk) 00:37, 20 December 2016 (UTC)

*cough*Flow*cough* Josve05a (talk) 03:32, 20 December 2016 (UTC)

Routemap

The new editor has broken Module:Routemap's convertbs function, which converts RDTs to use the Routemap template. Instead of returning diagram code, it returns strip markers (probably from the <nowiki> tags which are required to use the function). Jc86035 (talk) 08:12, 21 December 2016 (UTC)

I've looked through some of your contributions, and I'm not finding anything that has problems. Can you give me a diff that shows the problem? Or a list of exactly what to do to reproduce this for myself in my sandbox? Whatamidoing (WMF) (talk) 02:12, 22 December 2016 (UTC)

The way it's supposed to work (@Sameboat?) is that you receive the diagram code in preview mode after you wrap the diagram code:

{{#invoke:Routemap|convertbs|<nowiki>

[original diagram]

</nowiki>}}

In preview in the 2010 editor, both the new version and the old version are displayed, but in the 2017 editor the nowiki tags aren't handled properly for some reason.

To reproduce:

1. Edit an RDT using the BS-map or BS-table templates, like {{Piccadilly Line RDT}}.
2. Wrap the diagram code (not including the noincluded documentation) in the wrapper.
3. When previewing, the two blocks of code will only have strip markers in them.

Alternatively, if there's a Lua module for parsing nowikied template code the function could be modified to just output the Routemap code, but it's probably not worth the effort to do that and I'm not sure if it's possible. Jc86035 (talk) 06:18, 22 December 2016 (UTC)

I've written this up at phab:T153981 and added screenshots. Please take a look and let me know if I've missed anything. Whatamidoing (WMF) (talk) 21:32, 22 December 2016 (UTC)

The 2010 editor screenshot has an extra "{{Routemap" in the first row, although that's probably not much of a problem. Thanks for reporting the bug. Jc86035 (talk) 03:09, 23 December 2016 (UTC)

List of templates used in article

Tracked in Phabricator
Task T149009

Previously, there was a list of all templates used in the article below the Save button. This is now missing, or else it has been moved somewhere where I didn't find it. This was a nice feature that I miss. Hannibal (talk) 12:39, 21 December 2016 (UTC)

I would love to be able to see this feature elsewhere: perhaps linked in the little information tab at the top? Sadads (talk) 23:14, 21 December 2016 (UTC)

Would love the {{ shortcut to the insert template menu

I would love to have the insert template menu more readily available from the editing interface. The shortcut to just add "{{" and it start suggesting templates in the visual editor is super useful, and keeps me from making mistakes in filling out the template the first time. Sadads (talk) 23:17, 21 December 2016 (UTC)

I've added this as phab:T153956, but I'm not sure that it's going to work equally well in all circumstances. It sounds great for {{Infobox example |name=Example |um=I forget...; it sounds less than great for quick, common things such as {{Fact }}. Whatamidoing (WMF) (talk) 17:32, 22 December 2016 (UTC)

Why not? IKhitron (talk) 19:50, 22 December 2016 (UTC)

Perhaps it's not the case for everyone, but I can type {{fact}} faster than it can search for the template.  ;-) Whatamidoing (WMF) (talk) 21:16, 22 December 2016 (UTC)

I see. IKhitron (talk) 22:05, 22 December 2016 (UTC)

codemirror

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

would be nice if you make [codemirror.net CodeMirror] the backend. somebody has already made a plugin for the regular editor, though all it does is highlighting. code-mirror is extremely extensible very well documented: adding anything from brace-matching to auto-complete is just a few lines of code. that way you are not locked into a defined feature set. Guccisamsclub (talk) 00:11, 22 December 2016 (UTC)

It's incompatible with our language support requirements, unfortunately. Jdforrester (WMF) (talk) 19:24, 5 January 2017 (UTC)

I'm not clear what you mean. foreign language support? browser support for spell-checking? Guccisamsclub (talk) 20:07, 5 January 2017 (UTC)

Input Method Editors (required for many of the languages we support, like Urdu/Hindi/Japanese/Arabic) will die (pretty epically) if you make DOM changes anywhere near the content entry point. CodeMirror adds/removes spans as you type, which we've learnt from very tough experience is fraught with problems. Jdforrester (WMF) (talk) 21:31, 5 January 2017 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Ctrl + P creates preview, but loses contributions

When I press the Ctrl+ P shortcut, to preview, my contributions disappear and the page, loads temporarily without a "back button" with what I am assuming is a preview of my changes, but when I go back to work on the page, the editor interface has lost my changes. Sadads (talk) 01:06, 22 December 2016 (UTC)

I've filed this at phab:T153937 and pinged you in it. Whatamidoing (WMF) (talk) 05:51, 22 December 2016 (UTC)

Sudden transition

I sometimes experienced unintended transition from wikitext editor mode to visual editor mode, although I didn't use the visual editor mode before. Motoko C. K. (talk) 06:05, 22 December 2016 (UTC)

How strange. Thank you for this note. Can you please tell me your web browser and operating system? That information may help us figure out what's going on. Whatamidoing (WMF) (talk) 17:33, 22 December 2016 (UTC)

Chrome. MacOS Sierra. :) Motoko C. K. (talk) 17:41, 22 December 2016 (UTC)

I've started this report at phab:T154158.

Is this when you first open a page to edit, or in the middle of editing the page? Can you tell me what your settings are at https://ko.wikipedia.org/wiki/특수:환경설정#mw-prefsection-editing in the drop-down menu for "Editing mode"? Whatamidoing (WMF) (talk) 19:09, 26 December 2016 (UTC)

It happened when I opened a page first. The editing mode is "마지막으로 사용한 편집기 기억하기(remember the editor you last used)". Motoko C. K. (talk) 19:52, 26 December 2016 (UTC)

That's odd. I see no sign of you switching, either, although that's not 100% proof. (If you switch, but then don't save, it still remembers that you switched.)

As a work-around, you might want to change the setting to "Always give me the source editor". That should reduce the unexpected use of VisualEditor's original visual mode. Whatamidoing (WMF) (talk) 20:01, 26 December 2016 (UTC)

Yeah, I've already done it. Motoko C. K. (talk) 20:04, 26 December 2016 (UTC)

Where is the editing mode in English Wikipedia. I can't find the mode at the place where it is in Korean Wikipedia. Motoko C. K. (talk) 20:12, 26 December 2016 (UTC)

You switch from one to the other by clicking on the icon in the upper right corner. It's the same button in all languages.

Look for [[ ]] to go from the visual mode to the wikitext mode. It's next to the Save button.

In the wikitext editors, look for a short pencil icon in the upper right corner of the editing toolbar.

See Help:VisualEditor/User guide#Switching between the visual and wikitext editors for screenshots. Whatamidoing (WMF) (talk) 21:07, 26 December 2016 (UTC)

Unfortunately, that's what I meant. I talked about my preference. Motoko C. K. (talk) 02:33, 27 December 2016 (UTC)

In case anyone needs help finding the preferences:

1. Go to Special:Preferences. In the Editing tab, look in the biggest section ("Editor").
2. At the bottom of the list, make sure that "⧼visualeditor-preference-betatempdisable⧽" is turned OFF (no check mark). If it's not turned off, then you will not be able see the last thing in the section.
3. The last item in that section is "Editing mode:". The default is "Remember my last editor". I normally choose "Show me both editor tabs". However, if you never use the visual mode (which is awesome for tables!), then you might think about "Always give me the source editor".

Tip: if you edit this Flow post by clicking the ••• button in the upper right corner and choosing "Edit", then you'll see the codes that I used for this message. These are automatic translation codes. So if you copied them and pasted them into a page on the Korean Wikipedia, it would automatically translate those codes into Korean (or whatever your personal language setting is, on the first page of your preferences there). These codes may be handy for explaining how to do this to other people. Whatamidoing (WMF) (talk) 21:07, 27 December 2016 (UTC)

Wikitekst editörü

bu ne işe yarıyo ben bi bakıyım Nokiaustasi (talk) 11:15, 22 December 2016 (UTC)

This wikitext mode lets you edit the wikitext for Wikipedia articles and other pages with the same toolbar as the visual editor. Whatamidoing (WMF) (talk) 17:22, 22 December 2016 (UTC)

autocomplete outline

autocomplete for outline and bullet points. every decent markup editor has this feature. Guccisamsclub (talk) 18:10, 22 December 2016 (UTC)

What's the name of your favorite markup editor? Whatamidoing (WMF) (talk) 22:32, 22 December 2016 (UTC)

I don't really have one. I've used Stackedit, Typora etc. for markdown, and Dokuwiki for keeping track of everything. Even Dokuwiki, especially with the codemirror plugin, is much nicer than the mediawiki's textbox. It too has the auto-bullet feature, bracket matching, and keyboard shortcuts for a bunch of formatting. Text editors often have auto bullets for various markups, but you have to install plugins, and they always have brace matching out of the box. I guess the gold-standard of markup editors would be Emacs org-mode, though haven't used it beyond experimentation. I really hope the 2017 editor will be a modern text editor, instead of just a bigger textbox. Guccisamsclub (talk) 23:03, 22 December 2016 (UTC)

VisualEditor has all of these features – but some of them, such as automatically extending your bulleted list, are only available in the visual mode. Whatamidoing (WMF) (talk) 20:53, 26 December 2016 (UTC)

i like the the visual editor. but it's a bit slow—slower than code-mirror would be—and and has annoying popups. it certainly beats editing spaghetti markup in a circa 2000 text-box. i'm currently playing around with org-mode and the way it highlights markup is basically correct (although typora's way is probably easiest, though it can be finicky due to incomlete features). take a look at typora for inspiration, though i get that it would be an issue on older pc's without some major optimization.

one idea: why not make good desktop editor/viewer at some point? it could make for a decent editing experience for people with old pc's, crap internet, eyesight problems etc. it would also offer nicer features without the performance penalties. Guccisamsclub (talk) 01:20, 4 January 2017 (UTC)

I believe that an offline editing system is being considered, e.g., at phab:T106898. However, I don't expect it to happen soon. Whatamidoing (WMF) (talk) 17:52, 20 February 2017 (UTC)

dual pane editor (horizontal)

it would be nice to have two panes when editing a page. if you use list-defined references, you have to scroll down to the bottom every time you want add or refactor references. with a dual pane mode, you can have the bottom of an article always available. (would also be nice to let people choose where and how their references are inserted-instead of dumping them all inline whenever you use the toolbar buttons-but that's another story) Guccisamsclub (talk) 00:14, 23 December 2016 (UTC)

obviously one pane will be the default, but the user can open a second pane if they need it. Guccisamsclub (talk) 00:15, 23 December 2016 (UTC)

Hi Guccisamsclub,

Are you thinking about the sort of "split-window" view that is common in spreadsheets? Whatamidoing (WMF) (talk) 20:05, 23 December 2016 (UTC)

yeah exactly. btw, virtually all of the features anyone could dream of in an online text editor, are already implemented by CodeMirror, including multiple buffers. Guccisamsclub (talk) 20:24, 23 December 2016 (UTC)

This sounds like phab:T4745 from 2005.  :-) I'll ask the product manager about it, but I'm guessing that if this idea has already sat in the backlog for a decade, that it's probably not going to be a high priority. (Also, list-defined references are unpopular, so the case for investing resources in it is going to be weak.) Whatamidoing (WMF) (talk) 17:29, 27 December 2016 (UTC)

Thanks. They are unpopular because all the tooling (citoid and visual editor) dump the references inline. This is is not necessarily a "editor interface issue", but rather an issue with the auxiliary tools. If cytoid and visual editor used list-def refs, inline refs would be unpopular. Inline refs don't make any sense to me because they make the markup essentially unreadable, and you can never easily tell where a reference is defined and where it's used. For this reason, I only use the visual editor on wikipedia. The only time when I use the source editor for serious edits is when I'm reworking an entire article and converting everything to LDF, which takes a long time. Ideally you'd have the tools dump references at the end and have a dialog that shows all the references regardless of which section you are editing. Guccisamsclub (talk) 20:13, 27 December 2016 (UTC)

List-defined references were implemented in September 2009. If memory serves, VisualEditor (visual mode only) was first available on the English Wikipedia for early alpha testing in December 2012, and released generally there in July 2013. I'd say that the unpopularity of LDR at enwiki substantially pre-dates VisualEditor.

There's a script at w:en:User:PleaseStand/segregate-refs.js for converting the formatting from the common style to LDR. After you name each ref, it's really just a matter of clicking a button and waiting for the script to run. Speaking strictly in my volunteer capacity, I recommend that you scrupulously, even ostentatiously, follow w:en:WP:CITEVAR's recommendation to have a discussion on the talk page first before using the script, because these kinds of changes can annoy other editors. WhatamIdoing (talk) 06:59, 28 December 2016 (UTC)

highlight enclosing brackets

articles on wikipedia have templates embedded in templates and followed by templates. it gets to a point where it becomes impossible to tell where one template begins and another template ends. I think simply highlighting enclosing brackets based on cursor position-like text editors and IDE's do-will help a lot with that. Guccisamsclub (talk) 00:24, 23 December 2016 (UTC)

There's been some work done on this. It's insufficiently performant for live-editing/real-time use right now. I'm sure that the team will take a look at this goal again in the future. Whatamidoing (WMF) (talk) 19:12, 26 December 2016 (UTC)

Thanks. What do you mean by "live editing"? Rolling out the feature for beta testing?

Has anyone considered using an external library like "codemirror". It already does just about everything out the box, and well. You can make it do more. It's a mature and supports tons of languages. I've tried the mediawiki codemirror plugin and was impressed that highlighting for moderately complex pages was instant. I am sure it will have no problems highlighting enclosing braces. Why reinvent the wheel? Has anyone tested the plugin to get a feel for the performance on long wikipedia articles? It seems pretty fast, and I am sure you could modify it to increase performance even more. Guccisamsclub (talk) 20:27, 26 December 2016 (UTC)

I see that you've mentioned codemirror repeatedly. VisualEditor has used several external libraries; I don't know which were used specifically for syntax highlighting. Codemirror can't be used until there's been a security review (phab:T108687).

In general, there seem to be two ways to go about syntax highlighting: one that paints the page and then goes away as you start editing those areas, and the other tries to keep up with your changes while you're typing ("live editing"). The first is generally feasible, perhaps with a short delay on slower computers. The second – in all implementations that have been used on the Wikipedias so far, e.g., in WikEd – is okay on faster computers and painful, or even impossible, on slower computers, especially on longer articles.

There is a lot of discussion about how to do wikitext syntax highlighting in a non-painful way; phab:T101246 is probably the most central task at the moment. Whatamidoing (WMF) (talk) 20:48, 26 December 2016 (UTC)

HTML source

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

I sometimes see HTML source, not wiki text source in this mode. Motoko C. K. (talk) 06:31, 23 December 2016 (UTC)

Could you give an example, please? IKhitron (talk) 10:37, 23 December 2016 (UTC)

I will take a screen shot. Please wait. Motoko C. K. (talk) 10:49, 23 December 2016 (UTC)

see this screenshot.

https://drive.google.com/file/d/0ByalAkdQNqP5QTQ0c24tejFlWXM/view?usp=sharing Motoko C. K. (talk) 10:57, 23 December 2016 (UTC)

Thank you, but could you explain how did you get there? Some instructions to reconstruct it? IKhitron (talk) 14:30, 23 December 2016 (UTC)

I think it happens randomly in any pages regardless their namespaces. I experienced this problem when I visited a page for the first time, and I could reconstruct it by refreshing the page. Motoko C. K. (talk) 15:12, 23 December 2016 (UTC)

Motoko, that looks horrible. Thank you very much for the screenshot. I'm sorry that you've been dealing with this. Could you please give me the URL to the page that it happened on, and also tell me your web browser and computer OS?

I started the report at phab:T154155, but I suspect that the devs will be asking for more information. Whatamidoing (WMF) (talk) 18:47, 26 December 2016 (UTC)

The url is here: https://ko.wikipedia.org/wiki/틀:브랜드_정보. The browser is Chrome, and OS is MacOS Sierra. Motoko C. K. (talk) 19:44, 26 December 2016 (UTC)

Do you ever get that mess outside of the Template: namespace? Whatamidoing (WMF) (talk) 20:08, 26 December 2016 (UTC)

Yes I do. :( Motoko C. K. (talk) 20:14, 26 December 2016 (UTC)

We think this is now fixed and will be released in two weeks' time. Sorry for the disruption. Jdforrester (WMF) (talk) 19:22, 5 January 2017 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Preview references errors

Tracked in Phabricator
Task T160957

When using the preview, it is not possible to know if the reference error has been fixed, because it is not shown as in the classic view (with red colour). I think it would be better to see the errors in red, and as big as possible.

And I don't really know if happens with templates erros. Miangara (talk) 10:58, 23 December 2016 (UTC)

Are you thinking of this edit, in which the reference had used a non-existent citation template? Not marking a red-link page in red is a known problem. phab:T153535 (most specific) and phab:T39902 (biggest structural issue) are probably the most relevant pages. Whatamidoing (WMF) (talk) 18:43, 23 December 2016 (UTC)

In addition to what you said, I am thinking about:

1. this edit, concerning references errors

2. This other edit about some parameters that are not recognised or provoke an error in templates.

If you look at the previus version, you'll find at the bottom of the page (Referencias) some messages similar to what they name parse (sorry, but my English is not so technical).

Thanks for answering and I do encourage you tu solve it. Miangara (talk) 19:16, 23 December 2016 (UTC)

A lo mejor en castellano me expreso mejor: en rojo además de lo que reporta los enlaces que me aportas, añado que debería aparecer en la Previsualización:

- los errores en las referencias (varios: no se ha definido el contenido, o falta el </ref>, o las referencias definidas con un nombre determinado, ref name=lalala, no tienen el mismo contenido, etc)

- los errores en las plantillas, desde el que me señalas hasta los que yo te pongo de ejemplo en el mensaje anterior. Pero he visto que sí que se observan dichos errores recientemente en la Preview (no he vuelto a usar el editor de código 2017 hasta hoy, desde hace unas semanas).

Una vez más, gracias Miangara (talk) 19:22, 23 December 2016 (UTC)

This reply is about the Argentinian article. It said {{cita web|url=http://www.lanacion.com.ar/1386165-un-libro-repasa-la-vida-del-polemico-obispo-podesta|obra=La Nación|título=Un libro repasa la vida del polémico obispo Podestá|nombre=Elisabetta |apellido=Piqué |2 de julio de 2011}} (but it should say |fecha=2 de julio de 2011 at the end).

In Preview, I see this today:

Piqué, Elisabetta. «Un libro repasa la vida del polémico obispo Podestá». La Nación. Texto «2 de julio de 2011» ignorado (ayuda)

Is this correct now? Or is there another problem with the Argentinian article? Whatamidoing (WMF) (talk) 18:55, 2 January 2017 (UTC)

Yes, that is correct. Now it helps to see that there is something wrong with that Miangara (talk) 23:33, 2 January 2017 (UTC)

Copiar y pegar texto

Al copiar y pegar un texto no respeta los espacios entre párrafos. Solo pone el punto y aparte pero no deja una línea de espacio. Saludos

Copying and pasting a text does not respect the spaces between paragraphs. It only sets the point apart but does not leave a line of space. regards Ortisa (talk) 12:01, 23 December 2016 (UTC)

When I copy things, the result depends upon the source. If I copy from the wikitext page, then I get blank lines between paragraphs. If I copy from some websites, I get the paragraphs like this:

¡Aserrín! ¡Aserrán!
Los maderos de San Juan, 
piden queso, piden pan,
los de Roque alfandoque,
los de Rique alfeñique...

– but not "¡Aserrín! ¡Aserrán! Los maderos de San Juan, piden queso, piden pan, los de Roque alfandoque, los de Rique alfeñique..."

What are you seeing? Whatamidoing (WMF) (talk) 19:28, 26 December 2016 (UTC)

[Unrelated?] Serious side effect on normal source code editing caused by Firefox bug

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Hello, I have a serious problem on normal editing. I get a message that I cannot save due to loss of session. Normally this is by-passed if one insists. This does not work. Even if I follow the instructions, log off - log on, it still does now allow me to save. I could only save by turning on the 2017 editor again.

This is not a minor bug. This is a serious nuisance. Please act ! FocalPoint (talk) 17:42, 23 December 2016 (UTC)

phab:T151770 IKhitron (talk) 17:44, 23 December 2016 (UTC)

Thank you. As far as I can see this is a very serious mess. I will inform the other users in el-wiki of this issue, so that they are aware of this side effect of trying the 2017 editor. FocalPoint (talk) 18:02, 23 December 2016 (UTC)

Why do you think it has something with the new editor? IKhitron (talk) 18:03, 23 December 2016 (UTC)

Cause and effect - I did not have this problem before trying the new editor. Maybe I am wrong but it is the first thing that came to my mind. I never again had the problem of not being allowed to save more than once or twice. Now it is IMPOSSIBLE ! This is a first. FocalPoint (talk) 18:10, 23 December 2016 (UTC)

I'm sure you are wrong. IKhitron (talk) 18:10, 23 December 2016 (UTC)

I will note your disagreement, in the same location where I wrote my cautionary note, in el - village pump. FocalPoint (talk) 18:13, 23 December 2016 (UTC)

Thanks. Tell me when you'll know for sure who's right. IKhitron (talk) 18:14, 23 December 2016 (UTC)

Hey, I do not care who is right. I accept your word. I am a wikiholic editor. I only care that this problem is fixed by Wikimedia, to allow me to edit in the way I prefer. Nothing else! FocalPoint (talk) 18:21, 23 December 2016 (UTC)

(-; If so, tell me when you'll know for sure what's right. IKhitron (talk) 18:22, 23 December 2016 (UTC)

So far this looks like a Firefox bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1264192 https://bugzilla.mozilla.org/show_bug.cgi?id=1319403 May I ask you to try an alternative browser like Chrome or Chromium and see if the problem repeats to confirm it is a Firefox 50.x-only problem? JCrespo (WMF) (talk) 09:19, 25 December 2016 (UTC)

For the moment it seems to ba a FF problem (FF 50.1.0). Chrome seems to be OK, I am using it since I wrote about the problem here. FocalPoint (talk) 09:27, 25 December 2016 (UTC)

We have a conclusion from el-wiki. An editor identified the problem, that FF automatically accepts up to 150 cookies. Apparently the new editor helped to go over 150, creating the problems I saw. I have followed the instructions of our colleague in el-wiki and set the limit to 200. Now I am using FF without any problem. FocalPoint (talk) 19:25, 5 January 2017 (UTC)

Understood, will close this thread but we'll keep working on Phabricator to make sure it doesn't happen to others, who might not know how to fix it. Jdforrester (WMF) (talk) 19:30, 5 January 2017 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Somewhat like early ve in translation pages (based on Special:Translate)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

e.g. Category:MediaWiki configuration settings/de , By clicking Edit source I can also try this new editor ([4]), but shouldn't it navigates to Special:Translate ([5])? Liuxinyu970226 (talk) 07:52, 24 December 2016 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Diacritic sensitivity in searching

See phab:T154195 for discussion.

It would be great if diacritic-sensitive search were turned off (at least by default). Grabado (talk) 16:14, 24 December 2016 (UTC)

It should be returning the same search results that you get in Special:Search at the top of the page. Is that how it is working for you? Whatamidoing (WMF) (talk) 19:34, 26 December 2016 (UTC)

They probably mean the search text within the wikitext editor. That is already possible using regex in the editor, but complicated for the average person. Supporting such tools is also complicated due to the nature of languages because someone might be annoyed if they search for "Formatação" and get "Formatacao", in case they are attempting to replace the exact misspelled one.

It is something that the Search team in WMF definitely struggles a lot with because it is not a solved problem, and any solution would likely be Latin centric.

This article explains it a bit more (warning very technical):

http://alistapart.com/article/accent-folding-for-auto-complete 197.218.81.123 (talk) 20:25, 26 December 2016 (UTC)

That makes sense. User:Grabado, is that what you want? The "Command-F" kind of searching within the text, rather than the search results for making links and inserting media files? Whatamidoing (WMF) (talk) 01:36, 27 December 2016 (UTC)

Yes, User:Whatamidoing (WMF). Sorry if my first message wasn't clear enough (and thank you 197.218.81.123)

When using Command-F for searching, if I search "ole", "olé" should also be highlighted. This is the expected behaviour because is what web browsers do. Grabado (talk) 19:25, 27 December 2016 (UTC)

Thanks. I've described this at phab:T154195. Please feel free to correct or add to the description there. Whatamidoing (WMF) (talk) 19:48, 27 December 2016 (UTC)

Не всегда работает вставка текста из буфера обмена

Когда я выделяю текст статьи Википедии, помещаю его в буфер обмена и потом пытаюсь вставить в поле для редактирования текста, то копирование не происходит. Если же перед вставкой текста из буфера обмена этот текст вставить в блокнот (notepad.exe), там выделить и вставить в буфер обмена и уже потом вставить в поле для редактирования текста, то копирование успешно происходит. Прошу сделать так, чтобы при копировании не требовалось помещать копируемый текст куда-либо ещё и повторно помещать его в буфер обмена. Раммон (talk) 06:43, 28 December 2016 (UTC)

Вопрос, Раммон: если сразу вставлять, без посредников, но нажимать не Ctrl-V, а Ctrl-Shift-V, оно работает? IKhitron (talk) 06:47, 28 December 2016 (UTC)

После того, как я отключил в настройках "Новый режим вики-текста", сохранил настройки, и заново включил в настройках "Новый режим вики-текста" и сохранил настройки, то вставка текста из буфера обмена стала нормально работать как по нажатию Ctrl+V, так и по нажатию Ctrl+Shift+V. Раммон (talk) 07:15, 28 December 2016 (UTC)

Я имел в виду, работает ли в новом режиме, если нажимать и на Shift, Раммон? IKhitron (talk) 09:18, 28 December 2016 (UTC)

Да. Раммон (talk) 05:30, 29 December 2016 (UTC)

Спасибо.

Well, Whatamidoing (WMF), make the long story short, it looks like another sunlike problem. Copying a part of wikipedia read view text and pasting to NWE edit frame does not work. Plain text pasting works well. IKhitron (talk) 12:15, 29 December 2016 (UTC)

Thank you for this information.

It sounds like this is not phab:T153247, with ☀ = Article title = ☂.

Instead, when User:Раммон tries to paste the text (Control+v), nothing at all happens. No text is added to the page. Am I correct?

If I am correct, then this may be phab:T154162. We need more information about that problem. Whatamidoing (WMF) (talk) 21:00, 29 December 2016 (UTC)

Yes you are. Do you want me to ask him something else? IKhitron (talk) 23:49, 29 December 2016 (UTC)

I'd like to have web browser and computer OS information.

Also, if there is a particular line of text or a specific source that reliably fails, then I'd like to have a link to that page and exact directions for copying it, exactly like he does it. For example, if he always triple-clicks to select the line that he's copying, then I want to know that. Whatamidoing (WMF) (talk) 19:56, 30 December 2016 (UTC)

Спасибо за информацию, Раммон. Какой у Вас браузер и какая операционная система?

Кроме того, есть ли возможность получить четкие инструкции как повторить это явление - конкретная статья, конкретная строка и Ваши действия, например "Я трижды нажал на мышку"? IKhitron (talk) 19:58, 30 December 2016 (UTC)

If this is T154162, then that should be fixed on this wiki now (and on Wikipedias later today). Would be great to get confirmation one way or the other (so we can try another approach to fixing it). Jdforrester (WMF) (talk) 19:16, 5 January 2017 (UTC)

Раммон, мы ждем Вашего ответа, и кроме того, код изменился сегодня вечером, и по-видимому исправил этот момент. Проверьте, пожалуйста, работает ли оно сейчас. IKhitron (talk) 21:56, 5 January 2017 (UTC)

Теперь у меня вообще редактирование не работает - пишет: "К сожалению, сервер не смог сохранить ваши изменения из-за потери идентификатора сессии. Пожалуйста, нажмите кнопку «Записать страницу» ещё раз. Если эта ошибка повторится, попробуйте завершить сеанс и заново представиться системе". Эта ошибка имеет место как в новом вики-редакторе, так и в старом. Раммон (talk) 10:57, 10 January 2017 (UTC)

Я делал следующее: на странице истории https://ru.wikipedia.org/w/index.php?title=%D0%94%D0%B8%D1%81%D0%BF%D0%B5%D1%80%D1%81%D0%B8%D1%8F_%D1%81%D0%BB%D1%83%D1%87%D0%B0%D0%B9%D0%BD%D0%BE%D0%B9_%D0%B2%D0%B5%D0%BB%D0%B8%D1%87%D0%B8%D0%BD%D1%8B&curid=1913&action=history нажимал отмену последней правки участника Aborisov, затем нажимал кнопку викификатора текста, затем нажимал кнопку "Просмотр изменений" и затем - кнопку "Записать страницу". Раммон (talk) 10:58, 10 January 2017 (UTC)

Тот же вопрос: какая операционная система и какой браузер (хотя, после Ваших последних слов, я начинаю подозревать что это последняя версия Firefox), Раммон. IKhitron (talk) 12:06, 10 January 2017 (UTC)

MS Win7 64x Профессиональная SP1, Firefox 50.1.0 Раммон (talk) 07:19, 11 January 2017 (UTC)

Спасибо, Раммон. Я так и думал. В первую очередь разберемся с самой свежей проблемой. Смотрите m:Tech/News/2017/02/ru, раздел "Проблемы". Помогло? IKhitron (talk) 11:48, 11 January 2017 (UTC)

На странице about:config у меня нет настройки network.cookie.maxPerHost. Раммон (talk) 11:00, 12 January 2017 (UTC)

Тогда ее можно создать, Раммон. Дататип int. IKhitron (talk) 15:38, 12 January 2017 (UTC)

Помогло, спасибо. Раммон (talk) 06:48, 13 January 2017 (UTC)

Прекрасно.

Whatamidoing (WMF), about your question: It's Windows 7 Professional SP1, MF 50.1.0. IKhitron (talk) 14:17, 13 January 2017 (UTC)

no signature button

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

When I use the new wikitext editor for discussion, it lacks of signature button Xavier Combelle (talk) 18:05, 28 December 2016 (UTC)

See this topic, it's there, but the wise, experienced editors with probably millions of articles written, have decided, that signing isn't that useful. And it's another step on pushing this useless FLOW rubbish down our throats, where signing isn't wanted at all.

Grüße vom Sänger ♫^(Reden) 19:17, 28 December 2016 (UTC)

Thanks, it is enough for me now Xavier Combelle (talk) 19:29, 28 December 2016 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Breaks Twinkle rollback on en.wikipedia

Tried to AGF rollback but dialog didn't work. --Kakurady (talk) 19:06, 29 December 2016 (UTC)

Yes, this is one of many gadgets that will need to be adapted at some point. —TheDJ (Not WMF) (talk • contribs) 09:59, 2 January 2017 (UTC)

I don't have rollback installed any longer (it was a bit slow to load, so I kept clicking on buttons just as it finally finished loading, and consequently just as all the buttons jumped to a new place). Can you tell me what happened? (I hope that it quietly did nothing rather than undoing everything in sight.) Whatamidoing (WMF) (talk) 19:17, 2 January 2017 (UTC)

I think the revert went through, and then it's supposed to pop open a dialog to leave a welcome message on the user's page, which was the part that didn't happen. --Kakurady (talk) 19:58, 2 January 2017 (UTC)

Copy and paste of Header for linking, brings H1 heading level with it

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Since the MOS for most Wikis don't allow for H1 header formatting (since that is also used for the title of the article), it makes no sense for preserving the formatting when copy and pasting into the Wikitext editor. I would highly recommend removing that extra carryover. Sadads (talk) 18:23, 30 December 2016 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Editing redirect pages

Tracked in Phabricator
Task T156042

I found that it is currently impossible to edit a redirect page using this tool. When I click the edit button it enters edit mode, but on the destination of the redirect rather than the redirect page itself. The only other malfunction I have found is that sometimes when I click save edit, the click doesn't register and I have to click it a second time. I have otherwise found it smooth and aesthetically pleasing. Ypna (talk) 03:51, 31 December 2016 (UTC)

Same here, only I wanted to correct a double redirect, and instead it throw me to the middle redirect page (the one with the correct redirect, the one the wrong redirect page referred to). Máté (talk) 13:31, 1 January 2017 (UTC)