VisualEditor/Feedback/Archive/2013/01

Wikidata

Upcoming Wikidata may affect VisualEditor. Have you taken care of it? Nizil Shah (talk) 20:02, 8 January 2013 (UTC)

Wikidata pretty much is entirely graphical in modifying data entries. Jasper Deng (talk) 20:13, 8 January 2013 (UTC)

We've discussed with the Wikidata team at a very high level what we may want to do in this area in terms of integration, but we haven't undertaken any coding yet. I imagine that there will be an "inspector" to insert and edit Wikidata query/data item references, but this is for (much) longer down the track. Jdforrester (WMF) (talk) 01:18, 11 January 2013 (UTC)

OK.. thanks.. Nizil Shah (talk) 09:39, 24 April 2013 (UTC)

Intention NOT to allow editing of only a single section?!?

I'm getting the distinct impression, per this - http://www.mediawiki.org/wiki/VisualEditor/Feedback/Archive/2012%20exported#c-Deryck_Chan-2012-07-25T23%3A02%3A00.000Z-3_comments - that the developers have decided that editors don't need to edit single sections of a page - that VE needs ONLY to be able to edit entire pages. If that's true, I want to make two points:

• This is NOT just a technical decision - it's a decision that impacts how editors work, and as such, it should be formally proposed to the community. It may well be that the advantages of section editing (see below) are outweighed by the technical difficulties of getting VE to handle section edits, or other considerations, but that should be the decision of the community, not of the developers.

• There ARE advantages to editing single sections. As has been pointed out (and I've tested this; it's true), Mediawiki software is now smart enough to handle two editors simultaneously editing whole pages, as long as they don't edit the same section: there is no edit conflict when the second editor goes to save his/her edit. (It's unfortunate that http://en.wikipedia.org/wiki/Help:Edit_conflict#Prevention hasn't been updated, but that's another matter). Still, there are advantages to single-section editing, including:
  • It's faster to load, and faster to save. On mobile devices and other situations with limited resources (bandwidth or device memory), that can be critical.
  • For articles getting lots of edits (a current event, for example), it's still a better way to edit, since it encourages editors to stay within a single section. (By contrast, an editor who edits several sections and then tries to save the changes is almost guaranteed to have an edit conflict.)
  • It's a better way to resolve an edit conflict, when this happens. An editor can copy his/her proposed text for a section, go into that section again (new editing session), paste the proposed text on top of what is shown, then click "Show changes" to see what the other editor(s) have done. Such changes can then be incorporated into the proposed text, and another attempt made to change the section. By contrast, "Show changes" for an entire article could result in the display of a lot of changes outside of the section of interest, causing a much slower resolution of the edit conflict.
  • It puts the section heading into the edit summary, which makes it easier for other editors to see what's going on. For example, if they're concerned only with certain sections, they can ignore edits that are clearly to other sections.

I realize that previewing is no longer needed with VE, which removes one advantage of editing a single section, and that with regard to footnotes, it's preferable to edit an entire article rather than just a section. So perhaps the advantages of forcing editors to always edit entire articles do outweigh the disadvantages. But, to repeat myself, this is NOT a technical decision, it's a decision about how editors work. As such, simply dropping it on the community ("VE is going to be this way; if you don't like it, you can lump it") isn't a good idea. (If the VE team feels as if there is no need to publicize this issue/decision, I'll be happy to post about htis to various Wikipedia discussion boards, so that the community is made aware of this rather large planned change.) John Broughton (talk) 19:53, 11 January 2013 (UTC)

This is a very good point. May I add that besides these good reasons, editing section by section can allow to re-think user interface, to bring controls closer to the edited content and in the end to merge the view and edit tabs, providing users with instant read & write experience (see http://ckeditor.com/demo#inline for an example). Jul (talk) 21:35, 31 January 2013 (UTC)

Yes, section editing is currently precluded due to the technology stack and the manner of the integration. Longer-term we could theoretically support in-page section editing as, indeed, the new CKeditor shows off, though this poses problems as John highlights with editing components that span multiple sections like references, in-page links, the table of contents and others.

No final decision has been made as to whether we will work to support section editing in the VisualEditor, and it is unhelpful to characterise us as having made the decision. :-) Jdforrester (WMF) (talk) 05:31, 25 February 2013 (UTC)

That would be a huge regression. Nnemo (talk) 15:21, 27 March 2013 (UTC)

Wikivoyage parser extension tags and the VisualEditor

There is a thread on Wikivoyage's Travellers' pub regarding the use of custom pseudo-XML parser extension tags, and whether they ought to be replaced with templates. Will parser extension tags be supported with the VisualEditor? Are they handled by Parsoid? Would a shift away from using them over to using templates (possibly with Lua) be useful from the VisualEditor perspective? I'd invite VE developers and interested parties to participate in the thread on Wikivoyage. —Tom Morris (talk) 02:50, 16 January 2013 (UTC)

[moved from Talk:VisualEditor.] Jdforrester (WMF) (talk) 19:53, 16 January 2013 (UTC)

Replies to individual points:

Will parser extension tags be supported with the VisualEditor?

Yes, eventually. However, this will involve adding a custom "node handler" (data model item) for these tags, and an "inspector" (UI/interaction item) for what goes in them.

Are they handled by Parsoid?

Not yet, but they will be (using the regular parser hooks).

Would a shift away from using them over to using templates (possibly with Lua) be useful from the VisualEditor perspective?

It will change the nature of the problem. :-) Either way is fine, though we'll tackle Templates ahead of project-specific extensions, so that might sway you one way or another. The use of Lua shouldn't make a difference to our Template-handlers. Jdforrester (WMF) (talk) 19:59, 16 January 2013 (UTC)

About Chinese translation

What is 复查您的更高? Is it is"复查您的更改"? Zhangjintao (talk) 05:06, 17 January 2013 (UTC)

I see that this is message "Visualeditor-savedialog-title-review", which was set to that in December by Liangent. If you think it should be changed, you should do so on TranslateWiki.net. Jdforrester (WMF) (talk) 04:43, 25 February 2013 (UTC)

Side-by-side view (no more?)

I have been coming back every few months to look at the progress VisualEditor something that diapered long ago was the side-by-side view as seen at wmfblog:2011/12/13/help-test-the-first-visual-editor-developer-prototype I thought this was a very cool feature and hope they bring it back. 71.160.155.219 20:27, 17 January 2013 (UTC)

The side-by-side view we created in late 2011 was a technology demonstrator and not intended to be part of the long-term VisualEditor interface. In particular, the conversion between wikitext and HTML is non-trivial and to provide such a 'live' side-by-side would be very slow and unwieldily for users. Though it would help users learn wikitext quickly, this is not an objective of the VisualEditor (we're looking to replace it, not help users get accustomed and learn better).

Given that the Parsoid is built in nodejs, it's not absolutely impossible for side-by-side view to be brought back with the Parsoid running on the client side. However it would be so very slow and such a drag on the database servers that I do not expect us to ever build it, and if someone volunteered to develop it, I do not believe we would deploy it on Wikimedia's servers. Jdforrester (WMF) (talk) 05:06, 25 February 2013 (UTC)

See also bugzilla:47779. Helder 19:05, 3 July 2013 (UTC)

Internal server error by VisualEditor?

Hi,

I installed VisualEditor, Parsoid and NodeJS.

When I click the WYSIWYG-Button at 'VisualEditor:Sandbox' I get an error and the VE won't show up. Using Firebug, I was able to get a detailed message:

"NetworkError: 500 Internal Server Error - http://skwiki/api.php" POST: "action=visualeditor&paction=parse&page=VisualEditor%3ASandbox&oldid=&token=0f5ccf6e2f7c0348513ed25eec655a10%2B%5C&format=json"

However, when I manually go to > http://skwiki/api.php?action=visualeditor&paction=parse&page=VisualEditor%3ASandbox&oldid=&token=0f5ccf6e2f7c0348513ed25eec655a10%2B%5C&format=json I see this on the screen: > "{"error":{"code":"mustbeposted","info":"The visualeditor module requires a POST request"}}"

So there is no 500 Internal Error. Can you help me out? 217.111.66.226 12:30, 24 January 2013 (UTC)

Agreed! I'm having the exact same problem! 152.160.16.98 19:07, 31 January 2013 (UTC)

A note to the guy at 217.111.66.226.....

Try updating your mediawiki version. the spec on

http://www.mediawiki.org/wiki/Extension:VisualEditor

says that you need a minimum version of 1.21/wmf5+

I got that here:

https://toolserver.org/~krinkle/mwSnapshots/#!/mediawiki-core/wmf/1.21wmf8

And also had to change my localsettings.js file in Parsoid/js/.

For me it was

parsoidConfig.setInterwiki( 'localhost', 'http://LOCAL*IP*ADDRESS/wiki/api.php' ); 152.160.16.98 21:43, 31 January 2013 (UTC)