When a user goes to change a preference, they are usually in one of the following states:
1. On a page that the preference would affect, and they wish to change the preference and have the change be effective asap.
2. About to go to a page, and know they need to change a preference in order that it is rendered the way they want.

An example of both of those scenarios is bug 52355, where a user wants to enable the VisualEditor on the current page, or enable it on the next page they visit (especially if it is a redlink).

Currently the typical workflow is
0. The user on a mediawiki page
1. Load special:preferences
2. Change the preference and Save (which loads preferences panel again)
3. Press 'Back' button twice
4. Reload or click a link

Desired workflow:
1. Open a pref panel in the current page
2. Change the pref and close the panel
3. The changes become effective immediately, if that can be achieved without reloading the page and/or loosing any user data, or a small notice displayed near the preferences panel button to inform the users their changes will be effective by reloading.

--------------------------
**Version**: 1.22.0
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52355
All products occasionally cause the user to have their work disappear.  It could be the browser crashes, or the UI in a window becomes locked up.  The VisualEditor is having more than its fair share of these at the moment, and it would be good to track them with a keyword.

There are quite a few Parsoid/VisualEditor bugs that are behind 'corruption' of the wiki database.  'corruption' probably isnt the best name for the keyword.  It would include all the nowiki and pawn bugs, but also some parsoid round-trip issues.  These are not always high priority/severity, if they are rare or impossible in a 'normal configuration'.

--------------------------
**Version**: wmf-deployment
**Severity**: enhancement
Closing for the time being as per comment 6. Feel free to reopen if there are more requestees / more arguments.
In case that you are so far the only person interested in this, I recommend to use the Whiteboard field instead of introducing keywords - only difference to keywords is that anybody can use it for tagging (so using a "personal namespace" might be considered, e.g. I use the whiteboard for "aklapper-moreinfo" entries), and that it is not limited to entries globally defined on the server (like for keywords).
I'm saying this because I prefer to keep the list of keywords small (as otherwise nobody can remember them anymore and does not set them, seen that problem in many other Bugzillas) and cross-product.
Yes I am intetested in building lists. I could use tracking bugs, but we have this funky keywords feature in bugzilla where dataloss and corruption typically go.

Precisely because dataloss and corruption are orthogonal to severity and priority, these keywords would allow periodic review of these bugs that havent been resolved due to prioritisation and open adhoc system.

My intentions are to help the mediawiki product and extensions and users.
(In reply to comment #1)
> Refering to a potential database corruption keyword, what are your
> intentions?
> Are you just interesting to find a list of all such issues more quickly?
> Would this keyword somehow help developers to keep track?
(In reply to comment #2)
> IMO severity and dataloss are orthogonal.  Not all critical are dataloss
> cases,
> and some dataloss are not critical.  The definition of critical includes a
> reasonable caveat 'in a widely used and important component'.

I agree, it does not always fit, but in most cases.
Question is: How exact and specific do we need to tag information in Bugzilla, and for the sake of who? :)
A discussion is happening over at https://www.mediawiki.org/wiki/Talk:Bugzilla/Fields

IMO severity and dataloss are orthogonal.  Not all critical are dataloss cases, and some dataloss are not critical.  The definition of critical includes a reasonable caveat 'in a widely used and important component'.

I would consider bug 52187 to be a dataloss problem, and that its severity of normal is a reasonable assessment.  But that doesnt change the fact that real users are loosing their data.

IMO bug 54591 would be corruption, but unlikely to be critical as it isnt a standard operation to add a math element and put nothing in it, and it is easily fixable.
Loss of data is severity=critical by definition ( https://www.mediawiki.org/wiki/Bugzilla/Fields#importance ) hence I don't see a need for a keyword.

Refering to a potential database corruption keyword, what are your intentions? Are you just interesting to find a list of all such issues more quickly? Would this keyword somehow help developers to keep track?
this is like bug 46893.

 $ cd extensions/VisualEditor/modules/ve-mw/test/browser
 $ bundle exec cucumber features/visual_editor_bullets.feature

If the tests progress, eventually they print out a lot of

*** DEPRECATION WARNING
*** You are calling a method named class_name at /home/spage/projects/core/extensions/VisualEditor/modules/ve-mw/test/browser/features/step_definitions/visual_editor_bullets_steps.rb:81:in `block in <top (required)>'.
*** This method does not exist in page-object so it is being passed to the driver.
*** This feature will be removed in the near future.
*** Please change your code to call the correct page-object method.
*** If you are using functionality that does not exist in page-object please request it be added.

*** DEPRECATION WARNING
*** You are calling a method named select_text at /home/spage/projects/core/extensions/VisualEditor/modules/ve-mw/test/browser/features/step_definitions/visual_editor_bullets_steps.rb:14:in `block in <top (required)>'.
*** [same last 4 lines]

The lines deprecated by the former are all of the form
  SOME_element.class_name.{should, should_not} match /disabled/
where the HTML has CSS class="ve-ui-widget ve-ui-tool ve-ui-tool-outdent ve-ui-widget-disabled".  I don't know the page-object equivalent to retrieving the CSS class (attribute( 'class' ), but maybe instead the code could use page-object's disabled? and enabled? methods.

The latter deprecation is odd since the test specifically requires "watir-webdriver/extensions/select_text"

--------------------------
**Version**: wmf-deployment
**Severity**: normal
**Whiteboard**: gci2013 https://www.mediawiki.org/wiki/Google_Code-In#Candidate_tasks
After a quick look at VisualEditor Jenkins jobs[0], looks like this is fixed. Please reopen if you see the problem again.

0: https://integration.wikimedia.org/ci/view/BrowserTests/view/VisualEditor/
(In reply to Chris McMahon from comment #4)
> Cheezy actually fixed this but hasn't updated the page-object gem yet
> https://github.com/cheezy/page-object/issues/192

Željko / Chris: Is this still a valid ticket one year after? Has Cheezy updated it in the meantime or is this still a task suitable for new contributors?
If you need more information (and you probably do), feel free to ask questions
here, at #wikimedia-qa freenode IRC channel or at QA mailing list:

https://lists.wikimedia.org/mailman/listinfo/qa
Cheezy actually fixed this but hasn't updated the page-object gem yet https://github.com/cheezy/page-object/issues/192
See also bug 46893
And here:

https://wmf.ci.cloudbees.com/job/VisualEditor-test2.wikipedia.org-linux-firefox/119/console
Still not fixed:

https://wmf.ci.cloudbees.com/view/r-ve/job/VisualEditor-test2.wikipedia.org-linux-chrome/96/console
Non-embedded inspectors are generally positioned to the bottom right of the node they're inspecting. In cases where we're dynamically altering the node, however (like the live preview feature for math), it probably makes more sense to position that kind of inspector at the bottom left. Then if the dimensions of the node change, the inspector will move around a bit less.

Thoughts? Other ideas to tackle this issue?

--------------------------
**Version**: unspecified
**Severity**: enhancement
Fixed a while ago
If the parsoid service is down (`sudo service parsoid stop`, or update extension/Parsoid and forget/fail `npm install`), then viewing flow pages fails with exception

   Parser only supports wikitext to HTML conversion

   Backtrace:

   #0 /srv/mediawiki/extensions/Flow/includes/ParsoidUtils.php(24): Flow\ParsoidUtils::parser('html', 'wikitext', '<p>It's a long ...')

This is true, but it masks the real problem that parsoid has to work, and didn't.  ParsoidUtils::convert has a try-catch block around using parsoid, and if that fails it will fall back to using parser. It would be helpful for wiki operators if the exception message included the parsoid failure, e.g.
   Parser only supports wikitext to HTML conversion (and parsoid earlier failed with exception "VisualEditor is unavailable")

Now that I've figured out what's going on, this has become a low-priority bug :-)

--------------------------
**Version**: master
**Severity**: minor
https://gerrit.wikimedia.org/r/#/c/92633/
Prioritization and scheduling of this bug is tracked on Mingle card https://mingle.corp.wikimedia.org/projects/flow/cards/264
When an image is selected it should be possible to position it using the cursor keys.

up/down should move it one line up/down. Whether left/right should move it one character or one word at a time I'm not sure about. Possibly shift/ctrl should modify this?

This would be useful for fine control and for systems with laggy mouse behaviour (not uncommon on slow connections in my experience).

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51665
We probably can't use arrow keys (because that's over-riding expected behaviour of moving the cursor) but we could use Ctrl+→ etc. potentially.
When a pre-formatted paragraph with long lines is displayed in VE it word wraps. However it doesn't word-wrap in display mode (T2260), meaning that you have no idea that you need to add manual line breaks until after you have saved.

See https://en.wikipedia.org/w/index.php?title=User:Thryduulf/sandbox3&oldid=573792519#Section_number_three (rendered) and https://en.wikipedia.org/w/index.php?title=User:Thryduulf/sandbox3&oldid=573792519&veaction=edit&section=2 (in VE)

The word wrapping in VE is actually better than what happens in read mode, but the two should not be different. Fixing T2260 would be better, but as it's been open since 2004 adjusting VE to match the current behaviour seems more realistic :/

--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=260
Change 205177 merged by jenkins-bot:
Do not wrap <pre> nodes

[[https://gerrit.wikimedia.org/r/205177]]
Change 205177 had a related patch set uploaded (by Bartosz Dziewoński):
Do not wrap <pre> nodes

[[https://gerrit.wikimedia.org/r/205177]]
We have `pre.ve-ce-branchNode { white-space: pre-wrap; }` added per T40043, because Chrome/Safari will otherwise //also// wrap the text, not just between words, but anywhere (this affects any `<pre>` inside a  `contenteditable="true"` node). I did some searching and found https://bugs.webkit.org/show_bug.cgi?id=35935; it appears that we can set `word-wrap: normal;` to override this behavior.

We also need to remove `overflow: hidden` from the surface to get regular sane horizontal scrolling behavior. It doesn't //seem// to be necessary…
Created attachment 17130
Read - no word wrapping

**Attached**: {F11732}
Created attachment 17129
Preformatted text in Edit- word wrapping is present

**Attached**: {F11731}
Alternatively we could fix this bug in MediaWiki…
See e.g. http://www.impressivewebs.com/demo-files/question-mark-js/ - similarly used in Reddit etc.

--------------------------
**Version**: unspecified
**Severity**: enhancement
https://gerrit.wikimedia.org/r/#/c/107153/
Screenshot of link inspector not listing a matching page

When opening the link inspector on a link to dab page [[Department of Foreign Affairs and Trade]], the link inspector shows two items: the dab page, and the page [[Department of Foreign Affairs and Trade (Ireland)]].  It does not list [[Department of Foreign Affairs and Trade (Australia)]].  The unlisted page is not a new page.

Steps to reproduce:
1. https://en.wikipedia.org/w/index.php?title=Heidi_Bootle&oldid=573475141
2. Open Visual Editor
3. Click on Department of Foreign Affairs and Trade

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51013

**Attached**: {F11697}
Actually, merging this into bug 51013 for actioning.

*** This bug has been marked as a duplicate of bug 51013 ***
*** Bug 67150 has been marked as a duplicate of this bug. ***
*** Bug 62804 has been marked as a duplicate of this bug. ***
Although it can't be used in articles, it is widely used elsewhere, including userpages.
If you try and VEdit https://en.wikipedia.org/w/index.php?title=User:Elitre_(WMF)/Sandbox&oldid=573626556 you'll notice that this reflects in reference numbering being incorrect, since the ones in the divbox will be ignored.
Thanks.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=54803
Another issue:
<<Open a page with {{divbox|amber|test|Test content.}} Click on the divbox, open the template dialogue. Click on "apply changes". Divbox disappears.>>

If you want to test this, VEdit https://en.wikipedia.org/w/index.php?title=User:Elitre_(WMF)/Sandbox&oldid=573628652 .
My previous comment was related to a page containing <div style="{{divstyleamber}}">Content.</div>, which can not be edited.
Incorrect reversed display of non Latin characters

Please see the attached image and Bugs #54308 & #54309.

By this time I resigned to utilize the advanced toolbar and after making an attempt, I feel very cynical because this effort is totally useless. There is a lot to be said for programmers and developers learning to proofread a chapter or so of text, to see how their ideas are working in the real world.

In the first place, It takes several steps to hide the header to gain additional viewing space or access various features. 

Finally, The non-Latin characters, like Hebrew and Arabic were inserted from left to right. For those who don't understand, that's the equivalent of displaying Latin characters from right to left, as in: . . . . L K J I H G F E D C B A

In view of my previous posts, please consider correcting this ASAP.

--------------------------
**Version**: unspecified
**Severity**: normal

**Attached**: {F11606}
**yesod22** wrote:

Hi. The only input I can give is that as a bi-lingual english hebrew speaker being forced with the option of having english displayed RTL or hebrew displayed LTR is CERTAINLY not desired. I'd much prefer having each language displayed in it's natural order - as it's supposed to be.

The idea of displaying Hebrew or Arabic from LTR because that's the expectation of an english speaker reminds me of a joke by Louis CK on how the pilgrims named the natives "Indians" despite the fact that they had nothing to do with India :-) (see youtube). A language should be displayed in it's order - not in the order of what a non-native speaker would like it to be :-)

blessings, Daniel
Michael M., Please point me to the page on en.Wikipedia where RTL characters show up correctly. I just implemented the WikiEditor on en. Wikipedia and RTL characters were displayed in LTR order. Then, I am curious as to how do you know what is the expectation of the users???
Reopening: I looked at en.wikipedia and de.wikipedia. Both have a set of special characters *below* the editbox, which isn't part of MediaWiki, but developed by the communities. In both cases the characters of RTL languages are shown from right to left, so even if this behavior of WikiEditor is intended (which I doubt), it is wrong based on the expectation of its users.
Andre, the user's language settings should not affect the character sets. They should be displayed in their natural order regardless of the user's language preferences.
Confirming what you see. Hebrew letters Alef and Bet are on the left. 

I am pretty sure that this is intended and that it depends on your personal language settings in https://en.wikisource.org/wiki/Special:Preferences#mw-prefsection-personal-i18n because depending on your "primary" language you are used to either expect the first letter on the left (LTR) or on the right (RTL).

It's the same the other way round: 
Looking at the Cyrillic character section with the interface language set to Hebrew (by simply adding &uselang=he to the URL), I also get the Russian alphabet from right to left, while Russian is a left to right language.
In a status bar/next to the cursor/on the image

--------------------------
**Version**: unspecified
**Severity**: enhancement
Change 85970 merged by jenkins-bot:
Show a label with the current dimensions while resizing

https://gerrit.wikimedia.org/r/85970
Change 85970 had a related patch set uploaded by Esanders:
Show a label with the current dimensions while resizing

https://gerrit.wikimedia.org/r/85970
Created attachment 13376
Screenshot of implementation

**Attached**: {F11558}
Example image: https://www.mediawiki.org/wiki/File:MassMessage_submitted.png

Clicking on "edit" takes you to <https://www.mediawiki.org/wiki/File:MassMessage_submitted.png?veaction=edit&vesection=1>

Clicking on "edit source" tags you to <https://commons.wikimedia.org/w/index.php?title=File:MassMessage_submitted.png&action=edit&section=1>

The 'edit' link should take you to commons and somehow gracefully fallback on the wikitext editor since VE is not enabled.

--------------------------
**Version**: unspecified
**Severity**: minor
**URL**: https://www.mediawiki.org/wiki/File:MassMessage_submitted.png
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=62071
Change 130082 merged by jenkins-bot:
Don't change section edit links on foreign file description pages

https://gerrit.wikimedia.org/r/130082
Change 130082 had a related patch set uploaded by Alex Monk:
Don't change section edit links on foreign file description pages

https://gerrit.wikimedia.org/r/130082
**Author:** `swalling`

**Description:**
Screenshot

If you start ?tour=firstedit and then click veaction=edit, you get the wikitext-related Preview step unattached (see screenshot).

This is a low priority issue, because users should only be getting the wikitext 'firstedit' tour if VE is not available. I am filing just in case the opposite situation might happen, i.e. users start a ?tour=vefirstedit, click Edit source, then get the VE tour step. If that's impossible, then this can be ignored for now.

--------------------------
**Version**: unspecified
**Severity**: normal

**Attached**: {F11439}
If you look at firstedit tour definition, you'll see that shouldSkip is set to call isEditing() Calling gt.isEditing() checks to see if you are either editing with wikitext or if the VisualEditor is loaded.  However the tour step loads before ve is actually loaded.

IMO: isEditing needs to return true if VisualEditor is loading or loaded.  
Locally this fixes the bug for me.  I probably will make a patch for this.
Change 84735 had a related patch set uploaded by Mattflaschen:
Declare tour as requiring wikitext, but it doesn't work yet.

https://gerrit.wikimedia.org/r/84735
I was wrong about it being an easy fix.  As far as I can tell, this never worked (wikitext tours not being loaded for VisualEditor).  There are two different scenarios, which don't work for different reasons.

However, it will work in the other direction (which is probably why I didn't catch this bug earlier): If it's a VE tour it will not show in the wikitext editor.

I will fix this properly, but it looks like it may require some refactoring to do right.
Oh, I forgot the showConditionally.  This is a trivial fix, and I'll do it tonight.
Currently there are only 4 IRC channels being scanned at 

http://korma.wmflabs.org/browser/irc-repos.html

https://meta.wikimedia.org/wiki/IRC/Channels#MediaWiki_and_technical contains the list of tech channels

#pywikipediabot should be added as well in order to keep consistency with https://wikitech.wikimedia.org/wiki/Key_Wikimedia_software_projects

--------------------------
**Version**: unspecified
**Severity**: normal
Thanks! Closing.
Ok, channels are updated.

Having a JSON file with the list of channels and log place would be awesome :).

@Aklapper, from my side feel free to close the task if you prefer to have further discussion about automation in another ticket.
Also note my last comment at https://github.com/benapetr/wikimedia-bot/pull/49#issuecomment-149596883
It would be trivial for this to all be in json format too but I would leave that for @petrb to implement!
>>! In T56230#1735259, @Aklapper wrote:
>>>! In T56230#1734947, @Dicortazar wrote:
>> is there a way to automatically retrieve the list of available channels?.
> 
> for "automatically retrieve the list of channels **which are logged by wm-bot**" I have asked its maintainer and will update this task once I've received an answer.

<addshore> the list is not on github! You manage the setting per channel through the bot!
<addshore> http://bots.wmflabs.org/~wm-bot/dump/systemdata.htm
<addshore> that has all of the info on it, updated every 20 mins
<addshore> there isn't a structured form currently though
>>! In T56230#1737513, @Qgil wrote:
> Do we need to remove deprecated channels?

No, so I've canceled https://github.com/Bitergia/mediawiki-repositories/pull/8

>>! In T56230#1736157, @Dicortazar wrote:
> we just need to add the listed channels in that irc_channels.conf file and we would be done here :).

Awesome! Feel free to close this longstanding task after merging https://github.com/Bitergia/mediawiki-repositories/pull/9

We (I?) can create separate tasks to discuss whether to get certain channels logged by wm-bot ("mediawiki-i18n", "mediawiki-parsoid", "mediawiki-scripts", "wikimedia-cep", "wikimedia-design", "wikimedia-ect", "wikimedia-perf", "wikimedia-qa", "wikimedia-search", "pywikibot") and after deciding, getting them added to korma later.
This depends on your needs. I mean, as we're not automatically retrieving IRC channels information, we can keep as many channels as you want.

The irc_channels.conf file is more a place to centralize requirements from Korma than an automated place to retrieve IRC info. On the other hand, as we successfully automated Gerrit projects, the Gerrit .conf file is a place where automatically info is updated, added and removed.
Do we need to remove deprecated channels? Isn't their information useful to
count contributions of related users in those channels?
@Aklapper, what I've done so far is to manually add them to the infrastructure (this is indeed a script deleting, removing, adding URLs, tar.gz, etc) and I wanted to add that list of TRACKED channels once the process if finished and correct (still running).

And yes, as you comment, we just need to add the listed channels in that irc_channels.conf file and we would be done here :).
>>! In T56230#1735971, @Dicortazar wrote:
> Based on info provided by @Aklapper, I've added all of them

Thank you. 
I think we're cool with this list for now; adding any further potential channels would first require making them logged on the Wikimedia side of things.

@Dicortazar: For my understanding of the infrastructure: where did you "add" them? Any URL to some public diff? I guess the next and last step for one of us is to provide a pull request to `mediawiki-repositories/irc_channels.conf` adding those TRACKED channels and after merging that pull request we are done here?
Based on info provided by @Aklapper, I've added all of them, but mediawiki that was already in the list.

So, the list is as follows:

* "mediawiki": TRACKED
* "mediawiki-i18n": 
* "semantic-mediawiki": TRACKED
* "mediawiki-parsoid":
* "mediawiki-visualeditor": TRACKED
* "mediawiki-scripts":
* "wikimedia-tech": TRACKED
* "wikimedia-dev": TRACKED
* "wikimedia-toolserver": TRACKED
* "wikimedia-labs": TRACKED
* "wikimedia-labs-nagios":
* "wikimedia-ai": TRACKED
* "wikimedia-analytics": TRACKED
* "wikimedia-cep":
* "mediawiki-core": TRACKED
* "wikimedia-collaboration": TRACKED
* "wikimedia-databases": TRACKED
* "wikimedia-design":
* "wikimedia-ect":
* "wikimedia-fundraising": TRACKED
* "wikimedia-mobile": TRACKED
* "wikimedia-multimedia": TRACKED
* "wikimedia-operations": TRACKED
* "wikimedia-perf":
* "wikimedia-qa":
* "wikimedia-releng": TRACKED
* "wikimedia-research": TRACKED
* "wikimedia-search":
* "wikimedia-teampractices": TRACKED
* "huggle": TRACKED
* "pywikibot":
* "wikidata" TRACKED
And regarding to the rest of IRC channels. Do we have logs for all of them?

The following ones were the ones added in the GitHub change:

* "mediawiki": TRACKED
* "mediawiki-i18n": 
* "semantic-mediawiki": TRACKED
* "mediawiki-parsoid":
* "mediawiki-visualeditor":
* "mediawiki-scripts":
* "wikimedia-tech": TRACKED
* "wikimedia-dev": TRACKED
* "wikimedia-toolserver": TRACKED
* "wikimedia-labs": TRACKED
* "wikimedia-labs-nagios":
* "wikimedia-ai":
* "wikimedia-analytics": TRACKED
* "wikimedia-cep":
* "mediawiki-core":
* "wikimedia-collaboration":
* "wikimedia-databases":
* "wikimedia-design":
* "wikimedia-ect":
* "wikimedia-fundraising": TRACKED
* "wikimedia-mobile": TRACKED
* "wikimedia-multimedia":
* "wikimedia-operations": TRACKED
* "wikimedia-perf":
* "wikimedia-qa":
* "wikimedia-releng":
* "wikimedia-research":
* "wikimedia-search":
* "wikimedia-teampractices":
* "huggle": TRACKED
* "pywikibot":
* "wikidata"

For the rest of the non TRACKED IRC channels, there's missing information in some cases at https://meta.wikimedia.org/wiki/IRC/Channels about where the logs are stored.
I've commented on the GitHub repo.

As a summary: I'll close that pull request since the place to add/remove repositories takes place at https://github.com/Bitergia/mediawiki-repositories

On the other hand, is there a way to automatically retrieve the list of available channels?.

Finally, the list of updated repos analyzed by Korma are found at http://korma.wmflabs.org/browser/data/json/irc-repos.json, but there are some more than the initial four: "wikimedia-operations", "mediawiki", "wikimedia-dev", "wikimedia-labs", "wikimedia-mobile", "wikimedia-toolserver", "wikimedia-tech", "wikimedia-analytics", "wikimedia-fundraising", "semantic-mediawiki", "huggle"
>>! In T56230#1557951, @Dicortazar wrote:
> I'll check that list and update those channels in Korma.

@Dicortazar: Clean pull request now in https://github.com/Bitergia/mediawiki-dashboard/pull/62
(let's keep the discussion of this task focused on IRC channels, not mixing it with code repositories)
Thanks for this update!

I'll check that list and update those channels in Korma.

@Dzahn and @Aklapper, I'm still working on the feature to automate the list of repositories to be tracked by Korma at {T104845}. In summary this will provide a list of repositories per data source and a black list for each of them.

Thus, anyone interested in tracing new repositories or in adding some of them to the black list, should modify such lists and pull request a change.

A first version of the files are available at GitHub in https://github.com/Bitergia/mediawiki-repositories. Those are old versions, so we shouldn't change those a lot.

So, if we keep that workflow, @Aklapper, my suggestion is to add a new config file to the GitHub repo (irc_channels.conf) with the correct list of repositories (sorted). I can do this in any case with the new list you provided. This will help to centralized those lists of repos.

Comments are welcome in any case :). It's a bit complex task to automate and trace repositories, but this could be an interesting feature for all of us :).
So that updated list would be https://github.com/Bitergia/mediawiki-dashboard/pull/59/files (and obviously my GitHub workflow skills are still improvable, sigh)
>>! In T56230#1443372, @Dzahn wrote:
> How do you add channels to korma?

Editing `/browser/data/json/irc-repos.json` in https://github.com/Bitergia/mediawiki-dashboard
How do you add channels to korma?
Once {T96371} is closed, we may want to work on this task again.

We can discuss this during this Friday conf call and leave it as June task.
%%%*** Bug 60079 has been marked as a duplicate of this bug. ***%%%
IRC channels are not that critical. Normal priority.
Ooops, actually Nemo is (again) right:

https://meta.wikimedia.org/wiki/IRC/Channels#MediaWiki_and_technical
https://meta.wikimedia.org/wiki/IRC/Channels#Tools
Check the URL above. I'm proposing only the "MediaWiki and technical" section plus #pywikipediabot
There are 261 Wikimedia IRC channels. We want to gather all those channels?

I think it is not a big issue to configure and implement it, but it could be an important delay and resource consuming in the update process because logs are included in one big file per channel and the incremental support can not be implemented.

http://bots.wmflabs.org/~wm-bot/logs/

Is there any other place with logs for IRC channels?
InstantCommons does not work on Vagrant if you enable the 404 handler for images (the `thumb_on_404` role does that and most multimedia roles include it). The problem is related to thumbnail caching; similar to T101565, but the default wiki (`127.0.0.1`) is also affected.

As a workaround, caching can be disabled by creating `/vagrant/settings.d/10-DisableThumbnailCaching.php` with
```
<?php
$wgUseInstantCommons = false;
$wgForeignFileRepos[] = array(
	'class' => 'ForeignAPIRepo',
	'name' => 'wikimediacommons',
	'apibase' => 'http://commons.wikimedia.org/w/api.php',
	'fetchDescription' => true,
	'descriptionCacheExpiry' => 0,
	'apiThumbCacheExpiry' => 0,
);
```
Please reopen or file a new bug if you can reproduce.
IIRC yes but much harder to trigger than it used to be. But I'm may be wrong - I only vaguely remember what this was about.
@Tgr is this still an ongoing problem?
Change 223480 abandoned by Gergő Tisza:
Use 404 handler for all wikis when the role is enabled

Reason:
There doesn't seem to be a way to do this correctly.

[[https://gerrit.wikimedia.org/r/223480]]
Change 223493 merged by jenkins-bot:
Fix thumb on 404 role for multiwiki reality

[[https://gerrit.wikimedia.org/r/223493]]
Change 223477 merged by jenkins-bot:
Fix thumb rewrite rules

[[https://gerrit.wikimedia.org/r/223477]]
Change 223493 had a related patch set uploaded (by BryanDavis):
Fix thumb on 404 role for multiwiki reality

[[https://gerrit.wikimedia.org/r/223493]]
Change 223480 had a related patch set uploaded (by Gergő Tisza):
Use 404 handler for all wikis when the role is enabled

[[https://gerrit.wikimedia.org/r/223480]]
Change 223477 had a related patch set uploaded (by Gergő Tisza):
Fix thumb rewrite rules

[[https://gerrit.wikimedia.org/r/223477]]
From the Apache docs:
> REQUEST_FILENAME
> The full local filesystem path to the file or script matching the request, if this has already been determined by the server at the time REQUEST_FILENAME is referenced. Otherwise, such as when used in virtual host context, the same value as REQUEST_URI. Depending on the value of AcceptPathInfo, the server may have only used some leading components of the REQUEST_URI to map the request to a file.

So apparently the problem is that Apache does not map the URI to the filesystem path before checking whether the file exists. If I disable the rewrite rule, the thumbnail appears correctly.
Probably even more broken on other wikis since the 404 handler config rule seems to only be applied to the default wiki (and the one created by the `commonswiki` role which has its own apache rules).
Still (or again) broken. Commons API is used without a problem, the image is thumbnailed, but Apache redirects the request to `thumb.php` even though the thumbnail exists and seems to be in the right place. (`thumb.php` cannot handle remote images, that's T27958.)
Can't reproduce this anymore. https://gerrit.wikimedia.org/r/217769 might have fixed it.
Same for me. This is actually impacting my ability to code review certain changes... :-/
Enabling the multimedia role on a fresh MW-Vagrant box still produces broken thumbnails for me. ("//Error generating thumbnail: The source file 'XXX' does not exist.//")
@Eloquence, @tgr Is this still a problem?
Bulk unassigning bugs from Ori.
In the latest MediaWiki Vagrant with the multimedia role enabled, InstantCommons does not successfully generate thumbnails for me. The issue goes away if I comment out the thumb-php-on-404 handler, so I suspect it's an issue with the rewrite rule. CCing Bryan since he wrote that template.
I can confirm that Gergo's workaround does the trick, even for a Vagrant newbie like me.

So even if we can't fix this in code right away, at least we have a solution for making this work temporarily.

Thanks for this!
Bawolff: I could reproduce this with the multimedia vagrant role enabled, which in theory should enable 404-based image handling.
Workaround:

<?php
$wgUseInstantCommons = false;
$wgForeignFileRepos[] = array(
    'class' => 'ForeignAPIRepo',
    'name' => 'wikimediacommons',
    'apibase' => 'http://commons.wikimedia.org/w/api.php',
    'fetchDescription' => true,
    'descriptionCacheExpiry' => 0,
    'apiThumbCacheExpiry' => 0,
);

I started to track this down some weeks ago but ran out of time and had to give up. The issue was MediaWiki getting confused about which local directory to use for the thumb cache IIRC.
This is a known issue of using thumb.php directly instead of from a 404 handler. (Not sure how "known" in any case, not new)
Oddly, if I insert an image from Commons through VisualEditor it appears to work ok inline.

If I insert one in source, I get "Error creating thumbnail: Invalid thumbnail parameters".

whaaaaaat?
(Hopefully other reporters will improve the title and description if necessary!)
The French Wikipedia has a number of templates which usually ask for some kind of clarification about a whole passage of text (see https://fr.wikipedia.org/wiki/Mod%C3%A8le:Refnec#Exemples ).
So users are asking that, when they select that text and launch the template inspector, the text is already recognized as a "parameter" for that template.
Thanks.

--------------------------
**Version**: unspecified
**Severity**: enhancement
I think a better way to solve this would be to somehow allow templates to be treated as 'annotations' in VE (like bold style or links).
This feature would be very helpful for other common templates in articles. For example, the {{Colonnes}} template on French wiki, or its equivalent {{columns-list}} template on English wiki to put text/lists on several columns.

https://en.wikipedia.org/wiki/Template:Columns-list
I think it's not only the French wiki that may use this... On English wiki, the equivalent of {{Refnec}} and its "1" parameter is {{Citation needed span}} and its "text" parameter.

Maybe a way of implementing this would be the following :
* Add an information in TemplateData to be able to tell which parameter should be initialized with the selected text
* When you insert a template with VE, if the TemplateData as such configuration, use the selected text to initialize the parameter
And I think that such a functionality would need to be able to remove the template by replacing it with its first parameter.
NicoV reports this diff,
https://fr.wikipedia.org/w/index.php?title=Blood_Lad&diff=96657484&oldid=96506947 .
Assuming the user deleted the infobox without realizing it, I did not manage to reproduce the duplication of categories inside a reference tag (line 38); if I just copy/paste them they get nowikied, so it shouldn't be a vandalism.  

CCing subbu and gwicke here. T52120 and T54238 come to mind, but I'm not sure if it's really a dupe.
Thanks.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
T54238
T52120
T76715
T89618
Think this was all fixed
https://fr.wikipedia.org/w/index.php?title=Bello_de_Carcassonne&diff=107097528&oldid=107091155 duplicated two categories and added others, but not within a ref tag.  It also added a blank (== ==) section heading after the misplaced cats.
Yes Gabriel, I tried to behave like a vandal :) and wanted to paste templates and categories into the reference, to understand if this was what the user had actually done.
But as you can see here https://fr.wikipedia.org/w/index.php?title=Utilisateur%3AElitre_%28WMF%29%2FProve&diff=96710198&oldid=96710142 my result is different, in that the pasted content generated nowiki tags, so the duplication in the article is not a result of copy/pasting that content into the reference editor.
(In reply to comment #0)
> NicoV reports this diff,
> https://fr.wikipedia.org/w/index.
> php?title=Blood_Lad&diff=96657484&oldid=96506947
> .
> Assuming the user deleted the infobox without realizing it, I did not manage
> to
> reproduce the duplication of categories inside a reference tag (line 38); if
> I
> just copy/paste them they get nowikied, so it shouldn't be a vandalism.

Can you clarify what you mean with 'just copy/paste them'? Do you mean copy/pasting wikitext into VE?
Change in MediaWiki:Editing notice to a links does not  parse

Hi,


When I tried to add a internal link (related to [[Special:Preferences#mw-prefsection-editing]])  to MediaWiki:Editing, it did not parse as shown in attachment.  


*Exact edit  difference which I tried https://mr.wikipedia.org/w/index.php?title=मिडियाविकी%3AEditing&diff=1200554&oldid=44085 the result is shown in the attachment.


*The purpose of edit was to request users to give a try to VisualEditor and report input issues . (Issues related to usability of Marathi Devnagari script are very crucial to us )


I am not sure whether this a normal limitation of MediaWiki messages  and so not sure whether this will be accepted as a bug.

But still prefered to report this bug since it is simmiller problem of parsing which I observed in Bug no 45195 also and just prefered to keep developers informed.

Thanks and regards

--------------------------
**Version**: 1.22.0
**Severity**: normal
**Whiteboard**: aklapper-moreinfo
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=45195

**Attached**: {F11186}
The issue in comment 0 was about a link not being parsed and instead [[]] is literally shown. My confusion probably arised from the fact that you had changed https://mr.wikipedia.org/w/index.php?title=मिडियाविकी:Editing already, so I asked how to see this problem myself and to provide steps.

MediaWiki:Editing neither exists on en.wp or fr.wp and was removed in 2007.

As the issue was originally about https://mr.wikipedia.org/w/index.php?title=%E0%A4%AE%E0%A4%BF%E0%A4%A1%E0%A4%BF%E0%A4%AF%E0%A4%BE%E0%A4%B5%E0%A4%BF%E0%A4%95%E0%A5%80%3AEditing&diff=1200554&oldid=44085 which is totally wrong HTML I don't see any valid bug reported here.

If the problem still happens with *valid* HTML, please reopen this bug report and link to the revision of MediaWiki:Editing that shows the problem. Thanks.
Created attachment 13341
additional example of message MediaWiki:Editing

(In reply to comment #3)

Additional example of how MediaWiki message MediaWiki:Editing works.

**Attached**: {F11189}
Created attachment 13340
MediaWiki:Editing example en wikipedia

(In reply to comment #3)

Which language you used for The Tokyo article ? Here is an example from eglish wikipedia

**Attached**: {F11188}
Created attachment 13332
Editing The Tokyo article

(In reply to comment #2)
> *[[MediaWiki:Editing]] message (Current text:Editing $1) is visible at the
> top of every wiki page when you  are editing any wiki page.

No, not for me.

**Attached**: {F11187}
(In reply to comment #1)
> How to see what's on the screenshot? This is missing steps... 

*[[MediaWiki:Editing]] message (Current text:Editing $1) is visible at the top of every wiki page when you  are editing any wiki page.

* So the given screen shot will be visible on all wiki pages while editing if you save the given edit diff https://mr.wikipedia.org/w/index.php?title=मिडियाविकी%3AEditing&diff=1200554&oldid=44085 on any test wiki


** (My impression is MediaWiki messages work simmiller to Templates. If template:ABC is having internal link [[PQR]] and template:ABC is included in Template:XYZ usually internal link [[PQR]] of template:ABC will parse through Template:XYZ , What I suppose/doubt is,  If MediaWiki:ABC has internal link  [[PQR]] and MediaWiki:ABC is getting included in MediaWiki:XYZ unlike templates MediaWiki messages are not parsing internal link of another MediaWiki message.That is my pure guess you(Developers) are the right people to inform what is supposed to be expected behaviour for MediaWiki messages,and the reported behaviour is matching with expected behaviour or not)


Also, 
>    <small><small><small /><small /> 
> does not look like valid HTML to me.

*https://mr.wikipedia.org/w/index.php?title=%E0%A4%AE%E0%A4%BF%E0%A4%A1%E0%A4%BF%E0%A4%AF%E0%A4%BE%E0%A4%B5%E0%A4%BF%E0%A4%95%E0%A5%80:Sitenotice&diff=prev&oldid=1201270 It is the same text parsing through the internal links in different MediaWiki message.

HTML may be having minor issue on layout side but parsing of internal link is different issue I suppose.

Rgds
How to see what's on the screenshot? This is missing steps... Also, 
   <small><small><small /><small /> 
does not look like valid HTML to me.
If adding w:cs:template:commonscat, it might be confusing for newbies even for older wikipadians to set parameters. As in this case parameters or numbers, but VE sais that such parameters are unknown.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50735
Merging with bug 50735.

*** This bug has been marked as a duplicate of bug 50735 ***
If I can paraphrase Juan's bug report, ..

In the transclusion dialog, template 'add parameter' screen, for a template without templatedata (such as cs:wp template commonscat),...

Dont say 'Unknown parameter'.

If there is no templatedata, VE doesnt know about any parameters, so it should not offer warnings that are essentially bogus when it is given a parameter name.  The user cant use this 'Unknown parameter' information, so it is scary.  Further to that, VE _does_ know that numeric parameters names (like '1', '2', etc) are valid parameter name, so warning 'Unknown parameter' is false in that case.

Juan, if you want to add templatedata to that template, see https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/TemplateData  and
https://en.wikipedia.org/w/index.php?title=Template:Commons_category/doc&action=edit

The VE UI for templates without templatedata needs a usability overhaul. Some simple suggestions to improve usability while keeping the current UI structure:
1. say 'This template does not have VE compatible parameter data', and link to the relevant template:blah page
2. dont say 'No unused parameters' because that message is also misleading
3. Instead of 'Unknown parameter' for '1', say 'parameter number 1' or 'first parameter'
4. pre-populate the template form with a parameter '1', place the user in the parameter value field, but allow the user to rename the parameter name in the left hand list.

A more difficult suggestion is to rethink the way the numbered parameter UI works.  Putting numbers in a UI, without any explanation, is not intuitive or discoverable.  How does a newbie know to enter '1'?  The template documentation pages usually say to put in {{foo|blah}} ; they dont say {{foo|1=blah}} so the typical user doesnt know about '1'.
The steps to reproduce are unclear to me. Also see https://www.mediawiki.org/wiki/How_to_report_a_bug
I am trying to run the test at https://gerrit.wikimedia.org/r/#/c/83966/

In the end it is trying to compare the text that was typed with the text that actually appears on the screen. The test fails, because the Zero width no-break space (U+FEFF) character is added to the string that appears on the screen.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Presumably this is ve.ce.BranchNode.$blockSlugTemplate.
It'd be nice if WikiLove had a javascripty autocomplete for image names (at least local ones)

--------------------------
**Version**: master
**Severity**: enhancement
(In reply to comment #1)
> Any possibility of sharing a UI module with VisualEditor here, rather than
> having two implementations of a media selection browser?

Works for me. Though, ideally would go into core. WikiLove (optionally) depending on VisualEditor could be a potential problem

MassMessage has a simple similar implementation of this, with based on resources/mediawiki/mediawiki.searchSuggest.js in core
Any possibility of sharing a UI module with VisualEditor here, rather than having two implementations of a media selection browser?
Editing of large pages can use a significant amount of memory; a spotcheck that Max did on [[United States]] showed an increase of 121MB usage in Chrome while editing the page.

This is a concern for us for mobile in particular, as today's mobile devices have the amount of memory of computers from several years ago -- most have 1GB or 512MB (or even less), which has to house the operating system, background apps, the web browser, and the *entire* article with a richly annotated DOM.

Possible techniques for reducing memory usage were proposed at the VE mobile meeting yesterday:

* Section editing -- if we only have to load up a single section at a time, large pages won't use up nearly as much memory. Note that on mobile we already divide the page up into sections surrounded by <div>s that can be replaced with the editable surface; the other sections on page might not even be open.

* Limit full annotation processing to areas under active editing -- apparently it should be possible to delay some of the HTML processing on sections or even paragraphs that have not yet been edited. This might also save memory, but needs to be looked into.

--------------------------
**Version**: unspecified
**Severity**: enhancement
This is a high-level tracker bug rather than a blocker; it needs child bugs with more specifics to be nominated as blockers. Consequently, we decided to remove it from the Q3 blockers list at the triage on 2015-02-11.
More specific criteria and numbers are welcome / required here.
Also, should the "Epic" tag be added here?
>>! In T55825#558826, @brion wrote:
> Feel free to move this to 'general' and we'll hang some mobile-specific bugs off it that are more directly actionable.

Have any mobile-specific bugs been identified since 09/2013? Adding task numbers is welcome.
(In reply to comment #2)
> Feel free to move this to 'general' and we'll hang some mobile-specific bugs
> off it that are more directly actionable.

{{Done}}
Feel free to move this to 'general' and we'll hang some mobile-specific bugs off it that are more directly actionable.
Not sure this is a Mobile-specific bug, but yes, very important to make progress here. I think there's likely to be some produce trade-offs that are more appropriate for the Mobile than Desktop experience, though, so certainly some of it will be…
Users seem to expect that the feedback link will automatically supply information, especially the title of the article they're working on.  I'd also like to have the version number they were actually using (cacheing issues) and a link to the user's contibutions.

--------------------------
**Version**: 1.23.0
**Severity**: enhancement
The core feedback tool is (I think intentionally) very generic. If VE needs additional functionality, it should probably extend it.
The feedback tool isn't specific to VisualEditor - moving to the general group for others to see and comment.
(In reply to comment #1)
> Google has a feedback tool for Google+ which lets you "screenshot" the page
> you
> are on and highlight what you think is wrong. Something like that would be
> really cool.

That would be good, but possibly a bit more complicated for us. I wrote [[Wikipedia:Screenshots of Wikipedia]] to help people include screenshots in on-wiki bug reports, so linking prominently to that would be a very easy first step.
Google has a feedback tool for Google+ which lets you "screenshot" the page you are on and highlight what you think is wrong. Something like that would be really cool.
Right now external paste always writes the clipboard as formatted; in some cases, users will want to "Paste Unformatted".

On Mac, there's a standard shortcut for this of Cmd+Shift+V - I'm assuming that Ctrl+Shift+V would be sensible as well.

Would we also need a button? What about for the other standard 3 (Cut/Copy/Paste)?

--------------------------
**Version**: unspecified
**Severity**: enhancement
Change 88224 merged by jenkins-bot:
Plain text paste with paste special

https://gerrit.wikimedia.org/r/88224
Change 88224 had a related patch set uploaded by Esanders:
Plain text paste with paste special

https://gerrit.wikimedia.org/r/88224
(In reply to comment #1)
> ctrl+shift+v in Open Office is "paste special", which gives lots of
> non-default
> options so it doesn't seem out of line. Not sure a separate button is needed
> but if button=shortcut then shift+button should = shift+shortcut

We don't need a button to have a shortcut (but we do for users without a keyboard, or with a limited keyboard that can't do shortcuts, like tablet users).

> In general I think its best to cut/copy richly to the clipboard and let the
> target deal with the formatting. I don't know whether this view is common or
> uncommon though,

I agree personally, but people have asked for it a few times and it's a not-hard change for us to make when pasting from the clipboard.
ctrl+shift+v in Open Office is "paste special", which gives lots of non-default options so it doesn't seem out of line. Not sure a separate button is needed but if button=shortcut then shift+button should = shift+shortcut

In general I think its best to cut/copy richly to the clipboard and let the target deal with the formatting. I don't know whether this view is common or uncommon though,
When you open an existing reference in VE that only consists of one template the main use case should be that you want to edit that template. But now you need to first select it and then klick on the puzzle piece.

Instead I suggest that in that case, you get forwarded to the template editor directly after choosing to open the reference editor without having to do it manually.

--------------------------
**Version**: unspecified
**Severity**: enhancement
This was done (for citation templates) in the new citation system.
The VisualEditor and ULS MediaWiki extensions have recently been blessed with QA browser tests.  We would need them to be in the Contint Jenkins and triggered by Zuul whenever a patchset is submitted as well as in the gate-and-submit pipeline.

That needs several step:

- describe the jobs in Jenkins
- add the triggers in Zuul configuration

--------------------------
**Version**: wmf-deployment
**Severity**: enhancement
As far as I know this is resolved a long time ago. Please reopen if there is anything left to be done.
Have to make the following extension to trigger the job on patchset proposal:

CentralAuth
CentralNotice
Math
PageTriage
WikiLove
Change 341506 merged by jenkins-bot:
[integration/config] Add experimental mwext-mw-selenium-jessie

[[https://gerrit.wikimedia.org/r/341506]]
Change 341506 had a related patch set uploaded (by hashar):
[integration/config] Add experimental mwext-mw-selenium-jessie

[[https://gerrit.wikimedia.org/r/341506]]
@dduvall made it possible to trigger selenium tests when a new patchset is triggered which unblocked a few tasks.

Originally we had this blocked on T47499 which comes from Bugzilla and was the parent tracking task / epic for the #continuous-integration-scaling project.  It has progressed and we are not so far from having the jobs run on Nodepool.  That is {T137112} which is more specific than the legacy epic task and better reflect the intention.
For mediawiki/extensions/VisualEditor no browser tests are run for patch upload nor merge, so it probably still needs to be done, possibly also for a few other closed blockers.
>>! In T55697#1646493, @Jdlrobson wrote:
> The description is a little confusing. Does VisualEditor do this already? I can't see the selenium job on a per commit basis....

Still interested in the answer to this.
The description is a little confusing. Does VisualEditor do this already? I can't see the selenium job on a per commit basis....
I have closed a few tasks that were requesting browser tests to be triggered on patch proposal. There is no point in keeping them open until we are actually ready to trigger such jobs.
Per a discussion we had in the Releng weekly checkin, triggering browser tests from Gerrit would need the disposable VMs. We would also need to setup MediaWiki and the required backend services such as Parsoid (and more as needed).
(In reply to Matthew Flaschen from comment #7)
<snip>
> What's the status of this?  Are there any projects that have browser tests
> triggering on each change (even if non-voting)?
> 
> If not, can you outline the blockers?

It is not hold, mostly because we lack resources to do the integration / make them faster.  On top of my head:

* make them faster
* runnable in parallel and aggregate the results
* rethink the way we setup the environment to run the browser tests, it is currently a huge shell snippet which is copy pasted in different place


Feel free to take the leadership. Zeljkof and Nik Everett would be able to assist.  I can offer reviews / guidances as well.
(In reply to Antoine "hashar" Musso from comment #6)
> This is no more a top priority.  We have most browsertests run twice per day
> instead.
> 
> We will eventually managed to get them added in Gerrit, but there is a bit
> more work that needs to be done first.

What's the status of this?  Are there any projects that have browser tests triggering on each change (even if non-voting)?

If not, can you outline the blockers?
This is no more a top priority.  We have most browsertests run twice per day instead.

We will eventually managed to get them added in Gerrit, but there is a bit more work that needs to be done first.
Quick status update:

- ULS has browser tests being triggered albeit lot of tests ends up being
- MobileFrontend has a patch that has browser tests passing locally against a freshly installed wiki. Pending review / merge then I will add the browser tests.
- VisualEditor browser tests depends on some work to be done to safely start and stop a Parsoid daemon for each test.

I am focusing this week on integrating Parsoid daemon in Jenkins
The Jenkins jobo template in https://gerrit.wikimedia.org/r/#/c/86868/ would let us trigger tests.
See also the Wiki page https://www.mediawiki.org/wiki/Continuous_integration/Browser_tests
We will go with ULS first since we have a good experience interacting with the i18n team and they are in European timezone just like Zeljko and I.
raise priority, add 'tracking' in summary.
Need some UI to add/remove/edit the key value pairs.

--------------------------
**Version**: unspecified
**Severity**: enhancement
As an update, this is done for editing, but not adding/removing.
--------------------------
**Version**: unspecified
**Severity**: enhancement
Adam Cuerden says,  "I believe the VE team intends to have a some one click solutions in the near future, including adding templates of your choice to a bar? Although I'd hope there'd also be a few automatic lists you could choose to pull up - cleanup templates, etc."

So, it would be really comfy for users if the template editor, beyond being able to let them select what they need by typing the name, asked "Which kind of template do you want to add?" and provided lists of the most used/popular ones, divided per set (cleanup templates, citation templates and so on).
Or just a way to store one's most used choices.
Thanks.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
{T52458}
{T109253} looks like a similar request.
>>! In T55590#1673809, @Elitre wrote:
> @James_F, is this something a gadget could easily achieve?

It could, but I'd rather avoid people adding new things to the toolbar //ad hoc//. We really need a design for this that can scale.
@James_F, is this something a gadget could easily achieve?
Mmm... I don't know if it's a //blocker//, but it is quite desirable.
I suggest that per Amire80, cross-wiki templates be made a blocker bug for this feature.

It's just too much widely duplicated work to do otherwise.
It would really be appreciated in wikipedia's sister projects to have a costumizable common templates dropdown as there is with the citation tool.
The more I use VE, the more I miss such a feature.

The challenge with it is that it's badly project-specific, so community editors will need an easy way to customize this list, but something like this already done for citation templates, so it should be possible for other templates as well.

This is one issue for which it's REALLY worth poking around Wikimedia projects in different languages to ask them what would they like in such a feature, and what current features they currently have that are similar to this. For example, the Hebrew Wikipedia has the Templateslist script ( https://he.wikipedia.org/wiki/MediaWiki:Templateslist.js ), which adds a dropdown with common templates to the Vector editing toolbar, and users there complain that they don't want to use VE because VE doesn't have such a list.

I'm not rushing - this requires proper research, understanding and design, but it should be somewhere in the roadmap.
The more I use VE, the more I miss such a feature.

The challenge with it is that it's badly project-specific, so community editors will need an easy way to customize this list, but something like is already done for citation templates, so it should be possible for other templates as well.

This is one issue for which it's REALLY worth poking around Wikimedia projects in different languages to ask them what would they like in such a feature, and what current features they currently have that are similar to this. For example, the Hebrew Wikipedia has the Templateslist script ( https://he.wikipedia.org/wiki/MediaWiki:Templateslist.js ), which adds a dropdown with common templates to the Vector editing toolbar, and users there complain that they don't want to use VE because VE doesn't have such a list.

I'm not rushing - this requires proper research, understanding and design, but it should be somewhere in the roadmap.
The more I use VE, the more I miss such feature.

The challenge with it is that it's badly project-specific, so community editors will need an easy way to customize this list, but something like is already done for citation templates, so it should be possible for other templates as well.

This is one issue for which it's REALLY worth poking around Wikimedia projects in different languages to ask them what would they like in such a feature, and what current features they currently have that are similar to this. For example, the Hebrew Wikipedia has the Templateslist script ( https://he.wikipedia.org/wiki/MediaWiki:Templateslist.js ), which adds a dropdown with common templates to the Vector editing toolbar, and users there complain that they don't want to use VE because VE doesn't have such a list.

I'm not rushing - this requires proper research, understanding and design, but it should be somewhere in the roadmap.
*** Bug 69787 has been marked as a duplicate of this bug. ***
The main priority is a (very limited) suggestion of quick-inserting templates when in a reference, which is bug 50458.

This is certainly a possibility, but would probably want to be context-specific (so it only suggests clean-up templates when your cursors is at the top of the page; only suggests stubs when at the bottom; etc.).
Created attachment 13203
A very quick mockup for quick access buttons

One idea I've had is to use some of the empty vertical space on the right of the dialog for some quick access buttons. See attachment for a 2 minute mockup of how this might look. The labels I've used in the mockup are not necessarily the right ones, they're just ones I quickly thought of.

Either the buttons could be set to allow one-click access to certain templates, or to be drop-down lists of similar related ones. Possibly the two could be combined - click to get the top item in the list, or click and hold for a moment to open the drop down for short list (almost certainly no more than 10, probably less than that) of similar ones.

Selecting any of these would have the same effect as typing the name into the search field, selecting it, and clicking to add the template.

A second idea would be to change the transclusion editor button from a simple button to a combined button/drop down as I described above. Here you could only have a single list but it could be longer. Selecting a template from this list would load the transclusion editor with that template preloaded into it.

Some way of customising either/both lists (beyond recently used) would be useful too.

**Attached**: {F11786}
As discussed at bug 50452 comment 9 it would be very useful for a page to have associated metadata about its title.

For most pages and by default* this would be identical to the all-lowercase rendering of its stored title, but where pages correctly start with a lowercase letter (on wikis where the first character is case insensitive), contain special characters or conflict with interwikis/namespaces, etc. the metadata would record the correct page title. It could also be used for titles that should be italicised.
e.g. on en.wp:
Page Title         - Correct Title
[[IPad]]           - iPad
[[Benzo(a)pyrene]] - Benzo[a]pyrene
[[Pilot No. 5]]    - Pilot #5
[[D Ream]]         - D:Ream
[[Computer]]       - computer [indicating a common noun]
[[Amy Studt]]      - Amy Studt [indicating the title is proper noun]
[[Animal Farm]]    - <i>Animal Farm</i> [italicised proper noun, the tags are not literal]

The displayed title would be taken from this metadata and as such would effectively supercede the DISPLAYTITLE magic word and the [[template:correct title]] family of templates (and the equivalents on other wikis).

VisualEditor and any other tools that aid linking would be able to read the metadata and use it to determine what the default displayed name should be when linking to that article.

*Actually the default should be configurable as I guess languages like German that capitalise common nouns may want the default to be capitalised and the upper/lower case distinction probably doesn't make sense in all scripts.

--------------------------
**Version**: 1.22.0
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50452
https://bugzilla.wikimedia.org/show_bug.cgi?id=56868
https://bugzilla.wikimedia.org/show_bug.cgi?id=49076
>The advantage of storing this metadata is that it allows for a large amount of
>semantic information about the title which can be used not only for linking but
>potentially for customised display options and doubtless more that I haven't
>thought of.

That's certainly true. 
-----

My initial reaction is that the user is probably in a better position to decide how to capitalize/italicize the title in a given context than software would be, but if such formatting of titles is consistent, I suppose it could make sense to automatically do it.

>I'm told that it needs to be moved out of templates for VE to support.

It should not need that to *use* the data. To effectively edit the displaytitle data, it may need that.

>I don't
>know why.
>More philosophical, but I was under the impression that the long term goal was
>to separate metadata from content?

Some folks have that goal. Personally I think that doing so would reduce the power of mediawiki significantly, although my opinion may be a minority one. (And probably offtopic for this bug report)
> 
> The idea is not just to store what the title should be displayed as when it
> doesn't match the default, but to record what the title actually is in all
> cases. Presently there is afaik no way to tell that for example [[Parish
> ale]]
> is a common noun, [[Parish Walk]] is a proper noun and [[Parish Bar]] is a
> proper noun that should be italicised.

I don't think I properly understand the problem this is trying to solve. To be honest it sounds like a solution looking for a problem.

Basically what I'm asking:
*Does it really make sense to store what type of word the title is, instead of just how to display it. Mapping types of words -> how to display them sounds like something that would vary a lot by culture (Or even in english wikis that have different traditions)
*What problem (Other than perhaps ideological) does moving the data out of templates actually solve?
(In reply to comment #1)
> I'm confused. Is this asking to move {{DISPLAYTITLE:...}} out of wikitext?
> 
> Displaytitle is a form of metadata, and it gets stored in the db separately,
> and can be queried separately, etc.

Chris has it right - it's effectively asking to implement DISPLAYTITLE properly, rather than DISPLAYTITLEIFNEEDEDTOBEANOVERRIDE.
According to James F at  bug 50452 comment 9 "for this to be used in VisualEditor it would need to be a proper feature and not one hacked into a template"

The idea is not just to store what the title should be displayed as when it doesn't match the default, but to record what the title actually is in all cases. Presently there is afaik no way to tell that for example [[Parish ale]] is a common noun, [[Parish Walk]] is a proper noun and [[Parish Bar]] is a proper noun that should be italicised.
I'm confused. Is this asking to move {{DISPLAYTITLE:...}} out of wikitext?

Displaytitle is a form of metadata, and it gets stored in the db separately, and can be queried separately, etc.
If you start to add a link, and change your mind (e.g., you realized that you have the wrong word selected), there is no way to simply cancel adding a link.  You have to remove the link with the trashcan icon.

Steps to reproduce:

1. Select any word.
2. Press ctrl-K to enter link tool.
3. Attempt to cancel the link by closing the unwanted link tool dialog box using Esc key or the < button.
4. Discover that VisualEditor linked the word anyway.

If the Escape key and "Cancel" button are worthless for escaping/going back/cancelling, then they shouldn't be present or have any effect.

({T93749} altered this to re-add the cancel/close button.)
Change 209695 merged by jenkins-bot:
Only apply annotations if 'done' is clicked

[[https://gerrit.wikimedia.org/r/209695]]
Change 209695 had a related patch set uploaded (by Jforrester):
Only apply annotations if 'done' is clicked

[[https://gerrit.wikimedia.org/r/209695]]
We now have a "Remove" button, which is nice, but since the link is automatically created when you open the inspector, most people don't know that if you did nothing and want nothing to make the link, then you still need to "Remove" the link that you didn't know you already made.
Maybe we should label the "cancel" button "remove" or somesuch? I don't know…
*** Bug 56431 has been marked as a duplicate of this bug. ***
I'm not sure that the < button is going to be interpreted as "close and apply".  It looks to me a lot more like a "get me out of here" or "go back (to how things were)" button.  I think that it ought to be treated the same as an Escape key.
I'm getting very frustrated with the current behaviour of the link tool in this regard.

When I am in the link dialog and I press escape I want the dialog to exit and leave the page in the state it was in before I loaded the dialog, ignoring any changes I have made and whether I was adding or modifying a link.

The current behaviour of the < button (close and apply the current state) and the rubbish bin (close and remove link) are correct. 

There also though needs to be a button/icon though that closes and cancels all changes made (this is bug 52462).
This is due to fixing bug 51065; we can either have one or the other, but not both. I'm minded to stick with the behaviour as it now is, as it's less confusing that the previous form was.

Consequently, marking as WONTFIX. Very happy to be argued around to the opposite behaviour, however.
The Parsoid team is considering a simplification of the different mw:ExtLink/* variants to just a single mw:ExtLink type. 

For most types this should not make much of a difference to VE, but for auto-numbered external links ([http://example.com]) it might, so I am looking for your input. I did some testing on https://www.mediawiki.org/wiki/User:GWicke/TestNumberedLinks. Changes to the text lead to corruption as in this diff:

https://www.mediawiki.org/w/index.php?title=User%3AGWicke%2FTestNumberedLinks&diff=772988&oldid=772987

There also does not seem to be any automatic re-numbering when a numbered link is changed into a plain external link.

What are you plans for the handling of numbered links?

--------------------------
**Version**: unspecified
**Severity**: enhancement
*** Bug 57755 has been marked as a duplicate of this bug. ***
Change 98114 merged by jenkins-bot:
Make autonumbered external links inspectable

https://gerrit.wikimedia.org/r/98114
Change 98114 had a related patch set uploaded by Catrope:
Make autonumbered external links inspectable

https://gerrit.wikimedia.org/r/98114
*** Bug 57419 has been marked as a duplicate of this bug. ***
Though the code in gerrit 90432 is merged, that just adjusts how VisualEditor works with auto-numbered links to support Parsoid's changed behaviour - this bug remains undone. Resetting to ASSIGNED.
Change 90432 merged by jenkins-bot:
Add a node type for numbered external links

https://gerrit.wikimedia.org/r/90432
Change 90432 had a related patch set uploaded by Catrope:
Add a node type for numbered external links

https://gerrit.wikimedia.org/r/90432
I guess that means that we can go ahead and drop the explicit numbering in Parsoid in favor of pure CSS. We will also drop the /Numbered typeof suffix along with the other mw:ExtLink suffixes.

You will then get empty links with typeof="mw:ExtLink" as in this example.
* Supports:
  - http://caniuse.com/#feat=css-sel3 (CSS3 :empty)
  - http://caniuse.com/#feat=css-counters (counter-increment)
  - http://caniuse.com/#feat=css-gencontent (:before)

* Test case: http://jsfiddle.net/wTNc4/
  - Works fine in IE9: http://cl.ly/image/2r2L1F3U2X0r

I wonder why it didn't work for James?
(In reply to comment #5)
> Please test this test with IE as well. I am hopeful that it works with IE >=
> 8.

In IE9 you get "not empty" but none of the other four links.

In IE10 and IE11 you get all five links as expected.
Yeah, you need the UI for the creation of empty links. But there is no need to deal with renumbering etc in VE, which simplifies things a lot.

Please test this test with IE as well. I am hopeful that it works with IE >= 8.
(In reply to comment #3)
> With a href set this actually works as expected in FF and Chrome:

[…]

> So it seems that we can actually implement auto-numbered links in pure CSS.

That's great. :-)

We will still need a way of creating an auto-numbered external link (rather than just being able to copy and alter them), but that's our problem. :-)
With a href set this actually works as expected in FF and Chrome:

<html><head>
<style>
body {
    counter-reset: numberedlink;
}
a[typeof~="mw:ExtLink"]:empty:after {
    content: "[" counter(numberedlink) "]";
    counter-increment: numberedlink;
}
</style>
</head>
<body>
<a href="test" typeof="mw:ExtLink"></a>
<a href="test" typeof="mw:ExtLink">not empty</a>
<a href="test" typeof="mw:ExtLink"></a>
<a href="test" typeof="mw:ExtLink"></a>
<a href="test" typeof="mw:ExtLink"></a>
</body>
</html>

So it seems that we can actually implement auto-numbered links in pure CSS.
See http://www.w3.org/TR/css3-content/ for the relevant spec.
Maybe this could even be handled in CSS, somewhat like this example:

<html><head>
<style>
body {
    color: red;
    counter-reset: numberedlink;
}
a[typeof~="mw:ExtLink"]:empty:before {
    content: "[" counter(numberedlink) "]";
    counter-increment: numberedlink;
}
</style>
</head>
<body>
<a typeof="mw:ExtLink"></a>
<a typeof="mw:ExtLink"></a>
<a typeof="mw:ExtLink"></a>
<a typeof="mw:ExtLink"></a>
</body>
</html>

Problems in this simple experiment:

* Links are not clickable, and (maybe related)
* the content can only be generated :before and :after, but not inside the empty link.
Reporting user comment, some formatting is mine:
<<I made this http://en.wikipedia.org/wiki/User:Atethnekos/sandbox4 as a demonstration. 
1) If the hlist template is used in an infobox or a table like on the page, when I go to VE, the list will end up be extended far into the page. 
2) If it's used with [[File:Image]] as on the page, the list will end up being cut off, and then some weird things will happen if I try to click on the hlist template (e.g., the page will be extended to right and my browser will give a horizontal scroll bar). FF 23.0.1 Win7--Atethnekos 19:33, 25 August 2013 (UTC) >>

I edited his sandbox a couple of times. In this version http://en.wikipedia.org/w/index.php?title=User:Atethnekos/sandbox4&oldid=570256245&veaction=edit the pics of the masks are moved to the left: the caption of the first one is not cut out, but you can't edit the pics at all since VE will consider them as a non editable block.
I can't reproduce the horizontal bar and I can correctly edit the hlist template inside the mask pic caption with both FF and Chrome.
Thanks.

--------------------------
**Version**: unspecified
**Severity**: normal
Same as #51959, but it keeps hapenning on frwiki: some texts that look like telephone numbers are changed in <a href="tel:...">...</a>.

http://fr.wikipedia.org/w/index.php?title=Les_Visiteurs_(film,_1993)&diff=95954243&oldid=95559259

http://fr.wikipedia.org/w/index.php?title=Transformers_3_:_La_Face_cach%C3%A9e_de_la_Lune&diff=96093057&oldid=95089445

--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: other
**Platform**: Other
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51959
On re-testing this is now fixed.
(In reply to Elitre from comment #10)
> So, James, is this what we are going to do, adding this line? Thanks.

Yes, experimentation as to what triggers Safari to break things, and what changes cause it to stop breaking, is needed.
So, James, is this what we are going to do, adding this line? Thanks.
The answer appears to be to have:

  <meta name = "format-detection" content = "telephone=no">

… in the <head> of the page. Unfortunately, we probably don't want to switch this off for all MediaWiki pages, so instead we will need to experiment to see if JS inserting it into there makes the behaviour go away.
(In reply to Jesús Martínez Novo (Ciencia Al Poder) from comment #5)
> Hmmm, it seems I was close enough ;)
> 
> "In Safari on iOS, telephone number detection is on by default" according to
> [1]. There it says that adding <meta name="format-detection"
> content="telephone=no"/> would prevent that autolink feature, that may
> interfere with the content editable component of the editor.
> 
> ----
> 
> [1]
> https://developer.apple.com/library/safari/featuredarticles/
> iPhoneURLScheme_Reference/Articles/PhoneLinks.html

That URL is no longer valid. This is the new one:

https://developer.apple.com/library/ios/featuredarticles/iPhoneURLScheme_Reference/PhoneLinks/PhoneLinks.html
And, yes, I really think that VE/Parsoid should find a way to detect changes from browser extensions and neutralize them, otherwise it will be an endless battle to have every extension modified, updated, ...
(In reply to comment #4)
> This might be a bug in Safari rather than VE, but even if it is it would be
> useful for VE (or Parsoid?) to detect the changes and neutralise them. It is
> unlikely that Wikipedia would need href=tel: links but I can see they might
> be
> useful in environments like the contact pages on the Foundation wiki, so
> stripping such links completely mightn't be the optimal solution?

Isn't the <a> tag deactivated on the Foundation wiki also, as it is on Wikipedia ?
On Wikipedia, the <a href="tel:...">...</a> doesn't produce a link because MediaWiki renders the <a> tag as text.

Even if "tel:" was needed on any wiki, it would be better handled as an external link [tel:... ...] than as a <a> tag.
Hmmm, it seems I was close enough ;)

"In Safari on iOS, telephone number detection is on by default" according to [1]. There it says that adding <meta name="format-detection" content="telephone=no"/> would prevent that autolink feature, that may interfere with the content editable component of the editor.

----

[1] https://developer.apple.com/library/safari/featuredarticles/iPhoneURLScheme_Reference/Articles/PhoneLinks.html
Bug 51959 was also iPad/Safari and I've not seen any reports of it being reproducible on any other system so I've adjusted the bug summary accordingly.

This might be a bug in Safari rather than VE, but even if it is it would be useful for VE (or Parsoid?) to detect the changes and neutralise them. It is unlikely that Wikipedia would need href=tel: links but I can see they might be useful in environments like the contact pages on the Foundation wiki, so stripping such links completely mightn't be the optimal solution?
For the first one, iPad with Safari.
No answer for the seconde one.
May it be caused by a Skype plugin for the browser, that usually make those telephone-looking numbers into a clickable link to make a call through Skype?

http://stackoverflow.com/questions/3032427/how-to-prevent-phone-numbers-to-be-converted-into-skype-links
I can't reproduce it on either page using Firefox 23 / Linux.

Do you know what OS/browser those editors were using?
EverNote Web Clipper has a problem with the editable area and inserts:

<style id="_clearly_component__css" type="text/css">#next_pages_container { width: 5px; hight: 5px; position: absolute; top: -100px; left: -100px; z-index: 2147483647 !important; } </style><div id="_clearly_component__next_pages_container"></div>

Triggering: https://en.wikipedia.org/wiki/Special:AbuseFilter/345

--------------------------
**Version**: unspecified
**Severity**: minor
Change 163961 merged by jenkins-bot:
Remove certain blacklisted elements when getting HTML from document

https://gerrit.wikimedia.org/r/163961
Change 163961 had a related patch set uploaded by Alex Monk:
Remove certain blacklisted elements when getting HTML from document

https://gerrit.wikimedia.org/r/163961
Derk-Jan, did you hear back from Evernote?
Evernote support ticket #253866
I submitted a report with Evernote trough their API developers platform.

http://dev.evernote.com/support/faq.php#filebug

Not totally the right forum, but I suspect that was the easiest way to get developer level support.
Screeshot of post hiero editor

Safari 6

I opened the editor inline, didn't do anything, pressed the back arrow, the editor closed and inserted a newline.

--------------------------
**Version**: unspecified
**Severity**: normal

**Attached**: {F11956}
**Author:** `lucashokanson`

**Description:**
It would be extraordinarily useful to mimic Imgur.com's clipboard based uploader.  Upon visiting the upload page, you would simply Paste - command/control v or click a button to use your clipboard's contents.  This would then upload the file and return to you the standard file:____ page.  

In addition to this, if this functionality is built it, it would even more useful to streamline this into the page editor as well. A simple button click could pop up a prompt and upon upload return the proper image reference in your article.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=37932
https://bugzilla.wikimedia.org/show_bug.cgi?id=65670
I'm going to move this to upload wizard I suppose.
There's an ambition to add this to VisualEditor in time - see bug 37932, which I've added as a see also - but not sure on plans for doing this for the regular wikitext editor.
In Chrome, edit any page in https://test2.wikipedia.org

Click Transclusion, type 's' into input box.
Result is a list of suggestions that begin with "Smaller" and "Sectstub"

In Firefox, edit any page in https://test2.wikipedia.org

Click Transclusion, type 's' into input box.
Result is a list of suggestions that begin with "Succession box" and "South America"

This suggests that at least one list of Template suggestions is absolutely incorrect.

--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=58406
*** Bug 70219 has been marked as a duplicate of this bug. ***
This is caused by the search back end that supplies the suggestions; I don't think it alters by user/browser so much as over time (though it's cached after the first request for a bit). Not sure if this is a "bug" per se…
https://he.wikipedia.org/wiki/%D7%A8%D7%90%D7%A9%D7%95%D7%9F_%D7%9C%D7%A6%D7%99%D7%95%D7%9F?veaction=edit

The template on the left has a pie chart (see in view mode in the extendable green section) -- but in edit mode it's all jumbled.

--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
{T53932}
{T53166}
The issue as filed was resolved long time ago (see parent bug T52577), I filed T96667 to track the issue of oversized highlights.
There are no screenshots here to show how it used to be broken, but it seems almost correct now. Only the highlight is displayed incorrectly.

(The infobox also looks a bit borked, which is a Parsoid issue I filed as T96529.)

{F117709}
Testing the hieroglyphics feature on MW.org just now:

1. Open VE and select some text
2. Click "Hieroglyphics" button

Why can I "apply" hieroglyphics to a run of text, as if it was a kind of formatting? Doesn't make any sense.

3. Type some hiero codes (e.g. G26-t:Z4-A40) in the box
4. Leave the popup (by clicking away/clicking the < button)

The popup goes blank and can't be dismissed (Firefox 23).
Also notice that no hieroglyphics are seen.

5. Review changes.

The hiero tag successfully appears in the wikitext, even though it is invisible in VE.

Sorry for three issues in one bug, but I guess you guys can figure this out.

--------------------------
**Version**: unspecified
**Severity**: minor
I can't reproduce any of these issues in Chrome or Firefox. Please re-open with details if you can.
The second and third issues are now fixed. However, you can still "apply" hieroglyphics (and LaTeX) to a run of text: this behavior is confusing and nonsensical.
Some users on en.wp consider it a bug that VE shows the top of the page after you edit a "section", and demand instead that, as VE auto-scrolls to the relevant section when you click Edit, it does the same after you save. Thanks.

--------------------------
**Version**: unspecified
**Severity**: enhancement
*** Bug 54645 has been marked as a duplicate of this bug. ***
Not sure, is https://bugzilla.wikimedia.org/show_bug.cgi?id=52566 a dupe?
If you have the preference set to "Edit pages on double click", then double-clicking on a word while you're already in VisualEditor tries to re-open the page so you can edit it.

--------------------------
**Version**: unspecified
**Severity**: minor
**URL**: http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Double-click_asks_if_you_want_to_leave_page
Change 162968 merged by jenkins-bot:
Stop "Edit pages on double click" from affecting VE

https://gerrit.wikimedia.org/r/162968
Change 162968 had a related patch set uploaded by Alex Monk:
Stop "Edit pages on double click" from affecting VE

https://gerrit.wikimedia.org/r/162968
Is this now fixed given the above being merged?
Change 150391 merged by Bartosz Dziewoński:
Make mediawiki.action.view.dblClickEdit recheck preference

https://gerrit.wikimedia.org/r/150391
Change 150391 had a related patch set uploaded by Alex Monk:
Add JS hook to allow extensions to prevent double click from changing to action=edit

https://gerrit.wikimedia.org/r/150391
fwiw 'Enable section editing by right clicking on section titles' is active within VE
For variety, I confirmed on Chrome/Linux ;-)
This was reported in Mozilla 23 on Windows 8, and I reproduced it in Safari 6 on Mac OS 10.7.5, so it's probably universal.
I am editing a page and something untoward happens.  To review changes, I now have to click "Save page", which is sort of like a sign above a circular saw saying, "To unplug, please saw through wall.  Thank you for your cooperation."

:p

Perhaps hovering over the "save page" button could drop down alternative actions, such as "save draft of changes", "review..." etc.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Firstly, hover is something we avoid using in VisualEditor as it means the functionality isn't available for those using a touch interface. I don't think this is "major" - closer to "minor" - but either way it's an enhancement.

Also, there's an existing bug to show what changes you've made as you enter them (e.g. by highlighting the background of the new text, like Microsoft Word's "tracked changes" view): bug 37931.
See reported diff on fr.wp
https://fr.wikipedia.org/w/index.php?title=Debra_Winger&action=historysubmit&diff=95823433&oldid=94552186

The js is from Foxlingo but the liberal sprinkling of nowikis is from VE or Parsoid.

PrimeHunter at en.wp reports that a Google search for FoxlingoJS reveals several other internet forums are suffering the same problems.

--------------------------
**Version**: unspecified
**Severity**: minor
Change 163961 merged by jenkins-bot:
Remove certain blacklisted elements when getting HTML from document

https://gerrit.wikimedia.org/r/163961
Change 163961 had a related patch set uploaded by Alex Monk:
Remove certain blacklisted elements when getting HTML from document

https://gerrit.wikimedia.org/r/163961
At T53903,  Elitre said:

> A user at it.wp wonders: if VE could pre-populate the summary box, could it
> also auto-add the text that was added, in case of very short additions? i.e.,
> if someone added a parameter to a template, could it automatically detect
> what was added and write it in the edit summary? Thanks.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**: T53903, T50274
GMail's keyboard shortcuts help page

Similar to GMail's modal when '?' is pressed.

--------------------------
**Version**: unspecified
**Severity**: enhancement

**Attached**: {F11100}
Change 98517 merged by jenkins-bot:
Keyboard shortcuts MW integration

https://gerrit.wikimedia.org/r/98517
Change 107153 merged by jenkins-bot:
Keyboard shortcuts dialog

https://gerrit.wikimedia.org/r/107153
Change 107153 had a related patch set uploaded by Esanders:
WIP Keyboard shortcuts dialog

https://gerrit.wikimedia.org/r/107153
Change 98517 had a related patch set uploaded by Esanders:
WIP Keyboard shortcuts dialog

https://gerrit.wikimedia.org/r/98517
At https://en.wikipedia.org/w/index.php?title=Judi_Dench&curid=85432&diff=568314406&oldid=568147939 the article was top and tailed with
<embed type="application/x-datavault" width="0" height="0" />

Searching seems to suggest the most likely cause is the "DataVault" password manager browser plugin

--------------------------
**Version**: unspecified
**Severity**: minor
Change 163961 merged by jenkins-bot:
Remove certain blacklisted elements when getting HTML from document

https://gerrit.wikimedia.org/r/163961
Change 163961 had a related patch set uploaded by Alex Monk:
Remove certain blacklisted elements when getting HTML from document

https://gerrit.wikimedia.org/r/163961
Did you get anything back, Derk-Jan?
I've send an email to their support department. Let's hope it helps.
A user at it.wp asks if, in the long term, it will be possible to edit templates directly (i.e., infoboxes), without the transclusion dialog, as if one was changing something in a table. Thanks.

--------------------------
**Version**: unspecified
**Severity**: enhancement
*** This bug has been marked as a duplicate of bug 50182 ***
<< http://en.wikipedia.org/wiki/File:GreatNurse.jpeg is a headshot of Virginia Henderson that was uploaded to Commons yesterday. VisualEditor's image feature can't find it, and won't accept file names that it doesn't believe exist. WhatamIdoing (talk) 00:17, 13 August 2013 (UTC) >>

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=37578
*** Bug 52218 has been marked as a duplicate of this bug. ***
Marking WONTFIX as this is inherently fixed by CirrusSearch and lsearchd has been end of life'd and won't be improved further.
*** Bug 54777 has been marked as a duplicate of this bug. ***
The good news: CirrusSearch is updated a few seconds after a page is added, changed, or deleted.
The bad news: it isn't ready yet!
The image now comes up in the search result - this is probably a delay in the speed with which the search index is updated.
At https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=568194420#I_can.27t_edit_the_references it has been proposed that it would be helpful to editors if they could edit references in the reference list, as well as where they appear inline.

"As just about every object you see on a page is directly editable with the VE, of course having the reflist not editable is counter-intuitive. "

This proposal would make T54736 either unnecessary or just a "workaround"/interim measure, depending on the timescale to implement.

--------------------------

#2 in the 2023 wishlist: https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2023/Citations/Allow_citations_to_be_edited_in_the_references_section_with_VisualEditor
[[https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Questions_techniques/semaine_28_2016#Impossibilt.C3.A9_d.27apporter_des_corrections_dans_les_sections_Notes_et_r.C3.A9f.C3.A9rences|New feedback from a user]] (a beginner) who wants to change a reference rom the reflist while editing with VE.
The alphabetising problem could perhaps be reduced by making the references only limitedly editable. i.e. Only individually editable in a dialog that allows for the editing of the template/parameters only.
Adam Cuerdon comments:
    I'd suggest popping up a note telling the user what he or she is doing at least the first time, though. Something like "This reference is used to document the source of text in the article. You can also edit it by clicking on the number after the text. Please make sure that you don't accidentally break documentation with your edit. Thanks for your work!"
    We don't want to have a situation where newbies, for example, try to alphabetise the list, say.

Personally, I'm not sure "documentation" is the right word, but otherwise it seems like a good suggestion.
en.wp user JmCor reports that in Firefox on Windows 7 the shortcut "<shift><alt>V (show the changes), which stopped working when the Visual Editor was introduced: currently, <shift><alt>V simply positions the cursor on the "Show the changes" button."

I can confirm this also occurs in Firefox 23 on Linux.
Yes Ed, but only when you're on the content page.
alt+shift+v appears to launch VE now we have editor switching (from duplicate T130899)
(In reply to Lejonel from comment #4)
> In other namespaces focus is always on "show changes"
> button, but the shortcut does not actually click the button. That is because
> the HTML still contains a hidden "visual edit" tab with the same shortcut.

This is changing (bug 64142)
**dng032** wrote:

Results of testing in Wikipedias about a week ago:

("Positions" means that focus changes to the "Show changes" button, but does not actually show the changes)

Catalan : positions
German : shows dif
French : positions
Greek : positions
English : shows dif
Spanish : shows dif
Hungarian : positions
Italian : warns about not saving
Japanese : shows dif
Portuguese : positions
Russian : positions
Simple English : positions
Chinese : shows dif

Sorry for being late to react and for not retesting recently. ~~~~
Maybe Visual editor does not need an access key while the normal editor is used? Then one possible solution is to just remove 'v' as access key for visual editor when using the normal wiki editor.

I think removing the access key there should not cause any problems for most users, for two reasons:

1. Since currently "show changes" in wiki editor has the same acces key, neither of the access keys work as they should.
2. In most use cases for Visual editor a user starts visual editting when they are seeing an actual page, not when they are looking at the page in the wiki editor.
*** Bug 52969 has been marked as a duplicate of this bug. ***
Suggestions for a different shortcut for VisualEditor (or show changes) welcome.
This is because the same shortcut is used for multiple actions in the same page. 

For me in Firefox in namespaces with visual editor enabled pressing alt+shift+v once focuses on the "show changes" button, pressing again focus on "visual edit" tab" and further key pressing just changes the focus between the two. In other namespaces focus is always on "show changes" button, but the shortcut does not actually click the button. That is because the HTML still contains a hidden "visual edit" tab with the same shortcut.
**dng032** wrote:

(In reply to comment #2)
> This is definitely related to VisualEditor - the shortcut works when
> VisualEditor is disabled (Safari on Mac 6, Firefox 23 on Linux) and in
> Konqueror on Linux which VE is not enabled for.
> 
> Changing component to VisualEditor accordingly

jmCor: still Windows 7, Firefox 22.0. The component change did not fix the bug on my machine.
This is definitely related to VisualEditor - the shortcut works when VisualEditor is disabled (Safari on Mac 6, Firefox 23 on Linux) and in Konqueror on Linux which VE is not enabled for.

Changing component to VisualEditor accordingly
Adding James to the CC as this might be an artefact of VE, even though it affects the source editor.
The <var> tag is used in many articles for variables, and there are css styling rules for it. An example article is Shading
http://en.wikipedia.org/w/index.php?title=Shading

--------------------------
**Version**: unspecified
**Severity**: enhancement
Change 141605 merged by jenkins-bot:
Split out ve.{dm,ce}.TextStyleAnnotation into parts, add other annotations

https://gerrit.wikimedia.org/r/141605
Change 141605 had a related patch set uploaded by Jforrester:
Split out ve.{dm,ce}.TextStyleAnnotation into parts, add other annotations

https://gerrit.wikimedia.org/r/141605
VisualEditor needs a tool to set/unset font colour.

--------------------------
**Version**: unspecified
**Severity**: enhancement
[[ https://www.mediawiki.org/wiki/Topic:U1chcv4o6odr18kt | Here's a new request for this. ]]
(In reply to Elitre from comment #8)
> Would we need to file a separate bug for background text color?

Background colour isn't really a thing we want to encourage. :-) That would be a distinct piece of work; created as bug 73041.

If you meant surface colouring for objects like table cells or <div>s, that's another piece of work again - bug 52180	for table cells, possibly that bug will need to be split for the wider work.

If you mean the "highlight" / "mark" tool, that's yet another one - bug 64376.
Would we need to file a separate bug for background text color?
(Copied from
https://www.mediawiki.org/wiki/Thread:VisualEditor/Feedback/Textcolor)

Hi there :-)
Just wondering, why there is no feature for "coloring Text". In know, there is a way, to use 'span', but im looking for a feature, with a WYSIWYG-Editor. Any advices, ideas?

Thanks :-)
(In reply to comment #5)
> I think this will be difficult to implement well. I see two concerns:
> 
> * extraneous (noöp) <span>s being left behind in the wikimarkup; and

This is the same as bug 37835 and is trivial for us to trim out.

> * <span>s that specify the color black (bad for accessibility, etc.).

Yes, though we already give people loads of tools that they can (and frequently do) abuse. Technology should serve the community and we should make tools that let them do their job, rather than dictate that they can't do something (or, in this case, that they can but it's hard).

> There may be some generic "clear formatting" button/apparatus to be used to
> mitigate the second point, but I'm still wary.

There's already a "clear formatting" button provided - it would apply its magic to this too.
I think this will be difficult to implement well. I see two concerns:

* extraneous (noöp) <span>s being left behind in the wikimarkup; and
* <span>s that specify the color black (bad for accessibility, etc.).

There may be some generic "clear formatting" button/apparatus to be used to mitigate the second point, but I'm still wary.
(In reply to comment #2)
> Any pros/cons of handling this by wrapping colored text in span with
> appropriate value of style tag?

Yeah, that's what we'll want to do.

We'll want to supply a generic <span> editor (which lets you edit the style="…" tag as raw CSS) at some point, but we'd want to do something about colour sooner (and nicer), I think.
*** Bug 51409 has been marked as a duplicate of this bug. ***
Any pros/cons of handling this by wrapping colored text in span with appropriate value of style tag?
Do we want to do this as a general colour-picker widget, possibly?
**Author:** `sandrobt.wiki`

**Description:**
Here is how to reproduce it, when trying to add a link to the page "Maria" on en.wiki.

1) Select the add link icon and type "maria"
2) Select "Maria", which is at the end of the suggested list
3) Press Enter or the "<" button
4) Save

The link is added to Mariah Carey (which was on the top of the suggested list).
Cf. https://en.wikipedia.org/w/index.php?title=User:Sandrobt/prova&diff=prev&oldid=567641122

Note that this doesn't happen if in 2) you had typed "Maria" (which is the exact title of the page you want to link to).
Cf. https://en.wikipedia.org/w/index.php?title=User:Sandrobt/prova&diff=next&oldid=567641169

The same problem appears in similar situations in it.wiki (for example when adding a link to "Sega" you need to type it exactly like that, since the first option is always SEGA) 

I'm using Firefox 22.0 on Mac OS X 10.6.8.

--------------------------
**Version**: unspecified
**Severity**: normal
In fixing bug 50452 we have changed the behaviour slightly regarding this - not sure if it's still necessary to keep this open?
This happens in every case where:
* the input text case INsensitively matches an entry >= 2nd in the list, AND
* the input text case sensitively does NOT match the title of any in the list, AND
* the user selects the case insensitive match

It doesn't matter whether the text was entered in the link dialog or selected on the editing surface.
**sandrobt.wiki** wrote:

Ok, note taken. Though, a bug that inserts the wrong link in a pretty large variety of situation, despite selecting the correct one and without giving any clue of having done so, is a pretty seriuos problem and has probably alredy produced quite a lot of wrong wikilinks.
[resetting severity, see http://www.mediawiki.org/wiki/Bugzilla/Fields#Severity ]
if the template does not contain explicit "templatedata", the API call should return auto-generated "templatedata" structure, distilled from the template itself.


it's trivial to do - basically parse the template, extract parameter names (including order based, aka 1,2,3), and return "default" templatedata where every param is of type string, without any special attributes (default, required, etc.)

this 15-line enhancement will make VE suddenly useful for templates, without detracting anything from current functionality.

we did this in hewiki with "template param wizard" (the equivalent of VE template editor, for the old wikitext editor), and it enhanced the wizard's functionality tenfold.

regretfully i can't submit a patch - hopefully someone else will be able to do so.

peace.

--------------------------

**See Also**:
{T54135} / https://bugzilla.wikimedia.org/show_bug.cgi?id=52135
Change 257684 abandoned by Eranroz:
Guess parameters when templatedata is missing

[[https://gerrit.wikimedia.org/r/257684]]
Change 257684 had a related patch set uploaded (by Eranroz):
Guess parameters when templatedata is missing

[[https://gerrit.wikimedia.org/r/257684]]
>>! In T54581#1271501, @Krinkle wrote:
> .... Possibly with a warning outputted alongside the object. Similar to how MediaWiki's query api communicates things like "warnings", "normalized", and "badrevids".

maybe so, but maybe it should not be "warning". 
a new field can be added to the record returned by the API, e.g. "synthetic" or somesuch, to indicate tempaltedata was generated synthetically, and the template itself does not contain "templatedata" tag.

peace.
The TemplateData editor now supports scanning the template source code and inferring a list of parameter names to bootstrap the documentation editor.

We can use the same logic server-side to provide a basic TemplateData object for templates lacking it. Possibly with a warning outputted alongside the object. Similar to how MediaWiki's query api communicates things like "warnings", "normalized", and "badrevids".
for many many simple templates, just getting the list of parameter names is enough for even moderately experienced editors. 
the editor may even be well familiar with the template, but she does not necessarily remembers the exact name (case sensitive) of every parameters.


regarding your 2nd use case: are you aware that this tool (prepopulate templatedata editor) is already written and working?

written by wmf volunteer (intern? gsoc student? not sure), [[mw:. User:Mooeypoo]], and works on hewiki for quite some time. 
this tool already includes "import parameters from template" button - last time i checked, it was working quite well. 

see [[mw:MediaWiki:Gadget-templatedata-core.js]], function "importtemplateparams()"

if your comment meant to describe it rather than suggesting to build it, i apologize for the confusion.

bottom line: having templatedata is good, but when it does not exist, just seeing the list of parameters (including unpopulated) is hugely perferrable to not seeing them.

peace.
So this "guess template data" parser would be useful in two cases:

* Consumers of TemplateData (e.g. VisualEditor)

They could pass a parameter to the API of TemplateData to trigger this parser as fallback. The generated data would presumably be flagged in some way to allow consumers to identify them as such.

* TemplateDate editor

A button to prefill the template data (e.g. use the default data as a start and edit from there). This should not be misused to populate <templatedata> tags on a bunch of pages, this is only useful if users provide data beyond what is inferred (the inferred data is unlikely to ever be satisfactory as at best it can provide which parameters exist and maybe which are optional).
(In reply to comment #4)
> i did it long ago, and published it on
> [[en:Wikipedia:WikiProject_User_scripts/Scripts#Scripts]]. the script page on
> enwiki is [[en:User:קיפודנחש/TemplateParamWizard]].

See also
https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)/Archive_103#Template_Parameter_Wizard
(mentioned on bug 39598 comment 1)

> -- "Choices": this allows the designer to declare that a certain parameter
> has
> a fixed set of "legal" values. very useful when the template uses a parameter
> as an input for {{#switch:

Bug 51375.

> -- "Depends on": only expose this field if some other field is not empty.

Bug 50407.
The status was recently changed to "Assigned", but the "Assigned to" field was left as "Nobody". 
is Mr. (or Ms.) "Nobody" a new developer on the team?

peace.
Thanks so much for the nice words, but... 
This entry is about templatedata, not templatewizard.

the information i brought above relating to TW was meant as "what templatedata can learn from TW" - if you'd like to discuss TW and its use on enwiki, it should be discussed on enwiki, not here.

peace.
Thank you so much. It works beautifully. I couldn't test it in Hebrew WP because it is situated in the edit toolbar which was disabled by me because I feel more comfortable to type everything with my keyboard. But anyway, the gadget's performance is smooth even while editing large article like "United States" in English WP. The only few issues I can think of right now after tried it a bit are, I don't feel the toolbar is the proper place for the gadget icon. It deserves a more visible location in the edit page. The other thing I hope to improve is that I need to select the whole markups of existing template from "{{" to "}}" in order to edit it in the Wizard. For large infobox template which has lot of parameters filled, it could be little bit inefficient to trigger. I suggest the end of the selection of the markup extends to the first vertical bar near the template name, so only selecting like this "{{templatename|", works the same way as "{{templatename|foo|bar}}".
Hi kipod. I can't understand Hebrew language and I have some trouble to test it in Hebrew Wikipedia. Can you translate the gadget to English Wikipedia under your own userspace? Thank you.
https://he.wikipedia.org/wiki/Mediawiki:Gadget-TemplateParamWizard.js

the function is called buildParamsRaw() ("data" is the raw template page).

i cannot guarantee that it always works flawlessly, but the wizard works on hewiki  for a while now (more than a year), and i did not get any bug reports (i did have some bug reports for previous versions).

i think it is possible to intentionally create a legal template that will give bad results there: specifically, this function does not take "nowiki" and "noinclude" tags into account.

OTOH, it uses only 9 out of the budget of 15, so you have 6 lines to augment those shortcomings...

more seriously: i assumed the codebase already have non-negligible amount of logic that can be used to distill the parameter list of a template. 

(full disclosure: i too did not believe it can be done without tons of code - Eran Roz showed me the light)
I very much look forward to a link to the part of the hewiki wizard that implements this logic. I very much doubt it can be done (or done well) in 15 lines of code, and I very much doubt it's trivial or even easy to do it well.
To replace a file it is currently neccessary to delete the file from the page and insert the new one.

It would be easier to replace the filename only. This avoids to add caption and file options again.

--------------------------
**Version**: unspecified
**Severity**: enhancement
*** This bug has been marked as a duplicate of bug 51033 ***
I'm not sure there's a great way to merge the experience of adding a media item and the one for editing one, but this seems a reasonable extension.
When VisEd is activated from a section edit link, the focus of the display normally stays on that section.  However, if the user activates from a section edit link while on a diff link (has to be diff of current version), the focus shifts to the top of the page as if the whole page edit link had been pressed.

--------------------------
**Version**: unspecified
**Severity**: minor
Change 131415 merged by jenkins-bot:
Generate PHP VE edit section with correct parameter, vesection

https://gerrit.wikimedia.org/r/131415
Thanks, Matt!
Change 131415 had a related patch set uploaded by Mattflaschen:
Generate PHP VE edit section with correct parameter, vesection

https://gerrit.wikimedia.org/r/131415
This is just a special case.  The general issue is that VE does not navigate to the section when a section edit is initiated with a fresh page load (it does when it uses the AJAX switch to editing without a page load).  For example, https://en.wikipedia.org/w/index.php?title=Earth&veaction=edit&section=6 .  It appears in this case because VE (there is a comment to this effect) uses a new page load to start section editing when it's showing the latest diff (to deal with another issue).

This applies any time the user is sent directly to edit a section via VE.  For the Growth team's current project, we will allow the user to click "Sign up and edit" (including for sections).  This works using the normal signup page, with the returnto and returntoquery parameters.  That means we can not do an AJAX switch.

Besides login/signup, there are other (albeit less common) reasons you might want to link directly to a section edit URL.
Wikis use lots of shortcuts on the talk pages, and it can be quite frustrating for the uninitiated to figure out what WP:MOS, WP:N etc. mean, especially when several are used at once.

Having to click on the link to see that its about the 'Manual of Style' or 'Notability' would be unnecessary, if the same information was available in the tooltip when hovering the link.

--------------------------
**Version**: 1.22.0
**Severity**: enhancement
I was thinking when reading.

Now that you mention it, it would probably be useful for VisualEditor as well, but I think that can be its own bug.

(updating the summary to clarify)
In which exact situation should the tooltip be shown? 
Is this about reading? Editing?
Effectively fixed for dialogs by expedient of not doing this any more…
Has the bug:
- Chrome 29 beta
- Chrome 30 canary
- Safari 6.0.5

Does not have the bug:
- Firefox 22 stable
- Firefox Aurora 24.0a2
Created attachment 13055
Screenshot where it is dirty and broken (VE copied it from <link>)

**Attached**: {F11260}
en.wp user Wouterstomp suggests that the media selector should also suggest images that are used on other language versions of the article, not just based on the page title.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
{T53031}
This could be very useful, but would need us to move more of the media item usage data out of local wikis and into a central repository (probably Wikidata), which has been discussed a few times but I don't know how soon it might get done, sorry.
Wouterstomp at en.wp has requested that the media settings dialog shows a tumbnail/preview of the image so you can refer to it while writing the caption.

I would add to this that ctrl+click on this preview image should load the media description page in another tab/window.

--------------------------
**Version**: unspecified
**Severity**: enhancement
(In reply to comment #2)
> I don't think the original commenter had particularly thought of that, as the
> only thing you can currently do is write a caption. The idea being that you
> can refer back to the image when writing it. This will be even more useful
> I guess when you can used this dialog to write alt text.
> 
> My gut feeling is that a live preview would be nice but not essential.
> Possibly implement a static preview and then see if anybody asks for it to be
> made into a live preview. Assuming a live view is more than trivially harder
> to implement than a static one.

I believe that the hard stuff here will be in showing anything at all (and, particularly, anything that looks like how it will render in the page). Will check about live-updating, though.
I don't think the original commenter had particularly thought of that, as the only thing you can currently do is write a caption. The idea being that you can refer back to the image when writing it. This will be even more useful I guess when you can used this dialog to write alt text.

My gut feeling is that a live preview would be nice but not essential. Possibly implement a static preview and then see if anybody asks for it to be made into a live preview. Assuming a live view is more than trivially harder to implement than a static one.
Is this meant to be a preview of the media item as it will render in the page (i.e., a live-updated view of the configuration options from the dialog)?
<<This is not really a VE bug (it is possible in the standard editing mode as well), but it is something that happens more often in VE, and that perhaps can be automatically disabled in VE as well; inserting references inside section headers. This is never needed or wanted (it is ugly, and the thing that needs to be referenced should be in the text of the section, not only in the title anyway). Example (spam, but the principle applies): http://en.wikipedia.org/w/index.php?title=Miniature_pig&diff=prev&oldid=566703074 . Fram (talk) 07:31, 2 August 2013 (UTC) >>

--------------------------
**Version**: unspecified
**Severity**: enhancement
A user at en.wp asks:
"Why hide the puzzle and content icons until mouse-over? In general, if a function is active, it should be always shown - no idea, what hiding tries to achieve here."

Personally I think this could be very confusing for links, but it should be ok for templates and media.

--------------------------
**Version**: unspecified
**Severity**: enhancement
On reflexion, I'm going to mark this as WONTFIX per my reasoning in comment 1 - this would massively dominate the interface on most real-world pages and make it unusable.
yeah, the only way round that I can think of at the moment would be to have some sort of toggle between the current behaviour (default) and a display all mode. That would be useful for identifying at a glance where things are on a page, particularly with locating any invisible templates. It's not something I personally see as being of huge value, but I'm not everybody.
Templates and images aren't necessarily very big (think for example about the 20px-wide images that decorate some lists, either directly or as tables).

When a node is smaller than a threshold, it displays the node icon as a pop-out (like an inspector menu); if we showed them all the time it could massively crowd-out the text of the page.

Also, I worry that it would obstruct part of the template so you wouldn't know whilst editing exactly what was going to appear for users (if the menu icon was unhelpfully placed).
If category:A is redirected to category:B 
when user adds category:A it should switch it automatically to category:B like mediawiki:gadget-Hotcat.js

--------------------------
**Version**: unspecified
**Severity**: enhancement
Change 118218 merged by jenkins-bot:
Follow redirects in the category widgets

https://gerrit.wikimedia.org/r/118218
Change 118218 had a related patch set uploaded by Alex Monk:
Follow redirects in the category widgets

https://gerrit.wikimedia.org/r/118218
So the redirect comes up as a suggestion, but when we add it, the redirect is resolved and the target added?
The sentence "This page was last modified on … " (message lastmodifiedat) is not updated after an edit.

--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=48560
Verified in production.
Verified in test2 and betalabs. The timestamp for "This page was last modified on 5 November 2014, at 23:54." seems to reflect accurately editing&saving events.
Change 170264 merged by jenkins-bot:
Update "page was last modified on date, at time" footer line when saving

https://gerrit.wikimedia.org/r/170264
Change 170264 had a related patch set uploaded by Alex Monk:
Update "page was last modified on date, at time" footer line when saving

https://gerrit.wikimedia.org/r/170264
(... I had assumed this was for the LastModified extension without checking the message name.)
Change 170184 abandoned by Alex Monk:
Expose getLastModifiedText function

Reason:
oops

https://gerrit.wikimedia.org/r/170184
Change 170184 had a related patch set uploaded by Alex Monk:
Expose getLastModifiedText function

https://gerrit.wikimedia.org/r/170184
Same problem as bug 48560 (the page isn't re-painted when the edit is saved, just the contents <div>, and this sits outside that).
This is generally a valid feature request, and this is something that ULS and VE developers should consider some time in the not-so-far future.
Sorry, I meant to move this to ULS (as it's mostly a ULS design question) when it was filed some weeks ago.
(In reply to comment #11)
> my english is not good enough to understand the "incidentally, ..."
> paragraph. what does that mean in terms of coding?

We may write more code to let you use bits of VisualEditor (like the dialogs) outside of the editor.
my english is not good enough to understand the "incidentally, ..." paragraph. what does that mean in terms of coding?
(In reply to comment #8)
> oh, you are right, it is just code to parse and display it in page settings
> *blush*, sorry for confusion. coming back to the original suggestion: why not
> improve the hacky gadget in the frame of the VE project, instead of including
> it in the VE?

The hacky gadget, as I recall:

* Doesn't let you set non-Wikidata language links (as needed on non-Wikipedia wikis)
* Doesn't let you set local language links to over-ride the ones from Wikidata (as needed on Wikipedia sometimes e.g. for [[Maggie Simpson]])
* Doesn't let you change/remove other languages' links without making you leave the site and going to Wikidata to use the tools there
* Doesn't let you create new Wikidata entities for the page
* Is based on local code that may differ between wikis (making VisualEditor work differently in different places)

We agreed with the Wikidata team a few months ago that replacing this was a worthwhile thing to do.

Incidentally, on the wider point, we're very keen to start moving away from editing being a monolithic block of actions that have to take place together, and instead letting users "curate" quickly - whether that's changing categories, language links, workflow action items (like "needs wikifying" or "nominate for deletion") or other tasks - without having to enter the editor.

HOWEVER, that's not really the point of this bug, is it?
"about the cog not letting you change settings of other languages" refers to the small wheel symbol in the side bar close to "Languages". 
It is created by the MediaWiki extension "UniversalLanguageSelector" (ULS) so that would be the codebase to change for that aspect, not VE's code.
oh, you are right, it is just code to parse and display it in page settings *blush*, sorry for confusion. coming back to the original suggestion: why not improve the hacky gadget in the frame of the VE project, instead of including it in the VE?

the "about the cog not letting you change settings of other languages" and "ULS" i did not understand. what would you mean by this?
(In reply to comment #6)
> _remove_ the code to edit language links from the already complicated VE.

There is no code to edit language links in VisualEditor. What are you talking about?
james, bug 52105 is the exact opposite of the suggestion here. the visual editor team should, imo, leave the hacky gadget, or improve the hacky gadget with something which is not called hacky any more.

and, _remove_ the code to edit language links from the already complicated VE.
Being able to edit language links is bug 52105 (specifically, for Wikidata ones). This would replace the current hacky gadget.

The other part of this bug (about the cog not letting you change settings of other languages) would be an issue with ULS, not VisualEditor, I think?
> i see, you do not know this beast as well

I admit I don't know every single option of software running on Wikimedia servers by heart, plus sometimes bug reporters paraphrase things. That's why I appreciate good steps to reproduce to understand the problems that you're facing.

Now that I can reproduce I agree that it's slightly confusing. 
However the bug summary does not describe the problem but one potential solution, hence changing the bug summary to: 
"VE > Page Settings > Languages" functionality expected where ULS' "Language Settings" cog is

> and all people are happier.

On a general note: If you have not run a survey in your neighborhood and beyond (as other neighborhoods might have different needs and expectations), generalizations feel like http://en.wikipedia.org/wiki/Wikipedia:WEASEL and might diminish the impact & interest in your suggestions how to improve Wikimedia, which would be a pity.
wikidata at the bottom

attached page settings at the right, with languages. and wikidata at the bottom. and i see, you do not know this beast as well and do _not_ expect the language code there. just remove this language link code and all people are happier.

**Attached**: {F11931}
page settings at the right

**Attached**: {F11930}
Why would you want to edit languages, in order to understand the problem that you report here? To add links to articles with the same topic in other languages? That is exactly what Wikidata is for.

With regard to the wheel "which opens something else", this is part of your language and input text settings. 
See http://www.mediawiki.org/wiki/File:ULS_Usability_testing_summary.pdf for the Usability tests that led to this design.

> to really edit the languages one has to go to page settings!

I cannot find anything called "Page Settings" on for example http://en.wikipedia.org/wiki/Berlin . Please provide exact steps to reproduce.
On Unix systems with an X-Windows desktop middle-clicking usually pastes text that was last selected with the mouse.

It doesn't work in the VisualEditor in Firefox if automatic scrolling is enabled in the preferences.

--------------------------
**Version**: unspecified
**Severity**: minor
How on Earth does Firefox's automatic scrolling feature interact with its pasting feature? Gah. :-)
Go to https://www.mediawiki.org/wiki/User:Amire80/be-bullet-heading?veaction=edit, which contains the wikitext:
```
* list item 1
* list item 2
* list item 3

==Heading==
paragraph text
```
Press Shift-↓ (down arrow) three times.

The first time, the first list item is selected.
The second time, the second list item is selected.
The third time, the third list item AND the heading are selected.

Selecting the heading should require a forth press of Shift-↓.
Verified in Firefox 41.0a2 on OS X.
Screenshot of the bug as provided by user

Depending on the display format, VE fails to get the display of several tables properly in line. See also attachment; test page here:

http://de.wikipedia.org/wiki/Benutzer:Stefan_Knauf/Dateidurchsuchungsprogramm.cpp

Report:

http://de.wikipedia.org/w/index.php?title=Wikipedia:Technik/Text/Edit/VisualEditor/Beta2013-07&oldid=121040382#VisualEditor_ist_nicht_WYSIWYG

--------------------------
**Version**: unspecified
**Severity**: minor

**Attached**: {F11761}
Ugh, this is because we put block slugs between these tables, and the tables are floated left.
Rather than simply quietly inserting pawns and other placeholder characters into the page text, VisualEditor should do a sanity-check pre-save and either outright reject or loudly warn about edits that will insert such characters.

--------------------------
**Version**: unspecified
**Severity**: enhancement
The problem of inserting pawns and such is ancient history now, so building a system to detect them is not a good use of time.
I suggest piggybacking on the existing sanity check code: display the "your edit may be corrupted" warning in the save dialog and tag the edit with visualeditor-check.
What it says on the in. Like in most desktop applications, it should be possible for users to customise the keyboard shortcuts to their liking. Including in VisualEditor and source editor.

--------------------------
**Version**: 1.22.0
**Severity**: enhancement
Removed VE reference from the title because it's simply not part of MediaWiki core.
**Author:** `KilliondudeWP`

**Description:**
The edit summary box currently uses a textarea input box. Current functionality has the return key starting a new line in the textarea, but upon save the edit summary is truncated into one line in the page history (line breaks are turned into spaces). Thus, the textarea box is misleading.

A more sane option would be to use a single line text input box, where the enter key processes the edit rather than starts a new line.

See T40042 and T42034, and specifically T42034#467450.
>>! In T54133#1465077, @matmarex wrote:
> even worse in VE than in wikitext editor because the input field is narrower.

Putting a (wider) summary box in the main editor UI would solve {T52961} as well.
Such input box will still not wrap the typed text, which is terrible enough by itself for users, and even worse in VE than in wikitext editor because the input field is narrower.
How about making it an input box and just set `padding-bottom` to make it //feel// like a textarea?
As discussed on the patch, assuming that we want the text to wrap, this is **not actually possible to do** for most languages, and an English-only half-solution would be inappropriate. Browsers are really letting us down here.

As I understand, there are two reasons why we would want this, which have separate tasks:
* {T106325}
* {T50274}

We should focus on resolving these, which should be possible regardless of the underlying text field used.
Change 212795 abandoned by Bartosz Dziewoński:
[WIP] TextInputWidget: Allow wrapped singleline inputs

Reason:
This is not going to be compatible with different text input methods.

[[https://gerrit.wikimedia.org/r/212795]]
The idea may or may not actually be a good one. It's definitely interesting. The gist is that we dynamically swap the <input type=text> for a <textarea>. It has some funny behavior but sort of works.

The patch above makes it impossible to type a newline into the field, and should let it display the automatic browser's autocompletion when it is single-line. Ed mentioned that it can break with IMEs if you're typing a word and it changes from input to textarea in the middle of it.
Change 212795 had a related patch set uploaded (by Bartosz Dziewoński):
Allow wrapped singleline inputs

[[https://gerrit.wikimedia.org/r/212795]]
I think I have a pretty good idea on how to implement this, I'll try to do some pre-hackathon hacking on it today.
>>! In T54133#1302510, @Whatamidoing-WMF wrote:
> I care whether it **behaves like** the wikitext edit summary in terms of interacting with my web browser.  I want to type a complex edit summary once, and have that edit summary automagically re-appear whenever I start typing it on my next edit.  If you can give me that useful function while making the box a perfect square, then I'm satisfied.  I need the function, not the appearance. 

Yup. IIUC, changing the textarea to a text input line, will solve {T50274} (possibly that should be listed as blocked by this?)

Re: keeping it visually highlighted - do note that the textarea has the bright blue border now, when the field is active, which it is automatically when opened, (but not shown in matmarex's screenshot above), and I think that could be sufficient.
I've said this in several places, but I repeat it here:  I don't care what size or shape the edit summary box is on my computer screen.  

I care whether it **behaves like** the wikitext edit summary in terms of interacting with my web browser.  I want to type a complex edit summary once, and have that edit summary automagically re-appear whenever I start typing it on my next edit.  If you can give me that useful function while making the box a perfect square, then I'm satisfied.  I need the function, not the appearance.
The last thing I heard is that making the edit summaries any bigger required redesigning //the database// (yes, //that// database), not merely the user interface.
>>! In T54133#1302437, @awight wrote:
> Okay, I understand where that's coming from.  On the other hand, sometimes it's really helpful to have a brief summary sentence, then a few more paragraphs of relevant things which fall into the "why" category and are therefore more appropriate in a summary or the Talk page than in the main article.

Well, edit summaries are limited to around 200 characters. Changing that limit would involve redesigning the UI, which is doable, but is a fairly big undertaking that should only be done if there's some specific need to change this. I don't think there's a need for that.

> How would you suggest we broaden this discussion?  I'm not sure this is the right place, and donno if wikitech-l is the best mailing list, cos we should involve editors.

I expect that the product folks in the VisualEditor Team will take our input then make an appropriate decision. :-)
Okay, I understand where that's coming from.  On the other hand, sometimes it's really helpful to have a brief summary sentence, then a few more paragraphs of relevant things which fall into the "why" category and are therefore more appropriate in a summary or the Talk page than in the main article.

How would you suggest we broaden this discussion?  I'm not sure this is the right place, and donno if wikitech-l is the best mailing list, cos we should involve editors.
>>! In T54133#1302396, @awight wrote:
> @Deskana, I'm curious why you say that,
>> We want users to be fairly brief with their edit summaries

Edit summaries are intended to be quite brief summaries of the edits. I don't think encouraging users to write a lot of text in there is a good idea.
@Deskana, I'm curious why you say that,
> We want users to be fairly brief with their edit summaries
>>! In T54133#1296269, @matmarex wrote:
> For comparison. The last one looks positively //tiny//.  We'd need to come up with something smart if we were to make it single-line.

That's not necessarily a bad thing. We want users to be fairly brief with their edit summaries, and bigger boxes are more likely to encourage them to write more. Smaller boxes encourage the opposite.

That said, we'd have to be sure that the user's attention isn't drawn to the wrong place; in the last screenshot, the box is so small that the user's attention may not immediately be drawn to that text box. You could try try making the font in the box slightly larger, and slightly increasing the width of the dialogue to compensate.
For comparison. The last one looks positively //tiny//.  We'd need to come up with something smart if we were to make it single-line.

| Current edit summary field | {F166629,size=full} |
| -- |
| Wikitext editor edit summary field | {F166627,size=full} |
| -- |
| Proposed edit summary field (single-line) | {F166624,size=full} |
| -- |
Just merged in very similar task arguing that enter should submit the summary field. (On a similar note, I've proposed using meta + enter as a general shortcut for submitting dialogs in T98105.)

Good points in the comments:

@matmarex:
>This could be confusing since the summary text field looks like a multiline text input, possibly causing users to accidentally submit with incomplete summaries (which can't be corrected afterwards).
>
>It could be interesting to try something else – maybe pressing Enter twice to submit the form, maybe Ctrl+Enter? We should probably do some research.
>
>...
>
>* Facebook: comments to posts on the timeline are normally single-line (pressing Enter in the text field submits a comment), but you can make them multi-line by pressing Ctrl+Enter or Shift+Enter (or by copy-pasting text with newlines). Pressing Enter submits the comment even if it is multi-line.
>* My bank has these "wrapped single-line" inputs in some fields and pressing Enter always does nothing in them. Accidentally submitting a form could potentially have dire consequences there.

@Deskana:
>For the advanced user, the current approach where enter adds new lines is counterintuitive. The advanced user not only knows that edit summaries cannot be multi-line, but it also feels wrong because they're also used to enter submitting their edit.
>
>For the new user, the current approach feels misleading, as you're giving the user an expectation that edit summaries can be multi-lined when in fact they cannot. This user has no expectations about enter submitting the edit, so probably doesn't care too much about that.
>
>I think the best approach would be to make the edit summary box single-line, and make enter submit the edit.
(In reply to Spinningspark from comment #10)

However, the input box should be large enough to accomodate the maximum permitted length of edit summary, even if that means using two lines.
(In reply to Amir E. Aharoni from comment #9)
> Is it possible to meet in the middle: To show it as a textarea, but to allow
> saving using Enter/Return? And maybe provide autocomplete?

That will lead to another problem: newbies will accidentally save before they have finished entering the summary.

The fact is, the edit summary *is not* a text area and should not be displayed as such.  It can only ever be a single line of text.  That is what should be shown.  Enter should initiate a save.
Is it possible to meet in the middle: To show it as a textarea, but to allow saving using Enter/Return? And maybe provide autocomplete?
Bug 48274 seems to cover the same ground, and was one of the first things I found problematic with VE: those of us who do a lot of regular work on many different articles usually have a set of standardised edit summaries which can convey a lot of useful information, with links, to help other editors. The autocomplete facility provided by browsers for a one-line input box worked well.
**JohnCD67** wrote:

Killiondude's comment 1 is an significant usability point - for repetitive tasks it is very helpful that the browser pops up a list of suggestions to click on, which is context-sensitive and based on previous usage. I did not realise how helpful that was until with VE I found myself having to type the full edit summary each time.
(In reply to comment #5)
> > Sure, but collapsing the box down to a single line would de-emphasise the
> > edit summary, however, and turn it back into "a mysterious text box" that
> > uses "feel free to skip".
> 
> Why would it?
> 
> It's still hidden behind a modal dialog. I will wager that editors still feel
> forced to fill it in simply because it is there.

The numbers went up when we switched from inputbox to textarea. Expecting them not to fall when we reverse that change seems unlikely to me.
**sk8er_97456** wrote:

> Sure, but collapsing the box down to a single line would de-emphasise the
> edit
> summary, however, and turn it back into "a mysterious text box" that uses
> "feel
> free to skip".

Why would it?

It's still hidden behind a modal dialog. I will wager that editors still feel forced to fill it in simply because it is there.
(In reply to comment #3)
> I seriously doubt that that is the reason you have a higher incidence of edit
> summaries. What you did in parallel to making it a textarea was that you hid
> the "Save page" final submit button behind a dialog that prominently presents
> the box for an edit summary. Users no longer feel free to skip a mysterious
> text box and click "Save page" right away, the look and feel of the modal
> dialog forces them to consider filling it out in full before proceeding.
> That's why you're getting more edit summaries.

Sure, but collapsing the box down to a single line would de-emphasise the edit summary, however, and turn it back into "a mysterious text box" that uses "feel free to skip".
**sk8er_97456** wrote:

I seriously doubt that that is the reason you have a higher incidence of edit summaries. What you did in parallel to making it a textarea was that you hid the "Save page" final submit button behind a dialog that prominently presents the box for an edit summary. Users no longer feel free to skip a mysterious text box and click "Save page" right away, the look and feel of the modal dialog forces them to consider filling it out in full before proceeding. That's why you're getting more edit summaries.
By making the summary a textarea rather than an inputbox we've seen a radically-greater number of editors (especially, anonymous and new editors) entering edit summaries for their edits. I think we should think very seriously about the impact of such a change before just making it.
**KilliondudeWP** wrote:

Another issue brought up with having a text area box is that previously entered summaries are not suggested. Most browsers suggest prior terms entered into text input boxes, this allowing editors to choose from their (frequently) used summaries.

https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Improvements&oldid=566754323#Autofill_edit_summary
Steps to reproduce
1. Create a page with a linefeed
2. Edit it in VE
3. Copy the block containing the ↵
4. In a new VE window, paste

Expected results:
VE smartly removes the ↵

Actual results:
The ↵ is pasted into the second VE as a literal character

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=53828
Just want to capture that in many cases the user could want the ↵ to mean "break this line and create a new line"

I don't think this is 100% of the time, but enough that we should think about it.
Change 83222 merged by jenkins-bot:
The Great [...] Rewrite of 2013: Clipboard edition

https://gerrit.wikimedia.org/r/83222
Change 83222 had a related patch set uploaded by Esanders:
The Great [...] Rewrite of 2013: Clipboard edition

https://gerrit.wikimedia.org/r/83222
References are also pasted as [1], etc
As perhaps a simpler case of copy and paste from 'external sources', pasting richtext that copied from the same wiki should work seamlessly.

In many cases, the 'html' already has the metadata needed. e.g. the image, or text-with-wikilinks, even the categories, should be paste-able

https://en.wikipedia.org/wiki/Pelham_Parkway

With a tiny bit of additional html attributes, the navbox templates ({{Parkways in New York City}} & {{Bronx streets}}) could be copied as they are self-contained units - no parameter were used to invoke them.

Again with a bit of markup, the Infobox pasted into a VE session, but only the shell transclusion could set up - the parameters would need to be entered by the user in the VE.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51547
NB Firefox throws away RDFa properties when copying, so this won't be possible without JavaScript intercepting copy events, as it stands.
*** Bug 52787 has been marked as a duplicate of this bug. ***
(In reply to comment #2)
> This is a separate problem James.  This is about copying from a non-VE wiki
> page on the same wiki.  That is very different from copying from another VE,
> or another website.  As I eluded to in my initial enhancement request,
> additional HTML needs to be emitted into the read version of the wiki page in
> order that a VE could pick up the name of the template to use when pasting it
> into a VE.

Oh, sorry, I missed your comment about adding RDFa/etc. hinting to highlight what DOM elements are what.

"Tiny" is not remotely the correct word - this will require us to replace the entire read DOM with the same output as Parsoid provides VisualEditor, which is vaguely scheduled to be considered for research/analysis in about a year's time (this is so far off in the distance there isn't even a bug for it yet). Recasting.
This is a separate problem James.  This is about copying from a non-VE wiki page on the same wiki.  That is very different from copying from another VE, or another website.  As I eluded to in my initial enhancement request, additional HTML needs to be emitted into the read version of the wiki page in order that a VE could pick up the name of the template to use when pasting it into a VE.
This is not simpler. This is the same. The problem is not taking in rich text (from any source), it's inserting it sanely into VisualEditor's ContentEditable surface, sadly. Merging.

*** This bug has been marked as a duplicate of bug 33105 ***
The paste operation on Firefox behaves strangely when dom.event.clipboardevents.enabled = false
(which is exposed in the UI of several extensions)

When disabled, rich text appears to have been pasted into VE, with links in blue (but the link isnt editable), but in reality the paste has failed to change the underlying data in VE.

If the user starts typing, the pasted richtext disappears.

If the user saves immediately after the paste, the richtext remains visible in the VE, but the save only adds blank lines instead.

--------------------------
**Version**: unspecified
**Severity**: minor
When you start a new transclusion dialog for a template which has the templatedata specified it shows a list of the parameters with the label on the left and the actual parameters in grey on the right. This is good for power users who know the parameters. 

When you choose a parameter which has a value specified you can see the label, but you can't see what the actual parameter is. This would be quite handy and could use the same grey style as in the list.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Wikipedias in some languages, among them Polish, Russian, Ukrainian and Hebrew, have a gadget that shows a list of frequent edit summaries near the edit summary field in source editing mode.

Here are the source samples:

Polish: https://pl.wikipedia.org/wiki/MediaWiki:Gadget-edit-summaries.js
Hebrew: https://he.wikipedia.org/wiki/MediaWiki:Gadget-Summarieslist.js

Many users in the Hebrew Wikipedia complained about the lack of this gadget in the VisualEditor. This could be an enhancement request, but given that for several languages it's an integral part of the editing interface for these languages, it's a regression for them.

Adding this as a feature should be very easy, given that it's quite simple and the existing gadgets' code can be reused. Localization and customization for every project can be done on a MediaWiki page with a list of summaries for that project.

--------------------------
**See Also**:
{T50274}
The relevant gadgets currently seem to support VE (And so does the english wikipedia version of this gadget). Do we keep this open as a core VE improvement ? 

I'd think that considering the experiences with iOS mobile App canned edit summaries some thorough UX analysis and creative thinking would have to go into this to make such a thing useful for both inexperienced and seasoned editors honestly.
Yes, and FWIW, the he.wikipedia veteran editors welcomed this change, done by @eranroz (thanks, Eran).

It's available in the mobile apps in all languages, and I wonder - can @deskana provide any info about whether the mobile editors use it and like it? And what do the recent changes patrolers in different languages think about it?
Both of the gadgets linked have been extended to also work with VisualEditor, by the way.
(In reply to comment #1)
> I'm reminded of bug 48274.

It's somewhat related, but definitely not the same. What I'm talking about are very frequent summaries in a project. Every project community decides what it needs, but usually it's common generic stuff like "spelling", "adding links", "wikification", "removing unreferenced content", "copyediting" etc.
I'm reminded of bug 48274.
Steps to reproduce:
1. Open VE on a sandbox
2. In a different window, delete the sandbox
3. In the VE window, change the text in the sandbox and save the page

Expected results:
Something similar to the SE, which asks "
User xxx (talk) deleted this article after you started editing it, with a reason of:

    blah 

Please confirm that you really want to recreate this article." with a checkbox

Actual results:
Backend error message is displayed, and there is no option to ignore this error.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Change 169976 merged by jenkins-bot:
Catch pagedeleted errors and give the ability to re-create the page

[[https://gerrit.wikimedia.org/r/169976]]
Change 169976 had a related patch set uploaded by Alex Monk:
Catch pagedeleted errors and give the ability to re-create the page

https://gerrit.wikimedia.org/r/169976
I currently get this error in Parsoid:

TypeError: Cannot read property 'length' of null
    at Object.result.parse (eval at <anonymous> (/var/www/MediaWiki/Git/extensions/VisualEditor/parsoid/lib/mediawiki.tokenizer.peg.js:97:44), <anonymous>:18347:34)
    at PegTokenizer.tokenizeAsync (/var/www/MediaWiki/Git/extensions/VisualEditor/parsoid/lib/mediawiki.tokenizer.peg.js:135:25)
    at PegTokenizer._processText (/var/www/MediaWiki/Git/extensions/VisualEditor/parsoid/lib/mediawiki.tokenizer.peg.js:124:8)
    at PegTokenizer.process (/var/www/MediaWiki/Git/extensions/VisualEditor/parsoid/lib/mediawiki.tokenizer.peg.js:38:7)
    at ParserPipeline.process (/var/www/MediaWiki/Git/extensions/VisualEditor/parsoid/lib/mediawiki.parser.js:439:21)
    at ParserPipeline.processToplevelDoc (/var/www/MediaWiki/Git/extensions/VisualEditor/parsoid/lib/mediawiki.parser.js:455:21)
    at SSP.parseOriginalSource (/var/www/MediaWiki/Git/extensions/VisualEditor/parsoid/lib/mediawiki.SelectiveSerializer.js:143:17)
    at TemplateRequest.<anonymous> (/var/www/MediaWiki/Git/extensions/VisualEditor/parsoid/lib/mediawiki.Util.js:1266:3)
    at TemplateRequest.g (events.js:180:16)
    at Object.processSome [as _onImmediate] (/var/www/MediaWiki/Git/extensions/VisualEditor/parsoid/lib/mediawiki.ApiRequest.js:123:17)
worker 11363 died (1), restarting.
The response is now:

| Error: The page has been deleted since you fetched its timestamp

I guess we should inherit this message, however. Changing to an enhancement.
It should look at the attributes directly rather than take them as parameters. We should move the folding of all sorts of types into 'default' or 'none' in there. We should set the CSS class in one place rather than two different ones.

--------------------------
**Version**: unspecified
**Severity**: enhancement
The Poem extension has almost as much extension setup as it has functionality. Bundling it with MediaWiki is silly, it should simply be merged into core.

--------------------------
**Version**: 1.22.0
**Severity**: enhancement
**Whiteboard**: migrate Poem extension bugs to core post-resolution
Change 106861 abandoned by TTO:
Merge Poem extension into core

Reason:
I don't intend to pursue this anymore. However, reviewers here might be interested in https://gerrit.wikimedia.org/r/328887 and https://gerrit.wikimedia.org/r/328888 .

[[https://gerrit.wikimedia.org/r/106861]]
I'm not really interested in this anymore. Instead, I might try getting the automatic line numbering functionality requested in T15644 into the Poem extension, which would make the Poem extension a bit bigger and more worthwhile.
In particular, I'm interested in hearing more from @GOIII about:
> force the opening and closing poem tags to always reside on their own lines
and
> ways to use empty inline-blocks to ''handle'' not only stanza spacing; but indentation and eol padding as well. Making attribute manipulation easier through the opening (margin-top) or closing (margin-bottom) tags of Line itself could dramatically cut down on stuff like that.
Lets get a spec for `<lines>` written down in such a way that we can discuss issues like this:
* Should the tags be forced to be on their own lines?  (The current implementation doesn't force this.)
* Can you write `<lines class="foo">`?  Does this override the default "poem" and "mw-lines" classes, or add to them?  Is this sufficient for the different styling @GOIII describes?  (The current implementation doesn't allow extra classes.)
* What should the Parsoid representation be?
* What if somebody writes `<pre class="poem mw-lines">` in wikitext?  That's valid wikitext.  Should Parsoid try to re-serialize this as a `<lines>` tag?
* Generally styles hard-coded by mediawiki core are prefixed.  The `poem` class is not.
* If `<poem>` is aliased to `<lines>`, are we going to break all of wikisource overnight?
* Is a recursive parse strategy really appropriate?  It means that `<lines>` and `<pre>` are going to grow additional inconsistencies on the edge cases.  For example, `'''foo<lines>bar'''bat` could get rather confused about its `<b>`s.
From Parsoid's perspective, the biggest problem with `<lines>` is unclear semantics.

I suggest that this patch go through the RFC process first.  Let's write up a document which describes exactly how we want `<lines>` to behave.  We should also discuss deployment strategy in the RFC -- should we turn off support in core until Parsoid and VE also support it?  Or implement stopgap support which doesn't allow editing sections which contain `<lines>` (treating it an an "unknown extension"), or what?

And what is our strategy for migrating existing `<poem>` content to `<lines>`?  Is there an automatic translation?  Or are some details of the semantics going to trip us up when we try to convert existing content?

As @GOIII states, our paragraph handling in the wikitext parser is already extremely complex, and there are a lot of existing workarounds which depend on details of `<poem>` in order to obtain specific effects in poetry.  If we're going to create a new feature, let's make sure it can actually handle all the things that folks want it to do, without crazy hacks.
Change 106861 had a related patch set uploaded (by TTO):
Merge Poem extension into core

[[https://gerrit.wikimedia.org/r/106861]]

#patch-for-review
(In reply to comment #42)
> (In reply to comment #38)
>> A Global Message Delivery to all Wikisource Scriptoriums/Village pump is
>> higly recommended
> 
> MZMcBride, could you advise how feasible this would be?

I think a mention in [[m:Tech/News]] is sufficient here. Nothing is breaking, as I understand it, so this news is purely informational: "In addition to <poem>, you can also now use <some other tag name>."

If you really want to send a global message, you can use [[m:MassMessage]].
(In reply to James Forrester from comment #49)
> I don't particularly mind it being merged into core from an "editing" POV,
> but it is "yet another feature" in MediaWiki core which we're meant to be
> making leaner, faster and more flexible, which this roughly feels like it
> goes against.
> 
> The Parsoid-land changes aren't too hard to handle, I believe, so that
> shouldn't block this.

It's also another one of those features that will come in at least slightly handy on almost every wiki, though. It's deployed on a significant percentage of wikis, and on those on which it isn't deployed, the users probably wish it were deployed when they run into situations that call for its use. https://wikiapiary.com/wiki/Extension:Poem

Admittedly, it's not as important as, say, ParserFunctions or Cite (both of which should probably be merged to the core, by the way). But it's not very harmful, either.
(In reply to Kunal Mehta (Legoktm) from comment #48)
> (In reply to Tpt from comment #45)
> > Yes, you have right with "mw-lines".
> > 
> > I understand your concern with differing functionality that would require
> > two buttons in the editing interface (it's the major concern I see). I think
> > we should have feedback from the VisualEditor team.
> 
> James, do you/your team have an opinion?

I don't particularly mind it being merged into core from an "editing" POV, but it is "yet another feature" in MediaWiki core which we're meant to be making leaner, faster and more flexible, which this roughly feels like it goes against.

The Parsoid-land changes aren't too hard to handle, I believe, so that shouldn't block this.
(In reply to Tpt from comment #45)
> Yes, you have right with "mw-lines".
> 
> I understand your concern with differing functionality that would require
> two buttons in the editing interface (it's the major concern I see). I think
> we should have feedback from the VisualEditor team.

James, do you/your team have an opinion?
Change 106861 restored by Legoktm:
Merge Poem extension into core

Reason:
I think this is a valuable changeset that should be pursued.

https://gerrit.wikimedia.org/r/106861
Change 106861 abandoned by Krinkle:
Merge Poem extension into core

Reason:
Closing for now to clear pending review dashboard. Feel free to re-open when you can work on it.

https://gerrit.wikimedia.org/r/106861
Yes, you have right with "mw-lines".

I understand your concern with differing functionality that would require two buttons in the editing interface (it's the major concern I see). I think we should have feedback from the VisualEditor team.
That's a very good suggestion, Tpt. I would be inclined to call the CSS class something more like "mw-lines" or similar, to comply with modern class naming standards.

However I wonder if it is really a good idea to provide differing functionality, however minor, between <poem> and <lines>?
As I believe that <poem> tag will be kept as an alias forever, it may be interesting to make <poem> and <lines> semantic a little bit different:
- <lines> would be presentational only and the output will have the "lines" class as in <pre class="lines">
- <poem> has the same presentational effect as <lines> but use the "poem" class to specify that the content is a poem as in <pre class="lines poem">

It won't break sites CSS because the current pages only use the poem tags. If wikis wants to use their custom CSS for <poem> tag with all <lines> tags, they will only have to change "poem" by "lines" in their rules.
(In reply to comment #37)
> (In reply to comment #31)
> > 1) In comment 29, Jesús Martínez Novo made a good suggestion to more widely
> > publicize the new <lines> name before it gets committed.  
> > A mailing list thread might be a good way to
> > kick off this discussion.
> 
> I'll post one.

http://lists.wikimedia.org/pipermail/wikitech-l/2014-February/074337.html

No replies, so I assume no-one is concerned.

(In reply to comment #38)
> A Global Message Delivery to all Wikisource Scriptoriums/Village pump is
> higly recommended

MZMcBride, could you advise how feasible this would be?
(In reply to comment #40)
> The <poem/> tag usage on texts that does not contains poems, only the need to
> parse line breaks in a different behaviour, isn't the feature itself provided
> by the extension, only a very interesting side effect.

Please read the preceding comments in this bug report. The reason why this tag is going to be made available under the name <lines> is to emphasise that is not only used for poems, but for other texts that require the preservation of line breaks. This is not merely a "side effect", but the key feature of this tag.

> IMHO before merging Extension:Poem into core it firstly needs to addresses
> all
> expected behaviours in their original expected feature,

A merge of an extension into core, means taking the extension's existing functionality, and placing it in MediaWiki core. It does not mean we add extra features at the same time.

The Poem extension only provides poem-related (line break preservation) functionality, so that is all that core is getting in this merge. This is not the place to discuss other "original expected features".
The <poem/> tag usage on texts that does not contains poems, only the need to parse line breaks in a different behaviour, isn't the feature itself provided by the extension, only a very interesting side effect.

It looks to me like in very old MediaWiki versions without file undeletion support: media deletion at that time resulted in less disk space being used. But that aren't the feature, only a side effect.

IMHO before merging Extension:Poem into core it firstly needs to addresses all expected behaviours in their original expected feature, ie to provide quickly and in easy ways alternatives to format text portions based in a given form of language.
(In reply to comment #38)
> In the time that <poem/> tag arised on Wikisources, we have also asked for a
> <prose/> tag (See bug 6810).

That is an entirely separate issue. The presence or absence of a <prose> tag is not going to affect the resolution of this bug.

> As you can see on [3] and [4], the formatting isn't the same currently
> adopted
> in <poem/> tag, so the current consensus to set <poem/> as an alias for a new
> tag name isn't viable.

I don't understand your point here. What has this got to do with the <poem> tag?
A Global Message Delivery to all Wikisource Scriptoriums/Village pump is higly recommended, since this extension was firtly developed to Wikisource wikis and latter enabled on all Wikimedia wikis [1] [2].

In the time that <poem/> tag arised on Wikisources, we have also asked for a <prose/> tag (See bug 6810).

Unfortunately at that time the developers picked what was most easy to then instead of what is more user intuitive (sorry, but <poem>foo</poem> and {{prose start}}foo{{prose end}} don't makes sense to newcomers (#c6).

As you can see on [3] and [4], the formatting isn't the same currently adopted in <poem/> tag, so the current consensus to set <poem/> as an alias for a new tag name isn't viable.

[1] - https://wikitech.wikimedia.org/wiki/Server_admin_log/Archive_7#June_23

[2] - https://wikitech.wikimedia.org/wiki/Server_admin_log/Archive_10#February_7

[3] - https://en.wikisource.org/wiki/Template:Prose

[4] - https://fr.wikisource.org/w/index.php?title=MediaWiki:Common.css (classe prose : PERIMÉE, utiliser text )

[[:m:User:555]]
(In reply to comment #31)
> 1) In comment 29, Jesús Martínez Novo made a good suggestion to more widely
> publicize the new <lines> name before it gets committed.  We almost
> inadvertently introduced a conflict with <verbatim>, I'd like some greater
> certainty that the new <lines> name proposal has been seen by a larger number
> of editors/extension authors.  A mailing list thread might be a good way to
> kick off this discussion.

Will a post to wikitech-l suffice? Or is more needed in your opinion? I can probably handle the communication portion of this, just please be explicit with what you would consider sufficient.

> 2) In the comments on the patch, '----' was brought up as the last remaining
> way that the current <lines> implementation differs from 'indent-pre'
> handling.

Okay, I figured out what you mean here. At [[testwiki:Bug 52061#Indent-Pre ("Preceding space")]] a "----", the wikitext equivalent of a horizontal rule (<hr>), is not current expanded when there's a leading space.

In my opinion, this behavior (preceding space + unexpanded horizontal rule) is a separate issue that should be filed as a separate bug report (if one doesn't exist already) and is not a blocker to merging Gerrit change 106861. If you feel differently, can you please elaborate? (Also, can you please search for a relevant bug report and/or file one?)

> 3) I'd also like to review the code coverage issues a little more, to ensure
> that we're sharing code (and CSS rules) to the maximum extent possible.  This
> is to ensure that point #2 continues to hold in the future, and we don't
> accidentally introduce subtle incompatibilities by changing only one side of
> a code path.

Sure, code review is ongoing at Gerrit change 106861. If you have additional suggestions for technical changes, feel free to leave them on Gerrit. :-)
Instead of finding similarities between poem and indent-pre, which is moot since the indentation already breaks all markup that depends on being on the first column of the line, we may look at similarities between poem and normal wikitext.

It's practically the same. The only difference is that poem treats newlines as <br/>, while normal text simply ignore newlines or convert them into paragraphs when there's a combination of newlines.
(In reply to comment #31)
> I'd like to resolve this discrepancy: I really really *really* don't want to
> complicate the parser more with Yet Another Slightly Different Way to handle
> preformatted content.

There's nothing really new here :) We're just sending a <pre> tag to the parser, after all. The change to the parser itself is minuscule, and arguably it is a fix for a long-standing bug that was never exposed until now.

(In reply to comment #33)
> (07:34:41 PM) subbu: so, we were wrong .. <poem> is not indent-pre with
> classes then.

I'm glad you're aware of this! As I said in Gerrit, the similarities are purely coincidental.
I added a few more test cases to [[testwiki:bug 52061]] -- leading colons are also parsed differently inside <poem>.
I think I just saved this patch from a premature +2.

I'd like to summarize what still needs to be done here:

1) In comment 29, Jesús Martínez Novo made a good suggestion to more widely publicize the new <lines> name before it gets committed.  We almost inadvertently introduced a conflict with <verbatim>, I'd like some greater certainty that the new <lines> name proposal has been seen by a larger number of editors/extension authors.  A mailing list thread might be a good way to kick off this discussion.

2) In the comments on the patch, '----' was brought up as the last remaining way that the current <lines> implementation differs from 'indent-pre' handling.  I'd like to resolve this discrepancy: I really really *really* don't want to complicate the parser more with Yet Another Slightly Different Way to handle preformatted content.

3) I'd also like to review the code coverage issues a little more, to ensure that we're sharing code (and CSS rules) to the maximum extent possible.  This is to ensure that point #2 continues to hold in the future, and we don't accidentally introduce subtle incompatibilities by changing only one side of a code path.

Does anyone else have any remaining issues they'd like to see resolved before this is merged?
Regarding my use of "indent-pre" above -- I'm looking at this mostly from the perspective of parser maintenance.  As [[testwiki:bug 52061]] demonstrates, the desired behavior of <poem>/<lines> is the same as the existing behavior of 'indent-pre', although the implementation in the original patch was very different.  I would like to try to avoid adding a bunch of new hair (and crazy interactions) with the new feature, and instead try to reuse the existing indent-pre handling code so that all the corner cases were consistent.

In fact, assuming this gets merged, it might be cleaner in the future to document the "indent pre" behavior as "an implicit <lines> surrounding the indented region".  This would reduce confusion because "indent pre" and "<pre>" are actually quite different in their handling of embedded wikitext, etc.

I like the name <lines>, btw.
lines sounds good, or <preservelines>

That said, maybe it would be more user friendly to use a mediawiki.org page to discuss the tag name, so ideas can be better exposed and have more opinions (remember one have to explicitly register an account here to post a comment).

About <poem> itself, I don't know why is a different name really needed. What are other use cases for this? I've just only used it for poem and lyrics (which is basically the same).
I like <lines>, the name puts the focus on the individual "lines" of the content, which is also what the tag is doing. Nice lateral thinking, Michael :)
(In reply to comment #22)
> (In reply to comment #16)
> > <verbatim> is a misleading name since it still parses wikitext in its
> > content.
> > It is only verbatim for text-content. 
> 
> I do see what you mean here. The problem is, we have so far been unable to
> come
> up with a better name! <poem> is inappropriate as too specific/narrow.
> 

What about <lines>? The tag just just preserves the lines in its content, and it seems generic enough for what is used.
(In reply to comment #25)
> Since this is going to be merged into core/php-parser, presumably, you
> control
> this behavior and where in the parser pipeline the outer wrapping <pre> tag
> is
> generated? I haven't looked at the parser changes to answer that or how easy
> this is since I haven't really hacked the php parser. Maybe Scott can answer
> that more readily. 

I think I've got this part sorted.
That is right reg. CSS.

Since this is going to be merged into core/php-parser, presumably, you control this behavior and where in the parser pipeline the outer wrapping <pre> tag is generated? I haven't looked at the parser changes to answer that or how easy this is since I haven't really hacked the php parser. Maybe Scott can answer that more readily. 

At least with Parsoid, that is what we will consider outputting for this new tag unless VE folks find a <div> tag simpler than a marked up <pre> tag (seems unlikely).
What you are saying makes sense. Presumably the CSS for .poem would have to "neutralise" the monospace/gray formatting normally applied to pre tags.

My main question is, if we output a <pre> tag from the tag hook, will wikitext inside that tag still get parsed, as it should be?
(In reply to comment #22)

> (In reply to comment #20)
> > IMO the <poem> tag should be rendered as <pre
> > class="poem"> and it has exactly the behavior of indent-pre (with an extra
> > HTML
> > class and without the necessity to write the leading indentation).
> 
> A few questions about this statement:
> 
> * The gray box/monospaced font of <pre>/indent-pre would have to be removed
> for
>   <poem> blocks.
> * What are the existing differences between <poem> and indent-pre?
> * <pre> does not render identically to indent-pre, so could you explain how
>   rendering poems using <pre class="poem"> would help?

We weren't very clear about what we were discussing there. 

What Scott meant is that the patch should generate <pre class="poem"> .. </pre> for the HTML of the <verbatim>..</verbatim> (or <pre-text> or whatever tag name is picked) instead of generating <div class="poem">..</div>. It is cleaner and the ouput is semantically closer to the intention of the <verbatim> tag.
(In reply to comment #16)
> <verbatim> is a misleading name since it still parses wikitext in its
> content.
> It is only verbatim for text-content. 

I do see what you mean here. The problem is, we have so far been unable to come up with a better name! <poem> is inappropriate as too specific/narrow.

> Is there another way of achieving this
> without adding a new tag?

The <poem> tag is already in wide use. I don't see the problem with adding a tag for this functionality.

(In reply to comment #20)
> IMO the <poem> tag should be rendered as <pre
> class="poem"> and it has exactly the behavior of indent-pre (with an extra
> HTML
> class and without the necessity to write the leading indentation).

A few questions about this statement:

* The gray box/monospaced font of <pre>/indent-pre would have to be removed for
  <poem> blocks.
* What are the existing differences between <poem> and indent-pre?
* <pre> does not render identically to indent-pre, so could you explain how
  rendering poems using <pre class="poem"> would help?
I agree reg. output being <pre class='poem'> .. </pre>

However, maybe make it possible for the editor to provide a css-class rather than hardcode class="poem" into the tag?

For standard <poem> content,
<pre-text>
... 
</pre-text>

And for other uses,
<pre-text class="fancy-css">
...
</pre-text>
I further updated [[testwiki:bug 52061]] to show the difference between <poem> and <pre class="poem">.  IMO the <poem> tag should be rendered as <pre class="poem"> and it has exactly the behavior of indent-pre (with an extra HTML class and without the necessity to write the leading indentation).
(In reply to comment #17)
> I don't know what you mean by indent-pre.

Subbu clarified that this means the preceding space trick. I updated [[testwiki:bug 52061]].
Please, don't use <verbatim>!!. It's already been in use by a Wikia extension [1]

----

[1] http://community.wikia.com/wiki/Help:Verbatim_tags
(In reply to comment #16)
> From what I can tell, looking at output, this is "indent-pre" - "indent" +
> CSS-class. Given that indent-pre provides all the formatting functionality, I
> presume the missing ability of adding CSS-classes onto indent-pre is the
> primary reason for this new tag? Is there another way of achieving this
> without adding a new tag?

I don't know what you mean by indent-pre.

I created a test page at [[testwiki:bug 52061]] to demonstrate the poem tag's functionality.
<verbatim> is a misleading name since it still parses wikitext in its content. It is only verbatim for text-content. 

From what I can tell, looking at output, this is "indent-pre" - "indent" + CSS-class. Given that indent-pre provides all the formatting functionality, I presume the missing ability of adding CSS-classes onto indent-pre is the primary reason for this new tag? Is there another way of achieving this without adding a new tag?
(In reply to comment #10)
> Regarding the tag name, is <poem> ever actually used for things besides
> poems?

I looked at some examples in de.wikipedia. Apart from poems and poem-like texts (prayers etc.) there are things like inscriptions and dialogs, which use <poem>. And of course, as it is a wiki, some stupid things like quotes even without any line break in them.
Sure, let's go with verbatim.

Siebrand also noted on Gerrit change 106861 that if/when this gets merged, we'll need to migrate the Poem extension bugs to core.
I'd also prefer <verbatim> as the name.
I'm wondering if people would prefer <verbatim> as the name of this tag?
Change 106861 had a related patch set uploaded by TTO:
Merge Poem extension into core

https://gerrit.wikimedia.org/r/106861
The compact feature has always seemed quite buggy (or at least bizarrely unintuitive) and I wonder if we would really hurt much by killing it altogether.

Regarding the tag name, is <poem> ever actually used for things besides poems? I usually use <pre> for other cases.
(In reply to comment #8)
> I am thinking something like <verbatim>, <asis> ("as is"), <nocollapse>,
> <pretext>/<pre-text> (as in <pre> but for text, not code), <keepbreaks>
> [...]

Okay, I'll paint this bikeshed. I like verbatim or pretext. How about one of those?

> 2. The attribute "compact" seems to actually make the display less compact.
> See the testcase at [[mw:Extension:Poem]]. I think we need a new name/alias for
> this too. However, I have no idea what it is actually meant to be used for...

I'm not sure "compact" is needed... do people use it? If so, are there examples of it in the wild?
OK, I'm taking a look at this. The merge looks easy enough, but I need advice.

Poem has two major nomenclature issues:

1. The tag should have another name besides <poem>. In comment 6 <nobreak> was suggested, but Poem does the reverse - it preserves line breaks. I am thinking something like <verbatim>, <asis> ("as is"), <nocollapse>, <pretext>/<pre-text> (as in <pre> but for text, not code), <keepbreaks> ......... ?? Any better ideas?

2. The attribute "compact" seems to actually make the display less compact. See the testcase at [[mw:Extension:Poem]]. I think we need a new name/alias for this too. However, I have no idea what it is actually meant to be used for...
(In reply to comment #6)
> (In reply to comment #5)
> > If you merge it to core, please call it something other than <poem>. Other
> > than that I couldn't care less :D
> 
> I think we must keep the name "<poem>" for backward-compatibility, but it
> should definitely have a saner alias ("<nobreak>" or something).

The main name of the feature should be something else, <poem> can be an alias for backwards-compatibility.
(In reply to comment #5)
> If you merge it to core, please call it something other than <poem>. Other
> than that I couldn't care less :D

I think we must keep the name "<poem>" for backward-compatibility, but it should definitely have a saner alias ("<nobreak>" or something).
If you merge it to core, please call it something other than <poem>. Other than that I couldn't care less :D
Poem was merged into core back in 2008, but subsequently reverted; see http://www.mediawiki.org/wiki/Special:Code/MediaWiki/43520.
I must say, however, that I totally agree with the original report and Poem (along with some obvious stuff like CheckUser, RenameUser, etc.) should be in core; maybe it should've been there from day one, even.
Steps to deprecate an extension (apart from actual code changes):

* Turn off extension for testwiki in InitialiseSettings.php and make sure nothing breaks (1 deployment cycle)
* Turn off extension for all wikis in InitialiseSettings.php and make sure nothing breaks (1 deployment cycle)
* Remove extension from CommonSettings.php, wmf-config/extension-list, and make-wmf-branch/default.conf (1 deployment cycle)
* Move/deprecate MediaWiki documentation
* Get component removed from Bugzilla, migrate any existing bugs
* Have project removed from Gerrit (not immediately of course)
(In reply to comment #1)
> Anytime an extension is created or deprecated it's a logistical pain in the
> ass.

Can you elaborate on this? It seems pretty easy to me.
I'm cool with merging it into core, although I probably wouldn't call it 'easy'. Anytime an extension is created or deprecated it's a logistical pain in the ass. Also, I would prefer to have this idea vetted on Wikitech-l before someone actually goes through the trouble of doing it.
VE should work as expected without clipboard access.  Currently it only half initalises.

1. Install Kill Evil in Chrome or similar
2. Edit any page

(https://chrome.google.com/webstore/detail/kill-evil/epieehnpcepgfiildhdklacomihpoldk)

Result:
https://en.wikipedia.org/wiki/File:Missing-ui-ve.png

--------------------------
**Version**: unspecified
**Severity**: enhancement
People disable these features for good reason; a nice error message, or even an ugly error message, would be helpful to let them know why VE wont load.
@Esanders I agree, but perhaps we should also be better about error handling in general when an app such as VE fails to launch. There is no problem with not supporting Kill Evil, but I think there is a problem of ending up in a half initiated state with no user feedback right ?

I think that is an area that we could be better at (be it VE, UploadWizard or what not).
This little used extension kills APIs that are essential for VE to work.
Sorry for very slow triage.
When 'Kill Evil' addon exists, there are two failures to load modules, and then an exception which halts the VE initialisation half way.

Module 'WrappedSelection' failed to load: Module 'WrappedSelection' failed to load: No means of selecting a Range or TextRange was found rangy-core-1.3.js:105

Module 'Position' failed to load: required module 'WrappedSelection' not supported rangy-core-1.3.js:105

Uncaught TypeError: Object #<WrappedSelection> has no method 'refresh' rangy-core-1.3.js:3035

WrappedSelection rangy-core-1.3.js:3035
getSelection rangy-core-1.3.js:3084
ve.ce.Surface.showSelection ve.ce.Surface.js:1325
ve.ce.Surface.onChange ve.ce.Surface.js:747
oo.EventEmitter.emit oo.js:421
ve.dm.Surface.change ve.dm.Surface.js:402
ve.dm.SurfaceFragment.select ve.dm.SurfaceFragment.js:448
ve.ui.Surface.initialize ve.ui.Surface.js:81
(anonymous function) ve.init.mw.ViewPageTarget.js:1098
proxy load.php?debug=true&lang=en&modules=jquery%2Cmediawiki%2CSpinner%7Cjquery.t…%7Cmw.MwEmbedSupport&only=scripts&skin=vector&version=20130725T023359Z:775

in ve.ui.Surface method initialize, the following invocation should probably be skipped if those rangy modules have failed to load.

   // By re-asserting the current selection and forcing a poll we force selection to be something
   // reasonable - otherwise in Firefox, the initial selection is (0,0), causing bug 42277
   this.model.getFragment().select();
This isn't a fancy thing. You can't do things like bold the selection if you can't access information about what is actually selected.
That too ;-)  Making the bug more general.  Hopefully VE is able to be at least partially functional without all those fancy things.
That's more likely caused by the "getSelection and onselectstart/onmousedown" part of that extension.
A very common chess template on many Wikipedias recommends using '|=' , and most instances of chess boards use this syntax
https://en.wikipedia.org/wiki/Template:Chess_diagram#Standard_diagram
https://de.wikipedia.org/wiki/Vorlage:Schachbrett#Standarddiagramm

On German Wikipedia, editing the template strips the '=' signs.  This article is on the parsoid topfails
https://de.wikipedia.org/wiki/Edward_Lasker?veaction=edit
http://parsoid.wmflabs.org:8001/topfails/1

There are 900 uses of these chess templates on German Wikipedia.
https://de.wikipedia.org/w/index.php?title=Spezial:Linkliste/Vorlage:Schachbrett&limit=750
https://de.wikipedia.org/w/index.php?title=Spezial:Linkliste/Vorlage:Schachbrett-klein&limit=115
A few more of
https://de.wikipedia.org/wiki/Vorlage:Schachbrett-10x10
https://de.wikipedia.org/wiki/Vorlage:Schachbrett-8x10
https://de.wikipedia.org/wiki/Vorlage:Schachbrett-Chaturanga

The syntax is used on many other WPs, incl. eswp, frwp, plwp and ruwp
https://es.wikipedia.org/wiki/Plantilla:Diagrama_de_ajedrez#Diagrama_est.C3.A1ndar
https://fr.wikipedia.org/wiki/Mod%C3%A8le:Diagramme_d%27%C3%A9checs
https://fr.wikipedia.org/wiki/Alexandre_Alekhine
https://pl.wikipedia.org/wiki/Szablon:SzachyDiagram
https://ru.wikipedia.org/wiki/%D0%A8%D0%B0%D0%B1%D0%BB%D0%BE%D0%BD:%D0%A8%D0%B0%D1%85%D0%BC%D0%B0%D1%82%D0%BD%D0%B0%D1%8F_%D0%B4%D0%B8%D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B0

On English, the VE UI can go into massive layout problems, but the UI issues may all be due to the Parsoid issue.
https://en.wikipedia.org/wiki/French_Defence?veaction=edit
The number of uses on enwp appears to be in the same ballpark as dewp
https://en.wikipedia.org/w/index.php?title=Special:WhatLinksHere/Template:Chess_diagram&limit=900

--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
{T55226}
{T53166}
{T73404}
There are no screenshots here to show how it used to be broken, but it seems to behave correctly now.
Also at https://fr.wikipedia.org/w/index.php?title=Tour_(%C3%A9checs)&diff=96381943&oldid=95391142 .
Moving to visual editor in case there is something about the Parsoid output that is causing broken layout in the "|=" form of chess-board syntax.  Please assign to Parsoid if there is a bug here in our output.
Hmm .. strange.  When I copied both forms of the syntax into a file and parse it with Parsoid, the html renders just fine.  Curious why it breaks in VE however.

Verifiable here: http://parsoid.wmflabs.org/_wikitext/

Paste this there and scroll down past the literal html and you'll see this rendered correctly there.

------------------------------------------------
{{Infobox chess opening
|openingname = French Defence
|image = {{Chess diagram|=
|
|
|=
  |rd|nd|bd|qd|kd|bd|nd|rd|=
  |pd|pd|pd|pd|  |pd|pd|pd|=
  |  |  |  |  |pd|__|__|__|=
  |  |  |__|  |__|__|__|__|=
  |  |  |__|  |pl|__|__|__|=
  |  |  |__|__|__|__|__|__|=
  |pl|pl|pl|pl|__|pl|pl|pl|=
  |rl|nl|bl|ql|kl|bl|nl|rl|=
|
}}
|moves=1.e4 e6
|ECO=C00–C19
|birth =
|nameorigin = London vs. Paris correspondence match (1834–36)
|parentopening = [[King's Pawn Game]]
|AKA =
|chessgid=39913&move=2&moves=e4.e6&nodes=21720.39913
}}
------------------------------------------------
An alternative 'pretty' syntax that doesnt cause breakages is:

https://de.wikipedia.org/w/index.php?title=Edward_Lasker&diff=120835751&oldid=120194113

The html comments are visible in the parameters of the template dialog, but it stops the dirty diffs if this |= syntax is not desirable.
Several users on the English Wikipedia, most recently Salix, have requested that the parameters for templates should be in the recommended order not alphabetical order. 

For example in {{tracklist}} it lists "Track10" before "Track2", and in the various citation templates, "First" and "Last" should be adjacent.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Change 107428 merged by jenkins-bot:
Use paramOrder data for ordering template parameters

https://gerrit.wikimedia.org/r/107428
Change 107428 had a related patch set uploaded by Trevor Parscal:
Use paramOrder data for ordering template parameters

https://gerrit.wikimedia.org/r/107428
Resolved in Ic3eb665389380c8e3dd6562b059c2f6655a22588
After filling/testing a couple of templates in ca.wikipedia.org, it looks like the current behavior is the following:

* Required fields are sorted by the order they are listed in the template data.
* Optional files are sorted alphabetically.

Please sort everything following the same sequence used in the template data. Usually this is the same order used in the "old" documentation, which in turn tends to follow the order in which the information is presented.
The dependency has been fixed.

Is the importance of this still "Low enhancement"?
*** Bug 53891 has been marked as a duplicate of this bug. ***
(In reply to comment #4)
> There is a good case for imposing some ordering on the template parameters.
> Often you find some parameters naturally group together. Take for example
> http://en.wikipedia.org/wiki/Template:Infobox_single/doc There are various
> parameters which group together:
> *Ones relating to the image (Cover, Alt, Caption and Border)
> *Ones to do with the single chronology (Last single, This single, Next
> single)
> for infoboxes a prefered order would generally be the order they appear in
> the
> template.

Yeah, that sounds a totally reasonable thing to add. Making a bug now…
There is a good case for imposing some ordering on the template parameters. Often you find some parameters naturally group together. Take for example http://en.wikipedia.org/wiki/Template:Infobox_single/doc There are various parameters which group together:
*Ones relating to the image (Cover, Alt, Caption and Border)
*Ones to do with the single chronology (Last single, This single, Next single)
for infoboxes a prefered order would generally be the order they appear in the template.
There is no such thing as "TemplateData recommended order"; the JSON block is unordered and can't be relied upon. Does this imply that we should have a "parameter order" value for TemplateData?
Another example is [[pl:Template:Związek chemiczny infobox]] on pl.wp (infobox for chemical compounds) which has a lot of parameters which should be shown together, but which are not always alphabetically one after another. These groups are for example:

* gęstość + gęstość źródło + stan skupienia w podanej g + g warunki niestandardowe (density, source for density, state of matter for this density, non-standard environment conditions for the density)
* rozpuszczalność w wodzie + rww źródło + rww warunki niestandardowe (solubility in water, source, non-standard environment conditions)
An example of this is {{Taxobox}} which has 100+ parameters. There are about 10 recommended parameters which go at the top the list and the rest of the parameters have a strict ordering depending on taxonomic hierarchy. Kingdom, Phylum, Class,	Order, Family, Subfamily, Genus, Species. An example of use is http://en.wikipedia.org/wiki/Formica which gives the fields in a confusing alphabetial order (latin names are used for the fields).

A second problem is the order when no templatedata is specified. In the article http://en.wikipedia.org/wiki/Where_Does_This_Door_Go?veaction=edit
if you open up the dialog for the {{tracklist}} the parameters are listed in the order track1, track10, track11 ... track15 track2 track3 ... track9. Ideally they would be in strict numerical ordering. This would require a smarter sorting algorithm than just alphabetical. 

Another note is that case insensitive sort is better than case sensitive sort as templates often have the same parameter with different capitalization, 'Image' and 'image'.
Removing the last reference on a page, with <references/> present, causes the waring:

There are no references with the group "" on this page.

That should be 

There are no references on this page.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Change 86656 merged by jenkins-bot:
Add specific message for empty ref group list

https://gerrit.wikimedia.org/r/86656
Change 86656 had a related patch set uploaded by Esanders:
Add specific message for empty ref group list

https://gerrit.wikimedia.org/r/86656
I agree with John: Most pages dont used grouped references. It would be much more intuitive to say that there are no references at all. Several users in the Hebrew Wikipedia complained about it, and I imagine that it's the same in all languages.
In the use-case for this bug, there are no references of any group, so why mention groups at all.  IMO the UI shouldnt talk about groups unless it is necessary.  Most pages dont used grouped references.
(In reply to comment #0)
> Removing the last reference on a page, with <references/> present, causes the
> waring:
> 
> There are no references with the group "" on this page.
> 
> That should be 
> 
> There are no references on this page.

No. You can have dozens of <ref group="foo">s and no <ref>s and get that message.

Perhaps a special-case of "There are no references without a group on this page." for the null-group instance?
On the English Wikipedia the page title formatting level is never used in article space, although I understand it is used on some other wikis. It might be that other wikis do not use a dfferent page style.

Accordingly it would be nice to be able to remove/suppress/disable this item from the list on a per namespace (or, less ideally, per wiki) to avoid confusion to new editors. 

Unless this is absolutely trivial to implement, please regard it as a low priority enhancement request.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Sadly not trivial, but yes, this level of flexible configuration would be nice.
At en.wp a user comments:
"The tooltip with a "puzzle" icon that appears when clicking on a template should contain the name of the template used. This would allow readers to be aware of which template they're about to change and would make the Templates interface [[self-documenting]], teaching by example the existence of the most common templates.

For example, the next screenshot would contain the word "Chembox" besides the puzzle icon:"

Screenshot: [[File:VisualEditor - Template editing 1.png]]

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51827
(In reply to Alex Monk from comment #3)
> Don't we have this now? What to do about this bug?

Yes, fixed by Trevor's new context menus as of 6 months or so ago.
Don't we have this now? What to do about this bug?
(In reply to comment #1)
> What would this do when multiple templates (or other transclusions) are used
> in
> the scope of one transclusion block, like the succession boxes?

I can think of three logical options:

1. The name of the first template and some indication (perhaps an asterisk?) that there are multiple translcusions in the block, e.g. "s-start *"

2. a list of all the items in the transclusion, e.g. for [[Alan Williams]]:

s-start
s-par
s-bef
s-ttl
s-aft
s-end

Note that above, each template is listed only once, even for multiple occurrences, showing repeats is possible also.

3. The names of the first and last templates with an indication (probably an ellipsis) that there are omitted elements, e.g. "s-start ... s-end" or
s-start
...
s-end

The horizontal format I'd guess might be easiest to program but would only work for templates with short names.

In either 1 or 3 there could be a way to click to see the templates that are omitted. However I'm not sure how useful that would be, so my suggestion would be to just leave passive provision for it to be added later without difficulty should it be requested.
What would this do when multiple templates (or other transclusions) are used in the scope of one transclusion block, like the succession boxes?
If you open up the image finder, identify an image you want and /double/ click on it, the image finder closes and the selected image is inserted twice.

Debian/Iceweasel 17.0.7.

--------------------------
**Version**: unspecified
**Severity**: minor
I believe we fixed this yonks ago; sorry for slow response.
Also in Chrome 28/Windows 7.
Screenshot

**Attached**: {F11569}
In the site settings dialog you can see a list of language/interwiki links for the current article. There is a explanation text saying those can only be edited in the wikitext editor. Because of Wikidata this is now no longer true for most articles. The text should be adapted and maybe link to the corresponding Wikidata item?

--------------------------
**Version**: unspecified
**Severity**: trivial
\o/
thanks!
Change 97516 merged by jenkins-bot:
Note language links need to be edited on Wikidata

https://gerrit.wikimedia.org/r/97516
Change 97516 had a related patch set uploaded by Jforrester:
Note language links need to be edited on Wikidata

https://gerrit.wikimedia.org/r/97516
I could only find one major button that leads to the help pages - the one at the top toolbar. Ideally, there should be help buttons in every context - dialog boxes, inspector, plugins, etc.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
{T53237}
We disagree with the premise; instead, there should only be help links where they are useful to explain the complexity of a control to the user. Most of this is already done, and the focus areas for this release don't have this level of complexity required. Consequently, we decided to remove this from the Q3 blockers list at the triage meeting on 2015-02-11.
They are definitely in the i18n system, for example https://meta.wikimedia.org/wiki/MediaWiki:Visualeditor-dialog-meta-categories-defaultsort-help/en
The relevant documentation about messages (i18n system) appears to include 
* https://www.mediawiki.org/wiki/Help:System_message
* https://www.mediawiki.org/wiki/Localisation#Adding_new_messages
* https://www.mediawiki.org/wiki/Localisation_file_format
* https://www.mediawiki.org/wiki/Help:System_message#Finding_messages_and_documentation

The last of these says "How each message is used by MediaWiki, variables available, parameters used, limitations, et cetera is explained with the complete documentation in the qqq pseudo-language files", with a link to here:

* https://translatewiki.net/w/i.php?title=Special%3ATranslate&task=reviewall&group=core&language=qqq&limit=5000&tux=0

On that page, if I change the Group field to any of the four VisualEditor groups, and then look for the messages that James added to all items related to one VE menu, I can't find those messages. Should I be looking somewhere else, or are the messages not in the i18n system?
>>! In T53798#1029938, @John_Broughton wrote:
> * The content of contextual help should be similar to templates: visible to everyone, each on separate page, with a related talk pages, but not necessarily editable by anyone but an admin. What //isn't// needed is some programmer-added contextual help; what is needed is a //system// so that creating and modifying contextual help is done by members of Wikipedia communities. [For example, pages could be named something like this: Help:VisualEditor/ContextHelp///label//, where "label" is a unique name for where the contextual help will appear.

MediaWiki already solved this problem long ago with the i18n system and the MediaWiki: system namespace. Either look at the changes made to the i18n/en.json file, or search for the text you want changed, to find out which page in the MediaWiki namespace an admin needs to change. These MediaWiki pages can also have related talk pages.


>>! In T53798#1029938, @John_Broughton wrote:
> * Contextual help should be able to include links - because linking to the relevant section (or anchor point - see WP:EIW, for example) is important when the (relatively short) contextual help isn't sufficient.

I think we could allow that, but we'd need to change OO.ui.FieldLayout to accept HTML for the 'help' configuration, and then make VE-MW parse the help messages.
>>! In T53798#1029938, @John_Broughton wrote:
> * The content of contextual help should be similar to templates: visible to everyone, each on separate page, with a related talk pages, but not necessarily editable by anyone but an admin. What //isn't// needed is some programmer-added contextual help; what is needed is a //system// so that creating and modifying contextual help is done by members of Wikipedia communities. [For example, pages could be named something like this: Help:VisualEditor/ContextHelp///label//, where "label" is a unique name for where the contextual help will appear.

MediaWiki already solved this problem long ago with the i18n system and the MediaWiki: system namespace. Either look at the changes made to the i18n/en.json file, or search for the text you want changed, to find out which page in the MediaWiki namespace an admin needs to change. These MediaWiki pages can also have related talk pages.


>>! In T53798#1029938, @John_Broughton wrote:
> * Contextual help should be able to include links - because linking to the relevant section (or anchor point - see WP:EIW, for example) is important when the (relatively short) contextual help isn't sufficient.

I think we could allow that, but we'd need to change OO.ui.FieldLayout to accept HTML for the 'help' configuration.
Those who noticed the contextual help on the meta (page settings) menu - I'm not one of them - apparently didn't think it was worth commenting at WP:VE/F, or its equivalent at mediawiki.org. That may because contextual help was added to the VE menu //least used.// Or because no one was overwhelmed by the wording in the contextual help popups. Or because there was no obvious way to suggest improvements in wording. Regardless of the reasons, the lack of a response should absolutely not be taken to be a polling of the user community.

More generally:

* Contextual help absolutely is needed. The lack of this is one of the major weaknesses of wikitext editing. I don't think user feedback is needed to confirm this need. But if there is any doubt, then I suggest posting this the question ("Should VE menu items have contextual help?) at one or both Feedback pages. 
* The content of contextual help should be similar to templates: visible to everyone, each on separate page, with a related talk pages, but not necessarily editable by anyone but an admin. What //isn't// needed is some programmer-added contextual help; what is needed is a //system// so that creating and modifying contextual help is done by members of Wikipedia communities. [For example, pages could be named something like this: Help:VisualEditor/ContextHelp///label//, where "label" is a unique name for where the contextual help will appear.
* Contextual help should be able to include links - because linking to the relevant section (or anchor point - see WP:EIW, for example) is important when the (relatively short) contextual help isn't sufficient.
Change 186108 merged by jenkins-bot:
MWMediaDialog: Add contextual help for controls

[[https://gerrit.wikimedia.org/r/186108]]
Change 186108 had a related patch set uploaded (by Jforrester):
MWMediaDialog: Add contextual help for controls

[[https://gerrit.wikimedia.org/r/186108]]

#patch-for-review
Did we get any feedback?
The page settings ("meta") dialog now has a complete set of contextual help. Will wait for further user feedback before doing the rest of the dialogs.
Change 160371 merged by jenkins-bot:
Add contextual help to all remaining meta dialog controls

https://gerrit.wikimedia.org/r/160371
Change 160371 had a related patch set uploaded by Jforrester:
Add contextual help to all remaining meta dialog controls

https://gerrit.wikimedia.org/r/160371
Change 159104 merged by jenkins-bot:
Provide contextual help for the page settings dialog's controls

https://gerrit.wikimedia.org/r/159104
First one done. We'll seek feedback on this approach and then roll out for the rest of the dialogs.
Change 159104 had a related patch set uploaded by Alex Monk:
Provide contextual help for the page settings dialog's controls

https://gerrit.wikimedia.org/r/159104
Change 159095 merged by jenkins-bot:
Make help button for FieldLayout frameless again

https://gerrit.wikimedia.org/r/159095
Change 159095 had a related patch set uploaded by Alex Monk:
Make help button for FieldLayout frameless again

https://gerrit.wikimedia.org/r/159095
It looks like some work was done in Gerrit change 147751 and then reverted
So for adding these to the page settings controls, it should now just be a case of adding the new messages and using them as the config.help for each setting's FieldLayout. James, are you planning to do this?
So I suppose now the job is to start writing copy…
Change 142468 merged by jenkins-bot:
Allow FieldLayouts to have help text

https://gerrit.wikimedia.org/r/142468
Change 142468 had a related patch set uploaded by Alex Monk:
Allow FieldLayouts to have help text

https://gerrit.wikimedia.org/r/142468
As a start, maybe add the (?) icon next to each of the page settings controls so we can give some blurb for users? I'm happy to write the copy on the commits. :-)
**turingt** wrote:

Maybe, the way to make the target page configurable can be creating a fixed redirect page for each link, so that we can change the redirect target.
At https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=572181319#Inserting_reference there are comments that the instruction manual is too difficult to find, and requests that contextual help be added to the various dialogs. 

These help links should obviously open in a new window/tab, and the target needs to be configurable on wiki as help pages are not static and get split/merged/reorganised over time.
The description of a parameter in the list of parameters does not always fit in the width of the editing add-parameter box, particularly in firefox (where the font size is apparently larger in than chrome) and when users are using large fonts for accessibility reasons. Where this is the case (or always) the description should be shown in a tooltip on hover or when selected by up/down keyboard prior to insertion.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50354
https://bugzilla.wikimedia.org/show_bug.cgi?id=51436
https://bugzilla.wikimedia.org/show_bug.cgi?id=62142
I recently ran across [https://en.wikipedia.org/w/index.php?title=Polycarbonate&diff=prev&oldid=564618311 this edit].  It seems as though they were trying to fix a spelling correction and inadvertently destroyed a table and had an entire section get repeated.

There was a little [https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Strange_Diff discussion about the diff on the Visual Editor feedback page], where it was mentioned that the diff "is very strange and [the commenter didn't] recall seeing anything similar".

--------------------------
**Version**: unspecified
**Severity**: normal
This was fixed a very long time ago (around August last year), but I didn't spot this report until just now; my apologies.
The problem is that the table wikitext is buggy there.  It is missing a closing tag (in reality, it is missing a newline break.  |-|} .. See https://en.wikipedia.org/w/index.php?title=Polycarbonate&action=edit&oldid=563700122)

The PHP parser output for this is also broken (see https://en.wikipedia.org/w/index.php?title=Polycarbonate&oldid=563700122#Manufacturers_and_brands and where the table has ended up).

We could improve Parsoid to detect some scenarios like this, but it is currently lower priority.  Fixing the table by adding a line break between "|-" and "|}" should fix the issue for now.

Sample wikitext snippet for our use later:

{|
|foo
|-|}
abc
An English Wikipedia user familiar with the transclusion dialog expected thatthe way to remove an  image from the article was using a remove option in the media dialog. Such an option does not exist, and they couldn't work out another way of removing the image other than selecting and deleting the characters around and including the slug.

--------------------------
**Version**: unspecified
**Severity**: enhancement
It's (now?) very simple to delete an image by clicking on it and pressing delete. Pushback welcome.
After https://pl.wikipedia.org/w/index.php?title=Pomoc:VisualEditor/Skr%C3%B3ty_klawiszowe&oldid=37098556&diff=cur this edit it sees unreviewed pages and distinguishes between stable and unreviewed versions despite a) on this page, both versions are autoreviewed b) even if points [[Wikipedia:VisualEditor/Nawigacja]] (transcluded) out as pending rewiev - the project namespace is not reviewable.

--------------------------
**Version**: unspecified
**Severity**: minor
This is how it is configured in WikiEditor; will require icon creation.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Done and will be deployed tomorrow.
Change 74979 merged by jenkins-bot:
Add bold/italic for cyrillic/georgian languages

https://gerrit.wikimedia.org/r/74979
Change 74979 had a related patch set uploaded by Esanders:
Add bold/italic for cyrillic/georgian languages

https://gerrit.wikimedia.org/r/74979
This is how it is configured in WikiEditor; will require icon creation.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Done and will be deployed tomorrow.
Change 74979 merged by jenkins-bot:
Add bold/italic for cyrillic/georgian languages

https://gerrit.wikimedia.org/r/74979
Change 74979 had a related patch set uploaded by Esanders:
Add bold/italic for cyrillic/georgian languages

https://gerrit.wikimedia.org/r/74979
This is how it is configured in WikiEditor; will require icon creation.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Done and will be deployed tomorrow.
Change 74979 merged by jenkins-bot:
Add bold/italic for cyrillic/georgian languages

https://gerrit.wikimedia.org/r/74979
Change 74979 had a related patch set uploaded by Esanders:
Add bold/italic for cyrillic/georgian languages

https://gerrit.wikimedia.org/r/74979
This is how it is configured in WikiEditor; will require icon creation.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Done and will be deployed tomorrow.
Change 74972 merged by jenkins-bot:
Add bold/italic for more latin langages

https://gerrit.wikimedia.org/r/74972
Change 74972 had a related patch set uploaded by Esanders:
Add bold/italic for more latin langages

https://gerrit.wikimedia.org/r/74972
This is how it is configured in WikiEditor; will require icon creation.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Done and will be deployed tomorrow.
Change 74972 merged by jenkins-bot:
Add bold/italic for more latin langages

https://gerrit.wikimedia.org/r/74972
Change 74972 had a related patch set uploaded by Esanders:
Add bold/italic for more latin langages

https://gerrit.wikimedia.org/r/74972
This is how it is configured in WikiEditor; will require icon creation.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Done and will be deployed tomorrow.
Change 74972 merged by jenkins-bot:
Add bold/italic for more latin langages

https://gerrit.wikimedia.org/r/74972
Change 74972 had a related patch set uploaded by Esanders:
Add bold/italic for more latin langages

https://gerrit.wikimedia.org/r/74972
This is how it is configured in WikiEditor; will require icon creation.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Done and will be deployed tomorrow.
Change 74972 merged by jenkins-bot:
Add bold/italic for more latin langages

https://gerrit.wikimedia.org/r/74972
Change 74972 had a related patch set uploaded by Esanders:
Add bold/italic for more latin langages

https://gerrit.wikimedia.org/r/74972
This is how it is configured in WikiEditor; will require icon creation.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Done and will be deployed tomorrow.
Change 74972 merged by jenkins-bot:
Add bold/italic for more latin langages

https://gerrit.wikimedia.org/r/74972
Change 74972 had a related patch set uploaded by Esanders:
Add bold/italic for more latin langages

https://gerrit.wikimedia.org/r/74972
This is how it is configured in WikiEditor; will require icon creation.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Done and will be deployed tomorrow.
Change 74972 merged by jenkins-bot:
Add bold/italic for more latin langages

https://gerrit.wikimedia.org/r/74972
Change 74972 had a related patch set uploaded by Esanders:
Add bold/italic for more latin langages

https://gerrit.wikimedia.org/r/74972
This is how it is configured in WikiEditor; will require icon creation.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Done and will be deployed tomorrow.
Change 74972 merged by jenkins-bot:
Add bold/italic for more latin langages

https://gerrit.wikimedia.org/r/74972
Change 74972 had a related patch set uploaded by Esanders:
Add bold/italic for more latin langages

https://gerrit.wikimedia.org/r/74972
This is how it is configured in WikiEditor; will require icon creation.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Done and will be deployed tomorrow.
Change 74972 merged by jenkins-bot:
Add bold/italic for more latin langages

https://gerrit.wikimedia.org/r/74972
Change 74972 had a related patch set uploaded by Esanders:
Add bold/italic for more latin langages

https://gerrit.wikimedia.org/r/74972
At the moment wikimarkup being entered into the VE triggers a notice warning the user that it won't work - this notice then has to be actively dismissed. It'd be nice if, should the user remove the problematic markup, the notice would vanish.

I'm popping this in as a low-priority enhancement: I appreciate the VE team has active breakage to focus on.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52386
https://bugzilla.wikimedia.org/show_bug.cgi?id=70168
That area of code could do with some rethinking, but this is basically done.
Change 110295 merged by jenkins-bot:
Hide wikitext warning notification when the user removes the markup

https://gerrit.wikimedia.org/r/110295
Change 110295 had a related patch set uploaded by Alex Monk:
Hide wikitext warning notification when the user removes the markup

https://gerrit.wikimedia.org/r/110295
(In reply to comment #3)
> There's an issue with this though, in that the popup hovers over the 'Save
> page' button so I couldn't actually click 'Save page' very easily. It wasn't
> at
> all clear to me that clicking anywhere on the popup would close it.

You aren't the first person to say that - see bug 52386
(In reply to comment #2)
> The popup should also be closed automatically after the "save page" button
> has
> been pressed. At that point it's clear that the user is not going to remove
> any
> markup that still remains (for whatever reason) so the notice serves no other
> purpose and just gets in the way of the edit summary dialog.

There's an issue with this though, in that the popup hovers over the 'Save page' button so I couldn't actually click 'Save page' very easily. It wasn't at all clear to me that clicking anywhere on the popup would close it.
The popup should also be closed automatically after the "save page" button has been pressed. At that point it's clear that the user is not going to remove any markup that still remains (for whatever reason) so the notice serves no other purpose and just gets in the way of the edit summary dialog.
%%%*** Bug 52155 has been marked as a duplicate of this bug. ***%%%
If I move an image around, I see the "copy" cursor, even though I'm just moving.

--------------------------
**Version**: unspecified
**Severity**: minor
Created attachment 13903
cursor image

Oh, the screenshot doesn't show the cursor, but I added an example image of the cursor type instead.

Safari Mac Version 7.0 (9537.71) just dragging around a thumbnailed image throughout the text shows this problem for me. It changes from the move cursor to the copy cursor.

**Attached**: {F11318}
Nope, I still see this problem. Initially it's the move cursor, but as soon as i move the cursor somewhere between the lines, i get the copy cursor.

Screenshot attached.
The cursor I get in Safari (the same as in Firefox and Chrome) is the move cursor (a four-pointed cross). Marking as WORKSFORME. Possibly a config issue with your system?
http://it.wikipedia.org/wiki/Template:Cassetto is AFAIK the Italian version of Hidden (it shouldn't be used in articles).

http://it.wikipedia.org/wiki/Utente:Superchilum features a cassetto named Tudù which transcludes the subpage Utente:Superchilum/do.

If you try and edit the first section in that cassetto, Varie, with the classic editor, you correctly manage to edit the /do subpage; VE instead only allows editing the main userpage.

Thanks.

--------------------------
**Version**: unspecified
**Severity**: normal
When dragging an item in the visual editor (tested with image and text), the editing window does not scroll up or down when you reach the top or bottom of the window. This means you have to make several consecutive drag and drop actions to move an item within a long article/section. Per Bug 51665 the image must be separately selected before you are able to drag it (i.e. each movement requires two mouse clicks).

**See Also**:
{T36307}
{T75240}
I tested moving an image again today, and this is the result on my Air Os X in https://en.wikipedia.org/wiki/Victor_Diaz_Lamich?veaction=edit, using the trackpad.
In Chrome, maximized window, using Lamich’s plane pic:
*I click on it and drag it down to put it at the bottom of the article, a green “+" icon appears to guide me (good!). Nothing happens if I hover my pointer around the bottom of the page; down arrow does nothing; the side scrollbar doesn’t appear.
*The two-fingers scroll gesture does work when the pointer is on the side scrollbar, so I manage to put the pic at the bottom of the article.
*Now trying to put it back where it was, so I click and drag it again. Nothing happens if I hover around the top of the page or hit the up arrow, but the page does scroll if instead I move the pointer /on/ the toolbar (scroll gesture while on the side scrollbar also works). There may be a problem with the focus though, but at least the pic is where I want it to be.

In Safari, maximized window, using the same pic:
*Dragging the pic doesn’t show the green + icon, but a line instead. Dragging it toward the bottom of the screen achieves nothing. 
*The two-fingers scroll gesture works on the entire surface of the page, and it’s the only way to get to the bottom of the page, and then on the top again. Hovering on the toolbar while dragging accomplishes nothing in Safari; it shows the green + icon though, in the area of the tab name.
*Dragging and pressing the up and down arrows doesn’t seem to work. In the rare cases when it does, both the up and the down keys will actually move the pic toward the top of the page, one line at the time (holding the key never works in my experience).
Yes, OS X 10.9.5 Chrome and Windows 7 with IE 11- objects cannot be dragged beyond the bottom or the top of the page - the page does not scroll up. In IE 11, sometimes it's possible to drag beyond the bottom of a page but never beyond the top of editing area.
I'm on OS X 10.10.1 (14B25) with Chrome 40.0.2214.45 beta (64-bit) and the issue is present.
This appears to be OS-specific.  I do not have this problem (either scrolling up or down) on Mac OS 10.8.5; I know that at least two editors have this problem on Windows 8.
So I'm not sure I'm adding to the right bug, but I don't seem to be able to drag templates or images beyond the bottom of the window (and even beyond the top when I tested this the other way around) with the mouse.
I tried this in https://de.wikipedia.org/wiki/Benutzer:Elitre_%28WMF%29/sandbox with Chrome and Firefox.
Just tested this, I can scroll up, with some difficulty ( by positioning the cursor on the top toolbar), but scrolling down does not seem possible. 

Additionally, in most drag and drop interfaces I can be dragging and use a two finger, gesture based scroll while dragging, this does not work on VE (Chrome Version 39.0.2171.52 beta (64-bit) / OS X 10.10 )
This was fixed over the Summer.
I found this a problem to. When additing using just a touchpad or not having a scroll option on the mouse, you have a difficulties to move and object.
*** Bug 63170 has been marked as a duplicate of this bug. ***
Problem encounter at FF 24.0 Windows Vista. As I cant add a template, per this bug:
http://imgbin.org/index.php?page=image&id=15296

I have to use the method of placing the template on the top and scroll down. Thus this behaviour is blocking me in activity in VE.
(In reply to comment #4)
> the "challenge" was to get
> the "language" template back at the bottom of the page. You can't do this by
> dragging, even if you stay in the same window.

I think I know what you mean and I have filed a report about it at Bug 54756. Good catch! Thank you.

Also, setting the priority back to Normal since this is usually decided by the developer or team working on a specific report. Thank you for your understanding.
**Wikifram** wrote:

While the above is correct insofar that dragging beyond the page boundaries doesn't work (apparently not an urgent problem?), the "challenge" was to get the "language" template back at the bottom of the page. You can't do this by dragging, even if you stay in the same window. You can use some unintuitive workarounds (which you can find for yourselves), but the basic functionality doesn't work, just like most of the basic functionality of MW 1.22wmf19. has anyone tested ''anything'' in this release related to VE? Anything at all? Since it was "very" easy to find many problems with it in half an hour of testing. Back to the drawing boards please.
fwiw I believe this bug has been mentioned at https://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28technical%29#VisualEditor_weekly_update_-_2013-09-26_.28MW_1.22wmf19.29 

The users poses "a challenge" consisting in dragging the <languages /> bar at [[mw:Groups]] from the bottom of the page to the top, which implies dragging.

A more probable use case it to move pictures from one section to another.
Confirmed that this also occurs on Firefox 22 and Chrome 28 on Windows 7
Forgot to note this is on Firefox 22 on Xubuntu Linux
If you want to move an image to the start of a section in Visual Editor the logical course of action is to drag it to before the first character of the first word of the section.

A user of Firefox 21 reports this does not work at all, in my testing in Firefox 22 it appears to work only occasionally.

The counter-intuitive dragging the image to after the last character of the section title does work.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=54756
https://bugzilla.wikimedia.org/show_bug.cgi?id=65883
Change 139674 merged by jenkins-bot:
Block item drag and drop

https://gerrit.wikimedia.org/r/139674
*** Bug 51292 has been marked as a duplicate of this bug. ***
Change 139674 had a related patch set uploaded by Esanders:
Block item drag and drop

https://gerrit.wikimedia.org/r/139674
*** Bug 54756 has been marked as a duplicate of this bug. ***
I'm a little confused as to what the request is here - do you feel that VisualEditor should, when dragging, magically create (and destroy) places to put the cursor, so you can drag content there? Assuming this, I've re-titled, but please correct if I've misunderstood.

We've deliberately decided against that in the past as a confusing behaviour, hence why there are all the extra blank lines ("slugs") for the "possible place you could put the cursor which aren't actually there" concept.

We could do this, but I'm not sure. Also, it adds behaviour that is possible using a mouse but not the keyboard (dragging is not done in the keyboard, instead cut/paste is), which is a little uncomfortable given the intent of VisualEditor.

We've considered adding an "outline mode" which would have all the slugs shown, possibly including these ones, and an "editor mode" where no slugs at all would show, which could be one alternative to this request.
There is a similar problem when you try to drag elements to the end of the editable content area - see Bug 54756.
A user on English Wikipedia requests that templates such as navigation boxes that display as collapsed by default when viewing should display as collapsed by default when editing.

"Currently, navigation boxes are always uncollapsed when editing. This can be quite annoying when having to deal with big ones like {{The Beatles}}, e.g. on "I'm a Loser", also it might be confusing editors into believing that this part of a page can easily be edited."

--------------------------
**Version**: unspecified
**Severity**: minor
Created attachment 13417
Related render problems

This is a related problem, which would not be noticable if it was not for this bug.

https://en.wikipedia.org/w/index.php?title=Anarchism&veaction=edit

When in normal view mode (not VE), expand all of those sidebars
A large area of whitespace opens up above "Internal issues and debates", and the images appear there.

In the VE, that whitespace is filled with text, which causes the images to be pushed further down in the content, eventually slipping into the References section, and on Firefox the images even overlaps the References section.

I haven't investigated what is causing the VE vs non-VE rendering differences, but collapse is clearly the reason this rendering difference is a significant problem that all VE users face, rather than a minor glitch that only appears when the user is silly enough to alter all sidebars to be expanded.

**Attached**: {F11253}
(In reply to comment #1)
> First of all, this requires fixes for bug 51565 to be deployed, and then we
> need to fix the NavFrame and CollapsibleTable scripts in
> en:wp:MediaWiki:Common.js to use the same hooks.

That change has been made on enwp by TheDJ/hartman (cc'd)

https://en.wikipedia.org/w/index.php?title=MediaWiki:Common.js&diff=570114240&oldid=569893356

The templates are yet not collapsing; is there more development needed in VE product or in Common.js ?

I think 'collapse' need more special handling in VE (possibly even in parsoid); in order to be WYSIWYG.
1. The user can change the collapse state of templates in the VE dialog editor, and that change should be reflected in the VE after the changes are applied.
2. The user should be able to collapse and uncollapse a collapse-able template in order 
2.1 to visualise how the page will look in each mode
2.2 hide/unhide collapse-able templates that are consuming precious screen real estate (this should be a separate enhancement)

Perhaps this feature should be dependent on bug 30352.
First of all, this requires fixes for bug 51565 to be deployed, and then we need to fix the NavFrame and CollapsibleTable scripts in en:wp:MediaWiki:Common.js to use the same hooks.
>>! In T53613#2529488, @Danny_B wrote:
>>>! In T53613#2529467, @Jdforrester-WMF wrote:
>> Actually, VE will have one until it's banned in wikitext, not just "not easily accessible".
> 
> So ban it then. The request for it has been around for ages.

At the bare minimum you'll need to run a three-month-long community RfC on meta with convincing arguments that explain as to why they all need to replace `<big>` with `<span style="font-size: bigger;">` and so on. There are, from a quick search, over 70k pages with at least one of these on the English Wikipedia alone; the transition will be quite a lot of work.

It's not remotely worth it to spend that much in terms of WMF resources. If you want to try, you're welcome, but I seriously doubt you'll get sufficient consensus (and even then it'd probably need to be a configuration option so that third party wikis can address the breaking change in slower time).

Not of this is germane to this ticket, however.
>>! In T53613#2529467, @Jdforrester-WMF wrote:
> Actually, VE will have one until it's banned in wikitext, not just "not easily accessible".

So ban it then. The request for it has been around for ages. Not even speaking that it has been deprecated ages ago even in XHTML we used before, and it is obsolete in HTML5.
>>! In T53613#2529467, @Jdforrester-WMF wrote:
> Actually, VE will have one until it's banned in wikitext, not just "not easily accessible".

So ban it then. The request for it has been around for ages.
>>! In T53613#2529443, @matmarex wrote:
> "WT" is VisualEditor team's jargon for "wikitext". Wikitext editor's toolbar has buttons for this: {F4339790}
> 
> I'll note that there's a task to remove them: T40487. You could probably file a similar one for VisualEditor. But as long as one has them, the other should too.

Thanks for explanation.

So why instead of adding it to Visual Editor not removing it from WikiEditor then (which should be obviously easier)?
>>! In T53613#2529443, @matmarex wrote:
> "WT" is VisualEditor team's jargon for "wikitext".

Correct (though we didn't invent it).

> Wikitext editor's toolbar has buttons for this: {F4339790}
> 
> I'll note that there's a task to remove them: T40487. You could probably file a similar one for VisualEditor. But as long as one has them, the other should too.

Actually, VE will have one until it's banned in wikitext, not just "not easily accessible".
"WT" is VisualEditor team's jargon for "wikitext". Wikitext editor's toolbar has buttons for this: {F4339790}

I'll note that there's a task to remove them: T40487. You could probably file a similar one for VisualEditor. But as long as one has them, the other should too.
What does WT stand for?

What do you call feature-parity in this case?
>>! In T53613#2528664, @Danny_B wrote:
> We have headers and table captions providing semantically correct way how to emphasize headlining text. What is the use case of using big text elsewhere?

Off-topic. VE and WT are designed to have feature-parity. If you think we should ban users from using these, file a task.
We have headers and table captions providing semantically correct way how to emphasize headlining text. What is the use case of using big text elsewhere?
Change 141617 merged by jenkins-bot:
Provide tools to make text bigger or smaller

[[https://gerrit.wikimedia.org/r/141617]]
Change 141617 had a related patch set uploaded (by Jforrester):
Provide tools to make text bigger or smaller

[[https://gerrit.wikimedia.org/r/141617]]
Change 141617 had a related patch set uploaded by Jforrester:
Provide tools to make text bigger or smaller

https://gerrit.wikimedia.org/r/141617
--------------------------
**Version**: unspecified
**Severity**: enhancement
Now merged into master; will be deployed (as experimental) in the next push (so will be available on MediaWiki.org) - we will make this available to production wikis next week when we re-work the toolbar.
Change 78495 merged by jenkins-bot:
Create a subscript tool

https://gerrit.wikimedia.org/r/78495
Change 78495 had a related patch set uploaded by Steven Zhang:
Add subscript tool

https://gerrit.wikimedia.org/r/78495
An editor at en.wp has noted that subscript is requried to be able to correctly edit some articles, "ECG leads, e.g. V4" was the example given.
--------------------------
**Version**: unspecified
**Severity**: enhancement
Now merged into master; will be deployed (as experimental) in the next push (so will be available on MediaWiki.org) - we will make this available to production wikis next week when we re-work the toolbar.
Change 78490 merged by jenkins-bot:
Create a superscript tool

https://gerrit.wikimedia.org/r/78490
Change 78490 had a related patch set uploaded by Steven Zhang:
Add a superscript tool

https://gerrit.wikimedia.org/r/78490
As explained elsewhere, this is trivial to do but would make the toolbar (even more) unwieldy for all users, and so I de-prioritised it whilst waiting for a way to have lots of these icons available without filling everyone's screens with buttons most of them don't want to touch.

We're working right now on a first draft which we think will help with the clutter, at which point making these tools is a work of minutes.
A user at en.wp has noted the lack of a tool to set superscript means that the article [[Spiral Dynamics]] cannot be completely edited in VE.

The ability to set superscript and subscript are essential features for writing about many articles in the science, maths and technology fields, so it should be a core competence of the VisualEditor rather than a low-priority enhancement.
--------------------------
**Version**: unspecified
**Severity**: enhancement
Done by Peter C. at Wikimania 2013 Hacking Days. Yay.
Change 78019 merged by jenkins-bot:
Create strikethrough text style button

https://gerrit.wikimedia.org/r/78019
Change 78019 had a related patch set uploaded by Peter.C:
Create strikethrough text style button

https://gerrit.wikimedia.org/r/78019
--------------------------
**Version**: unspecified
**Severity**: enhancement
Now merged into master; will be deployed (as experimental) in the next push (so will be available on MediaWiki.org) - we will make this available to production wikis next week when we re-work the toolbar.
Change 78488 merged by jenkins-bot:
Create an underline tool

https://gerrit.wikimedia.org/r/78488
Change 78488 had a related patch set uploaded by Steven Zhang:
Create an underline tool

https://gerrit.wikimedia.org/r/78488
When viewing an article you have permission to edit, you see two tabs at the top - "Edit" and "Edit source". When viewing an article you don't have permission to edit, you see only one - "view source".

This is not good UI design There needs to always be the same number of tabs displayed. Ideally there should be tabs to "view source" and "view visual source" (with better wording though!), see Bug 51547.

If a read-only editor is not possible or not available then that tab needs to pop up a message saying that editing is restricted currently/until xx:xx for <log entry> and that they can view the wikitext source if they want (linked to an explanation what that means).

--------------------------
**Version**: unspecified
**Severity**: enhancement
Comment... I think it might be useful to have the suggested "view visual source" tab, primarily to enable copying content such as references between protected and non-protected articles. However, I do grok the additional layers of complexity this would entail...
A "read-only editor" is the view mode… I'm not really sure there's much value in going down the route, but instead we'd want to combine the two edit tabs together (except for users with VisualEditor disabled).
There should be a view-source equivalent for the visual editor so that people can see the page in VE as if the could edit it. It should allow them to interrogate things like template, so they can find out which template is producing what they see and how it does that. ~~When VE can cope with copy+paste, then~~ this will also allow them to copy and paste the relevant image/template/whatever to whatever article they are working on.

**See Also**:
* T54004
* T54091
(In reply to comment #0)
> There should be a view-source equivalent for the visual editor so that people
> can see the page in VE as if the could edit it.

This could get quite complex, but do-able if it's worth it.

> It should allow them to interrogate things like template, so they can find out
> which template is producing what they see and how it does that.

I can sort-of see the value here, but it's not great.

> When VE can cope with copy+paste, then this will also allow them to copy and
> paste the relevant image/template/whatever to whatever article they are working
> on.

We're probably going to want to do this with "read mode" HTML rather than build something like that (so, you copy something from the action=read and paste into veaction=edit and you get the template/etc. magically working).

Marking as "low" priority given difficulty and relatively low value for users; happy to be convinced otherwise.
I had OpenODBC's iODBC plugin installed in Safari (latest release, always). After any edit, EMBED tags would be inserted at the top and bottom of the article. This did not occur with the source editor, or any other editable widget, like this one I'm typing in now.

--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51423
Change 163961 merged by jenkins-bot:
Remove certain blacklisted elements when getting HTML from document

https://gerrit.wikimedia.org/r/163961
Change 163961 had a related patch set uploaded by Alex Monk:
Remove certain blacklisted elements when getting HTML from document

https://gerrit.wikimedia.org/r/163961
Can't see a link to a bug filed upstream -> rm upstream keyword
(In reply to PiRSquared17 from comment #10)
> This is now assigned to James Forrester.

No it isn't. Above line clearly says:

Assigned To: 	 VE team bugs – take if you're interested!
This is now assigned to James Forrester. Will a special test for this specific text be added? What can be done to fix this bug? Seems more like an upstream issue IMHO.
PiRSquared17 is right. This is not VE's fault. It only occurs in VE because of the way it sets up the editing area, which your plugin doesn't recognise as not to touch.

No and no.
"This is not VE's fault."

I am not at all certain of this. This problem ONLY occurs in VE. It does not occur in the source editor, or any other text editor across the whole wide web.

Something in VE is triggering this plugin to insert code. The plugin and the code it's inserting, is perfectly valid.
You could write an AbuseFilter to prevent edits like this. This is not VE's fault. There is a problem with the extension. Has anyone notified the author of said extension?
(In reply to comment #5)
> From my understanding, using this bug targetedly it is possible for Browser
> Add-Ons to insert malicious code in Wikipedia pages. The Wikipedia user will
> not even notice. I put importance to "immediate", in case I'm wrong please
> undo
> my change.

embed is not one of the allowed html tags when $wgRawHtml is disabled, so the embed tag is escaped as a security measure.  No malicious injection is possible via this bug.

The now archived discussion is
https://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28technical%29/Archive_114#Is_this_me_or_the_editor.3F

Examples:
https://en.wikipedia.org/w/index.php?title=The_Road_%282009_film%29&diff=prev&oldid=563739949
https://en.wikipedia.org/w/index.php?title=The_Road_%282009_film%29&diff=prev&oldid=564586766
https://en.wikipedia.org/w/index.php?title=Informix_Wingz&diff=prev&oldid=564587579
**wikipedia** wrote:

From my understanding, using this bug targetedly it is possible for Browser Add-Ons to insert malicious code in Wikipedia pages. The Wikipedia user will not even notice. I put importance to "immediate", in case I'm wrong please undo my change.
It is adding
<embed type="application/iodbc" width="0" height="0" />
Have you reported it to the author yet?
Actually my post over on the Village Pump *appears* to have turned up several other examples of plugins having the same problem. Not much more I can add though...

http://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)

Look for "Is this me or the editor?" (I can't get the section link to work)
Have you reported this upstream (i.e., to the author of the extension)? I don't this it's VE's fault, although I've seen similar stuff with another extension (FoxLingo):
[[m:en:Wikipedia:VisualEditor/Feedback/Archive_2013_07#Inserting_weird_script_tag_stuff]].

Actually, might be a more general bug, as these diffs have many similarities. I wonder if any other browser extensions do this.
The data->DOM converter should construct its DOM bottom-up, the way https://gerrit.wikimedia.org/r/74058 already does for annotations. This would enable us to do some cool things like:

* Pass childDomElements to nodes and meta items (already done for annotations)
* Pass data content in addition to DOM content?
* Allow nodes and meta items to unwrap themselves by returning an empty array (already done for annotations)
** We could implement unwrapping of generated wrapper paragraphs using this feature
* Possibly change the API so that instead of returning an array of DOM elements, the toDomElements function is responsible for appending its children.
** This could replace handlesOwnChildren, and enable model types with complex output

For DOM->data it's not as straightforward. We could experiment with bottom-up (outside-in, really) building there too, but it would be a bit less clear how things would work, and whether the copying involved would affect performance (although I believe we may already do a fair bit of copying around as it is).


This may be my pet project for my flight to Wikimania, or I may end up doing this sooner if there's time.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Ping on this bug.
(In reply to comment #0)
> * Possibly change the API so that instead of returning an array of DOM
> elements, the toDomElements function is responsible for appending its
> children.
> ** This could replace handlesOwnChildren, and enable model types with complex
> output
> 
This would also enable partial unwrapping of annotations, e.g. <p><a> Foo </a></p> -> <p> <a>Foo</a> </p>
Right now, ce.MWInternalLinkAnnotation obtains a DM rendering to get the computed href. We should factor out href computation so that this isn't needed.

--------------------------
**Version**: unspecified
**Severity**: normal
Change 90953 merged by jenkins-bot:
Get rid of dmRendering hack in ve.ce.MWInternalLinkAnnotation

https://gerrit.wikimedia.org/r/90953
Change 90953 had a related patch set uploaded by Catrope:
Get rid of dmRendering hack in ve.ce.MWInternalLinkAnnotation

https://gerrit.wikimedia.org/r/90953
(In reply to comment #2)
> (In reply to comment #1)
> > Change 86065 had a related patch set uploaded by Catrope:
> > Resolve rendered URLs according to the provided <base>
> > 
> > https://gerrit.wikimedia.org/r/86065
> This change tried to just get rid of href computation, but that's not good
> enough. It does need to actually be computed.

The most recent version of this change actually makes the hack worse, in order to partly fix bug 48915. Once that bug is fixed properly, this hack can be removed.
(In reply to comment #1)
> Change 86065 had a related patch set uploaded by Catrope:
> Resolve rendered URLs according to the provided <base>
> 
> https://gerrit.wikimedia.org/r/86065
This change tried to just get rid of href computation, but that's not good enough. It does need to actually be computed.
Change 86065 had a related patch set uploaded by Catrope:
Resolve rendered URLs according to the provided <base>

https://gerrit.wikimedia.org/r/86065
If someone is clicking on "Mobile View" and then back to "Desktop", a stopMobileRedirect cookie is left behind. This cookie will disable central notices on all wikimedia sites perpetually

--------------------------
**Version**: unspecified
**Severity**: enhancement
I'm marking this as wontfix.

While I see your point about not setting the stopMobileRedirect cookie for devices that wouldn't normally get automatically redirected (eg a desktop browser), we don't have a reliable way to detect that, so without rearchitecting, we can't really achieve this. Ultimately, we've been attempting to simplify how MobileFrontend works - partly for performance/caching reasons and partly for codebase sanity, and I do not think this usecase is compelling enough to warrant additional complexity.

I suspect Jon is right that with some CSS magic you may be able to resolve the specific issues you're running into with the banners. Otherwise, we should have a bigger discussion about how best for you guys to achieve what you need from within CentralNotice.
Is that zoomed in?
Does it disappear when you scroll?
Is it fixed position or absolute?

How can one access that banner on a phone - is there a url? Looks like with a few tweaks to the css that should be easy render correctly on a desktop view on a mobile screen...
**mwalker** wrote:

Illustration of why desktop banners should not be served to mobile users

Adam got this whilst browsing on the desktop site on his phone whilst logged out.

**Attached**: {F11712}
"With CentralNotice not filtering; true mobile users who choose to use the
desktop site may be presented with a banner that doesn't work on small screens
- e.g. the buttons are too small to hit with a finger."

This is a non-issue
The banner will be exactly the same size for users viewing the desktop site on a mobile device.
**mwalker** wrote:

(In reply to comment #4)
> You want to show a banner on the desktop site (en.wikipedia.org and friends)
> when viewed in a mobile phone?

Nope -- we want to show a banner on the desktop site to a desktop user who has previously used the mobile interface.

> Could you clarify "Removing the filtering comes at the expense of potentially
> exposing users to banners that don't work particularly well on small
> screens."

With CentralNotice not filtering; true mobile users who choose to use the desktop site may be presented with a banner that doesn't work on small screens - e.g. the buttons are too small to hit with a finger.

> Does this effect the mobile site (en.m.wikipedia.org and friends) in anyway?

No. Only the desktop site (and the transition of a desktop user between that and the mobile site and back.)

> I'm also unclear how this effects the VisualEditor roll out... (you mention
> this in the CentralNotice fix).

VE is only involved because we spotted it with a VE banner (they want to show to everyone so we're getting lots of interesting CN bugs.)

> The stopMobileRedirect cookie exists for a reason - if a user of the mobile
> site wants to see the desktop site this stops them from being redirected on
> every visit.

Yep, understood. The feature request is more to not return 'desktop' devices to the desktop site after having viewed the mobile site with a stopMobileRedirect cookie.

> We could only set the stopMobileRedirect cookie if the user is on a mobile
> phone but this is messy and I don't see what value the work put in to achieve
> this would gain. Does anything really need to change in MobileFrontend now?

Meh; don't know. This is an edge case... It's more related to if we have more things that are device dependent using the cookie to determine if someone is on a big device or not.
Just to check I understand the problem correctly:
You want to show a banner on the desktop site (en.wikipedia.org and friends) when viewed in a mobile phone?
Was there any reason you didn't do this before? I don't really understand the logic... ResourceLoader disables JavaScript on older phones so these banners should work perfectly fine.

Could you clarify "Removing the filtering comes at the expense of potentially exposing users to banners that don't work particularly well on small screens." - if a mobile views the desktop site on their phone they will either use a modified viewport [1] and the banner will look exactly the same as desktop, or if there is no viewport the entire website will be unreadable so I'd be surprised they'd even be in desktop mode.

Does this effect the mobile site (en.m.wikipedia.org and friends) in anyway?

I'm also unclear how this effects the VisualEditor roll out... (you mention this in the CentralNotice fix).

The stopMobileRedirect cookie exists for a reason - if a user of the mobile site wants to see the desktop site this stops them from being redirected on every visit.

We could only set the stopMobileRedirect cookie if the user is on a mobile phone but this is messy and I don't see what value the work put in to achieve this would gain. Does anything really need to change in MobileFrontend now?

[1] http://www.quirksmode.org/mobile/viewports2.html
Change 73999 merged by jenkins-bot:
(Bug 51465) No Longer Filtering Mobile Devices

https://gerrit.wikimedia.org/r/73999
Change 73999 had a related patch set uploaded by Mwalker:
(Bug 51465) No Longer Filtering Mobile Devices

https://gerrit.wikimedia.org/r/73999
**mwalker** wrote:

Fundraising's initial response is going to be just to just remove the filtering -- however, it would be a good feature for mobile frontend if that cookie was somewhat smarter (enough to remove itself when not needed / or track where it came from originally: varnish vs url click.)

Removing the filtering comes at the expense of potentially exposing users to banners that don't work particularly well on small screens.
There is consensus for a change to this element here: http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Dustbin_icon_not_intuitive_for_.22unlink.22

To summarize - the garbage can icon to remove a link is not intuitive.  Users may be unsure of its function, or believe it will remove the highlighted text, rather than just the link.  Most other editing UI's employ a broken link for this function, so it will be more familiar.

Suggested improvement:

*Replace "Garbage Can/Dustbin" with a "broken link" icon (example:http://us.fotolia.com/id/49483380)

*Replace current rollover text "Remove" with "Unlink"

--------------------------
**Version**: unspecified
**Severity**: enhancement
We've decided instead to remove the use of icons here as it's too confusing, and instead will use just the label.
See:
http://en.wikipedia.org/w/index.php?title=User%3ACananian&diff=564446937&oldid=564446873

I was adding a heading (after a <!-- ... --> comment) and the diff stuck a <br> inside the ==heading==.

I'm assigning this bug to VE for the moment, but it could be a parsoid bug.  I need to see the intermediate parsoid HTML generated for the change to tell one way or the other.

--------------------------
**Version**: unspecified
**Severity**: minor
Parsoid now normalizes this HTML to strip <br> from headings - the code is now in production.
Change 253050 merged by jenkins-bot:
T53444: Strip <br>s from headings via new HTML normalization routine

[[https://gerrit.wikimedia.org/r/253050]]
Change 253050 had a related patch set uploaded (by Subramanya Sastry):
T53444: Strip <br>s from headings via new HTML normalization routine

[[https://gerrit.wikimedia.org/r/253050]]
If you want an example of how that happens on a private wiki, see above line 114 [[ https://office.wikimedia.org/w/index.php?title=Community_Engagement_(Product)/Editing&diff=prev&oldid=158096 | here ]]. It doesn't involve hidden comments.
Unless it advances the consistency of parsing, I am not convinced this is worth a lot of effort beyond normalization during serialization. The WYSIWYG behavior is clearly an edge-case since wikitext does not support multi-line headings. So, if VE folks are with it, I am fine with it.
WYSIWYG is tricky here.  In this case, the user clearly saw the entire paragraph, including the newline, being styled as part of the heading.  If we handle this during normalization, then the result after saving will not be consistent with what the user saw during editing.

@Jdforrester-WMF It's //possible// that existing-tidy wouldn't remove `<p><!--comment--></p>` because of the embedded comment.  Currently PHP elides all the comments, so it hands tidy the string `<p></p>` which tidy happily removes.  So it's possible we could finesse this somehow, for example by emitting a stub comment from the PHP parser.  Investigation needed.
Maybe worth handling this in the normalization routines.
Would fixing the PHP Parser require us to have replaced Tidy first, then?
The original document was serialized with the `<br/>`:
```
$ (echo 'foo' ; echo; echo '<!--comment-->'; echo; echo 'bar') | tests/parse.js  --normalize=parsoid

<p>foo</p>
<!--comment-->
<p><br/> bar</p>
```
I wonder if we should be generating `<p><!--comment--></p>` for that case, instead of the `<br/>` embedded inside the next paragraph.  Our current behavior is consistent with PHP:
```
$ (echo 'foo' ; echo; echo '<!--comment-->'; echo; echo 'bar') | php maintenance/parse.php --quiet
<p>foo
</p><p><br />
bar
</p>
```
...but it's certainly not ideal from an editing perspective.  Maybe PHP should change here as well, although I'm guessing the reason it is putting the `<br/>` inside the `<p>` is because otherwise `tidy` would strip the "empty" `<p>` tag.

In any case, given this input DOM, VE's behavior is strange but understandable -- when you put your cursor between the exclamation mark and the last written line, VE is placing its internal insertion point between the `<p>` and the `<br/>`, so any heading conversion applies to the entire `<p>` contents, including the embedded `<br/>`.  The result that VE passes back to parsoid is then unsurprising:
```
<p id="mwAQ">some text</p> <!-- hidden comments FTW --><h2>Foo<br id="mwAw"> moar text here</h2>
```
and Parsoid gives a faithful serialization of this as wikitext.
The page is nominated for deletion, but [[https://en.wikipedia.org/w/index.php?title=Sabaragamuwa_Province_(Sri_Lanka)_bus_routes&diff=next&oldid=654323182| here's another example]].
Providing steps.
1) Start with [[ https://test.wikipedia.org/w/index.php?title=User:Elitre_(WMF)/Sandbox&diff=prev&oldid=223541 | a new or a blank page ]].
2) In wikitext mode, [[ https://test.wikipedia.org/w/index.php?title=User:Elitre_(WMF)/Sandbox&diff=next&oldid=223541 | write something on the first line, leave a blank line, write a hidden comment, leave a blank line, write something else ]], then Save.
3) Now enter VE mode. Notice the hidden comment is correctly displayed as an exclamation mark; there is now a carriage return sign at the beginning of the last line. 
4) Put the cursor in the blank line between the comment and the last written line. You can now write any word, select it and turn it into a heading or a subheading; notice the entire line below, including the carriage return sign, also becomes part of said heading/subheading.
5) Save. [[ https://test.wikipedia.org/w/index.php?title=User%3AElitre_%28WMF%29%2FSandbox&diff=223543&oldid=223542 | You now have wikitext for the heading/subheading you just made, showing up in plain sight ]]. You can also notice that the carriage return character was turned into a br tag.

Reproducible: Always.
Tested in Win 8 with the latest versions of Chrome, Firefox, IE, Opera (the last two while logged out).
Providing steps.
1) Start with [[ https://test.wikipedia.org/w/index.php?title=User:Elitre_(WMF)/Sandbox&diff=prev&oldid=223541 | a new or a blank page ]].
2) In wikitext mode, [[ https://test.wikipedia.org/w/index.php?title=User:Elitre_(WMF)/Sandbox&diff=next&oldid=223541 | write something on the first line, leave a blank line, write a hidden comment, leave a blank line, write something else ]], then Save.
3) Now enter VE mode. Notice the hidden comment is correctly displayed as an exclamation mark; there is now a carriage return sign at the beginning of the last line. 
4) Put the cursor in the blank line between the comment and the last written line. You can now write any word, select it and turn it into a heading or a subheading; notice the entire line below, including the carriage return sign, also becomes part of said heading/subheading.
5) Save. [[ https://test.wikipedia.org/w/index.php?title=User%3AElitre_%28WMF%29%2FSandbox&diff=223543&oldid=223542 | You now have wikitext for the heading/subheading you just made in plain sight ]]. You can also notice that the carriage return character was turned into a br tag.

Reproducible: Always.
Tested in Win 8 with the latest versions of Chrome, Firefox, IE, Opera (the last two while logged out).
No reproduction steps in > 18 months. If you can give some more details, please re-open.
(BTW, I really couldn't play that vid on YouTube.)
The steps are clear in AzaToth's video, but I can't reproduce that either: have you fixed something about ↵ being displayed, this week?
Does anyone have any steps to reproduce? I can't reproduce in Firefox or Chrome whilst playing around…
Also reported at https://fr.wikipedia.org/w/index.php?title=Cabinet_des_estampes_et_des_dessins_de_Strasbourg&curid=1591028&diff=96701784&oldid=96701717
Also reported at http://mr.wikipedia.org/w/index.php?title=%E0%A4%9F%E0%A4%BE%E0%A4%95%E0%A4%A3%E0%A4%95%E0%A4%BE%E0%A4%B0_(%E0%A4%B8%E0%A4%AE%E0%A4%BE%E0%A4%9C)&curid=66935&diff=1193242&oldid=1193112 .
*** Bug 52021 has been marked as a duplicate of this bug. ***
AzaToth made a screencast at http://youtu.be/G_xXETTVgO0 showing the issue.

Gwicke filed bug 50683 on the parsoid side -- we shouldn't allow newlines in a heading when we serialize to wikitext.

But there's still a VE issue -- where is the ↵ coming from (visible in AzaToth's screencast).  VE shouldn't be putting the newline inside the heading.
See also https://www.mediawiki.org/w/index.php?title=User%3AGWicke&diff=723931&oldid=655405

So the <!-- ... --> comment doesn't seem to have anything to do with it.
```
[subbu@earth:~/work/wmf/parsoid] echo '<a rel="mw:WikiLink" href="./Foobar">:foobar</a>' | php bin/parse.php --html2wt
[[:foobar]]

[subbu@earth:~/work/wmf/parsoid] echo '<a rel="mw:WikiLink" href="./Foobar">:foobar</a>' | php bin/parse.php --html2html --body_only
<p data-parsoid='{"dsr":[0,11,0,0]}'><a rel="mw:WikiLink" href="./Foobar" title="Foobar" data-parsoid='{"stx":"simple","a":{"href":"./Foobar"},"sa":{"href":":foobar"},"dsr":[0,11,2,2]}'>foobar</a></p>
```
(In reply to comment #11)
> My point is mainly that VE could easily understand when the punctuation is
> added by mistake, because the label and the target link will be different. So
> if the target does not feature a punctuation mark, but the label does, that
> was probably not wanted. 

Unfortunately we have to handle the case when it was intentional, so we can't just blindly auto-correct it. Also the definition of what is punctuation becomes much more complex when you are dealing with thousands of languages.
This is a Parsoid bug (the colon part, at least):

<a rel="mw:WikiLink" href="./Foobar">:foobar</a>

serialises to:

[[:foobar]]

which converts back to

<a rel="mw:WikiLink" href="./Foobar">foobar</a>
I am leaving aside the semicolon issue, covered elsewhere.
About what I reported in Comment 5:

1) Type ":foobar"
2) select all of this, from the colon (included) to the final r
3) click on the linking tool, and make this a link to the article "foobar"
4) save.
*outcome: the colon is included in the link; the link is working but the colon is invisible (and I think this is certainly not desirable).

Please note that this also happens to ": foobar", that is, if the colon and the typed word are separated by a space.


1) Type "foobar:"
2) select all of this, from the f to the colon, including it
3) click on the linking tool, and make this a link to "foobar"
4) save.
*outcome: the colon is included in the link, it is visible, the link works fine (and I think this is not good code).

Please note that when a piped link is created instead (for example if foobar is a link to Foobar2000), the colons will be part of the link in every case and they will all be visible.

My point is mainly that VE could easily understand when the punctuation is added by mistake, because the label and the target link will be different. So if the target does not feature a punctuation mark, but the label does, that was probably not wanted. 

HTH.
This is indeed reproducable, and not just with semi-colons, but it is not this bug. I've reported it separately as bug 54332 including how to reproduce it.
Can you leave some step-by-step instructions to reproduce the bug for clarification?
About semicolons, we got another feedback that I managed to reproduce, see https://en.wikipedia.org/w/index.php?title=User%3AElitre_%28WMF%29%2FSandbox&diff=573644513&oldid=573644268 .
I wrote French; and turned that into a wikilink, including the semicolon.
Then I added some text between the end of the word and the semicolon. The result is that we now have two wikilinks to the same word, and a nowiki tag in the middle.
Yes Ed, in both cases I selected the colon and the word and then used the link tool. I know that you can get the first result also in the source editor, but the second one definitely does not produce a working link with the source editor, and anyway I was not really sure if it makes sense having a wikilink which includes a colon and then makes it invisible. If you think none of these behaviours should be prevented or worked on anyway, please just re-close this. Thanks.
Can you explain how those cases were created. From what I can see colons don't extend link annotations, but if you select over a colon and use the link tool you're going to end up with weird stuff like that anyway.
I am reopening this since I noticed that colons at least still get included in the links: here https://en.wikipedia.org/w/index.php?title=User%3AElitre_%28WMF%29%2FSandbox&diff=573483719&oldid=573483114 the line beginning with "Performance problems: VisualEditor" has the colon included in the wikilink of the lattest word; the link works fine but you don't get to see the colon at all.
https://en.wikipedia.org/w/index.php?title=User:Elitre_(WMF)/Sandbox&diff=next&oldid=573483774 Here instead it is included in the wikilink to Issues, and I am not sure it's desirable either. Thanks.
(In reply to comment #3)
> Links are no longer getting extended automatically when any text is added at
> the end, including commas, semicolons, etc. Possibly a result of the fix for
> bug 51463

Indeed, this was fixed in that.
Links are no longer getting extended automatically when any text is added at the end, including commas, semicolons, etc. Possibly a result of the fix for bug 51463
(In reply to comment #1)
> instead of just the former (perhaps some kind of inline block wrapper around
> the link, e.g. like Apple does in Mail and Calendar when text contains a
> reference to a contact. It looks like "Foo { bar } quux." Where bar has a
> rounded bubble around it when hovered and the cursor can be placed inside or
> outside the bubble.

)

http://xkcd.com/859/
I don't think we should explicitly disallow such symbol to be used in the label (might lead to other strange side-effects and inconsistencies).

However it does give another use case for bug 51438. Having a better way to edit the label might reduce the cases where this happens. Perhaps we could make it possible to put the cursor inside the link (after the last character) and outside the link.

So that one can be in either of these positions:

 * Foo <a>bar|</a>
 * Foo <a>bar</a>|

instead of just the former (perhaps some kind of inline block wrapper around the link, e.g. like Apple does in Mail and Calendar when text contains a reference to a contact. It looks like "Foo { bar } quux." Where bar has a rounded bubble around it when hovered and the cursor can be placed inside or outside the bubble.
Currently, if you use TemplateData for a template without any parameters, you still have to create an empty "params" in the JSON (not really important), but you also end up with a "Template parameters" table with just the title line (Parameter	Description	Type	Default	Status).

Rather than displaying an empty table, I think it would be better to display no table at all, or a simple message saying that no parameters are defined for this template.

--------------------------
**Version**: unspecified
**Severity**: minor
The fix in beta:
 {F45817}

vs test2:  
{F45819}
Change 191518 merged by jenkins-bot:
Display a message when no parameters are defined

[[https://gerrit.wikimedia.org/r/191518]]
Change 191518 had a related patch set uploaded (by Mooeypoo):
Display a message when no parameters are defined

[[https://gerrit.wikimedia.org/r/191518]]

#patch-for-review
It would also be useful if you could set "no parameters" in the TemplateData so that VisualEditor does not suggest adding a parameter for these templates.
*** Bug 62417 has been marked as a duplicate of this bug. ***
Seeing this more often now with VE and think it may be a couple different issues (not all on our side) but want to see what we can do to stop it and or lessen impact. This is currently being added to the security queue because I'm a bit concerned about some of the symptoms and worry it could be an injection vulnerability (see below). If we rule out a security concern I'm obviously happy with it being moved.

Editors are making a normal edit and div's are being inserted like 

<div id="myEventWatcherDiv" style="display:none;"></div>

often at the start and end of the page. 

Googling around it seems they may be inserted by a common 3rd party plugin (divX?) but it is in no way clear. It also seems to be interacting weirdly with VE because it isn't only being inserted it's inserting WITHOUT <nowiki> tags which is what you'd expect if someone put a div in (see https://en.wikipedia.org/w/index.php?title=User:Jalexander/sandbox&diff=564465081&oldid=553572859 ). Could it be being injected somehow around VE and/or parser? 

Examples:
https://en.wikipedia.org/w/index.php?title=Spank!_The_Fifty_Shades_Parody&diff=prev&oldid=564448990
http://en.wikipedia.org/w/index.php?title=Kendra_Morris&diff=prev&oldid=564426900

--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51521
>>! In T53423#1031831, @Aklapper wrote:
> This task has #VE-deploy-2014-10-02 but is still open. Should this be retargetted?

No.
This task has #VE-deploy-2014-10-02 but is still open. Should this be retargetted?
Still seems to be happening, e.g. https://fr.wikipedia.org/?diff=108255165
Change 163961 merged by jenkins-bot:
Remove certain blacklisted elements when getting HTML from document

https://gerrit.wikimedia.org/r/163961
Change 163961 had a related patch set uploaded by Alex Monk:
Remove certain blacklisted elements when getting HTML from document

https://gerrit.wikimedia.org/r/163961
Has anyone here managed to actually get this to happen in their browser yet? James tried the DivX plugin in Safari on his Mac and couldn't get it to insert the bad content.
(In reply to comment #16)
> Sorry meant http://en.wikipedia.org/wiki/Special:AbuseFilter/345

Thanks - though we should probably silently remove on save inside VisualEditor, like Inez suggests.
Sorry meant http://en.wikipedia.org/wiki/Special:AbuseFilter/345
Detected and warning issued by the abuse filter http://en.wikipedia.org/wiki/Special:AbuseFilter/485
for the record it happened in fr.wp : https://fr.wikipedia.org/w/index.php?title=Les_Fourmis_%28Werber%29&diff=96415737&oldid=89791930
@James: Should we go for silent remove on safe? Also we can start tracking it with information about logged in vs. logged out user.
I am also curious to know why it only happens to anonymous editors - at least, all the occurrences I have seen so far.
On it.wp as well: http://it.wikipedia.org/w/index.php?title=Tank_Palamara&diff=60582899&oldid=60582688
Silently remove on save. Hacking blacklist will prevent people from saving and many of them are not technical enough to understand why - bad bad user experience.
(In reply to comment #8)
> As a workaround for now we could make VE remove those divs from the HTMLDOM
> that it is sending to MW API for serializing. @James: Should we do it?

You mean, have a blacklist of items to just silently remove on save? Could work as a quick hack.
As a workaround for now we could make VE remove those divs from the HTMLDOM that it is sending to MW API for serializing. @James: Should we do it?
(In reply to comment #6)
> Making this public since I don't see this having any security impact. Then
> the
> community can also give input into how they want to see it handled.

Thanks Chris
Making this public since I don't see this having any security impact. Then the community can also give input into how they want to see it handled.
(In reply to comment #2)
> It's certainly a type of edit we really don't
> want but more importantly I'm confused about how it's getting inserted and
> avoiding the normal VE/parser work flow which should <nowiki> it (instead of
> actually inserting it in as a div like it is now).
It's possible that the plugin inserts it in all <iframe>s. We use <iframe>s internally for encapsulating HTML documents.
(In reply to comment #2)
> I'm confused about how it's getting inserted and
> avoiding the normal VE/parser work flow which should <nowiki> it (instead of
> actually inserting it in as a div like it is now).

It looks like it's bypassing the browser's events model and just inserting into the DOM, hence the issue. JS like VE isn't able to notice things outside the JS events model, sadly.
(In reply to comment #1)
> Hi James, the google consensus seems to be that a DivX plugin is inserting
> that. 
> 
> http://padawan.info/en/2011/03/wtf-is-this-myeventwatcherdiv-doing-in-my-web.
> html
> 
> I'm guessing that VE's interface suddenly looks like something the plugin was
> expecting to use in the browser, and so it silently adds the div.
> 
> We could add an abusefilter rule to block those edits, but that seems a
> little drastic.

Ideally we'd want a global AbuseFilter rule that just silently dropped the content from the edit, but that's not a feature AF currently does. :-)

Blocking is a bit strong, though possibly likely to happen from the community if we just warn users and they ignore. The only fix (other than getting the upstream plugin crap fixed, which seems unlikely) is to do the auto-drop in VE, which is icky too.
yeah, that seems to be the consensus I could find too (which is very very weird... because I can't for the life of me find a 'legitimate' reason it should insert that into any page it can edit.. oh well certainly not the weirdest plugin BS I've seen). 

Actually I don't think that's very drastic to do, the community almost certainly would agree and I'd pass it off to them (though they'll likely blame us for it which is never fun). It's certainly a type of edit we really don't want but more importantly I'm confused about how it's getting inserted and avoiding the normal VE/parser work flow which should <nowiki> it (instead of actually inserting it in as a div like it is now).
Hi James, the google consensus seems to be that a DivX plugin is inserting that. 

http://padawan.info/en/2011/03/wtf-is-this-myeventwatcherdiv-doing-in-my-web.html

I'm guessing that VE's interface suddenly looks like something the plugin was expecting to use in the browser, and so it silently adds the div.

We could add an abusefilter rule to block those edits, but that seems a little drastic.
In view mode, [[Template:Top icon]] places the featured star or good article at the top right hand corner.

After loading a FA or GA or English Wikipedia, the featured star or good article icon appears where the template is, which is often down the bottom.  This is perfectly acceptable except for the 'where did it go?' feeling, but maybe a plugin could come up with a better UI design for topicons, geocoords, etc.

Also templates without any real estate (like {{Use dmy dates}} and {{Use Australian English}}) 'disappear' entirely.

https://en.wikipedia.org/wiki/Angels_Brought_Me_Here?veaction=edit

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51322
Now that bug 23796 is fixed, we "just" need to work out a way to let the user set/unset these (bug 72199) and then trap clicks on this area to open the meta dialog, I think?
This is a rather more general problem with the Vector skin (there's desire to have flag icons from the content, but no ability other than a hack that's unsupportable in VisualEditor).
Bug 51322 fixed issues that were 'solely metadata', but these actually do produce elements, the problems that remain for these elements are:
1: incorrectly positioned
2: their template edit button, when selected is visually placed far from the content, making it difficult to find. bug 50854
3: if they were correctly positioned, they are 'decoupled' from their anchor point  which is a problem with templates producing floating content as well. bug 50907
The meta-templates bug 51322 has been marked as fixed, but the issue of top icons is still ongoing.
'templates without any real estate' has been raised already as bug 51322 (meta templates).
It is easy to delete these hidden templates without noticing.

e.g. delete the '↵﻿' on Angels Brought Me Here.
The 'templates without any real estate' problem is raised here:

https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Time_for_an_essay

I'm not sure if a separate bug has been raised, or even should be.  The top icons and templates without any real estate all need a special UI, probably under 'page settings'.
Forked from the original request at bug 48666 which was solved by making the preference hidden, as intended.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Change 130075 merged by jenkins-bot:
Add dynamically generated list of namespaces to visualeditor-enable preference

https://gerrit.wikimedia.org/r/130075
Change 130075 had a related patch set uploaded by Alex Monk:
Add dynamically generated list of namespaces to visualeditor-enable preference

https://gerrit.wikimedia.org/r/130075
As in Bug T53330, I would like to request the icon for "Bold" to be an "N" (from "Negrito") in Portuguese ("pt" and "pt-br").
This was fixed and deployed yesterday.
Use case:
* The user opens VisualEditor
* The user types something that looks like wikitext
* VE notices and displays an mw.notify bubble with autoHide:false
* The user leaves VE by clicking on the Read tab
* The editor is torn down and we go back to view mode, but the bubble persists

I would like to be able to remove this bubble when the editor is torn down, but mw.notification doesn't expose an API for this. There is a .close() method on Notification, but there's no way to get the Notification object created by mw.notify().

--------------------------
**Version**: 1.22.0
**Severity**: enhancement
Change 74407 merged by jenkins-bot:
mediawiki.notification: Expose close method to hide a Notification

https://gerrit.wikimedia.org/r/74407
Change 74407 had a related patch set uploaded by Alex Monk:
Return Notification object from mw.notification.notify

https://gerrit.wikimedia.org/r/74407
(In reply to comment #2)
> I'd say that this is expected behavior and a "feature" of the shorthand. Just
> like you can't have a message parsed by just doing mw.msg(), you have to use
> mw.message().whatever() instead.
> 
> Alex's solution makes sense at a glance.
Returning the Notification object would fix this, yes. Unfortunately, that change is still pending review.
I'd say that this is expected behavior and a "feature" of the shorthand. Just like you can't have a message parsed by just doing mw.msg(), you have to use mw.message().whatever() instead.

Alex's solution makes sense at a glance.
I had this problem in Gerrit change 5130. Had to depend on mediawiki.notification, add a 'return notif' to the mw.notification.notify function and use that instead of mw.notify.
If an article has 

[external link]
[external link]

It is rendered in VE as:

[external link]↵[external link]

Selecting the ↵ and pressing delete causes the ↵ to be removed, however the link break is not removed, and saving says that there are no changes.

Example:
https://en.wikipedia.org/wiki/Otis_%28album%29?veaction=edit

--------------------------
**Version**: unspecified
**Severity**: normal
This appears to work correctly now.

(The article no longer has this wikitext now, but I tried on an older version: https://en.wikipedia.org/w/index.php?title=Otis_(album)&oldid=512105119&veaction=edit – be sure to only preview changes and do not accidentally save the article.)
Possibly a Parsoid bug?
The way VisualEditor handles links with square brackets, but no explicit anchor, can be confusing.  These links are generally discouraged on English Wikipedia, but still occasionally used.

An example is https://en.wikipedia.org/w/index.php?title=User:Superm401/Sandbox&veaction=edit&oldid=564175896 .  The wikitext for this is just [http://example.com], which renders as a linked [1] (or whatever number it is in the page)

However, you should edit the latest version of a page for testing this.  When you edit an oldid page, you won't be able to reproduce the "Save page" disable behavior I mention below.

VisualEditor lets you backspace to remove the characters one by one, which does not really reflect the model of how the link works.  After one or more is removed, "Save page" un-greys.  However, when you go to review the changes, it says, "Could not start the review because your revision matches the latest version of this page."

It does let you remove the link entirely, but to do so you need to explicitly remove each character (not just backspace once to delete the whole thing).

Do a fresh load of the edit page (separate test).  Then, click the chain icon next to the link.  Then, press enter twice to exit the link dialog.  This time, review changes works.  The wikitext becomes:

[http://example.com <nowiki>[1]</nowiki>]

It probably should not change the link if you simply enter the link dialog and press enter without changing anything.  Also, forcing it to text like this is inconsistent with what happens if you delete the right bracket (see above).

--------------------------
**Version**: unspecified
**Severity**: enhancement
(In reply to Matthew Flaschen from comment #9)
> Is it possible to convert an auto-numbered link to one with arbitrary text
> (that's what the second part of the bug title refers to)?

Yes, that's been possible for a while. In https://meta.wikimedia.org/wiki/Tech/News/2014/27?veaction=edit for example, click on one of the auto-numbered links to edit it, then click "add label" to convert it to a "normal" link.
Is it possible to convert an auto-numbered link to one with arbitrary text (that's what the second part of the bug title refers to)?
Change 143346 merged by jenkins-bot:
Make it possible to create autonumbered external links from link inspector

https://gerrit.wikimedia.org/r/143346
(In reply to Bartosz Dziewoński from comment #6)
> (In reply to James Forrester from comment #2)
> > You cannot …

[…]

> > * … convert an auto-numbered external link to a real external link; or
> 
> You can do that from ve.ui.MWLinkNodeInspector now, I don't know when it was
> implemented.

Yes, that was fixed a month or so ago with the creation of MWLinkNodeInspector.
(In reply to James Forrester from comment #2)
> You cannot …
> 
> * … create an auto-numbered external link; 

My patch https://gerrit.wikimedia.org/r/143346 implements this.

> * … convert an auto-numbered external link to a real external link; or

You can do that from ve.ui.MWLinkNodeInspector now, I don't know when it was implemented.

> * … "clear formatting" on an auto-numbered external link.
> 
> I think the first two are valuable, but the third isn't, because we're
> planning to remove the function of removing links and other rich styling
> from the "clear formatting" function button.

I don't think treating it as "formatting" makes sense anyway.
Change 143346 had a related patch set uploaded by Bartosz Dziewoński:
Make it possible to create autonumbered external links from link inspector

https://gerrit.wikimedia.org/r/143346
(In reply to Matthew Flaschen from comment #3)
> (In reply to Matthew Flaschen from comment #0)
> > VisualEditor lets you backspace to remove the characters one by one, which
> > does not really reflect the model of how the link works.
> 
> This is fixed.  It now highlights on first backspace, and erases on second,
> which I think is handled the same as similar things.

Yeah, sorry, forgot to say "we've done a bunch of work on auto-numbered external links since this bug was filed, so most of this is fixed, however…" at the top. :-)
(In reply to Matthew Flaschen from comment #0)
> VisualEditor lets you backspace to remove the characters one by one, which
> does not really reflect the model of how the link works.

This is fixed.  It now highlights on first backspace, and erases on second, which I think is handled the same as similar things.
Current status:

You can …

* … edit the target of an auto-numbered external link to a different external link; and 
* … edit the target of an auto-numbered external link to an internal link, and the anchor will automatically be set as the internal link value.


You cannot …

* … create an auto-numbered external link; 
* … convert an auto-numbered external link to a real external link; or
* … "clear formatting" on an auto-numbered external link.

I think the first two are valuable, but the third isn't, because we're planning to remove the function of removing links and other rich styling from the "clear formatting" function button. Re-titling, setting priority.
Also, if you highlight it, then use "Clear formatting", it does nothing.  I'm not sure what it should do (nowiki the URL?), but if it does nothing it should be greyed out.
From English Wikipedia, John Broughton (♫♫) 22:40, 12 July 2013 (UTC):

It's not a high priority, but still, a suggestion: the default search text, for an image search, is the complete page name. So, for example, if someone is editing a draft article, at User:WhateverEditorName/Article name, the default search text is "WhateverEditorName/Article name". It would be better if the default ignored the final slash and all text to the left of it; in this case, it would mean the default search would be "Article name".

--------------------------
**Version**: unspecified
**Severity**: enhancement
Change 137151 merged by jenkins-bot:
Use subpage only for media search string

https://gerrit.wikimedia.org/r/137151
Change 137151 had a related patch set uploaded by Mooeypoo:
Use subpage only for media search string

https://gerrit.wikimedia.org/r/137151
(In reply to comment #5)
> No, not everyone has the editbugs permission.

See bug 40497 for the editbugs problem.
No, not everyone has the editbugs permission. Andre can give you it, CCing him.
Ah, I see. :) I don't actually know if everyone has the rights to do so - bugzilla is a strange and wondrous land to me.
You missed my main point in the title : it's text "before" the / that should be ignored, not the text "after" ;-)

I don't see how I can change bug titles. Are you sure everyone has the rights to do so ?
The only things I can do is add a comment, add an attachment, ...
I've changed it. Titles are editable in bugzilla, much like wikitext. :)
Bug title is incorrect, it would rather be something like "Default search text for images should ignore text before /"
When using the Maxthon browser, clicking on a link (wiki or external) opens the link instead of allow ther to alter the link object.

After the linked page is opened, returning to the VE shows the link object icon which alllows the link to be altered.

--------------------------
**Version**: unspecified
**Severity**: normal
It works better than Google Chrome. :P  See bug 51270.
Sounds like we may need to blacklist the Maxthon browser. :-(
Copied from English Wikipedia:

Editing Gol Transportes Aéreos Flight 1907#Criminal proceedings I added two cleanup templates, {{update}} and {{prose}}. In the visual editor the two templates were differently left-aligned and different lengths, despite saving and displaying correctly. Reopening the page in the visual editor, the templates appear at their correct size and alignment, but do appear with an apparent blank line between them. Thryduulf (talk) 14:04, 12 July 2013 (UTC)

See screenshot: 
http://en.wikipedia.org/wiki/File:Visual_Editor_screenshot_-_templates_not_aligned.png

****
I could replicate this on Firefox (Windows 7) but not Chrome.

--------------------------
**Version**: unspecified
**Severity**: minor
Looks fine to me now?
I was following Sherry's kind advices in my sandbox at enwp http://en.wikipedia.org/wiki/User:Elitre_(WMF)/Sandbox:
<<you can create an {{Infobox person}}, with parameters like "name" and "occupation".  Within those parameters, you can type the wikicode for any templates you want.  For example, you can give it a name parameter of "Alice Expert((citation needed|date=July 2013}}", which later gets processed properly as a template. >>
An infobox appeared (well, a box with my sandbox title, actually), I saved, "your edit was saved" message appeared, the box isn't in the page anymore.
Tried again, same thing. No trace of my activity in the history. Win 7, Vector, both Chrome and FF.

Thanks,
E.

--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52640
Change 150419 merged by jenkins-bot:
Don't show PostEdit message if we made a null edit

https://gerrit.wikimedia.org/r/150419
Change 150419 had a related patch set uploaded by Alex Monk:
Don't show PostEdit message if we made a null edit.

https://gerrit.wikimedia.org/r/150419
Confirmed that this is still broken for VisualEditor (and not for wikitext editing).
**swalling** wrote:

(In reply to comment #3)
> This is the same behaviour as the wikitext editor. We really should fix this
> there first if we're changing behaviour for VisualEditor, so that they match.
> 
> CC'ed Steven - is there interest in changing for this case in core?

As far as I know, this problem is solved for the wikitext editor. We should not be showing the post-edit confirmation on null edits. I just re-tested this to confirm with a null edit to an article. Is there something special about Elitre's case that I should try to replicate?
This is the same behaviour as the wikitext editor. We really should fix this there first if we're changing behaviour for VisualEditor, so that they match.

CC'ed Steven - is there interest in changing for this case in core?
It might be worth adding that this actually works for Sherry:
http://en.wikipedia.org/w/index.php?title=User:Whatamidoing_(WMF)/sandbox&action=history .
It must be the "template within a template" thing, because it will save without that part. 
Thanks,
E.
Screenshot

Previously we had an issue that the cite extension would throw an error if you had a reference inside a template. That message is now suppressed, but only suppressed - it generates a substantial visual artefact on mouseover that previously contained the error message. See screenshot.

--------------------------
**Version**: unspecified
**Severity**: minor

**Attached**: {F11227}
I believe that this has been fixed for some time; I cannot replicate now.
A few users at itwp requested that the list of articles you can choose as a wikilink target supports right-click on each title to view the page in another tab; and that disambiguation pages in the same list appear differently (maybe italicized as it currently happens in MediaWiki special pages?) Thanks!

--------------------------
**Version**: unspecified
**Severity**: enhancement
Verified the fix in test2 and production.
The fix is verified in betalabs(beware of a difference between Link and Simple link!). The fix applies to the Link.
Change 171488 merged by jenkins-bot:
Matching pages from suggestions in link dialog now actually work as links

https://gerrit.wikimedia.org/r/171488
Change 171488 had a related patch set uploaded by SuchetaG:
Matching pages from suggestions in link dialog now actually work as links

https://gerrit.wikimedia.org/r/171488
(In reply to Roan Kattouw from comment #3)
> Both this and bug 50646
Forget about bug 50646, my mistake, that one was about links in a different context. Comment #3 is still valid for this bug though.
Both this and bug 50646 should be fixed by making the link suggestions real links, i.e. real <a> tags whose hrefs point to the pages they're suggesting.

To do that, you'd need MWLinkTargetInputWidget to use a specialized subclass of MenuItemWidget; right now it creates plain MenuItemWidgets. Eventually that specialized subclass could be enriched to contain an image and a description etc., per the new designs for the link inspector. We could also use this new widget in MWTitleInputWidget.
Bug 50240 asks for disambiguation pages to be distinguished in the list, so I'm retitling this one to focus on being able to open the targets with ctrl+click/right click. A user at en.wp has requested this functionality as well.
You can use right click or ctrl+click on the links once inserted into the page, but per Bug 48915 this currently leads to the wrong namespace for links other than those to and from the article namespace.
Screenshot of problem

When a page contains multiple floated blocks after one another that each have a context menu (e.g. both transclusion) the ones after the first get the context menu in the wrong place. Namely on the second "line" of the article instead of where the element actually is (much further down).

--------------------------
**Version**: unspecified
**Severity**: normal

**Attached**: {F11059}
Go to https://en.wikipedia.org/wiki/Mohammad_Azharuddin - look at the infobox image. Then hit "edit". I have no idea what's happening, but it shouldn't be.

--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
{T53932}
{T55226}
The issue as filed was resolved long time ago (see parent bug T52577), I filed T96667 to track the issue of oversized highlights.
There are no screenshots here to show how it used to be broken, but it seems almost correct now. Only the highlight is displayed incorrectly.

https://en.wikipedia.org/w/index.php?title=Mohammad_Azharuddin&oldid=564025381&veaction=edit

{F117707}
There are no screenshots here to show how it used to be broken, but it seems almost correct now. Only the highlight is displayed incorrectly.

{F117707}
The image displayed is the same, https://en.wikipedia.org/wiki/File:Mohammad_Azharuddin_Sangeeta_Bijlani.jpg. But it is cropped by CSS (using https://en.wikipedia.org/wiki/Template:Css_Image_Crop) and VE don’t let the image be cropped correctly…
If would be nice for power users to have an option to disable the popup warning that occurs when you are trying to leave the edit mode while you have done some editing.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Change 126994 merged by jenkins-bot:
Check useeditwarning preference before showing warning when browsing away from editor

https://gerrit.wikimedia.org/r/126994
Change 126994 had a related patch set uploaded by Alex Monk:
Check useeditwarning preference before showing warning when browsing away from editor

https://gerrit.wikimedia.org/r/126994
Change 126977 abandoned by Alex Monk:
Add preference to disable leaving warning while editing

Reason:
gah, missed that one.

https://gerrit.wikimedia.org/r/126977
The preference 'useeditwarning' already exists, but this bug is about VisualEditor, maybe the VisualEditor does not respect the core preference or implement it's own edit warning.
Note that such a preference existed before and was removed when this functionality was merged into core from the Vector extension (bug 46514).
I'd argue this is unwanted feature mania. If the warning doesn't make sense, remove it. If it does, leave it.
Change 126977 had a related patch set uploaded by Alex Monk:
Add preference to disable leaving warning while editing

https://gerrit.wikimedia.org/r/126977
As mentioned in IRC, we should make this a core feature for MW and just re-use that preference rather than have a VE-specific one.
See http://youtu.be/gqqswqLd5Yw for what I mean
Editor requests support for adding non-breaking spaces (&nbsp;), keyboard shortcut?

From MediaWiki Feedback:

How do I enter a no-break space (& nbsp;) into the source text via the keyboard? Something like Ctrl+Space would be nice … And, BTW, can I see the difference between a regular space and a no-break space?

Troubled @sset Work • Talk • Mail‎18:03, 8 July 2013

--------------------------
Alternative: {T70429}
>>! In T53045#1953183, @Nnemo wrote:
> Regarding Ctrl Space on PC, would Ctrl Shift Space work as well? It would be good.

Yes, that patch actually used both of these combinations, but space in the commit summary is limited ;)
>>! In T53045#1837188, @gerritbot wrote:
> Change 255937 had a related patch set uploaded (by Bartosz Dziewoński):
> Add command to insert non-breaking space, triggered by Ctrl Space (PC) / Opt Space (Mac)
> 
> [[https://gerrit.wikimedia.org/r/255937]]

Option Space on Mac is a good combination. Regarding Ctrl Space on PC, would Ctrl Shift Space work as well? It would be good.
If those are blockers, can they be listed as such?
Change 255937 abandoned by Bartosz Dziewoński:
Add command to insert non-breaking space, triggered by Ctrl Space (PC) / Opt Space (Mac)

Reason:
This doesn't seem to be moving forward. And last time I checked, non-breaking spaces in VE-MW (implemented as MWEntity) had a bunch of problems like T119838, T119839, T119840; so we wouldn't really want to point users towards them without fixing that first.

[[https://gerrit.wikimedia.org/r/255937]]
I also think CTRL+space is quite a high profile shortcut to assign to a relatively uncommon feature.
Change 255937 had a related patch set uploaded (by Bartosz Dziewoński):
Add command to insert non-breaking space, triggered by Ctrl Space (PC) / Opt Space (Mac)

[[https://gerrit.wikimedia.org/r/255937]]
>>! In T70429#1224015, @Esanders wrote:
> Or you could somehow annotate the whole word as nowrap. Arguably <nowrap>100 °C</nowrap> would be clearer than 100&nbsp;°C
>>! In T53045#1232726, @Ltrlg wrote:
> Inserting only the character is not persistent: there is at least one browser which replaces non-breaking spaces with normal spaces in `<textearea>`s (may be Firefox? don’t remember). See [[https://fr.wikipedia.org/w/index.php?diff=114391750&oldid=114391708|this diff]] for an example of such a replacement (I read unfortunately more talk pages than articles and don’t remember an recent example in ns-0).

//Sometimes//, a replacement of non-breaking spaces with normal spaces in the text area occurs (occurred). This is (was) caused by a bug of Firefox, that was fixed years ago. Now, this happens rarely, because people having a fossil Firefox are rare. Over time, such replacements will be rarer and rarer.

>>! In T53045#1232726, @Ltrlg wrote:
> Of course there are safe places (before colons, inside French quotations marks) where MediaWiki does not require a special space to render a non-breaking one and where it would make no difference.

These safe places exist. //But ://

# I think that these safe places are a setup specific to the site fr.wikipedia.org, and do not apply in the general case of a MediaWiki. I may be wrong here. 
# These safe places do not work in links. 
# These safe places do not work in wikicode. 
# « The safe places for french quotes » do not work in the visual editor — this is a bug, by the way.
Inserting only the character is not persistent: there is at least one browser which replaces non-breaking spaces with normal spaces in `<textearea>`s (may be Firefox? don’t remember). See [[https://fr.wikipedia.org/w/index.php?diff=114391750&oldid=114391708|this diff]] for an example of such a replacement (I read unfortunately more talk pages than articles and don’t remember an recent example in ns-0).

Of course there are safe places (before colons, inside French quotations marks) where MediaWiki does not require a special space to render a non-breaking one and where it would make no difference.
Inserting only the character is not persistent: there is at least one browser which replaces non-breaking spaces with normal spaces in `<textearea>`s (may be Firefox? don’t remember). See [[https://fr.wikipedia.org/w/index.php?diff=114391750&oldid=114391708|this diff]] for an example of such a replacement (I read unfortunately more talk pages than articles and don’t remember an recent example in ns-0).

Of course there are safe places (before colons, inside French quotations marks) where MediaWiki does not require the a special space to render a non-braking one and where it would make no difference.
For this feature, something would need to be clarified :

What would the keyboard combination insert in the wikicode ?

# The character non-breaking space 
# The HTML entity ##&nbsp;## 

These are two different things.

For this feature, I would recommend inserting the character non-breaking space. Inserting the non-breaking space character leaves the wikicode natural and readable. Well, as readable as the wikicode already is. ;-)
For this feature, I suggest Ctrl Shift Space rather than Ctrl Space.

Reasons :

# Ctrl Space is already taken for Spotlight on Mac. 
# The Word feature for entering a non-breaking space is pressing Ctrl Shift Space. 

The Word feature is quite well known. Having an inconsistency here would confuse users.
Related: https://phabricator.wikimedia.org/T70429
You should be able not only to change image caption, but select another image.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=54285
*** Bug 52580 has been marked as a duplicate of this bug. ***
*** Bug 53409 has been marked as a duplicate of this bug. ***
Try to add image to http://uk.wikipedia.org/wiki/29er_(%D0%B2%D0%B5%D0%BB%D0%BE%D1%81%D0%B8%D0%BF%D0%B5%D0%B4) 

It suggests no images for article "29er (велосипед)", but it will if you search by Commonscat template parameter or english interwiki

--------------------------
**See Also**:
{T54464}
I think doing this via Wikidata identity would be a better way forward.
Two editors have commented independent in different place over the weekend on English Wikipedia about how they wish they could access the edit summary while using the VE instead of on save, because they track their changes as they go.

--------------------------
**Version**: unspecified
**Severity**: enhancement
@Sadads has suggested that the Tab key be used to switch between the article and the edit summary window.
(Aaand there's an exception for that. See T114857.)
(Although they won't be able to do so if they enabled the warning that doesn't allow to save without providing an edit summary, as noted at de.wiki. )
On a related note: There's also no edit summary in the diff view ("review you changes"), just a save button. This tempts users to save without leaving an edit summary.
Think this is also happening on PL.WP. 

"Jeśli w okienku z polem służącym do opisu dokonanej zmiany klikniemy w link dotyczący sposobu opisywania zmian zostaniemy przekeierowani do strony Wikipedii z opisem tychże skrótów, jednak strona ta wyświetla się w tym samym małym okienku. Uniemożliwia to powrócenie to opisu modyfikacji a jednocześnie uniemożliwia zapisanie dokonanej zmiany w danym artykule. Michał (dyskusja) 11:36, 5 lis 2013 (CET)"

https://pl.wikipedia.org/wiki/Wikipedia:VisualEditor/Opinie#B.C5.82.C4.85d_w_okienku_opisu_zmian.
+1. This is a particularly useful feature of the old editor.
An editor from pt.wikipedia writes:

[E]ditnotices seems strange inside the flyout because there's a weird padding inside the popup, without the padding the templates would look nicer (there´s already padding in most edinotices templates by default). Dianakc (talk) 23:56, 6 July 2013 (UTC)

--------------------------
**Version**: unspecified
**Severity**: enhancement
(In reply to comment #2)
> Hi James,
> 
> I don't know what mean you by normal edit notices :) A simple 100% div, with
> background color but without padding would look weird inside the flyout.
> We are rethinking the editnotices design/content and right now they look
> somewhat awkward within this asymmetrical padding. If someone ever need a
> margin it can be done within the editnotices itself, but this mandatory
> padding
> limits the design a lot.

Normal edit notices are text only (or bold/italics/links). Adding any further styling, including <span>s, <div>s, images, etc. is likely to break in a variety of situations and isn't really intended behaviour for the tool.
Hi James,

I don't know what mean you by normal edit notices :) A simple 100% div, with background color but without padding would look weird inside the flyout.
We are rethinking the editnotices design/content and right now they look somewhat awkward within this asymmetrical padding. If someone ever need a margin it can be done within the editnotices itself, but this mandatory padding limits the design a lot.
(In reply to comment #0)
> An editor from pt.wikipedia writes:
> 
> [E]ditnotices seems strange inside the flyout because there's a weird padding
> inside the popup, without the padding the templates would look nicer (there´s
> already padding in most edinotices templates by default). Dianakc (talk)
> 23:56,
> 6 July 2013 (UTC)

I'm not sure that it's a better solution to get editors to make edit notices in uneditable HTML boxes, rather than the padding be system-level. The padding is designed to take normal edit notices; if you make fancy ones that break, the onus is generally on you. :-)

Note that we're planning on having setting/editing/removing page-level edit notices built into VisualEditor in the next few months, which will make enwiki's solution available to all wikis.
Several concerns noted about VisualEditor messing with math formulas when (evidently) the user was not attempting to edit the formula at all.

https://en.wikipedia.org/w/index.php?title=Raising_and_lowering_indices&curid=11325244&diff=563062676&oldid=560490441

https://en.wikipedia.org/w/index.php?title=Regression_analysis&curid=826997&diff=563265603&oldid=561802206

https://en.wikipedia.org/w/index.php?title=Bipartite_double_cover&curid=21241712&diff=563327691&oldid=554035797

I'm not sure if this is related to an existing bug or a different kind of thing.

--------------------------
**Version**: unspecified
**Severity**: normal
**cbm.wikipedia** wrote:

This is a duplicate of bug 50291. It is a round tripping error in VisualEditor.

%%%*** This bug has been marked as a duplicate of bug 50291 ***%%%
The changes don't actually change the visual output. Just the way italics (used to mark variables) and superscript and subscript tags interact. So it might change ''e''<sup>''x''</sup> to ''e<sup>x</sup>'' you could say the former is better semantically. Other cases will split a complex superscript into two separate subscripts  ''K''<sub>''n'',''n''</sub> into ''K<sub>n</sub>''<sub>,''n''</sub>, visually the same but worse semantically.

Marking as low priority as no visible change.
The save dialog uses a gray color on a very small text. This isn't good for contrast, and gives it rather 'light' color which might communicate a 'disabled' state to some users, which you don't want with a license text.

Just as with Special:UserLogin, I think we should switch to a slightly darker gray on small text.

--------------------------
**Version**: unspecified
**Severity**: enhancement
This has been [[ https://phabricator.wikimedia.org/rEVED48db1c16f81091f62d82539b2a41fede49ba7915 | changed to `#54595d` in wmf/1.29.0-wmf.7 ]] and fulfills WCAG 2.0 level AAA conformance.
The meta-design of the save process for wikitext and for VisualEditor are being reviewed by Design and by Legal right now; hopefully there'll be an update soon enough.
Perhaps when the [[WP:Tutorial]] on enwiki is updated for VE, we will want to enable VE on the tutorial sandboxes.

Also, when VE is enabled for anonymous editors, we might want to turn on VE in the enwiki [[WP:Sandbox]], because otherwise anons won't have anywhere to play with VE (they cannot create user pages).

Perhaps a category (similar to the way AFTv5 does it) or MediaWiki page (like Echo blacklist) would be the way to do it.

--------------------------
**Version**: unspecified
**Severity**: enhancement
While bug 55900 now allows logged-out users to invoke VE in the namespaces where it is already available, in the meantime I hope communities created temporary sandboxes in one of said namespaces :) (The Italian one did, it's basically a subpage of mine).
For the record: on ptwiki we also have a few sandboxes on Project namespace:
[[pt:Special:PrefixIndex/WP:Página_de_testes/]]
**Author:** `KilliondudeWP`

**Description:**
1) Have categories on a page with a stub tag underneath - https://en.wikipedia.org/w/index.php?title=Rosebud_Ranch&oldid=563208475 (note that this is SOP on enwiki per https://en.wikipedia.org/wiki/Wikipedia:ORDER#ORDER )

2) Edit the categories using VE to deleted one and modify another - https://en.wikipedia.org/w/index.php?title=Rosebud_Ranch&diff=563208669&oldid=563208475

3) End up with newly formed category underneath the stub template as well as some line breaks taken out. 

I reported this in #mediawiki-visualeditor while everyone was sleeping. This is something that might just need an enwiki fix since we like to put stub tags under categories.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
* {T51143}
* {T55508}
* {T74048}
There's also an inconsistency in how VE inserts `{{DEFAULTSORT}}` and categories.

If you edit the page's properties to add a `{{DEFAULTSORT}}`, apply, then edit the properties again to add a category, then the `{{DEFAULTSORT}}` is added before the category, as is usually expected based on community guidelines.

However, if you do the sequence in the other order (add a category first, apply, then edit the properties again to add a `{{DEFAULTSORT}}`), then the `{{DEFAULTSORT}}` is added //after// the categories.

Since the user doesn' t have a way to specify or change that order, VE should be consistent in how it outputs them in the wikitext.
*** Bug 51714 has been marked as a duplicate of this bug. ***
The reasons behind [[WP:ORDER]] are:
1) We want "stub categories" to appear Last in the list of categories.
2) We want 2 blank lines preceding stub-templates, for whitespace. (Other ways of achieving this are more complex, or don't work for articles with multiple stub-templates.)
See example of both factors, at http://en.wikipedia.org/w/index.php?title=Milo_McCarger&oldid=532917627


(To quote the [[WP:ORDER]] reference here, for ease of access: "While categories are entered on the editing page ahead of stub templates, they appear on the visual page in a separate box after the stub templates. One of the reasons this happens is that every stub template generates a stub category, and those stub categories appear after the "main" categories. Another is that certain bots and scripts are set up to expect the cats, stubs and ILLs to appear in that order, and will reposition them if they don't. Therefore, any manual attempt to change the order is doomed unless the bots and scripts are also altered.")
(In reply to comment #2)
> The problem here is not specifically "stub templates", but the general idea
> that some items of content - in this case, on one wiki, a sub-type of
> template that is trivially-identifiable to humans but not necessarily so for
> software - should have its own special ordering when the page is
> re-serialised. The explanation for why this (relatively new?) policy change
> for enwiki seems to be absent [...]

This practice has been documented at [[WP:LAYOUT]] for at least a few years. It's been standard practice since before then. There's a note in the current version of that document that explains that it's due to a battle with bots (notable AutoWikiBrowser, as I recall). Because most people add stub categories with AWB or similar scripts, the conventions those tools use become (or rather, became) wiki conventions.

I agree with the general point that we should move this type of information (whether a page is a stub and if so, what kind of stub) to a metadata area.
Moving back to VE as this is handled in VE until we move metadata out of the body.
In the medium term I'd like to move metadata like categories out of the page and into a header section (see bug 49143).

In the meantime, we serialize metadata wherever the VE places it in the DOM.
This is not minor, unless enwiki has agreed to abandon the long-established rules set out in http://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style/Layout#Order_of_sections . I have just added a category to [[Permyak Salty Ears]] (it's a sculpture I was stub-sorting), and it has been put below the stub tag and interwiki link, and not adjacent to two existing categories. 

There are also rules for the top of the article: navigational hatnotes go before anything else. Not in VE. WP:AWB sorts these out misplaced elements as part of "General fixes"; Twinkle can put a newly-added maintenance tag within the {{tl|multiple issues}} tag. It is very disappointing that VE seems incapable of offering the same level of helpfulness as these existing systems have offered for years.
When I edited an internal link and pasted in Work_breakdown_structure#Terminal_element as the new link target, the link editor widget thought that it was a new page, because it didn't understand that the # referenced an anchor within that page.

However, that was just a harmless warning - it did work. So I am classifying this as minor severity, because it is merely an incorrect warning message that could confuse editors.

--------------------------
**Version**: unspecified
**Severity**: enhancement
{T112898} has been fixed but `[[#section|text]]` just inserted is still red (all the same, it displays correctly for links which were already present before loading VisualEditor).
*** Bug 61428 has been marked as a duplicate of this bug. ***
(In reply to comment #11)
> John reports today that "It used to be possible, in VE, to link to another
> section of a page (say, Bank#History). Now, when section information is
> added,
> in the Link/Hyperlink dialog box, VE just deletes it when the user presses
> [return] or exits (in any way) that dialog box."

Noting for posterity that that was bug 53219, which has now been fixed.
John reports today that "It used to be possible, in VE, to link to another section of a page (say, Bank#History). Now, when section information is added, in the Link/Hyperlink dialog box, VE just deletes it when the user presses [return] or exits (in any way) that dialog box."
The VE software has changed (at least a week ago, maybe longer) for this issue. Now pressing [Return] does not remove the "#Whatever" text that the user typed, for the section link. So this bug is now primarily a display issue.

(In reply to comment #7)
> This isn't just a display problem, and it is NOT an enhancement - it's a real
> defect because editors are unlikely to take the time - as I did - to figure
> out
> how to make section links work.
> 
> Here's what happens now: The editor finds an article to link to (good UI;
> much
> better than the wikitext editor); then he/she starts typing the section link
> (#whatever). The link name turns red (that's the display issue), and it
> doesn't
> suggest section names (that would be a really slick enhancement; if you do
> this
> well, people are going to love you). Instead, when the editor is done typing
> the section information, one of four things can happen:
> 
> * The editor presses Enter/Return (per the user guide), and the section
> information is REMOVED by VE. That is clearly a defect in the software.
> 
> * The editor presses the close icon (<) (per the user guide), and the section
> information is REMOVED by VE. That is clearly a defect in the software.
> 
> * The editor clicks somewhere else on the page, and the section information
> is
> REMOVED by VE. That is clearly a defect in the software.
> 
> * The editor clicks on the area ABOVE the input box, the area containing the
> word "Hyperlink", and VE is happy, and saves the section information. (I'm
> going to add that to the user guide, but that wouldn't do nearly as much good
> as changing, in the software, what happens in the first three situations,
> above.
The suggestion of the sections that can be linked are also requested at it.wp.
*** Bug 51445 has been marked as a duplicate of this bug. ***
This isn't just a display problem, and it is NOT an enhancement - it's a real defect because editors are unlikely to take the time - as I did - to figure out how to make section links work.

Here's what happens now: The editor finds an article to link to (good UI; much better than the wikitext editor); then he/she starts typing the section link (#whatever). The link name turns red (that's the display issue), and it doesn't suggest section names (that would be a really slick enhancement; if you do this well, people are going to love you). Instead, when the editor is done typing the section information, one of four things can happen:

* The editor presses Enter/Return (per the user guide), and the section information is REMOVED by VE. That is clearly a defect in the software.

* The editor presses the close icon (<) (per the user guide), and the section information is REMOVED by VE. That is clearly a defect in the software.

* The editor clicks somewhere else on the page, and the section information is REMOVED by VE. That is clearly a defect in the software.

* The editor clicks on the area ABOVE the input box, the area containing the word "Hyperlink", and VE is happy, and saves the section information. (I'm going to add that to the user guide, but that wouldn't do nearly as much good as changing, in the software, what happens in the first three situations, above.
Worth noting here the comments on bug 50945 about cases where display text != link text (piped links)
*** Bug 51121 has been marked as a duplicate of this bug. ***
(In reply to comment #3)
> When reporting the duplicate bug (sorry, this one didn't come up in my
> search)

Don't worry, it's my fault for not triaging earlier. :-)

> I wondered whether this was related to Bug 33094

I don't believe so (though we should get that fixed soon too, of course).
When reporting the duplicate bug (sorry, this one didn't come up in my search) I wondered whether this was related to Bug 33094
*** Bug 51118 has been marked as a duplicate of this bug. ***
* The link inspector needs to understand that if Foo exists, linking to Foo#Bar isn't a red link
* Ideally the link inspector should have introspection of articles' sections so that it can suggest which headings to link to
* This should also work for naked (local) section links - i.e., linking to just #Bar on the local page.
This bug was cloned from bug 50120.

(In reply to bug 50120 comment #5)
> We believe that this is now fixed (due to fixes in Parsoid). Please re-open
> if it recurs.

How do you know what version of VisualEditor or Parsoid is running? Looking at Erik's comment (bug 50120 comment 6), I try to go to [[Special:Version]] to figure out what exact versions of Parsoid and VisualEditor are running (for debugging purposes and to figure out if this problem is still present in the latest bleeding edge code) and I find that Parsoid and VisualEditor are both marked as version 0.1.0. Not quite helpful for debugging. Splitting this issue out.

--------------------------
**Version**: unspecified
**Severity**: enhancement
With bug 53972 now fixed, this is now fixed in Beta Labs (see http://en.wikipedia.beta.wmflabs.org/wiki/Special:Version for git hashes against each extension), and for VisualEditor specifically (which was the original locus of this suggestion) it's also available at the bottom of the "help" menu.
(In reply to comment #1)
> Could we switch on the configuration we have on beta labs for Special:Version
> for other wikis? (Perhaps as a page option - ?showversions=true or whatever,
> so as to avoid confusing users.)

I'm not sure of the history here, but perhaps it could show the extra info only for logged-in users?
**Author:** `gigs`

**Description:**
I see that a cancel button has been added, which is an improvement, but the escape key should also cancel edit mode.

--------------------------
**Version**: unspecified
**Severity**: enhancement
The discussion above makes sense and I think the <escape> key feature as currently implemented is probably helpful to some people.  But as a user who heavily uses <esc> to get out of "insert ..." dialogs and so on, it's alternately scary and annoying that a hitting (any) key too many times threatens to cancel my changes without saving.

I'm not sure what improvements to suggest.  On second thought...  There doesn't seem to be a Cancel button, which makes it arch-surprising that a keyboard shortcut would do so.  What about changing the behavior of <esc> to "Save Changes" instead?  This seems consistent and friendly.
The discussion above makes sense and I think the <escape> key feature as currently implemented is probably helpful to some people.  But as a user who heavily uses <esc> to get out of "insert ..." dialogs and so on, it's alternately scary and annoying that a hitting the key too many times will threaten to cancel my changes without saving.

I'm not sure what improvements to suggest.  On second thought...  There doesn't seem to be a Cancel button, which makes it arch-surprising that a keyboard shortcut would do so.  What about changing the behavior of <esc> to "Save Changes" instead?  This seems consistent and friendly.
Verified in betalabs.  Escape key will bring a warning message  box 'Are you sure?'
>>! In T52868#805066, @Jdforrester-WMF wrote:
> Resolution is determined by QA for features and bugs.

Huh?
Resolution is determined by QA for features and bugs.
Change 175869 merged by jenkins-bot:
Cancel VE when escape key pressed

[[https://gerrit.wikimedia.org/r/175869]]
Change 175868 merged by jenkins-bot:
Dialog: Only handle escape events when open

[[https://gerrit.wikimedia.org/r/175868]]
Change 175869 had a related patch set uploaded (by Alex Monk):
Cancel VE when escape key pressed

[[https://gerrit.wikimedia.org/r/175869]]

#patch-for-review
Change 175868 had a related patch set uploaded (by Alex Monk):
Dialog: Only handle escape events when open

[[https://gerrit.wikimedia.org/r/175868]]

#patch-for-review
(In reply to WhatamIdoing from comment #11)
> I'm a bit worried about this.  What if I'm in a template dialog and
> accidentally press Esc twice/too long?  If this triggered the "Do you really
> wnt to exit?" confirmation, it might be okay.  However, I suspect that this
> might not have the ultimate effect that was intended.

Comment 10 asks for the unsaved changes warning to be shown. If we do that, I think it'll be fine. Pressing escape while a dialog is open will dismiss that dialog with a safe action (the cancel/never mind action). So if you press escape again when the unsaved changes warning is visible, that'll dismiss the warning with the safe action, which is "never mind, I want to continue editing". So if you press Esc a bunch of times or hold it too long, you'll end up in a loop of the unsaved changes warning appearing and being dismissed.
I'm a bit worried about this.  What if I'm in a template dialog and accidentally press Esc twice/too long?  If this triggered the "Do you really wnt to exit?" confirmation, it might be okay.  However, I suspect that this might not have the ultimate effect that was intended.
Yes, pressing escape when in a dialog should close that level of the dialog (if more than one) or the dialog if it's at the top level of the dialog. If a change was confirmed then it should remain when closed, if a change was unconfirmed it should be cancelled. 

With no dialogs open, escape should exit VE but should ask for confirmation before doing so if there are unsaved changes. That dialog should have keyboard actions such that enter confirms you want to leave and escape indicates that you don't want to leave and take you back to the VE. This will stop people losing work if they hit esc accidentally or too many times.
Clarify title so it's clear we all agree.
**gigs** wrote:

Agreed, that's how I envisioned it.
I'd like to note that really this should only happen iff someone is exclusively in edit mode. IOW, if someone has opened the template inspector, close that. Link inspector, close that - so on and so forth.
On macs, cancel is usually cmd-.

Wouldn't mind having that in VE.
I think this isn't a bad idea, though I'm a little troubled if this causes unexpected behaviour for users of some browsers.
**gigs** wrote:

OK, but my next question is: What form fields are people going to be interacting with when in the main Visualeditor?  The only form field I see is the search box.
Opera does that; it's useful enough that I expected other browsers to behave similarly. IE8 resets the value to the default (for both inputs and textareas). And Firefox apparently doesn't do anything, like you said.
**gigs** wrote:

What browsers?  Not Chrome or Firefox.  I don't have IE here to test with, but I doubt it does it either.

http://www.w3schools.com/jquery/tryit.asp?filename=tryjquery_event_blur_alert
The escape key is used by browsers to defocus (blur) currently focused form element. Reusing it for this would be really annoying.
Parser function syntax is generally {{#function_name : expr1 | expr2 | expr3 | ...}}

Currently VE sees this as a template with name "#function_name : expr1" and arguments "1 = expr2", "2 = expr3", etc. This makes it impossible to edit expr1 in VE.

Same for parserfunctions like urlencode and template messages. The transclusions editor should be able to handle them, preferably by invisibly detecting them and failing that with a special, user-selected mode. Until we can, we should show an explanatory message when the user attempts to add one. 

**See also:**
{T54607}
If Parsoid doesn't automatically tell VE whether something is a template or not, could it not be done by looking at the format of the string (e.g. {{# is never a template) or comparing it to a list of parser functions?
Many of the parser functions are rarely used in the main namespace (#if, ...), but some of them are really important even in the main namespace. For example {{formatnum:...}} is probably used a lot there.
Yes, we need a special form of editing transclusions which aren't templates; I can't recall whether Parsoid gives us sufficient information to recognise these as different except for introspection.
Original Bug title: 
Provide an API to activate VE on arbitrary textareas for Gadgets and user scripts and document it at [[:mw:VisualEditor/API]]

Please also create a mailing-list for those API updates.

Issue:
Since users will not be able to understand Wiki-Markup, please provide and API for turning-on VisualEditor on <textarea>s. Example use case would be the Translate Extension where translators still have to enter wiki-markup or LiquidThreads or whatever is adding Wiki-Markup to a page.

Providing an API to Gadget authors and other tools is an important matter; nearly all edits are made through gadgets at certain pages; thus it is not just an "enhancement".

--------------------------
**Version**: unspecified
**Severity**: enhancement
This is a quite considerable piece of work; marking as "low" absent a huge push for this.
narrow display

Seen in Chrome at least

* click Transclusion
* add a Template; add-parameter display is fine
* add a parameter to the template
* click Remove parameter

resulting display is too narrow and does not display fully

* add a new parameter in the garbled display

display of parameter value show echoed/ghost characters as user types into parameter input

--------------------------
**Version**: unspecified
**Severity**: normal

**Attached**: {F11254}
confirmed
I believe that this was due to a CSS caching issue (which we will more generally fix with bug 49420), and should now be gone - can you confirm?
Created attachment 12763
ghost characters while typing

**Attached**: {F11255}
The wikitext editor <textarea> element has a CSS class "mw-textarea-protected" when a protected page is being edited. This can be used to provide custom styling for this textarea, mainly in order to alert sysops that they are editing a fully protected page.

A similar CSS class name should somehow be provided for VE.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Change 130665 merged by jenkins-bot:
Add class name to protected pages, to allow for specific CSS styling of edit area

https://gerrit.wikimedia.org/r/130665
Change 130665 had a related patch set uploaded by Alex Monk:
Add class name to protected pages, to allow for specific CSS styling of edit area

https://gerrit.wikimedia.org/r/130665
If you Ctrl+Click a link in the VE, it'll open (discovered through trial and error). Presumably the cursor when hovering over links while Ctrl is depressed should be the hand icon, rather than the typing icon.

--------------------------
**Version**: unspecified
**Severity**: minor
Screenshot

See screenshot; not sure this is how it's meant to look, but it's how it looks. If there are no unused parameters it seems like the box notifying you of such should overwrite, rather than sit under, the search box - that's unnecessary functionality if all available parameters exist.

--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=54094

**Attached**: {F11039}
Just noting that bug 54094 (which was marked as a duplicate) is about the "Unknown parameter" message which appears (briefly) after the user has typed in '1'/'2' but not pressed enter yet.

(In reply to comment #5)
> Yes, "No more known parameters" would work. 
> 
> Not essential, but if it's not too much work, including a link to an
> explanation (that there may be unknown parameters and that these can be used)
> and/or the template documentation (if there isn't one provided elsewhere on
> that view) would be good. Obviously both should open in a new window/tab.

That is essentially bug 49772.
*** Bug 54094 has been marked as a duplicate of this bug. ***
Yes, "No more known parameters" would work. 

Not essential, but if it's not too much work, including a link to an explanation (that there may be unknown parameters and that these can be used) and/or the template documentation (if there isn't one provided elsewhere on that view) would be good. Obviously both should open in a new window/tab.
Urk. Tis true. In particular, I'm thinking of scenarios where you have an infinite number of parameters (templates that merely order and format a set of inputted data, for example). "No more known parameters" would work.
(In reply to comment #2)
> Possibly? Offering people the ability to do something when the system knows
> it won't end in what they want probably isn't the direction we want to be
> going in, however.

But the system doesn't 'know' that. TemplateData is hinting, not a binding-contract-of-doom. It's (intentionally) possible to add parameters that aren't in the hinting, because the hinting is out-of-date or doesn't cover this "secret" parameter, or because the name of your parameter is generated (e.g. {{CURRENTDAY}}=Easter Egg! or something more useful). Remember that there's almost no end to the level of flexibility that WT allows users…
Possibly? Offering people the ability to do something when the system knows it won't end in what they want probably isn't the direction we want to be going in, however.
Possibly we could say "No known parameters" and "No more known parameters" to make it clearer?
Since Parsoid has dropped it in bug 46027

--------------------------
**Version**: unspecified
**Severity**: normal
Change 71974 merged by jenkins-bot:
Drop mw:ExtLink/URL support

https://gerrit.wikimedia.org/r/71974
Change 71974 had a related patch set uploaded by Esanders:
Drop mw:ExtLink/URL support

https://gerrit.wikimedia.org/r/71974
**Author:** `lunarjam.mcgahan`

**Description:**
MS Word document describing and illustrating the bug

See attached document. O/S is iOS 6.1.3

--------------------------
**Version**: unspecified
**Severity**: minor
**OS**: other

**Attached**: {F11914}
>>! In T52714#589573, @TheDJ wrote:
> the technology of absolute positioning that is use by these templates and replace them with something more sustainable.

Split to T120809
Link to a few other templates that run into trouble due to this problem.

https://en.wikipedia.org/wiki/Template:Chess_diagram
https://en.wikipedia.org/wiki/Template:Quote_box (with curly quotes option on)
Yes, exactly, the elements themselves. The HTML DOM elements. Not the pretty picture that translates into, nor the ugly wikicode language that generates them.
**Wikifram** wrote:

(In reply to comment #14)
> And i'm slightly offended by your attack on me as a person. A volunteer who
> probably spends more time on en.wp than doing development.

I haven't attacked you as a person, for all I know you may be a wonderful person. I have attacked your comment as a developer here, and what I see as the mindset of many developers here when working as a developer. 

(In reply to comment #14)
> > are so wrong that I feel it may be hard to explain to you what is the problem with it.
> 
> I think you assumed that I meant the elements/templates themselves. You
> assumed
> incorrect.

I didn't "assume" anything, I read what you wrote: "Ideally, we would
just get rid of absolute positioned elements". Usually, when people write "get rid of elements", they mean "the elements themselves", not "keep the elements but get rid of the technology used". Don't blame your errors on others please. I have no problem with someone correcting his position or retracting earlier statements, and I'm not the type to claim for all eternity that you want to get rid of these elements if you clarify that that was not what you intended; but then just state that what you said was not what you meant, not that the problem lies with the reader who "assumed" something incorrectly.
> are so wrong that I feel it may be hard to explain to you what is the problem with it.

I think you assumed that I meant the elements/templates themselves. You assumed incorrect. I meant the technology of absolute positioning that is use by these templates and replace them with something more sustainable. They currently also break in mobile and are very sensitive to skin changes for instance. The technique used to place them is problematic (and has been known to be problematic for many years, it's part of why I consolidated those hacks into https://en.wikipedia.org/wiki/Template%3ATop_icon, so that we could replace them at some point). The same technique has also been used for several spam attacks on the wiki.

And i'm slightly offended by your attack on me as a person. A volunteer who probably spends more time on en.wp than doing development.
**Wikifram** wrote:

The DJ, thanks for your response, but I fear that it is again symptomatic of the incorrect view you and other devs seem to have. VisualEditor is ''not'' the goal, it is a means to make editing easier. Comments like "Ideally, we would just get rid of absolute positioned elements (.topicon, coordinates, FA/GA etc icons), but that's probably going to be near impossible." are so wrong that I feel it may be hard to explain to you what is the problem with it. There is absolutely ''nothing'' ideal about getting rid of these elements, they are a very useful aspect of maps and other position-defined elements. If VE can't handle these, then VE has to change or an alternative method that can be used in view mode and VE mode needs to be found. But "VE can't handle this, so we should get rid of these elements"? No, that's the opposite mindset of what we actually need. 

As for "nor is it extremely visible to the uninitiated.", have you looked at pages like [[:en:FC Barcelona]] or [[:en:ant]]? I think most of the "uninitiated" would notice some differences in the display between [[:fr:Azincourt]] and [https://fr.wikipedia.org/wiki/Azincourt?veaction=edit this] (cause this bug happens on all wikis, not just here...) 

This bug happens on about 1 in 5 pages. I don't see how this can be both "low" and "minor" in importance, either one should be a lot higher (a minor aspect that affects an awful lot of pages on all wiki versions is a lot more important than a minor aspect that only affects a few hundred pages, obviously). On a fair number of pages (e.g. the football kit ones, 25000 on enwiki alone, but also e.g. [https://fi.wikipedia.org/wiki/Paris_Saint-Germain?veaction=edit here]), this bug (assuming it is the same one) is very pronounced, so not so minor anyway.
By investigating the railway template problem, I think I identified 3 Parsoid bugs that were contributing to those problems on those pages. Most important is bug 57258. The others were bug 57251 and bug 57252.

These are very distinct issues from the location map issue.
For Location map, this is caused solely by:

.ve-ce-protectedNode, .ve-ce-protectedNode * {
position: relative !important;
top: 0 !important;
left: 0 !important;
bottom: 0 !important;
right: 0 !important;
}

Disabling it returns both the markers and the coordinates back to their original position. However, that also makes all content outside of the main box (you can click title coordinates that are generated by an info box).

Conclusion, this was probably done to counter the effects of absolute positioned elements and causes 'fallout' for relative positioned elements. One way to fix this is with a bit of JS.

var elements = $(".ve-ce-protectedNode").filter(function() {
      if( $(this).css("position") === "absolute" ) {
            $(this).addClass("evilabsoluteitems");
      }
});

And then assign the above css only to those elements. This is probably a rather 'expensive' operation. Ideally, we would just get rid of absolute positioned elements (.topicon, coordinates, FA/GA etc icons), but that's probably going to be near impossible. A third option might be to add a classname to all these elements that VE can recognize and then apply this styling to it.

The question of the railway template seems more complex. I have a suspicion that there is actually a coding error in those templates, since I see problems with columns/rows counts on those pages. That would also explain why they take long to render in parsoid, it likely makes it complex to render the pages.
Probably a separate problem, which may already be filed in buzila, but here are a few railway templates that have extreme layout issues.
https://en.wikipedia.org/w/index.php?title=Ontario_Northland_Railway&veaction=edit
https://en.wikipedia.org/w/index.php?title=Brunswick%E2%80%93Magdeburg_railway&veaction=edit
https://en.wikipedia.org/w/index.php?title=East_Lancashire_Railway&veaction=edit
https://en.wikipedia.org/w/index.php?title=Channel_Tunnel&veaction=edit
https://en.wikipedia.org/w/index.php?title=Ravenglass_and_Eskdale_Railway&veaction=edit
**lunarjam.mcgahan** wrote:

Map of Loyalsock State Forest in VE on Chrome 22 Win7

**Attached**: {F11916}
**lunarjam.mcgahan** wrote:

VE display of a railway line in Chrome 22 on Win7

**Attached**: {F11915}
**lunarjam.mcgahan** wrote:

Also does nasty things to railway line diagrams - see [[South Maitland Railway]].
**lunarjam.mcgahan** wrote:

For an example of a similar but not identical problem see the map in [[Loyalsock State Forest]]
Another fairly large set of 'CE-munging-absolutely-positioned-CSS bug'.  Is there an open bug for that?

https://en.wikipedia.org/wiki/Template:Football_kit
It also appears in other cases, such as this circle which should be over right-most persons face.
https://de.wikipedia.org/wiki/Selbstbildnis_%28Leonardo_da_Vinci%29?veaction=edit
Problem confirmed on Firefox and Chrome, and can be seen at

https://en.wikipedia.org/wiki/Macumba_Station?veaction=edit

And most other pages (lots and lots) that use

https://en.wikipedia.org/wiki/Template:Location_map

also confirmed for uses of the German template, so I am guessing most other wikis will have the same problem

https://de.wikipedia.org/wiki/Vorlage:Positionskarte

https://en.wikipedia.org/wiki/Azincourt?veaction=edit
https://de.wikipedia.org/wiki/Albany_%28New_York%29?veaction=edit

I cant find another bug that mentions location maps.
**lunarjam.mcgahan** wrote:

This bug also occurs in Chrome Version 27.0.1453.116 m on Windows 7.
This looks like a CE-munging-absolutely-positioned-CSS bug.
Very often I find that there are some tools that both these editors (VE and the old editor) that I would want to use on the same article. But there is no way to do so.

It would be a very useful feature of the VE if there was some way (direct, or indirect; like through the show preview button) for editors opening an article in VE to be able to edit the same article in the old editor without having to save it or discard the changes made.

Such a feature could also come in handy for other editors who have started editing through VE but couldn't understand the interface/needed to switch because they realised VE could not do an action they wanted

--------------------------
**Version**: unspecified
**Severity**: enhancement
This is the same as bug 47779

*** This bug has been marked as a duplicate of bug 47779 ***
Oops - just realized there was an external link in his comments.

The picture he mentions in his last sentence can be found here:
http://en.support.files.wordpress.com/2009/07/visual_editor2.png?w=688
Another editor adds:
If you want to switch (say you started in Visual, but you want to switch to source to get something fancy working), you have to either discard your changes or save a partial edit in visual and create a second edit in source. What I want to see is a means of switching between the two at will within the same edit. Wordpress does something similar where you can type up a blog post to switch between visual rendering and HTML source using tabs surrounding the edit window. You can switch between visual and HTML at will and each will be updated. I want to see the same thing with the Wikipedia VisualEditor. -Thunderforge (talk) 21:32, 6 July 2013 (UTC)

AND

They don't necessarily have to both be visible at the same time (in fact, that might be somewhat confusing and perhaps wouldn't work well on mobile devices and tablets if the VisualEditor is going to be used there). But I would like some way to switch between the two without having to discard an edit. Again, the tabs on the edit window that Wordpress uses are one excellent way to do this: they allow the edit space to be swapped out, providing a compact way to easily switch. A picture of it can be found here. -Thunderforge (talk) 21:40, 6 July 2013 (UTC)
Examples of articles where I need to use both? That would be any article where I'm trying to manipulate citations (move/add/append/improve) or with templates; as well as doing some general editing.


Example of what I want? A button saying "View this in the old editor", and clicking on that gets you the same article, including any changes you made, in the old editor. Alternately, you could display the same button in the preview mode when you're viewing the article
Can you provide some more specific examples?
Copied:
For logged in user, can there be a formatting preference to display [edit | edit source] as [edit source | edit]? --J. D. Redding 18:47, 3 July 2013 (UTC)

The user finds it frustrating that he keeps inadvertently selecting "edit"

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=56337
(In reply to comment #5)
> I don't think a user preference is appropriate here.
> 
> Given the resolution of bug 50540, I'm not sure there's anything actionable
> here.

Concurred; closing as INVALID.
I don't think a user preference is appropriate here.

Given the resolution of bug 50540, I'm not sure there's anything actionable here.
A better solution would be the one suggested at bug 50540.
I agree that we need to resolve this somehow, since the current hover interface has also been pointed out as a problem on touch devices (e.g. tablets).
I think it is a fairly high priority. It would keep a lot of users (such as me) from turning off the visual editor altogether. Many people are turning off the VE due to this problem. More and more people are saying this here:
[[Wikipedia:VisualEditor/Feedback]]

I want instant direct access to the "edit source" link. I want the "edit" link to be the one that is hidden. 

Better yet would be an option to display both links directly without any hover effects. When I want to click either link I do not want to waste one millisecond finding the link, or thinking I may screw up again, and hit the wrong link. 

Think gaming, ping, lag time, and even slightly experienced Wikipedia editors wanting to get things done faster.
We can do this, but I don't think it's as high priority as a number if others. Marking as such.
what it says on the tin; if you remove the first character from [[foo]] to change it to [[moo]], what you actually end up with is m[[oo]].

See also:
* T52745
* T52945
* T55495
* T52452
In the weekly triage meeting on 2015-05-06, we discussed this task. We acknowledge that this industry standard manner of operation for editors can lead to some poor outcomes, but as written this isn't actionable and we feel that the issue is not as high priority as the other user-facing work that we need to get done this quarter, so we rejected it as a piece of work for Q4.
comment from Elitre on bug 53210:
Seems I had written about it in an unrelated bug, sorry. This happens on itwp:
in order to do this
http://it.wikipedia.org/w/index.php?title=DNasi_attivata_da_caspasi&diff=60101664&oldid=60089990
I had to delete the word and link it back again. Our guidelines about style
require pages in that section to appear with the capital letter, so we need to
be able to fix that easily.

It is also reported on en.wp, the user states <<When trying to correct a
lower-case letter to a capital letter at the beginning of a link, I deleted the
lower-case letter and found I couldn't type a capital letter and have it become
part of the link, nor could I seem to extend the link over the capital.
Eventually, I typed the capital after the lower-case letter and then deleted
the lower-case letter. It might be good to have some way to extend a link over
adjoining letters/words/text. Mount Flatten (talk) 05:31, 22 August 2013 (UTC)
>>
Thanks.

ps. Might be related to https://bugzilla.wikimedia.org/show_bug.cgi?id=50745
*** Bug 53210 has been marked as a duplicate of this bug. ***
ve.init.mw.Platform.js currently hard-codes searching from Commons, even if the wiki doesn't actually load images from Commons. We should do this based on wiki config instead.

--------------------------
**Version**: unspecified
**Severity**: minor
Change 102377 merged by jenkins-bot:
Use image sources from the fileRepo API

https://gerrit.wikimedia.org/r/102377
Change 102377 had a related patch set uploaded by Mooeypoo:
Use image sources from API's fileRepo

https://gerrit.wikimedia.org/r/102377
This can now be done by using the new meta=filerepoinfo API query, which was introduced into core in gerrit 85344.
**humpface** wrote:

This was very frustrating for my work's internal wiki.  First, I didn't want any Instant Common images (and thanks to James, I was able to remove the line of code).  However, since I disabled the use of Instant Commons ($wgUseInstantCommons = false;), I was still able to search through the Instant Commons but after saving, everything showed up as a broken link.

Suggestion:
- Tie the JSON mediaSources object in ve.init.ms.Platform.js to the $wgUseInstantCommons (i.e., if Commons is turned off in LocalSettings.php, then a user can't search through the images).
(In reply to comment #1)
> Ideally we'd avoid hardcoding Commons entirely and instead of exporting
> isInstantCommons, we'd export fileRepos.

Indeed; that was what I was thinking when I wrote this bug. Title modified to be clearer.
Ideally we'd avoid hardcoding Commons entirely and instead of exporting isInstantCommons, we'd export fileRepos. That should be almost as easy to do and would fix other things as well:

* Wikis where their repo is Commons but through their own wgForeignFileRepos setting (e.g. like on WMF where we use more fine-tuned configuration that does essentially the same, or wikis that configure it but don't use wgUseInstantCommons because they want to set different parameters (e.g. disable repo[fetchDescription] or use a non-default repo[cacheExpiry]).

* Wikis with more than 2 repositories.

* Wikis working with other repos (e.g. a wiki farm might have their own commons-like thing).

Especially reason #1 since we do use InstantCommons in production but not the default settings through the UseInstantCommons toggle. We could hardcode some detection and export "isUsingCommonsAsARepoSomehow", but might as well take a few more minutes and figure out how to just export an array of api urls.


[] https://www.mediawiki.org/wiki/Manual:$wgUseInstantCommons#Details
Not sure the technical term, but: if I hover over, for example, the bugzilla "search bugs" link, it shows as a URL in the bottom left of firefox, allowing me to identify the destination. The same is true in articles in read mode. It'd be good to have this functionality in the VisualEditor, or some other way of more prominently identifying where links are going to: hovering over every. single. one. doesn't really work.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Re-marking as WORKSFORME.
As for the issue of browsers not displaying the link target in the status bar when you hover them: that's a browser problem. Neither Firefox nor Chrome appears to do this for links in a contentEditable.

However, since the filing of this bug we do have a better way than tooltips links to show their targets: when you put your cursor in a link, the context menu now shows the target of the link rather than just a link icon.

So, WONTFIX?
Removing See Also and unassigning; I thought this was about link suggestions in the dropdown in the link inspector, but it doesn't appear to be.
(In reply to comment #1)
> Links are now displaying page URL.Checked in FireFox 20

They are not in Firefox 25.0 on Fedora 19 in VE edit mode for me on https://en.wikipedia.org/w/index.php?title=Wikimedia_Foundation&veaction=edit
Links are now displaying page URL.Checked in FireFox 20 and Chrome Version 26.0.1410.65 using MAC OS X 10.8.5.
Therefore changing the status to resolved-worksforme for now.
If you experience this problem again,please reopen the bug.
I imagine this is mostly due to Firefox's JS engine, but I commonly run across articles that take an extremely long time to load the new VisualEditor interface. For example, "Domestic violence" and "Feminism" take about 30 seconds. Really long articles like "World War II" take over a minute. The interface loads in about half that time in Safari. I'm using Firefox 21.

Comparative loading figures:

| Article | FF 32, 2014-09 | Cr 37, 2014-09
|--|--|--|--|--
| Barack Obama | 17.6s | 17.2s
|--
| Cat | 16.4s | 16.0s
|--
| Beyoncé Knowles | 25.4s | 7.5s
|--
| India | 26.8s | 5.6s
|--
| Richard Nixon | 9.9s | 5.6s
|--
| Europe | 28.3s | 7.1s
|--
| English language | 18.2 | 8.0s
|--


| Article | FF 34.05 2014-12 |Cr 39 2014-12
|--|--|--|--|--
| Barack Obama | 13.23s | 10.61s
|--
| Cat | 11.59s |5.82s
|--
| Beyoncé Knowles | 8.01s|5.13s
|--
| India | 8.90s |5.64s
|--
| Richard Nixon | 8.85s|6.36s
|--
| Europe | 10.31s|6.52s
|--
| English language |6.98s|5.45s
|--
>>! In T52616#3769993, @Elitre wrote:
> T171093 ?

That's for a performance review, which isn't technically the same as making performance improvements. I don't particularly object to merging this into that, but I don't think it's quite right.
>>! In T52616#3769774, @Deskana wrote:
> I actually don't see a more general task for improving performance of the visual editor anywhere, so I guess I'll just leave this as it is for now.

T171093 ?
>>! In T52616#3769774, @Deskana wrote:
> I actually don't see a more general task for improving performance of the visual editor anywhere, so I guess I'll just leave this as it is for now.

Good idea actually: I was telling myself that there is plenty of computers which will not receive the update son (or will never receive an update), and we still have to improve performances for them.
I actually don't see a more general task for improving performance of the visual editor anywhere, so I guess I'll just leave this as it is for now.
>>! In T52616#3769691, @Trizek-WMF wrote:
> Firefox 57 really improves that issue (I can notice it even with my good computer which had a fast enough Firefox). Maybe reconsider that task?

Yeah, I doubt we'll work specifically on improving Firefox 57 performance directly, and instead choose to work on performance more generally. I can merge this into a more general task. In the unlikely event we do decide to work directly on Firefox 57 in the future, this can be reopened.
Firefox 57 really improves that issue (I can notice it even with my good computer which had a fast enough Firefox). Maybe reconsider that task?
This is really a tracker bug more than a specific call-to-action, so we decided in the meeting to remove it from the Q3 blockers list at the triage on 2015-02-11.
Those are pretty major performance improvements, much more than I was expecting. Odd.
Added the new data, one thing to note is if you check chrome before firefox, or check only firefox, the results are almost the same for firefox. but if you check chrome after firefox, it is faster, i guess due to caching. So, more food for thought.
Could you compare loading times for these articles now, three months later?
(In reply to matanya from comment #1)
> I'm using firefox 32 and did some tests on this on en,wikipedia, and beta
> en, which runs HHVM, but is on a virt cluster.

Comparing the time to execute of anything between beta and prod is comparing nothing of value. Different hardware, different cluster sizes (for cache, execute and db) and different code.
Adding timings in chromium 37 for comparison:


Article name:Barack Obama
beta en: 8.1s
en : 17.2s

Article name: Cat
beta en: 7.7s
en: 16.0s

Article name:Beyoncé Knowles
beta en: 5.1s
en: 7.5s

Article name: India
beta en: 4.8s
en : 5.6s

Article name: Richard Nixon
beta en:3.6s
en: 5.6s

Article name:Europe
beta en: 5.7s
en: 7.1s

Article name: English language
beta en:3.5s
en: 8.0s
adding Ori for possible HHVM implications
I'm using firefox 32 and did some tests on this on en,wikipedia, and beta en, which runs HHVM, but is on a virt cluster.

Article name:Barack Obama
beta en: 41.7s
en : 17.6s

Article name: Cat
beta en: 31.7s
en: 16.4s

Article name:Beyoncé Knowles
beta en: 16.9s
en: 25.4s

Article name: India
beta en: 36.4s
en : 26.8s

Article name: Richard Nixon
beta en:16.2s
en: 9.9s

Article name:Europe
beta en: 26.8s
en: 28.3s

Article name: English language
beta en:23.7s
en: 18.2

I think although it is a small test it does show the trend. 

The computer running this test is an i7 quad core from the 3rd gen with 8G of ram, so shouldn't be any issue on this front. 

Would be glad to provide any other info needed.
A contributor requests the following:

I'm sure this is far down the list of problems, but I think the transclusion editor (and other bits with similar display) have way too much white space. For each parameter one gets two blank lines for every one line with parameter name. That is annoying and when templates have dozens of parameters, as many infoboxes and citation templates do, it creates a lot of extra scrolling to find what one is looking for. I'd suggest reducing the whitespace between parameter names by half. Dragons flight (talk) 18:18, 2 July 2013 (UTC)

--------------------------
**Version**: unspecified
**Severity**: enhancement
We did this as part of the transclusion dialog tweaks in August; sorry for the slowness to update.
Disambiguations and other oddities can mean that the first link you select in a typeahead search may not actually be right. You then have to follow the link (which is hard in edit mode) and go looking again.

Being able to get a short preview of the selected link target, similar to what Navigation Popups gadget does when hovering over links, would go miles (kilometers) towards making link selection *awesomer*.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=59208
This is effectively now solved with the link image/data preview
It probably shouldn't be the highest priority, but as an editor, I would like something like this. In fact, I'd find it far more useful than Hovercards: When I'm reading an article and want to know more about a topic to which there is a link, I usually middle-click it to open it in a new tab and read it a bit later, so I don't really need Hovercards. As I am editing, however, it would be useful for me to add a link and  be more sure as to where is the link leading. Is [[Washing Machine]] leading to the article about the appliance or about the Sonic Youth album? Is [[AC/DC]] leading to an article about electrical engineering or about a band? These are real situation in which I found myself recently, and in both of them I had to open a new tab to make sure.

So I would love to see something more than just the title when I'm linking. It doesn't even have to be a full-blown Hovercard - just the first few words are likely to be enough. (Although reusing the Hovercards code makes sense, too.)
I'm not sure this is needed once bug 50240 is fixed, but we should re-consider it then. Also, some form of interaction that doesn't need hover would be needed for touch-screen devices, like mobile.
The template inspector's parameters contain the contents of each parameter, and also a line break, which represents, well, the break between two parameters. When modifying a param, it's all too easy to remove the line break, which results in user-unfriendly things like https://en.wikipedia.org/w/index.php?title=Kidz_Bop_20&diff=prev&oldid=562494239

--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=69682
Agreed, looks fixed.  I can no longer reproduce the problem I had before on $wgEnableCanonicalServerLink (I tried to test with the same exact changes on my sandbox).
…and in fact, this appears to have been fixed already? The leading and trailing newlines from wikitext source are not displayed in the fields in the template dialog, and can not be removed. However, newly inserted template parameters (and newly inserted templates) do not have "smart whitespace" added (this overlaps with T71682 a bit).
The whitespace around the value of parameters should just be preserved (and not shown in the text field at all). This can't be difficult to do, can it?
The bug is open for more than a year, and we get ugly diffs and ugly wikitext. Please increase its severity.

If it isn't possible or it is hard to know whether a template is "inline template" or "multiline template", at least allow manual indication for it (using TemplateData?)
(inspector->dialog; inspector is the context menu with buttons to open a dialog)
Confirmed (https://www.mediawiki.org/w/index.php?title=Manual:$wgEnableCanonicalServerLink&diff=728104&oldid=667291).
If you create a new reference, you can specify a name - great! If you try to modify an existing reference to add a name... https://en.wikipedia.org/wiki/File:VEReferenceEdit.jpg oops.
If we try to name a reference by only using a numeral, the system rejects it and says that numeral only reference names are not permitted.
I feel it is bogus that Visual Editor gets around this by adding a colon: e.g. - :17
That kind of reference name is wrong and unhelpful.
I hope that the ability to manually name references, or at least the ability to manually approve the generated name is restored.
> If you create a new reference, you can specify a name - great! 

It's no longer possible to specify a name even when creating a new reference.
At the triage meeting on 11 March it was agreed that this is too complex and imprecise to keep as a Q3 objective, but that a much more on-point task, {T92432}, could be done instead.
Here's another idea for an automatically suggested (but still editable) ref name that would work with manually formatted citations:  

Use the longest text string is in the citation, appending numbers as necessary to keep the names unique.  You might end up with a lot of refs named "September", but it in many cases it will pick up the most significant keyword in the source's title.
The citoid extension could definitely come up with an automated reference name, but that should be filed as a separate issue as a feature request :). For editing citations, the extension uses the same reference dialog as the rest of VE.
Perhaps Citoid could suggest a ref name.
*** Bug 57459 has been marked as a duplicate of this bug. ***
Useful for default would be to read from the parameters of the cite template if provided. The following would be a useful preference order I think 
1. Lastname and Year (e.g. Smith2013)
2. Author and year (e.g. Bob Smith2013)
3. Lastname and serial number (e.g. Smith001)
4. Title (first 3 words) and year (e.g. FreddieStarrAte1986)
5. domain, underscore, page name (If only a bare url is given) (e.g. bbc_magazine-23969607)
6. fist alphabetic string in reference (when neither a template or a url) and a string of four digits from the reference (e.g. Jones1999)
7. fist alphabetic string in reference and a serial number (when neither a template or a url and no sequence of four digits is present) (e.g. Brown001)
It would even be convenient if VisualEditor suggested a unique label for the ref, perhaps using the first alphabetic string of characters in the ref (usually the first author's last name).
Editor APerson at en.wp, is asking for this and suggests that the name of a reference could be set in the "Options" section along with the group name.
Actually, it even looks like the ability to name a reference has been removed from the reference creation interface. Expanding the scope of this request accordingly.

Being able name references is an important step to allow compatibility with the classic wikitext editor: human-readable names are much easier to use than names like ":5".
See http://en.wikipedia.org/wiki/United_States_v._Windsor right above the 'Dissents' heading. Clear template covers most of quote box.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50395
I can no longer reproduce this, nor the issue in either of the duped bugs (T53872, T54431). (Note that you need to look at older versions of the articles, as the problematic markup was changed since the bugs were filed.)

For future reference, here's a copy Jalexander's screenshot above: {F117777}
*** Bug 52431 has been marked as a duplicate of this bug. ***
*** Bug 51872 has been marked as a duplicate of this bug. ***
Covers most of the box appears to be for latest chrome (what I have). Other report below from FF:

http://i.imgur.com/rAJqIsa.png from FF23 (huge, on top of whole quote box and appears to be pushing other content away too)
https://en.wikipedia.org/w/index.php?title=Colorado_River&diff=562465192&oldid=562442392

When I go here, I have several options for what I can do with the edit:

> Revision as of 19:24, 1 July 2013 (edit) (undo) (thank)

I'd like another option that says "(this edit was made with VisualEditor and introduced a problem; report it here)" or something like that. A JavaScript gadget would be dandy, but I'm not picky about the implementation details.

--------------------------
**Version**: wmf-deployment
**Severity**: enhancement
Rephrasing summary to reflect what the report is about ("Make it easier" is vague and impossible to define when it's fixed).
Screenshot of oddly collapsed resizable area

Not sure whether it is specific to Safari 6 but it seems a bit buggy.

Sometimes when holding down the mouse button the cursor won't change from a  "move" cursor to a "drag/add" cursor (as if it is a regular hover, "move" until it hits the edge of the image and then becomes a regular pointer).

Also when dragging and dropping sometimes it seems to separate the image itself and the thumb container is left behind (!).

When resizing it seems to sometimes (sorry, can't be move specific yet) collapse into a single dot (see screenshot).

--------------------------
**Version**: unspecified
**Severity**: minor

**Attached**: {F11549}
Seems to now be fixed.
Created attachment 12723
Screenshot of misplaced image inspector

It also seems to take about a second for it to apply when releasing the mouse, so the user can continue to drag it else where and then after about 2 seconds into the second drag the image moves back and actually moves to where the first drag put it. It is at this point that the inspector stays behind when dropping near another image (see screenshot).

**Attached**: {F11550}
http://parsoid.wmflabs.org/en/User:Adjwilley/sandbox10?oldid=562331693

Relevant wikitext:

*{{Cite book| last=Fádil-i-Mázindarání | first= Asadu'lláh | authorlink = Mírzá Asadu’llah Fádil Mázandarání | year=1967 | title=Asráu'l-Á<u>th<u>ár, Vol.I| pages= 453 | publisher=Bahá'í Publishing Trust, Tehran | url = http://www.h-net.org/~bahai/areprint/authors/mazandarani/asrar.htm | ref=harv}}

(note the <u> isn't opened then closed, but double-opened)

Output HTML (with data-*, about and a few others stripped):

<li><span typeof="mw:Transclusion"><a rel="mw:WikiLink" href="...">Fádil-i-Mázindarání, Asadu'lláh</a> (1967). <a rel="mw:ExtLink" href="..."><i>Asráu'l-Á<u>th<u>ár, Vol.I</u></u></i></a><u><u>. Bahá'í Publishing Trust, Tehran. p.<span typeof="mw:Entity">&nbsp;</span>453.</u></u></span><u><u><span class="Z3988"><span style="display:none;"><span typeof="mw:Entity">&nbsp;</span></span></span></u></u></li><u><u>

<li>(next item here, note how we're still inside of <u><u>)

--------------------------
**Version**: unspecified
**Severity**: normal
Is this still an issue? Last activity was 12 months ago…
Re-titling to reflect our plan [1] to avoid the leaking and match PHP parser semantics instead.,

[1]: https://www.mediawiki.org/wiki/Parsoid/DOM_notes
https://www.mediawiki.org/w/index.php?title=VisualEditor/Basic_example_worksheet&oldid=751458&veaction=edit

"Foo <tt>bar<tt>\n == Heading == * Lists"
Change 73369 had a related patch set uploaded by Subramanya Sastry:
WIP: (Bug 50536) Improved handling of tree-builder fixup

https://gerrit.wikimedia.org/r/73369
The template encapsulation does not catch all template-affected content, so is not correct really. Alternatively we should be able to undo the leak to match the PHP parser's semantics. That would remove the need for extending the encapsulation in this case.
No, the tpl encapsulation looks correct to me.  The tree builder correction in this case is quite broad and it would be hard to detect auto-correction as well.  On this last example, there are no autoInserted* flags except on the innermost <u> tag.  As long as we are using a html5 compliant tree builder, our options are a little limited on this kind of html without doing more complicated tracking/analyses.  I am not convinced those are worth the trouble and headaches.
Since this is a plain transclusion this is pretty much the behavior I would expect. The formatting is processed in accordance with the HTML spec.

I suspect tidy has a heuristic that closes the <u> at some point in contrast with the HTML spec.

Something that looks broken on the Parsoid side is the missing encapsulation for formatting that spans list items:

echo '<ul><li>{{echo|<u>}}</li><li>foo</li></ul>' | node parse
<body><ul>
  <li><u about="#mwt1" typeof="mw:Transclusion" data-mw='{"target":{"wt":"echo","href":"./Template:Echo"},"params":{"1":{"wt":"<u>"}},"i":0}'></u></li>
  <li><u>foo</u></li>
</ul>
<u>
</u></body>

(reformatted the above a bit and removed data-parsoid for clarity)

We should in theory be able to detect that the leaked <u>s were completely auto-inserted by the treebuilder. Maybe we can use that information to extend the encapsulation for cases like this one.
Diff showing resulting VE breakage: https://en.wikipedia.org/w/index.php?title=User:Adjwilley/sandbox10&curid=38366631&diff=562462441&oldid=562331693 . I'm not sure if the categories being dropped is on the VE or Parsoid side yet.
There should be an edit notice whenever someone tries to use VE which says something like "Slower computers or users trying to use older markup should try editing in the older Editor." and link to the older editor. Otherwise we're directly cutting off plenty of editors who can't figure it out, and would have relatively slow internet.

P.S. My internet is slow enough to not give a satisfactory VE experience, and I consider myself to have decent Indian speed internets

--------------------------
**Version**: unspecified
**Severity**: enhancement
Change 135046 abandoned by Alex Monk:
Attempt to detect slow machines and show an edit notice

Reason:
This is seemingly impossible for me to get right, and just not worth the effort

https://gerrit.wikimedia.org/r/135046
Change 135046 had a related patch set uploaded by Alex Monk:
Attempt to detect slow machines and show an edit notice

https://gerrit.wikimedia.org/r/135046
We discussed how to do this in #mediawiki-visualeditor a bit. Some quotes:

<Krinkle> when a certain amount of time has passed (potentially taking the document complexity in account as well, avoid measuring network by accident), set a boolean flag, which in getEditnotices() will make it include/exclude that notice accordingly
<Krenair> I'm wondering what operation we should measure and what timing shows a reasonable speed
<Krinkle> Krenair: one or more of the actions in the setup of the surface (parsing of html into data DOM, conversion to linenar data model, building of CE etc.)

<Krenair> but those operations will all take different times depending on document length/complexity :/
<Krinkle> Krenair: Yes, but avoiding I mean, taking into account
<Krinkle> e.g. not `timespend > maxtime`, but something like `timespent/doc-size > maxratio`
<Krinkle> RoanKattouw might have some math ideas that are more useful
<Krinkle> However, we should probably do some research and see how slow the 'too slow' browsers really are.
<Krinkle> We might be able to measure it with a very simple operation at a small scale (e.g. create an iframe and attach it, just a random unused iframe), that that one operation is measurable enough, we can do it that way.
<Krenair> Hm. This is getting increasingly out of the 'MediaWiki integration' part
<Krinkle> The function calls are all in viewpagetarget in setupSurface
<Krinkle> though ideally this would probably be in ve-core, seems a useful statistis

Roan, could you comment on this when you have time please?
Timo thinks we can measure performance and display an edit notice if it's slow.
The plan is to get rid of the beta welcome dialog relatively soon (in the next few months), however…
So we already have the beta welcome dialog, I think we should add something like "Users of slow computers should consider doing this." after the "You can keep using the wikitext editor by clicking the "Edit source" tab instead – unsaved changes will be lost."
When I add a link to the title of the page, it is displayed as a normal link instead of a <strong class="selflink">.

Same problem while editing a page with a 'selflink' already present.

The contributor doesn’t see the article as it will be after saving.
Change 345526 merged by jenkins-bot:
[mediawiki/extensions/VisualEditor@master] Follow-up I88d45aad2: Fix selflink detection

[[https://gerrit.wikimedia.org/r/345526]]
Change 345526 had a related patch set uploaded (by Esanders):
[mediawiki/extensions/VisualEditor@master] Follow-up I88d45aad2: Fix selflink detection

[[https://gerrit.wikimedia.org/r/345526]]
Change 342084 merged by jenkins-bot:
[mediawiki/extensions/VisualEditor@master] Render self-links as if they were <strong>s

[[https://gerrit.wikimedia.org/r/342084]]
Change 341775 abandoned by Esanders:
Render self-links as <strong class="selflink">, not <a ...>

Reason:
See I88d45aad2aaa45e71b433350986b19764603a1f2

[[https://gerrit.wikimedia.org/r/341775]]
Change 341774 abandoned by Esanders:
Allow links to be constructed with custom elements

Reason:
See I88d45aad2aaa45e71b433350986b19764603a1f2

[[https://gerrit.wikimedia.org/r/341774]]
Change 342084 had a related patch set uploaded (by Jforrester):
[mediawiki/extensions/VisualEditor] Render self-links as if they were <strong>s

[[https://gerrit.wikimedia.org/r/342084]]
Change 341775 had a related patch set uploaded (by Esanders):
[mediawiki/extensions/VisualEditor] Render self-links as <strong class="selflink">, not <a ...>

[[https://gerrit.wikimedia.org/r/341775]]
Change 341774 had a related patch set uploaded (by Esanders):
[VisualEditor/VisualEditor] Allow links to be constructed with custom elements

[[https://gerrit.wikimedia.org/r/341774]]
>>! In T52497#561368, @Jdforrester-WMF wrote:
> bug 37901

aka T39901 in Phabricator numbering
This will need bug 37901 (a general CSS hinting system for links) to be implemented, which is planned for later this quarter. Hinting that links should be red (non-existent), bold (current), purple (stubs), orange (redirects) etc. will need to be supported in that service.
**crypticc62** wrote:

For those who might be wondering why selflinks would ever appear in an article: Many pages make use of navigation boxes, such as Template:Extreme Sports. Each navbox usually links to all of the articles that it will be transcluded to. So, with several hundred navboxes, each appearing on at least a dozen pages, we can expect selflinks to appear on several thousand articles.
Suppose an article contains two lines in Paragraph formatting, and we want to turn the first one into Heading formatting. Select the entire first line (Cursor at beginning of line, Shift-CursorDown) then choose Heading formatting from the selection box at the top. Result: both lines are turned into Headings, not just the first. (Bold and italics formatting changes work correctly and affect only the current line.)

--------------------------
**Version**: unspecified
**Severity**: normal
In Microsoft Word, both character-level styling and paragraph-level formatting are only applied to the one line that was selected either with Cursor-at-beginning-plus-Shift-Cursor-down or with a triple-click. In three of these four scenarios, VE behaves as Word.

As far as I can see, applying character-level styling to a line selected with Cursor-at-beginning-plus-Shift-Cursor-down does not become a pre-annotation on the following line (neither in Word nor in VE): the styling is not applied if I insert text at the beginning of that line.
This is the same behaviour as in other rich editors.

By selecting in the manner you've stated ("Cursor at beginning of line, Shift-CursorDown") you've selected the current text, the current line, AND the newline into the place before the first character.

If you mark the text as bold (which is character-level) the boldness becomes a "pre-annotation" on the second line before the first character (so typing anything at that point will become bold).

However, changing the format (rather than styling) of some text applies to the entire paragraph (because that's how HTML works) – i.e., the entire second line gets this applied.

We could theoretically apply different behaviour for styling and formatting, so we apply over a newline for the first but not the second, but that might be more unexpected?
This issue exists for all kind of formatting from the Headings pull-down menu.
Add a way to mark a parameter to be dependent on an other paramter. For example :
We have following parameters:
"foo1_bar", "foo1_baz", "foo1_quux" 
...
 "fooN_bar", "fooN_baz", "fooN_quux"

fooX_bar required fooX_baz to be used as well, it doesn't require fooX_quux to be used, but if fooX_quux is used, then fooX_bar must have been defined as well

--------------------------
**Version**: unspecified
**Severity**: enhancement
Well, I have another case: In German Wikipedia we have Template:Charteintrag, where not only such dependencies are required (eg if “POS_xy” then also “WO_xy”), but even the parameter names depend heavily on earlier added parameters. If I enter 1=x and 2=y, the possible parameters following are POS_x (with WO_x) and POS_y (with WO_y), but of course not eg POS_z! At the moment TemplateData is totally useless with this template, I fear.
[Moved from bug 60358 discussion.]

(In reply to Helder from bug 60358 comment #10)
> (In reply to James Forrester from bug 60358 comment #9)
> > (In reply to Helder from bug 60358 comment #8)
> > > (In reply to James Forrester from bug 60358 comment #6)
> > > > (In reply to Ricordisamoa from bug 60358 comment #5)
> > > > > or a set of fields may be mutually exclusive (and yet one of them would
> > > > > be required).
> > > > 
> > > > That doesn't make sense. "Required" means "the template will die horribly if
> > > > you don't include this". It is *not* a "we'd like you to fill this in" –
> > > > that's what "suggested" is for. Most templates will have no 'required'
> > > > fields.
> > > 
> > > It seems perfectly valid for a template to require that "either A or B be
> > > provided" and the user should be able to delete one of them if it is not
> > > needed.
> > 
> > This feels like a pretty edge case (and suggests that we should consider
> > whether the template should be re-written to be less anti-human); maybe file
> > a TemplateData bug to ask for a way to express this relationship?
> 
> This kind of relationship between parameters was requested on bug 50407.

Well, as I see it, this bug only asks for param-level relationships – if A also B; if C not D; etc.

Should we extend it for shared-param relationships (exactly one of A, B and C are required; D is an alias for E if F is set but is an alias for G if F is not set; …), or should we create a new bug? (BTW, this feels like a potentially ever-expanding system could be created, and we'd probably say this adds too much complexity for the value.)
Change 73708 abandoned by Krinkle:
Add depends and conflicts parameters

Reason:
Closing for now to clear review backlog. Can be re-activated when the feature request is accepted.

https://gerrit.wikimedia.org/r/73708
at en.wp a user has given the example of [[template:for]] where parameter 3 is optional unless parameter 4 is specified, when it becomes mandatory.

They expected that VisualEditor would give them a warning about using parameter 4 without parameter 3. Obviously this is not possible until TemplateData can define such relationships.
(In reply to comment #3)
> Note that as for a parameter "going together with" other parameters, this is
> what a "Set" is for.
> 
> Though Sets are merely suggestive and allow for overlap, it us a lot easier
> to
> work with from a user interface perspective.
Set doesn't make any sense for parameters like "author1, author2, ..., authorN"
> 
> Though TemplateData is generic and should not be tailored specific for
> VisualEditor, right now I'd recommend we hold off on this change until we
> find
"depends" and "conflicts" are pretty much not tailored for VE at all (Though I could agree, sets are).
> out and/or verify that this can be properly represented in a user interface
> without making it too complex.
The most important thing is that common templates can be modeled correctly without ending up with too many false choices, or hiding true choices because they couldn't be modeled correctly.
Note that as for a parameter "going together with" other parameters, this is what a "Set" is for.

Though Sets are merely suggestive and allow for overlap, it us a lot easier to work with from a user interface perspective.

Though TemplateData is generic and should not be tailored specific for VisualEditor, right now I'd recommend we hold off on this change until we find out and/or verify that this can be properly represented in a user interface without making it too complex.
Change 73708 had a related patch set uploaded by AzaToth:
Add depends and conflicts parameters

https://gerrit.wikimedia.org/r/73708
See also [[User:קיפודנחש/TemplateParamWizard#Depends on]].
https://en.wikipedia.org/w/index.php?title=Stand-your-ground_law&diff=562005779&oldid=561464750 is a good example (hat-tip to MatMaRex)

--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50120
Done and will be deployed tomorrow.
This should be fixed now. Rejoice!
Change 72233 merged by jenkins-bot:
Array.prototype.splice polyfill for Opera

https://gerrit.wikimedia.org/r/72233
Change 72233 had a related patch set uploaded by Matmarex:
Array.prototype.splice polyfill for Opera

https://gerrit.wikimedia.org/r/72233
function testSpliceBroken() {
	var n = 256;
	var a = [];
	a[n] = 'a';
	
	a.splice( n+1, 0, 'b' );
	
	return a[n] != 'a';
};

This yields 'true' on Opera.

That's probably the bizarrest browser bug I've ever seen, and it seems to be the root cause of this.
Funnily, my testing shows that the categories are only moved inside the reference if it contains a template. Inserting an empty or text-only reference results in the cateogires eing killed entirely.
Eh, it seems to be Opera-specific after all, I can't reproduce on Firefox (but it reproduces reliably in Opera).
(In reply to comment #1)
> Another is
> https://pl.wikipedia.org/w/index.
> php?title=Waldemar_Kasta&diff=36944980&oldid=36944831

Bartosz,

Both these corruptions were by you - were both of them made using Opera? If so, I'm happy to mark this bug out to you (but please clean up after yourself when editing using a blacklisted browser).
Very strange, looks like metadata is being moved somehow. Do we have any information about what the editors did to provoke this?
Another is https://pl.wikipedia.org/w/index.php?title=Waldemar_Kasta&diff=36944980&oldid=36944831 .
Screenshot

Firefox 21.0, Windows 7 - see screenshot.

--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=49896

**Attached**: {F11161}
This looks like it is caused by bug 49896.
This is a legacy of wiki-syntax, where all external links have to begin with the protocol. It would be nice to make the VE link inspector smarter than this.

"www.google.com" is almost certainly meant to be an external link - if there is an article by this name, then it could be shown in the link inspector dropdown as well, but the option for "External link" definitely needs to be there. Even something like "royal.gov.uk" should be recognised as a URL.

Requiring "http://" or some other protocol at the start is confusing for the newbie, as the protocol component of URLs is generally ignored nowadays.

--------------------------
**Version**: unspecified
**Severity**: enhancement
So we now have a separate external link input, but it shows URLs without a protocol as invalid :/
>>! In T52360#542816, @Krinkle wrote:
> We solved this to some degree in WikiEditor with the link dialog in that extension. We can probably re-use some of that logic.

https://github.com/wikimedia/mediawiki-extensions-WikiEditor/blob/master/modules/jquery.wikiEditor.dialogs.config.js#L131

By looking for www.? Yeah, that doesn't work. phabricator.wikimedia.org should be recognised, as well as the bug creator's suggestion of royal.gov.uk.

Sounds like {T76398} would fix this by having the user deal with it instead.
*** Bug 56490 has been marked as a duplicate of this bug. ***
We solved this to some degree in WikiEditor with the link dialog in that extension. We can probably re-use some of that logic.
Screenshot of bug

1. Go to [[de:Special:PendingChanges]]
2. Visit one of the linked articles and edit it in VE

Notice the wide right margin, caused by the floating FlaggedRevs status box.

--------------------------
**Version**: unspecified
**Severity**: normal

**Attached**: {F11085}
Indeed, probably fixed a while ago…
Seems fixed?
At the moment adding categories (through "page settings") involves turning away from the actual content. This is a problem because a lot of categories are dependent on the actual content, which needs to be referred back to - birth or death years, college, etc, etc.

Suggestion is:
* Show the existing categories in the standard skin location (at the bottom of the page, in Vector)
* Make the categories editable there, in some way.

----
Original onwiki comments were [[https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback/Archive_2013_6#Categories_-_display_them.2C_please |archive 6]] 
> I can see categories when I read an article. I can see them below the editing paraphernalia when I'm in Edit Source. But in VE I can only see them by clicking "Page Settings", which (a) takes a click and (b) means I can't see any of the article content (eg the hard-to-remember-the-spelling district name, the birth date, etc which I might want to use in creating categories, having seen that they aren't already there). Please display the categories in or around the article, not just as "Page settings".
and [[https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback/Archive_2013_7#Categories:_please_display_them_in_VE_-_not_the_right_bug |archive 7]]:
> I want to be able to see the categories when I've got an article open in VE: just as I can see them when reading the article, or when editing it in Edit Source. I don't want to have to click on "Page Data" to find out whether or not it's already got categories.

--------------------------
See also: {T67518}

merged duplicates: {T53153} and {T71506}
>>! In T52239#1562999, @John_Broughton wrote:
> It would be a definite improvement if the user could reach categories either via a top menu, or by scrolling to the bottom of the page. As several people have pointed out, there are disadvantages of the user being able to do only one of these, and - of course - there is no reason, from a programming viewpoint, why there can't be two paths to the same dialog.
> 
> So yes, I support (a) making existing categories visible at the bottom of a page, when in editing mode, (b) having something at the bottom of the page that, when clicked, will open the dialog where categories can be added or deleted, and (c) leaving that dialog accessible via the Pages options menu.

This sounds like a good path forward. It gives two paths to one dialog rather than two different dialogs. Hopefully, we can also extend the bottom-of-the-page experience to the read mode at some point.
It would be a definite improvement if the user could reach categories either via a top menu, or by scrolling to the bottom of the page. As several people have pointed out, there are disadvantages of the user being able to do only one of these, and - of course - there is no reason, from a programming viewpoint, why there can't be two paths to the same dialog.

So yes, I support (a) making existing categories visible at the bottom of a page, when in editing mode, (b) having something at the bottom of the page that, when clicked, will open the dialog where categories can be added or deleted, and (c) leaving that dialog accessible via the Pages options menu.
I was pointed to this bug because of a feedback comment. I mostly see discussion about category editing on the page itself. Another feature hotcat offers is to navigate the category-tree, so it is quite simple to put an article in a subcat, or to bring it to a category above it. Can that feature be considered as well?
How about extracting the categories editor and making it a beta feature as "HotCatoid"?
Just reinforcing @whatamidoing-wmf's point. This is one of those features where some user feedback would be welcome indeed, to see whether we are planning to put the right effort in the right feature. My totally subjective impression is that editors seem to be happy with HotCat, where you don't need to deal with wikitext at all. IMHO HotCat's UI could welcome some enhancements, but editing categories at the bottom of the page (where categories are found) seems to be unproblematic.
Just reinforcing @whatamidoing-wmf's point. This is one of those features where some user feedback would be welcome indeed, to see whether we are planning to put the right effort in the right feature. My totally subjective impression is that editors seem to be happy with HotCat, where you don't need to deal with wikitext at all. IMHO UI could welcome some enhancements, but editing categories at the bottom of the page (where categories are found) seems to be unproblematic.
This has been discussed several times on wiki, and none of the experienced editors have mentioned concerns about having to scroll all the way to the end of the page.  However, if you're worried about that, then you could leave an item in the toolbar that either jumps to the end of the page, or that does exactly what it does now.
>>! In T52239#1477765, @Jdforrester-WMF wrote:
> Certainly I think this should only happen at the bottom of the page, not the window, yes.

In that case, we'd either be duplicating controls (if we leave the current category interface in) or removing the ability to edit categories without a bunch of scrolling (if we take the current interface out).
Certainly I think this should only happen at the bottom of the page, not the window, yes.
I'm not sure this would actually be easier for the user. Currently, you can edit categories whenever you want without losing your place in the article; if we just stuck a category widget at the end of the document, you'd have to scroll all the way to the bottom every time you wanted to use it.

We could prevent that by putting the widget in a static flyout at the bottom of the window (as opposed to at the bottom of the //document//). But that means taking more screen space with the interface and splitting the editing tools between two different locations.
*** Bug 69506 has been marked as a duplicate of this bug. ***
pamdavies7: It is not "such a big ask" and the problem is well understood. This is an enhancement request with low priority because there are currently more important things to do, but this will be handled at some point.
In case you have a tech background, patches are welcome: http://www.mediawiki.org/wiki/Developer_access
To expand on my point of 07-07: if I'm stub-sorting an article which already has categories, a common technique is to look at a key existing category, see if it has a stub category, if not then go to its parent category, and onwards up the tree (particularly useful in biological taxa etc which are so hierarchic); another technique is to assign a broad stub category and then look at the sub-categories of the stub-category, as being much quicker than going to the full stub listings. Neither of these approaches is possible with VE - I have to either open the article a second time in another tab, or quit VE and do it in Edit Source. 

Please just display clickable links for the categories while I'm editing the article in VE. Is it such a big ask?
I've been told that [Wikipedia:VisualEditor/Feedback#Categories:_please_display_them_in_VE_-_not_the_right_bug my request] is covered by this bug, so I'll restate it here: please make the categories visible when I'm editing in VE. I can see them when I read an article, or while I'm editing in Edit Source, and I shouldn't have to click on "Page Data" to find out whether the article has been categorised or not.
We've discussed (but there's no bug for it - until now) duplicating the editing of categories in a box at the bottom of the article that would look similar to/the same as the category box in Vector (but with hidden categories shown, and inherited categories not shown). We'd have to properly design this, of course, so it may take a little time.

There's also a proposal to make the dialogs themselves smaller - bug 49549 - and draggable - bug 49969.
See the screenshot. I get that it's sort of a one-sided diff in a <poem> box, but it isn't particularly useful to review since no tweaks made by the VE that are problematic could be picked out; one would have to review the entire article, in markup.

I'm not sure if there's a better way to work it or if the answer is just to kill it for new page creations, but.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Closing since (1) we don't have a clear suggestion here, (2) some power editors clearly find the tool useful, and (3) it would be needlessly confusing to normally have a "review your changes" button, but take it away when you're creating a page. I've opened T106926 for the main design inconsistency between the two flavors of the dialog.
(Oliver Keyes, where's the screenshot?)

Currently on enwiki and mediawiki.org [Review your changes] on a new page displays the wiki text in a <pre> tag, so the wiki markup continues way off to the right side and is almost unusable.

If VE just gave it a style "ve-review-newpage" and give it something like
   white-space: pre-wrap;
it would be somewhat usable. Or you could use a poem-like div, from comment #0 it sounds like VE used that in June.

Cheers,

(In reply to comment #0)
> See the screenshot.
Where? I see no attachments.
I disagree; albeit as a power-user, I check the resultant wikitext quite often when I'm doing complex things with templates and parser functions (especially the kind that are subst:'ed).

This will be somewhat moot when we have an HTML-based "review your changes" available as well, but that's some months off at this point. :-( Rewording.
I guess the ask is "can we come up with a better way of handling things, or alternately not load the option to review on new page creations?" The wikitext editor handles it this way, yes. The wikitext editor sucks at it, and shouldn't be providing that button in that scenario ;p.
This is the exact same behaviour as the wikitext editor; I'm not sure what the 'ask' is?
See https://en.wikipedia.org/wiki/Joe_Flacco?veaction=edit - for example, references 24 and 25 under the section "2012 season: Super Bowl MVP". It looks like one of them is using Template:R, which may explain the problem, but I'm not sure if the icon not rendering properly is a template problem or a VE problem.

--------------------------
**Version**: unspecified
**Severity**: minor
Also in https://en.wikipedia.org/wiki/Michelle_%28song%29 sourced to the sfn template, it looks like.
From that article, references 25 and 26 (from {{r}} and <ref> respectively) generate:

{{r}} ->

<span about="#mwt97" class="reference" data-mw="…" rel="dc:references" typeof="mw:Transclusion  mw:Extension/ref" data-parsoid="…">[25]</a></span>

<ref> ->

<span about="#mwt99" class="reference" data-mw="…" id="…" rel="dc:references" typeof="mw:Extension/ref" data-parsoid="…"><a href="…">[26]</a></span>

Is this just because the CSS isn't being applied when it's "mw:Transclusion  mw:Extension/ref" as opposed to just "mw:Extension/ref"?
Edit [[User:This, that and the other/sandbox/VE6]] in VE using IE10:

1. Try modifying the heading text. You have to double-click on the heading to be able to modify it. Hopefully this stupid IE behavior can be worked around.

2. Double-click, and modify the heading text. "Save page" button is still disabled.

--------------------------
**Version**: unspecified
**Severity**: normal
This was fixed by undoing MW's overflow:hidden style on headings in https://gerrit.wikimedia.org/r/#/c/144104
link icon not square

See attachments. Reproduced in Chrome and Firefox by the original reporter, and me.

--------------------------
**Version**: unspecified
**Severity**: minor

**Attached**: {F11416}
This has been fixed, AFAICT.
Created attachment 12611
overlapping recycle bin

**Attached**: {F11417}
It looks like we currently output both for some modules.

Current output on a wiki with user and site css/js enabled[1] but empty:

<script>if(window.mw){
mw.loader.state({"site":"loading","user":"loading","user.groups":"loading"});
}</script>
<script>if(window.mw){
mw.loader.load(["mediawiki.action.view.postEdit","mediawiki.user","mediawiki.hidpi","mediawiki.page.ready","mediawiki.searchSuggest","mediawiki.page.watch.ajax","ext.vector.collapsibleNav","ext.visualEditor.viewPageTarget","skins.vector.js"],null,true);
}</script>
<script>if(window.mw){
mw.loader.state({"site":"ready"});
}</script>
<script>if(window.mw){
mw.loader.state({"user":"ready"});
}</script>
<script>if(window.mw){
mw.loader.state({"user.groups":"ready"});
}</script>

The first one with "loading" is always output. The last 3 with "ready" are output by OutputPage::makeResourceLoaderLink if $module->isKnownEmpty is true.

We should probably optimise this to just output "ready" in the first place.

--------------------------
**Version**: unspecified
**Severity**: enhancement
> resourceloader: Refactor module links output 
>
> Change-Id: I91754ce5fae3d05b4bfa7372372eba81ee2fc579
This looks fixed for me, because at the moment I will get directly
mw.loader.state({"site":"ready","user":"ready","user.groups":"ready"});
when there is no site or user js page (bug 46857?).
https://www.mediawiki.org/wiki/Help:Magic_words#Variables

{{CURRENTYEAR}}, {{CURRENTMONTH}], etc. - possibly a pop-up inserter with a brief description of what each do (and their current value?)

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=62740
Change 278429 abandoned by Alex Monk:
[WIP] Add MagicWord::getDocs and i18n messages for documentation of magic words

[[https://gerrit.wikimedia.org/r/278429]]
Change 140445 abandoned by Alex Monk:
[WIP] Allow TemplateData to output information about magic words

[[https://gerrit.wikimedia.org/r/140445]]
Change 278429 had a related patch set uploaded (by Alex Monk):
[WIP] Add MagicWord::getDocs and i18n messages for documentation of magic words

[[https://gerrit.wikimedia.org/r/278429]]
Change 140445 had a related patch set uploaded (by Jforrester):
[WIP] Allow TemplateData to output information about magic words

[[https://gerrit.wikimedia.org/r/140445]]
Change 140445 had a related patch set uploaded by Alex Monk:
[WIP] Allow TemplateData to output information about magic words

https://gerrit.wikimedia.org/r/140445
2014-06-16 22:00:29	<Krinkle>	but we'll need to implemetn support for the colon argument in Parsoid and VisualEditor DM first.
(In reply to Alex Monk from comment #5)
> Apparently some of the magic words involving 'colon arguments' will need
> Parsoid/VE DM support.

Does Parsoid not split out the zeroth argument or something? If so, is there a bug that this can be made semi-dependent on?
Apparently some of the magic words involving 'colon arguments' will need Parsoid/VE DM support.
(In reply to Alex Monk from comment #3)
> Actually, maybe we should just have VE query
> api.php?action=query&meta=siteinfo&siprop=magicwords, then load a
> documentation message for it in the given language.

no, ignore this
Actually, maybe we should just have VE query api.php?action=query&meta=siteinfo&siprop=magicwords, then load a documentation message for it in the given language.
So we need to:

* Alter TemplateData to provide documentation for magic words
* Add extra field to template insert dialog for the addition of magic words.
Feel like taking this on? It'd be a step towards fixing bug 50855 in general… Big fun challenge. :-)
It should be possible for users to modify the location of the TOC (see bug 49224 for getting it shown and updated as they edit), and the system should insert a __TOC__ identifier (that should be silently dropped by Parsoid when not needed?).

--------------------------
**Version**: unspecified
**Severity**: enhancement
Because the VE splits up the destination of a link and the text displayed for it (quite rightly) it's impossible, in VE mode, to identify where links point to without source editing. This is kind of a problem for disambiguation issues, for example. Is there any way that this could somehow be hunt-down-able?

--------------------------
**Version**: unspecified
**Severity**: enhancement
It's nice, but doesn't really address the workflow in comment 3.

(In reply to James Forrester from comment #3)
> However, this doesn't work well if you know there's one link to [[foo|xxx]]
> somewhere on the page and you want to change it to [[bar|xxx]], I agree.
This is now done with the new context widget system.
No, hovering over each link is not the answer: if I'm looking at a large article and want to find and amend the link which is pointing to some particular other page (perhaps in connection with cleaning up dab pages etc), I want to be able to use something like ctrl-F "Find" as I can at present: once the article is open in Edit Source, the hidden text is searchable.

As an example, look at [[User:PamD/sandbox for VE]] and find the link to [[Dunmallet]]. Now imagine if that page was the length of [[London]] and you needed to find a similar piped link.

Might also be an issue if people want to find (and check parameters of, or amend, etc) one particular template which is used on a page, but doesn't "show up" in the visible article. And probably various other scenarios. ~~~~
(In reply to comment #0)
> Because the VE splits up the destination of a link and the text displayed for
> it (quite rightly) it's impossible, in VE mode, to identify where links point
> to without source editing. This is kind of a problem for disambiguation
> issues, for example. Is there any way that this could somehow be
> hunt-down-able?

Hover over the link; that's the target, not the anchor, that comes up in the pop-up tooltip. 

However, this doesn't work well if you know there's one link to [[foo|xxx]] somewhere on the page and you want to change it to [[bar|xxx]], I agree.
The workflow of "this article has DAB issues, it's pointing to [disambiguation page], I should point it to [proper page], now to find the link that's pointing to the disambig- shit."
You can just click the floating "chain" icon to see the name of the destination article. 

What does this bug relate to in particular? Was there some use case where this isn't working/isn't possible?
User:JohnCD at English Wikipedia writes the following:
"If you enter, for instance, "Welcome" in the new template box, on clicking "Apply changes" you see the result; but if you enter "subst:welcome" you see only {{subst:welcome}}, though after clicking "Save page" the result is correct. Should there be a check-box for "subst" in the New template dialogue, (a) to save typing it out, (b) to arrange the correct display?"

James F. suggested this would be good to enter as an enhancement request, since template substitution should be supported.

Maggie

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=66281
[[ https://fr.wikipedia.org/w/index.php?title=Wikip%C3%A9dia:%C3%89diteurVisuel/Avis&diff=0&oldid=123998059#Subst_dans_le_mod.C3.A8le_ouvrage | New feedback ]] concerning that task (here, need to subst: a date on a template included with VE).
>>! In T51904#1406296, @Krenair wrote:
> I'm not sure the parsoid API from T73161 is quite what we were looking for. The idea had been to allow the user to mark a template to be substituted upon save, but with this we'd have to substitute an entire transclusion (immediately?)

If you look at this task's description, it asks for being able to do a subst when inserting a template from the template dialog box. Also, according to the description, susbt already works when saving.
If I have misunderstood this feature and how it would work inside VE, then we should talk more on IRC sometime to get clarity about how this would / should work and update it here, and we can make appropriate updates to the API.
>>! In T51904#1406342, @Krenair wrote:
> Substituting things directly on the client? That sounds like we'd run into more issues involving unbalanced html fragments?

Yes, subst directly on the client. In VE, as far as I understand, you cannot add transclusions that generate unbalanced HTML since you have to ask Parsoid for an expansion and you get balanced DOMs always.

So, as far as I can imagine, this subst feature in VE will have to be in-edit substitution of DOMs rather than on-save substitution of arbitrary wikitext.
>>! In T51904#1406342, @Krenair wrote:
> Substituting things directly on the client? That sounds like we'd run into more issues involving unbalanced html fragments?

Yes, subst directly on the client. In VE, as far as I understand, you cannot add transclusions that generate unbalanced HTML since you have to ask Parsoid for an expansion and you get balanced DOMs always.

So, as far as I can imagine, this subst feature in VE, it will have to be in-edit substitution of DOMs rather than on-save substitution of arbitrary wikitext.
Substituting things directly on the client? That sounds like we'd run into more issues involving unbalanced html fragments?
But yes, you would have to substitute transclusions immediately, rather than "on-save" as with the wikitext PST mode of operation.
>>! In T51904#1406296, @Krenair wrote:
> I'm not sure the parsoid API from T73161 is quite what we were looking for. The idea had been to allow the user to mark a template to be substituted upon save, but with this we'd have to substitute an entire transclusion (immediately?)

But, whenever a user edits a transclusion, you are querying the API to fetch the expansion. So, you would enable the subst parameter alongwith the query instead of marking up individual transclusions for 'at-save' substitution. Once substed, the transclusion itself goes away and the editor can further tweak that output if required.
I'm not sure the parsoid API from T73161 is quite what we were looking for. The idea had been to allow the user to mark a template to be substituted upon save, but with this we'd have to substitute an entire transclusion (immediately?)
Change 153895 abandoned by Alex Monk:
Add a subst property to template data which adds "subst:" to the target

Reason:
I'm not actually planning to work on this commit. The associated VE commit will continue to depend on this however.

https://gerrit.wikimedia.org/r/153895
Change 153934 had a related patch set uploaded by Alex Monk:
Provide a checkbox on template page of transclusion dialog to substitute when saving

https://gerrit.wikimedia.org/r/153934
Change 153895 had a related patch set uploaded by Alex Monk:
Add a subst property to template data which adds "subst:" to the target

https://gerrit.wikimedia.org/r/153895
Subst:ing isn't working (again?  still?).  

If you follow the (soon-to-be-blanked) directions in the user guide, you get the text typed in, with no display, no expansion, and no processing.  The result is that the exact wikitext of your template displays on the page, exactly as if it had been nowiki'd, but without the nowiki tags.

https://en.wikipedia.org/w/index.php?diff=620566012&oldid=618729009
Not only in insert dialogue. Template text should be inserted and rerendered page immediately.
for example:
-[[:en:Template:Accent]]
-[[:ru:Шаблон:Ударение]]

i do
-te|xt
-insert/template - subst:Ударение

i see in VE
-te{{subst:Ударение}}xt
(after saving the page text in read mode looks normally: téxt)


I want to see in VE
-téxt

if possible it should be a new method "template (with parameters) to text ()" with no return to template
for example:
-"insert/subst" or "insert/template" and in dialogue check-box for "subst"
-open TemplateData for "template" (now for "subst:template" TemplateData not shown)
-press Add template
-template is executed and generate new text which is inserted same as ctrl+v
-the new text (or all page) rendered (may consist any other template inside it)
*** Bug 59182 has been marked as a duplicate of this bug. ***
(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #2)
> > > This is effectively a subset of bug 49833 which seems to be part tracking,
> > > part bugs, part enhancement requests
> > 
> > … part mess. :-(
> > 
> > Not sure why you turned it into a tracker after Krinkle mis-named it; I don't
> > think it helps at all. I might undo that.
> 
> Sorry, that would be my misunderstanding of Krinke's intentions and then
> trying to be helpful. :(

Not your fault at all. :-) All fixed now, anyway.
(In reply to comment #3)
> (In reply to comment #2)
> > This is effectively a subset of bug 49833 which seems to be part tracking,
> > part bugs, part enhancement requests
> 
> … part mess. :-(
> 
> Not sure why you turned it into a tracker after Krinkle mis-named it; I don't
> think it helps at all. I might undo that.

Sorry, that would be my misunderstanding of Krinke's intentions and then trying to be helpful. :(
(In reply to comment #2)
> This is effectively a subset of bug 49833 which seems to be part tracking,
> part bugs, part enhancement requests

… part mess. :-(

Not sure why you turned it into a tracker after Krinkle mis-named it; I don't think it helps at all. I might undo that.
This is effectively a subset of bug 49833 which seems to be part tracking, part bugs, part enhancement requests
Lots of important templates need subst. On en {{prod}} and {{afd}} both need to be subst.
It seems that the server part of this is already correct.  The client just needs to add printable=1 to requests for JS-wrapped CSS should include printable=1, when the page is in print mode (printabable=yes).

This is necessary to make sure that screen CSS is omitted and print CSS is not wrapped in @media print for this use case.

--------------------------
**Version**: 1.22.0
**Severity**: normal
Given {T24256} was resolved, that means the printable mode is essentially no longer discoverable/advertised to users. I'm closing this task in favour of T167956.
I think {T24256} is definitely better than simply dropping the link entirely (although we'd have to hide it for no-JS).  A feature is only useful if users know about it, and I think having the link exposes the fact that our pages look reasonably good when printed.
I do know that the "printable" link, in the past had surprising amount of traffic for other websites. As in: without it, people don't know how to print (yes, i know, i know...)

So if we do remove the printable mode, then having the JS enabled print mode link is probably quite desirable I suspect.
> Given that we should support printing the view page directly, perhaps it makes sense to remove the "Printable" mode from MediaWiki? 

{T24256}
>>! In T51722#569487, @Mattflaschen wrote:
> [..]
> That illustrates that the print styles apply to the current DOM, not the original HTML source.  So even if the JS doesn't run in printable=yes, all the print styles still need to be correct in case they just print directly (without using printable view).

I agree. In fact, I suspect users that print pages would just print directly. It seems counterintuitive to first open a "Printable version".

Given that we should support printing the view page directly, perhaps it makes sense to remove the "Printable" mode from MediaWiki? The interface to print pages is part of the web browser. Having a control for it seems redundant.

If we want to keep it, we could collect analytics on popularity of printable=yes views in relation to [print events](http://tjvantoll.com/2012/06/15/detecting-print-requests-with-javascript/) (from both printable, and regular mode).
Not actively working on this, so putting it back in the pool, but I think the original issue holds.  It seems we should either:

1. Pass printable to load.php on printable=yes pages.
2. Not run JS on printable=yes pages (as Krinkle says was the case earlier).
Change 69276 abandoned by Krinkle:
ResourceLoader: Pass printable parameter to load.php.

Reason:
Closing for now.

https://gerrit.wikimedia.org/r/69276
(In reply to comment #2)
> Which is wrong, those things are not supposed to be loaded on a print page
> (to avoid e.g. collapsible buttons, "[show]", etc.). Though some of those are
> hidden by CSS, it'd be better for them to not initialise in the first place.

Well, if we do that, we need to find an equally simple way to debug the print CSS.  There are extensions that are supposed to do it (e.g. https://addons.mozilla.org/en-US/firefox/addon/web-developer/), but it shows the screen *and* print styles.  There's probably a good way to do it, just need to find it.

More importantly to the average user, we may want to run some JS on the printable=yes view.  People sometimes read in that view, and there's some stuff that works in that bare-bones mode.

For instance, the reference popups on enwiki (https://en.wikipedia.org/wiki/MediaWiki:Gadget-ReferenceTooltips.js) currently work there, and it seems useful.  You can even get the popup to print with some finagling.

That illustrates that the print styles apply to the current DOM, not the original HTML source.  So even if the JS doesn't run in printable=yes, all the print styles still need to be correct in case they just print directly (without using printable view).
We didn't pass this to the client and on to load.php because printable pages shouldn't run run any load queue.

http://mediawiki.dev/?printable=yes gives me:
> #top:
> mw.loader.load(["mediawiki.page.startup","mediawiki.legacy.wikibits","mediawiki.legacy.ajax"]);
> #bottom:
> mw.loader.load(["mediawiki.action.view.postEdit","mediawiki.user","mediawiki.hidpi","mediawiki.page.ready","mediawiki.searchSuggest","mediawiki.page.watch.ajax","ext.vector.collapsibleNav","ext.vector.collapsibleTabs","ext.visualEditor.viewPageTarget","skins.vector.js"],null,true);


Which is wrong, those things are not supposed to be loaded on a print page (to avoid e.g. collapsible buttons, "[show]", etc.). Though some of those are hidden by CSS, it'd be better for them to not initialise in the first place.

I think this is a regression. If memory serves, not so long ago there were no mw.loader calls on the printable view. Perhaps a change in Skin caused them to be inserted unconditionally?

Either way, if there is no other way around it, then the proposed change is good, but I'd prefer to prevent the client-side loader from being set up in the first place (so only the <link only=styles> will run).
Related URL: https://gerrit.wikimedia.org/r/69276 (Gerrit Change I691588c39da7fadeac1ca2ace2c1b769fc4e1bd6)
When I am editing an old revision of a page and then view the diff before saving it is the diff between the current version of the page and my edited version it seems. I was expecting to see the diff between the old revision and my edited version.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Oh I wasn't aware the wikitext-editor is doing the same. Then I guess you can close it. It should probably be consistent.

And yes the message could probably be improved.
This is the same behaviour as the wikitext editor. :-)

Theoretically we could have diff-against-current and diff-against-starting-point, but that could be a bit messy.

Do you think the message ("review your changes" in VE against "review changes" in wikitext) is confusing and should be changed?
Screenshot

See on https://en.wikipedia.org/wiki/Brainbuster for example, at the bottom - screenshot attached. Reproduced in Chrome, Firefox and Safari.

--------------------------
**Version**: unspecified
**Severity**: minor

**Attached**: {F11473}
Seems to be fixed - confirmed in test2/production.
I believe that this was fixed by Ed's work on this last week.
(In reply to comment #2)
> I had wondered whether the fix for bug 54446 would solve this too, but at
> least in Firefox 24.0 on Linux it is still evident.

Yeah, this is actually a rather more fundamental issue (the "next" item from the data model's point of view, if not the user's, is indeed a link). Sorry.
I had wondered whether the fix for bug 54446 would solve this too, but at least in Firefox 24.0 on Linux it is still evident.
This only seems to happen with an image at the start of the lead section and seems unaffected by the presence of a template,

Test case: 
https://en.wikipedia.org/w/index.php?title=User:Thryduulf/sandbox&oldid=567508072&veaction=edit

Real-world example:
https://en.wikipedia.org/w/index.php?title=Boden_Professor_of_Sanskrit_election%2C_1860&oldid=567473898&veaction=edit
See also: T51633, T52341
See also {T88117}
Moving to MW core.
If I'm right that it's consistent with core, this bug should be moved there.
I think this is about VE changing the <title> to "Editing IPod", which doesn't respect displaytitle? If so, this is consistent with core's behaviour...
Current bug summary: "VisualEditor: Title doesn't respect DISPLAYTITLE".

I'm not sure what this means. Looking at the links below, I see various issues, but none related to the <h1>. The <title> is a bit weird, but it's weird without VisualEditor as well.

* https://en.wikipedia.org/wiki/IPod?veaction=edit
* https://test.wikipedia.org/wiki/IPod?veaction=edit

Further clarification (including links) would be helpful here.
Some suggestions of improvements to the media insertion dialog; this is mostly a brain-dump which we might turn into a tracker later:

- a way of accessing the file page, on Commons or elsewhere
- a more clear highlighting
- maybe slightly enlarging the image
- double-click to insert
- filter by: …
-* media type
-* language (mostly specific to audio/video but also maps/diagrams)
-* length (audio/video)
-* resolution (image/video)
-* video bit-depth (image/video)
-* audio bit-depth (video/audio)
-* sample rate (audio)
-* format
-* licence
-* local vs. Commons

Notes:

The image size is based on the largest default thumbnail (the dialog asks for the 300x300px image and then shows it at 150x*px size). Changing this would need to have discussions with Ops about load on the image renderers and possibly changing the default sizes globally.

The filtering will have to wait for Solr faceted search, if that's indeed coing.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51032
It makes more sense to combine all the media-related bugs into bug 37870 as a tracker, and use this for its original intent, to be about structured data about files and using that for inserting.
I'm marking a few other improvement suggestions filed as bugs as blockers so they don't get lost.
It'd be nice to be able to search only by file name, if you know the title or know that that the file you want has a particular word in its name.  "Intitle:apple" cuts the number of images by 70%, which is a big help when there are ~12K files returned on that search.
Per Ed's comment on T50605:

> Above change fixes issue with annotations being dropped, but we still need to fix empty annotations not rendering (e.g. `<span style="display: block; background: red; width: 100px; height: 100px;"></span>`), either here or in a new bug.

This is the new bug. :-)
**Author:** `and.radiate`

**Description:**
Using alpha version as of 11JUN13. Did a small edit on Wikipedia English article "Nagato-class battleship" (deleting 3 letters from [Japanese] to form [Japan] in second sentence under section 5.1 World War II. Then scrolled down; after originally displayed area scrolled off screen, the screen went black in the TAB.  Other TABs in IE remained operative.  Back arrow did not produce any results on black screen or URL showing for the Wikipedia TAB.  Reloaded http://en.wikipedia.org in TAB with black screen; successfull load and correct operation thereafter.  Could not reproduce the error.

--------------------------
**Version**: unspecified
**Severity**: normal
No reproduction steps in three years, over which time it's been significantly changed. I'm marking this as Resolved for now.
and.radiate: Have you seen this problem again with a more recent VE version?
VisualEditor is removing the font weight from the "article" tab when using Monobook on the English Wikipedia.

Steps to reproduce:

* Go to <https://en.wikipedia.org/wiki/Canada_Goose_(clothing)>

* Click "edit this page".

* The "article" tab loses its boldness.

* Clicking the "cancel" button does not restore the boldness.

--------------------------
**Version**: unspecified
**Severity**: normal
Change 130085 merged by jenkins-bot:
Fix tab selection on monobook

https://gerrit.wikimedia.org/r/130085
Change 130085 had a related patch set uploaded by Alex Monk:
Fix tab selection on monobook

https://gerrit.wikimedia.org/r/130085
E.g. [[:fr:Foo]] or [[m:Foo]].

--------------------------
**Version**: unspecified
**Severity**: enhancement
As Roan says, external links are now silently converted to interwikis when appropriate by Parsoid, so this is totally possible, and has been since we fixed it in November.
This is kind of possible now, by creating external links.
I just tried adding a link with [[:w:eo]] and got this:
http://www.mediawiki.org/w/index.php?title=Language_portal%2FWikimania2013%2FEvent_Report&diff=768410&oldid=768371

[Changed the title to avoid confusion with interlanguage links.]
*** Bug 50889 has been marked as a duplicate of this bug. ***
It's actually already possible to create interwiki links by including the interwiki prefix in the link editor; example with wikitech: https://www.mediawiki.org/w/index.php?diff=729932 .

Interwiki links that have been created this way with VisualEditor can still be edited the same way as long as the page isn't saved.

Since this works for new and newly-added interwiki links, I'm not sure why they're blacklisted / green-striped in subsequent edits.
*** Bug 49545 has been marked as a duplicate of this bug. ***
See http://imgur.com/wmAeHRD

--------------------------
**Version**: unspecified
**Severity**: normal
No longer applicable
This is bad, though in a relatively edge case of lanklinks outside the main namespace.

--------------------------
**Version**: unspecified
**Severity**: normal
Change 127419 merged by jenkins-bot:
Use wgPageName instead of wgTitle when fetching language links

https://gerrit.wikimedia.org/r/127419
Change 127419 had a related patch set uploaded by Catrope:
Use wgPageName instead of wgTitle when fetching language links

https://gerrit.wikimedia.org/r/127419
*** Bug 50565 has been marked as a duplicate of this bug. ***
(In reply to comment #1)
> This description is a bit cryptic, so .. is bug 50565 a dup of this bug?

It is, yes; sorry for crypticness. Hope it's a little better now.
This description is a bit cryptic, so .. is bug 50565 a dup of this bug?
Users and categories should not be auto-completed based on page names (API action=opensearch) but instead based on their own respective query modules (list=allusers, list=allcategories) because the existence of a description page is optional and neither a subset nor superset of the database tables.

* Pages can exist for inexistent objects.
* Objects often don't have an associated page.

718db58f introduced category editing with autocompletion from opensearch (with hardcoded 'Category:' prefix). This should be switched to using list=allcategories instead.

That way the input field will no longer include results for inexistent categories, and no longer omit results for existing categories lacking a description page.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=65517
*** Bug 65956 has been marked as a duplicate of this bug. ***
Change 135782 merged by jenkins-bot:
Suggest categories that exist but don't necessarily have pages

https://gerrit.wikimedia.org/r/135782
Change 135782 had a related patch set uploaded by Alex Monk:
Suggest categories that exist but don't necessarily have pages

https://gerrit.wikimedia.org/r/135782
(In reply to comment #1)
> Though I commend the effort for correctness, I don't think that this has ever
> even been brought up in the HotCat feedback. It would be nice though.
> 
> However, an empty category (page only), is still a valid category in most
> workflows (you have to start somewhere), so I think that excluding them is no
> more correct than including categories without pages...

(Whilst not defending the current MediaWiki behaviour) the way you start a new category is either:
* Create the description page
* Add pages to it from wikitext with [[Category: <name> ]]
or:
* Implicitly create it by adding pages to it from wikitext with [[Category: <name> ]]

The same is true for HotCat, afaik you can use a category that doesn't exist yet. The page is optional and the 'Category' table row will be created once there are items in it (though it doesn't delete the row if there are no more children in it, so you can still have category pages for categories that don't "exist" but do exist in the database).

Either way I think it is more likely for a user to want to add a page to a category that is used on another page (which may or may not have a description page yet) then for a user to first create a category page and then add a page to it. Especially on established wikis.

I agree it doesn't really make sense but this is how MediaWiki works. We could change MediaWiki core to also create category rows immediately when the page is created.

We could do 2 ajax requests for every autocomplete action but that seems a bit too much, and given the choice between the two I think completing based on existing categories instead of category description pages, the former is more likely and also has larger volume (there are more categories than there are description pages, there are relatively few category pages for categories that don't exist, ideally a wiki would have none of them).
Though I commend the effort for correctness, I don't think that this has ever even been brought up in the HotCat feedback. It would be nice though.

However, an empty category (page only), is still a valid category in most workflows (you have to start somewhere), so I think that excluding them is no more correct than including categories without pages...
It would be very nice if the Ve would warn you about inconsistencies in header levels (when you are skipping a level for instance)

--------------------------
**Version**: unspecified
**Severity**: enhancement
Nice idea.

Possible rules:

* Use of H1 in the main namespace
* Use of Hn+1 not inside an Hn
* Others?
In https://de.wikipedia.org/w/index.php?title=Anna_Zaja&curid=7691608&diff=118985342&oldid=118754158 a missing space was added after the name, but it should not be inside the bold part.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**URL**: https://de.wikipedia.org/w/index.php?title=Anna_Zaja&curid=7691608&diff=118985342&oldid=118754158
Rephrased to "Whitespace characters should not take a pre-annotation unless they have non-whitespace after them in the annotation". This means that we have to evaluate whether pre-annotation should take place on insertion against both the content and the context, but then re-evaluate on the first non-WS character in a potential pre-annotation. This could get messy.
Situation:
* ResourceLoader wraps modules in closures
* MediaWiki developers put a closure in each file
* As a result loading 1 module with 2 files will have 3 closures

```
mw.loader.implement( 'foo', function ( $ ) {
  --- foo.a.js
  ( function ( $, mw ) { 
    ...
  }( jQuery, mediaWiki ) )

  --- foo.b.js
  ( function ( $, mw ) { 
    ...
  }( jQuery, mediaWiki ) )
} );

inside mw.loader#execute:

  script( jQuery );
```

It has been suggested we add "mw" to ResourceLoader's closure and get rid of the per-file closure.

The downside of doing that would be that they are less safe to use "standalone". e.g. a jquery plugin would be using $ directly, which, outside MediaWiki ResourceLoader context is bad.

There is also the pending refactoring of ResourceLoader debug mode to not be completely different and near useless by executing in the global scope.
Note that this bug isn't blocked on implementing global variable mappings.

This bug basically says:

* Closures added by ResourceLoader are not merely a by-product of the deferred loading. They are part of the eco system and to be relied on.
* Drop the tradition that each .js file should be loadable raw and standalone and instead embrace the dynamic build system.

The main thing blocking this is debug mode. We need to refactor debug mode to not load raw files (bug 62605). Instead it should merely keep them deminified. Ideally with support for source maps (bug 45514).
-- startup:
register(
 ..,
 [ 'ext.visualEditor', 1234, ...., ['VisualEditor']
);

-- mw.loader:
 script( $, global[propKeys..].. );

-- load.php response when loading visualeditor:
mw.loader.implement( 'ext.visualEditor.core', function ( $, ve ) {
 -- include ve.js
 -- include ve.A.js
 -- include ve.B.js
 -- include ve.C.js
} );
Also:


modules['bar'] = {
  scripts: ['bar.a.js', 'bar.b.js'],
  globals: {
    ba: Bar
  }
};

mw.loader.implement( 'foo', function ( $, mw, ba ) {
  --- bar.a.js
    ...

  --- bar.b.js
  ...
} );
Go to some long article (so long that it won't fit on one screen in your browser), start the visual editor, scroll down, then use up-arrow to walk all the way back up to the top of the article. It's not possible: the first lines of the article remain obscured by the visual editor's menu bar; the only way to make them visible is using the scroll bar or with PageUp.


This is Windows 7, Firefox 16.0.2, Chrome 26.0.1410.64 m, Mediawiki 1.22wmf4 (646544a), VisualEditor 0.1.0

--------------------------
**Version**: unspecified
**Severity**: normal
Apparently IE is affected too (see bug 63778).
Go to some long article, scroll all the way down, click to make the blinking cursor visible. Now press and hold the cursor-up key to go all the way back to the top. Upon release of the cursor-up key, the cursor will be invisibly placed behind the toolbar. Another press/release of the cursor-up key is necessary to make it visible again.
I believe that this was fixed some time ago as part of the toolbar fixes - please re-open if not.
I am now seeing the following behavior on mediawiki.org, using both Firefox and Chrome:

Editing a long article with the VisualEditor, scrolling down, and then pressing and holding CursorUp will scroll back to the top, but not quite: the very first line of the article remains obscured by the toolbar. I have to release and repress CursorUp to see that line.
This is now merged and will go out later today.
Change 73015 merged by jenkins-bot:
Bind listener to keyup to capture arrows & better math for scrolling.

https://gerrit.wikimedia.org/r/73015
Change 73015 had a related patch set uploaded by Robmoen:
Bind listener to keyup to capture arrows & better math for scrolling.

https://gerrit.wikimedia.org/r/73015
(In reply to comment #0)
> Go to some long article (so long that it won't fit on one screen in your
> browser), start the visual editor, scroll down, then use up-arrow to walk all
> the way back up to the top of the article. It's not possible: the first lines
> of the article remain obscured by the visual editor's menu bar; the only way
> to make them visible is using the scroll bar or with PageUp.

I can't reproduce this as written (for wmf6 or wmf7 on Mac or Linux, don't have Windows to test on). We did change the behaviour of the toolbar a little in wmf5, which may explain.

However, it /is/ possible using the cursor keys to put the cursor underneath the toolbar when scrolled down so that the user can't see where it is. Will change this bug to reflect that, but feel free to revert if you can reproduce.
Steps to reproduce bug:

* Edit a page and add the following content: `Hello "<code>world</code>".`
* Place cursor before the first quote, then use the arrow keys to move right (after the quote, before W for world).
* Insert a character.

Expected:

The place where the character appears, and the position of the blinking cursor should be the same. In actually, this is not the case.

The cursor is blinking **inside** the code annotation (close to the W, within the padded area of the code block).

The added character appeared **outside** the code annotation (close to the quote, outside the padded area of the code block).

Screenshot of problem (from May 2013):
{F10475}

Video capture (July 2018):
{F23391729}
**orbit** wrote:

Yeah, this is reproducible. No adjustment to margin or padding of the alien (the code element) is able to fix this issue though. We're using native browser selection rendering, and this is a side-effect.

One possible future fix would be to allow the cursor to be placed at the first and last offset of protected nodes (contenteditable would have to be set to true) to give the desired cursor rendering. Any keypress would have to first fixup the selection.

I think this is likely a minor occurrence and making such a dramatic change to protectedNodes is out-of-scope for now.
When ever the user does a load, save, diff (, other?) action with the server, we should check for whether the new edit token is an anonymous one when we're expecting the user to be logged in, so we can warn the user that they're now logged out (to prevent them asking for their IP to be over-sighted, etc.).

There's potentially utility in doing this in core (for the wikitext editor) as well.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Bug 48657 is the request for the same functionality in core's wikitext editor.
In the Category inspector, start setting an over-ride for a category's sort key, but instead of pressing return, click out; no sort key is set. If you change and click "apply", it seems like it should apply but doesn't, confusingly.

Thoughts?

--------------------------
**Version**: unspecified
**Severity**: trivial
Now merged.
Related URL: https://gerrit.wikimedia.org/r/67920 (Gerrit Change I256d2b21bc2306959f6d6a0373386054b21dadfe)
This seems weird to me, but it still might be intentional.

If you put the caret immediately after a sentence ending in a period (e.g. the last sentence of the lede from https://en.wikipedia.org/w/index.php?title=Kono_Statement_of_1993&oldid=546398254&veaction=edit), then click the Link button, it tries to link the last word, including the punctuation.

I would expect it to let you create an new link, without assuming any existing anchor.

--------------------------
**Version**: unspecified
**Severity**: normal
Merged in master; will go out as part of wmf5.
Related URL: https://gerrit.wikimedia.org/r/64481 (Gerrit Change I2408229cddd876ff8fe55a9eddf9bac87a61457e)
Bug.

Because null (the value we get for the end of the sentence) is silently converted to the string 'null' by RegExp#test (!?) and so we think it's an 'ALetter' which triggers the ALetter-MidNumLet-ALetter rule for mid-word punctuation, and so no break is returned.
This is indeed intentional (and took some time to get right). If the cursor is in, or directly adjacent to, a word, so that you can link a word quickly as a keyboard user without having to use a mouse or do keyboard-based shift-selection.

However, this is meant to not trigger when you're not in the "context" of a word, so it does some fancy language-dependent Unicode whitespace detection; it should be doing this for punctuation but apparently isn't, so referring to Ed to investigate.
When editing http://de.wikipedia.org/wiki/Wikidata the top of the Wikimedia logo in the template at the bottom of the page is cut off. (It might also be hidden behind the grey bar or something.)

--------------------------
**Version**: unspecified
**Severity**: normal
This happens in any article that uses the following template with an image, which is lots and lots and lots
https://de.wikipedia.org/wiki/Vorlage:Navigationsleiste

https://de.wikipedia.org/wiki/Bezirk_Altona?veaction=edit

And the German template appears on many other languages as well.
https://bar.wikipedia.org/wiki/Wikibooks?veaction=edit
We aim to render templates as similarly as possible, but there are some exceptions at this time. One such exception is that protected elements and their child elements positioned as 'absolute' or 'fixed' will be changed to relative. Protected elements are usually non-text or generated elements like images or templates.

Specifically in this case the CSS rule for elements that match '.ve-ce-alienNode, .ve-ce-alienNode *' is being used to set all elements relative. In a more recent version of the code this rule is now renamed to '.ve-ce-protectedNode, .ve-ce-protectedNode *' but it's effect is the same.

We should probably be only applying relative positioning to elements that are actually positioned 'absolute' or 'fixed', because it's currently being applied to an element that's positioned 'static'.
Created attachment 12328
screenshot of the issue in chromium in kubuntu

**Attached**: {F10816}
I cannot reproduce this using either Firefox or Chrome - which browser(s) does this appear in? Do you have a screenshot I could see? Does it still appear?
It should be possible to edit a part of a MediaWiki page such as a section or paragraph via VisualEditor without loading the entire article into the editor. This would be especially useful on mobile devices. This ticket is designated to serve as the parent task for all work related to such a goal.

The parsing-related work can be seen at [[https://phabricator.wikimedia.org/project/view/3331/|Parsoid: Section-Editing-Support board]].
>>! In T50429#979728, @Jdforrester-WMF wrote:
> It's entirely do-able for the developers of SemanticMediaWiki to create a VisualEditor integration for each of the fields in a form. Indeed, it's one of the use-cases we built VisualEditor around.

I have been poking around the VE and (recently) Semantic Forms looking for a place where I can dig in.  This may be it.  I can't promise anything, but knowing this is a place that needs work and that some of my users could use it helps.

Knowing other people want it doesn't hurt, either.
It's entirely do-able for the developers of SemanticMediaWiki to create a VisualEditor integration for each of the fields in a form. Indeed, it's one of the use-cases we built VisualEditor around. However, it'd be a bunch of work and it's nothing we're planning to do at the Wikimedia Foundation (we don't support Semantic MediaWiki either). So effectively this is a "no" for your question.

This task is talking about using VisualEditor to edit parts of a single-content-block page, not a page made up via collections of different pieces of information.
I've been using Semantic Forms for more than 4 years now. It used to support the FCKEditor extension (and branch SMW+ supported the WYSIWYG extension).
But the decision to stop using FCKEditor going forward was at least related to the promise of a cleaner integration with VisualEditor (Yaron Koren would be able to
comment more accurately on that).  I believe that was decided around 2012.

I'm now with a new company, and I've been tasked with evaluating Atlassian Confluence.  It supports bare pages, but also form-based pages.  The only significant feature it has over
Semantic Mediawiki / Forms installation is WYSIWYG editing.  I can't stick with MW 1.16 / FCKEditor as I did at my previous company, so it looks like we'll to go with 
Confluence... which is a shame to me, since I know how versatile the mediawiki environment is.

It doesn't seem like the work-arounds being considered would support being about do do WYSIWYG editing in a text field or the free text area of a Semantic Form.  
//If that's the case//, it would be nice if this could be marked WONTFIX, and a new issue created that discusses compensating for the lack of an edit section as we
know it in Mediawiki.

Or, it's 2015, the solution is about to be released any day now, and I'll shut up (I can do that last one anyway).
I've been using Semantic Forms for more than 4 years now. It used to support the FCKEditor extension (and branch SMW+ supported the WYSIWYG extension).
But the decision to stop using FCKEditor going forward was at least related to the promise of a cleaner integration with VisualEditor (Yaron Koren would be able to
comment more accurately on that).  I believe that was decided around 2012.

I'm now with a new company, and I've been tasked with evaluating Atlassian Confluence.  It supports bare pages, but also form-based pages.  The only significant feature it has over
Semantic Mediawiki / Forms installation is WYSIWYG editing.  I can't stick with MW 1.16 / FCKEditor as I did at my previous company, so it looks like we'll to go with 
Confluence... which is a shame to me, since I know how versatile the mediawiki environment is.

It doesn't seem like the work-arounds being considered would support being about do do WYSIWYG editing in a text field or the free text area of a Semantic Form.  
''If that's the case'', it would be nice if this could be marked WONTFIX, and a new issue created that discusses compensating for the lack of an edit section as we
know it in Mediawiki.

Or, it's 2015, the solution is about to be released any day now, and I'll shut up (I can do that last one anyway).
(In reply to Tim Starling from comment #49)
> > * Editing by section blocks users from editing other areas at the same time
> > that the notice flaws in after they've entered editing, for very limited
> > added-value.
> 
> For large articles, I think the added value would be very large indeed.
> People don't want to wait tens of seconds to make a small correction, and
> it's likely that VE performance causes many edits to be abandoned.
> 
> Perhaps there are other solutions for the performance issue, but it seems to
> me that this is a fairly obvious approach, especially for bandwidth
> reduction.

For what it's worth...

I did a non-scientific poll and asked the Hebrew Wikipedia community what are the people's reasons to avoid VE. Precisely this suggestion came up several times.
No, it definitely shouldn't be a preference – instead, it should be possible for everyone to "expand" the editing area from the one section to the entire article.
Another thought on the preference: currently clicking on a section edit gives a pre-filled edit summary including the section.  Whether this happens should depend on the same preference.  If I have "section-editing" set to yes, I would get the pre-filled edit summary and other sections hidden; if I have it set to no, I would get no pre-filled edit summary, and I would see the whole article, as happens now.  This would help avoid the (common) situation where the edit summary is misleading when a section edit is clicked.
Re comment 52: I agree that show/hide would be nice for the uneditable sections.

More importantly, if this behaviour is implemented, please make it a preference option.  I often use "edit beta" on one section in order to fix a problem I see in the section just above it; I'd hate to lose that capability.
Mike Christie has a suggestion:  Edit the whole page, but only display the chosen section.  

By this I don't think he means "discard" everything except the section, but instead just to cover up the other parts.  We're already scrolling to the chosen section, so this would add maybe a gray or white block over everything above that (or perhaps collapse it), and ideally everything below it, too.  

This would help people who are using section editing to keep them focused on their chosen tasks, rather than because of beliefs about performance or edit conflicts.
Comment 46 ignored comment 44, hence making the priority value reflect reality again. If there are further good arguments to give this higher priority, feel free to convince the *developers* to set a higher priority again.
james, we tried your sections within a table example from above here:
https://en.wikipedia.org/wiki/Wikipedia_talk:VisualEditor/Known_problems#section_in_a_table
and we could not create something useful.
note blocks section edit

**Attached**: {F10744}
upgrading this to "highest" as this is the main reason for item 1 (slow loading), item 2 (slow scrolling) and item 6 (no section editing) of https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Known_problems. personally i think this should be _the only_ "immediate". why?

i tried it at https://en.wikipedia.org/wiki/Jos%C3%A9_Mourinho.
* 1 click and 15 secs to edit
* 1 click to make go a away a note (see attachment)
* 1 click to edit summary
* 1 click and 20 secs to review changes
* 1 click to return to save form
* 1 click and 40 secs to save
* 5* pg down to go to the section just edited

section edit with the text editor takes:
* 1 click and 2 secs to open
* 1 click and 2 secs to preview
* 1 pg-down to find the save button
* 1 click and 10 secs to save
This:
"but I cannot justify spending donor funds to that extent"
just turned into:
"we're hoping to be able to undertake it some time towards the start/middle of next calendar year"

Which sure sounds like a priority change, so I'm not sure if my flag change was psychic-magic or precipitative-magic, but either way, it now seems like the correct priority status.  I've tried communicating other ways:
https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback/Archive_2013_07#Section_editing_will_never_be_implemented
("Any update from the dev discussion?") but got no answer, and the known problems page still says "not planned".

Anyway, it's good to hear that you are now planning to do this.  I'm sure it will be worth it for low-bandwidth editors.
(In reply to comment #43)
> I'm upgrading this to "normal" since it's listed at #4 on
> https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Known_problems and I'm
> not
> seeing any good case for low/lowest made here.

The "priority" field doesn't mean "how much do people want it", it's "how soon are the developers likely to get to do it".

As I explained above, this will require a series of major changes in Parsoid and a huge re-write of MediaWiki's skins system as we switch over to use Parsoid's generated HTML for read pages, and is many (many) months away - we're hoping to be able to undertake it some time towards the start/middle of next calendar year.

Magically changing the status of the priority doesn't make this complex work happen any quicker. There is no value in edit-warring over Bugzilla statuses, so I'm going to leave this as is, but please don't make changes like this.
I'm upgrading this to "normal" since it's listed at #4 on https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Known_problems and I'm not seeing any good case for low/lowest made here.
**joedecker** wrote:

This is quite serious for slow connections.
Ah, the disappearing double-links are Bug 50731.
Ah, I see the "edit|edit source" links on sections have turned back into just "edit" links, which edit the wikitext. Thank you :-)
I appreciate the VE is a hard problem  - but now you have an interface that *lies* to the user. It claims visual section editing is possible, but the PM for the VE has stated this functionality will not be funded.

So, is the interface lying to the user this bug, or should it be a separate bug?

If lying to the user is considered a feature, what is it for?
Oh, and sorry to be pedantic, but in the original context, "marginal utility" was not referring to a specific semi-solution as far as I can see:

>> I don't seem to be able to section edit with VisualEditor.
> To edit a section, we would need to get its HTML from Parsoid - but a section
isn't guaranteed to be balanced HTML ...
> Coming up with a solution to this is would be a significant piece of
engineering effort for marginal utility.

Thank you for confirming now that you *do* see utility in stopping the waste of bandwidth and slowing of load time.  Even if you think it is too difficult.
> the core developers of this are not intending to work on this issue any time soon
That's exactly what befuddles me, and seems like a poor judgement.  If it's anywhere near as big a task as you envisage, then I can't expect a volunteer to take it up.  So I conclude that realistically it will never be done.

> having the entire document available, but just not editable
Ok, I agree that would be useless, possibly of negative value. You're right that this is not what I'm asking for.

>Parsoid that loaded and edited only one section at a time would be a mammoth piece of work
Obviously I'm not a mediawiki programmer, so I speak from ignorance here.  But I don't understand why Parsoid can't just be given a shorter piece of wikitext to parse, along with the section number it is starting at.  Since the old editor is quite capable of serving up a correct section of the wikicode to the user, I don't see why the same wikicode can't be given to Parsoid.  Please can you get a third and fourth opinion on the feasibility of this.  Someone in your team may be able to think of a way around the problems you envisage.

> I've edited Wikipedia (and other wikis) since 2001, including over heroically-terrible connexions
So have you now also tried VisualEditor on those heroically-terrible connections?  I'm willing to bet that you will feel the weight of this problem.

>I cannot justify spending donor funds
The whole goal of VisualEditor is to improve accessibility and the editing experience for lower-tech editors right?  Well, the sad truth is that low-tech and globally underrepresented editor communities are strongly correlated with low bandwidth access.  Section editing in a long article gives an order of magnitude speed gain to those editors.  If you cannot do this for the target audience, I fear that VisualEditor will not serve those who need it the most.

I really hope you will discuss this with more people before confining it to the dustbin.
> Solving what you're actually asking for (a form of VisualEditor/Parsoid that
> loaded and edited only one section at a time) would be a mammoth piece of
> work,
> albeit with some usefuless as you describe.
> 
> > James, please try regular editing on a slow connection if you haven't done
> > this before, I'm pretty sure you'll end up editing the section source.
> 
> I've edited Wikipedia (and other wikis) since 2001, including over
> heroically-terrible connexions through the years; I am very aware of the
> impact
> that our current site has on low-bandwidth users, even without VisualEditor,
> but I cannot justify spending donor funds to that extent when there are more
> pressing demands on the resources of the VisualEditor team.

My first thought is what were people thinking when they thought that using a visual editor to edit a whole page at a time would not slow things down a lot for many users? I am not a developer though, and hindsight is 20/20. 

Whatever it costs to make a visual editor that edits a section at at time would be worth it. The WMF spends money on far less important things. I have been saying this for years. 

I think millions of dollars more a year should be spent on developer salaries just for the visual editor, and the coordination of vast armies of volunteer developers to work on the visual editor. Another spending priority would be developer money for cross-wiki watchlists.
I can't believe that section editing is marked as a "lowest priority" "enhancement"!  This is incredibly important to me.  The way it's currently set up wastes bandwidth and slows load time relative to the old editor.  Both of these are important when making a quick-fix edit.  Hardly "marginal utility".  James, please try regular editing on a slow connection if you haven't done this before, I'm pretty sure you'll end up editing the section source.  I'm quite supportive of visual editor in general, but if this is not going to be fixed, I may have to turn back.
%%%*** Bug 50592 has been marked as a duplicate of this bug. ***%%%
Just a note (for users not following the other bugs) that we have just merged a change along the lines of bug 49666 - there will be both an "edit" and an "edit source" link on every section, with the edit link taking the user into VisualEditor, scrolled down to that section.

This enhancement request (to have VE appear just for a section within a wider page) is not impossible, and we're keen to explore what impact it has, but very hard, and blocked on Parsoid's HTML being used as the basis for MW's read pages, so may take some time.
Related URL: https://gerrit.wikimedia.org/r/69984 (Gerrit Change I4b9c47fd65a700a81c880144247fec524edff7e5)
(In reply to comment #18)
> I commented at
> http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/
> Feedback#Now_unable_to_edit_sections_by_old_method
> that it would be ideal to have section-edit links for [edit] and [edit
> source].
> 
>  ie.
> Sandbox [edit]
>  replaced with:
> Sandbox [edit] [edit source]
> 
> I believe this would prevent a LOT of complaints in the short term, and it
> would permit a lot of us to continue being active beta testers
> (section-editing
> is my most frequent type of edit), that it should be High priority, if at all
> possible. Thanks.

I have created this as bug 49666.
(In reply to comment #25)
> It would be wonderful if the "edit source" links or icons for sections also
> showed up inside the Visual Editor. The Visual Editor could treat "edit
> source" links or icons as uneditable links. But the link would still work. So
> people could click "edit source" links or icons to open source editing of a
> section.

I have created this as bug 49665.
(In reply to comment #20)
> I read the discussion, and it seems nobody mentioned what i think is the
> "real"
> bug here: we have the "edit source" link, that drops you back to wikitext
> editor. The correct behavior for ve should obviously be to drop you to a
> section edit if the hser entered edit state through an edit section link. 
> 
> Peace.

I have created this as bug 49664.
Bartosz (comment 26). If I am reading bug 43133 right it sounds way too complicated. What I am suggesting is a simple "edit source" link to source mode editing of a section. Nothing fancy like floating windows, etc. tied in any way to the Visual Editor. 

One clicks out of the Visual Editor altogether. This means that edits to the source wikitext in a section are treated the same no matter how one got to that wikitext edit window. This avoids integration conflicts, additional edit conflicts, or anything complicated. 

Same for clicking on stuff Visual Editor can't edit. One is sent to source mode for the section where that stuff is found. Nothing more. 

For transcluded templates one still has to go to the bottom of the source-mode edit window for the whole page. That is where the list of transcluded templates is found. It would be nice if one could see such a list at the bottom of source-mode edit windows for sections too.
Timeshifter, this sounds very much like what is described at bug 43133.
I like kipod's ideas (comment 22). I think to more fully support section editing means to make it easy to choose either editor at any time. 

Let me explain. If the Bartosz patch is implemented (comment 24), or some variation of it, there will be "edit" and "edit source" links or icons on every section. 

It would be wonderful if the "edit source" links or icons for sections also showed up inside the Visual Editor. The Visual Editor could treat "edit source" links or icons as uneditable links. But the link would still work. So people could click "edit source" links or icons to open source editing of a section. 

People could go to source mode editing at anytime, even from inside the Visual Editor. That would be so convenient and so useful. 

Later on, this functionality could be extended to anything the Visual Editor can't edit. People could click on templates, tables, etc. inside the Visual Editor and go directly to source mode editing of that section. Or they could right-click templates, tables, etc. to go to a new tab in source mode for that section.
I submitted the patch above to show two links side-by-side, in the form of "[edit] [edit source]", similarly to how the article tabs are done.
Related URL: https://gerrit.wikimedia.org/r/68868 (Gerrit Change I13bbb9549c999bb7301bbcf530706a813184425d)
(In reply to comment #21)
> (In reply to comment #20)
> > I read the discussion, and it seems nobody mentioned what i think is the
> > "real"
> > bug here: we have the "edit source" link, that drops you back to wikitext
> > editor. The correct behavior for ve should obviously be to drop you to a
> > section edit if the hser entered edit state through an edit section link. 
> > 
> 
> It does do so (in its own way). If you click a section-edit link, it
> currently
> enters VE edit-mode, and scrolls down to the section you clicked on, and
> places
> the cursor at the beginning of the section-header.


no it doesn't. what i meant is that if you click on the "edit" section link, and then see something that requires wikitext editing and click "edit source", you are dropped into "old" editor _for the whole page_. this means that there is no way to execute the old "section edit" in the wikitext editor. removing this existing functionality is a regression, and fixing it should be easy.

"fixing it" meas that if you open the editor through a "section edit" link and then press "edit source", you will be in the exact same state as someone who has VE disabled and pressed the edit section link.

failing to fix this causes editors to disable VE (i know for a fact that i am not the only one who disabled VE because of this very reason).

peace.
(In reply to comment #20)
> I read the discussion, and it seems nobody mentioned what i think is the
> "real"
> bug here: we have the "edit source" link, that drops you back to wikitext
> editor. The correct behavior for ve should obviously be to drop you to a
> section edit if the hser entered edit state through an edit section link. 
> 

It does do so (in its own way). If you click a section-edit link, it currently enters VE edit-mode, and scrolls down to the section you clicked on, and places the cursor at the beginning of the section-header.
I read the discussion, and it seems nobody mentioned what i think is the "real" bug here: we have the "edit source" link, that drops you back to wikitext editor. The correct behavior for ve should obviously be to drop you to a section edit if the hser entered edit state through an edit section link. 

Peace.
(In reply to comment #17)
> (In reply to comment #16)
> > Matthew. You are incorrect. There has been a recent change. 
> 
> You're right that the section editing default has changed for people who
> opted
> in to VE.
> 
> However, if you've never changed any editing preferences (most registered
> users), you are still using the old editor by default.  That will change,
> assuming the random test works well and VE continues to improve.

I think Timeshifter means the "which will soon be all users" part, and I agree that it would be very unfortunate. Quiddity's solution seems like the best one, and IMO should be implemented before the A/B test on en.wp.
I commented at http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Now_unable_to_edit_sections_by_old_method
that it would be ideal to have section-edit links for [edit] and [edit source].

 ie.
Sandbox [edit]
 replaced with:
Sandbox [edit] [edit source]

I believe this would prevent a LOT of complaints in the short term, and it would permit a lot of us to continue being active beta testers (section-editing is my most frequent type of edit), that it should be High priority, if at all possible. Thanks.
(In reply to comment #16)
> Matthew. You are incorrect. There has been a recent change. 

You're right that the section editing default has changed for people who opted in to VE.

However, if you've never changed any editing preferences (most registered users), you are still using the old editor by default.  That will change, assuming the random test works well and VE continues to improve.
Matthew. You are incorrect. There has been a recent change. 
Please read comment 13 by James Forrester above. Here is the relevant part: 

"as of today, we have switched over to the 'beta' behaviour for VisualEditor in a number of regards, including section edit links - i.e., default behaviour for users with VisualEditor (which will soon be all users) is that section edit links will take you into VisualEditor, scrolled to that section, with the cursor at the start of it."
(In reply to comment #14)
> Many registered editors don't edit enough to know much about preferences. 
> ...

Editors who haven't changed their preferences are still using the wikitext editor.

> Worst of all, what was once an interesting option has now become an imposed
> encumbrance. There is no way to edit in source mode now without effort.
> Registered editors are forced to use VE. They can only opt-out of VE section
> editing. They must go here: 
> [[Special:Preferences#mw-prefsection-editing]]
> 
> Please return section editing of source wikitext as the default. Make this VE
> section editing gimmick the option in preferences. Make it opt-in, not
> opt-out. 

It is opt-in.  So far, the defaults have not changed in any way.  You can sign up for a temporary test account and see for yourself.

If you don't change any preferences, editing remains wikitext only.  And you can change back (and forth) at any time.  That means the defaults are not being imposed on anyone.

I understand your point.  VisualEditor is a work in progress.  However, it's a work in progress that's currently 100% opt-in, and James has already said he will consider two section edit links.
Many registered editors don't edit enough to know much about preferences. This is a bad idea. There are already many complaints here: 
[[Wikipedia:VisualEditor/Feedback]]

This could cause many editors, who already do not edit much, to edit less because their edits get reverted soon after using Visual Editor. VE messes up many things. I have seen it myself, and so I do not use VE. I have to check a WHOLE-PAGE preview diff for errors it inserts before I save some other minor thing I edited. Minor typos and other things that used to take me a few seconds to fix now take a long time with the Visual Editor. 

Visual Editor needs to edit SECTIONS, too. Not the whole page. So this fix is not a fix. Visual Editor still does not support section editing. It still only edits the whole page. 

Worst of all, what was once an interesting option has now become an imposed encumbrance. There is no way to edit in source mode now without effort. Registered editors are forced to use VE. They can only opt-out of VE section editing. They must go here: 
[[Special:Preferences#mw-prefsection-editing]]

Please return section editing of source wikitext as the default. Make this VE section editing gimmick the option in preferences. Make it opt-in, not opt-out. 

The WMF does not have anywhere near a consensus or approval or any other type of community process sanction that justifies imposing beta VE. Especially when it is as buggy and beta as it is now. VE was actually an interesting option until this latest forced imposition of beta VE.
(In reply to comment #12)
> OK. Now that I finally get it, and see that everyone (logged in or not)
> currently gets source editing of sections, let us not remove section editing
> of source wikitext when VisualEditor is fully implemented! That would make many
> editors very unhappy.

Just to update on this point: as of today, we have switched over to the 'beta' behaviour for VisualEditor in a number of regards, including section edit links - i.e., default behaviour for users with VisualEditor (which will soon be all users) is that section edit links will take you into VisualEditor, scrolled to that section, with the cursor at the start of it.

For the mean time (until VisualEditor is out of beta, when it will be much less likely that users will want to use wikitext editor often), there's a user preference (defaulted to off) that will redirect these section edit links back to the wikitext editor; this is in Special:Preferences > Editing > Beta features.

I'm open to seeing if there's a way of giving people two section edit links without being confusing in the medium/long term, but that's a discussion for later. :-)
OK. Now that I finally get it, and see that everyone (logged in or not) currently gets source editing of sections, let us not remove section editing of source wikitext when VisualEditor is fully implemented! That would make many editors  very unhappy. 

I sometimes like to open up a section in a new tab for editing. So I can switch between tabs to alternate between how the section currently looks, and how my preview looks. This also helps me in finding stuff in the wikitext. I can use browser find in both tabs to help me find where I need to edit. 

This can be very necessary when editing references, tables, navigation boxes, image captions, and other such wikitext. Images that are right-floating, for example, can be difficult to find in the wikitext otherwise.
(In reply to comment #10)
> OK. I see that section editing is currently enabled for anonymous users too
> on Wikipedia. I am almost always logged in, and so I must have been confused by
> the preference "Enable section editing via [edit] links".

That is in fact the preference, but it's checked by default (as well as always on for anons).
OK. I see that section editing is currently enabled for anonymous users too on Wikipedia. I am almost always logged in, and so I must have been confused by the preference "Enable section editing via [edit] links". I see now that it is about the URLs. See 
[[Help:Section#Section_editing]].

I would hate to lose section editing of source wikitext if VisualEditor is enabled for section editing. That would be a serious step backwards for the reasons I and others have discussed.
(In reply to comment #8)A section
> preview is much faster. I have been editing Wikipedia since 2005, and at one
> point I had forgotten that section editing is not a given for all editors. We
> are wasting a lot of editors time by not enabling it by default.

Wikitext section editing is enabled by default.
(In reply to comment #6)
> One of the things I'm pondering is if we should relabel the edit section
> links to have two links, one to VE and the other to wikitext. Possibly "[_edit_
> _*_]" or somesuch.

I think that might be too much clutter when VE rolls out to everyone.  But while it's opt-in, it will definitely encourage me to test it, since I use the edit section link a lot.
(In reply to comment #5)
> Err, whoops. Sorry, yeah, completely missed that paragraph.

:-)

> If the default editor behavior is a switch that controls parts of the
> interface like this (I didn't realize that), is this testable now anywhere?
> A Labs wiki or something?

No; we should do that.

One of the things I'm pondering is if we should relabel the edit section links to have two links, one to VE and the other to wikitext. Possibly "[_edit_ _*_]" or somesuch.
(In reply to comment #4)
> I mentioned it too, you know :-) - see:
> 
> (In reply to comment #2)
> | The behaviour in VisualEditor when running as the default editor is for the
> | edit section links to take you into VE for the entire page, with the view
> | moved down to the anchor of that section (note, this is not how it appears
> | right now on the various Wikipedias, but will be once they have the 'beta'
> | enabled).

Err, whoops. Sorry, yeah, completely missed that paragraph.

If the default editor behavior is a switch that controls parts of the interface like this (I didn't realize that), is this testable now anywhere? A Labs wiki or something?
(In reply to comment #3)
> Krinkle briefly mentioned an idea where section edit links might load the
> full VisualEditor form and then jump down to the specific section. This might
> be an approach to consider.

I mentioned it too, you know :-) - see:

(In reply to comment #2)
| The behaviour in VisualEditor when running as the default editor is for the
| edit section links to take you into VE for the entire page, with the view
| moved down to the anchor of that section (note, this is not how it appears
| right now on the various Wikipedias, but will be once they have the 'beta'
| enabled).
There must be a recognition that editing large articles is burdensome and that section editing has (had) _enormous_ value.

Even with JavaScript disabled, the parser continues to take a significant amount of time to parse a large article. And while modern browsers on modern hardware don't have as many issues, rendering large articles can also be taxing.

VisualEditor adds to this burden by piling on a lot of JavaScript. The idea that wanting to edit only a section of [[GE]] or [[Iraq War]] stems from wanting to skip past confusing wikitext or avoid edit conflicts misses the point, I think. Though I realize that VisualEditor uproots many principles of the current editing workflow/paradigm.

Krinkle briefly mentioned an idea where section edit links might load the full VisualEditor form and then jump down to the specific section. This might be an approach to consider.
(In reply to comment #0)
> I don't seem to be able to section edit with VisualEditor.

There are three issues here:
* To edit a section, we would need to get its HTML from Parsoid - but a section isn't guaranteed to be balanced HTML, for example (commonly-used):

{|
! Foo !! Bar
|-
=== Section 1 ===
|-
| Foo || bar
=== Section 2 ===
|-
| Foo || bar
|}

Coming up with a solution to this is would be a significant piece of engineering effort for marginal utility.

* The reasons we brought in section-editing originally were two-fold - to skip past confusing wikitext in other areas to find the item you actually wanted to edit (not an issue in the context of VisualEditor), and to avoid edit conflicts using the page-based diffs at the time (not an issue for ~ 7 years since Tim re-wrote the diff tool).

* Editing by section blocks users from editing other areas at the same time that the notice flaws in after they've entered editing, for very limited added-value.


The behaviour in VisualEditor when running as the default editor is for the edit section links to take you into VE for the entire page, with the view moved down to the anchor of that section (note, this is not how it appears right now on the various Wikipedias, but will be once they have the 'beta' enabled).

I'm not convinced that this is a WONTFIX, but I'm similarly not convinced that we should spend our time fixing this rather than, say, making VisualEditor and Parsoid work on Wikisource, or other things we could be doing with our limited resources.
Thoughts:

It strikes me that this might not be overly difficult - if VE is just using H<n> elements to represent sections anyway, then it should be relatively simple to change the edit URL to "javascript:", and add some JavaScript events to them that call the VE setup and, once it's done, brings the specified section to the top of the user's screen.

I won't mark this as easy, because I don't think it is. I wish we had an "intermediate" keyword.
How to reproduce:

1. Enable the "Mark all edits minor by default" option in the preferences.
2. Edit a page in the VisualEditor.
3. Press "Review and save", then "Looks good to me".
4. The edit summary entering bubble appears.

Observed:

* The "This is a minor edit" box is not checked.

Expected:

* The "This is a minor edit" box is checked.

Comment: The saved revision IS correctly marked as minor. It's just the check box that appears incorrectly.

GWT scenario for Cucumber:
Given that I am editing an article while the minordefault preference is on
When I am saving the article
Then the "This is a minor edit" box is checked

--------------------------
**Version**: unspecified
**Severity**: normal
Merged into master; will go out with wmf5.
Related URL: https://gerrit.wikimedia.org/r/63844 (Gerrit Change Ib5cdcb9433be5ff7b9179d3833f42e5c3453285a)
(In reply to comment #1)
> You know, if minoredit preference was killed, this wouldn't be an issue...

I couldn't agree more :)
You know, if minoredit preference was killed, this wouldn't be an issue...
Core now has jsduck documentation on https://doc.wikimedia.org/mediawiki-core/master/js/ .  It would be useful to provide a standardized mechanism for extensions to have their jsduck documentation automatically added under doc.wikimedia.org as well.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=48244
Marking this fixed.  The general functionality is there.  For GuidedTour specifically, https://gerrit.wikimedia.org/r/#/c/118428/ and https://gerrit.wikimedia.org/r/#/c/118426/ are in progress.
It looks like VisualEditor and MultimediaViewer are both doing so now.  i don't know if they're one-offs or there's a general process.

However, I would like to do the same for GuidedTour.  Currently, we have it at http://growthdoc.wmflabs.org/GuidedTour/ .
Wikitext edit has page title "Editing Foobar", as opposed to reading-mode's "Foobar". For people with a number of tabs open, it'd be great for them to get a handle on where they are by updating the window title to prepend "Editing " to it (and remove it on save).

--------------------------
**Version**: unspecified
**Severity**: enhancement
Yes, re-using 'editing' & 'creating' messages.

(In reply to comment #2)
> (In reply to comment #1)
> > And 'Creating'.
> 
> Ah, yes. Presumably they're existing MW messages to steal, avoiding
> duplication
> of i18n efforts?.
Merged; will go out with wmf5.
Related URL: https://gerrit.wikimedia.org/r/64325 (Gerrit Change I9dcc8ec2c37a7ff9cff6cedb7bdb1fed1bdc4deb)
(In reply to comment #1)
> And 'Creating'.

Ah, yes. Presumably they're existing MW messages to steal, avoiding duplication of i18n efforts?.
And 'Creating'.
It would be helpful to have a built-in method in Scribunto/Lua that allows retrieving a list of the categories used on a page.

For example, <https://en.wikipedia.org/wiki/Einar_Schleef> would return a list that includes:

* German dramatists and playwrights
* 1944 births
* 2001 deaths

As these categories are included on this page.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**: {T20596}
%%%*** Bug 59111 has been marked as a duplicate of this bug. ***%%%
I'd just like to make the explicit suggestion that the categories be exposed be on title objects (see http://www.mediawiki.org/wiki/Extension:Scribunto/Lua_reference_manual#Title_objects ) as they contain other information about a given page.
many + signs

Tested: 

In OpenOffice, create a small table with text in cells a1, a2, b1, b2, c2. 

Copy only the rows of the table. 

Paste into VE. 

* the view immediately in VE is of unusable information and some "+" characters apparently indicating cell boundaries. 

Version:1.0StartHTML:0000000155EndHTML:0000000881StartFragment:0000000475EndFragment:0000000864➞➞➞➞➞➞➞➞➞➞➞➞➞a1➞➞➞b1➞➞➞➞➞➞➞➞➞➞a2➞➞➞b2➞➞➞c2➞➞➞

* the view in the "Review your changes" panel is of a swath of white space with the contents of the table interspersed.

* User tendency is to copy entire contents of rows, yielding many empty cells.  VE dutifully tracks these empty cells and displays an enormous number of "+" symbols in the immediate view and mostly empty space in the "Review your changes" view.

* Upon save, no table is in the page when pasting from OpenOffice.

Other anomalous results are reported when pasting from the Apple Pages application.  From another user: 

"...number of cells didn't match the number of columns. Since they don't match, tried to delete the cells in order to recover the blank page, but they won't delete."

--------------------------
**Version**: unspecified
**Severity**: normal

**Attached**: {F11079}
Change 86664 merged by jenkins-bot:
Rich paste

https://gerrit.wikimedia.org/r/86664
Change 86664 had a related patch set uploaded by Esanders:
Rich paste

https://gerrit.wikimedia.org/r/86664
(In reply to comment #2)
> I think users will expect that pasting things like tables from other editors
> and sources into VE to more or less Just Work.

That is bug 41193 (and yes, getting that to work would be lovely). This is about corruption of the clipboard from OpenOffice, which is a distinct problem whether or not we get the pasted-formatting working in time for the 'beta'.
I think users will expect that pasting things like tables from other editors and sources into VE to more or less Just Work.
* Editing of table structure isn't exactly supported right now

* I'm curious what OpenOffice puts on the clipboard. It may well be that the root cause is "OpenOffice puts unreasonable things on the clipboard when copying a table"
**Author:** `mstankus`

**Description:**
In TeXShop, you can click on a piece of content (for example,
a word) and choose sync and you are sent directly to the 
part of the source corresponding to that word. It would be great
if that could happen for wikis.

--------------------------
**Version**: 1.22.0
**Severity**: enhancement
(In reply to comment #2)
> Write now, you decide what is wrong, click on edit and then
> search through markup for the word was misspelled or phrase
> which needs to be checked. 

This will mostly get fixed by VisualEditor which you can already try out:
http://blog.wikimedia.org/2013/04/25/visualeditor-alpha-in-15-languages/

Closing as WORKSFORME.
**mstankus** wrote:

Write now, you decide what is wrong, click on edit and then
search through markup for the word was misspelled or phrase
which needs to be checked. 

  An alternate approach would be to allow someone to mark 
a word with a mouse, right click, choose "edit wiki page"
and then have the computer open the editor AND move
the cursor to the part of the markup relevant to that 
word in the text. It looks through the mark up for you
and saves everyone time.
I don't know what TeXShop is, so "like in TeXShop" is not helpful.
Still I don't understand what is requested here. I click a word in the content of a wiki page (preferably in "Edit" mode), and I am send to which source, and why?
Could you come up with a specific example and exact steps to reproduce, plus the current outcome and the expected outcome? Thanks.
Change 389542 **merged** by jenkins-bot:
[mediawiki/extensions/MultimediaViewer@master] Remove special color treatment of close icon on confirmation

[[https://gerrit.wikimedia.org/r/389542]]
OH from @RHo: “We can finally close the close icon”
Change 376851 **merged** by jenkins-bot:
[mediawiki/extensions/CentralNotice@master] Use consistent close icon

[[https://gerrit.wikimedia.org/r/376851]]
Change 394076 had a related patch set uploaded (by Esanders; owner: Esanders):
[mediawiki/core@master] mw.postEdit: Use mw.notify to display message

[[https://gerrit.wikimedia.org/r/394076]]
Change 389542 had a related patch set uploaded (by VolkerE; owner: VolkerE):
[mediawiki/extensions/MultimediaViewer@master] Remove special color treatment of close icon on confirmation

[[https://gerrit.wikimedia.org/r/389542]]
Change 385250 merged by jenkins-bot:
[mediawiki/extensions/Popups@master] Use standard close icon

[[https://gerrit.wikimedia.org/r/385250]]
Change 385250 had a related patch set uploaded (by VolkerE; owner: VolkerE):
[mediawiki/extensions/Popups@master] Use standard close icon

[[https://gerrit.wikimedia.org/r/385250]]
Change 384094 merged by jenkins-bot:
[mediawiki/extensions/GettingStarted@master] Use standard close icon

[[https://gerrit.wikimedia.org/r/384094]]
Change 384191 merged by jenkins-bot:
[mediawiki/extensions/GuidedTour@master] Use standard close icon

[[https://gerrit.wikimedia.org/r/384191]]
Change 384191 had a related patch set uploaded (by VolkerE; owner: VolkerE):
[mediawiki/extensions/GuidedTour@master] Use standard close icon

[[https://gerrit.wikimedia.org/r/384191]]
Change 384094 had a related patch set uploaded (by VolkerE; owner: VolkerE):
[mediawiki/extensions/GettingStarted@master] Use standard close icon

[[https://gerrit.wikimedia.org/r/384094]]
Possible regression: {T178111}
Change 376873 merged by jenkins-bot:
[mediawiki/core@master] postEdit: Use standard close icon

[[https://gerrit.wikimedia.org/r/376873]]
Change 376869 merged by jenkins-bot:
[mediawiki/extensions/Translate@master] Use standard close icon

[[https://gerrit.wikimedia.org/r/376869]]
Change 376873 had a related patch set uploaded (by VolkerE; owner: VolkerE):
[mediawiki/core@master] postEdit: Use standard close icon

[[https://gerrit.wikimedia.org/r/376873]]
Change 376869 had a related patch set uploaded (by VolkerE; owner: VolkerE):
[mediawiki/extensions/Translate@master] Use standard close icon

[[https://gerrit.wikimedia.org/r/376869]]
Change 376851 had a related patch set uploaded (by VolkerE; owner: VolkerE):
[mediawiki/extensions/CentralNotice@master] Use consistent close icon

[[https://gerrit.wikimedia.org/r/376851]]
Change 376648 merged by jenkins-bot:
[mediawiki/extensions/UniversalLanguageSelector@master] Use consistent close icon

[[https://gerrit.wikimedia.org/r/376648]]
Change 376648 had a related patch set uploaded (by VolkerE; owner: VolkerE):
[mediawiki/extensions/UniversalLanguageSelector@master] Use consistent close icon

[[https://gerrit.wikimedia.org/r/376648]]
Just to give an update

https://www.mediawiki.org/wiki/Wikimedia_Foundation_Design/Agora_icon_set gives a list of places the old icon is used, probably based off of this report, but the page has not been updated for 2 years, so it is likely out of date. 

https://doc.wikimedia.org/oojs-ui/master/demos/#icons-apex-ltr gives what I believe to be the most recent icons (using apex). Based on the attached screenshot, that is indeed what Wikipedia uses in the edit feedback

{F4913849}

If someone could investigate other places and help to figure out to what extent this is still an issue, that'd be great
{F187901}

This icon is used for all of these instances mentioned above:

https://upload.wikimedia.org/wikipedia/commons/5/56/PEF-1-Cropped.png
https://upload.wikimedia.org/wikipedia/commons/3/37/CentralNotice_banner_2013-05-03.png
https://upload.wikimedia.org/wikipedia/commons/3/37/CentralNotice_banner_2013-05-03.png

---

{F187902}
{F187903}

This icon is used specifically to clear input fields. 

---

I hope this helps. Let me know if I'm not answering any other questions mentioned. I'll provide info around specs soon.
@Galorefitz: Sorry that nobody has replied yet. I've also brought up your question on the mailing list now: https://lists.wikimedia.org/pipermail/design/2015-June/002325.html
I am new here and was wondering if I could contribute to resolving this ticket.

I went through the conversation and had a few doubts:
1. Are we to switch from icons to glyphs, everywhere? Or just make the icons consistent, for now?
2. Already pointed out, but not answered,

>>! In T50067#526717, @Aklapper wrote:
> As Jared added the "easy" keyword to this ticket: What is the prefered approach and expected implementation for a potential new code contributor? 
> Which specific 'close' icon to use everywhere?
> What is the complete list of codebases which are affected?
James, there are still many many interfaces especially with smaller dialogs (language switching, fundraising banners, etc) which use icons for dismiss, this is true on mobile as well due to space constraints, I'd prefer to get consistency in these places then we can investigate in which interfaces we should expand beyond just an icon. But for places we're CURRENTLY using an icon, that icon should be consistent.
(In reply to Andre Klapper from comment #9)
> As Jared added the "easy" keyword to this ticket: What is the prefered
> approach and expected implementation for a potential new code contributor? 
> Which specific 'close' icon to use everywhere?
> What is the complete list of codebases which are affected?
> 
> This ticket got a bit messy so I got lost. Summarizing is highly welcome.

From what I understand, the current guidance is "never ever ever use an icon for workflow functionality", per user testing outcomes. This is why VE switched over to simple words instead ("Done"/"Cancel"/etc.)
As Jared added the "easy" keyword to this ticket: What is the prefered approach and expected implementation for a potential new code contributor? 
Which specific 'close' icon to use everywhere?
What is the complete list of codebases which are affected?

This ticket got a bit messy so I got lost. Summarizing is highly welcome.
8. Besides #2 (an 'X' in a circle), other fund-raising banners use the plain 7px 'x' image donate/Small-black-close.png for their close iocn, e.g. http://meta.wikimedia.org/w/index.php?title=Main_Page&banner=B13_0725_trn_Cntrl_nd_yyYY&force=1
(In reply to comment #4)
> 1. Located in core (probably /skins/common/images/)

In the past I've tried to use core image resources in CSS files together with @embed without success. I think that desperately needs fixing to go onward with the unification.

> 3. Available in a large size and a small size

I would consider having SVG version too a must.
7. Extension:GuidedTour uses a square [X] icon, no hover, for its .x_button style. <https://bits.wikimedia.org/static-1.22wmf3/extensions/GuidedTour/modules/externals/mediawiki.libs.guiders/mediawiki.libs.guiders.submodule/x_close_button.jpg>
I checked in a smaller version of the closewindow19x19.png image in change I0e170305.
There are also currently 2 close window images in core (besides jQuery UI):

1. https://bits.wikimedia.org/static-1.22wmf3/skins/common/images/closewindow.png

2. https://bits.wikimedia.org/static-1.22wmf3/skins/common/images/closewindow19x19.png

I don't think #1 is used anywhere any more (but would be worth checking).

I believe #2 is the same image as the one used in CentralNotice and similar to the Agora design.

If we want developers to standardize on one close icon it needs to have the following properties:

1. Located in core (probably /skins/common/images/)
2. Works for any background (light, dark, grey, etc.)
3. Available in a large size and a small size
4. Conforms to design guidelines

closewindow19x19.png is probably the best bet since it meets 3 of the 4 criteria. All we need to do is create a smaller version for use in small UI elements. Then we can start standardizing everything on that. We can override the jQuery UI close box in resources/jquery.ui/themes/default/.
Related URL: https://gerrit.wikimedia.org/r/62237 (Gerrit Change I0e1703057e45297d6728cb635c58183aa37103da)
4. The Universal Language Selector extension uses its own chunky X icon with no hover behavior. jquery.uls styles icon-close with background of https://bits.wikimedia.org/static-1.22wmf3/extensions/UniversalLanguageSelector/lib/jquery.uls/images/close.svg

5, 6. The Translate and VisualEditor extensions also have close.svg icons for CSS backgrounds, each slightly different.
1. is a design from late 2012.

2. matches https://www.mediawiki.org/wiki/Wikimedia_Foundation_Design/Agora_Icon_Set#General edits in 2012 which says "Dismiss - an 'X' in a circle."

3. came from jquery.ui work in 2010.
Component: UI

The speech bubble icon and "Leave feedback" link in Visual Editor look like they apply to the page being edited.  I was expecting a Talk: tool.

It would be more clear if the text were "Report bug in Visual Editor", but that's annoyingly verbose.  Which is sort of the intention here, I assume ;)  Normally, this link would get buried in a dropdown menu or something, IMO.

The problem is exacerbated if you are sort of blind and zoom in your browser a lot, because the VE feedback link becomes very prominent once the toolbar is wrapped.
Yep, from what I recall of the past and my understanding of the report, the issue looks solved.
The link is now neatly tucked inside a dropdown menu. There's no screenshot on this bug, so I can only guess that it wasn't like this before. This probably resolves the issue sufficiently.

{F23347}
Adding many blockers of bug 38638 to the list of "easy" bugs, to mark them as candidates for [[mw:Google Code-in]] tasks (gci2013). If you think this bug is not suitable, remove the keyword.
The feedback link isn't a VisualEditor item but part of MediaWiki core. Moving bug appropriately.
Screenshot of page in view mode

Show thumbnail in user preference size in edit mode.

1. Set user preference to 300 pixel: "Thumbnail size:" of https://de.wikipedia.org/wiki/Spezial:Einstellungen?uselang=en#mw-prefsection-rendering

2. Edit page with image included as standard thumb.

Thumbnail is shown in a smaller size instead of the user preference size.

--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://de.wikipedia.org/wiki/Benutzer:Raymond/thumb
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50379

**Attached**: {F10384}
We have now implemented displaying default images in local wiki default size, and explicitly *not* user-preference size.

This is because the editing surface should encourage users to make the right kind of edits for all users, not just themselves. If a page has an image at default and a second at 300px, and a user with a default of 400px resizes one of the images to fit in with the other, a user with a default of 200px (e.g. an anonymous user) will get a different experience and may try to revert (or the change will have a different effect to what was intended).

I'm therefore re-titling this bug to just refer to local wiki size, and marking as FIXED. Happy to discuss further.
Change 114420 merged by jenkins-bot:
Set up wiki-default image size

https://gerrit.wikimedia.org/r/114420
Change 114420 had a related patch set uploaded by Mooeypoo:
[wip] Set up wiki-default image size

https://gerrit.wikimedia.org/r/114420
French Wikipedians would like VE to follow the local convention that thumbnails are only displayed with the "upright" option (https://en.wikipedia.org/wiki/Wikipedia:Extended_image_syntax#Size).
User preference and wiki-default sizes specify the maximum width of an image, regardless of dimensions or aspect ratio, but VE scales the images to fit in a 190px by 212px box.

This means that some images, particularly tall thin ones such as full-length portraits, get rendered at very different sizes in VE edit mode to view mode, with consequential impact on the layout of surrounding content.
*** Bug 52487 has been marked as a duplicate of this bug. ***
Confirmed with Gabriel (Parsoid team) that this [should|is going to be] solved in VE.
Created attachment 12197
Screenshot in edit mode with smaller thumbnail

**Attached**: {F10385}
Review your changes

See screenshot.

--------------------------
**Version**: unspecified
**Severity**: minor

**Attached**: {F10352}
Meh. I guess I'll never use VE.
Exactly what is the problem? The fact that the VisualEditor dialog overlaps the Monobook sidebar, or that the searchbox/logo in the Monobook sidebar overlap the VisualEditor dialog?

The VisualEditor dialog overlapping is pretty much inevitable since it has a minimum width. If your screen is too narrow it has no where to go (short of a scrollbar, which I think give a worse user experience).

If it were always overlapping it would be a more pressing problem, but right now it only overlaps if you activate the review dialog, in which case your focus is more likely to be on the dialog than on the sidebar (e.g. if we need to choose, it is the obvious choice).
Given that these all exist in DM, it's "just" a question of making a set of icons for each function and adding it to the tool bar (and then working out what to do with a toolbar with eight such icons when we wanted two.

Have left off from the existing list in ve.dm.TextStyleAnnotation.js:

* span - as that'll need to be a distinct bug given the complexity (it'll need at least an inspector, possibly a dialog)
* strong/em - should we just silently use these instead of b/i (or vice versa)? Either way, it feels confusing to give the user both options.

--------------------------
**Version**: unspecified
**Severity**: enhancement
All now in #VisualEditor-EditingTools.
Related URL: https://gerrit.wikimedia.org/r/64801 (Gerrit Change I51f2605e7d8e2bab1d641f02244d5cd24f505676)
Icons for these are now merged into master; the outstanding work here is relatively light, except for the overall design issue about the toolbar having too many buttons.
Related URL: https://gerrit.wikimedia.org/r/64475 (Gerrit Change I2f317e1dda2c2e2fceac401768c732dae02e83ce)
Cannot reproduce in Firefox/Mac or Chrome/Mac; asking user to reconfirm.

--------------------------
**Version**: unspecified
**Severity**: minor
**Platform**: PC
I asked the user. he meant to a local script which isn't supported by VE.
As suggested by Timo - currently we have 'wmgUseVisualEditor' and 'wmgVisualEditorParsoidPrefix' which both need to be defined for each wiki we're putting VE on, which is a bit annoying (and prone to mistakes) - when we have all 295 Wikipedias with it switched on, it will be even worse. We should probably clean this up a bit.

--------------------------
**Version**: unspecified
**Severity**: enhancement
This is now done and live in production.
(In reply to comment #1)
> We could replace wgUseVisualEditor with a visualeditor.dblist file, and
> change the Parsoid prefixes to be equal to $wgDBname.

$wgUseVisualEditor (or wmgUseVisualEditor) seems fine to me, not sure if a dblist would make things easier.

Getting rid of having to configure wmgVisualEditorParsoidPrefix for each wiki would be great (or at least setting it dynamically/automatically from CommonSettings.php).
Related URL: https://gerrit.wikimedia.org/r/64493 (Gerrit Change I621e98da3be4f787e294d97b350b92d217f43a00)
(In reply to comment #1)
> We could replace wgUseVisualEditor with a visualeditor.dblist file, and
> change the Parsoid prefixes to be equal to $wgDBname.

That sounds like a start, but we're going to want to run some wikis in nothing (no preference to switch on - just not in the .dblist file?), some in alpha (opt-in, limited namespaces) and some in beta (default, all "content" even-numbered namespaces that won't break - e.g. MediaWiki:, Template:, Schema:, ? others). Would we want two .dblist files? And some magic juice to decide what namespaces were safe?
We could replace wgUseVisualEditor with a visualeditor.dblist file, and change the Parsoid prefixes to be equal to $wgDBname.
Please write your bugs report to http://parsoid.wmflabs.org/_bugs/ only with https to avoid a secure hole.

Please see this as a blocker for the coming roll out. Thanks.

--------------------------
**Version**: unspecified
**Severity**: normal
We're scrapping this feedback system, so marking as INVALID.
Comment from bug 47507 comment 1:

| No data goes over the wire that is personally-identifying, so I would
| disagree that this is a blocker; however, yes, this is good practice and we
| should try to do thi[s] (especially, to avoid unexpected mix-mode for users).
It seems <syntaxhighlight is working just fine, but it's old deprecated 'redirect' <source is not recognized by VE, as can be seen in the link.

--------------------------
**Version**: unspecified
**Severity**: minor
**URL**: https://en.wikipedia.org/wiki/User:TheDJ/Sandbox
[Parsoid component reorg by merging JS/General and General. See bug 50685 for more information. Filter bugmail on this comment. parsoidreorg20130704]
*** This bug has been marked as a duplicate of bug 47579 ***
This is probably something Parsoid needs to handle (or, rather, SyntaxHighlight with the Parsoid functionality to cope with 'redirects' between extension tags). Gabriel, does this sound right to you?

@Raimond - bug 43126 is about editing these blocks; this is just about displaying them correctly.
Dupe of bug 43126?
https://en.wikipedia.org/w/index.php?title=Phil_Thompson&action=edit&oldid=535300833

Note that in this mode, the VE tab is missing the oldid

--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://en.wikipedia.org/w/index.php?title=Phil_Thompson&action=edit&oldid=535300833
All of the tabs in this mode go to current, not oldid, so I think this is something that either should be fixed upstream in MW core (in which case, VE should just magically work), or be left as is, given that users will expect the current behaviour.
In this mode without the VE, the wikitext edit tab doesn't go to the oldid, it goes to the curid page; I think we're going to have to think about how to let users get the VE from here.

Timo, any thoughts?
Currently the "Edit source" button's label is the same whether the page is extant or not. This should change.

--------------------------
**Version**: unspecified
**Severity**: minor
Merged; will go out with wmf5.
Related URL: https://gerrit.wikimedia.org/r/64276 (Gerrit Change Iafba040cb8eb53017f38f2099a473e0e43e2ec46)
That is https://github.com/senchalabs/jsduck/wiki/Inline-examples

For instance:

resources/js/ext.translate.editor.js
9:       * Example usage:

resources/js/ext.translate.proofread.js
107:     * Example usage:

resources/js/ext.translate.pagemode.js
10:      * Example usage:
JSDuck's `@example` syntax is for a live demo of running code. For OOjs UI and VisualEditor this can be useful in places for classes and methods that are largely about their visual and interactive rendering (not about the shape return value itself). However I'm not sure that's useful in the case of the Translate extension.

To render code examples with syntax highlighting, just use three backticks (or indentation) to create a code section in JSDuck's markdown rendering. Closing this task as it doesn't seem actionable right now.

Right now Translate documentation isn't rendered/published anywhere, so in its current form the code examples are readable as-is. If they are published, one of the three examples will need to be indented for it to be preformatted correctly.
Example of how usage example is used:

https://doc.wikimedia.org/VisualEditor/master/#!/api/ve.init.sa.Target

(especially notice the live preview)

https://doc.wikimedia.org/mediawiki-core/master/js/#!/api/mw.html
- Edit an article on the English Wikipedia in the VE

- Click "Review and save"

- Click "Something is wrong"

- Enter text into the field and click "report problem"

Nothing happens - either the error report is not sent, or the fact that it was sent is not conveyed to the user.

Reproduced three times in a current Chromium version (Chromium/25.0.1364.160) on Ubuntu.

--------------------------
**Version**: unspecified
**Severity**: normal
The HTTPS element of this is now seemingly fixed in production. On submission, the user gets a "Your problem has been reported. Thank you." message. Marking as closed.
To clarify, Gabriel checked the log and the reports I sent indeed do not seem to have made it through.

And I agree that a "thank you" alert would be nice, but I would already have been happy if the "Report a problem" dialog box would just have closed after clicking the "Report problem" button. Instead, nothing happened at all...
IIRC posting from Wikipedia pages accessed via https has always been broken because of client-side security restrictions for subrequests. I think this is an instance of that problem.
The reports go to a private log that Gabriel monitors. :-)

We're likely to kill the feature in the medium-term anyway, but a "Thank you for your report" JS alert wouldn't go amiss.

Timo, thoughts?
An automatic tracking category for pages with errors in <math> (when parsed by texvc) would help finding these pages and fixing the errors.

--------------------------
**Version**: unspecified
**Severity**: enhancement
I see nobody answers. I am closing the task by myself. If there is a problem, reopen it.

Closed as resolved by [[https://gerrit.wikimedia.org/r/292576]].
The discussion was moved to [[https://en.wikipedia.org/wiki/MediaWiki_talk:Math-tracking-category-error|here]].
No problem.
Thank you. I have posted an edit request at that page on en.wiki.
First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
Second of all, there is no link for this case help, because it's too obvious.
1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
2. Put there for example a code:
{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
4. And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment).
5. Save the page.
6. Open one page with a math error in good namespace for editing. Make sure the category is there.
7. Open one page with a math error in bad namespace for editing. Make sure the category is not there.
8. If there is a problem, replace ":" with "-" in the code and try again.
9. When you are sure it works, run a nulledit bot on the current category content.
10. Done.
First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
Second of all, there is no link for this case help, because it's too obvious.
1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
2. Put there for example a code:
{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
4. And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment).
5. Save the page.
6. Open one page with a math error in good namespace. Make sure the category is there.
7. Open one page with a math error in bad namespace. Make sure the category is not there.
8. If there is a problem, replace ":" with "-" in the code and try again.
9. When you are sure it works, run a nulledit bot on the current category content.
10. Done.
I would love to do it myself (for everyone, not just in my own vector.js). @IKhitron, do you have a link to instructions on how to take care of it on en.wiki? Thanks.
I meant one line in wiki code, @SalixAlba and @Jonesey95, not jawascript.
It is a little annoying. But I'm convinced it is worth the extra effort. In time the number of false positives will go down and each page is re-rendered. Some talk pages which discuss rendering errors  will remain.

If its really a problem this bit of javascript in your vector.js will hide most of the talk pages.

  jQuery( document ).ready( function( $ ) {	
    	if( document.title == "Category:Pages with math errors - Wikipedia, the free encyclopedia") {
		$(".mw-category-group a").each(function(ind,ele) {
			var title = ele.innerHTML;
			if(title.startsWith("User:") || title.startsWith("Talk:") || title.startsWith("User talk:") 
			 || title.startsWith("Wikipedia:") || title.startsWith("Wikipedia talk:") ) {
				root = ele.parentElement;
				$(root).css({"display":"none"});
				console.log(ele.innerHTML);
			}
		})
	   }
     }
But @Jonesey95, you can do it in a minute by yourself.
If possible, it might be a good idea to limit the namespaces to which this category applies. For an example, see the Citation Style 1 error messages and categories on en.wiki, e.g. "Category:Pages with archiveurl citation errors":

"Pages in the Book talk, Category talk, Draft, Draft talk, Education Program talk, File talk, Help talk, MediaWiki talk, Module talk, Portal talk, Talk, Template talk, TimedText talk, User, User talk, and Wikipedia talk namespaces are not included in the error tracking categories."

The error message still shows on these pages, but they are not categorized. There is little point in categorizing someone's User sandbox page; it clutters the category with false positives.
@Aklapper? Or maybe @Quiddity? Thanks.
It looks like this is fixed in T134872 by https://gerrit.wikimedia.org/r/292576 We can probably close this as a duplicate.
So we now seem to have [[Category:Pages with math errors]] on en wiki at least.
Hello, @Aklapper. It works. I think you need close this task as resolved.
I think we would need comunity consensus for enabling the MathSearch extension in production... and a lot of cleanup work... sinc it's currently more desinged as demo/proof of concept.
**physik** wrote:

(In reply to Richard Morris from comment #2)
> This error is made worse by the difference between the syntax used in
> MathJax and texvc. In
> http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/
> Feedback&oldid=569279227#Math_text_that_doesn.27t_parse_when_in_VE
> a unicode character was used in a formula, the editor was probably using
> MathJax so the error did not show up. There seem to be a few such errors. A
> google search
> https://www.google.co.uk/search?q=%22Failed+to+parse%22+site:en.wikipedia.
> org+-Talk%3A
> can be used to find some.

Bug 72240 will make it better again. I'll try to migrate this feature from MathSearch to the Math extension.
This error is made worse by the difference between the syntax used in MathJax and texvc. In
http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=569279227#Math_text_that_doesn.27t_parse_when_in_VE
a unicode character was used in a formula, the editor was probably using MathJax so the error did not show up. There seem to be a few such errors. A google search https://www.google.co.uk/search?q=%22Failed+to+parse%22+site:en.wikipedia.org+-Talk%3A
can be used to find some.
**physik** wrote:

This is already a feature of the MathSearch extension.
Per IRC discussion between me and Trevor:

* Move list of MetaItems to dm.Document
* Keep MetaList (possibly rename it) with current API, wraps around list of items in Document
* MetaList takes a surface, and can make changes using that surface
* MetaItem.remove method will have to be removed, because it can't call back into the surface

(This is for post-July)

--------------------------
**Version**: unspecified
**Severity**: enhancement
Take the document:

<!-- meta -->content<!-- data -->

If you remove all of "content", the two comments now have to share an offset in the metadata array but this process is not recorded in the transaction. As a result, when the commit is rolled-back the comments aren't re-split so the resulting doc is:

content<!-- meta --><!-- data -->

--------------------------
**Version**: unspecified
**Severity**: normal
Related URL: https://gerrit.wikimedia.org/r/57850 (Gerrit Change I4edad1c2dd37c723bff2792bab7d694ef17a86dc)
Unlikely to ever be resolved because of {T139740}.
We can keep this open.  I actually just added a sleep to a test because I needed to get on with other things, and I should return to fix it at some point.
(In reply to Andre Klapper from comment #18)
> Are there more tests containing sleep or is this fixed?
> 
> Tony: Are you still working on this or should the assignee be reset to
> default?
I think there are a few more sleep keywords to be removed. Sorry, but I dont think I will be able to continue on this right now. Resetting to default assignee for the time being.
Are there more tests containing sleep or is this fixed?

Tony: Are you still working on this or should the assignee be reset to default?
All patches merged => resetting status from PATCH_TO_REVIEW to NEW
Change 109471 merged by jenkins-bot:
Removed sleep variable from TwnMainPage tests

https://gerrit.wikimedia.org/r/109471
Cirrus has two sleeps:
1.  It waits for some suggestions not to appear.  Without reworking the error handling in the javascript I can't remove this.  I don't feel up to reworking that right now.
2.  It sleeps between the creation of two pages that it uses to test searches that prefer pages with recent edits.  If I could backdate edit times then I wouldn't need it but I can't at this point.

In total Cirrus sleeps 35 seconds because each of the above is executed once.  It could be better but it could be worse.
Change 109471 had a related patch set uploaded by 01tonythomas:
Removed sleep variable from TwnMainPage tests

https://gerrit.wikimedia.org/r/109471
Change 108916 merged by Cmcmahon:
Replaced sleep with page-object gem waiting API

https://gerrit.wikimedia.org/r/108916
Change 108918 merged by jenkins-bot:
Removed sleep with waiting API in browsertests

https://gerrit.wikimedia.org/r/108918
Change 108918 had a related patch set uploaded by 01tonythomas:
Removed sleep with waiting API in browsertests

https://gerrit.wikimedia.org/r/108918
Change 108916 had a related patch set uploaded by Zfilipin:
Replaced sleep with page-object gem waiting API

https://gerrit.wikimedia.org/r/108916
(In reply to comment #8)
> Tony and I have paired on getting his environment set up to work on this.
I will put my status in [QA] once I have made my environment ready.
Tony and I have paired on getting his environment set up to work on this. Tony, if you still are interested in working on this, feel free to assign the bug to yourself. Let me know if you need help.
Tony Thomas:  just removing the code is not enough.  The tests have to be made to wait properly for whatever it is they are waiting for.  

Using sleep() is either an interim step that never got completed, or else the person writing the test could not think of a better way to wait for whatever the test needs.  

So the tests need to be updated in a thoughtful way so that they wait correctly without using sleep() but also without failing mistakenly.
(In reply to comment #3)
> Sleep statements found:
> 
Removing the code from the following places will do ?
mw.ViewPageTarget tabLayout is currently hard-coded, which means that we can't have VE work in replace mode on one wiki and add mode on another.

[No doubt other aspects of the integration configuration should not be hard-coded.]

--------------------------
**Version**: unspecified
**Severity**: minor
Related URL: https://gerrit.wikimedia.org/r/66881 (Gerrit Change I3fcb0c2903ae62d61ff789b5504e0ea23932121b)
Page: pages are not plain wikitext pages but are split into three textareas: header, footer and body and a proofreading level tag (note 1).
So, an adaptation of the VisualEditor to these pages is needed in order to make edition of the pages work.

The UI need to be tweaked in order to allow the splitting of the main textarea into three and the edition of the Proofreading level at the save of page as it works currently for wikitext editing (example: https://en.wikisource.org/w/index.php?title=Page:La_Fontaine_-_The_Original_Fables_Of,_1913.djvu/20&action=edit ).

An other useful (but less important thing) things is to add modules to the Visual Editor to support specific tags used by Wikisource like <pages>, <section> and <poem>.

note 1: structure of the page as save in the database:
<noinclude><pagequality level="LEVEL" user="LAST PROOFREADER" />HEADER<div class="pagetext">BODY<noinclude>FOOTER</noinclude>

--------------------------
**Version**: unspecified
**Severity**: enhancement

This card tracks a proposal from the 2015 Community Wishlist Survey: https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey

This proposal received 41 support votes, and was ranked #23 out of 107 proposals. https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey/Wikisource#Visual_Editor_adapted_for_Wikisource
{nav icon=file, name=Mentioned in SAL (#wikimedia-operations), href=https://tools.wmflabs.org/sal/log/AVgmueGyHQCSeVEJeq-D} [2016-11-02T20:27:45Z] <arlolra> updated Parsoid to version 173d7e32 (T149241, T119228, T141723, T141905, T147742, T48580, T133320)
Change 295707 merged by jenkins-bot:
Allow extensions to handle specific contentmodels.

[[https://gerrit.wikimedia.org/r/295707]]
Change 295707 had a related patch set uploaded (by Cscott):
Allow extensions to handle specific contentmodels.

[[https://gerrit.wikimedia.org/r/295707]]
Parsoid support for extensions implementing their own contentmodels at https://gerrit.wikimedia.org/r/295707
>>! In T48580#2398307, @Osnard wrote:
> Is there already a place/time made out to work on this during the Hackathon?

Table in Room 12 if you're not there!
Change 284681 merged by jenkins-bot:
Sectioned edit target for page namespace

[[https://gerrit.wikimedia.org/r/284681]]
Is there already a place/time made out to work on this during the Hackathon?
when trying to insert > pages get a 404 error ;' trying to switch to code hangs.
when refresshing and repeating it saves properly. on chrome browser 
{F4145216}
when trying to insert > pages get a 404 error
{F4145216}
@DannyH, you should subscribe to this :-)
>>! In T48580#2232258, @coren wrote:
>>>! In T48580#2228508, @jayvdb wrote:
>> Is it safe to assume this feature will not suddenly become active and in use in production once code from this task is merged?
> 
> It will certainly remain as a beta feature for quite some time, requiring explicit activation.

Well why not activate it on https://test2.wikipedia.org at the very least? The ProofreadPage extension is already 'enabled' there and nobody really uses it for proofreading; just for testing &/or illustrative purposes.

If not, please remember to make the beta "option" available there as well.
>>! In T48580#2228508, @jayvdb wrote:
> Is it safe to assume this feature will not suddenly become active and in use in production once code from this task is merged?

It will certainly remain as a beta feature for quite some time, requiring explicit activation.
Is it safe to assume this feature will not suddenly become active and in use in production once code from this task is merged?  Sorry that I need to ask ... but I have been unpleasantly surprised in the past (definitely not referring to the developers active on this or related task), and I hope to avoid that occurring in this case.

I think WS folk would like to play with it a little in a test bed before it becomes active somehow, and will need longer than a few days as the deploy process moves from beta/test/prod.

I certainly would be happy to do some QA work on it, if given a decent window to work with.  i.e. I cant make any promises to help if the approach is: it is merged, and will be deployed in three days, happy hunting.
Change 284681 had a related patch set uploaded (by Esanders):
WIP Sectioned edit target for page namespace

[[https://gerrit.wikimedia.org/r/284681]]
>>! In T48580#2214028, @Ankry wrote:
> We are still waitng for Page namespace support which is the main editing namespace for most wikisources. Moreover, many new wikisourcians edit **only** in the Page namespace. The general trend is to have articles in main namespace automatically or semi-automatically generated basing on data from Index and Page namespaces. So having VE support in main namespace may be a nice feature, but mostly useless.

Indeed.  Having VE there at all was a preliminary requirement, not the end result.  :-)
i noted some buggy interaction for the insert > pages, initially rather than subsequenly editing pages template https://www.mediawiki.org/wiki/VisualEditor/Feedback
i noted some buggy interaction for the insert > pages initially rather than subsequenty editing pages template https://www.mediawiki.org/wiki/VisualEditor/Feedback
i noted some buggy interaction for the insert > pages initially rather than editing pages https://www.mediawiki.org/wiki/VisualEditor/Feedback
>>! In T48580#2213983, @Qgil wrote:
> What is missing to consider this task Resolved?

We are still waitng for Page namespace support which is the main editing namespace for most wikisources. Moreover, many new wikisourcians edit **only** in the Page namespace. The general trend is to have articles in main namespace automatically or semi-automatically generated basing on data from Index and Page namespaces. So having VE support in main namespace may be a nice feature, but mostly useless.
What is missing to consider this task Resolved?

I am trying to summarize the progress on this task at https://meta.wikimedia.org/wiki/Wikimedia_Blog/Drafts/WIP_Wikimedia_Hackathon_2016_post#The_connection_with_the_Community_Wishlist. Is there any beautiful screenshot in Commons that we can reuse?
This was deployed in the new Single Edit Tab mode.  The basic explanation is at https://www.mediawiki.org/wiki/VisualEditor/Single_edit_tab if anyone is looking for information.
Insert -> Pages -> there is no "onlysection" attribute

Z.
works well in chrome and firefox. saved first new article.
>>! In T48580#2173976, @Jdforrester-WMF wrote:
> Clarification: This will be for all Wikisources, not just frws. :-)

Oh, yeah.  Good point.  It will be available (selectable from the beta features selector) on all Wikisources.
>>! In T48580#2172585, @coren wrote:
> @Jdforrester-WMF is planning to turn the configuration switch on April 7.
> 
> At that point, Visual Editor will become available as a beta feature on fr.wikisource.org for all content namespaces except Page (that's the next part being worked on now).

Clarification: This will be for all Wikisources, not just frws. :-)
Current status: we now have a proper design for Page namespace that is in progress but - as a first step - we now have usable mainspace editing with Visual Editor (including the transclusion tag).  This is currently working on a test server, and is scheduled for the deployment train Tueseday, Apr 5 (and deployed on group 1 that inlcludes the Wikisources on Apr 6).

@Jdforrester-WMF is planning to turn the configuration switch on April 7.

At that point, Visual Editor will become available as a beta feature on fr.wikisource.org for all content namespaces except Page (that's the next part being worked on now).
> I will be in Jerusalem, and will concentrate on coordinating work on this task while there (as well as hack on it myself).
Great! I'll be in Jerusalem too and willing to work on it.
I will be in Jerusalem, and will concentrate on coordinating work on this task while there (as well as hack on it myself).
IMPORTANT:  **If you are a community developer interested in working on this task:** The [[ https://www.mediawiki.org/wiki/Wikimedia_Hackathon_2016 | Wikimedia Hackathon 2016 ]] (Jerusalem, March 31 - April 3) focuses on #Community-Wishlist-Survey projects. There is some budget for sponsoring volunteer developers. THE DEADLINE TO REQUEST TRAVEL SPONSORSHIP IS TODAY, JANUARY 21. Exceptions can be made for developers focusing on Community Wishlist projects until the end of Sunday 24, but not beyond. If you or someone you know is interested, please [[ https://www.mediawiki.org/wiki/Wikimedia_Hackathon_2016 | REGISTER NOW ]].
@Jdforrester-WMF are you able to add some guidance here?
What can we do, as community members, to raise the priority of this? It is **really** important for Wikisource to have the VE active within the Page namespace. It is probably the most needed feature of Wikisource projects, and it would be an important testbed for the VE itself: Wikisource books are heavily formatted, much more than Wikipedia articles.
(In reply to comment #2)
> This data should be in a queryable format. The current format sucks and should
> be abandoned. If there's not already a bug filed about this, please file one.
Done (bug 46724). But before doing anything on this direction, a refactoring of the wikitext edition interface is needed because the current system is closely based on this storage format (bug 46578).
(In reply to comment #0)
> note 1: structure of the page as save in the database:
> <noinclude><pagequality level="LEVEL" user="LAST PROOFREADER" />HEADER<div
> class="pagetext">BODY<noinclude>FOOTER</noinclude>

This data should be in a queryable format. The current format sucks and should be abandoned. If there's not already a bug filed about this, please file one.

(In reply to comment #1)
> How would we go with looking to put the user into the API?  That information
> would be useful to present through the 'page information' so it is
> presentable via 'action=info'.  At the moment one has to pull the page data to
> get the user info, while the proofread status is already captured. Well that
> is my limited understanding of the data.

action=info is part of index.php, not api.php. That is, the info action is part of the (graphical) user interface, not part of the MediaWiki API. This bug should just be about a single issue. Adding this type of information to the info action can be a dependent bug of this bug. There may be such a page filed already, maybe.

Basically, once the data is queryable, both the info action and the MediaWiki API modules can pull the data out easily. But that's at least three separate bugs (and probably many more).
How would we go with looking to put the user into the API?  That information would be useful to present through the 'page information' so it is presentable via 'action=info'.  At the moment one has to pull the page data to get the user info, while the proofread status is already captured. Well that is my limited understanding of the data.
Inline comments would be powerful addition to AFT.  It would be something like
https://en.wikipedia.org/wiki/Stet_%28software%29 integrated into MediaWiki.

I think it would help people make useful comments that could more
quickly be acted on/resolved.

I realize this would be a large enhancement, but I think it's worth considering at some point in the future.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**URL**: http://annotator.wmflabs.org/
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=49603
No reply. Hence closing.
>>! In T48440#529613, @Parent5446 wrote:
> https://gerrit.wikimedia.org/r/79839
> https://gerrit.wikimedia.org/r/78251
> 
> Once they are merged, the extension has most of the features implemented. The only thing not implemented is threading, which would be too difficult because OKFN does not natively support it.

>>! In T48440#529622, @Mattflaschen-WMF wrote:
> Yeah, I consider this complete.

So should this task be closed as resolved? (The item is mentioned on https://www.mediawiki.org/wiki/Outreach_programs/Possible_mentors - that's how I got here)
If you have open tasks or bugs left, one possibility is to list them at https://www.mediawiki.org/wiki/Google_Code-In and volunteer yourself as mentor.

We have heard from Google and free software projects participating in Code-in that students participating in this programs have done a great work finishing and polishing GSoC projects, many times mentores by the former GSoC student. The key is to be able to split the pending work in little tasks.

More information in the wiki page. If you have questions you can ask there or you can contact me directly.
**tilgovi** wrote:

Nice to see this worked out well!

As for replies, I've got a threading plugin that handles most of this. I'm looking to upstream it for Annotator 2.0.

I'll also take the feedback about not showing annotations immediately into mind. Nothing stops the integrator from overriding the .annotator-hl styles, but something more direct and programmatic might make sense.

Once again, reach out any time in #annotator on freenode or the annotator-dev list and I'll keep watching this bug.
The GSoC project has the "Prototyping" word very visible. Wikimedia requirements for deployment are out of scope. The fact that they are being discussed already now indicates that this prototyping phase seems to be a success. :)

Let's get through the GSoC evaluation and let's talk about further steps after that.
Bug 52156 (history) is also a blocker (to be clear, this is an extra, not part of the required prototype deliverables) to WMF (and probably most third parties) deployment.  It's not strictly UI, but it's definitely user-visible (to experienced users who understand history).
**swalling** wrote:

(In reply to comment #54)
> Yeah, I consider this complete.  I think we will be able to get those two
> merged, but I don't think either are hard requirements (though the annotation
> tab is pretty useful, because otherwise you get annotations everywhere all
> the
> time).

I think bug 52064 is the only big UI/UX blocker for actually deploying this to a Wikimedia wiki. Showing annotations by default on every view is likely to annoy folks. 

Otherwise, I think even things like bonafide threading support can be put on hold for later release. Overall, agreed with Matt that this product is nearly done. Very good work for a GSoC project. :)
Yeah, I consider this complete.  I think we will be able to get those two merged, but I don't think either are hard requirements (though the annotation tab is pretty useful, because otherwise you get annotations everywhere all the time).

As Tyler noted, there's not really reply support.  However, if you comment on the same text, it puts the annotation underneath.

The other item that is not implemented (mainly since we did not prioritize it) is including the date.

However, there have been other items implemented that were not listed under Required Deliverables, so I think it balances out.  E.g.

* Update and delete
* Proper DB setup (including AnnotationRepository for testability), including SQLite support and updates.
* Logged out user support (under review; Required Deliverables mentions usernames, but not IPs)
* PHP unit tests (this is the third change under review, which I would like to get merged).
There are two open patches right now:

https://gerrit.wikimedia.org/r/79839
https://gerrit.wikimedia.org/r/78251

Once they are merged, the extension has most of the features implemented. The only thing not implemented is threading, which would be too difficult because OKFN does not natively support it.
GSoC "soft pencils down" date was yesterday and all coding must stop on 23 September. Has this project been completed?
(In reply to comment #49)
> Just tried the demo and it works well. Great work Richa and mentors! Just a
> couple of comments:

Thanks. :)

> - When I edited the page all annotations were gone, I reverted to the
> previous edition but the annotations didn't reappear.

Yes, handling page changes is one of the trickier things that there may or may not be time for this summer.

However, we do want to fix the issue where the wrong annotations appear when you look at an old version of the page from the history (bug 51728).

> - I assume that these annotations will be displayed in the newly deployed
> Visual Editor. Would it be possible to update the text anchor as the text is
> being changed? Annotations in Google Docs have this behaviour, however I am
> not sure if it would be too complex to mimic that feature.

There is no VE support so far.

> - In the "recent changes" page I didn't see any notification of my actions, I
> understand that it could be meant this way?

We may have time to add logging, but you're right there is no history or logging yet.
 
> And I also loved that you can select several sections of text and create one
> annotation for all those sections. If the annotation link could be displayed
> (maybe with a 3rd icon, an anchor displaying the link), that would be a great
> addition for external websites linking to/highlighting particular fragments,
> or conversations in the talk page pointing to fragments.

That's a possibility at some point.
(In reply to comment #49)
> Just tried the demo and it works well. Great work Richa and mentors! Just a
> couple of comments:
> - When I edited the page all annotations were gone, I reverted to the
> previous
> edition but the annotations didn't reappear.
It looks for annotations for the latest revision since i am using the latest revision id. There is already a bug filed for this https://bugzilla.wikimedia.org/show_bug.cgi?id=51728 .
> - I assume that these annotations will be displayed in the newly deployed
> Visual Editor. Would it be possible to update the text anchor as the text is
> being changed? Annotations in Google Docs have this behaviour, however I am
> not
> sure if it would be too complex to mimic that feature.
> - A minor glitch: when I delete an annotation I get the message "sorry we
> could
> not destroy this annotation", however the annotation is indeed deleted.

The destroying of annotations is still under review. https://gerrit.wikimedia.org/r/74150 so the annotations are not actually deleted currently.
> - In the "recent changes" page I didn't see any notification of my actions, I
> understand that it could be meant this way?
> 
> And I also loved that you can select several sections of text and create one
> annotation for all those sections. If the annotation link could be displayed
> (maybe with a 3rd icon, an anchor displaying the link), that would be a great
> addition for external websites linking to/highlighting particular fragments,
> or
> conversations in the talk page pointing to fragments.
> 
> Micru
Just tried the demo and it works well. Great work Richa and mentors! Just a couple of comments:
- When I edited the page all annotations were gone, I reverted to the previous edition but the annotations didn't reappear.
- I assume that these annotations will be displayed in the newly deployed Visual Editor. Would it be possible to update the text anchor as the text is being changed? Annotations in Google Docs have this behaviour, however I am not sure if it would be too complex to mimic that feature.
- A minor glitch: when I delete an annotation I get the message "sorry we could not destroy this annotation", however the annotation is indeed deleted.
- In the "recent changes" page I didn't see any notification of my actions, I understand that it could be meant this way?

And I also loved that you can select several sections of text and create one annotation for all those sections. If the annotation link could be displayed (maybe with a 3rd icon, an anchor displaying the link), that would be a great addition for external websites linking to/highlighting particular fragments, or conversations in the talk page pointing to fragments.

Micru
You can now also use the simpler URL, http://annotator.wmflabs.org
There is now a test wiki for this, http://annotator.instance-proxy.wmflabs.org/ .  If you're interested in testing it, create an account, then try annotating http://annotator.instance-proxy.wmflabs.org/wiki/Lorem_ipsum .

Currently, you must be logged in, both to see annotations and to make them (bug 51722).
We've made a Bugzilla component.  This will still be the main bug, tracking the initial key functionality.
**nick** wrote:

That GitHub compare url has the sense of the comparison the wrong way round: http://github.com/okfn/annotator/compare/master...wip
**nick** wrote:

(In reply to comment #43)

Hi all,

Sorry not to have weighed in earlier. I'm really glad to see you're using Annotator, and hope I can help out with any problems you might have.

> I'm a little unclear about the relationship of 'read' and 'index', and how
> the URLs work.

Yes, this is a bit messy. Read and index are implicitly the same endpoint at the moment, and index is just "read" with a null ID. Obviously this is horrible, but it turns out that it doesn't matter that much as an index endpoint that returns all annotations is almost never useful anyway, so...

> It seems like this may be a moot point if we use loadFromSearch.  However, I
> would expect there to be an 'index' url for consistency.

...the vast majority of real implementations use loadFromSearch. If you're interested, current work in progress on Annotator 1.3/2.0 (http://github.com/okfn/annotator/compare/wip...master) is revisiting some of this stuff, and the four endpoints that need implementing by a store are now create/update/delete/query, and the index endpoint is gone.

But, to answer your concrete question: use loadFromSearch and ignore the existence of the "index" endpoint.
I was wondering if someone from the OKFN team could answer a couple quick questions.

I'm a little unclear about the relationship of 'read' and 'index', and how the URLs work.

https://github.com/okfn/annotator/wiki/Storage#index says index returns "a list of all annotation objects".  First, I'm wondering if that is supposed to be limited to the current page's annotations.  Maybe that's up to us.

However, the plugin docs (https://github.com/okfn/annotator/wiki/Store-Plugin) have no mention of index, nor do I see a way to override the URL.

https://github.com/okfn/annotator/wiki/Storage#read says it's a straight-forward method that takes an ID and returns a single annotation.

But the plugin docs (Store-Plugin) say, "read: GETs all annotations. Called when plugin loads or .loadAnnotations() is called. Server should return an array of annotations serialised as JSON."

Looking at the Coffee code, it seems read is called to get a list, but never explicitly called for a single annotation (although there is a commented out line doing that).  However, since we're using the recommended 303 redirect, it's implicitly used for creations.

The list part is confirmed by testing.  It loads http://127.0.0.1:9090/w/api.php?action=annotator-read&id=:id, which is a bit weird.  I think this is related to https://github.com/okfn/annotator/issues/186

It seems like this may be a moot point if we use loadFromSearch.  However, I would expect there to be an 'index' url for consistency.
See also:
* [[Wikipedia:Village_pump_(idea_lab)/Archive_3#Sticky_Notes_for_Easier_Editing]]
* [[Wikipedia:Sticky notes]]
**tilgovi** wrote:

We're right here watching, Rob :)

I would recommend just focusing on upstream okfn/annotator. We're cranking hard to get everything relevant pushed upstream.

Richa, don't hesitate to reach out if you want help testing or have any questions about the annotator code.
**azaroth42** wrote:


Just to recommend the hypothes.is version of annotator, and to point to the Open Annotation specification for the implementation:

http://www.openannotation.org/spec/core/

and 

http://www.w3.org/community/openannotation/

Hope that helps, and looking forwards to seeing the outcomes. Happy to answer any Open Annotation questions that may come up!
Gerrit is ready and all my github changes are imported. 
https://git.wikimedia.org/log/mediawiki%2Fextensions%2FAnnotator.git
The basic skeleton of where to call the annotations is ready. Now i am starting with the storage of comments. Here are some of my points:
1. Going through the idea of custom table implementation and storing comments in a separate table which takes account of the revision id, user and the range.
2. Creating classes 'create', 'update', 'read', 'delete' for annotations. https://github.com/okfn/annotator/wiki/store-plugin#urls
3. Modify the above urls of OKFN as:
prefix: 'api.php'
create: '?action=create', etc.
Just a note that i have made a repo on github https://github.com/richajain/Prototyping-inline-comments and have done some initial commits. I will be updating this with the progress done at regular time.
**tilgovi** wrote:

Just popping in to subscribe to CC on this. I'm actively maintaining and improving Annotator for Hypothes.is and am happy to answer any questions or work with you all to close any gaps we need to in order to store annotations in mediawiki.
(In reply to comment #35)
> I saw they allow overriding the URL syntax
> (https://github.com/okfn/annotator/wiki/Store-Plugin#urls), so the main
> concern
> is probably less used methods like PUT and DELETE, which needs investigation
> on
> both sides (OKFN and MW).

AFAIK, if you submit a PUT/DELETE request to the API, it will probably just treat it as a GET request, although I could be wrong and have not tested this.
(In reply to comment #33)
> (In reply to comment #32)
> > Someone may have made a RESTful wrapper of a MW API, or have advice on doing
> > so.
> 
> I sure hope this exists. The API interface is terrible right now.

I saw they allow overriding the URL syntax (https://github.com/okfn/annotator/wiki/Store-Plugin#urls), so the main concern is probably less used methods like PUT and DELETE, which needs investigation on both sides (OKFN and MW).
From Matt's email:
> The high-level concept of RevisionDelete applies, but I don't think
> directly using it is a good fit.  What happens if one comment on a page
> is a violation, but the next consecutive 999 are fine?  With RevDel, I
> think you'd have to remove the bad one, then suppress all 1000 (correct
> me if I'm wrong) containing the bad one, leaving no history of how the
> good 999 developed.

I was thinking one page per comment.

> True, but there's existing code (the main one I'm thinking of is AFTv5)
> to learn from.  Another reason not to use a page is that it constrains
> changes.  Once we publish the JSON page, there could be bots that rely
> on it, rather than the API.  If we just use JSON internally, that gives
> us flexibility.

If we use pages, we could still use JSON only internally. We'd implement a new Content type for annotations and still provide an API module for accessing comments.

All that said, I understand the concern with using articles as a storage medium, so I would be fine with either way. I just wanted to make sure we weren't ditching the idea without due consideration.
(In reply to comment #32)
> Someone may have made a RESTful wrapper of a MW API, or have advice on doing
> so.

I sure hope this exists. The API interface is terrible right now.
Richa Jain has been accepted for Google Summer of Code for this project.  She is currently investigating OKFN and the store plugin.  The below are some thoughts as a starting point:

OKFN provides documentation on writing a plugin for storing annotations (https://github.com/okfn/annotator/wiki/Store-Plugin)?  The most straightforward approach seems to be implementing that as a MW extension.

https://github.com/okfn/annotator-store is an example of how one store works, though of course the MW extension example will be different.

One issue is that the API is RESTful.  It lets you set a custom prefix, but the syntax is a little different than MW normally uses.  

One way to do this is to make a normal MW-style API subclass (like https://www.mediawiki.org/wiki/API:Extensions#Creating_API_modules_in_extensions), then hook into the URL routing code to translate the OKFN-style RESTful URLs to calls to the API.

Someone may have made a RESTful wrapper of a MW API, or have advice on doing so.  It's probably also worth looking at the hooks (https://www.mediawiki.org/wiki/Manual:Hooks)
**ganeshaditya1** wrote:

(In reply to comment #30)
going by the description, it perfectly fits the bill! I mean it has all the methods of firefox available in IE. But the documentation is really very poor man. Its going to take me a while to make heads and tails of this :(
(In reply to comment #29)
> going a little off topic here, I think internet explorer cannot be supported
> in any efficient way, cause of the way text ranges are implemented in it. 
> 
> Both ofkn and pundit are not supported in IE. I ve been going through the
> code of OFKN for a while now and this dawned upon me just now.

In the VisualEditor project we have similar needs for cross-browser range selection and manipulation, and we have used the Rangy library - https://code.google.com/p/rangy/ - which has worked out well for us. Not sure if this is helpful for you?
**ganeshaditya1** wrote:

going a little off topic here, I think internet explorer cannot be supported in any efficient way, cause of the way text ranges are implemented in it. 

Both ofkn and pundit are not supported in IE. I ve been going through the code of OFKN for a while now and this dawned upon me just now.
Another tool for inspiration? http://www.thepund.it/

Java backend but "The Pundit client is a Javascript application based on the Dojo Toolkit http://dojotoolkit.org/ . It works closely with the Pundit server API, allowing the end-user to annotate any kind of web contents."

Apparently related with Europeana and funded by the EU. Sounds like open source but after a very few clicks couldn't find sources (busy day etc).
Just a note to say that Anthony Chen has submitted a GSoC proposal related to this project: https://www.mediawiki.org/wiki/User:N3c/GSoC_Proposal
**ganeshaditya1** wrote:

I seem to have butt into the conversation .. I didn't read the comments yet. 
Apologizes .. 

Anyways keeping with the conversation, since you guys are discussing interfaces, please checkout my prototype

http://adityasastry.in.cp-2.webhostbox.net/index.php?title=Special:BlankPage

Instead of the in-page along with article display, I would propose a movable popout as the readability might suffer when you try to squeeze in the comments interface into the article.
(In reply to comment #23)
> Hey,
> My name is Aditya and am interested in pursuing this as my GSOC project.

Thank you for your interest.

> Implementing this for some other theme is very easy. We just need to add a
> DIV in the theme's php file.

Note that this is being proposed as an extension.  Thus, you should not need to modify the core skin definition.
**ganeshaditya1** wrote:


2)Databases
Allow me to make a very bold statement here that  json/xml are ill suited for a project of this nature.
Justification:
1) There are many helper classes already written for MediaWiki like sanitizer class(which depends on the databases) load balancer class(Incase one wants to distribute the comments data) and few other classes which implement functionality which is critically needed. Incase one wants to go the XML/JSON way one needs to implement them as well.

2) Maintenance will become an issue.

3)When migrating between hosts one needs to manually select the xml/json files and move them around. MYSQL supports one click export and import functionality for all the tables.

I will be making a prototype for databases as well in a couple of days.
And here's my idea. Each article is stored as a WikiText string, so as illustrated by my UI the selected text's starting and ending indexes are caught and the article page name is also caught. These three attributes will be used as indexes into a table "Comments" 

When parsing this wikitext, based on the starting and ending indexes the text will be marked and a link will be provided next to it to access the comments as I have shown.

I will be implementing this functionality by tuesday. But for the sake of proposal I will be not using any of the MediaWiki classes for now so you people could test drive it once and based on your feedback I will be making ammendments to my proposal, so please review my work so far :)
**ganeshaditya1** wrote:

Hey,
My name is Aditya and am interested in pursuing this as my GSOC project.

After going through the requirements, leaving apart any additional features required. I have outlined two major aspects of this project.

1) Designing the UI.
2) Designing the database.

I just want to present my perspective on these two things before I start drafting my proposal. I want to hear your opinion on this.

1)UI
When it comes to designing the UI. I think it will be better if we go with a custom build rather than using a ready-made component, cause MediaWiki uses themes and each component should match the theme and a ready made component leaves very little margin for customization ( in-case its a opensource component, then it might as well be modified, but the person designing the theme need to be not only versed with the code of the MediaWiki but as well as the source code of the component, hence I believe a ready made component would constrain the customizability of MediaWiki.

http://adityasastry.in.cp-2.webhostbox.net/index.php?title=Special:BlankPage
This is a UI mockup I came up with. Its a prototype for a prototype :P I have made an implementation of this for VECTOR theme, but I have placed the CSS and JS for this in the common skins shared.css and the JS in vector.js as of for now.
Implementing this for some other theme is very easy. We just need to add a DIV in the theme's php file.
Just a note to say that Richa Jain has submitted a GSoC / OPW proposal related to this report:

https://www.mediawiki.org/wiki/User:Rjain/Proposal-Prototyping-inline-comments

There is another student that has submitted a proposal. I will announce it here as soon as there is a public URL.
Slightly related: http://homes.cs.washington.edu/~travis/reflect/

With old MediaWiki extension code available: http://www.mediawiki.org/wiki/Extension:Reflect

Depends on LiquidThreads, so I don't expect many possibilities of reuse as-is but perhaps you want to have a look.
(In reply to comment #19)
> http://okfnlabs.org/annotator/ is maybe (with some adaptations) a relevant
> option.

Also http://hypothes.is (they seem to build on top of okf's annotator: https://github.com/hypothesis/h#development)
http://okfnlabs.org/annotator/ is maybe (with some adaptations) a relevant option.
This is the end result we are after:

Wikipages optionally looking like this (famous examples picked for reference only):

http://gplv3.fsf.org/comments/lgpl-draft-1.html (few comments)

http://gplv3.fsf.org/comments/gplv3-draft-2.html (really busy)


That view would include the possibility to add comments. There is a sandbox to play without registration at

http://www.co-ment.com/see/

And a lite version at https://lite.co-ment.com/


PS: group permissions to be taken into account? Maybe not in a prototype for a GSOC student but I can imagine that the same levels of protection (open, registered users, autoconfirmed...) would be desired. For Wikimedia wikis I would require login, a nice reason to register. But this is going too far...  :)

Also, spam check? Posting external URLs possible or not? Well, this can be endless and again we should define the scope for a GSOC prototype.
From where I'm coming from, it has nothing to do with the first option (HTML comments/warnings to editors).

It is meant as a collaboration tool, essentially your second option.  I don't see it as a replacement for long free-form discussion ("this article needs more reliable sources..."/"it has an undue weight is the following areas"...), but a targeted form of collaboration around small areas of the article, like co-ment.

I agree a first pass (on MediaWiki.org, etc.) would be useful regardless, even if not all the code could necessarily be integrated into the permanent solution.  It would allow trying out implementations and UI ideas.

I agree it would probably have to be one interface at first (and maybe ever), and VisualEditor/Parsoid probably makes more sense.

There would probably have to be limited threading, but flat (these people commented on this excerpt in this chronological order) would probably be sufficient.  If it gets too elaborate, talk it to the talk page/Flow.

To keep it concise, I would suggest just the username and date (perhaps auto-formatted to e.g. "3 hours ago" for recent comments), rather than a signature.  I suggest it should show IPs for anons.

I'm not envisioning using LQT, since it seems like if we want to integrate at some point, Flow would be a better candidate.

It would be most useful attached to pages, automatically invalidating a comment when an excerpt is altered.  But "attached to revision" is probably more realistic for the first implementation.
So, to my mind there are two options here, and I can't quite understand which is being discussed (it appears both):

* Is this about surfacing to the editors in some nice way post-VisualEditor roll-out the existing comments for editors - I.e. "<!-- PLEASE DO NOT CHANGE OBAMA'S NAME -->" at the top of the Barack Obama article on enwiki? If so, great, and this should probably be moved to the VisualEditor product space. This is definitely needed for VE, but I worry that the scope for functionality is not huge, and it might be limiting.

* Is this about building an additional persistent/semi-persistent un-threaded/semi-threaded discussion space on top of pages/revisions(?) like Co-ment and Google Docs? If so, that sounds fun, and something that we're also looking at building for VisualEditor (as part of the real-time collaboration system, potentially), but I wouldn't want us to get in the way of someone building a first pass for GSoC. Doing this for both VE and wikitext at the same would be a really hard UI challenge (they're very different interface concepts), so perhaps limiting it to just one of them for now? Also, there needs to be a really serious discussion about how this would work from a product perspective (threading? how much? how signed? using LQT? why not? where stored? attached to revisions? To pages? to sections of said revision/page? how? etc.) lest it become mammoth. OTOH, this would be very cool as well.

Apologies for the confusion on my part. :-)
I've linked this bug from https://www.mediawiki.org/w/index.php?title=Feature_map&diff=663816&oldid=566850 where the FSF feature was reported.

(In reply to comment #11)
> Are all annotations willing the be seen publicly by default? We won't go for
> private annotations, but maybe people want to have notes-to-self? Like ToDo
> post-its for editors, or notes for students preparing their school work.

Looks outside the scope of the request. It's indeed the sort of thing the word "annotation" is usually used for, so let's not call this proposal "annotations" maybe?
More context:

Commons has annotations in images:
http://commons.wikimedia.org/wiki/Commons:Image_annotations

Munaf mentioned annotations at
http://www.mediawiki.org/wiki/Micro_Design_Improvements#Annotations
James Forrester has indicated that this may be within the scope of VisualEditor, and that he would be receptive to the feature being implemented as part of GSOC.  I've CCed him.
To follow up, I have decided to act as mentor should the project be selected.

I think annotation is a valid term, although comment is also commonly used (e.g. LibreOffice, Google Docs).  co-ment seems to use both terms.

There should probably be some kind of permalink that shows the comment, but initially that might just be a link to the revision (especially if comments aren't preserved on edit in the first implementation).

I don't think they should be shown to readers by default.  It would have to be a toggle of some kind.  It would be nice to make this available in VisualEditor mode (either just that, or both).

The notes to self idea needs further thought.  I see the primary use of the extension as collaborative work, but then again people do use userpage for drafts too.

If this project moves forward, we may want to continue speccing it out on mediawiki.org.
A bit of context and braindumping:

http://openannotation.org/
http://www.openannotation.org/wiki/index.php/Web_Page_Clients_List

Maybe "annotations" is the label we are looking for? Wikipedia articles are not scholarship texts, and inline comments won't be scholrship annotations. Then again... aren't they structurally the same? Point to a specific portion of text and connect a comment, a signature, a timestamp, maybe a link.

Another aspect is My Annotations, as part of My Contributions.

I guess annotations will need a unique deeplink? 

And do we get those annotations by default, or should users activate an "Annotated view"? Maybe the latter, it looks like too much extra bytes and clutter for the majority of people interested in the first paragraph and some factoids.

Bonus:
Are all annotations willing the be seen publicly by default? We won't go for private annotations, but maybe people want to have notes-to-self? Like ToDo post-its for editors, or notes for students preparing their school work. Those would be as public as our User pages: public for those knowing where to look but out of default searches / views.
This feature request is being considered for 

https://www.mediawiki.org/wiki/Summer_of_Code_2013#Project_ideas

Question: is there a potential mentor willing to help potential students interested in this project?
This sounds much more like a separate extension than an enhancement to ArticleFeedback.
Such articles tend to be protected on some level, though, and the same reasons would probably have to apply to this as well.
(In reply to comment #4)
> But why would that many people be commenting on the same thing?

Think of a controversial article that asserted a true, verifiable, but controversial fact.  It would probably perennially attract comments to the sentence stating the fact.  So at the very least there would have to be easy filtering/mark as resolved/mark as rejected.

I agree it doesn't *have* to be Wikipedia-scalable, but it's certainly far more useful if it is.

Note, implementers should also consider looking at the co-ment code.
Right, I guess my point was just that wikipedia is not as extreme as folks often make out, sorry. If the thing is well-engineered and scales properly it should work for everyone, which would be perfect.
If it's not the problem, all the better. I'm just saying that we shouldn't hamper this potential GSOC project with Wikipedia-centric issues if they are not issues for the 98% of MediaWikis out there.
(In reply to comment #3)
> Then again it is not a trivial project at all. If we propose this we should
> put
> apart key aspects of Wikipedia like 5.000 editors commented on the same
> sentence, performance issues, scalability... Perhaps the project could
> consist
> in recycling as much stet code as possible and plug it to a MediaWiki
> backend.

But why would that many people be commenting on the same thing? There are only so many parts of an article worth commenting on, and only so many points to be made, and a flat out discussion would belong on a talkpage (or equivalent), not in the comments themselves.

As it is people tend to distribute what they work on and edit. Yes, many, many people edit wikipedia and such, and a lot of people may edit the same article, but it doesn't happen all at once. Comments, even if they do span multiple revisions, will only span so many before they cease to apply.

Just look at gerrit as a tiny example - plenty of folks comment on plenty of things, but I've rarely seen more than one or two people comment inline on any one patchset. It's only useful for so many things, and once someone made a point there's no use making it again.
Regadless of Wikipedia & Wikimedia plans, this looks like an extension that would be useful and welcomed in other MediaWikis out there. Well, I know that in the GPLv3 drafting times I really wanted to have that in the MediaWiki based project we were running...

Then again it is not a trivial project at all. If we propose this we should put apart key aspects of Wikipedia like 5.000 editors commented on the same sentence, performance issues, scalability... Perhaps the project could consist in recycling as much stet code as possible and plug it to a MediaWiki backend.
See http://lists.wikimedia.org/pipermail/ee/2013-March/000263.html (beginning of thread), in particular http://lists.wikimedia.org/pipermail/ee/2013-March/000276.html (about some of the UI/UX challenges).

The AFT team is not planning on implementing this, at least for the time being.

It is a candidate for a Google Summer of Code Project (mentioned at https://www.mediawiki.org/wiki/Talk:Summer_of_Code_2013#List_of_project_ideas_25327), among other possibilities.
This could also potentially be done as a separate extension.
Various users find them inappropriate in #mediawiki because it is a support channel, not as much a developer discussion channel (#wikimedia-dev).

Whether to move them there or to a dedicated channel isn't clear yet.

See discussions on bug 46282 and bug 46144.

--------------------------
**Version**: wmf-deployment
**Severity**: enhancement
https://github.com/valhallasw/pywikibugs is the source for people who want to make modifications.
Wikibugs is dead, pywikibugs reports to #wikimedia-dev.
(In reply to Krinkle from comment #11)
> Re-opened since bug 46144 is still unresolved.

You didn't re-open this bug. It's now a tracking bug that's marked resolved/fixed with an open dependency. Hrm.
Re-opened since bug 46144 is still unresolved.
06.45 -!- Nemo_bis changed the topic of #wikimedia-dev to: MediaWiki and Wikimedia software development | Support: #mediawiki | Technical help for Wikimedia wikis: #wikimedia-tech | Wikimedia operations: #wikimedia-operations

It used to be "Developers' talk about WMF's #mediawiki projects" or very similar ones (the key being WMF) since the beginning of time (creation as -usability).
https://gerrit.wikimedia.org/r/#/c/57752/ , https://gerrit.wikimedia.org/r/#/c/57753/ merged.

00.31 -!- gerrit-wm [~gerrit-wm@manganese.wikimedia.org] has quit [Remote host closed the connection]
00.32 < mutante> bot is moving per merged changes
00.32 < James_F> Yup. :-)
00.32 < James_F> (Yay.)

(CEST)
Related URL: https://gerrit.wikimedia.org/r/58661 (Gerrit Change I588f2eba8fba9603f33386e54e90c03e2bb5f5f0)
(In reply to comment #6)
> Ori submitted I10a02bfe to get this done when there is approval.

I'd say, why can't we do both? Lets first move it out of #mediawiki. That is something we all agree upon.

We'll keep it in regular talk channels for now (#wikimedia-dev).

If we believe that it is disturbing even in a developer-oriented channel (which I'm sure it won't) then we can choose to create a separate channel, but going all the way at once is unnecessary and only creates more chaos.
Ori submitted I10a02bfe to get this done when there is approval.
I wrote this before: Could we move this debate to its target audience somehow, as I'm afraid that it won't be seen in this Bugzilla report?
I understand that's hard for IRC, but maybe a generic mailing list or RFC? 
I don't see much sense battling here.
(In reply to comment #3)
> #wikimedia-dev is not Wikimedia deployment specific development. It is
> development of software used by Wikimedia, which all of MediaWiki is
> obviously part of at least as long as either MediaWiki is a Wikimedia
> Foundation project and Wikipedia.org runs on MediaWiki. Regardless of
> whether our staff maintains it or not.

This is insane. Are you hearing yourself?

>> I'd much prefer #mediawiki-feeds.
> 
> For what reason? Because you don't want to see it in channels that you're in?

Because it's the least bad option (other than keeping the bots in #mediawiki).

> In that case we move it out of channels not meant for developers only
> (#mediawiki) and into #wikimedia-dev where it is reasonable to ask you to use
> /ignore if you don't like it.

This doesn't make any sense. What's accomplished here?

> If you do find them useful, then how are they useful in a separate channel?
> You'd have to manually check up there to see for anything. I don't think that
> works well in practice. The whole idea of being exposed to other people's
> activities casually (without actively looking for it) wouldn't exist anymore
> then I believe.

That's a reason to either keep the bots in #mediawiki or not. Moving them to a separate discussion channel solves nothing.

> Besides, what about the channels for operations, visualeditor, parsoid,
> mobile.
> They all have bots related to their activities, because it makes sense to
> have it in the same channel so you're exposed to each others activities and
> can jump into things when they come by. Separating it out is
> counter-intuitive.

What about them? You're the one conflating gerrit-wm and wikibugs and then complaining about the two being conflated. wikibugs is only in #mediawiki and was the subject of its own discussion before you created this bug. gerrit-wm is in multiple channels already and serves a different purpose from wikibugs.
(In reply to comment #2)
> I don't think #wikimedia-dev should exist.
> Moving MediaWiki development bots to a Wikimedia channel is pretty wrong.
> 

#wikimedia-dev is not Wikimedia deployment specific development. It is development of software used by Wikimedia, which all of MediaWiki is obviously part of at least as long as either MediaWiki is a Wikimedia Foundation project and Wikipedia.org runs on MediaWiki. Regardless of whether our staff maintains it or not.

#wikimedia-dev should exist by all means, it isn't specific but broad. Perhaps too broad, but that's why we have specific channels for teams that prefer their own area:
- operations, visualeditor, parsoid, mobile, i18n.

A #mediawiki-dev could exist leaving #wikimedia-dev with only non-MediaWiki related dev stuff, but that would be rather narrow. There is no justification to split it up right now I think. It isn't too crowded and splitting it up would go at the cost of more decentralisation and less integrated communication.

> I'd much prefer #mediawiki-feeds.

For what reason? Because you don't want to see it in channels that you're in?

In that case we move it out of channels not meant for developers only (#mediawiki) and into #wikimedia-dev where it is reasonable to ask you to use /ignore if you don't like it.

If you do find them useful, then how are they useful in a separate channel? You'd have to manually check up there to see for anything. I don't think that works well in practice. The whole idea of being exposed to other people's activities casually (without actively looking for it) wouldn't exist anymore then I believe.

Besides, what about the channels for operations, visualeditor, parsoid, mobile. They all have bots related to their activities, because it makes sense to have it in the same channel so you're exposed to each others activities and can jump into things when they come by. Separating it out is counter-intuitive.
I don't think #wikimedia-dev should exist.

Moving MediaWiki development bots to a Wikimedia channel is pretty wrong. I'd much prefer #mediawiki-feeds.
wikibugs has gone missing from #mediawiki.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**URL**: https://www.mediawiki.org/wiki/Git/IRC
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=28402
(In reply to comment #31)
> @Nemo, this bug is about wikibugs. Though some related change has been
> merged,
> wikibugs is not yet run from puppet so that change is irrelevant until that
> is
> activated.

Current status is also discussed in https://gerrit.wikimedia.org/r/#/c/54984
As this came up in the IRC office hour today, wondering whether to go via an RFC for this.
(In reply to comment #39)
> Whose blood do I sacrifice to have this happen?

How about this, instead:

(In reply to comment #21)
> We could schedule an IRC meeting, announce it ia wikitech-l mailing list, and
> tally votes/opinions on a wiki page.
(In reply to comment #40)
> Chad's?

No, not me. I tried to move it out of #mediawiki, but people yelled at me. I don't care about this bot anymore.

Removing myself from CC.
Chad's?
Whose blood do I sacrifice to have this happen?
(Updating summary to make it easier to search this bug)
Sooo... it's still in #mediawiki, and not in #wikimedia-dev. Does it need additional poking?

[Personally I prefer the bots in #mediawiki, but it sounds like I've lost this fight. :)]
sorry, one last time
..
test - wikibugs bot, please report in new channel, after having to kill concurrent bot instances started by old script
moved to #wikimedia-dev
(In reply to comment #31)
> @Nemo, this bug is about wikibugs. Though some related change has been
> merged, wikibugs is not yet run from puppet so that change is irrelevant
> until that is activated. wikibugs is still in #mediawiki. Reopening.

At the time the bug was closed, #mediawiki was blessèdly-free of bots. :-)
@Nemo, this bug is about wikibugs. Though some related change has been merged, wikibugs is not yet run from puppet so that change is irrelevant until that is activated. wikibugs is still in #mediawiki. Reopening.
https://gerrit.wikimedia.org/r/#/c/57752/ , https://gerrit.wikimedia.org/r/#/c/57753/ merged.

00.31 -!- gerrit-wm [~gerrit-wm@manganese.wikimedia.org] has quit [Remote host closed the connection]
00.32 < mutante> bot is moving per merged changes
00.32 < James_F> Yup. :-)
00.32 < James_F> (Yay.)

(CEST)
Note that wikibugs is now 30 % less chatty, as bug 28402 was fixed (bug 28402 comment 8). It would maybe deserve a second chance. :)
Related URL: https://gerrit.wikimedia.org/r/58661 (Gerrit Change I588f2eba8fba9603f33386e54e90c03e2bb5f5f0)
Ori submitted I10a02bfe to get this done when there is approval.
What about moving them to #wikimedia-dev instead of #mediawiki?

I think most (actively involved) developers that are on IRC aren't disturbed by the feed. If they really must they're experienced enough to not be afraid of a simple /ignore.

Though I speak only for myself, I believe those that do want the feed, would prefer it to be in context of regular conversation, not in a separate channel.

It's where random bits of interesting things come by from (e.g. discussing a change, proposing and and then someone does it or files a bug about it).

It doesn't work when in a separate channel.

See also #mediawiki-parsoid, #mediawiki-visualeditor, #wikimedia-operations, #wikimedia-mobile etc. (and same for third parties such as #jquery-dev and webkit).

The problem is mainly with #mediawiki being a support channel instead of dev channel, not with having notifications in a human-occupied irc channel in general.
de duping title, These are two issues that really should be discussed separately.
*** Bug 46282 has been marked as a duplicate of this bug. ***
(In reply to comment #22)
> Right
> now, wikibugs is reporting CC changes, when it used to not report those.

This is what I just linked: bug 28402 aka bug 43130, which has a patch that someone needs to commit/review.
(In reply to comment #18)
> That's not a valid reason, imho. We need a way to tone down what it reports,
> if it's going to stay...the rate of bug reporting & commenting is many times
> greater than it once was. It's definitely gotten noisier over the years,
> which has reduced its utility.

I believe I already said as much somewhere around here, but wikibugs _is_ producing more noise lately, as it was broken by the recent Bugzilla upgrade and nobody has fixed it (or deployed the fixes to it, I can't remember). Right now, wikibugs is reporting CC changes, when it used to not report those.
We could schedule an IRC meeting, announce it ia wikitech-l mailing list, and tally votes/opinions on a wiki page.
Could we move this debate to its target audience somehow, as I'm afraid that it won't be seen in this Bugzilla report? 
I understand that's hard for IRC, but maybe a generic mailing list or RFC?
(In reply to comment #18)
> That's not a valid reason, imho. We need a way to tone down what it reports,
> if
> it's going to stay...the rate of bug reporting & commenting is many times
> greater than it once was. It's definitely gotten noisier over the years,
> which
> has reduced its utility.

Reduced it's utility -> in the main support channel. The bot *is* useful, I just think it drowns out conversation these days.
That's not a valid reason, imho. We need a way to tone down what it reports, if it's going to stay...the rate of bug reporting & commenting is many times greater than it once was. It's definitely gotten noisier over the years, which has reduced its utility.
Bumping importance back down; wikibugs belongs on #mediawiki as it's always been. Recommend WONTFIX.
Upping priority, adjusting summary, reopening.
I've created bug 46282 about kicking gerrit-wm instead, per myself & p858snake.
(In reply to comment #13)
> wikibugs appears to be in #mediawiki right now and is happily reporting bug
> updates...

This required me unquieting and unbanning the bot and Tim re-adding the bot to the channel.

(In reply to comment #9)
> Moving it's easier said than done, since it's not puppetized properly, but
> that can be worked around.

It's pretty easy. You change "mediawiki" to something else (e.g., "mediawiki-feeds").

> Long term--wouldn't improvements to wm-bot be a good idea too?

Absolutely. In the short-to-medium term, STOP KICKING THE BOT ON A WHIM.
wikibugs appears to be in #mediawiki right now and is happily reporting bug updates...
(In reply to comment #11)
> (In reply to comment #7)
> > Hashar kicked it yesterday... Adding hashar to CC.
> 
> I have not kicked wikibugs out of any IRC channel. Additionally, I have ZERO
> interest in wikibugs nowadays nor am I able to do anything about it. Sorry.

Ah it was ^demon. Sorry for my bad memory.
(In reply to comment #7)
> Hashar kicked it yesterday... Adding hashar to CC.

I have not kicked wikibugs out of any IRC channel. Additionally, I have ZERO interest in wikibugs nowadays nor am I able to do anything about it. Sorry.
(In reply to comment #8)
> If we kick any single bot, Gerrit produces a-lot more cruft lately than
> wikibugs... I, as having pointed out would prefer them all in a separate
> channel that is moderated and only the bots are voiced.

This. wikibugs is useful, it tends to notify about semi-interesting things that are happening (unless it notifies that someone CC'd himself on something, but that's another bug).

gerrit-wm tends to spam about changes being merged to wmf branches.
(In reply to comment #6)
> (In reply to comment #5)
> Lets move it into #mediawiki-feed or another channel then. It provides a
> better
> service than wm-bot does (comment 1), and people find it useful. If the
> specific channel that it's in is a problem, move the bot, don't just kill it.

Moving it's easier said than done, since it's not puppetized properly, but that can be worked around.

Long term--wouldn't improvements to wm-bot be a good idea too?
Lets take this the mailing list again...

(But my two cents)
If we kick any single bot, Gerrit produces a-lot more cruft lately than wikibugs... I, as having pointed out would prefer them all in a separate channel that is moderated and only the bots are voiced.
Hashar kicked it yesterday... Adding hashar to CC.
(In reply to comment #5)
 
> We've had *contributors* complaining about the bot(s) for the past couple of
> months/years.

So then lets fix the problem, not just shut off a service people find useful.
> 
> I really don't think two/three people saying "I LIKE THE BOT IN #MEDIAWIKI SO
> LEAVE IT THE HELL ALONE" trumps the wider problems here...that the bot
> *needs*
> to go.

Lets move it into #mediawiki-feed or another channel then. It provides a better service than wm-bot does (comment 1), and people find it useful. If the specific channel that it's in is a problem, move the bot, don't just kill it.
We actively had a user saying "This channel obviously isn't for support...two pages of scrollback and I've spotted 2 real people." This is a bad thing, contrary to what you may think.

We've had *contributors* complaining about the bot(s) for the past couple of months/years.

I really don't think two/three people saying "I LIKE THE BOT IN #MEDIAWIKI SO LEAVE IT THE HELL ALONE" trumps the wider problems here...that the bot *needs* to go.
*** Bug 46139 has been marked as a duplicate of this bug. ***
15 04:19:44 -!- wikibugs [~wikibugs@mchenry.wikimedia.org] has joined #mediawiki
15 04:03:39 < Susan> Can someone please take a look at <https://bugzilla.wikimedia.org/show_bug.cgi?id=46144>?
15 04:16:04 < jeremyb_> Susan: i did
15 04:16:18 < Susan> Helpful.
15 04:16:19 < jeremyb_> (a while ago)
15 04:16:29 < jeremyb_> Susan: it was kicked. people didn't like the spamming
15 04:16:37 < Susan> I don't like people.
15 04:16:39 < Susan> I think we're even.
15 04:16:41 < jeremyb_> there was a user trying to get help and had trouble because of the flood
15 04:16:52 < jeremyb_> (wasn't my decision i only saw the scrollback)
15 04:17:03 < jeremyb_> Susan: anyway, there's #mediawiki-feed for now
15 04:17:10 < Susan> It's a terrible replacement.
15 04:17:15 < Susan> As it's missing wikibugs.
15 04:17:28 < jeremyb_> it has wm-bot providing a similar service
15 04:17:31 < jeremyb_> i witnessed it
15 04:17:50 < jeremyb_> and you've been there too
15 04:18:34 < jeremyb_> Susan: at some point we should either let it back into #mediawiki or configure it to not join (and remove the ban). also we could maybe get wikibugs to join #mediawiki-feed if you really care
15 04:18:48 < Susan> I do really care.
wm-bot in #mediawiki-feed is not an acceptable replacement for wikibugs.

For example, Quim added a comment here: bug 35508 comment 14.

wm-bot reported this:

<wm-bot> [bugzilla] (--- - created by: Sumana Harihareswara | priority: enhancement - Normal assignee Chad H.) [Bug 35508] List of Gerrit users - https://bugzilla.wikimedia.org/show_bug.cgi?id=35508

I realize that this is a limitation of Bugzilla's RSS feed, but the output is still almost useless.
This is kind of a ridiculous case, but it cost me an hour of debugging time, so documenting it here for posterity. It won't be a practical issue until we start composing transactions together.

Consider:

var data = ve.dm.example.withMeta,
    oldDoc = new ve.dm.Document( ve.copyArray( data ) ),
    newDoc = new ve.dm.Document( ve.copyArray( data ) ),
    tx = new ve.dm.Transaction();
tx.pushRetain( 11 );
tx.pushReplaceMetadata( [], [ { metadata element here } ] );
tx.pushReplace( [] , [ 'a', 'b', 'c' ] );
ve.dm.TransactionProcessor.commit( newDoc, tx );
ve.dm.TransactionProcessor.rollback( newDoc, tx );

After running this, you'd expect oldDoc.metadata and newDoc.metadata to be equal, but they're not:

> oldDoc.metadata[11].length;
4
> newDoc.metadata[11].length;
5

When the transaction is rolled back, the metadata element that was added was never removed. I think this is because the content insertion pushes the metadata back, and then when the rollback tries to remove the metadata again, it can't find it. When the metadata replacement and content replacement are swapped, it works fine, so that's my workaround for now.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Trevor complained the naming of these things doesn't make sense, so let's sit down and come up with a strategy for renaming this stuff at some point.
TODO comment in ve.dm.Converter.test.js:

// TODO: this is a hack to make normal heading/preformatted
// nodes the most recently registered, instead of the MW versions

It's not entirely clear to me how we should fix this. Maybe once we hard-split the VE and MWVE code bases and each of these has its own test suite, then we won't have to worry about this as much.

--------------------------
**Version**: unspecified
**Severity**: normal
This was fixed in gerrit 70753.
When the Parsoid server is down completely (e.g. because you forgot to start it), the error message VE gives you is "parsoidserver-http-200". It's kind of ridiculous that it's presenting an error with 200, but it's also a lie: 200 wasn't the response code we got from Parsoid, we got no response whatsoever.

--------------------------
**Version**: unspecified
**Severity**: normal
https://gerrit.wikimedia.org/r/#/c/53165/
DM nodes have a static name property which is used by the nodeRegistry. CE nodes currently have their names written out at least twice. It also creates unnecessary complexity when inheriting CE nodes as the parent constructor cannot be used (as it contains the parent's name hard coded).

--------------------------
**Version**: unspecified
**Severity**: normal
Related URL: https://gerrit.wikimedia.org/r/52545 (Gerrit Patch-Set: Ibf31de16ab28ad58209c1443cd74f93dda278998/7)
Fixed with https://gerrit.wikimedia.org/r/#/c/52545/
Functions like runConverterTests() and what not are often global functions in the test file. These should be un-global-ified somehow.
Found a few:

- ve.dm.ModelRegistry.test
* function checkForPickMe

- ve.dm.Transaction.test
* function runBuilderTests
* function runConstructorTests
I can't find these any more. Resolved?
The hallmark of chainability in VE, dm.SurfaceFragment, doesn't actually use @chainable to document the chainability of most of its methods.

--------------------------
**Version**: unspecified
**Severity**: normal
Change-Id: Ib950422ddb78d7b91545399a6053e82ae2dbd932
ve.dm.Transaction.newFromWrap() currently doesn't check that the transaction it generates will be valid. That is, it will ensure that things are unwrapped correctly, but it doesn't check that the result doesn't end up violating parent/child restrictions.

It's not entirely clear to me whether we should try to rectify that or throw an exception, but either of those is better than generating a transaction that, when applied, will make the document nonconformant.

--------------------------
**Version**: unspecified
**Severity**: enhancement
When a user saves a page, VE should check for references (<ref>s) created without the de-referencing block (<references /> or {{reflist}} or...) and intervene:

* prompt them to fix before saving (out of the notices area?);
* refuse to save before fixed (grey out the save button?); or
* auto-fix for them (insert a "== References ==\n<references />" section just above the categories), though this (a) sucks, (b) enforces a particular wiki's style on other wikis in code, and (c) would be difficult to internationalise

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=54906
https://bugzilla.wikimedia.org/show_bug.cgi?id=51260
This probably doesn't really matter any more, since the absence of a references template will simply cause the references to display at the end of the page.
The last thing I want us to be doing is adding more error messages. I really think that we can get away with actually fixing the error for people. 

I'd rather see us put it in the wrong place and someone have to fix it than us give the user an error they probably don't know how to fix. 

Can we do a quick audit of major sites and where they put the reference list? I worry we're worrying a bit too much about about negative feedback that might not be as big a deal as we might think.
(In reply to comment #4)
> The auto-fix option in comment 0 has been requested today by en.wp user
> Mahitgar. If the issues noted can be overcome, then it would be the most
> user-friendly way forward.
> 
> Regarding those issues, it is not obvious why this "sucks" - please could you
> elucidate?
> 
> Internationalisation of the section title could (I guess easily) be achieved
> by
> inserting the contents of a MediaWiki page instead of something defined in
> code. e.g. the equivalent of
> 
> ==={{subst:MediaWiki:Refsection title}}===
> <{{subst:MediaWiki:Reflist function name}} />
> 
> 
> This doesn't solve the option of imposing en.wp style on other wikis though.

Blindly putting the references section at the end of the article seems to not be great (it'd be after the "external links" and "see also" sections, and after any stub or thematic templates).
The auto-fix option in comment 0 has been requested today by en.wp user Mahitgar. If the issues noted can be overcome, then it would be the most user-friendly way forward.

Regarding those issues, it is not obvious why this "sucks" - please could you elucidate?

Internationalisation of the section title could (I guess easily) be achieved by inserting the contents of a MediaWiki page instead of something defined in code. e.g. the equivalent of

==={{subst:MediaWiki:Refsection title}}===
<{{subst:MediaWiki:Reflist function name}} />


This doesn't solve the option of imposing en.wp style on other wikis though.
*** Bug 51910 has been marked as a duplicate of this bug. ***
Bug 50779 makes it easy to accidentally delete the references list, so this should check for its presence every save not just when references have been added.
Currently this would require scanning for the exact html it outputs as the <span style="color:red;">...</a> tag. Which can be tricky to do reliably.

Though the Cite extension could perhaps be the first to give their elements some kind of standard attribute for parse errors, it should probably do more like the TemplateData extension: Refuse to save without it and show a warning there instead. Then the API will return to VE with a nice { error: .. } block containing a error code which we can use to fetch a localised message.
Using a more extensive default $linkTrail regex was tried in 416c84480 (although I don't know why it used `\p{L&}` rather than `[[:alpha:]]` or `\p{L}`), but this was reverted in 5b97a5bb due to {T17035}. We could probably try that again (without the apostrophe, see T16655) now that we require a more modern version of PHP with a more modern version of PCRE. It may not work correctly for alphabets other than Latin.

----

Please have a look at 
https://www.wikidata.org/wiki/MediaWiki:Gadget-rightsfilter/hu
where the link has the form [[:hu:Reguláris kifejezés|regex]]alapú
and "ú" is not linked.
This is a multilingual project, so all letters should be included into links, or at least all Hungarian letters. :-)
>>! In T47126#2509560, @Verdy_p wrote:
> link trails are just a minor facility for **lazy** English contributors using the Wiki code editor.

Those links can be used in many languages. In German Wikipedia they are used exceedingly!
Hungarian was cited because the current conservative linktrail rules break Hungarian words. `\p{L}` or `\p{L&}` would work well for Hungarian (I imagine the latter was used to avoid affecting CJK languages; no idea how well that works). Even `\p{Latin}` would be fine.
For years it was corrected in the other direction. It would be mad to change this now.
I don't think that "cleanup" operations such as automated replacement of [[Dog|dogs]] to [[dog]]s are useful. In fact they are counterproductive (and in fact unnecessary for the Visual Editor that should completely avoid using these link trails).

My opinion is we **should deprecate** these old link trails and in fact correct the other ways (link trails are just a minor facility for **lazy** English contributors using the Wiki code editor.

In fact, even the Wiki editor should better automatically convert these trails (only [a-z]) to regular links without them. It would also simplify the parsers for bots and analysers. Contributors should always use regular links, that are in fact more readable, and more explicit about the effective range of text covered by links.
I don't think that "cleanup" operations such as automated replacement of [[Dog|dogs]] to [[dog]]s are useful. In fact they are counterproductive (and in fact unnecessary for the Visual Editor that should completely avoid using these link trails).

My opinion is we **should deprecate** these old link trails and in fact correct the other ways (link trails are just a minor facility for **lazy** editors using the Wiki code editor.

In fact, even the Wiki editor should better automatically convert these trails (only [a-z]) to regular links without them. It would also simplify the parsers for bots and analysers. Contributors should always use regular links, that are in fact more readable, and more explicit about the effective range of text covered by links.
I can say that link trails work well in Polish, which has fairly complex conjugation and declension rules. I'd make a wild guess that it works in around 50% of cases (in English it's more like 99%, as you say). There is a very popular gadget on Polish Wikimedia projects that applies wikitext code cleanup, and one of the cleanups it does is converting things like `[[Dog|dogs]]` to `[[dog]]s`. I would be very sad if we wanted to get rid of them.
I can say that link trails work well in Polish, which has fairly complex conjugation and declension rules. I'd make a wild guess that it works in around 50% of cases (in English it's more like 99%, as you say). There is a very popular gadget that applies wikitext code cleanup, and one of the cleanups it does is converting things like `[[Dog|dogs]]` to `[[dog]]s`. I would be very sad if we wanted to get rid of them.
Note als othat a few languages written in the Latin script also use "agglutination" for creating very long custom "words" by using many prefixes/inffixes/suffixes (and often some internal mutations). Such extension may break for example in Finnish or Hungarian (Hungarian was cited at top of this bug).

Any way I don't think that link trails are a very good idea: users can't control it easily (and should not have to include some arbitrarty separation toklen such as "nowiki/>" to limit these trails. Link trails were added only for lazy English writers that want to create links to a singural noun, by placing the final "s" of the displayed plural in the trail, or for placing some common suffixes ("ed", "s") of conjugated verbs (but it does not work when there are more complex mutations such as "*y -> *ies").

This concept of link trails does not even exist in HTML. And anyway with the Visual Editor, we much less need it now as it is simpler to edit links separately of their visible text content.
> Such link trails should contain only letters or digits in the same script as the last string script used within the inner text of the link and only if that script is alphabetic or an abjad, but probably not Indic abugidas and not any sinographic script (a good question is: can we extend some kanas after a kanji in the inner text of the link (I don't think so), but we can probably extend runs of kanas.

There are some rules for semi-sensible word breaking in CJK languages. VisualEditor implements some of them to be able to e.g. extend selection to the word around cursor when inserting an internal link. I'm not sure if they're simple enough to implement as a regexp; @dchan can probably advise.
In my opinion [[:alpha:]] or \p{L} would be wrong for Chinese and Thai at least ! they would produice overlong links sticked side by side everywhere and covering most contents in all paragraphs. In Wikipedia, almost all the text of paragraphs would be blue except the start of paragraphs without significant words.

Such link trails should contain only letters or digits in the same script as the last string script used within the inner text of the link and only if that script is alphabetic or an abjad, but probably not Indic abugidas and not any sinographic script (a good question is: can we extend some kanas after a kanji in the inner text of the link (I don't think so), but we can probably extend runs of kanas.

The Unicode rule of matching identifiers is not usable for this (we are not in the context of a programminc language but within a context of use by a natural language, so the punctuation/spacing rules are very different).

If we want a regexp, for now let's focus only in Latin, Greek, Cyrillic, Arabic, Hebrew, and possibly Hangul, breaking the run if there's any change of script (but not if these are "weak" digits belonging to all scripts). Extending the regexp for other scripts should be tested first (the hint here is to look at existing rules existing in CLDR for *word breakers* and look at the Unicode standard covering this complex aspect. And may be include also the line breakers to restrict more the link trails to get shorter runs.

However this should not be very language specific: it should better be script-specific.
Historical note: Using a more extensive regex was tried in 416c84480 (although I don't know why it used `\p{L&}` rather than `[[:alpha:]]` or `\p{L}`), but this was reverted in 5b97a5bb due to {T17035}. We could probably try that again (without the apostrophe, see T16655) now that we require a more modern version of PHP with a more modern version of PCRE.
"Is this strange behaviour something we want to preserve, or is it just a historical quirk?"
Or just survived tests, as a rare case.
Essentially I think the linktrail for `en` should include all Latin-alphabet characters in the regex. Would `/^(\p{Latin}+)(.*)$/` work?

Although, oddly enough, most uppercase letters are left out of the linktrails. For the Hungarian example above, only accented uppercase letters are matched, not regular ones. Most languages don't include any uppercase letters in their linktrail  string. Is this strange behaviour something we want to preserve, or is it just a historical quirk?
No, this is a perfectly valid bug. Unfortunately "link trails" are currently specified per-language, and the link trail for English doesn't include any accented characters. For example it's defined like this for Hungarian: `$linkTrail = '/^([a-záéíóúöüőűÁÉÍÓÚÖÜŐŰ]+)(.*)$/sDu';`, but these characters will only work on a Hungarian-language wiki.
OK. Thanks for the detailed explanation.
This seems to be problem on all multilingual projects...
It could also be that the content language is still English in some cases, but it doesn't seems so form the content source.
This is link trails and it is part of the localization that would be very difficult to get right for everyone. In this case I would say put what you want to use for the page part into the link and do not depend on the link trails.
This test works in Chrome, but in Firefox it fails with:

Expected: 	

"a<b>b<span typeof=\"mw:Entity\" class=\"ve-ce-leafNode ve-ce-MWEntityNode\" contenteditable=\"false\">c</span>d<div class=\"ve-ce-leafNode ve-ce-alienNode ve-ce-alienInlineNode\" contenteditable=\"false\"><tt>e</tt></div></b>"

Result: 	

"a<b>b<span class=\"ve-ce-leafNode ve-ce-MWEntityNode\" typeof=\"mw:Entity\" contenteditable=\"false\">c</span>d<div class=\"ve-ce-leafNode ve-ce-alienNode ve-ce-alienInlineNode\" contenteditable=\"false\"><tt>e</tt></div></b>"

(the difference is in the order of the class and typeof attributes)

We should probably implement DOM comparison instead of string comparison in the ce.ContentBranchNode test suite.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Related: https://gerrit.wikimedia.org/r/#/c/240722/ in MW, where we need to decode data-mw and parse body.html, sometimes recursively :/
https://gerrit.wikimedia.org/r/#/c/240693/
This specific case is fixed in https://gerrit.wikimedia.org/r/#/c/57240 by using equalDomElement. However, another case has appeared: recent code introduced full HTML preservation in mw:Image and the attribute order in the HTML serialization matters there too, so now that test passes in Chrome but fails in Firefox (getDataFromDom test 4).
Not sure if it is caused by the javasript object keys. May be related to how WebKit/Geck order the element attributes when serialising the html.

If the former:
 ve.getHash or assert.deepEqual

If the latter:
 assert.equalDomElement
Should perhaps have some kind of magic alias "trigger" that maps to meta/ctrl respectively.

The flexibility of being able to bind something to ctrl on mac, and to meta on pc is useful but in the most common case we don't to do that.

And we're currently duplicating this internal logic at the cost of decentralisation. So plugin authors providing Tools need to duplicate this logic also, meaning more maintenance when we change this.

--------------------------
**Version**: unspecified
**Severity**: enhancement
The GettingStarted extension is tagging edits of new users (bug 43191). These tags should be temporary.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**swalling** wrote:

https://gerrit.wikimedia.org/r/#/c/65337/ was merged, and henceforth only users who aren't autoconfirmed will get their GettingStarted edits tagged.
Related URL: https://gerrit.wikimedia.org/r/65337 (Gerrit Change I3bc2235ac9d5ae1060c86df03663dcb8a6966a38)
(In reply to comment #4)
> It sounds like you have a general problem with permanent tags. 

It sounds like you didn't read comment 3.
**swalling** wrote:

(In reply to comment #3)
> The general trend of permanently tagging edits should be examined. Other
> sites
> engage in similar practices (such as Facebook marking mobile posts), but
> whether this is a good thing or whether it should be encouraged is up for
> debate.
> 
> In this case, I don't think permanently marking someone's first edits after
> you've secretly tagged them as part of an experiment that they didn't opt in
> to
> is a good idea. Do other bad tags exist? Yes, but those aren't really
> relevant
> here.

It sounds like you have a general problem with permanent tags. 

I think our actual enhancement is to not tag edits of users who aren't new anymore if they make further edits via Special:GettingStarted, e.g. if you're autoconfirmed don't tag their edit, even if if comes via GettingStarted. That's an enhacement we should make, but it's not the same thing as altering MediaWiki tags so they're there one minute and gone the next. That's unexpected and broken behavior according to how tags currently work in all other cases. 

I've changed the bug title to reflect what we're actually going to do around tagging in GettingStarted, to ensure that the tag is accurate.
The general trend of permanently tagging edits should be examined. Other sites engage in similar practices (such as Facebook marking mobile posts), but whether this is a good thing or whether it should be encouraged is up for debate.

In this case, I don't think permanently marking someone's first edits after you've secretly tagged them as part of an experiment that they didn't opt in to is a good idea. Do other bad tags exist? Yes, but those aren't really relevant here.
This proposal is a specific case of https://bugzilla.wikimedia.org/show_bug.cgi?id=18670 .
I'm not yet convinced this is a problem.  There are a variety of permanent tags (edit filter, VisualEditor, etc.).  In all cases, it's a good-faith tag of the edit.

Edit filter tags are permanent, even though they sometimes wrongly flag an edit as harmful.  It's just understood that the situation will be cleared up, and editors will move on.

Similarly, the fact that a user made a Special:GettingStarted edit doesn't even mean they're necessarily new.  It's understood and accepted that established users can also have this tag on their edits if they use the page.

It indicates how they made it.  It certainly is not a marker of whether the edit is productive.  And it doesn't really say anything about the user, let alone the user's future work.
I encountered many times now on wikis (usually the small wikis) that there are 100s of local MediaWiki pages with translations from before translatewiki.net covered that language.

And even after twn covered it, there may have been local improvements that over time make it into twn, but then the local page stales.

To avoid translations from going out of sync (the longer we wait with this, the harder it is to clean them up as the difference between an override and an outdated translation becomes harder to tell), and also to avoid migration issues when messages change.

Lets run this asap.

--------------------------
//EDIT//: deleteEqualMessages.php has been completed on the following wikis:
{P1988}
{nav icon=file, name=Mentioned in SAL (#wikimedia-operations), href=https://tools.wmflabs.org/sal/log/AVsHFYbVlCyyDMEPvX-7} [2017-03-25T20:08:22Z] <Krinkle> Ran mwscript deleteEqualMessages.php on public wikis (T45917) - deleted 5 pages across 5 wikis
{nav icon=file, name=Mentioned in SAL (#wikimedia-operations), href=https://tools.wmflabs.org/sal/log/AVruLkTylCyyDMEPvWIy} [2017-03-21T00:04:54Z] <Krinkle> mwscript deleteEqualMessages.php on public wikis (T45917)
> if dry run, where to publish it. (https://people.wikimedia.org/~krinkle/ maybe?)

That would be ok. On the other hand, this list already proves that LocalisationUpdate is needed and must be faster, to avoid accumulating translator frustration and unnecessary technical debt (see ruwiki example: https://ru.wikipedia.org/w/index.php?title=MediaWiki%3ACreate-local&type=revision&diff=84144899&oldid=84144800 https://translatewiki.net/w/i.php?title=MediaWiki%3ACreate-local%2Fru&type=revision&diff=7293894&oldid=5453967 ).
>>! In T45917#3083285, @Nemo_bis wrote:
> So if anything we should have a cronjob with a dry run, which triggers an alert somewhere when messages get translated locally. It could be one useful signal of an insufficient frequency of localisation updates, due to broken LocalisationUpdate or other reasons. (In general, we already know that the updates must be daily; but contingent data points are still useful.)

This.

I regularly check Special:AllMessages //in languages that I know//. I wish it was done in all languages, but I alone don't have the capacity to do it manually. I very frequently find not only translation mistakes, but also reasons to fix the original English message, and of course this happens not only when the local customization is the same as the original message, but also when it's different.

It's good to have local translation in the MediaWiki space as a quick fix for particularly bad translation mistakes, or for actually-needed local customizations, but it must not be relied upon as a an actual way to translate the interface, even temporarily. (And even though I'm saying "actually-needed local customization", these should actually always raise the question of whether this thing should be done through a message at all, but that's a separate topic.)
So if anything we should have a cronjob with a dry run, which triggers an alert somewhere when messages get translated locally. It could be one useful signal of an insufficient frequency of localisation updates, due to broken LocalisationUpdate or other reasons. (In general, we already know that the updates must be daily; but contingent data points are still useful.)
That's what I'm saying. The usual reason people were editing the messages was because LU was broken, or there was a long time between deploys.

I'm not even suggesting we encourage people to edit the MW namespace like that
I agree with @nemo_bis why force people to do something they dont want to, especially if we have the ability to do it ourselves.
> People that don't want to wait for train deploys and/or LocalisationUpdate?

Forcing such people to edit the MediaWiki namespace would be a broken system.
>>! In T45917#3081939, @Nemo_bis wrote:
>> Any reason we can't cronjob it, say monthly?
> 
> This is supposed not to be a recurring task on each wiki: if it's needed regularly, then something is wrong.

People that don't want to wait for train deploys and/or LocalisationUpdate?
> Any reason we can't cronjob it, say monthly?

This is supposed not to be a recurring task on each wiki: if it's needed regularly, then something is wrong.
It'd be interesting to see the scale of this in relation to T158360...

Any reason we can't cronjob it, say monthly?
@MarcoAurelio Thanks. Yeah, my thoughts exactly. This should be re-run from time to time as upstreaming happens all the time.

Meanwhile, as always, feel free to ask here or on IRC for a run on a specific wiki (or set of wikis).
@MarcoAurelio Thanks. Yeah, my thoughts exactly. This should be re-run from time to time as upstreaming happens all the time.

Meanwhile, as always, feel free to ask here on IRC for a run on a specific wiki (or set of wikis).
@MarcoAurelio Thanks. Yeah, my thoughts exactly. This should be re-run from time to time as upstreaming happens all the time.
We should do this once or twice a year. Nice job, thanks.
{nav icon=file, name=Mentioned in SAL (#wikimedia-operations), href=https://tools.wmflabs.org/sal/log/AVqnN6AAHQCSeVEJfRZs} [2017-03-07T05:22:04Z] <Krinkle> foreachwikiindblist 'all - closed - private' deleteEqualMessages.php (T45917) - purge upstreamed translations from remaining wikis
{nav icon=file, name=Mentioned in SAL (#wikimedia-operations), href=https://tools.wmflabs.org/sal/log/AVqm0BIAlCyyDMEPvRe-} [2017-03-07T03:28:58Z] <Krinkle> foreachwikiindblist closed deleteEqualMessages.php (T45917) - purge upstreamed translations from closed wikis
{nav icon=file, name=Mentioned in SAL (#wikimedia-operations), href=https://tools.wmflabs.org/sal/log/AVpoVYifQMK9DA-FKjFz} [2017-02-23T00:18:40Z] <Krinkle> mwscript deleteEqualMessages.php --wiki simplewikibooks (T45917)
{nav icon=file, name=Mentioned in SAL (#wikimedia-operations), href=https://tools.wmflabs.org/sal/log/AVnODfVMHQCSeVEJfEH0} [2017-01-24T01:18:58Z] <Krinkle> mwscript deleteEqualMessages.php --wiki gotwiki (T45917)
@Krinkle: Maybe https://meta.wikimedia.org/wiki/Steward_requests/Miscellaneous#All_local_mediawiki_messages_on_got.wikipedia.org_should_be_deleted is of interest here. Thanks.
{nav icon=file, name=Mentioned in SAL (#wikimedia-operations), href=https://tools.wmflabs.org/sal/log/AVlreqFoHQCSeVEJe_Xe} [2017-01-04T21:55:15Z] <Krinkle> mwscript deleteEqualMessages.php --wiki nowikinews (T45917)
{nav icon=file, name=Mentioned in SAL (#wikimedia-operations), href=https://tools.wmflabs.org/sal/log/AVlreoZdHQCSeVEJe_Xd} [2017-01-04T21:55:08Z] <Krinkle> mwscript deleteEqualMessages.php --wiki nowiki (T45917)
>>! In T45917#2822892, @MarcoAurelio wrote:
> Can angwiki be run next? Thanks.

:white_check_mark: Done!
>>! In T45917#2822892, @MarcoAurelio wrote:
> Can angwiki be run next? Thanks.

Done :)
{nav icon=file, name=Mentioned in SAL (#wikimedia-operations), href=https://tools.wmflabs.org/sal/log/AVidG31FHQCSeVEJeyWR} [2016-11-25T20:09:34Z] <Krinkle> mwscript deleteEqualMessages.php --wiki angwiki (T45917)
Can angwiki be run next? Thanks.
{nav icon=file, name=Mentioned in SAL (#wikimedia-operations), href=https://tools.wmflabs.org/sal/log/AVhFB-pNQMK9DA-FJhuN} [2016-11-08T17:41:36Z] <Krinkle> mwscript --deleteEqualMessages.php --wiki ptwikinews (T45917)
{nav icon=file, name=Mentioned in SAL (#wikimedia-operations), href=https://tools.wmflabs.org/sal/log/AVhEvj7xQMK9DA-FJhrT} [2016-11-08T16:21:08Z] <Krinkle> mwscript --deleteEqualMessages.php --wiki kkwiki (T45917)
{nav icon=file, name=Mentioned in SAL (#wikimedia-operations), href=https://tools.wmflabs.org/sal/log/AVhBM2zgHQCSeVEJesuz} [2016-11-07T23:50:39Z] <Krinkle> mwscript --deleteEqualMessages.php --wiki jawikinews (T45917)
{nav icon=file, name=Mentioned in SAL (#wikimedia-operations), href=https://tools.wmflabs.org/sal/log/AVhBIxJ3HQCSeVEJesuW} [2016-11-07T23:32:47Z] <Krinkle> mwscript --deleteEqualMessages.php --wiki jawikibooks (T45917)
{nav icon=file, name=Mentioned in SAL (#wikimedia-operations), href=https://tools.wmflabs.org/sal/log/AVhBEtxkHQCSeVEJestw} [2016-11-07T23:15:04Z] <Krinkle> mwscript --deleteEqualMessages.php --wiki gawiktionary (T45917)
{nav icon=file, name=Mentioned in SAL (#wikimedia-operations), href=https://tools.wmflabs.org/sal/log/AVd9IhIcfIH_7EDsrdXG} [2016-09-30T22:06:07Z] <Krinkle> Re-run mwscript deleteEqualMessages.php on all wikis it was previously run on (T45917)
>>! In T45917#2570454, @MuhammadShuaib wrote:
> @Dereckson, Will you export for me urwiki mediawiki messeges which do not exist on translatewiki? I can help which messeges to be imported to translatewiki. 

Thanks, this is important work. :)
Here the list of messages to export:

{P3863}

You need to clean it: remove any Wikipedia or Wikimedia message.

The goal is to:
  - translate on wiki Wikimedia/Wikipedia messages
  - translate on TranslateWiki universal messages
@Dereckson, Will you export for me urwiki mediawiki messeges which do not exist on translatewiki? I can help which messeges to be imported to translatewiki.
{nav icon=file, name=Mentioned in SAL, href=https://tools.wmflabs.org/sal/log/AVatnr1JpirJUPGy-ySY} [2016-08-21T15:01:16Z] <Dereckson> Run deleteEqualMessages maintenance script on urwiki (T45917)
>>! In T45917#2570412, @Dereckson wrote:
> We can sorry :)

Thanks, Okay, I wish to delete those messeges which have same value on both wiki.
We can sorry :)
>>! In T45917#2570408, @Dereckson wrote:
> We can't start to delete messages with the same values on ur. and TranslateWiki if you wish.
> 
> That would delete 297 messages with the (identical) translation already on TranslateWiki.

You can't? :)
We can't start to delete messages with the same values on ur. and TranslateWiki if you wish.

That would delete 297 messages with the (identical) translation already on TranslateWiki.
We can't start to delete messages with the same values on ur. and TranslateWiki if you wish.

That would delete 297 messages.
We can't start to delete messages with the same values on ur. and TranslateWiki.
>>! In T45917#2570406, @Dereckson wrote:
> Yes but that's exactly the problem.
> 
> TranslateWiki manages the translation for EVERY wiki un Urdu (and you can set every installation of MediaWiki in Urdu just adding ?uselang=ur).
> 
> Wikimedia and Wikipedia specific translations should be done on wiki.
> 
> Universal translations should be done on TranslateWiki.
> 
> So yes, we can export translations from ur.wikipedia to import them to TranslateWiki, but there is a need to know what messages to import, what not.

In that case, Will you delete mediawiki: messeges on ur.wiki? Because now we are translating on translatewiki.
Yes but that's exactly the problem.

TranslateWiki manages the translation for EVERY wiki un Urdu (and you can set every installation of MediaWiki in Urdu just adding ?uselang=ur).

Wikimedia and Wikipedia specific translations should be done on wiki.

Universal translations should be done on TranslateWiki.

So yes, we can export translations from ur.wikipedia to import them to TranslateWiki, but there is a need to know what messages to import, what not.
>>! In T45917#2570356, @Dereckson wrote:
> The issue is how to sort them between Wikimedia-specific messages and universal messages for every wikis?

I want it for specific wiki, ur.wiki
The issue is how to sort them between Wikimedia-specific messages and universal messages for every wikis?
Is this possible to move mediawiki: namespace translations to translatewiki.net? Previously we had translated huge amount of mediawiki software strings locally. Some have been outdated but many of them are useful. And now we would like to continue translate on translatewiki.
{nav icon=file, name=Mentioned in SAL, href=https://tools.wmflabs.org/sal/log/AVafiUcdX4d8bmU7pfbN} [2016-08-18T21:23:09Z] <Dereckson> Run deleteEqualMessages maintenance script on eswikibooks, eswikiquote, eswikisource, eswiktionary and eswikiversity (T45917)
Done.

{P3852}
I'm handling the es part, then I'll reassign the task to Krinkle for review and closure.
Doing a quick check, I've encountered the same problems at the rest of Spanish language projects, as such I propose to run the script on:

* eswikibooks
* eswikiquote
* eswikisource
* eswiktionary
* eswikiversity

Thank you.
Requesting the script to be run on es.wikisource as per https://es.wikisource.org/w/index.php?title=Especial%3ATodosLosMensajes&prefix=&filter=modified&lang=es&limit=5000

Lots of local messages equal to the source in TWN.

Thank you!
{nav icon=file, name=Mentioned in SAL, href=https://tools.wmflabs.org/sal/log/AVUIBSXNgCrwkbTdmSYI} [2016-05-31T18:13:23Z] <Krinkle> mwscript deleteEqualMessages.php --wiki hrwikibooks (T45917)
{nav icon=file, name=Mentioned in SAL, href=https://tools.wmflabs.org/sal/log/AVUDAGmt1EdYBLP_75C3} [2016-05-30T18:50:06Z] <Krinkle> mwscript deleteEqualMessages.php --wiki nvwiki (T45917)
{nav icon=file, name=Mentioned in SAL, href=https://tools.wmflabs.org/sal/log/AVTknVjG1EdYBLP_72u_} [2016-05-24T21:13:17Z] <Krinkle>  mwscript deleteEqualMessages.php --wiki mrwiki (T45917)
{nav icon=file, name=Mentioned in SAL, href=https://tools.wmflabs.org/sal/log/AVTkYTJ_gCrwkbTdmPef} [2016-05-24T20:07:35Z] <Krinkle>  mwscript deleteEqualMessages.php --wiki diqwiki (T45917)
{nav icon=file, name=Mentioned in SAL, href=https://tools.wmflabs.org/sal/log/AVTkVf57sSQjJM_mrtuk} [2016-05-24T19:55:21Z] <Krinkle>  mwscript deleteEqualMessages.php --wiki cywiktionary (T45917)
{nav icon=file, name=Mentioned in SAL, href=https://tools.wmflabs.org/sal/log/AVTkTHRTgCrwkbTdmPdj} [2016-05-24T19:44:56Z] <Krinkle>  mwscript deleteEqualMessages.php --wiki warwiki (T45917)
{nav icon=file, name=Mentioned in SAL, href=https://tools.wmflabs.org/sal/log/AVTjg8HA1EdYBLP_72ig} [2016-05-24T16:05:43Z] <Krinkle>  mwscript deleteEqualMessages.php --wiki fiwikinews (T45917)
{nav icon=file, name=Mentioned in SAL, href=https://tools.wmflabs.org/sal/log/AVQM0ZS2D0x0K5Df_Smj} [2016-04-12T23:32:22Z] <Krinkle>  mwscript deleteEqualMessages.php --wiki elwiki (T45917)
{nav icon=file, name=Mentioned in SAL, href=https://tools.wmflabs.org/sal/log/AVQHoFN2gCrwkbTdl-Hq} [2016-04-11T23:20:28Z] <Krinkle> mwscript deleteEqualMessages.php --wiki idwiki (T45917)
{nav icon=file, name=Mentioned in SAL, href=https://tools.wmflabs.org/sal/log/AVQHmQ5I1EdYBLP_7mNA} [2016-04-11T23:12:31Z] <Krinkle> mwscript deleteEqualMessages.php --wiki zh_classicalwiki (T45917)
{nav icon=file, name=Mentioned in SAL, href=https://tools.wmflabs.org/sal/log/AVQHOvKAD0x0K5Df_R_k} [2016-04-11T21:29:44Z] <Krinkle> mwscript deleteEqualMessages.php --wiki bgwikiquote (T45917)
{nav icon=file, name=Mentioned in SAL, href=https://tools.wmflabs.org/sal/log/AVQHOuy9gCrwkbTdl-ET} [2016-04-11T21:29:42Z] <Krinkle> mwscript deleteEqualMessages.php --wiki frwikibooks (T45917)
{nav icon=file, name=Mentioned in SAL, href=https://tools.wmflabs.org/sal/log/AVQHDv3n1EdYBLP_7mIC} [2016-04-11T20:41:43Z] <Krinkle> mwscript deleteEqualMessages.php --wiki plwiki (T45917)
{nav icon=file, name=Mentioned in SAL, href=https://tools.wmflabs.org/sal/log/AVQDoTWOD0x0K5Df_RpN} [2016-04-11T04:42:57Z] <Krinkle> mwscript deleteEqualMessages.php --wiki shwiki (T45917)
{nav icon=file, name=Mentioned in SAL, href=https://tools.wmflabs.org/sal/log/AVQCZCaKD0x0K5Df_RoZ} [2016-04-10T22:56:38Z] <Krinkle> mwscript deleteEqualMessages.php --wiki srwiki (T45917)
{nav icon=file, name=Mentioned in SAL, href=https://tools.wmflabs.org/sal/log/AVQCP56LgCrwkbTdl9qq} [2016-04-10T22:16:44Z] <Krinkle> mwscript deleteEqualMessages.php --wiki yowiki (T45917)
{nav icon=file, name=Mentioned in SAL, href=https://tools.wmflabs.org/sal/log/AVQCLBWxgCrwkbTdl9qj} [2016-04-10T21:55:24Z] <Krinkle> mwscript deleteEqualMessages.php --wiki trwikimedia (T45917)
{nav icon=file, name=Mentioned in SAL, href=https://tools.wmflabs.org/sal/log/AVPepXiHD0x0K5Df_P7O} [2016-04-04T00:21:39Z] <Krinkle> mwscript deleteEqualMessages.php --wiki ruwiki (T45917)
{nav icon=file, name=Mentioned in SAL, href=https://tools.wmflabs.org/sal/log/AVPeRhqty3uubrspqdd0} [2016-04-03T22:37:29Z] <Krinkle> mwscript deleteEqualMessages.php --wiki eswiki --lang-code ca (T45917)
{nav icon=file, name=Mentioned in SAL, href=https://tools.wmflabs.org/sal/log/AVPeRglHy3uubrspqddz} [2016-04-03T22:37:25Z] <Krinkle> mwscript deleteEqualMessages.php --wiki eswiki (T45917)
{nav icon=file, name=Mentioned in SAL, href=https://tools.wmflabs.org/sal/log/AVPLTHP8y3uubrspqcNy} [2016-03-31T06:11:38Z] <Krinkle> mwscript deleteEqualMessages.php --wiki zh_min_nanwiki (T45917)
{nav icon=file, name=Mentioned in SAL, href=https://tools.wmflabs.org/sal/log/AVOnA0SngCrwkbTdl4Pi} [2016-03-24T05:05:22Z] <Krinkle> mwscript deleteEqualMessages.php --wiki zhwikiquote (T45917 , P1988)
> Has this now all been done and resolved?

Not that I know.
Has this now all been done and resolved?
>>! In T45917#1841781, @Jdforrester-WMF wrote:
> What is left to do here?

Running on all wikis.
What is left to do here?
Ran for a few more wikis:

```
eowiki: 129 pages
euwiki: 740 pages
frpwiki: 2 pages
frwiki: 48 pages
huwiki: 7 pages
kawiki: 777 pages
ocwiki: 862 pages
rowiki: 432 pages
zhwiktionary: 143 pages
fywiktionary: 65 pages
pmswiki: 391 pages
```
Ran for a few more wikis:

```
eowiki: 129 pages
euwiki: 740 pages
frpwiki: 2 pages
frwiki: 48 pages
huwiki: 7 pages
kawiki: 777 pages
ocwiki: 862 pages
rowiki: 432 pages
zhwiktionary: 143 pages
fywiktionary: 65 pages
```
Ran for a few more wikis:

```
eowiki: 129 pages
euwiki: 740 pages
frpwiki: 2 pages
frwiki: 48 pages
huwiki: 7 pages
kawiki: 777 pages
ocwiki: 862 pages
rowiki: 432 pages
zhwiktionary: 143 pages
```
Ran for a few more wikis:

```
eowiki: 129 pages
euwiki: 740 pages
frpwiki: 2 pages
frwiki: 48 pages
huwiki: 7 pages
kawiki: 777 pages
ocwiki: 862 pages
rowiki: 432 pages
```
Ran for a few more wikis:

```
eowiki: 129 pages
euwiki: 740 pages
frpwiki: 2 pages
frwiki: 48 pages
huwiki: 7 pages
kawiki: 777 pages
ocwiki: 862 pages
```
Ran for a few more wikis:

```
eowiki: 129 pages
euwiki: 740 pages
frpwiki: 2 pages
frwiki: 48 pages
huwiki: 7 pages
kawiki: 777 pages
```
Maybe it can be used to clean old translations such as [[https://meta.wikimedia.org/w/index.php?title=Special%3AAllMessages&prefix=&filter=modified&lang=eu&limit=5000|these ones]] at Meta? (included other langs). Thread opened at Babel.
Ran it for a two more wikis after inspecting the dry-run:

```
cewiki: 243 pages
sawiki: 58 pages
```
Ran it for these wikis:
```
mediawikiwiki
* [[MediaWiki:Wikilove-barnstar-resilient-desc]]
* [[MediaWiki:Wikilove-barnstar-tireless-desc]]
* [[MediaWiki:Code-referenced]]
* [[MediaWiki:Rss-item]]

nlwiki
* [[MediaWiki:Logentry-block-block]]
* [[MediaWiki:Logentry-block-unblock]]
* [[MediaWiki:Centralauth-uwbr-name]]
* [[MediaWiki:Centralauth-uwbr-registration]]
* [[MediaWiki:Centralauth-uwbr-editcount]]
* [[MediaWiki:Centralauth-uwbr-intro]]
* [[MediaWiki:Sandboxlink-subpage-name]]
* [[MediaWiki:Sandboxlink-portlet-label]]

commonswiki: 0
metawiki: 0
```
>>! In T45917#1152012, @Krenair wrote:
> Is there a reason we haven't done this on all wikis now?

No good one. It's fine to proceed.
Is there a reason we haven't done this on all wikis now?

{P436}
Ran for commonswiki per my own request there as sysop (could've deleted them by hand):


> 279 pages in the MediaWiki namespace override messages.
> 1 pages are equal to the default message (+ 0 talk pages).
> 
> List:
> * [[MediaWiki:Visualeditor-ca-editsource]]
Spread over the past two weeks, mwscript deleteEqualMessages.php was ran[1] on the following wikis while performing other routine maintenance and interface fixes:

abwiki
afwiki
afwikiquote
alswiki
bat-smgwiki
bpywiki
cswiki
cswikiversity
cswiktionary
cvwiki
lnwiki
nahwiktionary
newwiki
nlwiki
rowiktionary
simplewiki
sqwiki
suwiki
tlwiki

[1] https://wikitech.wikimedia.org/wiki/Server_admin_log
(In reply to Nemo from comment #26)
> Thanks! I'd suggest to avoid touching talk pages, so that the operation is
> truly no-op. Those talk pages are unlikely to exist but wikis have different
> policies on the matter.

Good point. We have orphan tools to detect those and are indeed not always trivial/uncontroversial. Will keep them from now on.
Thanks! I'd suggest to avoid touching talk pages, so that the operation is truly no-op. Those talk pages are unlikely to exist but wikis have different policies on the matter.
Ran mwscript deleteEqualMessages.php --delete --delete-talk on the following wikis:

* afwiki
* amwiki
* brwiki
* euwiktionary
* gvwiki
* hrwiki
* hrwiktionary
* iawiki
* miwiki
* mlwiki
This was requested to be run on wuuwiki: https://meta.wikimedia.org/w/index.php?title=Steward_requests/Miscellaneous&oldid=7913568#Remove_useless_system_messages_on_wuu_wikipedia
Krinkle, are you still planning to work on this?
The short version of the long story (that is partially outlined in previous comments by all of you) is that it:

* Was never consistent to be begin with.
* It has changed over time.
  So we can't reliably know now what to do with a message. You'd have to account
  for deployment dates for different wikis and assume a community member
  intentionally left a message override untouched knowing the new behaviour.
  More likely it was forgotten about and is actually still assuming the old logic. 
* It can vary by message whether it is blankable or disableable.

If the code calls isBlank first (like Sitenotice) then it can be blanked with '' without leaving a gap in the interface because the feature checks it first.

If the code calls isDisabled first, and then falls back or something, then it can be blanked with '' or '-' and it will use the default.

However by far the default behaviour for the majority of messages is that if you create a local page, it replaces the message with that page. And if you put '' or '-' in it, it will appear as a gap in the interface.

Either way, those pages are there with empty content for a reason, so it doesn't make sense to delete them en mass as part of this maintenance script.
Blanking a message no longer disables it (bug 14176), so all pre-12.06.2013 blankings should be transformed in deletions.
I'm confused by comment #12 and #13 then, I understood from them that '' no longer meant default.
(In reply to comment #16)
> > Even the "redundant" messages getting deleted makes me a little sad, given
> > how useful some of that page history can be (including being linked from active
> > bug reports). But I understand that it's better future-proofing. Alas.
> 
> I remember blanking some MediaWiki messages precisely to use the default but
> keep the history.
> Maybe the script should edit the messages to whatever is used now to mean
> "use
> the default" ("-" ?) when there are several edits to the page.

Sometimes '', sometimes '-' (handled by Message:isBlank and Message::isDisabled) however those are not generic APIs. The message system does not use these methods. They are available for local code to use if they want to.

So there's no way of knowing whether an individual message "supports" that behaviour, and even then we currently have some use '' and some use '-' ('' is a safe bet for both).
(In reply to comment #15)
> I've run this on a single wiki where I'm also a local sysop (nlwiki) and
> noticed the script has a minor flaw.
> 
> It incorrectly deleted MediaWiki:Sitenotice.

Fixed in I5b416cda25a3641862df9919c46ae59ad5d5d6e0.
> Even the "redundant" messages getting deleted makes me a little sad, given
> how useful some of that page history can be (including being linked from active
> bug reports). But I understand that it's better future-proofing. Alas.

I remember blanking some MediaWiki messages precisely to use the default but keep the history.
Maybe the script should edit the messages to whatever is used now to mean "use the default" ("-" ?) when there are several edits to the page.
I've run this on a single wiki where I'm also a local sysop (nlwiki) and noticed the script has a minor flaw.

It incorrectly deleted MediaWiki:Sitenotice (if it is empty), which is undesirable. So we should probably change the script to make an exception for empty messages.

Those are most unlikely to change anyway because there is no message content to update or change, it is empty.
(In reply to comment #13)
> (In reply to comment #12)
>> If a script to delete empty messages existed in the past, we could've run it
>> once globally after we reverted the feature to have blank messages mean
>> default. But it has been to long to do this now.
> 
> What do you mean too long? It's been today for Wikipedias (1.22wmf7). Blank
> message has always meant "equal to default", so it doesn't seem out of scope
> for the script, which should be run by third parties before upgrading to
> MediaWiki 1.22.

Not always. The behavior has switched a few times now.

There's no good answer here. It's impossible to determine intent simply by page_len being equal to 0. I tend to agree with Krinkle that it's better to be cautious here.

Even the "redundant" messages getting deleted makes me a little sad, given how useful some of that page history can be (including being linked from active bug reports). But I understand that it's better future-proofing. Alas.

> [...] [[MediaWiki 1.22]] [...]

You mean [[mw:MediaWiki 1.22]], of course.
(In reply to comment #12)
> If a script to delete empty messages existed in the past, we could've run it
> once globally after we reverted the feature to have blank messages mean
> default. But it has been to long to do this now.

What do you mean too long? It's been today for Wikipedias (1.22wmf7). Blank message has always meant "equal to default", so it doesn't seem out of scope for the script, which should be run by third parties before upgrading to MediaWiki 1.22.
If you consider it out of scope I'd file a bug for another script to be created, but nobody would be working on it so it would become too late so I'll just add a warning on [[MediaWiki 1.22]] and let sysops sort it out manually.
(In reply to comment #11)
> (In reply to comment #10)
> > Related URL: https://gerrit.wikimedia.org/r/64991 (Gerrit Change
> > I2680413c276365a44c935a6f6fdd740daa86341e)
> 
> Merged a month ago.
> 
> Given bug 14176 (bug 49793), the script should also delete blank messages and
> be run as soon as possible; unless a separate script is prepared and run for
> that only.

Since blank messages no longer mean showing the default, deleting them seems inappropriate.

Yes, there are likely some pages out there that are blank and currently causing bugs due the message being empty instead of the default. However it would be a mistake to unconditionally delete all blank pages in the MediaWiki namespace.

For maintenance scripts like deleteEqualMessages it is important that they do not affect the interface. It should only delete things that are non-controversial.

If a script to delete empty messages existed in the past, we could've run it once globally after we reverted the feature to have blank messages mean default. But it has been to long to do this now. And one could also argue that it was dangerous even then because there might be existing pages that are blank for other reasons.
(In reply to comment #10)
> Related URL: https://gerrit.wikimedia.org/r/64991 (Gerrit Change
> I2680413c276365a44c935a6f6fdd740daa86341e)

Merged a month ago.

Given bug 14176 (bug 49793), the script should also delete blank messages and be run as soon as possible; unless a separate script is prepared and run for that only.
Related URL: https://gerrit.wikimedia.org/r/64991 (Gerrit Change I2680413c276365a44c935a6f6fdd740daa86341e)
Related URL: https://gerrit.wikimedia.org/r/62159 (Gerrit Change I2680413c276365a44c935a6f6fdd740daa86341e)
(In reply to comment #7)
> (In reply to comment #6)
> > I could run it, but I'd like to not execute my own request without a little
> > more consensus from people.
> > 
> > They aren't permanent or hidden actions in any way (regular wiki deletions,
> > it's a bot basically), but they would be a horror to undo.
> > 
> 
> Can you dry run it and make a list of the pages that will be deleted so they
> can be reviewed before deletion?

I'm not sure what there is to review regarding individual pages. They all follow the same description, whatever reasoning one would use about them doesn't specify for any particular page:

 Pages in the MediaWiki namespace that exist and override a system message
 of which the wiki page contents are equal to the system message of the site
 language (in other words, there is no longer a reason fo the override page
 to exist).

Deleting these pages has no visible effect as the effective value of the interface message will still be the same.

The advantage is saving maintenance work later on by not having to update these messages when the software upgrades, and for consistency across wikis.

A common scenario is the following:
* 3 wikis in language x
* 1 of the wikis overrides a message (making an improvement)
* the message is fixed in translatewiki
* the message update is deployed
* users of all 800 wikis using language x now see the new version of the message
* another update is made to the message and deployed
* all wikis use it, except the wiki where the first change came from which is now out of sync without it being intentionally so.


Alright, I'm biased as it was my own idea. But that doesn't mean the script itself has to be controversial. I'll run this next week if no objections are raised before then.
**Thehelpfulonewiki** wrote:

(In reply to comment #6)
> I could run it, but I'd like to not execute my own request without a little
> more consensus from people.
> 
> They aren't permanent or hidden actions in any way (regular wiki deletions,
> it's a bot basically), but they would be a horror to undo.
> 

Can you dry run it and make a list of the pages that will be deleted so they can be reviewed before deletion?
I could run it, but I'd like to not execute my own request without a little more consensus from people.

They aren't permanent or hidden actions in any way (regular wiki deletions, it's a bot basically), but they would be a horror to undo.

I wouldn't know why someone would disagree, but then again, there've only been a few people involved so far that all agreed.
**Thehelpfulonewiki** wrote:

Any progress on running this?
See bug 43915.
(In reply to comment #2)
> Can the old [[User:MediaWiki default]] be used for this task?

The script I wrote uses that user and ensures it is in the bot group  (that is, add if not present) before it runs.

(In reply to comment #2)
> I understand this is going to affect messages pre-betawiki.

No, it is not.

(In reply to comment #2)
> However I  what would happen with messages that we decided to customize

Nothing.
Can the old [[User:MediaWiki default]] be used for this task? (Please note that since it does not run since 2006 it has been deflagged from the bot group from some projects).

I understand this is going to affect messages pre-betawiki. However I wonder what would happen with messages that we decided to customize localy. Those should not be deleted as they're likely going to be recreated later... Only a minor issue, though.
This is a subset of the general task "clean-up local messages".
What we have now:
[[mw:Localisation#Old_local_translation_system]]
https://toolserver.org/~robin/?tool=cleanuplocalmsgs
We should amortize per-request overheads by batching API requests.

AFAIK there is no generic batching support in the API currently, and adding it would probably be a bit too time-consuming for now. Instead we can add a unique string as a separator, for example something like 

<nowiki>d41d8cd98f00b204e9800998ecf8427e</nowiki>

This would work for for action=expandtemplates and action=parse which are the main workarounds we currently use. In the longer term we should switch to explicit methods that don't involve parsing wikitext, which is probably also a good moment to add real batching support.

Decisions about batch sizes could be based on wikitext source size initially (based on the assumption that templates with a bazillion parameters also take longer to expand). A fixed number of templates per batch would be another simple alternative. Really fancy batching could use stats of previous processing times (returned by the PHP preprocessor per transclusion and stored in HTML).

Ideally we would also enforce separation between batched requests to avoid non-deterministic behavior for stateful extensions.

--------------------------
**Version**: unspecified
**Severity**: enhancement
@ssastry, good point re load. Added the parse request rate for completeness. Also agreed re needing more data.
@ssastry, good point re load. Added the parse request rate for completeness.
@subbu, good point re load. Added the parse request rate for completeness.
You need to account for the spikiness in the load too. see http://grafana.wikimedia.org/#/dashboard/db/parsoid-timing-wt2html (zoom out to a 7-day window and look how the request rate was much closer to 200 reqs / sec last few days compared to < 150 reqs / sec earlier in the week (before batching was enabled). I am fairly confident that parsing latencies haven't been affected adversely based on monitoring this last couple days. But, I think we have to wait and watch this over the next couple weeks before we have a truer picture. 

On the other hand, if you look at ganglia graphs for the API cluster, you do see a reduction in network traffic in/out of it (despite the higher parse load on the Parsoid end) + a downward trend in the load there.
Batching was fully enabled on Sept 29th, around 16:14 UTC. 12-hour median latencies as seen by RESTBase in the last days (smoothed version of [this graph](http://grafana.wikimedia.org/#/dashboard/db/restbase?panelId=9&fullscreen)):

P99:
{F2651940}

Mean:
{F2651943}

Smoothed parse request rate:
{F2652092}
Batching was fully enabled on Sept 29th, around 16:14 UTC. 12-hour median latencies as seen by RESTBase in the last days (smoothed version of [this graph](http://grafana.wikimedia.org/#/dashboard/db/restbase?panelId=9&fullscreen)):

P99:
{F2651940}

Mean:
{F2651943}

Smoothed parse request rate:
{F2652078}
Batching was fully enabled on Sept 29th, around 16:14 UTC. 12-hour median latencies as seen by RESTBase in the last days (smoothed version of [this graph](http://grafana.wikimedia.org/#/dashboard/db/restbase?panelId=9&fullscreen)):

P99:
{F2651940}

Mean:
{F2651943}

Parse request rate:
{F2652035}
Batching was fully enabled on Sept 29th, around 16:14 UTC. 12-hour median latencies as seen by RESTBase in the last days (smoothed version of [this graph](http://grafana.wikimedia.org/#/dashboard/db/restbase?panelId=9&fullscreen)):

P99:
{F2651940}

Mean:
{F2651943}
Batching was fully enabled on Sept 29th. 12-hour median latencies as seen by RESTBase in the last days (smoothed version of [this graph](http://grafana.wikimedia.org/#/dashboard/db/restbase?panelId=9&fullscreen)):

P99:
{F2651940}

Mean:
{F2651943}
Batching was fully enabled on Sept 29th. 12-hour median latencies as seen by RESTBase in the last days (smoothed version of [this graph](http://grafana.wikimedia.org/#/dashboard/db/restbase?panelId=9&fullscreen):

P99:
{F2651940}

Mean:
{F2651943}
12-hour median latencies as seen by RESTBase in the last days (smoothed version of [this graph](http://grafana.wikimedia.org/#/dashboard/db/restbase?panelId=9&fullscreen):

P99:
{F2651940}

Mean:
{F2651943}
12-hour median latencies as seen by RESTBase in the last days:

P99:
{F2651940}

Mean:
{F2651943}
Change 227208 merged by jenkins-bot:
Batch MW parser and imageinfo API requests

[[https://gerrit.wikimedia.org/r/227208]]
Change 227208 had a related patch set uploaded (by Tim Starling):
Batch MW parser and imageinfo API requests

[[https://gerrit.wikimedia.org/r/227208]]
Sounds good to me since it looks like it keeps complexity down implementing this since the code can be customized to Parsoid's needs. But, once this is all ironed out and live, we should update docs for 3rd party Parsoid installs about requirement (unless batching can be made optional on the Parsoid end).
@tstarling +1 from me. Your rationale covers all the things I would have brought up (and more). Sorry for being slow, @ssastry is vacationing and I'm not sure if @cscott's been following this thread.
@tstarling +1 from me. Your rationale covers all the things I would have brought up (and more). Sorry for being @ssastry is vacationing and I'm not sure if @cscott's been following this thread.
No response, so I committed the MW extension to https://gerrit.wikimedia.org/r/#/c/226670/

Still ironing out a couple of issues on the client side. A changeset will appear soon.
Please comment on the idea of doing batch parsing in an extension instead of in a core API module. I'd like to know if it sounds like a good idea before I create the Gerrit repository.

The reasons for doing this were:
* Simpler design, due to the smaller number of clients/stakeholders. Code size is only 135 physical lines, with no internal API calls, compared to 800 for action=parse and 218 for action=expandtemplates.
* Allows the action=parse and action=expandtemplates modules to be easily combined. No need to break my head trying to think about generic Lua frontend batch processing APIs which allow arbitrary actions to be combined.
* An API for parsoid use only can easily be policed for misuse or DoS, e.g. with IP-based access control. No need for restrictive server-side batch size limits which may interfere with optimal performance.
* Expedient output format, based on b/c with action=parse and action=expandtemplates, which allows the client to share code with the fallback case.
* Forking the API provides an easy path towards more aggressive integration with the MW parser, for example output annotation hooks.

The proposed extension name is ParsoidBatchAPI.
I've written a client-side "batcher" class hierarchy, and a MediaWiki extension which does server-side batches of mixed parse and preprocess operations. The impact on both client and server CPU time is substantial, as expected from the discussion on T88915. For [[List of 20th-century classical composers]] with a batch size of 50, node CPU time went from 54s to 29s, and HHVM CPU time went from 216s to 70s.

The impact on latency can't easily be measured in my current test setup.

Unfortunately, it was necessary to treat each item in the batch as a distinct parse operation, with clearState(), since Parsoid wishes to know which categories are generated by which templates. This causes a number of useful caches to be discarded at the start of each batch item. This may be the reason why the HHVM CPU time is still 70s, even though running the text through expandtemplates as a whole takes only 10s. Increasing the batch size from 50 to 500 only reduced the HHVM CPU time to 65s.

If clearState() was not done, it would not be easy to determine which template caused the addition of a given category. Consider the case of a template which is invoked with no arguments, which causes a tracking category to be added. If this template is invoked more than once in a parse operation, the expansion cache will prevent ParserOutput::addCategory() from being called on the second and subsequent invocations. This implies that the expansion cache would need to be disabled or rewritten to support this Parsoid use case.
We should also keep in mind the effect of batching on overall system reliability. In {T97204} I advocate for tight timeouts in backend services, combined with no client retries when encountering a server timeout. In general, batching makes it harder to establish tight timeouts on end points. We should thus limit it to end points where each batch action has a very predictable processing time, and the overall batch will always complete within a reasonable timeout (< 60s).
We should also keep in mind the effect of batching on overall system reliability. In {T97204} I advocate for tight timeouts in backend services, combined with no client retries when encountering a server timeout. In general, batching makes it harder to establish tight timeouts on end points. We should thus limit it to end points where each batch action has a very limited processing time, and the overall batch will always complete within a reasonable timeout (< 60s).
I concur.
It is good thing to reduce the load on the API cluster, but I don't think this task should be a VE Q3 blocker. 

Right now,
(a) Parsoid tracks all edits -- so there is going to be no change in Parsoid parsing load (and hence API load) even if VE is enabled everywhere (assuming edit rate stays the same).
(b) The current load on the API cluster is not problematic that forces us to work on this for VE deployment.

So, I suggest that this task be removed from the VisualEditor Q3 Blockers workboard since there are other more higher priority issues to fix in Parsoid land.
>>! In T45888#978615, @tstarling wrote:
> The main reason I am leaning towards the internal batcher is because some of the queues will have very little traffic on them, e.g. queues for small wikis. This makes for some uncomfortable tradeoffs when you try to set the dispatch timeout. Consider that parse operations are observed to take ~10s and issue ~100 API requests -- this implies a mean interval between requests on the order of 100ms, and a timeout of at least that much if there is to be any throughput benefit from batching at all. That is quite a long time to wait. From a throughput perspective, the optimal dispatch timeout may be more than 1s.

The amount of batching we can achieve on the long tail is bounded by the maximum latency penalty we are willing to introduce. A global batcher can combine requests from different API clients (not just parsoid), and should thus result in lower average latencies by filling up batches quickly (or reaching a given batching ratio with a lower maximum latency penalty).

Also keep in mind that with selective re-expansion of templates those requests will become less common, which will make the single-client batch even less effective, as there are just less requests to combine within the time window.

> Also, note that Parsoid currently performs API requests with keep-alive disabled. With default socket options, this implies a limit of 470 API requests per second per client server before local port exhaustion occurs, as in T75949. Batching internally, without the involvement of TCP, avoids this limit.

The number of connections has not been an issue in practice & would not change. On the proxy we could also enable [SPDY support](https://github.com/indutny/node-spdy), which reduces the number of connections to one per client & removes some per-request overhead. That said, I think the `Connection: close` bit can be removed. It was a work-around from an early node version IIRC, and is no longer needed.
>>! In T45888#978615, @tstarling wrote:
> The main reason I am leaning towards the internal batcher is because some of the queues will have very little traffic on them, e.g. queues for small wikis. This makes for some uncomfortable tradeoffs when you try to set the dispatch timeout. Consider that parse operations are observed to take ~10s and issue ~100 API requests -- this implies a mean interval between requests on the order of 100ms, and a timeout of at least that much if there is to be any throughput benefit from batching at all. That is quite a long time to wait. From a throughput perspective, the optimal dispatch timeout may be more than 1s.

The amount of batching is bounded by the maximum latency penalty we are willing to introduce. A global batcher can combine requests from different API clients (not just parsoid), and should thus result in lower average latencies by filling up batches quickly (or reaching a given batching ratio with a lower maximum latency penalty).

Also keep in mind that with selective re-expansion of templates those requests will become less common, which will make the single-client batch even less effective, as there are just less requests to combine within the time window.

> Also, note that Parsoid currently performs API requests with keep-alive disabled. With default socket options, this implies a limit of 470 API requests per second per client server before local port exhaustion occurs, as in T75949. Batching internally, without the involvement of TCP, avoids this limit.

The number of connections has not been an issue in practice & would not change. On the proxy we could also enable [SPDY support](https://github.com/indutny/node-spdy), which reduces the number of connections to one per client & removes some per-request overhead. That said, I think the `Connection: close` bit can be removed. It was a work-around from an early node version IIRC, and is no longer needed.
Request batching appears to be simple to implement (~100 lines according to @gwicke) and would cause a substantial decrease in API cluster CPU load. By switching it on only for requests initiated by the job queue, there would be no effect on user latency.

> The problem with general batching is that state in MediaWiki is not very well defined. Several extensions for example keep internal state between calls to tag hooks, and resetting that state between individual requests in a batch would probably produce a similar overhead as the regular per-request setup (30+ms).

No, parser state in MediaWiki is very well-defined, it is defined as the data which is cleared by Parser::clearState(). Extensions which keep internal state hook this function in order to clear their state. MediaWiki is reasonably well-optimised for clearing the parser state, since message parsing does so, often tens of times per request. The overhead is orders of magnitude smaller than the request setup time.

> The current performance numbers combined with several optimizations aimed at avoiding API requests lessened the need for API request batching on our end.

Parsoid is still by far the largest API consumer by CPU time.

> Speeding up individual API requests is a general architectural goal, and should be addressed in that context. Closing this bug as WONTFIX on our end.

I am familiar with MW setup time optimisation, and compared to that large, ongoing effort, Parsoid request batching looks like low-hanging fruit.
The current performance numbers combined with several optimizations aimed at avoiding API requests lessened the need for API request batching on our end.

Speeding up individual API requests is a general architectural goal, and should be addressed in that context. Closing this bug as WONTFIX on our end.
Adding custom batching support just for template expansion and extension tag calls would really be a workaround, and would add complexity to both clients and the server. If the performance of API requests could be improved in general, we could and should probably avoid that complex workaround in favor of the general solution.

In the longer term, our HTML storage and incremental re-parsing / expansion plans should reduce the number of template expansions and extension calls to a fraction of the level we'll produce initially. The round-trip testing we are currently performing is already close to the edit rate of the English Wikipedia and did not create any issues on the API cluster. A Parsoid installation tracking all edits on all wikis would probably create 2-3 times the number of API requests, which are probably still doable for the current API cluster.

Overall it seems to be a good idea to hold off on a custom batching solution until it is clear that it is really needed and general API performance improvements are not possible.
For us, the main use cases are template expansion using the PHP preprocessor and the expansion of extension tags. Currently, both of these are only available with a detour through the PHP parser (action=expandtemplates and action=parse respectively), so we'd like to add direct API end points to perform these actions.

A general batching mechanism would probably accept a posted JSON array with each member being an object containing the API arguments for one action (action etc). The return value would be a JSON array with results corresponding to the request array. Instead of relying on positions in an array the client could also supply UIDs for requests which are then mirrored in the result. This could be achieved with an reqid member in each request object.

The problem with general batching is that state in MediaWiki is not very well defined. Several extensions for example keep internal state between calls to tag hooks, and resetting that state between individual requests in a batch would probably produce a similar overhead as the regular per-request setup (30+ms).

In Parsoid, we can work around this issue for our specific use cases by maintaining a whitelist of stateless extensions which can be mixed in a batch without producing non-deterministic output. Non-whitelisted extensions would need to be expanded in a single action=parse request containing all extension tags for that particular extension in page order.
action=query was built specifically to support batching, but other actions might choose not to implement it. Could you give a very specific example of
* How the final api request should look like?
* What do you expect in return.
This is now merged and will go out later today.
Related URL: https://gerrit.wikimedia.org/r/69801 (Gerrit Change I5a58b4dcebd6ceae0ffcd24f663429f25bdc3db9)
Related URL: https://gerrit.wikimedia.org/r/69801 (Gerrit Change I5a58b4dcebd6ceae0ffcd24f663429f25bdc3db9)
I believe that the current list of titles  will quickly be a problem if VE is rolled out to unexperienced users on wikipedia: they will probably use Heading 1 because they don't know it shouldn't be used in 99.9...% of edits.
When I tried to add a section, I used Heading 1 by default and only changed back to Heading 2 when I saw that the new title was bigger than what I'm used to.

If you think <h1> titles should be kept in VE, it should be separated from the other titles (after other ones). Eventually, would it be possible to make that configurable on a per wiki basis if some wiki really use <h1> as a normal title ?
> Lots of wikis (e.g.meta) use H1s quite liberally.

I didn't know that, and it seems bad practice. Could you point to some examples? Maybe there is a use case I'm completely overlooking.


> | H1: Title
> | H2: Heading
> | H3: Sub-heading
> | H4: Sub-heading
> | H5: Sub-heading
> | H6: Sub-heading

I'm not so happy about the name "Title", and it being at the top of that list. I would much rather see it buried somewhere at the bottom, maybe as the very last option, and something like "Duplicate page title", or at least something that makes it abundantly clear that it is not something that is meant to be used.
AzaToth's suggestion is to label as follows:

| H1: Title
| H2: Heading
| H3: Sub-heading
| H4: Sub-heading
| H5: Sub-heading
| H6: Sub-heading

The differentiation between H3 - H6 would be only styling. Not sure how I feel about this, but it's certainly "correct".
(In reply to comment #12)
> Kill the H1s from the editor please. They should really be considered
> deprecated in the wiki syntax, and aren't something that people should be
> able to create by accident.

VE is meant to be able to edit all content that's valid. Lots of wikis (e.g. meta) use H1s quite liberally. Discouraging use is fine, but preventing use feels wrong. (Also, what the hell should VE do when it encounters an H1 in the wild, if they were 'disabled'?)
Kill the H1s from the editor please. They should really be considered deprecated in the wiki syntax, and aren't something that people should be able to create by accident.
(In reply to comment #10)
> Instead of messing around with the numbers and having [heading 3 = <h4>], why
> not rename them "Heading", "Subheading", and "Sub-subheading".

So:

| H1: Title
| H2: Heading
| H3: Sub-heading
| H4: Sub-sub-heading
| H5: Sub-sub-sub-heading
| H6: Sub-sub-sub-sub-heading

It might get a bit ridiculous, but I like the idea.
**ypnypn9** wrote:

(In reply to comment #9)
> It is unfortunate that wikitext currently allows h1 elements. It shouldn't.
> It should be the end aim for the visual editor to have feature parity with
> wikitext, but at the current point it makes it natural to select a heading 1
> when you really never want to do that. I would prefer to see it not available
> in the visual editor at all, but as a compromise, I could live with renaming
> Header 1 to Pageheader, and move it all the way to the bottom of markup
> elements, and rename header 2 to header 1, etc. That way we don't lose an
> option in the visual editor that is available in wikitext, and at the same
> time reduce the chance of people thinking it is an option they may want to
> choose for a header, which it is not.

Instead of messing around with the numbers and having [heading 3 = <h4>], why not rename them "Heading", "Subheading", and "Sub-subheading".
It is unfortunate that wikitext currently allows h1 elements. It shouldn't. It should be the end aim for the visual editor to have feature parity with wikitext, but at the current point it makes it natural to select a heading 1 when you really never want to do that. I would prefer to see it not available in the visual editor at all, but as a compromise, I could live with renaming Header 1 to Pageheader, and move it all the way to the bottom of markup elements, and rename header 2 to header 1, etc. That way we don't lose an option in the visual editor that is available in wikitext, and at the same time reduce the chance of people thinking it is an option they may want to choose for a header, which it is not.

At the same time, we may want to think about abandoning the option to make h1 headers in wikitext too, but that makes for a different discussion which should take place in a different place than this bug.
Does this really have much to do with the VE to begin with ? It's already allowed. I agree that such is a bad thing but that's a separate story. I guess at most, we could make the H1 option 'non visisble' unless the current element already is exactly of that type.

What would be nice, was if the VE would have more 'guided' heading building. It could warn you about inconsistencies in header levels for instance.
*** Bug 48955 has been marked as a duplicate of this bug. ***
(In reply to comment #4)
> Agree--Visual Editor should not use <h1> HTML tags for headings at all
> because
> MediaWiki uses <h1> HTML for page name and headings are subordinate to page
> name. Heading-1 should create <h2> HTML tags, Heading-2 <h3> HTML tags,
> Heading-3 <h4> HTML tags, etc. Newcomers don't know this. Visual Editor
> should
> simply do this correctly without editors needing to know or think about it at
> all. Offering <h1> HTML in Visual Editor will cause confusion and misuse
> among
> the very people Visual Editor is designed to empower. They just want it to
> work
> right.

Except "Heading 1" is actually create-able on any wiki page ("= Foo ="), it's just discouraged. This is a tension between what the software /lets/ users do and what they /should/ do. I'm not convince that hard and fast global rules are always appropriate.
**rogerchrisman** wrote:

Agree--Visual Editor should not use <h1> HTML tags for headings at all because MediaWiki uses <h1> HTML for page name and headings are subordinate to page name. Heading-1 should create <h2> HTML tags, Heading-2 <h3> HTML tags, Heading-3 <h4> HTML tags, etc. Newcomers don't know this. Visual Editor should simply do this correctly without editors needing to know or think about it at all. Offering <h1> HTML in Visual Editor will cause confusion and misuse among the very people Visual Editor is designed to empower. They just want it to work right.
**rogerchrisman** wrote:

Agree--Visual Editor should not use <h1> HTML tags for headings at all because MediaWiki uses <h1> HTML for page name and headings are subordinate to page name. Heading-1 should create <h2> HTML tags, Heading-2 <h3> HTML tags, Heading-3 <h4> HTML tags, etc. Newcomers don't know this. Visual Editor should simply do this correctly without editors needing to know or think about it at all. Offering <h1> HTML in Visual Editor will cause confusion and misuse among the very people Visual Editor is designed to empower. They just wont it to work right.
May want to cover content namespaces in general (but provide some way of getting them). Also to consider preventing H6s (and H5s?).
*** Bug 44780 has been marked as a duplicate of this bug. ***
**turb** wrote:

(In reply to comment #7)
> Afaik the bad token handling has been solved for the save process. The load
> process no longer requires a token.
> 
> Can you confirm this now works fine?

Yes, it does work fine now, even with Cookie Monster preventing cookies to be set.
Afaik the bad token handling has been solved for the save process. The load process no longer requires a token.

Can you confirm this now works fine?
**turb** wrote:

(In reply to comment #5)
> Does normal editing (through the old, non-visual editor) work for you on
> mediawiki.org when not whitelisted?

Yes, it works.
(In reply to comment #3)
> (In reply to comment #2)
> > (In reply to comment #1)
> > > Can you confirm whether VE always fails to load with Cookie Monster and
> > > always
> > > loads successfully without Cookie Monster?
> > And could you also confirm that you're able to edit *as a logged-in user*
> > using
> > the regular non-visual editor?
> 
> I forgot to mention I was testing on VisualEditor:Test in mediawiki.org, that
> was not whitelisted in Cookie Monster. When I did whitelisted it, the page
> reloaded and VE was now working.
> 
> I just removed again mediawiki.org from whitelist, and VE now loads without
> end.
> 
Does normal editing (through the old, non-visual editor) work for you on mediawiki.org when not whitelisted?
This has probably already been fixed. I have no issues with undo/redo in Firefox on my local wiki running MW 1.23 and WikiEditor from master.
With the above patch, the former message:

    Error loading data from server: parsoidserver-http-bad-status:
    500. Would you like to retry?

… turns into:

    Error loading data from server: parsoidserver-http-bad-status:
    500: Page Fetch failure for "BADURL": Error: getaddrinfo
    ENOTFOUND. Would you like to retry?

Which is not ideal, but at least describes things a bit. Marking this as FIXED.
Change 157775 merged by jenkins-bot:
Add debugging help to VisualEditor

https://gerrit.wikimedia.org/r/157775
Change 157775 had a related patch set uploaded by Jforrester:
Add debugging help to VisualEditor

https://gerrit.wikimedia.org/r/157775
Fixed by Ed last year in https://gerrit.wikimedia.org/r/#/c/78035/
**suitongbowgn** wrote:

(In reply to comment #9)
> (In reply to comment #8)
> > There are quite a lot of extensions where the content should probably be
> > treated as a simple block of text. <math>, <source>, <pre>, <poem> basically
> > just have plain text ending with the appropriate closing tag.
> 
> Sort of. Ideally there will one day be a visual math editor, a visual music
> editor, and we already have [[mw:Extension:CodeEditor]] (which is even
> deployed
> to certain wikis) for JavaScript and CSS, which will likely cover <pre> and
> <source>/<syntaxhighlight> blocks.
> 
> I suppose <poem> and <nowiki> blocks can use a simple editor. :-)

For <math> please see bug 43058. I believe it is already available via VisualEditor experimental code.
For <syntaxhighlight> please see bug 47742. The code is currently under code review and will be available via VE experimental code in the future.
(In reply to comment #8)
> There are quite a lot of extensions where the content should probably be
> treated as a simple block of text. <math>, <source>, <pre>, <poem> basically
> just have plain text ending with the appropriate closing tag.

Sort of. Ideally there will one day be a visual math editor, a visual music editor, and we already have [[mw:Extension:CodeEditor]] (which is even deployed to certain wikis) for JavaScript and CSS, which will likely cover <pre> and <source>/<syntaxhighlight> blocks.

I suppose <poem> and <nowiki> blocks can use a simple editor. :-)
There are quite a lot of extensions where the content should probably be treated as a simple block of text. <math>, <source>, <pre>, <poem> basically just have plain text ending with the appropriate closing tag.

Some partial fix of this would be a great step in allowing VE to be used on some large classes of article.
*** Bug 51131 has been marked as a duplicate of this bug. ***
*** Bug 47742 has been marked as a duplicate of this bug. ***
Moved to Lowest as this has a huge dependency on Parsoid which they are unlikely to implement; depending on their reconsideration in a while.
(In reply to comment #3)
> +1, I imagine this feature as a toggle button, which switches the main view
> between its current rendering containing uneditable blocks, to a hybrid
> rendered + wikitext view in which the VE-opaque stuff is displayed as raw
> source.

Actually, we'll probably have inspector buttons on alienated nodes that trigger a float-over IFRAME quasi-window (in the same way that we do for the link inspector) for the individual item, rather than have a different editing mode (disrupting the entire editing flow feels wrong), but these decisions have yet to be taken.
+1, I imagine this feature as a toggle button, which switches the main view between its current rendering containing uneditable blocks, to a hybrid rendered + wikitext view in which the VE-opaque stuff is displayed as raw source.

The VE is great, but I have not found it to be usable for anything beyond the most trivial copy-editing, because of this issue.
(In reply to comment #3)
> (a) and (b), I guess. See bug 52061. I was going through a list of bugs in
> the Poem component, since they will all need to be moved once the change
> is merged (hoping it *is* merged, of course). Sorry if I'm getting too far
> ahead of myself, but this bug did seem like an odd one out, so I moved it
> out here.

Moving back to Poem, then. The bug can be moved the MediaWiki/editing or whatever later, when bug 52061 is closed-fixed.

> (In reply to comment #2)
> > > so I'm punting back to VisualEditor.
> > 
> > Why? It's not VisualEditor's problem that an extension hasn't been updated
> > yet…
> 
> Well, if Poem is to become a MediaWiki core feature, then it will turn into
> something for the VE team to worry about.

No, not really. It'll remain the responsibility of some code's maintainer, whoever that is (you?). In the absence of an obvious maintainer, that's the "Platform team", which sucks, but is rather outwith this bug report.

The VE team build VE and some of the MW-specific VE tools. We're not going to make an editor for EasyTimeline, and we're not going to make one for Poem, for the same reason. :-)

> Also, if I may point it out, the WikiHiero extension is seemingly supported
> in VisualEditor core. The extension itself knows nothing about VE. is that
> an anomaly?

Yes; the code's yet to be moved into that repo. Give me a spare 10 minutes. :-)
(a) and (b), I guess. See bug 52061. I was going through a list of bugs in the Poem component, since they will all need to be moved once the change is merged (hoping it *is* merged, of course). Sorry if I'm getting too far ahead of myself, but this bug did seem like an odd one out, so I moved it out here.

(In reply to comment #2)
> > so I'm punting back to VisualEditor.
> 
> Why? It's not VisualEditor's problem that an extension hasn't been updated
> yet…

Well, if Poem is to become a MediaWiki core feature, then it will turn into something for the VE team to worry about.

Also, if I may point it out, the WikiHiero extension is seemingly supported in VisualEditor core. The extension itself knows nothing about VE. is that an anomaly?
(In reply to comment #1)
> This is not a bug/enhancement in the Poem extension itself,

False. The Poem extension fails to register a VisualEditor enhanced editor for itself. This is a problem with that extension. See also bug 43115, bug 43118, bug 43127, etc.

> so I'm punting back to VisualEditor.

Why? It's not VisualEditor's problem that an extension hasn't been updated yet…

> If I've got this wrong, please don't move the bug back to Poem, as this
> component is hopefully going to be removed soon.

Please justify this.

All MW extensions that are deployed on the WMF cluster (and many that aren't) have a Bugzilla component, by policy. Are you saying that:

 (a) you want us to remove this extension from the cluster,
 (b) you want us to merge this extension into MW core, or
 (c) you want us to break our existing policy for this extension?
This is not a bug/enhancement in the Poem extension itself, so I'm punting back to VisualEditor.

If I've got this wrong, please don't move the bug back to Poem, as this component is hopefully going to be removed soon.
Same as {T29157}, EasyTimeline is legacy and will eventually be replaced in favor of the Graph extension (T137291). As such it does not make sense to invest in a VisualEditor plugin that will eventually be made obsolete when timelines are migrated to Graph.
I'd advise against work on this task; see {T137291} for the likely disposition of the extension.
Not a duplicate; bug 27157 is about making a stand-alone interactive visual tool to create and edit EasyTimelines, whereas this is specifically about doing it inside VisualEditor (and so not for wikitext users).
I think this is a duplicate of bug 27157. Please revert if I'm wrong.

*** This bug has been marked as a duplicate of bug 27157 ***
*** This bug has been marked as a duplicate of bug 39632 ***
Change 338911 **merged** by jenkins-bot:
[mediawiki/core@master] Make it possible to not propagate errors to PHP

[[https://gerrit.wikimedia.org/r/338911]]
Change 409171 had a related patch set uploaded (by Gergő Tisza; owner: Gergő Tisza):
[operations/mediawiki-config@master] Stop PHP errors from going to the hhvm channel

[[https://gerrit.wikimedia.org/r/409171]]
Change 374895 merged by jenkins-bot:
[mediawiki/core@master] exception: Support message normalisation for structured logging

[[https://gerrit.wikimedia.org/r/374895]]
Change 374895 had a related patch set uploaded (by Krinkle; owner: Krinkle):
[mediawiki/core@master] exception: Support message normalisation for structured logging

[[https://gerrit.wikimedia.org/r/374895]]
It's been several months, let's look at the current state of affairs:

* MediaWiki core - <https://github.com/wikimedia/mediawiki/blob/61696a0bd/includes/exception/MWExceptionHandler.php>
 * `exception`: PSR-3 structured message with exception context via `MWExceptionHandler::getLogContext` (includes trace)
 * `exception-json`: JSON-formatted structured data with exception context via `getStructuredExceptionData()`  (includes trace)
 * `error`: (Non-suppressed only) PSR-3 structured message with exception context (includes trace)
 * `error-json` (Includes suppressed errors) JSON-formatted structured data with exception context (includes trace)
* wikimedia/operations-mediawiki-config - <https://github.com/wikimedia/operations-mediawiki-config/tree/f750c8930f/wmf-config>
 * `exception`: Enabled (to mwlog and to logstash)
 * `exception-json`: Disabled (to mwlog only)
 * `error`: Enabled (to mwlog and to logstash)
 * `error-json`: Disabled
* Logstash config - <https://github.com/wikimedia/puppet/blob/87740eaedc/modules/role/files/logstash/filter-mediawiki.conf>
 * Augments `channel=exception`
 * Converts any `channel=exception-json` to `channel=exception` (Unused, todo: remove)
* logstash.wikimedia.org receives:
 * `type:hhvm` - All non-suppressed error messages and fatal errors (no trace)
 * `type:mediawiki channel:exception` - Fatals and caught exceptions logged by MediaWiki, structured and includes trace.
 * `type:mediawiki channel:error` - Non-suppressed error messages, structured and includes trace.

Known issues or remaining tasks:
* **Nothing?** {icon check color=green} **Resolved**?

Checklist (//EDIT: Moved to task description.//)
It's been several months, let's look at the current state of affairs:

* MediaWiki core - <https://github.com/wikimedia/mediawiki/blob/61696a0bd/includes/exception/MWExceptionHandler.php>
 * `exception`: PSR-3 structured message with exception context via `MWExceptionHandler::getLogContext` (includes trace)
 * `exception-json`: JSON-formatted structured data with exception context via `getStructuredExceptionData()`  (includes trace)
 * `error`: (Non-suppressed only) PSR-3 structured message with exception context (includes trace)
 * `error-json` (Includes suppressed errors) JSON-formatted structured data with exception context (includes trace)
* wikimedia/operations-mediawiki-config - <https://github.com/wikimedia/operations-mediawiki-config/tree/f750c8930f/wmf-config>
 * `exception`: Enabled (to mwlog and to logstash)
 * `exception-json`: Disabled (to mwlog only)
 * `error`: Enabled (to mwlog and to logstash)
 * `error-json`: Disabled
* Logstash config - <https://github.com/wikimedia/puppet/blob/87740eaedc/modules/role/files/logstash/filter-mediawiki.conf>
 * Augments `channel=exception`
 * Converts any `channel=exception-json` to `channel=exception` (Unused, todo: remove)
* logstash.wikimedia.org receives:
 * `type:hhvm` - All non-suppressed error messages and fatal errors (no trace)
 * `type:mediawiki channel:exception` - Fatals and caught exceptions logged by MediaWiki, structured and includes trace.
 * `type:mediawiki channel:error` - Non-suppressed error messages, structured and includes trace.

Known issues or remaining tasks:
* **Nothing?** {icon check color=green} **Resolved**?

Clean up or optimisation:
* [ ] Avoid duplicate logging under `type:hhvm` – Pending review: https://gerrit.wikimedia.org/r/338911
* [ ] Remove unused `exception-json` conversion filter from `filter-mediawiki.conf` in `operations/puppet.git`
* [ ] Fix de-duplication and message counting possible by ensuring `normalized_message` does not include the exception_id.
It's been several months, let's look at the current state of affairs:

* MediaWiki core - <https://github.com/wikimedia/mediawiki/blob/61696a0bd/includes/exception/MWExceptionHandler.php>
 * `exception`: PSR-3 structured message with exception context via `MWExceptionHandler::getLogContext` (includes trace)
 * `exception-json`: JSON-formatted structured data with exception context via `getStructuredExceptionData()`  (includes trace)
 * `error`: (Non-suppressed only) PSR-3 structured message with exception context (includes trace)
 * `error-json` (Includes suppressed errors) JSON-formatted structured data with exception context (includes trace)
* wikimedia/operations-mediawiki-config - <https://github.com/wikimedia/operations-mediawiki-config/tree/f750c8930f/wmf-config>
 * `exception`: Enabled (to mwlog and to logstash)
 * `exception-json`: Disabled (to mwlog only)
 * `error`: Enabled (to mwlog and to logstash)
 * `error-json`: Disabled
* Logstash config - <https://github.com/wikimedia/puppet/blob/87740eaedc/modules/role/files/logstash/filter-mediawiki.conf>
 * Augments `channel=exception`
 * Converts any `channel=exception-json` to `channel=exception` (Unused, todo: remove)
* logstash.wikimedia.org receives:
 * `type:hhvm` - All non-suppressed error messages and fatal errors (no trace)
 * `type:mediawiki channel:exception` - Fatals and caught exceptions logged by MediaWiki, structured and includes trace.
 * `type:mediawiki channel:error` - Non-suppressed error messages, structured and includes trace.

Known issues or remaining tasks:
* **Nothing?** {icon check color=green} **Resolved**?

Clean up or optimisation:
* [ ] Avoid duplicate logging under `type:hhvm` – Pending review: https://gerrit.wikimedia.org/r/338911
* [ ] Remove unused `exception-json` conversion filter from `filter-mediawiki.conf` in `operations/puppet.git`
Since 9eafbebdd882a562171fd0e46dcd5a9ec1e55cf8 has been deployed, some new error logs are surfacing \O/  An example is {T158770}  :-}
The `error` channel (with severity=ERROR or maybe WARNING) should be added added to fatalmonitor on logstash, I suppose?
[[https://logstash.wikimedia.org/app/kibana#/doc/logstash-*/logstash-2017.02.22/mediawiki/?id=AVpjaHVDlL3ktRIGM6p7|Example error]]. See T136849#3045285 for comments on the format. (Except `exception.trace` seems different here. Or just has random errors in different ways than for other exceptions.)
Change 338820 merged by jenkins-bot:
Route PHP warnings from the handler into udp2log

[[https://gerrit.wikimedia.org/r/338820]]
Change 338911 had a related patch set uploaded (by Gergő Tisza):
Make it possible to not propagate errors to PHP

[[https://gerrit.wikimedia.org/r/338911]]
Change 338901 had a related patch set uploaded (by Gergő Tisza):
Do not mix suppressed errors with non-suppressed ones

[[https://gerrit.wikimedia.org/r/338901]]
Change 338821 merged by jenkins-bot:
MWExceptionHandler::handleError: Set log severity based on error level

[[https://gerrit.wikimedia.org/r/338821]]
>>! In T45086#3041561, @Tgr wrote:
> The point is that the handler should not return false on errors which PHP would only log but not abort on, so that warnings don't get duplicated.

Ok, I'm finally getting what you are working towards. Thanks for sticking with me. :) It would need some config flag as you mentioned in T45086#3041550 since the default behavior of the logging system is discard everything.
>>! In T45086#3041550, @Tgr wrote:
>>>! In T45086#3041541, @bd808 wrote:
>> By not returning false and instead handling everything internally in the custom handler, the handler itself becomes responsible for deciding when to abort the request.
> 
> Yes, and it's a trivial decision (assuming we want to replicate the existing behavior): just abort on `*_ERROR`, unless PHP error reporting is turned off. So would there be any disadvantage to doing that? We could abort via exceptions which is more useful (HHVM can log the trace when the script aborts with an error but normal PHP can't), plus generally have better logging, at the cost of higher log volume / manual setup needed. It should probably be configurable and off by default but for WMF servers (and anyone else who cares enough about error logging to fine-tune it) it seems like a win.

If the handler returns false then $php_errormsg is not set (based on code inspection). Grep shows it being used by PEAR Net/Socket, it calls @ini_set('track_errors', 1).
>>! In T45086#3041557, @bd808 wrote:
> How is raising an unhandled exception functionally different than passing control back to the default error handler? Is this an attempt to get more data into the PHP runtime's error log or less? I'm confused about the goal here.

The point is that the handler should not return false on errors which PHP would only log but not abort on, so that warnings don't get duplicated. For errors which need the script to abort, IMO just push them to the exception channel (ie. don't log in the error handler but throw an exception) because that behaves nicer with non-log-based debugging (e.g. the developer would see a stack trace instead of just an error message, the user would see an exception hash that they can report). But logging and returning false, or just `die`ing, are also viable alternatives, the primary issue is log duplication for non-fatals.
>>! In T45086#3041550, @Tgr wrote:
>>>! In T45086#3041541, @bd808 wrote:
>> By not returning false and instead handling everything internally in the custom handler, the handler itself becomes responsible for deciding when to abort the request.
> 
> Yes, and it's a trivial decision (assuming we want to replicate the existing behavior): just abort on `*_ERROR`, unless PHP error reporting is turned off. So would there be any disadvantage to doing that? We could abort via exceptions which is more useful (HHVM can log the trace when the script aborts with an error but normal PHP can't), plus generally have better logging, at the cost of higher log volume / manual setup needed. It should probably be configurable and off by default but for WMF servers (and anyone else who cares enough about error logging to fine-tune it) it seems like a win.

How is raising an unhandled exception functionally different than passing control back to the default error handler? Is this an attempt to get more data into the PHP runtime's error log or less? I'm confused about the goal here.
>>! In T45086#3041541, @bd808 wrote:
> By not returning false and instead handling everything internally in the custom handler, the handler itself becomes responsible for deciding when to abort the request.

Yes, and it's a trivial decision (assuming we want to replicate the existing behavior): just abort on `*_ERROR`, unless PHP error reporting is turned off. So would there be any disadvantage to doing that? We could abort via exceptions which is more useful (HHVM can log the trace when the script aborts with an error but normal PHP can't), plus generally have better logging, at the cost of higher log volume / manual setup needed. It should probably be configurable and off by default but for WMF servers (and anyone else who cares enough about error logging to fine-tune it) it seems like a win.
Change 338821 had a related patch set uploaded (by BryanDavis):
MWExceptionHandler::handleError: Set log severity based on error level

[[https://gerrit.wikimedia.org/r/338821]]
>>! In T45086#3041483, @bd808 wrote:
> One way to provide granularity without creating N log channels would be to actually use the PSR3 log level in the generated log events:

I would still put suppressed logs into their own channel because the way we seem to be using suppression is usually to prevent the program from being stopped and not so much to suppress logging, so having severity information for suppressed events seems useful. I agree about the rest (I actually wrote the patch yesterday but apparently forgot to submit it).
Is someone actually saying the log volume is too high? It looks to me like it's blocked on nobody giving a crap since 2015. Suppressed errors were removed from the stream in https://gerrit.wikimedia.org/r/#/c/177096/
>>! In T45086#3041502, @Tgr wrote:
>>>! In T158270#3041160, @bd808 wrote:
>> We [return false from the error handler] that because it's the correct way for a default `set_error_handler()` to function. If we swallowed the errors there without returning false then `$php_errormsg` would not be populated and all errors would be handled as though the `@` suppression operator was applied to every line in the codebase.
> 
> We don't seem to use `$php_errormsg` anymore, so as far as I can see all that would do is to switch error logginrg to Monolog instead of the PHP/HHVM log files. (Assuming we die / throw an exception for errors which would interrupt program execution when unhandled.) Isn't that a good thing? It seems counterproductive to have the same error in logstash both as a Monolog event with traces etc. and a mostly useless HHVM record. Or are we worried about Monolog being more fragile / less reliable than logfiles/syslog?

I think you are confusing the log data that we collect in WMF production and how PHP/HHVM work. The error handler must either abort the execution of the request or not. By not returning false and instead handling everything internally in the custom handler, the handler itself becomes responsible for deciding when to abort the request. If the handler returns (i.e. doesn't abort the request somehow) then it is functionally the same as applying `@` suppression to all lines in all scripts.
Change 338820 had a related patch set uploaded (by Tim Starling):
Route PHP warnings from the handler into logstash

[[https://gerrit.wikimedia.org/r/338820]]
>>! In T158270#3041160, @bd808 wrote:
> We [return false from the error handler] that because it's the correct way for a default `set_error_handler()` to function. If we swallowed the errors there without returning false then `$php_errormsg` would not be populated and all errors would be handled as though the `@` suppression operator was applied to every line in the codebase.

We don't seem to use `$php_errormsg` anymore, so as far as I can see all that would do is to switch error logginrg to Monolog instead of the PHP/HHVM log files. (Assuming we die / throw an exception for errors which would interrupt program execution when unhandled.) Isn't that a good thing? It seems counterproductive to have the same error in logstash both as a Monolog event with traces etc. and a mostly useless HHVM record. Or are we worried about Monolog being more fragile / less reliable than logfiles/syslog?
>>! In T45086#3041403, @Tgr wrote:
> What's the current state of this task? Is it blocked in the log volume being too high? There are a few things we could do about that:
> * only log warnings (at least initially), not notices
> * sample
> * send suppressed errors to a separate channel which can be blackholed
> * cut down the number of warnings/notices in production (a lot of that has been happening recently, so maybe it's worth doing another experiment and reassess the situation?)

One way to provide granularity without creating N log channels would be to actually use the PSR3 log level in the generated log events:
* suppressed -> debug
* E_STRICT -> debug
* E_NOTICE, E_USERNOTICE, E_DEPRECATED, E_USER_DEPRECATED -> info
* E_WARNING, E_CORE_WARNING, E_COMPILE_WARNING, E_USER_WARNING -> warning
* E_RECOVERABLE_ERROR -> error

It would be a pretty simple patch to MWExceptionHandler to allow the caller of `MWExceptionHandler::logError()` to specify a severity level and then to adjust `MWExceptionHandler::handleError()` to set an appropriate level. The current implementation in `MWExceptionHandler::logError()` emits all events as severity `error`.
What's the current state of this task? Is it blocked in the log volume being too high? There are a few things we could do about that:
* only log warnings (at least initially), not notices
* sample
* send suppressed errors to a separate channel which can be blackholed
* cut down the number of warnings/notices in production (a lot of that has been happening recently, so maybe it's worth doing another experiment and reassess the situation?)
@bd808 Thanks!

Looks like we're not using `error-json` in Logstash yet. For PHP Notice and Warning events, Logstash uses the apache2/hvvm source still (which doesn't have stack traces). Currently blocked on T88732.
@bd808 Thanks!

Looks like we're not using `error-json` in Logstash yet. For PHP Notice and Warning events, Logstash uses the apache2/hvvm source still (which doesn't have stack traces).
@bd808 Thanks!

Looks like we're not using `error-json` in Logstash yet. For PHP Notice and Warning events, Logstash uses the apache2 error_log source still (which doesn't have stack traces).
Change 177096 merged by jenkins-bot:
exception: Hide suppressed errors in 'error' log, flag in 'error-json'

[[https://gerrit.wikimedia.org/r/177096]]
Change 177095 merged by jenkins-bot:
exception: Implement error-json log

[[https://gerrit.wikimedia.org/r/177095]]
Change 177096 had a related patch set uploaded (by Krinkle):
exception: Hide suppressed errors in 'error' log, flag in 'error-json'

[[https://gerrit.wikimedia.org/r/177096]]

#patch-for-review
Change 177095 had a related patch set uploaded (by Krinkle):
exception: Implement error-json log

[[https://gerrit.wikimedia.org/r/177095]]

#patch-for-review
As of 399ba2fecf, MediaWiki has a new debug log group called "error" (similar to "exception" log we've had for years).

Its entries are PHP Notices, PHP Warnings etc.. These always went (and still go) to PHP stderr (and apache's error log), but are historically lacking stack traces. 399ba2fecf hooks into PHP's error handler and produces a stack traces and forwards it to the new log.

@Reedy and I enabled ([[ https://gerrit.wikimedia.org/r/#/c/173649/ | b4ace9661a ]]) this in production at Amsterdam Hackathon 2014 but it was disabled ([[ https://gerrit.wikimedia.org/r/#/c/173655/ | 82139373383c ]]) as it generated too much data on `fluorine` (1.5G in under 15 minutes).
As of 399ba2fecf, MediaWiki has an new debug log group called "error" (similar to "exception" log we've had for years).

Its entries are PHP Notices, PHP Warnings etc.. These always went (and still go) to PHP stderr (and apache's error log), but are historically lacking stack traces. 399ba2fecf hooks into PHP's error handler and produces a stack traces and forwards it to the new log.

@Reedy and I enabled ([[ https://gerrit.wikimedia.org/r/#/c/173649/ | b4ace9661a ]]) this in production at Amsterdam Hackathon 2014 but it was disabled ([[ https://gerrit.wikimedia.org/r/#/c/173655/ | 82139373383c ]]) as it generated too much data on `fluorine` (1.5G in under 15 minutes).
I wonder if we should close this. There's going to need to be some work to port this log into logstash, but that should be a different task. Also, knowing how much disk space it's going to use over a 24 hour period would be useful. The logs should certainly be very compressible...
The ability to log backtraces in php errors was added in https://gerrit.wikimedia.org/r/#/c/173642/ .
It was enabled in production in https://gerrit.wikimedia.org/r/#/c/173649/ and disabled again in https://gerrit.wikimedia.org/r/#/c/173655/ , because it was using "up 680M in under a minute".

Having backtraces enabled is a huge help. So they should be enabled permanently and also sent into logstash.
Grabbing stack traces for warnings should be possible with a custom error handler and debug_backtrace() or ErrorException. It should probably be put behind a feature flag of some sort so that deployments that don't care about tracking warnings don't incur the performance penalty of generating the backtrace.
The above might be from xdebug..
[Parsoid component reorg by merging JS/General and General. See bug 50685 for more information. Filter bugmail on this comment. parsoidreorg20130704]
Much of this is now resolved. [foo] is no longer nowiki-escaped, but [''foo''] is due to the apostrophes.

There is still some room for (minor) improvement by moving the nowiki inside the brackets, although in some cases it is actually easier to read to wrap an entire line in nowiki instead of several nested nowikis.
Note about the lost "'''" in the example above: that is a different bug unrelated to nowiki-escaping -- it should be fixed after the ongoing serializer refactor is complete.
https://gerrit.wikimedia.org/r/49190 added URL validation in the tokenizer
based on the wiki's configured URL protocols. This now makes the nowiki escaping more precise and fixes the snippet in this bug report.

[subbu@earth lib] echo '[[Link target|These are '''just''' [normal brackets]]]' | node parse --wt2wt
[[Link target|These are just [normal brackets]]]

However, this wont be visible in the VE yet till a new deploy of Parsoid (another couple weeks, I expect).
The problem is that till templates are expanded, it is hard to know whether the content of a "[..]" is going to a link or not.  That is the reason the tokenizer defers decisions for all [..] content till all templates are expanded so it can all be handled in a single place.

But, there is another ticket for addressing this a bit more selectively which should address nowiki situations like this: https://bugzilla.wikimedia.org/show_bug.cgi?id=44449 --
I believe adding illogical nowiki markup is somewhat irritating to existing editors.

Perhaps a simple solution: Is there any justification for the tokenizer to consider an opening [ as a token? I believe only [http://, [https://, [irc://, [ircs://, [ftp://, [news://, [mailto: and [gopher:// should be external link tokens.
One underlying issue is that our tokenizer is relatively liberal in what it accepts as an external link target, while a stricter validation is applied after templates etc are expanded. Our wikitext escaper also makes use of the tokenizer (plus some regexps), but does not (yet) consider external links that turn out to have invalid targets.

Current output:

echo "[[Link target|These are '''just''' [normal brackets]]]" | nodejs parse --wt2wt
[[Link target|These are '''just'''<nowiki> [normal brackets]</nowiki>]]
This refers to behaviour that has now changed such that this is no longer actionable, so marking as INVALID.
Code has been merged.
I believe that this is now fixed given the changes in Parsoid and in how VE talks to it; marking as such.
This has been fixed by Ie8a35700bc9e in mediawiki core.

In the current configuration however out tabLayout is in "add" more (when this bug was reported, we were still in "replace" mode).

In "add" mode we add an extra tab for "VisualEditor", so the original "Edit" is still there, which is the default. And double-clicking in the content area will (as it should) trigger the original editor.

If/when we enable the "replace" mode again, since this bug is fixed, double-clicking will trigger VisualEditor as expected.

So, although it can't be seen right now, as the feature is not activated right now, this bug as been fixed.

To verify, edit ve.init.mw.ViewPageTarget.js and set `this.tabLayout = "replace";`.
Bumping; didn't make it to 2013-01-16.
Cannot reproduce this without a deep stack trace; also, this is from three months ago, and we're unlikely to still have the same issue.
Max - any update on this? Can you reproduce when using debug=true (so we might have a hope of finding the underlying cause)?
Cannot reproduce this without a deep stack trace; also, this is from three months ago, and we're unlikely to still have the same issue.
We're scrapping this feedback system, so marking as INVALID.
I'm watching this bug.  Parsoid does support CORS headers via a configuration in localsettings.js (although maybe not yet on this particular response), so if you do decide to fix this on the parsoid end let me know.
De-prioritising and pulling from target milestone.
Related URL: https://gerrit.wikimedia.org/r/61035 (Gerrit Change Idebb147ee03ad956cd0f3826c304db65eed1e34e)
Fixed and being deployed today.
Related URL: https://gerrit.wikimedia.org/r/60911 (Gerrit Change Iec91b30422017ce9d71bc71b2cbeb71688e0d18f)
Related URL: https://gerrit.wikimedia.org/r/60899 (Gerrit Change I0e55faca4eabe910d9b4d8ca8c6b4b0bd42e8539)
(In reply to John Broughton from comment #5)
> (In reply to John Mark Vandenberg from comment #4)
> 
> I think we've wandered off topic, for which I'll take some responsibility.
> The issue is NOT links to redirect pages, which (typically as hatnotes) can
> be absolutely correct. Rather, the problem is wikilinks to redirect pages
> **that are marked as being for misspellings**.

Thanks for clarifying your solutions are for misspelling redirects only.

What I was focusing on was the underlying problem that the software does not have a good way to determine which redirects are marked as misspellings?  And the concept of misspelling is IMO too complex to be built into the mediawiki layer.

Surely not by looking for [[Template:R from misspelling]] or [[Category:Redirects from misspellings]] (as was done for disambiguation pages)

__MISSPELLING__ ?  That would be equally odd.

Bug 13595 is an interesting idea that records per-redirect custom messages to be used in one context (above target article), but the same approach may be used to provide custom messages to other contexts (such as in VE).

Another approach may be to add misspellings to Wikidata, preferably as a misspellings attribute on the target Qs (similar to labels), rather than have redirects as distinct items in Wikidata (as was done for dab pages).
(In reply to John Mark Vandenberg from comment #4)

I think we've wandered off topic, for which I'll take some responsibility. The issue is NOT links to redirect pages, which (typically as hatnotes) can be absolutely correct. Rather, the problem is wikilinks to redirect pages **that are marked as being for misspellings**. So, let me reword the four alternatives I gave, above, to (hopefully) make this clearer.

In articlespace (only):

1. The software adds an administrative category, "Articles with wikilinks to redirect pages for misspellings", when an article is saved that has one or more of these problematical links.

2. Links to redirect pages for misspellings are shown in yellow, both when previewing an edit and after saving the page. (With VisualEditor, the yellow coloring would appear immediately after typing the wikilink, which is ideal.) However, the editor can save the page with the (problematical) wikilink still on it.

3. The software issues a warning when an editor tries to save a page with a link to a redirect page used to fix a misspelling, but allows the editor to override this. (Misspelled wikilinks need to be highlighted, of course; the software could also make it easy to accept a spelling change, since the redirect page points to the correct spelling of the article being linked to)

4. The software issues a warning when an editor tries to save a page with a link to a redirect page for a misspelling, and prevents the editor from overriding this. (Misspelled wikilinks need to be highlighted, of course.)

** Addendum:** 

I'll also note that since we're concerned with *what the reader sees*, we should ignore wikilinks where a pipe is used, since the software can't (easily) determine if what the reader sees is correct:  [[wikilink to redirect|possibly correctly spelled text]].
(In reply to John Broughton from comment #3)
> Google translate didn't turn Comment 2 into anything meaningful for me, so
> here are four alternative solutions, which could be implemented in the
> software, one or more of which may already have been suggested above (in
> Polish).
> 
> ...
> 
> Alternatives #1, #2, and #3 are compatible; all could be implemented
> together. Alternative #4 is problematical in that an editor who is doing a
> minor change might be blocked from saving that change even though he/she had
> nothing to do with creating the wikilinks that go to redirects, and he/she
> may not understand how to correct this. (Think of a relatively new editor,
> or an IP editor.)
> 
> Implementing #1 would be invisible to the reader; #2 might cause a bit of
> confusion.

These solutions all presume that *every* link to a redirect is problematic.  If that is what the software presumes, it will cause more problems than it solves.  There are many instances where a link to a redirect page is appropriate.  If they are categorised into a maintenance category, some idiot will try to 'fix' them.  If it is more difficult to link to redirects using the VE UI, competent editors will complain bitterly.

> *** Or someone could just create a bot that notifies editors that they've
> made a mistake with their wikilink - as does DPL bot, for links to
> disambiguation pages. ***

This would be helpful, and the bot author could adapt the logic to understand when links to redirects are desirable.  For redirects categorised as spelling mistakes, a bot could also fix them automatically.
Google translate didn't turn Comment 2 into anything meaningful for me, so here are four alternative solutions, which could be implemented in the software, one or more of which may already have been suggested above (in Polish).

In articlespace (only):

1. The software adds an administrative category, "Articles with wikilinks to redirect pages", when an article is saved that has one or more problematical links.

2. Links to redirect pages are shown in yellow, both when previewing an edit and after saving the page. (With VisualEditor, the yellow coloring would appear immediately after typing the wikilink, which is ideal.) However, the editor can save the page with the (problematical) wikilink still on it.

3. The software issues a warning when an editor tries to save a page with a link to a redirect page, but allows the editor to override this. (Problem wikilinks need to be highlighted, of course.)

4. The software issues a warning when an editor tries to save a page with a link to a redirect page, and prevents the editor from overriding this. (Problem wikilinks need to be highlighted, of course.)

Alternatives #1, #2, and #3 are compatible; all could be implemented together. Alternative #4 is problematical in that an editor who is doing a minor change might be blocked from saving that change even though he/she had nothing to do with creating the wikilinks that go to redirects, and he/she may not understand how to correct this. (Think of a relatively new editor, or an IP editor.)

Implementing #1 would be invisible to the reader; #2 might cause a bit of confusion.

*** Or someone could just create a bot that notifies editors that they've made a mistake with their wikilink - as does DPL bot, for links to disambiguation pages. ***
>>! In T44653#480329, @Nemo_bis wrote:
> Every time I look (e.g. on webpagetest.org), I always find one or two "failing" load.php calls however I test it. Usually it's the CentralNotice taking too much

From looking at the original description I tend to think it was a CentralNotice issue indeed. On the other hand, bannercontroller stuff was refactored in the meanwhile.
Closing for now as most likely the original cause can no longer cause a page to take 12 seconds to load given the following major changes that have happened since then.

* Switch to HTTPS and HTTP/2 made bits re-use the same connection instead of establishing a new connection, thus speeding things up and reducing the changes that a connection gets cut off.
 * {T96848}
 * {T94896}
 * {T95448}
 * ..
* Since then, bits itself has been folded into the main domains entirely, further optimising this re-use: 
 * {T107430}
* Since then, we've also reduced the number of requests that block rendering and page-ready
 * {T107399}
@Nemo_bis: I'm asking anybody in the CC list as someone might have faced the same problem in that IP range. 
If I had asked anybody specifically, I would have prefixed a name. :)
> Does this problem still happen nowadays?

Who are you asking? The reporter is one of those made into ghosts by the bugzilla murder.
Does this problem still happen nowadays?
> We no longer use bits to serve this content. So this can probably be closed now ?

What makes you think the issue was caused by the fact of being served from that domain?
We no longer use bits to serve this content. So this can probably be closed now ?
**bugzilla.wikimedia.org.76374** wrote:

Here is a Chrome plugin that provides a workaround:

https://chrome.google.com/webstore/detail/wikipedia-speedup/ppmagkdpdaaabpmdppckemgkngkpchdl?hl=en
(In reply to Macavity from comment #19)
> This happens reliably on the IP range my ISP uses (looks like
> 86.141.0.0/16), when jqueryMsg is in the query string:
> 
> This times out:

Works for me as I get a cached response /* cache key: enwiki:resourceloader:filter:minify-js:7:519abda9a1640250a7c561ccfd0f22f8 */
I don't see ongoing CentralNotice campaigns for UK.
This happens reliably on the IP range my ISP uses (looks like 86.141.0.0/16), when jqueryMsg is in the query string:

This times out:

http://bits.wikimedia.org/en.wikipedia.org/load.php?debug=false&lang=en&modules=ext.centralNotice.bannerController%7Cext.centralauth.centralautologin%7Cext.uls.init%2Cinterface%2Cpreferences%2Cwebfonts%7Cext.visualEditor.viewPageTarget.init%7Cjquery.accessKeyLabel%2CbyteLength%2Cclient%2Ccookie%2CmwExtension%2CtabIndex%2Cthrottle-debounce%2Ctipsy%7Cmediawiki.Title%2CUri%2Capi%2Ccldr%2CjqueryMsg%2Clanguage%2Cnotify%2Cuser%2Cutil%7Cmediawiki.language.init%7Cmediawiki.legacy.ajax%2Cwikibits%7Cmediawiki.libs.pluralruleparser%7Cmediawiki.page.startup%7Cmmv.base%2Chead%7Cskins.vector.js&skin=vector&version=20141031T180422Z&*

This returns:

http://bits.wikimedia.org/en.wikipedia.org/load.php?debug=false&lang=en&modules=ext.centralNotice.bannerController%7Cext.centralauth.centralautologin%7Cext.uls.init%2Cinterface%2Cpreferences%2Cwebfonts%7Cext.visualEditor.viewPageTarget.init%7Cjquery.accessKeyLabel%2CbyteLength%2Cclient%2Ccookie%2CmwExtension%2CtabIndex%2Cthrottle-debounce%2Ctipsy%7Cmediawiki.Title%2CUri%2Capi%2Ccldr%2Clanguage%2Cnotify%2Cuser%2Cutil%7Cmediawiki.language.init%7Cmediawiki.legacy.ajax%2Cwikibits%7Cmediawiki.libs.pluralruleparser%7Cmediawiki.page.startup%7Cmmv.base%2Chead%7Cskins.vector.js&skin=vector&version=20141031T180422Z&*
Every time I look (e.g. on webpagetest.org), I always find one or two "failing" load.php calls however I test it. Usually it's the CentralNotice taking too much, I don't see what can be done in this component.
Correct, comment 14 - comment 17 are a different issue.
Yeah, bits was having issues earlier today. https://wikitech.wikimedia.org/w/index.php?title=Server_Admin_Log&oldid=69483 and http://status.wikimedia.org/8777/156486/Static-assets-(CSS/JS) seem to confirm this. I think separate issues are getting mixed in to a single bug, though.
And little bit more. In my case it is maybe just only DNS updating problem. In my home ip bits.wikimedia.org resolves to  91.198.174.233, 2620:0:862:ed1a::a,  bits.esams.wikimedia.org.

In .kapsi.fi where everything is working fine bits.wikimedia.org resolves to  2620:0:861:ed1a::a, 208.80.154.234, bits-lb.eqiad.wikimedia.org
Bug 39322 came to my mind, so I'd still appreciate the output of the following commands

traceroute bits.wikimedia.org

curl -i http://bits.wikimedia.org/
**bugzilla.wikimedia.org.76374** wrote:

Andre: we have already determined that it is a problem related to the source ip range.
**bugzilla.wikimedia.org.76374** wrote:

Look at the screenshot. Just one out of multiple calls to the same script fails. So the routing is definitely ok.
Just realizing that this question still stands:

> Is the routing to the bits servers ok from both ip address ranges?
For me in Firebug that specific call is 51ms and 14.9kb (being logged in), for you 11440ms and 0.0kb.

And in my case the URL is
http://bits.wikimedia.org/en.wikipedia.org/load.php?debug=false&lang=en&modules=ext.centralNotice.bannerController%7Cext.wikimediaShopLink.core%7Cjquery.client%2Ccookie%2CmwExtension%7Cmediawiki.cldr%2CjqueryMsg%2Clanguage%2Cnotify%2Cutil%7Cmediawiki.language.data%2Cinit%7Cmediawiki.legacy.ajax%2Cwikibits%7Cmediawiki.libs.pluralruleparser%7Cmediawiki.page.startup%7Cwikibase.client.init&skin=vector&version=20130311T110922Z&*
**bugzilla.wikimedia.org.76374** wrote:

screenshot of timeout in firebug

**Attached**: {F10260}
**bugzilla.wikimedia.org.76374** wrote:

Yes, it is still a problem. See the screenshot.
As we've changed data centers in late January and the related setup, could you please test if this is still a problem?
Fixed upstream, will be in 1.21wmf9.
It seems like this task is sort of obsoleted by {T102398} and its blockers+dependencies.
I came here just for this after too often accidentally publishing an incomplete or undescribed edit. It's really frustrating to me as a user that it's not easily possible to see if pressing the "Publish changes" button will take me to an intermediate step allowing review and description or if it will publish the changes immediately. 

This issue has been open for 5+ years now. Please take action to differentiate the text on the two buttons so it's possible to distinguish whether pressing them will publish something immediately or not.
> for example, we can provide an access to preview as an additional mode in the menu we provide access to "Visual editing" and "Source editing".

I provided mockups demonstrating something like this in [[#3274084|a previous message]].
I feel like unfortunately we already have enough tasks open about how long translations look ugly and make the interface potentially difficult to use. "..." is a good compromise that I really endorse.
@dialmove's suggestion above to rename the button to "Review and publish" would also be a simple way to improve things.

The downside is that the space for the button is limited, and the text can already be fairly long in some languages. E.g. in Hungarian "Publish changes" is "Változtatások közzététele"; "Review and publish" would be something like "Változtatások áttekintése és közzététele".

Maybe just change to "Review" and rely on the constructive colors to tell the user that's the next step?
> I'd like to understand better the specific issues that the uncertainty about "whether 
> the save button saves immediately" generates. 

From observing the users and further corroborated by the comments on Kurier 

1. Users, particular experienced ones, seem to rely a lot on previewing before they save, so they want to preview //before// they save and create an entry in the history.
2. In the current UI, the only way to preview is clicking a button that indicates it does something they want to avoid: Saving directly.

Thus there is a problem. Adding … does not solve all the problems. But it alleviates point 2: It indicates that clicking "publish changes" does //not// do immediately what they want to avoid.
>>! In T44138#3578131, @Jan_Dittrich wrote:
> Who is the one to decide about this?

Me. I'm watching this task. :-)

This is far from the most pressing item on the agenda, but I do agree with the statement of the problem. I like the ellipsis idea; it's not perfect, but it's easy to implement, is at least step in the right direction, and can easily be iterated on. I think more discussion about other solutions would be good.
You may consider my feedback withdrawn. I didn't make the connection with the operating system conventions. I have indeed used many applications that use ellipsis in context menus or top menus for items to indicate they won't be performed immediately but will require an additional interaction first (e.g. new dialog, or next panel if already in a dialog).

Before I realised this connection, my main concern was that adding ellipsis would not solve the original problem, which is that users may be uncomfortable clicking this button because they may want to do a comparison first or enter an edit summary, and the current appearance of the button suggests it will be immediate. Adding ellipsis does make sense for this and might a good first step toward solving this problem.
It seems that 
* An ellipsis is standard in many UI guidelines, including Mac and Windows (as @Tgr wrote). It is an UI standard at least since the 90s and basically the icon for "a window will open".
* The only feedback I remember that was contra ellipsis itself came from @Krinkle ("It doesn't clarify or improve the user experience, it only makes it more mysterious."). 
* The  character could be either included via CSS or in the translation messages.  
* The "does the save button save immediately?!" is an actual problem (at least according to German Kurier and feedback on enwiki according to @TTO )

With ellipsis, it would look like 

{F7336409}

@Pginer-WMF – what do you think? And: Who is the one to decide about this?
Yep, I’ve put the word ‘Done’ in my mockups.
What about "Complete...", "Final review" or similar term to indicate the button will lead to the publication, but not being a "Publish" button?
Related to this, there is an [[ https://de.wikipedia.org/w/index.php?title=Wikipedia:Kurier&oldid=166132048 | article on the German signpost equivalent "Kurier" ]], in which as user talk about having trouble finding the save button and difficulties on clicking on "save", assuming it might save directly. 

> »Zunächst einmal sucht man vergeblich einen Knopf für die Vorschau.  Wie heißt es doch: „Sei mutig!“ Wir drücken also einfach ohne Vorschau auf „Änderungen speichern“ «

> Roughly translated: »We search unsuccessfully of the "preview" Button … They say "Be brave" and we press without preview on "Save Changes"«
@Frigory, @Jan_Dittrich: There is a task for this, where all this stuff should probably go, please see T155732
Hi @Frigory, Hi @Dvorapa,

I like these ideas! I suppose they should have their own ticket. The current ticket was just meant to make the button actions clearer. Your suggestion extends the scope a lot. 
Can you copy it in a separate tasks and mention this one (T44138)? Thus they would be kept connected and allows each one to focus on the button, two column view or both. 
If you need help doing it, please write me or tell here.
So I could imagine something like this.

- Possibility to have frames in the same dropdown, and an additional option for separate scrollbars: {F8119433}
- A dropdown in the top right-hand corner of each frame to choose its content: {F8119439}
- The splitted view: {F8119442} (the bar at the middle can be moved)
- In the content selection, a ‘Switch panels’ option (I don’t know if the correct word should be ‘frame’ or ‘panel’), and the content of the other panel is grayed; also, a ‘Refresh’ button for the preview: {F8119451}

Of course there should be other icons (‘Refresh’ should be an icon).

This way the toolbar is even shorter than before, because ‘Done’ is shorter than ‘Publish changes’ — :).
No, if I add just a button with "Preview" and dropdown arrow, the symbol button is moved to the second line. The problem of a space in a toolbar or why text labels should be avoided was discussed in detail in T116417 or T153306 or above I guess.
No, if I add just a button with "Preview" and dropdown arrow, the symbol button is moved to the second line. The problem of why text labels should be avoided due was discussed in detail in T116417 or T153306 or above I guess.
- Separate scrollbars could be a preference.
- Indeed separate toolbars and dialogs are probably a bad idea.
- I don’t understand why the Preview dropdown wouldn’t be convenient? You don’t have enough space for it?
@Frigory I'm not a dev, but I like your proposals (I've already suggested some of them in a different task). Just be aware of those people with more narrow screens (like me - 1280x768), where those features like separate scrollbars, separate toolbars/dialogs and text "Preview" as a dropdown label are not very convenient.
@Liuxinyu970226 That should be possible with CSS or HTML/CSS without big issues if requested and agreed upon.
>>! In T44138#3171667, @Tgr wrote:
>>>! In T44138#3171527, @Elitre wrote:
>> Do we know if there's an equivalent for the ellipsis for every language we support?
> 
> Looking at the translations for the [[https://translatewiki.net/w/i.php?title=Special:Translations&message=MediaWiki%3AEllipsis|ellipsis]] and some messages containing it ([[https://translatewiki.net/w/i.php?title=Special%3ATranslations&message=Watching&namespace=8|1]], [[https://translatewiki.net/w/i.php?title=Special%3ATranslations&message=Moredotdotdot&namespace=8|2]]) it would seem so.

Would it be possible to migrate all ellipsis of MediaWiki core and extensions in all languages to use "…" (by default, i.e. if we don't provide translations), which can help extract a lot?
On desktop it's very widely used. See e.g. [[https://msdn.microsoft.com/en-us/library/windows/desktop/bb226792(v=vs.85).aspx|Microsoft]] and [[https://developer.apple.com/library/content/documentation/UserExperience/Conceptual/OSXHIGuidelines/TerminologyWording.html#//apple_ref/doc/uid/20000957-CH15-SW3|Apple]] button design guidelines.
>I'm not sure the standard is used in this way. It is used in dropdown menus, but I don't think it is common in push buttons. I certainly don't recall seeing it in web "call to action-style" buttons, ever.

Yes, it is not very widely used on buttons. Checking some applications (Libreoffice and Ubuntu System  Settings), I found that: 
* Few of the buttons I checked open new windows/popups anyway (makes sense, I assume, a button usually triggers an action)
* For the buttons which open a new window, several had "…"  (In Setting: "Network"/"use as hotspot…" ; "Language Support"/"install / remove Languages…"; "Security and Privacy"/ "Files & Applications"/ "Clear Usage Data…")

So, not //widely// used, but used, if it opens new windows. 

 I think it would be an improvement.
>>! In T44138#3162853, @Jan_Dittrich wrote:
>> Roan suggested perhaps changing "Save page" to read "Save page...", which would give the user a clue that it's going to be a process, not an immediate action.
> 
> I think this would make sense – it is an established UI standard and can be found in many desktop applications. 
> I would love to see an improved wording on the button itself, but util then, I’d go with …

I'm not sure the standard is used in this way. It is used in dropdown menus, but I don't think it is common in push buttons. I certainly don't recall seeing it in web "call to action-style" buttons, ever.

>>! In T44138#2087472, @Tgr wrote:
> The whole save/preview/edit summary interface feels clunky and getting the way. I don't have a constructive suggestion, it's a rather straightforward way of handling saving in a WYSIWYG editor - but it does not feel right, and I hear others complaining about it as well.

I think a large part of the weird feeling is having the button at the top of the screen. "Submit" buttons are typically at the bottom of the page, below the form they complete, to go with the reading flow (see this very interface as an example).
>>! In T44138#3162853, @Jan_Dittrich wrote:
>> Roan suggested perhaps changing "Save page" to read "Save page...", which would give the user a clue that it's going to be a process, not an immediate action.
> 
> I think this would make sense – it is an established UI standard and can be found in many desktop applications. 
> I would love to see an improved wording on the button itself, but util then, I’d go with …

I'm not sure the standard is used in this way. It is used in dropdown menus, but I don't think it is common in push buttons. I certainly don't recall seeing it in web "call to action-style" buttons, ever.
>>! In T44138#3171527, @Elitre wrote:
> Do we know if there's an equivalent for the ellipsis for every language we support?

Looking at the translations for the [[https://translatewiki.net/w/i.php?title=Special:Translations&message=MediaWiki%3AEllipsis|ellipsis]] and some messages containing it ([[https://translatewiki.net/w/i.php?title=Special%3ATranslations&message=Watching&namespace=8|1]], [[https://translatewiki.net/w/i.php?title=Special%3ATranslations&message=Moredotdotdot&namespace=8|2]]) it would seem so.
@Elitre: To better understand the concern – is this about the problem that users may see a rectangle because their fonts don't support "…" or about the users not understanding what "…" means in that context?
Do we know if there's an equivalent for the ellipsis for every language we support?
> Roan suggested perhaps changing "Save page" to read "Save page...", which would give the user a clue that it's going to be a process, not an immediate action.

I think this would make sense – it is an established UI standard and can be found in many desktop applications. 
I would love to see an improved wording on the button itself, but util then, I’d go with …

Would look like: 
{F7336409}
> Roan suggested perhaps changing "Save page" to read "Save page...", which would give the user a clue that it's going to be a process, not an immediate action.

I think this would make sense – it is an established UI standard and can be found in many desktop applications. 

Would look like: 
{F7336409}
A very typical wording would be "Review and save" (or "Review and publish"). It shouldn't be merely "Save" or "Publish", since the page is not immediately saved when pressing it.
"Ready to save"?
Maybe there should be something like "Proceed to save" instead...
I like the save process for the most part.  I agree this (initial label that opens the dialog) could potentially be changed, but in practice it's not really a problem as is.
The whole save/preview/edit summary interface feels clunky and getting the way. I don't have a constructive suggestion, it's a rather straightforward way of handling saving in a WYSIWYG editor - but it does not feel right, and I hear others complaining about it as well.
**swalling** wrote:

This is being discussed on enwiki as well, at https://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28technical%29#VE_.22save.22_vs_.22finish_edit.22_button
There have been a lot of complaints about this on the enwiki feedback page. One especially interesting point was raised by the ever-wise John Broughton:

> ["Save page"] is the same label as on the button, in the old editing interface, that completed the edit session. Lots of effort has been made, over the years, to encourage editors to write an edit summary before they click "Save page", and now VE is designed exactly the opposite. The button ought to be labeled "Finish edit" or "Continue" or "Final steps" or just about anything other than "Save page".
> The current problem is even worse than just one poorly labeled button. In VE, after clicking "Save page", a dialog box appears that also has a "Save page" button. So now an editor has to understand that the two "Save page" buttons do not do the same thing. And documentation (when it's written) is going to have to clarify which "Save page" button is being referred to - unless the label on the first occurrence of "Save page" is changed, as it should be.

The button label on enwiki was modified to "Finish edit" per [[MediaWiki:Visualeditor-toolbar-savedialog]].
There have been a lot of complaints about this on the enwiki feedback page. One especially interesting point was raised by the ever-wise John Broughton:

> ["Save page"] is the same label as on the button, in the old editing interface, that completed the edit session. Lots of effort has been made, over the years, to encourage editors to write an edit summary before they click "Save page", and now VE is designed exactly the opposite. The button ought to be labeled "Finish edit" or "Continue" or "Final steps" or just about anything other than "Save page".

> The current problem is even worse than just one poorly labeled button. In VE, after clicking "Save page", a dialog box appears that also has a "Save page" button. So now an editor has to understand that the two "Save page" buttons do not do the same thing. And documentation (when it's written) is going to have to clarify which "Save page" button is being referred to - unless the label on the first occurrence of "Save page" is changed, as it should be.

The button label on enwiki was modified to "Finish edit" per [[MediaWiki:Visualeditor-toolbar-savedialog]].
There have been a lot of complaints about this on the enwiki feedback page. One especially interesting point was raised by the ever-wise John Broughton:

---
["Save page"] is the same label as on the button, in the old editing interface, that completed the edit session. Lots of effort has been made, over the years, to encourage editors to write an edit summary before they click "Save page", and now VE is designed exactly the opposite. The button ought to be labeled "Finish edit" or "Continue" or "Final steps" or just about anything other than "Save page".

The current problem is even worse than just one poorly labeled button. In VE, after clicking "Save page", a dialog box appears that also has a "Save page" button. So now an editor has to understand that the two "Save page" buttons do not do the same thing. And documentation (when it's written) is going to have to clarify which "Save page" button is being referred to - unless the label on the first occurrence of "Save page" is changed, as it should be.
---

The button label on enwiki was modified to "Finish edit" per [[MediaWiki:Visualeditor-toolbar-savedialog]].
I agree the toolbar button needs improvement, but imho changing the label from "Save page" to "Save page..." is not an improvement.

It doesn't clarify or improve the user experience, it only makes it more mysterious.

I'd prefer we look for another solution, but I think the current situation is better than having "..." tacked on to the label.
Setting milestone to 2013-06-27 since it is marked as blocker for "Beta" (2013-07). It may be moved to an earlier milestone as we see fit. But no later than 06-27. Setting it since I use milestone to sort "My bugs".
Filing without prejudice as to whether we should implement.
I'm assuming that this is a high level tracking purpose ticket.
**orbit** wrote:

Any details?
Change 283443 merged by jenkins-bot:
Update RangeFix to 0.2.0

[[https://gerrit.wikimedia.org/r/283443]]
Change 283443 had a related patch set uploaded (by Esanders):
Update RangeFix to 0.2.0

[[https://gerrit.wikimedia.org/r/283443]]
Fixed in RangeFix: https://github.com/edg2s/rangefix/pull/4
getClientRects (native function) is messed up in IE10 and below when the zoom level is not 100%, it looks like it's applying the zoom factor twice. It may be able to fix it using screen.deviceXDPI / screen.logicalXDPI to calculate the zoom level - maybe this can be done upstream in RangeFix...
You would think our code would have changed a lot in the past two years, but this bug is still reproducible. It doesn't happen in IE11 though.
Dhaval: There was a recent fix to the client test module here:
https://gerrit.wikimedia.org/r/#/c/45183/ Which was deployed on Tuesday.

This fixed a problem with VisualEditor being enabled in IE despite it being configured to be disabled for all versions of Internet Explorer during this deployment.

However, there is a recent patch to enable VisualEditor in IE9 and above.
https://gerrit.wikimedia.org/r/#/c/45233/
Which should be rolled out in the next VisualEditor deployment.
I couldn't see the visual editor option at all in IE10. I am using Windows 7 and IE10.0.9200
This seems fixed, but I found bug 54891 when testing it. Not sure whether this should be considered a bug on VisualEditor side or in Parsoid serializer.
This should be fixed now.  The core patch has been merged for some time.  Liangent, can you retest?
There's still a patch in that depends on a core patch. It's not testable on zhwiki until the core patch is deployed. I guess that will happen at wmf11, which is (at most) four weeks away from zhwiki. But it may have fixed this.

If someone could test it locally, it's at https://gerrit.wikimedia.org/r/50814 and the core patch is in the latest mediawiki (from git).
(In reply to comment #7)
> We could do so, but it is pretty low priority for us. Note that you can also
> point the web service to a page in the user namespace like this:
> 
> http://parsoid.wmflabs.org/zh/User:Liangent/Test

Now linkprefix is applied incorrectly. Still the same use case: [[中]]cjk[[文]]

Expected: [[中]]cjk[[文]]

Actual: [[中]][[文|cjk文]]
We could do so, but it is pretty low priority for us. Note that you can also point the web service to a page in the user namespace like this:

http://parsoid.wmflabs.org/zh/User:Liangent/Test
(In reply to comment #5)
> We have switched to use per-language link trail (and prefix) regexps now with
> https://gerrit.wikimedia.org/r/#/c/48589/. Our HTML form defaults to English
> settings, but testing on a test page from the Chinese Wikipedia has a good
> chance of working. Can you verify that the test cases above are now fixed?

Can you make that HTML form accept an extra "language" option?
We have switched to use per-language link trail (and prefix) regexps now with https://gerrit.wikimedia.org/r/#/c/48589/. Our HTML form defaults to English settings, but testing on a test page from the Chinese Wikipedia has a good chance of working. Can you verify that the test cases above are now fixed?
(In reply to comment #3)
> Liangent, how well does the new regexp work for Chinese?

[[中]]cjk[[文]]

This gets linktrailed which are usually not wanted. I believe there're some real world use cases on zhwiki as we usually don't put a space between Chinese and embedded English words.
This specific example is working now as we have extended our negative char class to include something very close to the union of the complements of per-language character classes. This is a bit of a departure from default MediaWiki behavior, but might not be noticeable in practice. 

We'd get consistent link trail behavior across languages if this works ok. If it does not, we'd have to revert to traditional per-language regexps.

Liangent, how well does the new regexp work for Chinese?
(In reply to comment #7)
> Looks done in Gerrit change #46668?

Whoops, sorry, yes, we didn't mark this bug as fixed then. Resolved since the 4 February roll-out.
Looks done in gerrit 46668?
I've created a gadget for this:
https://en.wikipedia.org/wiki/Special:Preferences#mw-prefsection-gadgets
Currently inside the Testing and development section

It should work for all versions of Safari, most recent versions of Chrome (though less optimal), some versions of Firefox (support is a bit sketchy there).

https://developer.microsoft.com/en-us/microsoft-edge/platform/status/positionsticky/
https://bugzilla.mozilla.org/show_bug.cgi?id=886646
https://bugzilla.mozilla.org/show_bug.cgi?id=975644
https://bugs.chromium.org/p/chromium/issues/detail?id=231752
https://developers.google.com/web/updates/2016/12/position-sticky
https://bugs.chromium.org/p/chromium/issues/detail?id=702927
I've created a gadget for this:
https://en.wikipedia.org/wiki/Special:Preferences#mw-prefsection-gadgets
Currently inside the Testing and development section

It should work for all versions of Safari, most recent versions of Chrome (though less optimal), some versions of Firefox (support is a bit sketchy there).

https://developer.microsoft.com/en-us/microsoft-edge/platform/status/positionsticky/
https://bugzilla.mozilla.org/show_bug.cgi?id=886646
https://bugs.chromium.org/p/chromium/issues/detail?id=231752
https://developers.google.com/web/updates/2016/12/position-sticky
https://bugs.chromium.org/p/chromium/issues/detail?id=702927
*** Bug 53358 has been marked as a duplicate of this bug. ***
http://datatables.net/extras/fixedheader/

and 

http://css-tricks.com/persistent-headers/

are some of the nicest implementations i have seen so far. both require cloning the headers, which is currently not possible with sortable tables.

I think that if we would want to do this, we should split of the thead and tableheader normalization of tablesorter into it's own module and reuse that for fixed headers.
Moving to the right component. You need javascript to dynamically switch the styling of a table header like this.
Moving to the Parser component. I hope this is the right place.

PS: part of https://www.mediawiki.org/wiki/Bug_management/Triage/20130307
Change 234473 abandoned by Krinkle:
Add class rownumbers for tables

Reason:
Closing to reduce review noise. Feel free to re-open once task has settled on a solution.

[[https://gerrit.wikimedia.org/r/234473]]
This may be a starting point to pass on to others interested in this topic:
Articles containing tables with fixed row numbers are in this hidden category: 
*https://en.wikipedia.org/wiki/Category:Article_with_table_with_fixed_row_numbers 

Please add the category to any article I have missed. 

I noticed that the 800 row table with fixed row numbers is now sorting fast for me: 
*http://cannabis.shoutwiki.com/wiki/User:Timeshifter/Sandbox_4 

Later edit: I checked sorting using an 11-year old PC, and I see that sorting took 2 seconds for that very long table of 779 rows. 

On that same 11-year-old PC sorting is fast on lists of around 200 rows. Such as this one that has fixed row numbers: 
*http://cannabis.shoutwiki.com/wiki/Basic_2013_Global_Marijuana_March_city_list

So since country lists on Wikipedia are a little over 200 rows, then this type of CSS will not be a problem, even on old PCs. Country lists are about the longest lists on Wikipedia.
This may be a starting point to pass on to others interested in this topic:
Articles containing tables with fixed row numbers are in this hidden category: 
*https://en.wikipedia.org/wiki/Category:Article_with_table_with_fixed_row_numbers 

Please add the category to any article I have missed. 

I noticed that the 800 row table with fixed row numbers is now sorting fast for me: 
*http://cannabis.shoutwiki.com/wiki/User:Timeshifter/Sandbox_4
Any system of row numbering is fine by me. I saw another list today I would like to add row numbers to: 
*https://en.wikipedia.org/wiki/List_of_minimum_wages_by_country 

Click the header of the hourly PPP minimum wage column to get a list covering the highest to lowest minimum wages by country. USA is around 15th on the list. Not sure since there is no row numbering.

That list though is too wide to use the method I have used in other lists. Such as in this one: 
**https://en.wikipedia.org/wiki/List_of_countries_by_intentional_homicide_rate
It seems there are two feature requests being mixed here:

1. Having a "fixed" column that won't change when the rows are sorted. Typically a column that numbers the rows, which we want to treat separately and not related to the other fields in each row.
2. Not needing to manually maintain the numbers in these rows when editing pages so that you don't have to change all other rows when inserting or re-ordering entries.

The current patch essentially implements a solution for issue 2 (automatically number the rows and render the row's number). It also kind of solves issue 1. It doesn't really preserve the authored cell contents, but rather it reproduces them dynamically in CSS. This still requires manual work and seems fairly limited.

I'd recommend solving these problems separately. Two ideas:

* Allow for automatic numbering of rows. Perhaps by providing syntax in wikitext that would allow a cell in each row to be set as the placeholder for an incrementing number within the current table. Or perhaps by generating the tables with a Lua module? Or by keeping them maintained manually, with perhaps a client-side feature in VisualEditor/WikiEditor to automatically encourage re-indexing the "index number" cell based on a particular marking on the class (e.g. a class on the table, similar to "wikitable" and "sortable").
* Add a feature in tablesorter that allows one of the columns to be marked as "static" (similar to "unsortable") which will preserve that table column as-is regardless of the sorting of the rest of other columns for each row.
Here are some lists with row numbering: 
*https://en.wikipedia.org/wiki/List_of_countries_by_incarceration_rate 
*https://en.wikipedia.org/wiki/List_of_countries_by_intentional_homicide_rate 
*https://en.wikipedia.org/wiki/List_of_countries_by_total_health_expenditure_per_capita 
*https://en.wikipedia.org/wiki/List_of_U.S._states_by_incarceration_rate 

Discovered another problem with the current method of row numbering. Italics used for some of the country names causes the rows to not align the farther down the list one goes. See this list revision: 
https://en.wikipedia.org/w/index.php?title=List_of_countries_by_intentional_homicide_rate&oldid=727879356 
Had to remove the italics to fix it. 

These lists are popular and are maintained since they are in alphabetical order. The row numbering allows rank order to be seen easily with a click of the mouse on the sorting button. 

The problem is that the initial setup of such lists is tedious, and subject to many rules such as no italics, no flag icons, and no references within the chart itself. All break the row alignment. Along with wide tables. So the number of columns has to be limited to allow the charts to be seen correctly on narrower screens.
I put some tables in a sandbox of mine to see if the patch has been implemented in the test release of MediaWiki 1.27.0-wmf.7. 
*https://test2.wikipedia.org/wiki/User:Timeshifter/Sandbox 

The patch has not been implemented in the test release of MediaWiki 1.27.0-wmf.7. 
*https://www.mediawiki.org/wiki/MediaWiki_1.27/wmf.7
I put some tables in a sandbox of mine to see if the patch has been implemented in the test release of MediaWiki 1.27.0-wmf.7. 
*https://test2.wikipedia.org/wiki/User:Timeshifter/Sandbox 

The patch has not been implemented in the test release of MediaWiki 1.27.0-wmf.7.
I put some tables in a sandbox of mine to see if the patch has been implemented in the test release of MediaWiki 1.27.0-wmf.7 (dfe838b). 
*https://test2.wikipedia.org/wiki/User:Timeshifter/Sandbox 

The patch has not been implemented in the test release of MediaWiki 1.27.0-wmf.7 (dfe838b).
Is T113340 (Allow to request modules by CSS classes in content) holding this up? 

I was looking at the proposed patch: 
https://gerrit.wikimedia.org/r/#/c/234473 

Trying to decipher the holdup from the notes there. There are so many tables not being updated because they are in rank order initially.
I checked the Internet Explorer 7 page on Wikipedia: 
https://en.wikipedia.org/wiki/Internet_Explorer_7 

A reference from that article said that IE7's desktop browser share in August 2015 was 0.31%. 
http://marketshare.hitslink.com/browser-market-share.aspx?qprid=2&qpcustomd=0
I was looking at: 
https://gerrit.wikimedia.org/r/#/c/234473 

and a note from Sept 3, 2015 3:31 AM says "Added code to make the rank column always unsortable"

I assume this is added to the column header?:
```class="unsortable" |```

That is necessary to remove the sorting icon from the header. So people will not be confused.
>>! In T42618#1604298, @Timeshifter wrote:
> How does this fail in Internet Explorer 7? Is it just a blank column? If so, that is not important in my opinion. 

Yes, in IE7 and other unsupported browsers (if any), just a blank column will be shown. Or, if you add the numbers as fallback with the `rownumbers-fallback` class, these will be shown, but will be sorted along with the rest of the table, instead of being fixed.
>>! In T42618#1601171, @Schnark wrote:
> Adding a blank column is easy. That's two clicks in Visual Editor, 

It is not immediately intuitive, but it is easy after I figured it out! So it takes exactly 3 steps to add a row-number column to an existing table. See history: 
https://test.wikipedia.org/w/index.php?title=User:Timeshifter/Sandbox4&action=history 
https://test.wikipedia.org/wiki/User:Timeshifter/Sandbox4 

Now that I see how easy it is to add a blank column this is definitely easier than my previous suggestion. I could explain it all in fewer paragraphs than is currently used in [[https://en.wikipedia.org/wiki/Help:Sorting|Help:Sorting]]. See the section currently titled "Auto-ranking or adding a row numbering column (1,2,3) next to a table". 

How does this fail in Internet Explorer 7? Is it just a blank column? If so, that is not important in my opinion.
I'm of the opinion that functions like this should 'just work' and so far none of the proposals I have seen qualify as 'just work'. That means that people will use it incorrectly and there will be confusion. That's not a good experience. I'm also pondering: What would the dialog window look like for this in VE.

As an 'overall picture' kind of guy, i'm just not enthusiastic and I think that we should be careful of 'feature creep' and long term maintenance burden. Sometimes it's better to NOT have a feature, then to add extra complexity.
How about something like `header=Lp` in the top of the table wikitext? So to get Polish numbers and header:
```
{|  lang="pl" header="Lp" class="wikitable sortable rownumbers"
```

>>! In T42618#1601171, @Schnark wrote:
> Adding a blank column is easy. That's two clicks in Visual Editor, or replacing `/^\| /` with `| || ` with the search-and-replace-tool in the WikiEditor toolbar. Given that users are currently willing to add code like on https://en.wikipedia.org/wiki/List_of_U.S._states_by_incarceration_rate#Incarceration_rate_by_state adding a blank column won't scare them away.

I am the one that added the fixed row numbering to that article. It had previously been in rank order, and so it was impossible to update it easily.  I added much more recent numbers that I copied from the data table of a Commons map of US incarceration rates that someone else did. It was in alphabetical order, and not rank order. The Wikipedia article had been using 2009 numbers until I updated it this summer. 

This patch will not be used much if it depends on skilled editors. I don't use Wikieditor. I rarely use the Visual Editor. I barely understand some CSS, and I occasionally have figured out (and soon forgotten) some regex methods in Notepad++ to do complicated replacements within the Unicode wikitext of long lists or SVG images. Very frustrating. I am not a developer like you. I am skilled in other areas. 

Currently, people are adding rank columns that are not fixed. Many of these table lists are way out of date because even a single change messes up the rank order, and the list is soon completely out of order. People stop updating it at all. A fixed row-number column fixes this because then the list can be put in alphabetical order. Alphabetical order is far easier to maintain. Sorting a column instantly produces a list in rank order. If this patch is dead simple to use then hundreds of tables will then be easy to set up and maintain.
How something like `header=Lp` in the top of the table wikitext? So to get Polish numbers and header:
```
{|  lang="pl" header="Lp" class="wikitable sortable rownumbers"
```

>>! In T42618#1601171, @Schnark wrote:
> Adding a blank column is easy. That's two clicks in Visual Editor, or replacing `/^\| /` with `| || ` with the search-and-replace-tool in the WikiEditor toolbar. Given that users are currently willing to add code like on https://en.wikipedia.org/wiki/List_of_U.S._states_by_incarceration_rate#Incarceration_rate_by_state adding a blank column won't scare them away.

I am the one that added the fixed row numbering to that article. It had previously been in rank order, and so it was impossible to update it easily.  I added much more recent numbers that I copied from the data table of a Commons map of US incarceration rates that someone else did. It was in alphabetical order, and not rank order. The Wikipedia article had been using 2009 numbers until I updated it this summer. 

This patch will not be used much if it depends on skilled editors. I don't use Wikieditor. I rarely use the Visual Editor. I barely understand some CSS, and I occasionally have figured out (and soon forgotten) some regex methods in Notepad++ to do complicated replacements within the Unicode wikitext of long lists or SVG images. Very frustrating. I am not a developer like you. I am skilled in other areas. 

Currently, people are adding rank columns that are not fixed. Many of these table lists are way out of date because even a single change messes up the rank order, and the list is soon completely out of order. People stop updating it at all. A fixed row-number column fixes this because then the list can be put in alphabetical order. Alphabetical order is far easier to maintain. Sorting a column instantly produces a list in rank order. If this patch is dead simple to use then hundreds of tables will then be easy to set up and maintain.
>>! In T42618#1598099, @Timeshifter wrote:

> And a blank header is fine for the number column.

I would consider a blank header just because the user was to lazy to add a row for it as bad practice. It's not clear whether that blank header is acceptable for everyone, see matmarex's comment:
>>! In T42618#434067, @matmarex wrote:
>    * In the heading neither "№" nor "#" would be acceptable in, say,
>      Polish (we use "Lp." which is an abbreviation of "ordinal
>      number"), although this might be worked around by just leaving
>      the space empty as tm112 suggests above; I'm not sure if that'd
>      be acceptable for all languages we support in MediaWiki, though.


> If editors are required to add a blank column first this will be used a lot less than it could be. Country lists have over 200 rows. 

Adding a blank column is easy. That's two clicks in Visual Editor, or replacing `/^\| /` with `| || ` with the search-and-replace-tool in the WikiEditor toolbar. Given that users are currently willing to add code like on https://en.wikipedia.org/wiki/List_of_U.S._states_by_incarceration_rate#Incarceration_rate_by_state adding a blank column won't scare them away.
OK, I see that currently it requires an existing blank column. See: 
https://test.wikipedia.org/wiki/User:Timeshifter/Sandbox3

How about "rownumbers" class for adding numbers to an existing blank column? And "autorownumbers" class for adding both the numbers and the column. See:

>>! In T42618#434018, @Yair_rand wrote:
> To just get the fixed numbering column without manually adding cells to each row or using JS, one could use CSS generated-content cells with counters:

But why require an existing column at all? And a blank header is fine for the number column. I used Yair_rand's method without problems on Shoutwiki. I removed the border coloring from his CSS. Maybe some other changes in the CSS too. I don't remember, since it was done a couple years ago. Here is what I did: 
*http://cannabis.shoutwiki.com/wiki/MediaWiki:Common.css 
*http://cannabis.shoutwiki.com/wiki/2013list - see section called "Alphabetical city list".

If editors are required to add a blank column first this will be used a lot less than it could be. Country lists have over 200 rows.
OK, I see that currently it requires an existing blank column. See: 
https://test.wikipedia.org/wiki/User:Timeshifter/Sandbox3

How about "rownumber" class for adding numbers to an existing blank column? And "autorownumber" class for adding both the numbers and the column. See:

>>! In T42618#434018, @Yair_rand wrote:
> To just get the fixed numbering column without manually adding cells to each row or using JS, one could use CSS generated-content cells with counters:

But why require an existing column at all? And a blank header is fine for the number column. I used Yair_rand's method without problems on Shoutwiki. I removed the border coloring from his CSS. Maybe some other changes in the CSS too. I don't remember, since it was done a couple years ago. Here is what I did: 
*http://cannabis.shoutwiki.com/wiki/MediaWiki:Common.css 
*http://cannabis.shoutwiki.com/wiki/2013list - see section called "Alphabetical city list".

If editors are required to add a blank column first this will be used a lot less than it could be. Country lists have over 200 rows.
>>! In T42618#1594012, @Timeshifter wrote:
> What about using "rownumber"? Is that in use on Wikipedia, or other wikis?

`rownumber` in singular or `rownumbers` in plural? But yes, that's probably the best idea.

>>! In T42618#1594246, @TheDJ wrote:
> Hmm, i still find the whole feature somewhat confusing:
> 
> Deployed here:
> https://test.wikipedia.org/wiki/User:TheDJ/T42618

I just added a second example, to both show how it works with an unsortable first column and how it looks like in a different language.

> And it's still purely a stylistic effect, that will rely on people still fixing the fallback values, which of course they won't...

Well, in most cases the fallback values won't be added at all, so users of IE6 and IE7 will see an empty row instead of the rank, which isn't perfect (that's why I think it should be possible to add a fallback), but doesn't hurt much.

> And the whole initial premise of it being 'confusing' that the numbers follow the sort state, is rather an arbitrary valuation as well. I find it confusing if they don't follow the sorting actions personally. I don't know. I'm still not enthusiastic.

In my example of course it doesn't make sense to have a column for the rank in the current order, but for example the table in https://de.wikipedia.org/wiki/Liste_der_Gro%C3%9Fst%C3%A4dte_in_Deutschland uses a hack to add such a fixed rank column, and it does make sense there.

>>! In T42618#1594736, @Timeshifter wrote:
> It seems that the patch does not create a column for the row numbers? Why not? 

Because it doesn't know what to use as heading.
It seems that the patch does not create a column for the row numbers? Why not? 
*https://test.wikipedia.org/wiki/User:Timeshifter/Sandbox2
It seems that the patch does not create a column for the row numbers? Why not? 
https://test.wikipedia.org/wiki/User:Timeshifter/Sandbox2
https://test.wikipedia.org/wiki/User:TheDJ/T42618

> And the whole initial premise of it being 'confusing' that the numbers follow the sort state, is rather an arbitrary valuation as well. I find it confusing if they don't follow the sorting actions personally. I don't know. I'm still not enthusiastic.

I suggest that the patch remove the sorting icon from the rank column. Then people are more likely to figure out that the rank column is not supposed to sort, nor change at all. The patch needs to add the "unsortable" class to the rank column header. See how here:
*https://en.wikipedia.org/wiki/Help:Sorting#Making_a_column_unsortable
Hmm, i still find the whole feature somewhat confusing:

Deployed here:
https://test.wikipedia.org/wiki/User:TheDJ/T42618

And it's still purely a stylistic effect, that will rely on people still fixing the fallback values, which of course they won't...

And the whole initial premise of it being 'confusing' that the numbers follow the sort state, is rather an arbitrary valuation as well. I find it confusing if they don't follow the sorting actions personally. I don't know. I'm still not enthusiastic.
What about using "rownumber"? Is that in use on Wikipedia, or other wikis?

"mw-" is used for mw-collapsible and mw-collapsed on Wikia:
*http://community.wikia.com/wiki/Help:Collapsing 

But not on Wikipedia: 
*https://en.wikipedia.org/wiki/Help:Collapsing

A side note. I noticed that the numbeo.com site uses fixed row numbering on most of their many sortable tables:
*http://www.numbeo.com - for example: 
*http://www.numbeo.com/crime/rankings_by_country.jsp - the rank column.
What about using "rownumber"? Is that in use on Wikipedia, or other wikis?

"mw-" is used for mw-collapsible and mw-collapsed on Wikia:
http://community.wikia.com/wiki/Help:Collapsing 

But not on Wikipedia: 
https://en.wikipedia.org/wiki/Help:Collapsing

A side note. I noticed that the numbeo.com site uses fixed row numbering on most of their many sortable tables:
*http://www.numbeo.com - for example: 
*http://www.numbeo.com/crime/rankings_by_country.jsp - the rank column.
You almost convinced me to drop the "mw-" prefix, but then I noticed, that `autonumber` is already in use for autonumbered external links. This shouldn't be a problem if everything is done right, as in one case the class is on an `<a>`, in the other case on a `<table>` element, but you never know with what expectations users added rules for `.autonumber` to their personal CSS. Also note that there is a class `mw-datatable` which is used on tables in wiki content, too, so the "mw-" prefix isn't my invention.

Of course I'm open to arguments against my concerns and other suggestions, the currently proposed patch won't be the last one.
I prefer simplicity. There is no great need for "mw" in front of the class name. I have no problem with "autonumber", "rownumber", or just "rows". Or anything else without "mw" in front of it. 

I doubt too many people other than me used the old class=autonumber CSS provided by Yair_rand higher up in this thread.

See: 
http://cannabis.shoutwiki.com/wiki/MediaWiki:Common.css 

It has the Yair_rand CSS for easy autonumbering used on these pages: 
http://cannabis.shoutwiki.com/wiki/User:Timeshifter/Sandbox_10 
http://cannabis.shoutwiki.com/wiki/User:Timeshifter/Sandbox_4 
http://cannabis.shoutwiki.com/wiki/2013list 

By changing to the latest Mediawiki class name those pages will still work when the mediawiki software used on Shoutwiki incorporates the new automatic row numbering class. I can then delete the old Yair_rand CSS for autonumbering from MediaWiki:Common.css on that Shoutwiki wiki.
I prefer simplicity. There is no great need for "mw" in front of the class name. I have no problem with "autonumber", "rownumber", or just "rows". Or anything else without "mw" in front of it. 

I doubt too many people other than me used the old class=autonumber CSS provided by Yair_rand higher up in this thread.

See: 
http://cannabis.shoutwiki.com/wiki/MediaWiki:Common.css 

It has the Yair_rand CSS for easy autonumbering used on these pages: 
http://cannabis.shoutwiki.com/wiki/User:Timeshifter/Sandbox_10 
http://cannabis.shoutwiki.com/wiki/User:Timeshifter/Sandbox_4 
http://cannabis.shoutwiki.com/wiki/2013list 

By changing to the latest Mediawiki class name those pages will still work when the mediawiki software used on Wikia incorporates the new automatic row numbering class. I can then delete the old Yair_rand CSS for autonumbering from MediaWiki:Common.css on that Shoutwiki wiki.
I prefer simplicity. There is no great need for "mw" in front of the class name. I have no problem with "autonumber", "rownumber", or just "rows". Or anything else without "mw" in front of it. 

I doubt too many people other than me used the old class=autonumber CSS provided by Yair_rand higher up in this thread.

See: 
http://cannabis.shoutwiki.com/wiki/MediaWiki:Common.css 

It has the Yair_rand CSS for easy autonumbering used on these pages: 
http://cannabis.shoutwiki.com/wiki/User:Timeshifter/Sandbox_10 
http://cannabis.shoutwiki.com/wiki/User:Timeshifter/Sandbox_4 
http://cannabis.shoutwiki.com/wiki/2013list 

By changing to the latest Mediawiki class name those pages will still work when the mediawiki software used on Wikia incorporates the new automatic row numbering class. I can then delete the old Yair_rand CSS for autonumbering from MediaWiki:Common.css on that Wikia wiki.
Hmm, "autonumber" might be better in this case for consistency with existing classes from this script (like "sortable") and since the script aspires not to be MediaWiki-dependent.
>>! In T42618#1588087, @MatthiasDD wrote:
> But why starts the classname with mw- ? I suggesst use of "autonumber" instesd "mw-autonumber".

To avoid clashes with classes added to MediaWiki:Common.css, e.g. T42618#434098.
A good patch, it works good for ltr- and rtl-direction. But why starts the classname with mw- ? I suggesst use of "autonumber" instesd "mw-autonumber". Every user read this HTML-code in the wiki-editor. It should be simple and short. For the counter i suggest use of "row":
  table.autonumber tr td:first-child:before {
	counter-increment: row;
	content: counter(row);
}
Change 234473 had a related patch set uploaded (by Gerrit Patch Uploader):
Add class mw-autonumber for tables

[[https://gerrit.wikimedia.org/r/234473]]
Is there any reason this can not be implemented right now? I will be adding row numbering to dozens of tables right away when this is implemented. Once I do so, I am sure it will be immediately added to hundreds more tables as others see how easy it is to add something like 
class="wikitable sortable rownumbers" 

See Help:Sorting to see how convoluted it is to add row numbers now without a class for it: 
https://en.wikipedia.org/wiki/Help:Sorting 
https://en.wikipedia.org/wiki/Help:Sorting#Auto-ranking_or_adding_a_row_numbering_column_.281.2C2.2C3.29_next_to_a_table 
See also the talk page and this current thread (before it goes to the talk archive):
https://en.wikipedia.org/wiki/Help_talk:Sorting#Accessibility_issues_when_implementing_.22rank.22_in_a_separate_table
Is there any reason this can not be implemented right now? I will be adding row numbering to dozens of tables right away when this is implemented. Once I do so, I am sure it will be immediately added to hundreds more tables as others see how easy it is to add something like 
class="wikitable sortable rownumbers" 

See Help:Sorting to see how convoluted it is to add row numbers now without a class for it: 
https://en.wikipedia.org/wiki/Help:Sorting 
See also the talk page and this current thread (before it goes to the talk archive):
https://en.wikipedia.org/wiki/Help:Sorting#Auto-ranking_or_adding_a_row_numbering_column_.281.2C2.2C3.29_next_to_a_table
(In reply to Bartosz Dziewoński from comment #20)
> 1. Obviously, no support for old browsers. I understand that this is a
>    trade-off that we're willing to make.

According to http://caniuse.com/#feat=css-counters the CSS solution even works in IE8, and because IE7 and below are now grade C, a JS solution can't reach a greater level of support anyway.

I doubt that there is great support for CSS Counter Styles Level 3 yet, but at least most of the stuff from Predefined Counter Styles should be supported, so localization up to the level it is done for ordered lists ([1]) should be possible.

[1] https://git.wikimedia.org/blob/mediawiki%2Fcore.git/902f90a123bef85cfaf2b206c51a89ffdd416674/resources%2Fsrc%2Fmediawiki.legacy%2Fshared.css#L935
In comment 18 I linked to a row-numbered sortable table in a page that no longer has that table. I copied the table from an old revision of the page to this sandbox: 
http://cannabis.shoutwiki.com/wiki/User:Timeshifter/Sandbox_10 
This table has 168 rows. Sorting is not slowed down by the auto numbering. 

The auto numbering CSS used is found here: 
http://cannabis.shoutwiki.com/wiki/MediaWiki:Common.css 
CSS is in the section titled "Easy method of auto numbering of table rows".

As I said previously (comment 23) sorting a table with 779 rows is slowed down by the addition of auto numbering: 
http://cannabis.shoutwiki.com/wiki/User:Timeshifter/Sandbox_4
*** Bug 10433 has been marked as a duplicate of this bug. ***
On long lists autonumbering table rows means sorting any column takes longer. Around a couple seconds to sort a column 800 rows long. This is true whether using the easy CSS method or the hard CSS method (with every cell manually added in).

I link to an example below of a table with around 800 rows. 

With autonumbering:
http://cannabis.shoutwiki.com/w/index.php?title=GMMcities&oldid=6398 
Table from above-linked old revision has been copied to this sandbox after converting to the easy CSS method: 
http://cannabis.shoutwiki.com/wiki/User:Timeshifter/Sandbox_4

Same table without autonumbering sorts faster:
http://cannabis.shoutwiki.com/wiki/User:Timeshifter/Sandbox_5 

The initial click takes a couple seconds in all cases. Click again. 

I haven't been able to find a working JS method of autonumbering. Can someone link to a table with JS doing the autonumbering. I want to see how fast it is. 

I have not seen any JS tables linked from previous comments that work for me. Please point me to working JS I can copy to Shoutwiki, or to my personal user JS on a wiki. So I can test it on some tables.
**winne2i** wrote:

They also say (on w3) that you can add suffix which solves the problem with number formatting that you mentioned. In such way those numbering issues are solved but every wiki would have to set its own @counter-style and heading cell content.
(Or – can it be preset?)
(In reply to Bartosz Dziewoński from comment #20)
>    * No support for digit conversion (some languages use other numerals
>      than 0 1 2 3 4 5 6 7 8 9, e.g. Arabic uses ٠‎ ١‎ ٢‎ ٣‎ ٤‎ ٥‎ ٦‎ ٧‎ ٨‎
> ٩‎).
>      I don't think this is possible with CSS (although I might be wrong).

I underestimated the CSS designers, it does support this :) (in the spec at least). See <http://www.w3.org/TR/css-counter-styles-3/> and <http://www.w3.org/TR/predefined-counter-styles/>.
(In reply to Yair Rand from comment #17)
> To just get the fixed numbering column without manually adding cells to each
> row or using JS, one could use CSS generated-content cells with counters:
>   <snip>

I was thinking about doing this with just CSS, and this solution is
very neat, but is has two problems:

1. Obviously, no support for old browsers. I understand that this is a
   trade-off that we're willing to make.

2. Less obviously, no support for internationalization!
   * No support for digit conversion (some languages use other numerals
     than 0 1 2 3 4 5 6 7 8 9, e.g. Arabic uses ٠‎ ١‎ ٢‎ ٣‎ ٤‎ ٥‎ ٦‎ ٧‎ ٨‎ ٩‎).
     I don't think this is possible with CSS (although I might be wrong).
   * No support for various typographic conventions on the number
     formatting; again, proper Polish would require a dot to be placed
     after the ordinal number (as in 1., 2., 3. etc. for first,
     second, third), some might want 1st, 2nd, 3rd etc. in English as
     well, and who knows what other languages might require.
   * In the heading neither "№" nor "#" would be acceptable in, say,
     Polish (we use "Lp." which is an abbreviation of "ordinal
     number"), although this might be worked around by just leaving
     the space empty as tm112 suggests above; I'm not sure if that'd
     be acceptable for all languages we support in MediaWiki, though.

It's probably a good solution on a per-wiki basis (for at least some
languages), but I'm afraid we won't be able to use it in core unless we
manage to solve the above problems (might be doable with some deep LESS
magic, at least for the latter two).
**winne2i** wrote:

This solution is great, I hope this one will be implemented soon.

As for '#' or '№' – I think there could be also an empty cell or even a cell without borders and background (as if there was no cell). It could also be up to local admins choice.
(In reply to Yair Rand from comment #17)
> To just get the fixed numbering column without manually adding cells to each
> row or using JS, one could use CSS generated-content cells with counters: ...

It works great, and is a lot easier to use than the row-numbering method I was using before. 

I am using Yair Rand's method on a ShoutWiki wiki. Currently using this easy method on the table on this page: 
*http://cannabis.shoutwiki.com/wiki/2013list 

Before I would have to manually create a cell at the beginning of each row in the table. Here is the table with the old method:
* [Removed incorrect link]

Now all I have to do is add this to the top line of any table: 

class="sortable autonumber"

I adapted the CSS a little. Here it is:
http://cannabis.shoutwiki.com/wiki/MediaWiki:Common.css 

I removed the border coloring, and I used # for the header. See: 
https://en.wikipedia.org/wiki/Number_sign 
- # is more common in American English. 

I hope this easy method can be implemented soon on Wikipedia and the Commons. It is by far the easiest auto-row-numbering method I have seen. It would make things a lot easier than the hacks currently listed at Help:Sorting: 
*https://en.wikipedia.org/wiki/Help:Sorting - see "Static column" and following sections.
(In reply to Yair Rand from comment #17)
> To just get the fixed numbering column without manually adding cells to each
> row or using JS, one could use CSS generated-content cells with counters: ...

It works great, and is a lot easier to use than the row-numbering method I was using before. 

I am using Yair Rand's method on a ShoutWiki wiki. Currently using this easy method on the table on this page: 
*http://cannabis.shoutwiki.com/wiki/2013list 

Before I would have to manually create a cell at the beginning of each row in the table. Here is the table with the old method:
* [Removed incorrect link]

Now all I have to do is add this to the top line of any table: 

class="sortable autonumber"

I adapted the CSS a little. Here it is:
http://cannabis.shoutwiki.com/wiki/MediaWiki:Common.css 

I removed the border coloring, and I used # for the header. See: 
https://en.wikipedia.org/wiki/Number_sign 
# is more common in American English. 

I hope this easy method can be implemented soon on Wikipedia and the Commons. It is by far the easiest auto-row-numbering method I have seen. It would make things a lot easier than the hacks currently listed at Help:Sorting: 
*https://en.wikipedia.org/wiki/Help:Sorting - see "Static column" and following sections.
(In reply to Yair Rand from comment #17)
> To just get the fixed numbering column without manually adding cells to each
> row or using JS, one could use CSS generated-content cells with counters: ...

It works great, and is a lot easier to use than the row-numbering method I was using before. 

I am using Yair Rand's method on a ShoutWiki wiki. Currently using this easy method on the tables on these pages: 
*http://cannabis.shoutwiki.com/wiki/2014list 
*http://cannabis.shoutwiki.com/wiki/2013list 

Before I would have to manually create a cell at the beginning of each row in the table. Here is the table with the old method:
*http://cannabis.shoutwiki.com/w/index.php?title=2014list&oldid=21668

Now all I have to do is add this to the top line of any table: 

class="sortable autonumber"

I adapted the CSS a little. Here it is:
http://cannabis.shoutwiki.com/wiki/MediaWiki:Common.css 

I removed the border coloring, and I used # for the header. See: 
https://en.wikipedia.org/wiki/Number_sign 
# is more common in American English. 

I hope this easy method can be implemented soon on Wikipedia and the Commons. It is by far the easiest auto-row-numbering method I have seen. It would make things a lot easier than the hacks currently listed at Help:Sorting: 
*https://en.wikipedia.org/wiki/Help:Sorting - see "Static column" and following sections.
To just get the fixed numbering column without manually adding cells to each row or using JS, one could use CSS generated-content cells with counters:
  table.autonumber > tbody {
    counter-reset: autonumbering;
  }
  table.autonumber > tbody > tr::before {
    counter-increment: autonumbering;
    content: counter(autonumbering);
  }
  table.autonumber > thead > tr::before {
    content: "№";
  }
  table.autonumber > thead > tr::before, table.autonumber > tbody > tr::before {
    display: table-cell;
    padding: 0.2em;
    border: 1px solid #AAA;
    vertical-align: middle;
    text-align: center;
  }
I am not sure if T4315 and T12433 are resolved duplicates of this. I marked T4315 as a resolved duplicate of this, but now I am not sure. Maybe we can fix that problem too. 

It would be nice if the fixed number column was automatically numbered (row numbering) without having to fill in anything in the column cells at all. 

T12433 offers some automatic numbering JS that does this:
https://en.wikipedia.org/wiki/User:Mike_Dillon/Scripts/autonumber.js 

via class="wikitable autonumber"

The example given at T12433 is this: "Example: say an author creates a chart that alphabetically lists all of the 535 members of the US Congress.  It would be laborious to list the numbers 1, 2, 3, … 533, 534, 535 near each of the 535 entries on the list.  And next time the list changes (at the next election, when names  are added to or subtracted from the list of Congress members), the author would have to repeat the laborious process of numbering the 535 entries on the  list all over again."

For T12433 the original poster's user page has moved to here:
https://en.wikipedia.org/wiki/User:Joseph_A._Spadaro 

The table wikitext he provided in T12433 produces this: 
http://en.wikipedia.org/wiki/User:Timeshifter/Sandbox29
I am not sure if bug 2315 and bug 10433 are resolved duplicates of this. I marked bug 2315 as a resolved duplicate of this, but now I am not sure. Maybe we can fix that problem too. 

It would be nice if the fixed number column was automatically numbered (row numbering) without having to fill in anything in the column cells at all. 

Bug 10433 offers some automatic numbering JS that does this:
[[User:Mike Dillon/Scripts/autonumber.js]]

via class="wikitable autonumber"

The example given at bug 10433 is this: "Example: say an author creates a chart that alphabetically lists all of the 535 members of the US Congress.  It would be laborious to list the numbers 1, 2, 3, … 533, 534, 535 near each of the 535 entries on the list.  And next time the list changes (at the next election, when names  are added to or subtracted from the list of Congress members), the author would have to repeat the laborious process of numbering the 535 entries on the  list all over again."

For bug 10433 the original poster's user page has moved to here:
[[User:Joseph A. Spadaro]]

The table wikitext he provided in bug 10433 produces this: 
[[User:Timeshifter/Sandbox29]]
%%%*** T4315 has been marked as a duplicate of this bug. ***%%%
%%%*** Bug 2315 has been marked as a duplicate of this bug. ***%%%
*** Bug 40634 has been marked as a duplicate of this bug. ***
I've created a proof-of-concept implementation using the sortEnd.tablesorter event $.tablesorter fires upon finishing sorting.

The code is essentially five lines:
```
$('table.sortable th.unsortable.ordinal').each(function(i, th) {
  var $th = $(th), $table = $th.closest('table');
  $table.on('sortEnd.tablesorter', function() {
    $table.find('tr td:nth-child('+ (th.column+1) +')').each(function(j, td) {
      $(td).text( (j+1) );
    });
  })
});
```
This means that for every column with class="unsortable ordinal" on the header cell inside a table with class="sortable", the code will re-fill it with consecutive numbers, starting at 1, when the table is sorted. This allows for columns which contain ordinal numbers (the original use case).

The solution was discussed on pl.wikipedia's technical village pump[1][2] and is currently live in its common.js[3]. It's used on a few pages already, including the aforementioned [[pl:Miasta w Polsce (statystyki)]] and our help page with a list of interwiki codes, [[pl:Pomoc:Interwiki]].

[1] [[pl:Wikipedia:Kawiarenka/Kwestie techniczne#Poprawa tabeli w Miasta w Polsce (statystyki)]]
[2] [[pl:Wikipedia:Kawiarenka/Kwestie techniczne#Sortowanie tabeli]]
[3] [[pl:MediaWiki:Common.js]], at the very bottom
Okay, so I'm inclined to say this ain't worth doing. Closing.
(In reply to comment #12)
> If we need to be messing with the buttons, I'd say we need to be putting
> additional emphasis on the "Save page" button rather than further emphasizing
> "Cancel".

There are some bold plans about doing just that, Steven and Jon (CC'd) know more about them than me. I think you can play with a reasonably current demo at http://ee-flow-extra.instance-proxy.wmflabs.org/wiki/Main_Page (use the "Agora styling" menu on the left).
**skizzerz** wrote:

Having Cancel be a link instead of a button is not unprecedented in designs, and in fact would be preferred for a couple of reasons:

1. Making them both buttons would put extra emphasis on the Cancel action, making it more likely that users will accidentally click it and wipe their edit.
2. If a user does not wish to actually edit, and the Cancel link is removed entirely, they may not know that they can also cancel the edit by clicking another link elsewhere (does anybody have info on how many times the cancel link is clicked vs how many edits are cancelled via other means?)

If we need to be messing with the buttons, I'd say we need to be putting additional emphasis on the "Save page" button rather than further emphasizing "Cancel".

Interesting further reading on the topic: http://www.lukew.com/ff/entry.asp?571=
**andnlnbn18** wrote:

Can I work on it?
Minor update!
We are using selective serialization by default, so this is no longer a major issue in practice.
(In reply to comment #3)
> Note also that through continuous edits more cruft might be added around the
> same source text, and at some point ugly visual changes do occur.

This is VisualEditor bug 47434, which is fixed in VE master, but not yet deployed.
Note also that through continuous edits more cruft might be added around the same source text, and at some point ugly visual changes do occur.

See the bold text at http://en.wikipedia.org/w/index.php?title=Yolanda_Ordaz_de_la_Cruz&oldid=551330208#Impact . It appeard through several edits, each one adding a bit.

See the diff of the fix:

http://en.wikipedia.org/w/index.php?title=Yolanda_Ordaz_de_la_Cruz&diff=551330391&oldid=551330208
*** Bug 47442 has been marked as a duplicate of this bug. ***
See https://www.mediawiki.org/wiki/Parsoid/Roadmap for our latest plans on this. Our plan is to support HTML-only wikis with VisualEditor without any dependency on Parsoid.
Not WORKSFORME; we actively did something that made this work (just, we didn't notice at the time). :-)
(In reply to comment #4)
> Behaviour
> 
> 1. Enter "RFC 1234" & save; it doesn't auto-nowiki, so you get a page with
> "RFC
> 1234" as wikitext which automatically links.
> 2. Edit again in VE; you get a link which you could edit.
This is no longer true. The behavior on master is that the link gets alienated.

> 3. Saving this without changing causes the link to be unchanged (as
> expected).
> 4. Saving this with a different link doesn't convert 
You can't do that, because it's an alien. You can remove it as a unit. Bolding it seems to work too, although there's a different bug that causes text to be cut off there, will investigate.

> 5. Enter "<nowiki>RFC 1234</nowiki>" in wikitext editor, save.
> 6. Edit in VE; you get some text link in an alien node.
> 7. Saving this causes the link to be unchanged (as expected).
> 
Also alienated.

Entering "RFC 2822" into an existing paragraph causes Parsoid to <nowiki> the entire paragraph.

> Fixes for unexpected behaviours above:
> 
> 1. This feels a little odd; should magic links be allowed, or should Parsoid
> (un?)magically wrap them in <nowiki>s?
It does this now, although the entire paragraph is wrapped.

> 2. This probably should be alienated in DM.
It is now.

> 4. If the link won't be alienated (i.e., option 2 is not followed), we'll
> need
> to special-case this kind of link and re-generate [[]]s around it (? in DM).
Moot, because we have alienation working.

Closing this bug as WORKSFORME. I saw a few weird issues while testing this, but they seem to be Parsoid serialization bugs not directly related to this bug, and I may have an out-of-date library again.
Note that VE supports "bulletizing" lines inside a definition list and they end up properly indented.

For example, using VE to highlight 1, 2, and 3 on a page with the following wikitext
  : 1
  : 2
  : 3
and clicking "Bullet list" results in
  :* 1
  :* 2
  :* 3

Seems like this is a good start on some sort of broader support for arbitrary indention.
*** Bug 67751 has been marked as a duplicate of this bug. ***
I had a problem caused by the broken definition lists. If you have a maths equation aligned as a block using a dl ie

:<math>e^{i \pi}</math>

then you can't add a non indented paragraph after it. https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback/Archive_2014_2#Trying_to_add_a_line_after_an_equation

This has some impact on Bug 61051 about how MathJax equations are aligned.
*** Bug 65247 has been marked as a duplicate of this bug. ***
(In reply to comment #2)
> Perhaps the way to do this is to use the same visual clues that are used when
> using revision tracking in OOo Writer, MS Word etc. Particularly if they use
> the same markings as each other.

Word does a thin line (1px wide, maybe) down the outer column of a page to indicate changed lines, in both the desktop and print versions, I believe, by default.
Perhaps the way to do this is to use the same visual clues that are used when using revision tracking in OOo Writer, MS Word etc. Particularly if they use the same markings as each other.
The mobile version of VisualEditor doesn't do text over-lays to avoid issues like this bug. Closing as INVALID now that work there is progressing.
Regarding Android, I've raised a similar issue at Bug 51270.
Something very similar happens on my Android phone. However, if I blur the editor and refocus it, the first cursor I get upon focusing doesn't have a selection handle, but if I then move the cursor, a selection handle appears.
>>! In T39835#1170062, @NicoV wrote:
> There's also the situation with nowiki surrounded by bold or italic formatting: [[2008|''<nowiki/>'']] in [[ https://fr.wikipedia.org/w/index.php?title=Saint-Florent-des-Bois&diff=prev&oldid=113366483 | this edit ]].

{T95730}.
There's also the situation with nowiki surrounded by bold or italic formatting: [[2008|''<nowiki/>'']] in [[ https://fr.wikipedia.org/w/index.php?title=Saint-Florent-des-Bois&diff=prev&oldid=113366483 | this edit ]].
*** Bug 54266 has been marked as a duplicate of this bug. ***
Just FYI, we have a user at en.wp stating <<I was going to give examples of what turns out to be bug 37835. As the bug is a year old, looks like this won't be fixed and therefore no use in giving the examples.>> :/
*** Bug 51877 has been marked as a duplicate of this bug. ***
I don't know if it is related to this bug, but it is no longer possible to select only part of a link. Previously you could unlink the second word separately for example. See also bug 51531 and bug 50945
Change 74084 had a related patch set uploaded by Catrope:
[WIP] Unwrap whitespace-only links

https://gerrit.wikimedia.org/r/74084
Pulling from this milestone as it's a lot of work for a small feature.
(In reply to comment #4)
> We probably shouldn't allow users to create whitespace-only links, because
> they
> don't render correctly in HTML let alone wikitext. I'm going to work on a
> change that strips whitespace-only links in the converter.
This part depends on bug 46464.
<a> </a> doesn't actually render as a clickable link in Firefox. Even if you set text-decoration:underline; on it, it still doesn't render and can't be clicked. However, <a>&nbsp;</a> does behave "correctly".

We probably shouldn't allow users to create whitespace-only links, because they don't render correctly in HTML let alone wikitext. I'm going to work on a change that strips whitespace-only links in the converter.
I'll allow myself to close it.

In essence, VisualEditor now allows to edit template parameters comfortably separately from the rest of the text, and also includes a lang/dir setting (both made mostly by @mooeypoo; thanks!)

Some articles might still be using bidirectional control characters (probably not much in the English Wikipedia, but quite a lot in the Hebrew Wikipedia), but that's a matter for editors and not developers.
777preethi: Please see https://www.mediawiki.org/wiki/How_to_report_a_bug and create a new ticket with sufficient information to reproduce your setup. Thank you in advance!
**777preethi** wrote:

This error is coming on some clicks.

**Attached**: {F9202}
This doesn't seem to be related to VisualEditor.
(In reply to comment #0)
> I've played a bit, by adding a $namespace parameter extracted from
> $wgRequest->getInt( 'namespace' ), but I would need some guiding about
> reusing
> it in more Special pages (for instance, also in WantedPages) and prepare a
> patch if this enhancement is considered interesting enough.

I'd recommend to write a basic initial patch and iterate from there on.
You are very welcome to use Developer access
  https://www.mediawiki.org/wiki/Developer_access
to submit a patch as a Git branch directly into Gerrit:
  https://www.mediawiki.org/wiki/Git/Tutorial
Change 220344 abandoned by Jforrester:
WikiEditor: Add svg images

Reason:
No reason to back-port.

[[https://gerrit.wikimedia.org/r/220344]]
Change 220344 had a related patch set uploaded (by Paladox):
WikiEditor: Add svg images

[[https://gerrit.wikimedia.org/r/220344]]
* https://gerrit.wikimedia.org/r/181786 (branch master): #mw1.26wmf12
* https://gerrit.wikimedia.org/r/195529 (branch master): #mw1.26wmf12
Change 195529 merged by jenkins-bot:
Add svg to LESS file

[[https://gerrit.wikimedia.org/r/195529]]
Change 181786 merged by jenkins-bot:
WikiEditor: Add svg images

[[https://gerrit.wikimedia.org/r/181786]]
i have uploaded patch that moves the signature button down slightly please could you check it. and if you want the italic i changed a bit could i have some help to do that please.
I think the italic I was done like that on purpose.
Maybe I could do something with css for the signature since that is a new updated version of previous with details of who created in the patch at gerrit.

But not sure about italic might need help on that one please.
Hi how can I fix it. I am using the original version but removed the shadow.
I can be OK with this version.
I have a slight concern about the outline of the italic I, and the signature button seems to be aligned a bit 'high'.

{F182267}
Ok so I should disable enhanced dialogs to test to see if it still works.
I just visited  http://en.random-wikisaur.tk/index.php?title=Main_Page&action=edit  with Win8.1/IE 11 and saw no ill-effects when zooming either. Some of the plain-text based icons still seem a little "dull" to me but so are the .png variants; not a reason to disqualify merging imho though.
{F181822}
'Enhanced dialogs' are enabled for guests it seems so it might be best to verify everything is OK without the dialogs enabled and just straight WikiEditor as well.

Remember: A picture is worth a thousand words; especially if as many icons are displayed as possible (i.e. tick the 'Advanced' menu open like I did in my screen-grab)
Here is a screenshot showing it works now.

Zoomed in at 110%.

{F181806}
Yes it is fixed. I inserted the code to fix chrome issue I also tested it in ie to check if it affected the way it shows but doesent.
>>! In T37342#399524, @TheDJ wrote:
> Created attachment 16901
> Alignment trouble
> 
> Well I should be able to see that it works in all situation, not just in yours, and as this screenshot of a zoomed Chrome shows, it simply still doesn't work... unfortunately.
> 
> **Attached**: {F9095}

@TheDJ - assuming the modifications mentioned in...

>>! In T37342#1228421, @Paladox wrote:
> Hi I fonund a fix to chrome zooming out problem. we should use preserveAspectRatio="none" and xml:space="preserve" in button-sprite.svg file.

>>! In T37342#1228470, @Paladox wrote:
> Found the fix at http://yootheme.com/support/question/6801?order=modified

... have been applied to the latest rebase, could you please see if the Chrome~Zoom issue has been resolved?
Getting these .svg images up & working is the first step on the path to mirroring VE's scheme (FontAwesome-ish). Thanks
Found the fix at http://yootheme.com/support/question/6801?order=modified
Hi I fonund a fix to chrome zooming out problem. we should use preserveAspectRatio="none" and xml:space="preserve" in button-sprite.svg file.
https://code.google.com/p/chromium/issues/detail?can=8&start=0&num=100&q=&colspec=ID%20Pri%20M%20Week%20ReleaseBlock%20Cr%20Status%20Owner%20Summary%20OS%20Modified&groupby=&sort=&id=458307
Change 181788 abandoned by Paladox:
Adds svg to css file

Reason:
Moved to https://gerrit.wikimedia.org/r/#/c/195529/8 since less has been merged.

[[https://gerrit.wikimedia.org/r/181788]]
Change 195529 had a related patch set uploaded (by Paladox):
Add svg to LESS file

[[https://gerrit.wikimedia.org/r/195529]]
Thankyou. your really good at it.
>>! In T37342#1056482, @Paladox wrote:
> Hi could you please do what you did with the image...
Here is the icon without mask but same effect (+ some minor improvements).
{F44927}
>>! In T37342#1056482, @Paladox wrote:
> Hi could you please do what you did with the image...
Here is the icon without mask but same effect.
{F44922}
Thanks.
Hi could you please do what you did with the image your uploaded and do it to this one https://git.wikimedia.org/blob/mediawiki%2Fextensions%2FWikiEditor/1eaf5e8463ae5a95c7a7939d8f3f894b1283742f/modules%2Fimages%2Ftoolbar%2Finsert-ilink.svg this is an old link and this is the current link https://git.wikimedia.org/blob/mediawiki%2Fextensions%2FWikiEditor/c12f248eaa673b1419bd20c77a59ddc0c5bba07f/modules%2Fimages%2Ftoolbar%2Finsert-ilink.svg the old one uses mask the current link doesent please could you get the new link to look like old link without having to use mask.
Thank you for doing that. It is that another image had to have mask removed because it was not showing in internet explorer. but thanks for upload an updated image without mask.
>>! In T37342#1053269, @Paladox wrote:
>> Hi internet explorer does not support mask. please could you do the image without having to do mask thanks.

I have uploaded a new version (the "s" more away from pencil and without mask, and bit other improvements). Thanks for promptly take.
>>! In T37342#1053269, @Paladox wrote:

I have uploaded a new version (the "s" more away from pencil and without mask, and bit other improvements). Thanks for promptly take.
>>! In T37342#1053269, @Paladox wrote:

I have uploaded a new version (the "s" more away from pencil and without mask). Thanks for promptly take.
>>! In T37342#1053269, @Paladox wrote:

I have uploaded a new version (the "s" more away from pencil and without mask). Thanks for take.
>>! In T37342#1053269, @Paladox wrote:

I have uploaded a new version (the "s" more away from pencil and without mask)
I have added the new image to the patch I have also updated the png version.
Hi internet explorer does not support mask. please could you do the image without having to do mask thanks.
Thanks will add it soon to the patch.
On request I've created an new signature icon:
* [[ http://commons.wikimedia.org/wiki/File:Insert-signature2.svg | File:Insert-signature2.svg ]]

Because the current icon shows something like "**f**alse" or in German "**f**alsch"/"fehlerhaft"
The patch is ready to be merged with the svg and then we can merge the file that includes the svg line in css later.
Hi I have reported the bug at webkit for svg not being able to zoom out correctly on chrome. The bug is at https://bugs.webkit.org/show_bug.cgi?id=141535
Change 181786 had a related patch set uploaded (by Paladox):
Re add svg images

[[https://gerrit.wikimedia.org/r/181786]]

#patch-for-review
Hi I have uploaded the new image.
I am using my laptop screen on tv so I can upload the image now which I will be doing.
Ok should I use this one. Sorry I missed this reply. I will upload when I can. Laptop broke last week so have to wait for it be repaired before using git to upload.
@Paladox

I don't know what the big deal was. I commented out the `<mask>` section using a text editor and the basic icon reappeared when I opened it again. Now I don't know if that means it still needs a //mask// or not  -- can't say I didn't corrupt the file further either. 

{F26805}

The only thing I'm sure is that I can see it now in IE... and I bet that's better than knowing there is a button on your toolbar but the lack of even a crippled button-icon means you have no clue what it does until you tick on it. (NOT optimal).

So use it if we can, fix it if we must... but at least swap out the one rendering ''blank'' for something that everybody can at least see.
@Paladox

I don't know what the big deal was. I commented out the Mark section using a text editor and the basic icon reappeared when I opened it again. Now I don't know if that means it still needs a //mask// or not  -- can't say I didn't corrupt the file further either. 

{F26805}

The only thing I'm sure is that I can see it now in IE... and I bet that's better than knowing there is a button on your toolbar but the lack of even a crippled button-icon means you have no clue what it does until you tick on it. (NOT optimal).

So use it if we can, fix it if we must... but at least swap out the one rendering ''blank'' for something that everybody can at least see.
@Paladox

I don't know what the big deal was. I commented out the Mark section using a text editor and the basic icon reappeared when I opened it again. Now I don't know if that means it still needs a //mask// or not  -- can't say I didn't corrupt the file further either. 

{F26805}

The only thing I'm sure is that I can see it now in IE... and I bet that's better than knowing there is a button on your toolbar but the lack of even a crippled button-icon means you have no clue what it does until you tick on it. (NOT optimal).

So use it if we can, fix it if we must... but at least swap out the one rendering ''blank'' for something that everybody at see.
@Jdforrester-WMF said:
>At the request of Design I'm (very slowly) working on replacing all the assets with copies of the OOjs UI ones (in advance of actually switch WikiEditor over to using that, which is lower priority). Maybe we should merge these efforts?

If it gets mobile, tablet and similar device user's the same intended results //A//nd within a reasonable amount of time, then I'm all for it. The current ''bundle'' of .png-matching .svg files are just not making the cut. I suspect the amount of turnover week in, week out has jaded many beyond the point of no return by now as well.

Still, I'd hate to wait another 3 or 4 months for something that could be applied today in full & in the interim; where individual, problematic .svg based icons are disabled by pointing them either to the equivalent .svg stand alone image file or the alleged fallback, stand alone png  as the issues at hand should dictate.
Hi the image insert-ilink.svg and the same image but in button-sprite.svg seems to not show in certain browsers the problem is with using mask. It works in chrome but in Internet explorer it does not show this I doint know how to fix this problem.
>>! In T37342#945952, @Paladox wrote:
> I can confirm that problem is because of multiple images inside one image file. I tested it.

Are you saying its because WikiEditor first looks to use ''Spirited'' button icons from //button-sprite.svg// using offset coordinates instead of individual icons?

If so, I wonder why it does not happen using //button-sprite.png// (or does it but nobody bothered to try?)
I can confirm that problem is because of multiple images inside one image file. I tested it.
Hi here is the bug filed https://bugs.webkit.org/show_bug.cgi?id=125118 and https://code.google.com/p/chromium/issues/detail?id=260319 it seems the bug is when the image has multiple images in it.
Hi if you zoom out to 50% it lines up again. seems to either been a problem with the css or it is webkit or chrome.
I think it is to do with this file jquery.wikiEditor.toolbar.config.js

and how do you add something like 2px -142px center to background-position because it seems if I add 2px center the icon goes back to the position you want it to be but it is a different icon.
Oh ok.
>>! In T37342#945594, @Paladox wrote:
> probably the file button-sprite.png and .svg need to be separated into different images to fix the issue on google chrome (guessing)

It could just be an overlooked css attribute and setting like the one that fixes T78354 for example. We won't know until folks have something to test against.
probably the file button-sprite.png and .svg need to be sepereted into different images to fix the issue on google chrome (guessing)
Hi but there is an error with chrome where if you zoom out pass 90% or lower it will make the icons go out of position. how will that get fixed but any ways chrome default zoom is 100% and not a lot of people use 90% zoom (guess) so this svg images that are being added could get merged and the problem fixed letter including the .css or .less file.
>>! In T37342#943845, @Paladox wrote:
> There is also a bug with having svg images because if your on chrome and 90% zoomed in the icons go everywhere.

Every example screenshot that I've seen is not the default WikiEditor toolbar but always with additional buttons, etc. added afterwards. I'd like to see an unmodified WikiEditor toolbar behave that way just to be sure.

Scratch that I just saw https://phabricator.wikimedia.org/T37342#399524

seems like problem with the spirited coordinates not re-sizing on such actions as a zoom.
>>! In T37342#943845, @Paladox wrote:
> There is also a bug with having svg images because if your on chrome and 90% zoomed in the icons go everywhere.

Every example screenshot that I've seen is not the default WikiEditor toolbar but always with additional buttons, etc. added afterwards. I'd like to see an unmodified WikiEditor toolbar behave that way just to be sure.
Hi the problem started when someone created the images earlier this year. The problem was the reported.
>>! In T37342#943844, @Paladox wrote:
> Do you have the link for svg version of format-olist.svg 

It was part of one your patchsets - https://gerrit.wikimedia.org/r/151203
There is also a bug with having svg images because if your on chrome and 90% zoomed in the icons go everywhere.
Do you have the link for svg version of format-olist.svg
>>! In T37342#943824, @GOIII wrote:
> ...but if the svg file variants for all the existing png files are missing some, I doubt anybody would want to merge that so there's the first roadblock
> 
Then again, the whole point of keeping/having the png files is for a fallback if svg somehow fails so I take it back -- no reason not to vote merge
r151203 had at least `format-olist.svg` listed in it

...but if the svg file variants for all the existing png files are missing some, I doubt anybody would want to merge that so there's the first roadblock

I wish we could slow down some and address one thing at a time - we're already 9 patch-sets deep for example and the css could have taken some cleaning/amending first too.
Hi they doint currently have svg images but can be added later.
Change 151203 abandoned by Paladox:
WikiEditor: Convert .css to .less and also fixes SVG issues.

Reason:
Split this into two patches first patch is svg images https://gerrit.wikimedia.org/r/#/c/181786/ second patch is convert .css to .less https://gerrit.wikimedia.org/r/#/c/181790/

[[https://gerrit.wikimedia.org/r/151203]]
Hi I have this patch now https://gerrit.wikimedia.org/r/#/c/181790/ that converts .css to .less
See, this is partly why the previous patches were so hard to follow. With the revised 1st patch just being the addition of the svg variants, the following .png files have no corresponding .svg file in the new patch

* format-bold-L.png
* format-bold-hy.png
* format-bold-ka.png
* format-bold-os.png
* format-bold-ru.png

* format-italic-D.png
* format-italic-E.png
* format-italic-hy.png
* format-italic-ka.png

* format-olist-rtl.png
* format-olist.png
* format-ulist-rtl.png

* insert-redirect-rtl.png

* magnify-clip.png
See, this is partly why the previous patches were so hard to follow. With the revised 1st patch just being the addition of the svg variants, the following .png files have no corresponding .svg file in the new patch

* format-bold-L.png
* format-bold-hy.png
* format-bold-ka.png
* format-bold-os.png
* format-bold-ru.png

* format-italic-D.png
* format-italic-E.png
* <s>format-italic-I.png (see previous comment above)</s>
* format-italic-hy.png
* format-italic-ka.png

* format-olist-rtl.png
* format-olist.png
* format-ulist-rtl.png

* insert-redirect-rtl.png

* magnify-clip.png
See, this is partly why the previous patches were so hard to follow. With the revised 1st patch just being the addition of the svg variants, the following .png files have no corresponding .svg file in the new patch

* format-bold-L.png
* format-bold-hy.png
* format-bold-ka.png
* format-bold-os.png
* format-bold-ru.png

* format-italic-D.png
* format-italic-E.png
* format-italic-I.png (see previous comment above)
* format-italic-hy.png
* format-italic-ka.png

* format-olist-rtl.png
* format-olist.png
* format-ulist-rtl.png

* insert-redirect-rtl.png

* magnify-clip.png
Hi I have managed to do it.
Please could I have some help to rename it because I try it but it stays at lower case I instead of being uppercase i.
Change 181788 had a related patch set uploaded (by Paladox):
Adds svg to css file

[[https://gerrit.wikimedia.org/r/181788]]

#patch-for-review
Change 181786 had a related patch set uploaded (by Paladox):
Re add svg images

[[https://gerrit.wikimedia.org/r/181786]]

#patch-for-review
Change 151611 abandoned by Paladox:
WikiEditor: Re add SVG

Reason:
I have added split some of this in to two patches which are at https://gerrit.wikimedia.org/r/#/c/181786/ and https://gerrit.wikimedia.org/r/#/c/181788/

[[https://gerrit.wikimedia.org/r/151611]]
shouldn't `format-italic-i.svg` be `format-italic-I.svg` ? (capital i =I [eye] )

the existing png I think its suppose to replace is `format-italic-I.png`
Css file containing svg.

https://gerrit.wikimedia.org/r/#/c/181788/
Always abandon AFTER you have replacements up no?


>>! In T37342#943714, @Paladox wrote:
> So I should add svg images and if I have any png files I should add them and I should not edit the css files on first patch but add the svg image to css on the second patch and then last patch change css to less.


Right, the first step should just be to add the final desired svg variants and/or any final desired png - be they replacements or previously missing
Hi this is the first patch https://gerrit.wikimedia.org/r/#/c/181786/ is this what you ment for first patch.
I will abandon them patches in a min. I will upload the new patches to make sure they are what your saying to do. thanks for helping.
So I should add svg images and if I have any png files I should add them and I should not edit the css files on first patch but add the svg image to css on the second patch and then last patch change css to less.
Ok.
>>! In T37342#943701, @Paladox wrote:
> So I should do the svg images first. and then css to less last.
Patch No.
# add all the final svg variants and any additional final png files to the ...images/toolbar directory
     * nothing should change the current rendering by only adding image files here
# edit the current css to use the svg variants and have the png variants as the fall backs
     * we can stop here to see if anybody has svg rendering issues or not. If not...
# convert the svg rich css files to use the less format
     * we then see if anything has changed from the rendering seen in #2

Well that's what I //think// is the best way for folks to pay attention to this again while addressing previously voiced concerns/issues. I could very well be 100% wrong mind you.
>>! In T37342#943701, @Paladox wrote:
> So I should do the svg images first. and then css to less last.
Patch No.
# add the svg variants and any additional png files to the ...images/toolbar directory
     * nothing should change the current rendering here
# edit the current css to use the svg variants and have the png variants as the fall backs
     * we can stop here to see if anybody has svg rendering issues or not. If not...
# convert the svg rich css files to use the less format
     * we then see if anything has changed from the rendering seen in #2

Well that's what I //think// is the best way for folks to pay attention to this again while addressing previously voiced concerns/issues. I could very well be 100% wrong mind you.
>>! In T37342#943701, @Paladox wrote:
> So I should do the svg images first. and then css to less last.
Patch No.
# add the svg variants and and any additional png files to the ...images/toolbar directory
     * nothing should change the current rendering here
# edit the current css to use the svg variants and have the png variants as the fall backs
     * we can stop here to see if anybody has svg rendering issues or not. If not...
# convert the svg rich css files to use the less format
     * we then see if anything has changed from the rendering seen in #2

Well that's what I //think// is the best way for folks to pay attention to this again while addressing previously voiced concerns/issues. I could very well be 100% wrong mind you.
Patch No.
# add the svg variants and and any additional png files to the ...images/toolbar directory
     * nothing should change the current rendering here
# edit the current css to use the svg variants and have the png variants as the fall backs
     * we can stop here to see if anybody has svg rendering issues or not. If not...
# convert the svg rich css files to use the less format
     * we then see if anything has changed from the rendering seen in #2

Well that's what I //think// is the best way for folks to pay attention to this again while addressing previously voiced concerns/issues. I could very well be 100% wrong mind you.
Hi I will create the first patch with the new svg images excluding the arrow image. and second will include css to less arrow svg images and the new svg images from first reason because if first patch gets merged then this patch could get rebased without needing to add anything else.
So I should do the svg images first. and then css to less last.
Hi the reason I created three patches is because someone asked me to create separate patches and then someone asked me to put the patch into one. so I created three patches. should I create two one with the convert to .less and with the svg images of arrow and then the other svg images in different patch with the fix for the background.
On second thought - maybe css to less conversion should be the last patch merged after all the other pieces are in place rather than the first patch.
basically yes -- although I suspect you would do better by taking the existing three and separating the changes even further into even more specific patches. Again, this is just from an observational standpoint rather a technical one. Nevertheless, these enhancements seem to be pretty much ignored no matter how one looks at them.

Maybe the first step should be a conversion of the existing .css into less format prior to the svg icons addition/modifications for example. Then add the svg variants in another patch - the changes needed to make them live in the now existing less files in still another patch. And so on....
Hi so should I abandon them and then re upload them.
> [[https://gerrit.wikimedia.org/r/151611]]
> 
> [[https://gerrit.wikimedia.org/r/151616]]
> 
> [[https://gerrit.wikimedia.org/r/151203]]
> 
These 3 patches have been re-committed for weeks and weeks now to no avail. Nobody, including myself, seems to be comfortable with supporting a merge for revisions that have three-dozen or more Patch-sets in place to date -- not to mention each patch is trying to accomplish more than it should or overlaps into another's all at once.

It seems to me the best way to get the underlying changes merged is to abandon these three and create new ones that accomplishes the same end results but with smaller steps to reach that aim instead.
Change 151611 had a related patch set uploaded (by Paladox):
WikiEditor: Re add SVG

[[https://gerrit.wikimedia.org/r/151611]]

#patch-for-review
Change 151203 had a related patch set uploaded (by Paladox):
WikiEditor: Convert .css to .less and also fixes SVG issues.

[[https://gerrit.wikimedia.org/r/151203]]

#patch-for-review
Change 151611 had a related patch set uploaded (by Paladox):
WikiEditor: Re add SVG

[[https://gerrit.wikimedia.org/r/151611]]

#patch-for-review
Change 151611 had a related patch set uploaded by Paladox:
WikiEditor: Re add SVG

https://gerrit.wikimedia.org/r/151611
Change 151611 had a related patch set uploaded by Paladox:
WikiEditor: Fix issue with SVG

https://gerrit.wikimedia.org/r/151611
Based on talking to James and Trevor, we can provide the icons that will improve consistency dramatically, we're targeting end of day tomorrow Nov 5 to have all the assets ready to integrate. Thanks for a moment of patience.
(In reply to Jared Zimmerman (WMF) from comment #66)
> No, i just mean the same SVG assets. for bold, italic, image, link, etc. Not
> the code behind an OOUI control

That's fundamentally incompatible with how MediaWiki is built. Reaching in to the code base to pull out assets will immediately fail basic code review.
No, i just mean the same SVG assets. for bold, italic, image, link, etc. Not the code behind an OOUI control
Using the OOUI icons means using OOUI. Porting the wikitext editor to OOUI is a big piece of work.
part of me is still wondering why we aren't using the icons that are in use in VisualEditor currently, any rational?
Change 168821 merged by jenkins-bot:
Revert "Add SVG versions of toolbar icons"

https://gerrit.wikimedia.org/r/168821
Hi I have one of the images that were fixed by a user here and fixed the other ones to. the patch is at https://gerrit.wikimedia.org/r/#/c/151611/
Okay, this is getting ridiculous. M4tx made a commit that added SVG files (a low priority enhancement). The commit accidentally mutilated the "B" icon (visible regression) and was merged by TheDJ.

See
https://gerrit.wikimedia.org/r/#/c/97454/
http://i.imgur.com/mBZm28W.png


I don't know what everyone is doing, but please just fix the icon. All this other stuff is unrelated to this bug. If there's no simple commit that fixes the icon soon I'll recommend reverting the SVGs for the time being and re-submitting that change as a draft blocked on restoring the B icon.
This one only includes the fixes for svg http://simple-random-wikisaur.tk/index.php?title=Main_Page&action=edit
That site also includes .less.
(In reply to Derk-Jan Hartman from comment #55)
> "is the way I thought this was all going to play out too." There are no
> dependencies on the tickets, there are no comments on the commit message
> that indicate this.
> 
Granted - and you are absolutely correct to take that position imo as well. I merely had the small benefit of following this exercise 20+ revisions ago is all. Don't read into it any further than that.

(In reply to Derk-Jan Hartman from comment #53)
> 4: It turned out that there were problems with the SVGs in production. This
> should have been cause for reverting the change.

Bingo. Regression seems to be a dirty word around here however.
Created attachment 16901
Alignment trouble

Well I should be able to see that it works in all situation, not just in yours, and as this screenshot of a zoomed Chrome shows, it simply still doesn't work... unfortunately.

**Attached**: {F9095}
I have created 3 commits one has all of it in it and 2nd patch has .less in it and third patch has the fixes for svg.
"is the way I thought this was all going to play out too." There are no dependencies on the tickets, there are no comments on the commit message that indicate this.

That first link already mixes three issues in a way that I'm not confident anymore that something unexpected is mixed into it as well.

Separation of concerns (in bugzilla tickets, commit messages etc), be explicit about what depends on what, proof that stuff works (as intended) and you will convince a core reviewer to merge the code. That has not happened so far.
Ok I have tested all the patches on my site. here is link to show how it is working. http://en.random-wikisaur.tk
Paladox, I'm not sure how I need to explain this to you and it hope it doesn't come across as rude, because it's not intended to be that way, but this whole stuff is simply not reviewable right now.

If I go trough a patchset, read the commit message and the diff, test it in my browsers and NOT have all my questions answered. It cannot be merged.

Things I should not have to do are:
1: Go trough 50 patchset rebases
2: Go trough 15 comments interspersed with these rebases, for finding answers that should be in the commit message, if they affect the review.
3: Pick and choose between 3 patchsets, for one change.


This Bug ticket is about converting the Original PNGs to SVG.
1: M4tx did some nice work
2: This work was not pixel perfect with the original PNGs, but that was fine
3: I approved the SVG change on that basis
4: It turned out that there were problems with the SVGs in production. This should have been cause for reverting the change.
5: Instead of reverting I gave people a chance to fix it, Pro, you etc.
6: You currently are the one making those proposals for changes.
7: You can't answer the questions in a way that gives enough people confidence to approve the changes. (either by lack of experience, by lack of your mastery of the language, of not actually being able to prove it all works as expected etc.)
8: This means the patches cannot be merged, and that means that it's about time to bite the bullet, and I need to admit that I should have reversed the original commit back then when it became clear there were some problems with the original change to SVG.
(In reply to paladox2015 from comment #50)
> Hi i have got it right i have added the images that were here to the patch
> and also added a note on who created the image i also followed fomafix
> instructions and so the patch should be correct now.

https://gerrit.wikimedia.org/r/151203

... followed by ...

https://gerrit.wikimedia.org/r/151611

... followed by ...

https://gerrit.wikimedia.org/r/151616

... is the way I thought this was all going to play out too.
Change 168821 had a related patch set uploaded by TheDJ:
Revert "Add SVG versions of toolbar icons"

https://gerrit.wikimedia.org/r/168821
Hi i have got it right i have added the images that were here to the patch and also added a note on who created the image i also followed fomafix instructions and so the patch should be correct now.
I can't seem to get a clear, concise and accurate description from the patch submitters on these problems. Problems also remain in the latest versions of the submitted patches with strange offset problems in the sprite when the user zooms in or out.

Since there are clearly problems in the original patch that was converting the toolbar resources to SVG, and since it seems that the patch submitters cannot get them corrected, I think that there is only one solution left. Revert the original SVG patch and wait till someone with SVG skills AND gerrit experience pays attention to this problem.
Hi I have now fix it.
Hi I have fixed it.
(In reply to paladox2015 from comment #42)
> Merge Failed.
> This change was unable to be automatically merged with the current state of
> the repository. Please rebase your change and upload a new patchset.

So please fix that? :)
Change 151203 had a related patch set uploaded by Paladox:
WikiEditor: Convert .css to .less and also fixes svg issues.

https://gerrit.wikimedia.org/r/151203
Change 160421 abandoned by Paladox:
WikiEditor: Convert .css to .less and also fixes svg issues.

https://gerrit.wikimedia.org/r/160421
Change 160421 had a related patch set uploaded by Paladox:
WikiEditor: Convert .css to .less and also fixes svg issues.

https://gerrit.wikimedia.org/r/160421
Hi I have now re opended the patch but it says 

Merge Failed.

This change was unable to be automatically merged with the current state of the repository. Please rebase your change and upload a new patchset.
Change 151203 had a related patch set uploaded by Paladox:
WikiEditor: Convert .css to .less and also fixes svg issues.

https://gerrit.wikimedia.org/r/151203
Change 151203 had a related patch set uploaded by Paladox:
WikiEditor: Convert .css to .less and also fixes svg issues.

https://gerrit.wikimedia.org/r/151203
Change 151203 restored by Paladox:
Update WikiEditor

https://gerrit.wikimedia.org/r/151203
Hi I have already done a patch that does that. https://gerrit.wikimedia.org/r/#/c/151203/ Someone commit and said to split them into two patches.
(In reply to Bartosz Dziewoński from comment #36)
> 
> Can anybody summarize what is going on and what's up with all the various
> patches and attachments? . . .
> 

I'll second that!

When it comes to such matters involving images/icons on a toolbar, it seems [to me] the best way to whittle down the issues is to actually have them render in semi-real world instances and have folks report back their findings.

Can't we merge ....

https://gerrit.wikimedia.org/r/151611

and 

https://gerrit.wikimedia.org/r/151616

... so that they at least come up live & working on test2.wikipedia.org in the immediate near future (i.e. today)?

That should get us a decent pool of user responses before next week's scheduled core update to see if those patches resolve anything (or not) bug-wise and still give us enough of a buffer to further refine or revert as needed before that scheduled update rolls-out as well.

The way things stand now, with half a dozen patch sets awaiting attention or implementation for weeks if not months already, we sure don't seem to be resolving much.
This bug seems to be tracking at least two or maybe three completely distinct issues, one of which has just been reported as bug 70679.

Can anybody summarize what is going on and what's up with all the various patches and attachments? Derk, you're marked as assignee – are you still working on it?
Hi I have fixed the problem I also removed the shadow from the rest of the svg icons.
Comment on attachment 15497
button-sprite.svg fixed

Hi there is a problem with this image I uploaded to gerrit and this is what user krinkle said.


format-B is now missing a doctype. And the sprite completely changed. It should probably only have the bold part replaced.

I mean xml header, not doctype.
Change 151611 had a related patch set uploaded by Paladox:
WikiEditor: Fix issue with SVG

https://gerrit.wikimedia.org/r/151611
Change 151203 abandoned by Paladox:
Update WikiEditor

Reason:
Ok.

Please see Ic0c261f66ee882efeb07ab77ee2a3a5533093c4f for the fix for svg images. and I2a223e202aa488f0e83e663e490ee009da686687 for converting .css to .less.

https://gerrit.wikimedia.org/r/151203
Change 151611 had a related patch set uploaded by Paladox:
WikiEditor: Fix issue with SVG

https://gerrit.wikimedia.org/r/151611
Change 151203 had a related patch set uploaded by Paladox:
Update WikiEditor

https://gerrit.wikimedia.org/r/151203
But for sure, I would upload tomorrow another fixed version, with all group transform attributes removed (W3C valid uncompressed and xml well formed).
@Derk-Jan Hartman, yes me too, it is the browser zoom level, but only in Chrome and only sporadically. (If I reset the zoom level, the effect is gone immediately.)

I can't say it is an SVG bug, instead of a Chrome bug with CSS sprite sheets (maybe only with SVG).
@PRO, i'm also seeing what you see in your: "Screenshot - vector-bar completely disordered"

I'm mostly seeing it if I zoom the page out a bit. Probably has to do with scaling and rounding... ?
Is anyone working on merging PRO's corrected button sprite into code?

I'm also seeing what Krinkle reported before (positioning issues of the shadow of all letters) which is fixed with attachment 15497.

This should be a high priority since it looks pretty broken right now!
@PRO, btw we don't need it to be SVGZ compressed, because that already happens on the fly.

I concur that the gaussian blur is somewhat unusual, and I'm not a big fan of it myself.
Thank you PRO, i'll get on this in the next week.
Comment on attachment 15497
button-sprite.svg fixed

All GaussianBlur filter are still present although this is very unusual for small icons. I would make a version without GaussianBlur. (File size before 152.841 Bytes after my optimation = 34.961, SVGZ compression = 10.918 Bytes)
button-sprite.svg fixed

I've optimized the button-sprite and also converted all text to path. Check it out.

**Attached**: {F9094}
Comment on attachment 15466
Screenshot - vector-bar completely disordered

Now everything is ok again, I've nothing changed.
Comment on attachment 15465
Letter B fixed

font type to path
Screenshot - vector-bar completely disordered

It appears also if I logged out. Win 7 Chrome 34. Firefox is normal.

**Attached**: {F9093}
Letter B fixed

Font to pfad converted , remove all transform attributes.

**Attached**: {F9092}
Created attachment 15431
Zip of icon files

**Attached**: {F9091}
@DJ, the proposed SVG icons were significantly different (bevels, embossing, gradients) which definitely diverge from what we had, I was just saying, if we're diverging from what we had, I'd like to diverge in the right direction, not in the direction of greater ornamentation.
Eh, this is just about the old style icons, we are not talking about replacing them...
I thought there is an Wikimedia icon initiative? I'm interesting to do this like simple in the Tango/GNOME style!? [[File:Gnome-format-text-bold.svg]]
Anything that is already part of wikifont doens't need to be redrawn https://github.com/munmay/WikiFont/blob/master/Screenshot-current.png
Good point, i'll upload them on commons.wm.org
**anonmoos** wrote:

Re: request for assistance in the Commons Graphics village pump:

It might help if the SVG code in question were available somewhere as an ordinary SVG file, and not only as embedded in some kind of generalized source code patch management database system that not everybody may feel like trying to come to terms with...
I also left a request for assistence in the commons graphics lab. https://commons.wikimedia.org/wiki/Commons:Graphics_village_pump#SVG_improvements_for_MediaWiki_toolbar
Comment on https://gerrit.wikimedia.org/r/97454:

FIXME: The "B" button looks broken.

> This change changed the B button to have 3D depth
> whereas all the others remain flat (the book icon
> also some depth to it, but not beyond a simple surface,
> which looks fine). The depth is sufficiently odd that
> I suspect this was not done on purpose. 
>
> Screenshot: http://i.imgur.com/mBZm28W.png
> (bottom row shows the new SVG versions)
>
> It looks like the outline that is making it look
> 3D is actually just the regular outline, and the
> black filling for some reason only covers half
> of the width.
Change 97454 merged by jenkins-bot:
Add SVG versions of toolbar icons

https://gerrit.wikimedia.org/r/97454
DJ, looks "good enough for now" I'd like for us to clean this up, and switch to a smaller set of icons that use the new wikifont icons when we can https://www.mediawiki.org/wiki/Design/Wikicons
Created attachment 15051
screenshot safari 7

I notice a few small problems the shadow of the chars seems a tad excessive, the red traffic sign around the W is a bit shifted for me (likely Mac Safari specific issues).

**Attached**: {F9090}
Done and commented.
Pau / Brandon: Could you review the patch (8 lines of CSS and a bunch of new SVG files), or do you have an idea who could?
Created attachment 13895
Screenshot of WikiEditor after the patch

**Attached**: {F9089}
Change 97454 had a related patch set uploaded by M4tx:
Add SVG versions of toolbar icons

https://gerrit.wikimedia.org/r/97454
See also:
https://github.com/he7d3r/mw-gadget-DebugModeToggle
Related: https://bugzilla.wikimedia.org/show_bug.cgi?id=48287
Some feedback on the choice of shortcuts:
http://lists.wikimedia.org/pipermail/wikitech-l/2013-September/071684.html
(http://www.gossamer-threads.com/lists/wiki/wikitech/388134)
Change 81605 merged by jenkins-bot:
Add keyboard shortcuts for formatting tools

https://gerrit.wikimedia.org/r/81605
Change 81605 had a related patch set uploaded by Jforrester:
[WIP] Add keyboard shortcuts for formatting tools

https://gerrit.wikimedia.org/r/81605
Unfortunately the ⌘ + 1 -> ⌘ + 8 are taken by the browser in Chrome for "switch to tab 1…8", and ⌘ + 9 is for "switch to final tab".

I'm going to go our own way (whee) with:

* ⌘ + Alt + 0 -> Paragraph
* ⌘ + Alt + 1 -> Heading 1 (Page title)
* ⌘ + Alt + 2 -> Heading 2 (Heading)
* ⌘ + Alt + 3 -> Heading 3 (Sub-heading 1)
* ⌘ + Alt + 4 -> Heading 4 (Sub-heading 2)
* ⌘ + Alt + 5 -> Heading 5 (Sub-heading 3)
* ⌘ + Alt + 6 -> Heading 6 (Sub-heading 4)
* ⌘ + Alt + 7 -> Preformatted

And potentially:

* ⌘ + Alt + 8 -> Blockquote (when that is working)

This isn't great, but it's the least-bad option that I can see.
Confluence seems preferable, mainly because it has one less key.  I'm not sure how many people are familiar with either, and people who know the Word shortcuts will have to disregard Ctrl + Alt + 4 either way.
(In reply to comment #5)
> This is typically done with ctrl+alt+# in Microsoft Word on Windows, where #
> is a number between 1 and 3. 
> 
> I'm not sure if this is the right way to go, but at least there's some
> precedence.

Microsoft Word:
* Ctrl + Shift + N -> Paragraph (⌘ + Shift + N on Mac)
* Ctrl + Alt + 1 -> H1 (⌘ + Alt + 1 on Mac)
* Ctrl + Alt + 2 -> H2 (⌘ + Alt + 2 on Mac)
* Ctrl + Alt + 3 -> H3 (⌘ + Alt + 3 on Mac)
* Ctrl + Alt + 4 -> € (hello, Europe!)

Confluence:
* Ctrl + 0 -> Paragraph (⌘ + 0 on Mac)
* Ctrl + 1 -> H1 (⌘ + 1 on Mac)
* Ctrl + 2 -> H2 (⌘ + 2 on Mac)
* Ctrl + 3 -> H3 (⌘ + 3 on Mac)
* Ctrl + 4 -> H4 (⌘ + 4 on Mac)
* Ctrl + 5 -> H5 (⌘ + 5 on Mac)
* Ctrl + 6 -> H6 (⌘ + 6 on Mac)
* Ctrl + 7 -> Preformatted (⌘ + 7 on Mac)

Should we adopt the Word ones (which are more common but less relevant) or the Confluence ones (which are a perfect fit for our needs, but less commonly-known)?
- document the idea at [[ https://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects | Mentorship programs/Possible projects ]]
- this project would use a lot of code from existing VisualEditor screenshots project
Move to MediaWiki, because Translate and TWN already support this. It's "just" about producing the screenshots and adding them to qqq.

I'm not sure how many components are using https://commons.wikimedia.org/wiki/Special:Contributions/LanguageScreenshotBot but perhaps that feature can be promoted more. There are some devs who love screenshots for documentation but are probably unaware of the feature.
I do not plan to work on this any time soon. Please reopen if you care about this.
All the items in https://bugzillapreview.wmflabs.org/tag/visualeditor-data_model/ should also be in the main VisualEditor project, which is currently called https://bugzillapreview.wmflabs.org/tag/visualeditor-general/ (and per {T856} won't be re-named until after the import).

I support the ~8000 bugs //could// all just be mass-added(?) after the import, but this feels like a perfect opportunity to get it done right from the start.
Cf. T100, T72, T101 on subprojects and parent projects.
>>! In T859#15852, @Jdforrester-WMF wrote:
> Because the saved searches for Phabricator work the way they do, this means that every month or so we'd need to ping out an e-mail to everyone who might care about VisualEditor telling them to forget the old search URL and use a new one.

According to your previous post, this query was meant to be used basically by the development team leadership. Even if not, I personally think that a query URL posted and updated at the parent project description would be more useful than flooding the parent project with >1000 tasks. HOWEVER,  none of this really matters. You are the product owner and you decide how you want to organize your projects.   :)

Back to the initial request, it looks clear at this point that //tagging tasks also against a super-project// is more a particular approach than a solution for everybody. Therefore, we will not touch the migration script, and we will leave this decision to project owners, who can do this manually pretty easily with batch edits.

Resolving as Declined.
>>! In T859#15771, @Qgil wrote:
> I still don't see why you cannot do what you explain with the search query I'm proposing. 

[Snip]

The number of sub-projects inside VisualEditor changes quite frequently. Right now they are tracked by a combination of Bugzilla tracking bugs (mostly for features) and Bugzilla components (for code areas and types of problem). On average I'd say a new project comes along every month or so.

Because the saved searches for Phabricator work the way they do, this means that every month or so we'd need to ping out an e-mail to everyone who might care about VisualEditor telling them to forget the old search URL and use a new one. The only way to work around this, AFAIAA, is to cheat with a mega-project that is added to everything anyway.

I'm sure you've considered this and decided that for Phabricator you don't need it, which is awesome, but some of us do. :-)

> PS: ACL has nothing to do with this discussion, and I suspect it doesn't work as you think it works. See https://www.mediawiki.org/wiki/Phabricator/Requesting_a_new_project#Policy

Well, no. The **team** "VisualEditor" will have special status in the ACL of the "VisualEditor" **repos** but probably not needed in the ACL of the "VisualEditor" project's **tasks**. Probably.
I still don't see why you cannot do what you explain with the search query I'm proposing. 

Let me explain you the situation of the Wikimedia Phabricator team, which is very similar to your case. We don't have a mega-project. In most cases, tasks that can go to a specialized project are not listed under "Phabricator". If we want to triage tasks tasks regardless of the subproject they are in, we only need to query https://phabricator.wikimedia.org/maniphest/query/q47HlqJVpTSy/

One list, all tasks, grouped by priority. And still someone can go to "Phabricator" and get a sane list of tasks, because we are not duplicating by default. We did that at the beginning, and it didn't take long before we moved away. If we want to aggregate, we can use saved queries, leaving the default/general projects genuinely for tasks that don't fit anywhere else (just like you have in Bugzilla, btw).

PS: ACL has nothing to do with this discussion, and I suspect it doesn't work as you think it works. See https://www.mediawiki.org/wiki/Phabricator/Requesting_a_new_project#Policy
>>! In T859#14800, @Qgil wrote:
>>>! In T859#14527, @Jdforrester-WMF wrote:
>> the "general" bucket is just a "triage me" one, and a general-overview list of top-end priorities.
> 
> I'm not sure a list with ~8000 bugs is useful to "triage me" anything. Besides, you can just get that list with a saved search query whenever you need it.

No.

All new VE bugs go into the VE mega-project (with a status of "Needs triage"). As part of the triage, it will be given a priority and added to one or more projects of which it's a part – //e.g.// "VisualEditor MediaWiki integration" or "VisualEditor table editing" or "VisualEditor ContentEditable" or "VisualEditor performance" or whatever.

Most people will care about a particular feature or aspect of functionality, and so will only follow those particular projects. A few people, like the development team leadership, will want to see the overall priorities across the whole of the VisualEditor mega-project to decide whether to pull resources from one area and put it into another. The ACL for merge/etc. access will also belong to members of the VisualEditor mega-project (probably), as more fine-grained control is not needed and locking-down controls is against our general ethos at Wikimedia.

Does this make sense?
>>! In T859#14527, @Jdforrester-WMF wrote:
> the "general" bucket is just a "triage me" one, and a general-overview list of top-end priorities.

I'm not sure a list with ~8000 bugs is useful to "triage me" anything. Besides, you can just get that list with a saved search query whenever you need it.
>>! In T859#14527, @Jdforrester-WMF wrote:
> the "general" bucket is just a "triage me" one, and a general-overview list of top-end priorities.

I'm not sure a list with ~8000 bugs is useful to "triage me" anything. Besides, you can just get that list with a search query.
>>! In T859#14564, @Qgil wrote:
> Also, wouldn't the right solution be to move the "General" tasks to the main project and then archive the "General" project?

Yes, that's what T856 said. Except that there is no "main project"; "General" is the principal project.
Also, wouldn't the right solution be to move the "General" tasks to the main project and then archive the "General" project?
>>! In T859#14534, @Aklapper wrote:
> Umbrella projects: If you don't want to spend time manually adding super-projects to task in projects there needs to be some rule or even code to automatically do that... 

Sure, that's what Herald is for. :-)

> In general we prefer to keep the Bugzilla-to-Phab import code simple and not handle project rename requests in there.

Yeah, fine for {T856} to be fixed manually by me after the migration. If necessary, I can fix this request manually too after the migration, but….
Umbrella projects: If you don't want to spend time manually adding super-projects to task in projects there needs to be some rule or even code to automatically do that... 

In general we prefer to keep the Bugzilla-to-Phab import code simple and not handle project rename requests in there.
>>! In T859#14519, @Qgil wrote:
> Different teams might want to deal with this situation in different ways. You are saying: all tasks in a subproject must be added to the parent project as well. Others might prefer the current situation, where tasks in a subproject are not "duplicated" in a parent project.
> 
> For instance, this is what we are doing in the Phabricator project. As soon as a task is defined as "Code-Review" or "Project-Management", we usually place them in these subprojects only, removing them from "Phabricator" unless for some reason we want to keep it as a reminder. This keeps the parent project backlog still usable, allowing us to put some attention to the tasks that are not placed in some other subproject.

Sure, but for the projects I listed the "general" bucket is just a "triage me" one, and a general-overview list of top-end priorities.
Different teams might want to deal with this situation in different ways. You are saying: all tasks in a subproject must be added to the parent project as well. Others might prefer the current situation, where tasks in a subproject are not "duplicated" in a parent project.

For instance, this is what we are doing in the Phabricator project. As soon as a task is defined as "Code-Review" or "Project-Management", we usually place them in these subprojects only, removing them from "Phabricator" unless for some reason we want to keep it as a reminder. This keeps the parent project backlog still usable, allowing us to put some attention to the tasks that are not placed in some other subproject.
Is this something that we want to have before the launch, right after the launch, or whenever it is ready?

> [[ https://lists.wikimedia.org/pipermail/wikitech-l/2014-October/079117.html | On Wed, Oct 22, 2014 at 8:02 AM, David Cuenca  wrote ]]:
> 
> Tagging is just a poor man's
> version of classing, since it doesn't let you define the relationship
> between tags. True that you can put any task in several projects/tags, the
> problem is that the project structure is nevertheless flat:
> https://phabricator.wikimedia.org/project/query/all/
> Which will become cumbersome to navigate for occasional visitors as the
> number of projects goes up.

Sure, but after years of Bugzilla we have also seen that the rigid tree structure of https://bugzilla.wikimedia.org/describecomponents.cgi causes many problems too, and occasional visitors probably find it cumbersome anyway.

If we want a high level overview of the projects, we can always have a wiki page identifying the main teams/projects, the starting points to understand the hundreds of projects that we will have soon. Now there is a task to discuss this.  :)
1. Regarding Bugzilla's product-component tree structure vs. Phab's flat namespace, soon the way to go in Phabricator will be using subprojects (see T123078) instead of some external wiki page listing connections or hierarchy between Phab projects.
2. I consider http://www.mediawiki.org/wiki/Phabricator/Projects sufficient, and if $someone considers it not sufficient, $someone please write a wikipage for what is wanted here (and/or reopen this task and assign it to themselves), or enhance the code that creates http://www.mediawiki.org/wiki/Phabricator/Projects to fulfil their needs.
1.+2. together: Hence I'm declining this task.
We do have http://www.mediawiki.org/wiki/Phabricator/Projects nowadays (which is created automatically). That's probably where to continue here.

That current script misses certain contextual knowledge, e.g. that a project named "Flow" is technically a "MediaWiki extension", or that "FR" is the same as "Fundraising". Not sure how that could be implemented.
I'm going to remove ECT 01/2015 from this. It's a nice to have but I don't think I'll have time to work on this in January
We have scheduled this task for #ECT-January-2015 but it has no owner. Based on lessons learned, we should either get an owner for it or remove it from the sprint.
Maybe you don't have the permissions. No problem, it's here now: https://www.mediawiki.org/wiki/Phabricator/Projects
@Qgil I have added the draft template to the wiki. However, I cannot find the "Move" link. All I see is (From left to right): User Page, Discussion, Read, Edit, Edit Source, View History and Watchlist (The star). Some help is appreciated!
@Toolboxx8, you have done a tone of work! Thank you very much. I will close this task as completed now. Just one thing, can you please add a "{{draft}}" template at the top of the page (just paste that string using "edit source", and then move the page to Phabricator/Projects, please? To move the page just click the "More" link in the toolbar.

We will probably massage that page a bit and then create another task to add the descriptions and polish it. As said, I believe you have put enough effort to consider your GCi task closed, even if we will keep this task here open until the page is ready. Thank you again.
So, I have added links to the list and add a few more projects that were present in Phabricator but not in Bugzilla.

It is still incomplete, mainly the MediaWiki extensions part (there are a lot under it) and the Wikimedia section at the bottom. I have included archived projects while adding a (Archived) note beside the projects, it can be removed if it is not wanted. I also have not include a lot of projects that are in Phabricator but was not in Bugzilla e.g. JavaScript, Jenkins, Human Resource etc.

You can check out the list at : https://www.mediawiki.org/w/index.php?title=User:Toolboxx8/Sandbox

Another problem is at the Common Apps part where all the projects are archived. Should it just be removed? I added a link to the Android project page on Phabricator by the side.

Finally, just out of curiosity as I was going through the list of projects. Under 'Unofficial Apps' the projects listed there use "or" instead of "on", for example: Wikipedia or Windows 8. Shouldn't it be "on" instead of "or"? Just a minor question.
@Aklapper Oh, I see.

Yeah, that makes a lot of sense. As I was browsing through the active projects I couldn't find any that was closely related to those in Bugzilla. Yes, it only states if the projects is new, unconfirmed or patched.

Okay, thanks a lot! I'll see what I can do to improve it further.

@Qgil I will continue to work on it for a while and upload the URL to the GCi page. Is that ok?

I feel that I could still improve the page a little more.
I think the current list would be good enough for a GCi task in terms of entries. We can polish these type of details that are quite time consuming for a newcomer but someone like Andre can decide in a whim. I would put my time on linking each entry to its Phabricator project and adding the soft description, if available.
@Toolboxx8: Thanks for your work on this!
Referring to your example, Bugzilla product "Common Apps" and component "Android" became Phabricator project "Commons-App-Android" - you can see that listed in the list of all projects under https://phabricator.wikimedia.org/project/query/all/?after=Commoa .
Note that the project is closed as archived so no new tasks can be filed under it anymore (I guess you looked at the list of //active// projects in Phabricator, which makes sense - we're not interested in listing archived/inactive projects).
Unfortunately, Bugzilla's describecomponents.cgi does not tell you whether a project is archived or not so that is indeed confusing. :-/

If you have further specific cases where you aren't sure what has happened, don't hesitate to list them here and ask - but in general, don't worry too much if you cannot find some stuff, it does not have to be //totally// perfect. :)
I have created a clone (quite literally) of the old Bugzilla page: https://old-bugzilla.wikimedia.org/describecomponents.cgi at https://www.mediawiki.org/w/index.php?title=User:Toolboxx8/Sandbox which is almost an exact copy of the old web page.

I have not linked the items to any projects yet as I know the difference between Bugzilla and Phabricator. However, I am unsure of how to link the two together. Some projects that are in Bugzilla are not present in Phabricator. Whereas some projects in Phabricator are not listed in Bugzilla. Any advice on tackling this problem?

Should I edit the project page? For example:

  - Common Apps
       - Android

becomes

  - Android
(as in Phabricator) and then add subprojects under this title?
# Create an account in https://www.mediawiki.org/
# Then you can go with your browser to a page like www.mediawiki.org/wiki/User:YOUR-USERNAME/Sandbox (changing "YOUR-USERNAME" for your actual username)
# Click "Create"
# Type some text. Save. 

There you have your page. Then you can share the URL here while you keep editing by clicking "Edit".
Hi @Qgil

Thanks for the guidelines! I now understand what is my aim.

However, I have a few questions. Where should the wiki page be? And how do I go about creating one?

I'm sorry but I'm sort of new to creating wiki pages, but I'm willing to learn!

I have search about and read a few articles and watch a few videos but I'm not sure which one to follow. Any suggestions?
Hi @Toolboxx8, to keep this task simple, 

# please create a wiki page cloning the list of projects shown in this page: https://old-bugzilla.wikimedia.org/describecomponents.cgi, but linking to their current Phabricator projects, which an be found under https://secure.phabricator.com/project/.
# then, under each project list the subprojects that look more relevant to you, for instance checking the amount of tasks they have listed.

I started a rough example of how this would look like at [[ https://phabricator.wikimedia.org/T833#19869 | at a previous comment ]] in this task.

No need to aim for perfection. If you have a wiki page that looks complete enough for a v0.8, we can continue polishing it.
Hi!

I'm excited in taking part in GCi and taking this task. However, I'm not very sure about my task at hand. I have a rough idea from the description given, but I would like to have a more detailed explanation? 

It says that my proposal should help a newcomer to Phabricator to understand how we use Phabricator for managing projects. Does that mean I'm writing like a tutorial guide? 

Some help is much appreciated! Thanks!
Heads up! A student has taken this #Google-Code-in-2014 task.

http://www.google-melange.com/gci/task/view/google/gci2014/5777066188341248

Hi toolboxx8! If you have questions, you can ask them here. In addition to the GCi mentors there are other community members that may help you. Thank you for your interest in contributing to Wikimedia!
Task added to GCI at https://www.mediawiki.org/wiki/Google_Code-in_2014#Category:_Documentation.2FTraining
I don't think we need a 1:1 mapping of all the projects. After the Bugzilla migration we will have hundreds. The word "overview" in the subject of this task is important.

Also, we don't need to perpetuate a Bugzilla tree structure that never made us happy.

We just need a sane list of main areas, identifying the most popular / relevant projects underneath.
If I understand correctly, we want to start with a 2-column table on mediawiki, that lists:
1. The existing components in bugzilla, as the structured 2-level tree that they are currently in. (https://bugzilla.wikimedia.org/describecomponents.cgi)
2. The current list of phabricator projects. (https://phabricator.wikimedia.org/project/query/all/)

----
Once that exists:
* A) We'd add a section for anyone to Propose obvious/immediate additions, for column 2. 
** These proposals would be related to things discussed in T802 and T705. 
* B) We'd discuss/decide on a logical hierarchy for sorting the items in column 2, for an at-a-glance overview, to help people find the likely project name(s) they want to use in a Task.
** B1) This might incorporate/adapt the listing/structure given in https://www.mediawiki.org/wiki/Wikimedia_Engineering#Features_engineering , plus other sections from https://wikimediafoundation.org/wiki/Template:Staff_and_contractors 
** B2) Plus potentially some of the structure from https://meta.wikimedia.org/wiki/Wikimedia_movement
* C) And we'd also take 1 or 2 key examples of each "Type" to add to the docs in https://www.mediawiki.org/wiki/Phabricator/Requesting_a_new_project#Type_of_project (only "Tag" currently has an example: "Accessibility").

----

Q1. Is that fairly accurate?

Q2. What other existing mappings, are missing?

Q3. Are **all** the existing components in bugzilla going to be replicated in phabricator 1-to-1? ("No" would mean we are also taking this opportunity to remove/merge some of the unused/un-useful components. Either now, or later.)

Q4. Is there a static list of all bugzilla's current "Product->Component" options?  (Ideally, I want a copy&pastable 2-level bulletpoint list, of just the names. Otherwise I have to manually copy&paste a few hundred lines...)

(I have zero spare time to guarantee mentoring. But I'd happily contribute thoughts/edits, occasionally. :-)
...and I am very happy to (co-)mentor this task! 
Anybody willing to add this to https://www.mediawiki.org/wiki/Google_Code-in_2014#Proposed_tasks ? (I might do so if nobody is faster)

@Micru and/or @Quiddity: Are you in?
(Sorry, apparently my brain cannot have all ideas at once)

... and with https://bugzilla.wikimedia.org/describecomponents.cgi as starting point, a student cannot go too too wrong, with just a bit of guidance.
Also, this is a task that @Micru and/or @Quiddity could mentor. You just need to know about Wikimedia, editing wiki pages, and searching projects in Phabricator.
Also, this is a task that @Micru and/or @Quiddity could mentor. You just need to know about Wikimedia, editing wiki pages, and searching projects in Phabricator to mentor this one.
We are talking about a wiki page that serves as a list of the main projects (the ones that are important on its own and the ones that act as umbrella of many others). Something like (if only our Bugzilla tree structure would be same). This page shouldn't aim to contain all the projects, probably 2 levels only i.e.

* MediaWiki
** API
** Configuration
** ((some more core components))
* MediaWiki Extensions
** VisualEditor
** MobileFrontend
** ((a few more selected))
** See all extensions ((a query to all projects containing the word "extension" in the title)
* (etc etc)

While having a perfect two-level tree isn't trivial, having a first version up to a level that invites experienced contributors to fine tune it is not that difficult.
I'm not entirely sure which problem we want to solve. Make people understand what types of "projects" we have is already reflected by https://www.mediawiki.org/wiki/Phabricator/Requesting_a_new_project#Type_of_project I'd say? 
Or what else is thought of?

For the records, https://phabricator.wikimedia.org/project/query/all/ lists all archived and active projects.
A GCi task?
This would be useful to identify who is currently working on a card. Helps with visual scanning and clearly shows when certain people are "hogging" cards.
As Shaggy once said "it wasn't me", but do appreciate the heads up.
CCing @JKatzWMF just to ma sure he is aware of he comment above. No worries, it happens the first time.  :)
>>! In T85455#1083879, @Jdlrobson wrote:
> Got it! FYI to newbies like myself there is a barely visible checkbox when you edit project details for Sprint - tick that and boom - magic :)

@jdlrobson: Please do read https://www.mediawiki.org/wiki/Phabricator/Project_management#Sprints and spread the word that there is documentation. I just corrected the wrong icon, the wrong color, and the missing start and end dates of "Gather Sprint C_" (the name still violates the [[ https://www.mediawiki.org/wiki/Phabricator/Creating_and_renaming_projects | project guidelines ]]).
Got it! FYI to newbies like myself there is a barely visible checkbox when you edit project details for Sprint - tick that and boom - magic :)
That is not a Sprint project.... As in using the Sprint extension (no burndown chart).
This is so far my biggest pain point about using Phabricator for sprint boards. I can see username but not avatar - how do I get the avatars on https://phabricator.wikimedia.org/tag/gather_sprint_c/board/
Proof: https://phabricator.wikimedia.org/tag/%C2%A7_visualeditor_q3_blockers/

Thank you!
Good! It looks like the cards wuld benefit from some vertical-align: top.

Anyway, @Jdlrobson is the one wanting this feature, and he is a web coder ninja himself... (hint, hint)
In order to make the cards look better (like Trello), we would have to recreate several upstream UI classes.  

For this image, I opted to use the basic icon class PHUIIconView() which has constants that control the css and celerity resource implementation.  The icon size is set by the constant HEAD_SMALL which makes it 35px square.  This was overridden in a recent update in the phabricator-side-menu-view.css (phabricator-icon-nav .phui-icon-view.phuihead-small) that sets it as 24px square.  This can be seen here: https://phab08.wmflabs.org/project/sprint/board/27/

I do not think that this card style is very nice and it could be improved.  But, the small image is there for now.
In order to make the cards look better (like Trello), we would have to recreate several upstream UI classes.  

For this image, I opted to use the basic icon class PHUIIconView() which has constants that control the css and celerity resource implementation.  The icon size is set by the constant HEAD_SMALL which makes it 35px square.  This was overridden in a recent update in the phabricator-side-menu-view.css (phabricator-icon-nav .phui-icon-view.phuihead-small) that sets it as 24px square.  This can be seen here: https://phab08.wmflabs.org/project/sboard/27/

I do not think that this card style is very nice and it could be improved.  But, the small image is there for now.
Thank you! Not bad at all for sprints, where there are less tasks and all of them are supposed to be assigned to someone. I can also see its usefulness in non-sprint projects, but that depends on https://secure.phabricator.com/T4863, which is a longer term game.

I think it would be better to use the smallest version of the avatar, like the one used in the log of tasks (i.e. see above "Aklapper triaged this task as "Needs Volunteer" priority.").

Also, the boxes might need to be arranged differently. Currently the height of the avatar pulls "Points:" down, which looks bad and makes the size of the card bigger.
Check https://phab08.wmflabs.org/project/sprint/board/27/ for demo and test of this feature.
Check https://phab08.wmflabs.org/sprint/board/27/ for demo and test of this feature.
Change 182463 merged by Christopher Johnson (WMDE):
adds User image icon to Sprint Board Task Cards

[[https://gerrit.wikimedia.org/r/182463]]
Change 182463 had a related patch set uploaded (by Christopher Johnson (WMDE)):
adds Owner Image Icon to Sprint Card

[[https://gerrit.wikimedia.org/r/182463]]

#patch-for-review
What I want:

1)  Open page.
2)  Insert > Image
3)  Paste in URL (from Commons)
4)  Insert image


What I got:

1)  Open page.
2)  Insert > Image
3)  Paste in URL (from Commons)
4)  No image found.
5)  Remove most of the URL
6)  Insert image.
As a user looking for a report about a MediaWiki core bug, I want to quickly look for it without bothering about non-core reports or specific components/projects, so that I find what I'm looking for before I give up out of desperation.

----

Currently, I must type N MediaWiki core projects manually in the "Projects" field. (Cf. https://secure.phabricator.com/T3670#65849, first bullet.)
This project is selected for the #developer-wishlist voting round and will be added to a MediaWiki page very soon. To the subscribers, or proposer of this task: please help modify the task description: add a brief summary (10-12 lines) of the problem that this proposal raises, topics discussed in the comments, and a proposed solution (if there is any yet). Remember to add a header with a title "Description," to your content. Please do so before February 5th, 12:00 pm UTC.
A question @Nikerabbit asked reminded me of this bug, specifically of the use case: list the #i18n tasks filed against a MediaWiki core/MediaWiki extensions component, to have an overview similar to what was provided by SMW on https://translatewiki.net/wiki/Support/Open_requests#MediaWiki .
The problem it was blocked on was disabling notifications, right? Having an umbrella project would make sense, with or without subproject support, but Andre has a point about spam.
I think this discussion deserves to be resurrected now that we have real subproject support in phabricator.
>>! In T76942#1287991, @Krinkle wrote:
> We now have the generic "Untriaged" status

There is no such task status but a "Needs Triage" priority but the task priority field is [[ https://www.mediawiki.org/w/index.php?title=Topic:Sh94hyx5vqslwf8n&topic_showPostId=shljfgkm296r8vk3#flow-post-shljfgkm296r8vk3 | not used by every team ]] so that does not entirely sound like the same.

> However, considering not all components in MediaWiki core have an appropiate place in Phabricator yet (some are simply too niche or don't fit anywhere) a "MediaWiki-Core-Misc" or "MediaWiki-Other" component may be useful.

"Misc" to me is pretty much the same as "General" which already is part of the current name... but interpretation of words might be different.

> I've tried to make a complete list of all MediaWiki core components, saved in the profile description of #MediaWiki-General-or-Unknown: https://phabricator.wikimedia.org/project/profile/135/

Uh, thanks! I hope we will remember to update that when needed...
Indeed. "Unknown" should not be its own component anymore. We now have the generic "Untriaged" status and/or workboard column for that (depending on the project in question).

However, considering not all components in MediaWiki core have an appropiate place in Phabricator yet (some are simply too niche or don't fit anywhere) a "MediaWiki-Core-Misc" or "MediaWiki-Other" component may be useful. Or perhaps having just "MediaWiki" for those suffices, though I do see a use case for being able to query those at ease (and even have a workboard for it). Doing an exclusion search is imho unacceptable. Also because the list of MediaWiki subcomponents will inevitably change over time, and will keep changing a lot in the short term as we identify more components in MediaWiki and move other things out into libraries.

I've tried to make a complete list of all MediaWiki core components, saved in the profile description of #MediaWiki-General-or-Unknown: https://phabricator.wikimedia.org/project/profile/135/
>>! In T76942#946690, @Nemo_bis wrote:
>> rename MediaWiki-General-or-Unknown to #MediaWiki 
> 
> Absolutely not. We MUST be able to search stuff in the MediaWiki-General-or-Unknown component. If you rename it #MediaWiki, it will immediately get filled with stuff which is not General-or-Unknown, and phabricator doesn't practically offer search features to counter this. Deleting the project is about as useful.

I disagree with Nemo; renaming sounds like a good idea to me. It won't get filed if the bugs are triaged, and bugs are being triaged.

More important use-case are people filing bugs, who keep accidentally adding them in `#MediaWiki-Core-Team` (perhaps since that's what pops up when searching for "mediawiki core" project).
So I'd propose creating a MediaWiki umbrella project (like VisualEditor or Multimedia) and creating a Herald rule to automatically add that umbrella project to any of the (newly created) tasks in one of MediaWiki Core's "subprojects". 

(Big) **But:**
* Adding that umbrella project to all existing tasks will create a huge number of notifications. We are talking about roughly already 4800 //open// tasks here, and for proper search results I'd prefer including also closed ones which means updating approx. 26000 tasks. I am not sure if we could (ab)use a maintenance window (like T86772) and //somehow// disable mail notifications for that time (@chasemp: Can we do that somehow?), but that's nothing I want to do in "normal mode".
* Adding that umbrella project to all existing tasks via batch-editing will be cumbersome and time-consuming as long as T76152 is not fixed. I could survive that but it'll take some time (26000 / ~100 = 260 actions). Or I need to first play more with / learn Conduit and bots. Meh.

So until these one and a half items are sorted out, we are unfortunately stuck here.
>>! In T76942#946690, @Nemo_bis wrote:
>> rename MediaWiki-General-or-Unknown to #MediaWiki 
> 
> Absolutely not. We MUST be able to search stuff in the MediaWiki-General-or-Unknown component. If you rename it #MediaWiki, it will immediately get filled with stuff which is not General-or-Unknown, and phabricator doesn't practically offer search features to counter this.

It is unclear why "we must" and who we is. 
You could search for "In All Projects: MediaWiki" && "Not In Projects: ..." and save that query. Setting that query up is pretty cumbersome though.
> rename MediaWiki-General-or-Unknown to #MediaWiki 

Absolutely not. We MUST be able to search stuff in the MediaWiki-General-or-Unknown component. If you rename it #MediaWiki, it will immediately get filled with stuff which is not General-or-Unknown, and phabricator doesn't practically offer search features to counter this. Deleting the project is about as useful.
==== Creating an MW Core umbrella project ====

1) So the proposal is to rename #MediaWiki-General-or-Unknown to #MediaWiki ? If MW Core team is fine with that I am happy to go ahead.

2) Note that for VisualEditor I set up a Herald rule (H10, but T630):

 If "Projects" include any of: {VisualEditor-ContentEditable, VisualEditor-ContentLanguage, ...}, then: Add (umbrella) project "VisualEditor", every time this rule matches. ("every time" means even if someone tries to manually remove the Umbrella project that it would be readded again to a task).
  Is the same wanted here too?

==== Renaming MW Core subprojects ====

Renaming all those MediaWiki-* core subprojects is a separate topic (this task is about searching core tasks). See the list at https://phabricator.wikimedia.org/project/query/all/?after=MediaWiki-a (and ignore some stuff like extensions, "MediaWiki-Developer-Summit-2015" project etc.) for those projects.
If we renamed "MediaWiki-Database" to "Database" this would collide with the Herald rule that I proposed above - any task with projects "MediaWiki-extensions-Foo" and "Database" (named "MediaWiki-Database" beforehand) would get an automatic "MediaWiki" project associated with that rule. I don't think this would be helpful, and if we didn't set up a Herald rule then manually adding the "MediaWiki" umbrella project is not a great use of triage time either.
So with the current situation I'm slightly against using more generic names for those MW core subprojects.
>>! In T76942#848212, @Chad wrote:
>>>! In T76942#848206, @Nemo_bis wrote:
>>> You'd search for [Database] and not [MediaWiki]
>> 
>> Is "and not" allowed in the search, filters and workboard definitions consistently? 
> 
> I see fields to exclude projects in all these places. Let me clarify:
> # Go to [[ /maniphest/query/advanced/ | advanced search ]]
> # Add "MediaWiki" to "Not in Projects"

That's one place, not "all these places". For instance the main search has no "Not in projects". https://phabricator.wikimedia.org/search/query/advanced/ 

Did you check the search forms of all applications which have knowledge of projects? (I don't even know which those are.)
>>! In T76942#848206, @Nemo_bis wrote:
>> You'd search for [Database] and not [MediaWiki]
> 
> Is "and not" allowed in the search, filters and workboard definitions consistently? 

I see fields to exclude projects in all these places. Let me clarify:
# Go to [[ /maniphest/query/advanced/ | advanced search ]]
# Add "MediaWiki" to "Not in Projects"
> You'd search for [Database] and not [MediaWiki]

Is "and not" allowed in the search, filters and workboard definitions consistently?
>>! In T76942#848047, @Nemo_bis wrote:
>> So then a database bug for MediaWiki core would be tagged [MediaWiki], [Database] instead of [MediaWiki-Database]
> 
> And how to distinguish that from, say, bugs in some extensions with the usage of the database?
> 

You'd search for [Database] and not [MediaWiki]

> Plus, did we really surrender to the idea that to do a mere search here we'll need to edit tens of thousands bugs to update their tags?

It's more than just search imho. I think the current tags are an awful way to organize bugs and my plan gives us a whole lot more flexibility in this area :)
> So then a database bug for MediaWiki core would be tagged [MediaWiki], [Database] instead of [MediaWiki-Database]

And how to distinguish that from, say, bugs in some extensions with the usage of the database?

Plus, did we really surrender to the idea that to do a mere search here we'll need to edit tens of thousands bugs to update their tags?
> So then a database bug for MediaWiki core would be tagged [MediaWiki], [Database] instead of [MediaWiki-Database]

And how to distinguish that from, say, bugs in some extensions with the usage of the database?

Plus, did we realy surrender to the idea that to do a mere search here we'll need to edit tens of thousands bugs to update their tags?
> So then a database bug for MediaWiki core would be tagged [MediaWiki], [Database] instead of [MediaWiki-Database]

And how to distinguish that from, say, bugs in some extensions with the usage of the database?
I think this is how it should be done, and I'm personally happy that no less than the MediaWiki team is willing to move in this direction. 

In addition to solving the search fragmentation problem, this also will mean that there will be better piles of untriaged tasks: a very big one (but only one) for all MediaWiki related tasks, and then one for each "discipline" (tag), where contributors specialized in that area can help with a first triage regardless of whether they are directly involved in MediaWiki core or not.

One problem to take into account are the mentions to `#mediawiki` the IRC channel. But well, chances that those mentions are written in #mediawiki related tasks are high, and if not, removing the project is easy.
>>! In T76942#842969, @bd808 wrote:
> Can we just rename #mediawiki-general-or-unknown to #MediaWiki?

In my plan that's how I'd do it, then additionally add that tag to all MediaWiki-* tagged tasks and then rename their projects to drop the MW-* prefix.
Once upon a time in Bugzilla we had a catch all component for Mediawiki:  MediaWiki -> General-or-Unknown.  #MediaWiki sounds good to me.
Here's what I've been saying to do (in a couple of places on IRC already). The current MediaWiki-* tags are awful. Instead, we should have a [MediaWiki] project in which bugs about MediaWiki go. We'd then have things like [Database], [Localization], [Editing], [Parsing] that would get applied alongside.

So then a database bug for MediaWiki core would be tagged [MediaWiki], [Database] instead of [MediaWiki-Database] (or even worse, adding a [MediaWiki-Core]).

The added benefit is that all extensions and other projects will get to use core's general tags like database or javascript for tagging their bugs too.
Can we just rename #mediawiki-general-or-unknown to #MediaWiki?
[Project organization needs to primarily work for the project owners and Quim explained above the difference. Feel free to search for items under both the Phabricator and Phabricator.org if you are looking for Phab specific tasks.]
> "Phabricator.org" project is for upstream requests, and this is clearly not one.

Debatable, but that debate is happening on other reports. Feel free to create another Phabricator subproject for issues with the phabricator.wikimedia.org instance that don't fit your definition of "specific features and configuration in our instance".
> "Phabricator.org" project is for upstream requests, and this is clearly not one.

Debatable, but that debate is happening on other reports. Feel free to create another Phabricator subprojects for issues with the phabricator.wikimedia.org instance that don't fit your definition of "specific features and configuration in our instance".
For what is worth...

"Phabricator.org" project is for upstream requests, and this is clearly not one.

"Phabricator" project is for specific features and configuration in our instance. I personally think this is not one of these.

"Project-Creators" is a Phabricator related project to work on tasks related with the creation of projects, and I personally think that this is one of these.
Please stop removing phabricator-related projects from phabricator-related reports. Searching tickets on this site is hard enough.
I think a "MediaWiki Core" project distinct from the "MediaWiki Core Team" project is fine.  It might be a little confusing, but survivable.
PS: ah, now I understand the confusion. I typed `#MediaWiki-Core` which is an additional hashtag of MediaWiki-General-or-Unknown. Sorry for the confusion. I'll edit my original comment.
>>! In T76942#823768, @Nemo_bis wrote:
> Why did you remove the Phabricator project?

Because I don't think the legit problem you are reporting should be solved with a new Phabricator feature, but with the topols we have. 

> This has nothing to do with MediaWiki code.

This is a problem that the #MediaWiki-Core-Team should be aware of, and the solution agreed should work for them in the first place. 


> Creating a new project for all MediaWiki core tasks is definitely overkill. 

In my opinion, developing a local Phabricator application to solve this probles is an overkill.

> Also, reusing the MediaWiki-General-or-Unknown name for such a new project is out of question, because we would then be unable to tell "General/Unknown" tasks from the others.

Indeed. This is why in my proposal I didn't touch it.

> Lower cost alternatives:
> 1) a local phabricator application allowing us to do regex search against projects;
> 2) a local phabricator application which, in the search form, expands a literal "MediaWiki-*" to a list of all MediaWiki core projects;

I don't see the lower cost in these proposals. They are far more expensive to develop and maintain.

> 3) a saved search across all MediaWiki core projects, maintained by the bugwrangler and prominently linked by all phabricator search forms.

That would be low cost indeed. If this is a good solution, then this is all we need.
Why did you remove the Phabricator project? This has nothing to do with MediaWiki code.

Creating a new project for all MediaWiki core tasks is definitely overkill. Also, reusing the MediaWiki-General-or-Unknown name for such a new project is out of question, because we would then be unable to tell "General/Unknown" tasks from the others. Lower cost alternatives:
1) a local phabricator application allowing us to do regex search against projects;
2) a local phabricator application which, in the search form, expands a literal "MediaWiki-*" to a list of all MediaWiki core projects;
3) a saved search across all MediaWiki core projects, maintained by the bugwrangler and prominently linked by all phabricator search forms.
Why did you remove the Phabricator project? This has nothing to do with MediaWiki code.

Creating another project for all MediaWiki core tasks is definitely overkill. Also, reusing MediaWiki-General-or-Unknown is out of question, because we would then be unable to tell "General/Unknown" tasks from the others. Lower cost alternatives:
1) a local phabricator application allowing us to do regex search against projects;
2) a local phabricator application which, in the search form, expands a literal "MediaWiki-*" to a list of all MediaWiki core projects;
3) a saved search across all MediaWiki core projects, maintained by the bugwrangler and prominently linked by all phabricator search forms.
A possible solution:

* Create `#MediaWiki-Core` as a project umbrella (we could even consider the use of the 'umbrella' icon, still with violet background)
* Batch edit all the tasks in all the MediaWiki Core subprojects and associate `#Media-Core` to them.
* Create a Herald rule consisting in adding `#MediaWiki-Core` automatically to any task associated with any of the subprojects.

I'm not sure whether this is an overkill or not, but it is very likely that @Nemo_bis is not the only person willing to perform queries across MediaWiki Core components.
A possible solution:

* Create #MediaWiki-Core as a project umbrella (we could even consider the use of the 'umbrella' icon, still with violet background)
* Batch edit all the tasks in all the MediaWiki Core subprojects and associate #Media-Core to them.
* Create a Herald rule consisting in adding #MediaWiki-Core automatically to any task associated with any of the subprojects.

I'm not sure whether this is an overkill or not, but it is very likely that @Nemo_bis is not the only person willing to perform queries across MediaWiki Core components.
Please split off a #Browser-Support-Opera-12 project from #Browser-Support-Opera. The Presto-based "classic" Opera 12.xx (and previous versions) is a completely different browser from the Chromium-based "new" Opera 15.xx (and later versions, currently at 26), having completely different and completely unrelated bugs. (There was no desktop Opera 13 or 14.)

Most of the existing bugs under this project seem to be about Opera 12, but new reports are mostly about Opera 15+. I'll be happy to re-triage them (getting the bulk task change permission would probably help).
Meh.
@matmarex: See my questions in T76302#796189 (first part before I unfortunately answered the braoder part).
We talk about 15 open tickets in total for Opera, and currently I don't want specific projects for versions of one browser (like MSIE-10, MSIE-11 etc). I think 15 tickets is small enough (and in theory, priority could be decreased for ancient Opera codebases), and I don't think that adding more projects to differentiate makes more people use the browser-support tags that we already have. I'm afraid of tagging for the sake of tagging.
@Aklapper, @Krinkle, After reading your comments, I have no strong argument myself to keep/archive these browser tags.
>>! In T76302#795544, @Qgil wrote:
> I guess at least the #Mobile-Web team will find these browser specific tags useful, and I have also seen many VisualEditor bugs being specific to i.e. Firefox.

I'm not questioning the usefulness of a bug report detailing its relation to a specific browser. I'm questioning the use in maintaining tags for them. What would be the added value over simply stating it in the title or description (like we do for the other aspects of a bug, e.g. the page, class, country, user group etc.). Sure it matters, but every other aspect of a task name/description matters too. Is it useful to add tags? Have we used these for queries in the past?

>>! In T76302#796188, @Aklapper wrote:
> 
>>>! In T76302#795501, @Krinkle wrote:
>> We should've dropped this
> 
> (..) no information should ever be lost when migrating. (..)

They could've been converted the same way we did "Severity", "Version" and "See also". Simply appended to the bug report (which probably mentions it already in the description and/or title).
There are 15 open tasks with the Opera project tag set so should not be too hard to (re)triage. 
Do you really also care about closed ones, or about Opera 12 bugs? (Basically: Is this information of any real value or are we just categorizing for the sake of categorizing.)

>>! In T76302#795501, @Krinkle wrote:
> We should've dropped this

Your "we" is not the "we" of those folks who had and have a strong opinion that no information should ever be lost when migrating. In any case we could still always archive projects in Phab if we wanted.



>>! In T76302#795544, @Qgil wrote:
> I guess at least the #Mobile-Web team will find these browser specific tags useful

At least when it came to the "Mobile Platform" field in Bugzilla, it was set zero times in the last 12 months by a mobile team. I can imagine that the absolute number isn't too different for the "Web browser" field though I haven't checked.

> A rename might help using them for the purpose they were created. For instance, what about #Opera-Specific, #Firefox-Specific...

That would have been a really good idea for Bugzilla where the "Web browser" field had a bug exposure. Now it's rather hidden as yet another project but I think I'd still go for #Opera-Browser-Specific etc.
I guess at least the #Mobile-Web team will find these browser specific tags useful, and I have also seen many VisualEditor bugs being specific to i.e. Firefox.

A rename might help using them for the purpose they were created. For instance, what about #Opera-Specific, #Firefox-Specific...
I think tagging tasks with Browser-Support at all is a wasted effort. We should've dropped this like we dropped the other fields from BugZilla (and imported as plain text in the description).
This is a huge problem for test automation.

- open any page in VisualEditor
- toolbar tools are located in `<div class="oo-ui-toolbar-tools">`
- as far as I can see, there is no unique way to access a tool in the toolbar (example: click Insert tool)
- all of them share the same classes, and none of them have unique attributes, like `id`
- the only thing that is different is the string (Cite, Insert...), but since it changes when the UI language changes, it is not usable for us
- our test automation breaks all the time because elements in the toolbar move around, and the workarounds that we have at the moment are all fragile
- the best solution for us would be if every tool in the toolbar (undo, redo, paragraph...) had an unique id
- unique classes (or any other attribute, as long as it is unique) would work for us
- if there is an attribute used for translations, it would work for us, as long as each tool has and unique attribute
- this is not just a problem in toolbar, but let's start somewhere
Change 174666 merged by jenkins-bot:
Add classes to toolbar UI elements

[[https://gerrit.wikimedia.org/r/174666]]
>>! In T76143#932189, @Esanders wrote:
> Thanks Amir. On a separate issue - would you be able to work with a JS API in this case, so we know if it's worth implementing?

This is probably a question for @zeljkofilipin. For the sake of language screenshots and testing in general it must be something that will work with Ruby and Selenium, and Zeljko is a far bigger expert in this than I am.
Thanks Amir. On a separate issue - would you be able to work with a JS API in this case, so we know if it's worth implementing?
I updated the patch. Now it adds classes only to elements that cannot be found in the DOM by Selenium in any other way. Incidentally, all of these are elements that are identified by a text label, rather than an icon. Where as icons have classes that are the same in all languages, the labels are different everywhere.

I think that the current version of https://gerrit.wikimedia.org/r/#/c/174666/ (Patch set 15) addresses all the comments above.
A 'better API' in this case would probably be giving groups unique symbolic names, then they could be accessed via 
```
ve.init.target.getToolbar().getGroup( 'structure' )
```
for example.
The problem with letting people use these classes for gadgets is they then become an undocumented API. Trevor's point about greppability is that I should be able to see a class in the code and search for it to find out who uses it and what for, this is why we add comments when classes are built dynamically. API's for gadgets should be provided directly via JavaScript, not classnames/ID. ve-test-* obviously smells - but it is clear what it does and obvious what needs to be replaced when we come up with a better API for this particular task.
I expected that the names that I gave may have to be changed. I'm generally fine with any naming scheme. If everybody is sure that these things are useful for nothing but testing then it can be ve-test-*. I can imagine that these classes can also be useful for community-developed gadgets that do Stuff with the toolbar; there were similar gadgets for WikiEditor. Also, it's kinda odd to have a class with "test" in it in usual production version, but that isn't a disaster either.
I think there is no risk in adding a couple of strings causing any noticeable performance problem. However, if this is how we are going to target things, than I can see this becoming a very common thing, and it won't be a couple of strings, it will be a ton of them.

My worry isn't even that it's "bloat" as much as cruft. If the classes are for testing only, then ideally we can namespace them as such. not only is "ve-ui-TargetToolbar-insert" not following the lowerCamelCase naming convention, but it's misleading that it's a class used for styling the ve.ui.TargetToolbar's insert object, rather than targeting it for testing.

I recommend we better quarantine such added classes, such that they are easy to grep for later on, should we come up with a less "duct tape" approach. Perhaps you could namespace testing classes as "ve-test" and describe the actual thing being tested with the class name, such as "ve-test-insertToolGroup"?
>>! In T76143#794364, @Jdforrester-WMF wrote:
> If you want robust tests, agree to my request to have the browser tests block merge. :-) Right now the tests are a basket case because they don't need to pass in master, which means they often don't. The responsibility for testing software should be with the team building it, and when they break a test they should also fix it. By having browser tests not block merge, they're just out-of-band chaff.

Amen. It would mean some serious work on the tests, but I think this is the only way to go forward. I am not sure I have ever voted -1 when we were talking about making browser tests voting, but my memory could be failing me.

> And I find it hard to believe that I still have to argue that we should have more rigorous testing, rather than a series of hacks. :-(

I am not sure what you mean here.
>>! In T76143#793969, @Jdforrester-WMF wrote:
> Also, if this is a requirement, it should be made in OOUI which ships the toolbar code, not hacked in by one of its clients. Adding the request to the OOUI project.

As far as I am concerned, this is a requirement. Amir and I did the best we could be we were pretty sure we did it wrong. Thanks for letting us know where this belongs to.
>>! In T76143#794185, @zeljkofilipin wrote:
>>>! In T76143#793969, @Jdforrester-WMF wrote:
>> I'm not sure I agree with the premise here, that bloating the DOM model and so taking up more memory/etc. is a worthwhile objective just so we can test more easily…
> 
> This is not about testing //more easily//, this is about having robust test automation. At the moment, our test automation is made up of cardboard and duct tape.

If you want robust tests, agree to my request to have the browser tests block merge. :-) Right now the tests are a basket case because they don't need to pass in master, which means they often don't. The responsibility for testing software should be with the team building it, and when they break a test they should also fix it. By having browser tests not block merge, they're just out-of-band chaff.

>>! In T76143#794289, @zeljkofilipin wrote:
>>>! In T76143#793969, @Jdforrester-WMF wrote:
>> I'm not sure I agree with the premise here, that bloating the DOM model and so taking up more memory/etc. is a worthwhile objective just so we can test more easily…
> 
> I find it hard to believe that we still have to fight for testability in 2014. If VisualEditor team does not care about it, I give up on test automation of VisualEditor.

And I find it hard to believe that I still have to argue that we should have more rigorous testing, rather than a series of hacks. :-(
>>! In T76143#793969, @Jdforrester-WMF wrote:
> I'm not sure I agree with the premise here, that bloating the DOM model and so taking up more memory/etc. is a worthwhile objective just so we can test more easily…

Do you have any data on how much memory/etc. would be taken by adding a few strings to the page?
>>! In T76143#793969, @Jdforrester-WMF wrote:
> I'm not sure I agree with the premise here, that bloating the DOM model and so taking up more memory/etc. is a worthwhile objective just so we can test more easily…

I find it hard to believe that we still have to fight for testability in 2014. If VisualEditor team does not care about it, I give up on test automation of VisualEditor.
>>! In T76143#793969, @Jdforrester-WMF wrote:
> I'm not sure I agree with the premise here, that bloating the DOM model and so taking up more memory/etc. is a worthwhile objective just so we can test more easily…

This is not about testing //more easily//, this is about having robust test automation. At the moment, our test automation is made up of cardboard and duct tape.
I'm not sure I agree with the premise here, that bloating the DOM model and so taking up more memory/etc. is a worthwhile objective just so we can test more easily… Also, if this is a requirement, it should be made in OOUI which ships the toolbar code, not hacked in by one of its clients. Adding the request to the OOUI project.
The above patch adds class `ve-ui-TargetToolbar-insert` to the Insert element. Something like this is all we need so far, if VisualEditor team thinks this is the way to go.

Before:

```
<div class="oo-ui-widget oo-ui-widget-enabled oo-ui-toolGroup oo-ui-indicatorElement oo-ui-labelElement oo-ui-popupToolGroup oo-ui-listToolGroup">
```

After:

```
<div class="ve-ui-TargetToolbar-insert oo-ui-widget oo-ui-widget-enabled oo-ui-toolGroup oo-ui-indicatorElement oo-ui-labelElement oo-ui-popupToolGroup oo-ui-listToolGroup">
```

Tested in MediaWiki-Vagrant virtual machine with VisualEditor role enabled.
Change 174666 had a related patch set uploaded (by Zfilipin):
WIP: Add a class to the toolbar button

[[https://gerrit.wikimedia.org/r/174666]]

#patch-for-review
In test2 and production(betalabs does not display the error).

In VE, open any page for Edit and insert Media - "Uncaught TypeError: undefined is not a function" is immediately displayed.

--------------------------
**Version**: unspecified
**Severity**: trivial
(In reply to Roan Kattouw from comment #2)
> Elena showed me that if you open the media dialog on a new page after typing
> some text and going to a new paragraph, the usual jQuery JSONP abort error
> thing happens, and it consistently happens every time you open the dialog.
> This probably means we are sending a request and then immediately aborting
> it.

We are immediately sending a request every time the search input is changed. In the case of opening the insert dialog, the search input should get the page title, so a request is immediately sent with that. If the request is sent and is immediately aborted even if no other detail was changed (so, if you didn't change the search input at all) then maybe there's an issue with the way the input is updated. But then, the search appears, so the request doesn't seem to be cancelled immediately.

I'm not entirely sure what goes on there with the JSONP failures, but if this is about cancelling requests before they're done, I'm not entirely sure we can do anything about it -- requests are sent when the input is changed, which means that when the user types, we send each request on keystroke. If you're writing a whole word of 5 letters, then you'll get 4 cancelled requests and 1 completed one.

Changing this behavior would mean adding some "search" button to do the search on click rather than instantaneously on keystroke, and that's not the behavior we want.
Elena showed me that if you open the media dialog on a new page after typing some text and going to a new paragraph, the usual jQuery JSONP abort error thing happens, and it consistently happens every time you open the dialog. This probably means we are sending a request and then immediately aborting it.
Works fine for me in production (enwiki), test2 and beta labs.
Change https://gerrit.wikimedia.org/r/#/c/171326/ shouldn't have to trigger bundle-rubocop.

Affects at least mediawiki-extensions-VisualEditor and oojs-ui repos, probably more.
Confirmed that Rubocop still runs on //e.g.// https://gerrit.wikimedia.org/r/187166 which has a Ruby file.
Change 187805 merged by jenkins-bot:
rubocop: Run *-bundle-rubocop only if relevant files were modified

[[https://gerrit.wikimedia.org/r/187805]]
Change 187805 had a related patch set uploaded (by Krinkle):
rubocop: Run *-bundle-rubocop only if relevant files were modified

[[https://gerrit.wikimedia.org/r/187805]]

#patch-for-review
Unassigning myself, I am not working on it.
Seems we should only trigger it when .rubocop.* or .rb files are changed.

In Zuul something like:

jobs:
 - name: '^.*-rubocop$'
   files: '(^\.rubocop\..*|.*\.rb$)'

The same files: statement would have to be added to any other rubocop jobs defined as non voting in the jobs section. Ie:

  - name: mediawiki-core-bundle-rubocop
    voting: false
+   files: '(^\.rubocop\..*|.*\.rb$)'
For completion.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Per bug 67657, there's now key.wt going to be available in the Parsoid output; if so, we should show that, not the key name, so that "foo<!--OMG!-->bar" is shown as "foobar".

--------------------------
**Version**: unspecified
**Severity**: minor
Aha, yes.

Still, the comment might be important in some rare cases…
I think it's the other way around: Now the same code would show "foobar", and if you want to display "foo<!--OMG!-->bar" you'd need to use key.wt.
An often encountered hurdle for new editors is that they can't find out how to move a page. Generally they ask how to "change the title". Apparently - and understandably - in their mental model, the title of a page is part of the page. It would be nice if VE could accommodate that model. For that I suggest
* Make the page title editable
* If the new page title is a valid title, move the page to that location
** If the move fails, notify of the failure to automatically change the title, and link to the documentation of the move functionality, suggesting to do it manually.
* If the new page title isn't a valid title, insert a {{DISPLAYTITLE}} element to the page.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Hmm. I like this idea. Could get a bit complicated where "sometimes" it is moving the page, and "sometimes" it's setting the {{DISPLAYTITLE}}, and it's not clear which is which.

Also, moving mid-edit might be complicated on the back-end? MW relies on the title of a page /way/ too much. Something to watch for when we implement.
images overlap preformatted text box

Betalabs - desktop and mobile

Steps to reproduce: 

1. In VE insert preformatted text 
2. Insert an image  - observe that the image will be overlapping the preformatted text. 

The two screenshots are attached.

--------------------------
**Version**: unspecified
**Severity**: normal

**Attached**: {F14713}
At the moment, <pre> blocks and images overlap in the read version of pages too, so we're correct to show the same thing in VisualEditor. I'm declining this; we can file a broader bug if we want to change how the read version looks.
Created attachment 16892
desktop - image overlap preformatted area

Added attachment - VE_desktop_images overlapping preformatted text- that displays the issue clearer.

**Attached**: {F14714}
For the very few GCNs that generate wiki-link links (class=new etc.).

--------------------------
**Version**: unspecified
**Severity**: trivial
Change 345607 merged by jenkins-bot:
[mediawiki/extensions/VisualEditor@master] MWSaveDialog: Run links through a render function for preview & visual diff

[[https://gerrit.wikimedia.org/r/345607]]
>>! In T73900#3146112, @Esanders wrote:
> What did you mean by non-template GCN? Extension nodes?

Yes.
Change 345607 had a related patch set uploaded (by Esanders; owner: Jforrester):
[mediawiki/extensions/VisualEditor@master] MWSaveDialog: Run links through a render function for preview & visual diff

[[https://gerrit.wikimedia.org/r/345607]]
What did you mean by non-template GCN? Extension nodes?
(Uploaded Gerrit change 167249 for that)
Yeah. More with bug 65353 really
In the top template at https://it.wikipedia.org/wiki/Korova_Milk_Bar?veaction=edit "migliorare questa voce", which leads to https://it.wikipedia.org/w/index.php?title=Korova_Milk_Bar&action=edit , shows up as red. This is related to this bug, I guess?
Open the link inspector and just type in double slash(forward), click done.It gets inserted in the CE as an external link.
The external links should be validated for correct format.

--------------------------
**Version**: unspecified
**Severity**: enhancement
I raised this  ticket, because i thought there should be some sort of client-side validation for external link entries.What I mean is, when i type in a "//" or "//foo" then even the  external link icon should not get inserted to the page. Right now it is only after saving the page,you would see that "//" is saved as a text and not a link.
(In reply to Ritu Swain from comment #2)
> it could follow the HTTP URL syntax.

What is that syntax? What about other protocols? How to define what's "valid" without excluding other valid URLs?
(In reply to Andre Klapper from comment #1)
> [Problem is unrelated to specific browsers hence removing 'Web browser'
> field entry. "should be" -> new feature, hence setting 'Severity' to
> 'enhancement'.]
> 
> (In reply to Ritu Swain from comment #0)
> > The external links should be validated for correct format.
> 
> Do you have any definition (or even regular expression) in mind for "correct
> format"?
> it could follow the HTTP URL syntax.But right now anything that has a double slash("//" or "//foo") is taken as an external link.
[Problem is unrelated to specific browsers hence removing 'Web browser' field entry. "should be" -> new feature, hence setting 'Severity' to 'enhancement'.]

(In reply to Ritu Swain from comment #0)
> The external links should be validated for correct format.

Do you have any definition (or even regular expression) in mind for "correct format"?
*If* the scope of the link inspector is supposed to support URIs as per http://www.ietf.org/rfc/rfc3986.txt this could become complex...
This suggestion comes from Gebruiker:Stratoprutser at nl.wp.

--------------------------
**Version**: unspecified
**Severity**: enhancement
>>! In T73612#3588103, @Prtksxna wrote:
> Has this come up as a problem again?

There was some confusion about a similar problem (see T174898), but this specific problem hasn't come up. I'm changing priority to reflect the state of things here.
>>! In T73612#775328, @Jdforrester-WMF wrote:
> …so although we could add a "paste unformatted" button it would feel very odd…

Where do you think this would make sense? Within the //Insert// menu? One option could be to add it in the right click context menu, but I am sure hijacking that will come with problems of its own.




>>! In T73612#775330, @Jdforrester-WMF wrote:
> If you couldn't find it then probably others couldn't either; we should keep this open until we come up with a good way to expose this.


Has this come up as a problem again?
(In reply to Stratoprutser from comment #4)
> ok my bad, thanks for the follow-up, closing

If you couldn't find it then probably others couldn't either; we should keep this open until we come up with a good way to expose this.
**m8r-0p6s0d** wrote:

ok my bad, thanks for the follow-up, closing
(In reply to Stratoprutser from comment #2)
> Ah! In Firefox ctrl shift v opens Ad blocks' blockable items dialog, but
> disabling adblocker indeed pastes unformated.
> 
> Not sure if it needs a button or an entry under "Insert", but its always
> nice to have such a hidden feature somewhere exposed?

If you click on the help icon, then "keyboard shortcuts" ("Tastaturkürzel" in German), it is listed there along with the other standard shortcut commands. Unfortunately browsers will not let us provide cut/copy/paste buttons, so although we could add a "paste unformatted" button it would feel very odd…
**m8r-0p6s0d** wrote:

Ah! In Firefox ctrl shift v opens Ad blocks' blockable items dialog, but disabling adblocker indeed pastes unformated.

Not sure if it needs a button or an entry under "Insert", but its always nice to have such a hidden feature somewhere exposed?
This is already available via the standard shortcut (Ctrl/Cmd+Shift+V), and it's listed in the dialog of all keyboard shortcuts.

Is this asking for a button to do this as well?
A fr.wp editor uses centered lists in his sandbox, https://fr.wikipedia.org/wiki/Utilisateur:NemesisIII/Brouillon#Le_spectacle  (diff:  https://fr.wikipedia.org/w/index.php?diff=107080711&oldid=107080641 ).

--------------------------
**Version**: unspecified
**Severity**: enhancement
Sometimes you know the name of an image, but need to be able to find it on a large page.  It would be convenient if searching (with Command-F or Control-F) could find the image this way.
If we did this, we would need to highlight the matching text. We could do that by popping open the inspector which contains the matching file name and highlighting inside it. We'd still have to handle the common case of words which don't appear in an inspector because the title is too long, though.

Somewhat similar to T103286.
If we did this, we would need to highlight the matching text. We could do that by popping open the inspector which contains the matching file name and highlighting inside it.

Somewhat similar to T103286.
Hello. As discussed in [[https://it.wikipedia.org/wiki/Discussioni_MediaWiki:Visualeditor-ca-editsource | :it:Discussioni_MediaWiki:Visualeditor-ca-editsource ]] we'd need a way to get the same editing labels of en.wiki (in italian, obviously), that are "Edit", "Edit source" and "Edit beta":

* When VE is disabled by user, show these labels: "EDIT" (for wikitext)
* When VE is enabled, show these labels: "EDIT SOURCE" (for wikitext), "EDIT BETA" (for VE)

Now on it.wiki there are "Modifica sorgente" (edit source) for the classic edit when VE is off and "Modifica" (edit) both for the VE edit and for the classic edit when VE is enabled. There's a way to have three different labels to change according to the consensus that emerged?

Thanks,
Horcrux92

P.S. Sorry for the probably erroneous categorization.

--------------------------
**Version**: unspecified
**Severity**: normal
>>! In T72230#1034842, @Aklapper wrote:
> It was difficult to understand because I assumed you want to potentially display three labels. Initial description wasn't entirely clear. Alright then, thanks for clarifying and your patience :)

Thank to you.
My probable guilt is I haven't got a very wide english lexicon, so the repetitions in the sentences may be confusing.
It was difficult to understand because I assumed you want to potentially display three labels. Initial description wasn't entirely clear. Alright then, thanks for clarifying and your patience :)
>>! In T72230#1034779, @Aklapper wrote:
> Sorry but I'm getting lost here (plus I don't know implementation details as I'm not a developer). 
> 
> Could you please edit the task description here and finish these two sentences:
> * When VE is off: Show these labels in this order: ...
> * When VE is on, show these labels in this order: ...
> plus for the case of just displaying "Edit", please also explain what "Edit" would do (either wikitext or VE).
> That might things less confusing here. Sorry. :-/

Maybe I should give up...

* When VE is disabled by user, show these labels: EDIT
* When VE is enabled, show these labels: EDIT SOURCE, EDIT BETA
EDIT would open the classic edit mode, that is the wikitext editing (ovviously, since VE is disabled).

The labels' names are indicative (they would be editable in the MediaWiki namespace) and I don't care about the order.

Why it is so difficult to understand? It would be the <u>same</u> setting of en.wiki.
>>! In T72230#1034779, @Aklapper wrote:
> Sorry but I'm getting lost here (plus I don't know implementation details as I'm not a developer). 
> 
> Could you please edit the task description here and finish these two sentences:
> * When VE is off: Show these labels in this order: ...
> * When VE is on, show these labels in this order: ...
> plus for the case of just displaying "Edit", please also explain what "Edit" would do (either wikitext or VE).
> That might things less confusing here. Sorry. :-/

Maybe I should give up...

* When VE is disabled by user, show these labels: EDIT
* When VE is enabled, show these labels: EDIT SOURCE, EDIT BETA
EDIT would open the classic edit mode (wikitext editing).

The labels' names are indicative (they would be editable in the MediaWiki namespace) and I don't care about the order (ovviously, since VE is disabled).

Why it is so difficult to understand? It would be the <u>same</u> setting of en.wiki.
>>! In T72230#1034779, @Aklapper wrote:
> Sorry but I'm getting lost here (plus I don't know implementation details as I'm not a developer). 
> 
> Could you please edit the task description here and finish these two sentences:
> * When VE is off: Show these labels in this order: ...
> * When VE is on, show these labels in this order: ...
> plus for the case of just displaying "Edit", please also explain what "Edit" would do (either wikitext or VE).
> That might things less confusing here. Sorry. :-/

Maybe I should give up...

* When VE is disabled by user, show these labels: EDIT
* When VE is enabled, show these labels: EDIT SOURCE, EDIT BETA
EDIT would open the classic edit mode (wikitext editing).

The labels' names are indicative (they would be editable in the MediaWiki namespace) and I don't care about the order.

Why it is so difficult to understand? It would be the <u>same</u> setting of en.wiki.
Sorry but I'm getting lost here (plus I don't know implementation details as I'm not a developer). 

Could you please edit the task description here and finish these two sentences:
* When VE is off: Show these labels in this order: ...
* When VE is on, show these labels in this order: ...
plus for the case of just displaying "Edit", please also explain what "Edit" would do (either wikitext or VE).
That might things less confusing here. Sorry. :-/
>>! In T72230#1034429, @Aklapper wrote:
>>>! In T72230#1034061, @Horcrux92 wrote:
>> Because "edit" is ambiguous.
> 
> If that's ambiguous then why request three labels, instead of two that are not ambiguous (classic wikitext editing, VE editing)?

The third one would appear when VE is off and must be independent from the other two (like on en.wiki).

Instead of quote only four words, I please you to try to answer to my two questions.
>>! In T72230#1034429, @Aklapper wrote:
>>>! In T72230#1034061, @Horcrux92 wrote:
>> Because "edit" is ambiguous.
> 
> If that's ambiguous then why request three labels, instead of two that are not ambiguous (classic wikitext editing, VE editing)?

The third one would appear when VE is off and must be independent from the other two (like on en.wiki).

Instead of quote only four words, try to answer to my two questions.
>>! In T72230#1034061, @Horcrux92 wrote:
> Because "edit" is ambiguous.

If that's ambiguous then why request three labels, instead of two that are not ambiguous (classic wikitext editing, VE editing)?
Because "edit" is ambiguous. Why the basic "edit" should be the VE-mode?

We discussed it a lot (as can you see in the page that I linked in the first post) and we'd like to be able to put into practice our decisions.

The real question I'd like to make is: why on en.wiki it's possible to have three distinct labels (two for VE-mode on and one for VE-mode off) and on it.wiki it is not?
>>! In T72230#1033724, @Horcrux92 wrote:
> The problem is that we cannot turn the label "Edit" in "Vidual edit" without changing the same label for who has got VE off.

I understand that part, but why do you want to turn "Edit" into "Visual edit"? The intention behind this would be welcome and why you think that it's not more confusing.
The problem is that we cannot turn the label "Edit" in "Vidual edit" without changing the same label for who has got VE off.

For us this is a problem, maybe not to big but I thought you would have been able to solve it.
My question "Which problem do you try to solve?" is still unanswered though...
(In reply to Andre Klapper from comment #1)
> Hi,
> what would "Edit Beta" do if you already have the two other buttons? 
> Which problem do you try to solve? What's the URL to the discussion?

https://it.wikipedia.org/wiki/Discussioni_MediaWiki:Visualeditor-ca-editsource

We would like to:
1) edit the label "Modifica" (edit) in "Modifica visuale" (visual edit) for the edit made with VE;
2) edit the label "Modifica sorgente" (edit source) in "Modifica" (edit) for the classic edit (when VE is enabled);
3) mantain the label "Modifica" for the classic edit (when VE is disabled);

And, if I have correctly understood, the 1 and the 3 are impossible to do together, because both of them refer to MediaWiki:Visualeditor-ca-editsource.

The same goes for the label [edit] near the section titles.

If it can be useful, I forget to say that on en.wiki (as you may know) VE is disabled by default, while on it.wiki it's enabled by default.
Hi,
what would "Edit Beta" do if you already have the two other buttons? 
Which problem do you try to solve? What's the URL to the discussion?
A Wikipedia editor raised the following problem: When experienced Wikipedians want to add a template in the source editor, they can copy the template code without parameter values, which usually appears on template documentation pages, and then fill all the parameters one by one, and eventually delete the unneeded empty lines.

In VE, parameters must be added one-by-one, and this feels less efficient. As the default behavior this may be OK, but there can be a button that shows all the available parameters.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=72083
How would this work? How does VisualEditor know that you wanted a field specified and left blank, vs. haven't set it?
Lines starting with ; are not recognized as wikitext and just saved, only afterwards revealing their wikitext meaning:

https://wikimania2014.wikimedia.org/w/index.php?title=User%3ADeryck_Chan%2FWMUK_report&diff=49488&oldid=49487

Reported: https://www.mediawiki.org/wiki/Thread:VisualEditor/Feedback/;caption

--------------------------
**Version**: unspecified
**Severity**: trivial
The current behavior in production: 
;(semi-colon) triggers a warning "Wikitext markup detected..."
: (colon) adds <blockquote></blockquote>
Indeed. This is intentional. Use of a ":" to "indent a paragraph" (as multiple people who are wikitext experts have complained) is a sign that they're doing it wrong. :-) This is a much better outcome for editors – doing what they "meant" to do – and for readers.
I don't think that's exactly correct:  the ; semi-colon and the : regular
colon are supposed to create association lists (aka definition lists,
because they're used for glossaries a lot).  I believe that a <blockquote>
is a different thing.

Whatamidoing (WMF)/Sherry Snyder
Community Liaison
Wikimedia Foundation, Inc.
Verified in beta and test2 - a semi-colon will trigger a wikitext warning; a colon(:)  - indicates a <blockquote> text.
Change 175909 merged by jenkins-bot:
Warn users who write ';' or ':' on a new line that it won't work

[[https://gerrit.wikimedia.org/r/175909]]
Change 175909 had a related patch set uploaded (by Jforrester):
Warn users who write ';' or ':' on a new line that it won't work

[[https://gerrit.wikimedia.org/r/175909]]

#patch-for-review
Goal:   

* Add something to an existing citation that the template shouldn't include, like a {{verify credibility}} tag.
* Assign a citation to a references group.


Steps to reproduce:

1.  Open a page containing a {{cite book}} template.
2.  Click on the citation to edit it.
3.  Think, "Um, I don't actually want this ''in'' the template; I want this ''after'' the template."
4.  Give up.


~~This can be done, if you happen to know that the thing to do is to select the ref, ignore the tag that pops up, go to the Cite menu, and choose Basic~~ (after Citoid replaced the old Cite menu, this is no longer possible).  But the ability to edit these refs would be more discoverable if the Cite Book dialog had a button at the bottom for "Use reference editor".
{T180104} looks related.
MediaWiki: CSS/JS pages on any non-large wiki are usually a mess. Occasionally, we'll discover that wikis have been loading external resources for months and no one noticed. In addition, the local sysops maintaining those pages usually don't know JavaScript and are copy-pasting what someone else told them to do. Even when that's not the case, mistakes can result in code with [[https://szl.wikipedia.org/w/index.php?title=MediaWiki%3ACommon.js&diff=prev&oldid=208782|obvious syntax errors]] being sent to readers for long periods of time.

Various proposals have floated around over the years. The wikitech-l threads have some good discussion on some of the reasons why this is difficult for smaller wikis.
* Wikitech-l:
  * [[http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/74283|No longer allow gadgets to be turned on by default for all users on Wikimedia sites]] (specifically about Gadgets though)
  * [[http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/79080/|Deployment targets and preferences (was: Superprotect user right, Comming to a wiki near you)]]
* Wikimedia-l: 
** [[http://thread.gmane.org/gmane.org.wikimedia.foundation/74166|Next steps regarding WMF<->community disputes about deployments]]
** [[http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/79055/|Superprotect user right, Comming to a wiki near you]]

**See Also**:
* {T39230} (bug 37230)
* {T53651} (bug 51651)
* {T71550}
* {T121470}
* {T165981}
* {T120886}
* {T171563}
another possibility outside of Gadget 2 is a test wiki where any JS, CSS or Lua is tested and then moved over to the main WMF wikis after having a +2 code reviewer approve merging it over. The MediaWiki namespace is mostly interface messages, restricting JS & CSS editing to new permissions might make this safer as well; editusercssJS was split into separate permissions though seems to be limited use cases (someone breaking personal js/css).
I think relying on Git is a good idea, but I think you underestimate that by moving contributing to these files to a git, you remove it from direct access from the wiki. I think it will feel like we're taking away control form the community, even if this isn't the intention, as we in some way remove the direct editing possiblity from the wiki and make it more difficult to contribute there for normal user.

We have to find a compromise to minimize this problem, because this wouldn't ever be accepted otherwise. (Many users still remember the js wheel-war between WMF and community at German Wikipedia to well, even if it's been a long time ago and many things have changed.)
CodeReview + FlaggedRevs is a possible way to handle this task, although not a good one. SVN-style "linear" history sucks for code review (which is why pretty much every single projetc abandoned it when DVCS-s became mainstream), and implementing non-linear history in MediaWiki does not sound like fun, so the most promising approach is to make MediaWiki sync with the master branch of some remote repo, after which there is no point in rebuilding the code review interface in MediaWiki, since there are plenty decent ones out there.
>>! In T71445#3612257, @SpookyGhost8 wrote:
> There also is [[ https://www.mediawiki.org/wiki/Extension:CodeReview | Extension:CodeReview  ]] but status is historical reference, perhaps reopening that for development would be a potential solution?

CodeReview is perfectly stable and usable and (mostly) feature-complete. The `{{Historical}}` template was added to that page by someone who doesn't appear to be familiar with the extension. There is absolutely nothing preventing you from installing and using CodeReview -- or if there is, that's a bug and I'd love to hear about it so that we can get it fixed! Just because something isn't used on Wikimedia's wikis anymore doesn't mean it's flat-out obsolete and/or unusable.

All that being said, CodeReview is mostly a web UI for a Subversion (SVN) repository. The workflow is essentially different when it comes to a SVN repository as opposed to editing on-wiki .css and .js pages: changes to the latter are live immediately, whereas code changes committed to a SVN repo need to be manually deployed by someone.
It is my firm belief that creating a largely new system for "code reviewing" on-wiki .css and .js pages would be the easiest and cleanest solution instead of trying to repurpose CodeReview. In any case, please feel free to add me as a reviewer to CodeReview patches and I'll be happy to review 'em (unless someone else beats me to it, that is).
There also is [[ https://www.mediawiki.org/wiki/Extension:CodeReview | Extension:CodeReview  ]] but status is historical reference, perhaps reopening that for development would be a potential solution?
From what I remember that was already done in #Gadgets-2.0.
Would it be more secure to possibly add in a few more custom user permissions such as splitting editinterface into editJS and editCSS with also adding in restrictions for template namespace and editLua for Lua? I know that edituserjs&css was split into edituserjs and editusercss. This way the mediawiki namespace would contain the interface messages; all javascript is restricted to .js and users with editJS, all css is restricted to .css and users with editCSS; all lua modules restricted by editLua; possibly restrict templates to editTemplate. Just a suggestion...
In relation to {T158149}, I dare to ask: what is the current status? :)
See also {T171563}, which I just created for the rest of the problem (pages outside MediaWiki: namespace, still a very large set with some potential vulnerabilities).
Based on my work around T165981 during the 2017 Hackathon - which essentially involved creating a prototype implementation of Wikia's ContentReview extension compatible with core MediaWiki - I would like to note the following:

Creating an extension that just requires site JS to pass certain requirements (manual review, automated tests) before it is served to other users is relatively easy to develop. As discussed above and elsewhere, such a system has been in operation at Wikia since 2015 - its main benefits are that it has a clear workflow, and is tightly integrated into MediaWiki.

I'm on the opinion that if extra code review features are required from this product, such as branching or line comments, implementing them within MediaWiki would be a bad idea. It would have to reconcile MediaWiki's concept of singular multi-revision pages with the paradigm of a branching VCS - an extension implementing this could easily become a highly complex behemoth that is a nightmare to develop, maintain and sustain.

If the decision is to extract the code review functionality from MediaWiki, it is possible to leverage the power of existing VCS and code review tools, such as Gerrit. In this scenario, the setup can be further simplified by completely eliminating JS pages handling from inside MediaWiki. The versatility of ResourceLoader makes it possible to define configurable custom modules that pull their source content from an external data source instead of MediaWiki pages.
Just an idea: what about committing to have an initial plan agreed by the end of Wikimania -- latest? Just an arbitrary date, but a firm one. A driver would be required to stir the discussion and draft plan, though.
Note that, for templates and modules, a branch-like system is already used manually on English Wikipedia (and probably other wikis) via template/module sandbox pages, though there's no hard requirement for their use to propose changes.
>>! In T71445#3039577, @Samwilson wrote:
> […]
> The tricky part of it I think is whether or not it's going to be possible to set up a development environment (or e.g. use an existing test wiki) in which to work on scripts etc. and then easily move them from there to code review and then to the live wiki.

That's why I'd prefer a more universal approach: If you think of a wiki as a whole as a Git (or similar) repository, you could test in a particular "branch" (even if for example a change in a template system requires edits to multiple templates pages) and, after testing, merge it to "master".  Proposed changes to protected pages could be submitted as branches and, if approved, merged.  Changes to (subelements of) the main page or other portals could be mocked up without having to fiddle with all the dependent links.  Flagged revisions would be a special case where there is a social contract to merge changes to a particular branch regularly.  Users could save their incomplete rewrites of a page in a branch without having to copy & paste it to their computer.  Etc.

That wouldn't make the solution to this task easier, but if the solution to this task already is complex, it would be nice if it solves other use cases as well.
@MZMcBride: the difference between on-wiki JS and CSS and pretty much any other wiki page (although templates and modules sometimes also fall into this category) is that edits to them can break the whole site for other users. So it's not about trying to limit editing of these to "professionals", but just to make it less likely to introduce errors.

Which is why these pages are often protected and left to admins to edit. But even people who know what they're doing (which is all I would take "engineers" in the above sense to mean) can make mistakes and would benefit from a process of being able to propose changes and have those changes be easily reviewed by other people before they go live and suddenly make everyone's search autocomplete stop working. :-)

I'd also say that no one seems to be suggesting Gerrit as a solution. I'm not super familiar with Differential, but I guess it's better (or does it just have more whitespace and better-looking buttons?) On the other side of the fence, there's Github and seemingly a lot of people find that relatively easy to use. So surely we can have figure out something that works.

The tricky part of it I think is whether or not it's going to be possible to set up a development environment (or e.g. use an existing test wiki) in which to work on scripts etc. and then easily move them from there to code review and then to the live wiki.
>>! In T71445#1459477, @Krinkle wrote:
> Everybody is welcome to contribute ideas, create tasks, start polls, etc. but you need an engineer to do the engineering. When I say "engineers" I'm not referring to Wikimedia Foundation staff. Instead, it should fully embrace open source.

I agree with most of what you write in this comment. I'll note that there's a view that engineer should be treated similar to a term like doctor, and should require at least a degree in engineering. Developers, coders, or programmers might be more apt.

I also don't really love the notion that engineers need to do the engineering (even when broadening the terms to be almost meaningless). Wikipedia is not exclusively written by professional encyclopedists, Wiktionary is not exclusively written by professional lexicographers, Wikinews is not exclusively written by professional reporters, etc.

>>! In T71445#3028613, @Tgr wrote:
> This was the second (slash third, in a tie) most popular item in the [[https://www.mediawiki.org/wiki/User:Community_Tech_bot/WishlistSurvey/Votes|Developer Wishlist results]]. Any thoughts about the next step?

I would recommend re-reading this task. It's quite long, but contains a lot of good and useful thoughts.

Speaking of engineers and engineering, it strikes me as odd and interesting that the Gerrit code review process isn't really well-liked (cf. {T114419}, etc.), and yet we're expecting the same people to build a "sane code-review process" that integrates perhaps Git, perhaps wiki pages, and definitely an even larger and more diverse group of Wikimedians?
If this could be done as an extension that talks to //any// git repository (as configured by site admins), then it would work with whatever Git code review system people want (i.e. Wikimedia sites could use Gerrit or Differential), and third-party wikis could do it with Github.

An extension could easily update a given set of gadget's pages based on the content of files in a public Git repository somewhere. It'd be really cool if changes made locally could also be pushed out to that repository as review-requests — although perhaps it's more likely that the set up would be that some wikis are configured to //only pull// from the repo (because that's the point of requiring code review after all), and it'd be possible to configure development wikis to send new code to the repo (and to receive updates when the user asks for them).

Is there a possibility that such an extension could be a sort of global gadget system? The code is still duplicated, but it's controlled centrally. Would work for templates and modules too.
>>! In T71445#3028613, @Tgr wrote:
> I guess first we should determine if this needs to be done inside MediaWiki
Yes please.

> or the community would accept something based on gerrit/github/whatever (which would be much less work and would provide much better tooling integrartion).
Gerrit is awful [no citations needed] and GitHub is proprietary, and plenty of people -- developers and users alike -- care about the solution being as FOSS as possible.

Anyway, I don't think doing this as a MediaWiki extension is impossible; there are probably a few tricky questions to solve and whatnot, but considering that [[https://github.com/Wikia/app/tree/dev/extensions/wikia/ContentReview|Wikia managed to implement a similar system]], it should be doable. I'd be interested in helping out where possible to get this thing built.
This was the second (slash third, in a tie) most popular item in the [[https://www.mediawiki.org/wiki/User:Community_Tech_bot/WishlistSurvey/Votes|Developer Wishlist results]]. Any thoughts about the next step? I guess first we should determine if this needs to be done inside MediaWiki or the community would accept something based on gerrit/github/whatever (which would be much less work and would provide much better tooling integrartion).
This proposal is selected for the developer wishlist voting round and will be added to a MediaWiki page very soon. To the subscribers, or proposer of this task: please help modify the task description: add a brief summary (10-12 lines) summarizing the problem that this proposal raises, topics discussed in the comments, and a proposed solution (if there is any yet). Remember to add a header with a title "Description," to your content. Please do so before February 5th, 12:00 pm UTC.
A couple possibilities:
* write a bot that syncs page content to files on Github (or some other DVCS site to be bikeshedded later), push out the whole code review system there
* write a proper extension that does that and can load alternative branches / pull requests on demand, a bit like TemplateSandbox
* repurpose [[https://www.mediawiki.org/wiki/Extension:CodeReview|CodeReview]] to work with page revisions instead of an SVN repo, and pair it with something like FlagRev.

The second option is probably the sane one.
I've been thinking about this task a bit more with {T151408} recently filed. I wonder whether we could implement some kind of social +2 process for on-wiki JavaScript and CSS as a medium-term solution. If we needed to, we could also investigate a technical +2 process, but that's probably overkill for now.

What would a social +2 process look like? We'd try to convince the various wikis to adopt a process of proposing edits on the talk page and having more than one person review the code for sanity before editing the live JavaScript or CSS pages. This type of approach has both the same benefits and detriments as Gerrit's +2 process, of course. Gerrit implements this at a technical level and wikis could as well if needed, but a social process would be more organic and perhaps a better starting point.

A lot of the discussion surrounding security issues related to on-wiki JavaScript editing boils down to this task, I think. A true increase in security would likely only come from some kind of sane and workable code review situation. The other issues (such as bot flags) are peripheral and marginal in comparison.
Would this task be a good topic for the #wikidev17 ? If so, the deadline to submit new proposals is next Monday, October 31: https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit/Call_for_participation
@Dinoguy1000 thanks for sharing that information !
As a bit of a case study, Wikia recently experienced [[ http://community.wikia.com/wiki/Thread:890734 | two ]] [[ http://community.wikia.com/wiki/Thread:922459 | attacks ]] which resulted in revoking the ability for admins to edit pages in the MediaWiki namespace (except for a [[ http://community.wikia.com/wiki/Help:System_messages/whitelist | handful of whitelisted pages ]]), user JS being [[ http://community.wikia.com/wiki/Help:Personal_CSS_and_JS#JavaScript | made opt-in]] (and admins not being able to edit other users' CSS/JS any more either), and a [[ http://community.wikia.com/wiki/Help:JavaScript_review_process | review process ]] for sitewide JS instituted (though it's more of a [[ http://community.wikia.com/wiki/Help:JavaScript_review_process#What_are_the_criteria_for_approval.3F | lightweight sanity check ]] than a proper code review).
>>! In T71445#1469730, @demon wrote:
>>>! In T71445#1459477, @Krinkle wrote:
>> Or we can enter the realm of Git. [..] I doubt it's too complex for someone we expect to be writing code. Especially with all the existing GUI applications for Git.
> 
> I think it's very important to differentiate between "using Git" and "using Git in the same way we develop MW."

Completely agree.
>>! @demon wrote:
> I can see the argument for Git, but under no circumstances should we subject any more people to Gerrit than we already do [..]

Agreed. The repo shouldn't use Gerrit, and it shouldn't require WMF staff to add users to its access group. I'm pushing for a repo that is first and foremost maintained independently by the community and deployed often (at least weekly; with the option to ride WMF-SWAT deployment schedule for individual changes so they can even push changes twice a day when needed). Phabricator makes sense, but if the community has other suggestions we should consider those as well.
The idea of Git but not Gerrit for gadget developers is sensible. It fits with T1238 and the idea of bringing gadget developers together and closer to our wider developer community.

I agree that a code review extension for MediaWiki would put us in a costly spin-off. Differential is already enabled [[ https://phabricator.wikimedia.org/differential/query/all/ | here ]] (and in [[ https://phab-01.wmflabs.org/differential/query/all/ | phab-01 ]] if someone wants to play with it). Barriers are obstacles but also defenses. If there are barriers for gadget developers they will be barriers also for other developers. Better work on minimizing common barriers than creating different workflows to achieve the same goals.

The process for deploying patches for gadgets from Differential to Wikimedia projects would need a plan. Would this be the same process as for MediaWiki core and extension patches (meaning that this plan is also blocked on {T18}) or can some shortcuts be taken?

>>! In T71445#1459477, @Krinkle wrote:
> this "gadget repository" should be viral. Similar to how wikis hand out access for bureaucrats and sysops. In the common case, all granting and revoking of access in this context should be handled by the community, not staff.

Nothing that Differential cannot handle, right?
>>! In T71445#1459477, @Krinkle wrote:
> Back in 2006, Wikimedia had a tightly controlled repository (SVN). There was little manpower to maintain separate access controls. Deployments were scarce (every 3-6 months). For those reasons, it was not feasible and not reasonable to maintain gadgets in SVN.
> 

Heh, "tightly controlled." Yes, you couldn't just sign up...but all you had to do was ask and not be an idiot. Versus now where anyone can sign up, but it's impossible to get trusted access to anything :p

I disagree that there was lack of manpower to maintain ACLs for SVN...we already did...

And...deployment cycles had nothing to do with whether we hosted Gadgets in SVN.

I actually don't even remember a discussion about putting them in SVN, but I am gladly willing to be proven wrong.

> Or we can enter the realm of Git. A small barrier that is actually quire //relevant// to software developers. I've encountered plenty of competent hobby programmers with years of experience that hadn't used Git before. It's something new, and yeah, that can be scary. But I doubt it's too complex for someone we expect to be writing code. Especially with all the existing GUI applications for Git.

I think it's very important to differentiate between "using Git" and "using Git in the same way we develop MW." Right now I think the two are a little conflated (possibly because we've had discussions about doing the latter before).

I can see the argument for Git, but under no circumstances should we subject any more people to Gerrit than we already do; the CR process it enforces is absurd, terrible, and actively scares people away. Also, I don't like the idea of building more infra in/around Gerrit when we're trying to kill the dang thing ;-)

Now, if we want to build something on Phabricator. Or just plain old Git...that could be useful or cool. But let's not ruin all the Gadget maintainers' lives by making them use Gerrit :p
>>! In T71445#1018186, @DaBPunkt wrote:
> This ticket exists to prevent users at Wikipedia of disabling stuff they don’t want.
Not really.
No it does not.
>>! In T71445#1017081, @Krenair wrote:
> Yes, and it's bad. It's why this ticket exists.

This ticket exists to prevent users at Wikipedia of disabling stuff they don’t want. That’s the hole purpose; not security, not helping, but control. Be at least so frank and say the truth.

Yes, there is the possibility that an admin could do evil stuff with JS; but at Wikipedia we have something called »Assume good faith« and until now it worked great. The users implemented so much stuff in JS and CSS that Mediawiki lacks until today – if you are underused try to fix the software (there are a few thousand bugs in here) and not implement a new kind of force-control.
>>! In T71445#1016949, @jayvdb wrote:
>>>! In T71445#1016916, @Krenair wrote:
>>>>! In T71445#1016860, @jayvdb wrote:
>>> And whenever it happens, we can improve the static analysis tools (and desysop the fool who wrote it).
>> 
>> I don't think you understand. It's not okay for us to get to this stage.
> 
> You're already in this stage.  That is reality.

Yes, and it's bad. It's why this ticket exists.
>>! In T71445#1016916, @Krenair wrote:
>>>! In T71445#1016860, @jayvdb wrote:
>> And whenever it happens, we can improve the static analysis tools (and desysop the fool who wrote it).
> 
> I don't think you understand. It's not okay for us to get to this stage.

You're already in this stage.  That is reality.
>>! In T71445#1016860, @jayvdb wrote:
> And whenever it happens, we can improve the static analysis tools (and desysop the fool who wrote it).

I don't think you understand. It's not okay for us to get to this stage.
>>! In T71445#1016685, @Krenair wrote:
> 
>>>! In T71445#1016653, @jayvdb wrote:
>>>>! In T71445#1011829, @Krenair wrote:
>>> I don't think we can just sandbox JS running on the wiki, @jayvdb
>> 
>> Firstly, that isnt what I recommended.  We can perform static analysis of the JS / CSS before it is saved.  Tools exist for this.  It doesnt need to be perfect; the JS is either written by an admin, or enabled by an admin, or a user is enabling a script in their own JS page only.  
>> More broadly, the scary area is small wikis with few admins, potentially adding code that they dont understand written by someone else, possibly malicious.  Static analysis and ops monitoring suspicious JS page saves can gradually improve static analysis to make it increasingly difficult for malicious code to come via this vector through a sysop to the wiki's Common.js.
> That's not good enough. It doesn't matter how big/small a wiki is or how many admins it has, that would only affect catching the fact that malicious JS ***has already been added*** by an admin user who is either malicious themselves (e.g. the account was taken over by someone unauthorised, or the actual authorised user was untrustworthy themselves even) or didn't know what they were doing. By then it's too late - we must catch this stuff *before* it can be run on random people's clients, e.g. with a full external code review system.

Did you look at any of the static analysis tools before writing this?  My point is that wikis have a saner environment than many of the other projects who rely on static analysis, as we have less people able to edit the JS.  And whenever it happens, we can improve the static analysis tools (and desysop the fool who wrote it).  We can also run the static analysis tools in over-protective mode, and use {{edit protected}} to engage an JS expert (with a special right) whenever the tool incorrectly detects proposed code as unsafe, due to potential security implications.
>>! In T71445#1016730, @Ricordisamoa wrote:
>>>! In T71445#1016653, @jayvdb wrote:
>> Another approach regarding JS is to migrate it to a language which is safer, and compile it into JS.  https://github.com/mherkender/lua.js
> 
> Is this a joke? Putting together two bad languages cannot result in a good one.
> And by the way, MediaWiki embeds lots of 'custom' JS libraries we must be able to use.

A bridge to 'approved' JS libraries would be needed.
>>! In T71445#1016653, @jayvdb wrote:
> Another approach regarding JS is to migrate it to a language which is safer, and compile it into JS.  https://github.com/mherkender/lua.js

Is this a joke? Putting together two bad languages cannot result in a good one.
And by the way, MediaWiki embeds lots of 'custom' JS libraries we must be able to use.
>>! In T71445#1016653, @jayvdb wrote:
>>>! In T71445#1011829, @Krenair wrote:
>> I don't think we can just sandbox JS running on the wiki, @jayvdb
> 
> Firstly, that isnt what I recommended.  We can perform static analysis of the JS / CSS before it is saved.  Tools exist for this.  It doesnt need to be perfect; the JS is either written by an admin, or enabled by an admin, or a user is enabling a script in their own JS page only.  
> More broadly, the scary area is small wikis with few admins, potentially adding code that they dont understand written by someone else, possibly malicious.  Static analysis and ops monitoring suspicious JS page saves can gradually improve static analysis to make it increasingly difficult for malicious code to come via this vector through a sysop to the wiki's Common.js.
That's not good enough. It doesn't matter how big/small a wiki is or how many admins it has, that would only affect catching the fact that malicious JS ***has already been added*** by an admin user who is either malicious themselves (e.g. the account was taken over by someone unauthorised, or the actual authorised user was untrustworthy themselves even) or didn't know what they were doing. By then it's too late - we must catch this stuff *before* it can be run on random people's clients, e.g. with a full external code review system.
>>! In T71445#1011829, @Krenair wrote:
> I don't think we can just sandbox JS running on the wiki, @jayvdb

Firstly, that isnt what I recommended.  We can perform static analysis of the JS / CSS before it is saved.  Tools exist for this.  It doesnt need to be perfect; the JS is either written by an admin, or enabled by an admin, or a user is enabling a script in their own JS page only.  
More broadly, the scary area is small wikis with few admins, potentially adding code that they dont understand written by someone else, possibly malicious.  Static analysis and ops monitoring suspicious JS page saves can gradually improve static analysis to make it increasingly difficult for malicious code to come via this vector through a sysop to the wiki's Common.js.

However there are ways to sandbox JS. Again, tools exist and are in production. https://en.wikipedia.org/wiki/Caja_project 

Another approach regarding JS is to migrate it to a language which is safer, and compile it into JS.  https://github.com/mherkender/lua.js  Then the only 'real' JS is libraries provided by extensions managed by code review processes.
I don't think we can just sandbox JS running on the wiki, @jayvdb
Maybe a tool like https://www.mediawiki.org/wiki/Gerrit_patch_uploader can be created to supplement Phab/etc.

Not that I agree with this idea ; IMO we'd be far better off identifying the problematic uses of .css and .js and requiring a new right to save changes which appear to have security implications. That allows gradual improvement, and is not too dissimilar to security checks used on uploads.  And 'safe' functions added to properly managed JS modules whenever Common.js editors hit their head too regularly on the security inspector.
Ref web-based editor in Phabricator, as commented in T71445#742556, we checked upstream, but generally speaking they are not enthusiastic with the idea. See their reasoning at https://secure.phabricator.com/T6008#7
>>! In T71445#1005858, @Krinkle wrote:
> Using Git does raise the barrier for contribution a little.

This is a concern, though. While Phabricator uses SUL and so doesn't have the issues that earlier proposals of using Gerrit did, until WMF has moved from Gerrit to Phabricator for code review it's hard to really guess how this might work in practice for people who maintain gadgets on-wiki and aren't used to other workflows.

Ideally one workflow would be loading the gadget files in a web-based editor of some sort, making the changes, and submitting that as a patch without having to use any locally-installed software other than a web browser and without any complicated key setup. But does Phabricator support that (and will it be enabled here)?
>>! In T71445#1005858, @Krinkle wrote:
> We'd have a clear distinction between the "wiki-content administrator" role (sysop) and "developer" role. One person can still have both roles, but sysop would no longer imply "developer". We currently have a situation where users can become sysop (to block users, delete pages, etc.) – but at the same time able to change gadgets. (Through the MediaWiki-namespace that got unfortunately re-used for Gadgets). This isn't a matter of personal trust or malicious intent. These users have clearly gained the respect and trust of their respective communities. It's about technical competence and experience to make decisions about software modifications. This is a sensitive area. It's not fair to demand from most sysops that they have to make these decisions. They shouldn't have to deal with requests for edits on Common.js without knowing what the impact of such program would be.

Conversely, more experienced JavaScripters should be able to merge improvements without having to request advanced user rights on each wiki.
And what about Lua modules then? A Git repository would probably speed T52329 up.

However, I'm afraid that many users could think of Git being another way to limit their independence.
>>! In T71445#1006055, @Steinsplitter wrote:
>>>>! In T71445#968479, @Ricordisamoa wrote:
>> I often find privacy violations in Common.js in the form of well-intended scripts  (...)
> 
> Then the software should log or prevent such actions (like a abusefilter). 

There's no way to automate code review, especially not of obfuscated code. Same goes for security review, which is as important (and a lot of scripts are lacking here... only yesterday I had to kill a user script because of a CSRF vulnerability that would allow page deletions).
>>>! In T71445#968479, @Ricordisamoa wrote:
> I often find privacy violations in Common.js in the form of well-intended scripts  (...)

Then the software should log or prevent such actions (like a abusefilter). 

And please remember that a lot of script dev's don't like to work with git...
>>! In T71445#968958, @Steinsplitter wrote:
>>>! In T71445#968625, @Krenair wrote:
>> All currently-on-wiki gadgets/scripts need to go through some form of pre-deployment code review. Not just popular ones.
> 
> Can we please establish community consensus before implanting such a code review. This sounds like a huge change.

Huge yes, but if done it'd basically be a CONEXCEPT type of thing as this would be for technical code security and quality reasons.

(Just in case it's not clear, this is with my technical volunteer hat on. My opinion only, etc.)
>>! In T71445#968479, @Ricordisamoa wrote:
> I know this has probably been discussed before

Yes, about a thousand times. Could you volunteer to read the past discussions (linked in task description) and summarise them in the task description, please?
>>! In T71445#968625, @Krenair wrote:
> All currently-on-wiki gadgets/scripts need to go through some form of pre-deployment code review. Not just popular ones.

Can we please establish community consensus before implanting such a code review. This sounds like a huge change.
>>! In T71445#968625, @Krenair wrote:
> All currently-on-wiki gadgets/scripts need to go through some form of pre-deployment code review. Not just popular ones.

Can we please establish community consensus before implanting such a code review. This is a HUGE change.
All currently-on-wiki gadgets/scripts need to go through some form of pre-deployment code review. Not just popular ones.
All currently-on-wiki gadgets/scripts need to go through some fprm of pre-deployment code review. Not just popular ones.
>>! In T71445#968494, @Steinsplitter wrote:
>>>! In T71445#968479, @Ricordisamoa wrote:
>> I know this has probably been discussed before, but... what about hosting gadgets via Git/Phabricator?
>> At least the largest ones will benefit from more thorough review.
> 
> This is something else. Hosting highly popular gadgets like HotCat makes sense imho, :)

But then we wouldn't need any on-wiki "code-review process".
>>! In T71445#968479, @Ricordisamoa wrote:
> I know this has probably been discussed before, but... what about hosting gadgets via Git/Phabricator?
> At least the largest ones will benefit from more thorough review.

This is something else. Hosting highly popular gadgets like HotCat makes sense imho, :)
I know this has probably been discussed before, but... what about hosting gadgets via Git/Phabricator?
At least the largest ones will benefit from more thorough review.
>>! In T71445#968415, @Nemo_bis wrote:
>>>! In T71445#958792, @MZMcBride wrote:
>> the list is in T71445#742344.
> 
> Anything that begins with «To take English wikipedia as an example» is IMHO irrelevant for a bug whose summary is "on Wikimedia sites".

Exactly. For example, on commons are only a few coders who are keeping up scripts (fixing bugs, deprecated code etc.)  Implanting a code review in such a case makes coder unhappy.
>>! In T71445#958792, @MZMcBride wrote:
> the list is in T71445#742344.

Anything that begins with «To take English wikipedia as an example» is IMHO irrelevant for a bug whose summary is "on Wikimedia sites".
>>! In T71445#956103, @Nemo_bis wrote:
> I feel this report is //un cane che si morde la coda//. Unless someone summarises the (relevant parts of the) discussion above and in the linked threads, I propose to close this invalid.

Closing this issue as invalid would probably be the wrong choice as I think the issue is both real and unresolved.

I can't quote Jon's list of action items above (the quote button is disabled for some godforsaken reason), but the list is in T71445#742344.
>>! In T71445#957894, @Aklapper wrote:
> [Please do not add otherwise contentless "+1" comments as they create notifications for everybody. Use tokens or flags instead. Thanks.]

-1
[Please do not add otherwise contentless "+1" comments as they create notifications for everybody. Use tokens or flags instead. Thanks.]
>>! In T71445#956103, @Nemo_bis wrote:
> I feel this report is //un cane che si morde la coda//. Unless someone summarises the (relevant parts of the) discussion above and in the linked threads, I propose to close this invalid.
> 
> We already have separate, actionable reports (and sometimes RfC) for things like JavaScript validation and granularity of sysop permissions.

+1
I feel this report is //un cane che si morde la coda//. Unless someone summarises the (relevant parts of the) discussion above and in the linked threads, I propose to close this invalid.

We already have separate, actionable reports (and sometimes RfC) for things like JavaScript validation and granularity of sysop permissions.
>>! In T71445#742556, @Qgil wrote:
> @eloquence proposed to investigate the idea of Phabricator with a web based interface for editing files, as a possibility to bring easy-as-in-editing-text development closer to proper code review and continuous integration with automated QA.
> 
> We checked upstream, but generally speaking they are not enthusiastic with the idea. See their reasoning at https://secure.phabricator.com/T6008#7
> 
> For different reasons, @Legoktm proposed to go back to the idea of a MediaWiki-based code review...

Now that this task is here, let me add #Code-Review just to make sure that people interested in code review in Phabricator know about this discussion.
I think the effort of bringing all developers under the same roof is worth, and mediawiki.org is the right roof. 

But going back to the definition of the sane code-review process, some ideas came up from a casual email chat. Summary in sequential order:

Erik proposed to investigate the idea of Phabricator with a web based interface for editing files, as a possibility to bring easy-as-in-editing-text development closer to proper code review and continuous integration with automated QA.

We checked upstream, but generally speaking they are not enthusiastic with the idea. See their reasoning at https://secure.phabricator.com/T6008#7

For different reasons, Legoktm proposed to go back to the idea of a MediaWiki-based code review. Let me paste:

"(...) we could just put a revision id in the gadget definition:

"scripts": {"foo.js": 123, "bar.js": 456},
"styles": {"baz.css": 789},

Or something like that. So anyone can edit (maybe still restricted by
a userright or maybe not) the JS/CSS pages, but their changes don't
actually take effect until the gadget definition is updated by someone
with those rights (+2). This allows us to take advantage of wiki
process like be bold, revert, discuss, but still impose a review
requirement by someone with "+2" rights. In some ways it's like SVN."

As Legoktm explain, there is a precedent of this type of process in the workflow for approving EventLogging schemas, where many can edit the schemas but only a few can point to a new version (the +2 equivalent).

https://www.mediawiki.org/wiki/Extension:EventLogging/Guide#Peer_review
(In reply to Quim Gil from comment #30)
> mediawiki.org please. I'm happy to discuss the reasoning wherever
> corresponds.
Ideally both global user scripts and global gadgets should be in the same wiki (but Meta is already in use for the first, so going to another wiki will require migration - which is easy enough: 1. inform users; 2. import any /global.js/css from Meta, with history; 3. delete the old ones from Meta).

Anyway, both Meta and mw.org have Translation extension installed, which will help creating multilingual documentation in a consistent way for popular gadgets.
(In reply to Helder from comment #29)
> using a single common wiki would be the best - whatever wiki is choosen -

mediawiki.org please. I'm happy to discuss the reasoning wherever corresponds.
What about creating the "Gadget developer" user group on WMF wikis, with the user rights which are currently given to sysops (edituserjs, editusercss and editinterface - which gerrit change 154452 splits into 'editsitejs' and 'editsitecss') and, later, also the user rights introduced by Gadgets 2.0 (see the links mentioned on comment 17).

Then, send an announcement recommending communities to evaluate whose of their sysops should indeed have the permissions to edit JavaScript and CSS and add them to the new user group, and after a reasonable amount of time, remove the user rights from sysops on WMF wikis.

Also, since it is recommended to keep gadgets central[1], and since now Meta-wiki is the central wiki used by extension GlobalCssJs, maybe apply any code-review process first to the editing of global gadgets hosted on Meta (some are currently hosted on mw.org or enwiki, or wikidata, but using a single common wiki would be the best - whatever wiki is choosen - and would help in the implementation of the Gadgets 2.0 when that is ready for deployment in the future).

[1] https://www.mediawiki.org/wiki/ResourceLoader/Migration_guide_%28users%29#Keep_gadgets_central
(In reply to Yann Forget from comment #27)
> Why not do it as page correction and validation in Wikisource? It is a light
> process, and there is no need to learn a new tool.
> 
> With the Proofreading page extension, 2 non-anonymous users are needed to
> validate a page. Additionally, more right could be needed (either sysop or
> autopatrolled).

This sounds good to me. +1
Why not do it as page correction and validation in Wikisource? It is a light process, and there is no need to learn a new tool.

With the Proofreading page extension, 2 non-anonymous users are needed to validate a page. Additionally, more right could be needed (either sysop or autopatrolled).
Depends on bug 20153?
(In reply to Stefan2 from comment #16)
> I think that the problem is that the MediaWiki namespace can be edited by
> any administrator. Many administrators do not understand what the code does,
> as demonstrated for example by the "~~~~" in
> [[szl:Special:PermanentLink/207947]], which Legoktm mentioned above. A
> simple solution would be to remove the right to edit pages in the MediaWiki
> namespace from administrators and instead assign it to a new group,
> "scripteditors", consisting of editors who understand how the code works.
> 

> Broadly, administrators are trusted users and should be treated as such.

Yes but whereas I might trust a fellow developer, I still wouldn't at all me comfortable if they +2ed their own code and this is why we have code review processes. Also I might trust an administrator in wiki things but if they are unable to use a code review tool then I wouldn't trust them to edit JavaScript. I worry that a lot of this is due to an outdated idea that JavaScript is not a real language. Ask yourself what if MediaWiki:Common.php existed and how allowing editing of code on a wiki that would make you feel...

I can imagine Common.js being useful for a hobby wiki to make a few tweaks, but it really has no place on a Wikimedia wiki and we should certainly not be building code review systems to support it. Instead we should be focusing energy on making code review in mediawiki core quicker and more enticing and more regularly deploying our code.
(In reply to MZMcBride from comment #19)
> In other words, if you all want to deprecate the use of MediaWiki:Common.js
> and similar pages, you should work toward that goal. If/when the day comes
> that they're no longer needed, then we can consider getting rid of them. But
> this bug seems to be a bit "cart before the horse."

Agreed, and if anyone wants to write patches that make our software more useful I will happily help merge them. Have raised bug 69550 so as not to derail this bug anymore. :)
(In reply to MZMcBride from comment #19)
> Err, most of the MediaWiki namespace isn't JavaScript and CSS, it's
> interface messages. The fact that JS and CSS pages are included in the
> MediaWiki namespace has always been a design quirk that should probably be
> corrected as their inclusion in the namespace is a(n) (ab|mis)use of the
> namespace's purpose.

Well yes, but there are some messages that are also a big issue. See also bug 43646
(In reply to C. Scott Ananian from comment #8)
> I think that extensions and gadgets are probably the "right" way to make
> sitewide changes.  Extensions already have a code review/deployment process,
> although we can certainly work to make that smoother/easier.  Perhaps enwiki
> could have an 'Extension:enwiki', for example, which could contain any code
> which would otherwise live in common.js.

I was thinking a bit more generic, but yeah, this might be a good idea to pursue. My thought was that you might have Extension:WikimediaScripts, which follows the pattern of E:WikimediaMaintenance and E:WikimediaMessages and E:WikimediaEvents. Inside the WikimediaScripts extension, you'd have modules that could then be loaded on a per-wiki basis.

> common.js is just a weird special case that doesn't need to exist.

I addressed this line of reasoning in comment 19, last paragraph. For now, there's a definite need for these pages to exist. That may not be true in the future, but it is true today.
(In reply to Brad Jorsch from comment #9)
> (In reply to MZMcBride from comment #6)
>> Code is the enemy; less code is better. Rather than looking at ways to
>> impose code review on wiki communities, we should first look for ways to
>> centralize code (global gadgets) and we should look for ways to make the
>> current site-wide JavaScript hacks no longer necessary.
> 
> While having more code in gadgets rather than in common.js is good, it's
> orthogonal to the need for a good code review process that's actually usable
> by wiki users. The global gadgets will still need a code review process.

It would be helpful if you could explicitly specify what needs you see that you feel MediaWiki could handle well and/or that you think Phabricator could not handle well.

> Wiki users might accept having to go to a Commons-like site instead of doing
> it on their local wiki (and in the long run they'll probably have to), but
> they're unlikely to accept something that requires they install software
> locally, sign up for a non-SUL account, figure out ssh keys, publish an
> email address publicly, and so on.

GitHub and GitLab both allow in-browser editing now, I believe. I imagine Phabricator, which will allegedly be part of Wikimedia unified login, will also have equivalent functionality. The e-mail address is trivially solvable in Git by simply making up an e-mail address (User:Anomie@git-en.wikipedia.org), I think? And if you're using a Web browser and single unified login for authentication, you probably don't need to worry about SSH keys or installing software such as Git locally.

You may be correct that there's a need here for global gadgets, but I think we need to do more to be much clearer about what that need is and how we propose to address it, assuming additional development—outside of the ongoing Phabricator work and I suppose the work to deprecate Common.js and similar pages—is needed.
(In reply to Gilles Dubuc from comment #7)
> The fact that people who aren't developers and/or who don't understand what
> custom JS they're deploying to millions of users is the problem.

You're basically hitting [[hard cases make bad law]] here. Most Wikimedia wikis (probably over 800 of them) do not have millions of users.

> If you're not willing to learn git, you're not the right person to be
> pushing custom JS to a top-5 website.

Can we please collectively stop with the "top-5" bullshit? :-)  Obviously the English Wikipedia and other wikis are a consideration, but over 99% of MediaWiki wikis are not top-5 anything.
(In reply to Stefan2 from comment #16)
> I think that the problem is that the MediaWiki namespace can be edited by
> any administrator. Many administrators do not understand what the code does,
> as demonstrated for example by the "~~~~" in
> [[szl:Special:PermanentLink/207947]], which Legoktm mentioned above. A
> simple solution would be to remove the right to edit pages in the MediaWiki
> namespace from administrators and instead assign it to a new group,
> "scripteditors", consisting of editors who understand how the code works.

Err, most of the MediaWiki namespace isn't JavaScript and CSS, it's interface messages. The fact that JS and CSS pages are included in the MediaWiki namespace has always been a design quirk that should probably be corrected as their inclusion in the namespace is a(n) (ab|mis)use of the namespace's purpose.

Broadly, administrators are trusted users and should be treated as such.

Whether the rest of the MediaWiki namespace is needed is also debatable nowadays, but probably also outside the scope of this ticket.

> I think that some code should be removed from Common.js files and moved to
> MediaWiki core instead. For example, [[sv:MediaWiki:Common.js]] contains
> code fixing incorrect sorting of text in tables (search for
> "tableSorterCollation"). Every user of MediaWiki would want text to be
> sorted correctly, so I don't see why this couldn't be in MediaWiki core
> instead.

Yes, for sure. I made a similar comment above (comment 6). We should figure out why these pages are still needed and work to address that by putting the functionality in MediaWiki core or in an extension. I think this is a better use of time than proposing trashing the functionality.

In other words, if you all want to deprecate the use of MediaWiki:Common.js and similar pages, you should work toward that goal. If/when the day comes that they're no longer needed, then we can consider getting rid of them. But this bug seems to be a bit "cart before the horse."
(In reply to Eran Roz from comment #13 and comment #14)
> I just runned a simple phantomjs script on all wikipedia languages to catch
> simple errors:
> 
> [...]

Thanks for this. I split this out to bug 69519.
Gadgets 2.0 (T31272) introduces new user rights specific for edit/management of gadgets:
https://www.mediawiki.org/wiki/ResourceLoader/Version_2_Design_Specification#User_rights
See also this discussion about which users (user groups) should have each permission:
https://www.mediawiki.org/wiki/Thread:Talk:ResourceLoader/V2_testing/Questions_about_permission_model_and_developer_workflow
Gadgets 2.0 introduces new user rights specific for edit/management of gadgets:
https://www.mediawiki.org/wiki/ResourceLoader/Version_2_Design_Specification#User_rights
See also this discussion about which users (user groups) should have each permission:
https://www.mediawiki.org/wiki/Thread:Talk:ResourceLoader/V2_testing/Questions_about_permission_model_and_developer_workflow
I think that the problem is that the MediaWiki namespace can be edited by any administrator. Many administrators do not understand what the code does, as demonstrated for example by the "~~~~" in [[szl:Special:PermanentLink/207947]], which Legoktm mentioned above. A simple solution would be to remove the right to edit pages in the MediaWiki namespace from administrators and instead assign it to a new group, "scripteditors", consisting of editors who understand how the code works.

I think that some code should be removed from Common.js files and moved to MediaWiki core instead. For example, [[sv:MediaWiki:Common.js]] contains code fixing incorrect sorting of text in tables (search for "tableSorterCollation"). Every user of MediaWiki would want text to be sorted correctly, so I don't see why this couldn't be in MediaWiki core instead.
Eran Roz: please fill bug report for all such issues. This way they can be triaged / assigned to the proper persons and will be easier to track than this bug which is merely for discussion.
Created attachment 16185
Example for errors across wikis

Maybe it is a bit off-topic but here are some cases of errors across wikis in simple read/edit transaction using phantomJS

**Attached**: {F14648}
I think code review isn't the solution, as it is probable that no one will review the code for small wikis. 
However it would be great to have automated tests running after changes in common.js and gadgets. Such general tests can at least validate no external resource is loaded, or no invalid syntax is added.
The simplest option is to run it outside MW (such as a script in labs that runs X times a day), but an extension to do it while editing would be even better...

BTW
I just runned a simple phantomjs script on all wikipedia languages to catch simple errors:

testing als
ERROR: ReferenceError: Can't find variable: ta
TRACE:
 -> https://als.wikipedia.org/w/index.php?title=MediaWiki:If-pt-login.js&action=raw&ctype=text/javascript&dontcountme=s: 9

testing kk
ERROR: TypeError: 'null' is not an object (evaluating 'document.getElementById('mw-vector-current-variant').innerHTML=wgULS("Кирил","Latın","توتە")')
TRACE:
 -> https://bits.wikimedia.org/kk.wikipedia.org/load.php?debug=false&lang=kk&modules=site&only=scripts&skin=vector&*: 9


anyone wants to fix them? :)
(In reply to Brad Jorsch from comment #9)
> ...
> they're unlikely to accept something that requires they install software
> locally, sign up for a non-SUL account, figure out ssh keys, publish an
> ...
FYI: we might have SUL for Phabricator:
http://fab.wmflabs.org/T314
Notice that many wikis have migrated code from Common.js to default gadgets (e.g. for modularization, to allow users to disable functionality, to make debugging easier, to allow importing specific parts from other wikis, etc), and others also load subpages like Common.js/edit.js, Common.js/watchlist.js, Common.js/IEFixes.js, etc..

Wikimedia Commons for example has 17 gadgets enabled for everyone by default. See more stats on
https://meta.wikimedia.org/wiki/Gadgets
(In reply to Gilles Dubuc from comment #7)
> The fact that people who aren't developers and/or who don't understand what
> custom JS they're deploying to millions of users is the problem. It's not a
> situation that needs to be perpetuated through dumbed-down on-wiki code
> review.

I've heard that same argument as to why wikitext is better than VisualEditor. I didn't agree then, and I don't agree now: making the process technically difficult to try to discourage "unqualified" contributors isn't a very well-targeted heuristic. Even if the people affected are smart enough to be able to figure out the process, they may well decide the effort isn't worth it.


(In reply to MZMcBride from comment #6)
> Code is the enemy; less code is better. Rather than looking at ways to
> impose code review on wiki communities, we should first look for ways to
> centralize code (global gadgets) and we should look for ways to make the
> current site-wide JavaScript hacks no longer necessary.

While having more code in gadgets rather than in common.js is good, it's orthogonal to the need for a good code review process that's actually usable by wiki users. The global gadgets will still need a code review process.

Wiki users might accept having to go to a Commons-like site instead of doing it on their local wiki (and in the long run they'll probably have to), but they're unlikely to accept something that requires they install software locally, sign up for a non-SUL account, figure out ssh keys, publish an email address publicly, and so on.

FlaggedRevs isn't a good model, because we need merging of proposed changes rather than a linear history. I don't know whether CodeReview will do pre-commit review, which is probably a necessity.
I think that extensions and gadgets are probably the "right" way to make sitewide changes.  Extensions already have a code review/deployment process, although we can certainly work to make that smoother/easier.  Perhaps enwiki could have an 'Extension:enwiki', for example, which could contain any code which would otherwise live in common.js.  On github, at least, proposing a new change would be as easy as going to the 'common.js' file inside the Extension:enwiki respository and clicking 'edit', which takes care of forking, branching, commiting, and submitting a pull-request.

Gadgets don't really have a good review mechanism at the moment.  I think this bug could concentrate on reviews for gadgets;  common.js is just a weird special case that doesn't need to exist.
The fact that people who aren't developers and/or who don't understand what custom JS they're deploying to millions of users is the problem. It's not a situation that needs to be perpetuated through dumbed-down on-wiki code review. Like MZ just described, if there's a way to remove the bulk of the need for these users to deploy custom JS, it should be explored first.

And for whatever JS is left that can't be standardized into a global gadget repository (I haven't looked at the code, but I imagine there will always be "that specific thing that can't be done differently"), community members with appropriate skills should be doing it. If you're not willing to learn git, you're not the right person to be pushing custom JS to a top-5 website. Even if you don't want to learn or don't have time to, it just means that you need to enlist the help of someone who knows about this stuff. Right now that step doesn't exist and irresponsible actions are being taken by people who are just unaware of what they're doing.

I think that a "simple mode" review tool is also likely to make the uneducated people sending JS they don't understand less likely to learn to master what they're doing. As such it wouldn't be code review, it would be "please make this thing I don't understand work and deploy it", which puts all the workload burden on the reviewer, instead of being the 2-way street code review should be.
I'm not sure this problem is being approached in the best way. I think it would be helpful to look at use-cases and work backward from there. Why are administrators adding custom site-wide JavaScript?

Looking through [[MediaWiki:Common.js]], for example, it seems as though a lot of code is deprecated and could be removed once de-referenced. The non-deprecated code should probably exist in MediaWiki core or in a MediaWiki extension, if it's generally useful functionality.

Code is the enemy; less code is better. Rather than looking at ways to impose code review on wiki communities, we should first look for ways to centralize code (global gadgets) and we should look for ways to make the current site-wide JavaScript hacks no longer necessary.

(In reply to Zell Faze from comment #4)
> I think the community would likely reject attempts to use git or gerrit. 
> Whatever this system is, it will need to be implemented within Mediawiki. 
> People have a hard enough time leaving their home wiki, I seriously doubt
> that most sysops are going to download and learn to use git.

A smart front-end could mask that the user is using Git. I'm thinking about an interface similar to in-browser editing in the GitHub front-end. But again, I'd like us to more closely look at the underlying use-cases first.
Indeed. This definitely must be implemented "inside" MediaWiki (whatever the backend we use, the UI must be displayed within regular MediaWiki pages) if it is supposed to be used by MediaWiki users and not MediaWiki developers.
I think the community would likely reject attempts to use git or gerrit.  Whatever this system is, it will need to be implemented within Mediawiki.  People have a hard enough time leaving their home wiki, I seriously doubt that most sysops are going to download and learn to use git.

Though Flaggedrevs is weird, I personally think that it, or something like it, is the way to go.  The learning curve of it is less than that of git and gerrit, and I'm sure some sort of bridge could be made that would allow running of tests on code submitted there.

I feel like any system outside of Mediawiki would stifle each communities autonomy, something that in recent weeks we've seen they care an awful lot about.
Why can't we just do this the same way as our current status quo (gerrit) or the soon-to-be status quo (phabricator)? Less systems that do the same thing to maintain...

Some volunteers have +2 on our projects, this is the same situation except that we need to find more volunteer reviewers than usual, because we don't have the bandwidth to review this at the moment.

IMHO if the code review process we normally undergo feels heavy to impose on this audience, it just needs that we need to improve the process. If it becomes easier to outsiders, it benefits all projects.
Would it make sense to use git / phabricator ?   We will have to convince the community that a pre commit review workflow is a good thing, but that would let us run validation tests and deploy on some staging area before rolling changes to production.

I am very skeptical at our ability to code and maintain a review system in MediaWiki, we have past experiences:

- CodeReview extension for svn could have been nice if we had the ability to devote time to it, it turned out to be simpler to delegate the software to third party (Gerrit, soon Phabricator). 

- FlaggedRevs which would let one validate revisions before they were made public. I don't think anyone regret it. I found the workflow / UI etc terrible and never understood how it worked.


Also, we could use such a review system for Gadgets and LUA modules.  When writing, versionning and collaborating on code, ones need a version control system. git comes to mind.
This would need to be done differently from how FlaggedRevisions currently is implemented (as in FR you still submit a new version which is directly being used by eg. ResourceLoader).

I would suggest to have a new extension in which edits can basically be suggested like github pull requests and then get merged/ commented on/ rejected by a reviewer.

Mid to long term this process should be centralized and managing JS/CSS should move away from the Wikis into a central place (that can be a MediaWiki, but IMO doesn't necessarily have to be one).
Intention:
Attempting to replace a formula with text by selecting the formula does not work.  Simply nothing happens.  Either typing or pasting has the same null effect.  Attempting to replace a formula by inserting a template results in the template being inserted after the formula, not instead of it.




Reproducible: Always

--------------------------
**Version**: unspecified
**Severity**: enhancement
(In reply to Spinningspark from comment #0)
> Intention:
> Attempting to replace a formula with text by selecting the formula does not
> work.  Simply nothing happens.  Either typing or pasting has the same null
> effect.  Attempting to replace a formula by inserting a template results in
> the template being inserted after the formula, not instead of it.

Yes, this is intentional. We could reconsider it but I worry that the additional slowness to support certain broken browsers in this respect (I believe the main issue here is Firefox) is not worth the minor user experience improvement.

Note that the "delete" and "backspace" keys still work to delete the selection.
The "Wrap text around this item" checkbox appears above the the alignment buttons and looks like a label for these buttons. The button group doesn't have a label of itself. It should be moved around somehow so the separation between them will be clear.

--------------------------
**Version**: unspecified
**Severity**: minor
Change 152054 abandoned by Amire80:
Move the wrapping checkbox under the alignment buttons

https://gerrit.wikimedia.org/r/152054
Change 152054 had a related patch set uploaded by Amire80:
Move the wrapping checkbox under the alignment buttons

https://gerrit.wikimedia.org/r/152054
... Also, it's on by default, so that's another reason not to put it on the top.
Let's rename our global namespace to something longer than 2 characters and not identified by lowercase characters.

Proposing VisualEditor instead of 've'.

--------------------------
**Version**: unspecified
**Severity**: enhancement
1. '[[' to a paragraph and dismiss the wikitext warning
2. type in another paragraph then re-focus the [[ paragraph and type
3. the wikitext warning returns

--------------------------
**Version**: unspecified
**Severity**: enhancement
Displaying it once per session...? Per James, this is a wontfix I think.
Not sure that this is not a WONTFIX. We don't really want it to be lost on users that they're Doing It Wrong™. :-)
--------------------------
**Version**: unspecified
**Severity**: enhancement
or it could be a spot in the resize steps which replaces the "XXX x XXX" with "Default size" There are any number of options.
(In reply to Jared Zimmerman (WMF) from comment #1)
> updated the title to not jump to the conclusion of how this should be done,
> not sure if a button is the right answer,

An "action button" is the "set … without invoking image settings dialog" UX concept in VE…
updated the title to not jump to the conclusion of how this should be done, not sure if a button is the right answer,
When editing, "default size" in mw prefs is not honored.
http://en.wikipedia.beta.wmflabs.org/wiki/Thumbnail_size2 / http://en.wikipedia.beta.wmflabs.org/api/rest_v1/page/html/Thumbnail_size2
This really looks like it would be a simple fix. Parsoid sets `class="mw-default-size"` on the `<figure>` elements if no explicit size was given, and VE already knows user's preferred thumbnail size.
This issue has been pointed on fr.wp too.
With the given example I see the image 1.66 bigger while reading than while editing.
I'd like to revisit this, the current behavior is actively against the WYSIWYG model established in VE. I'm still not understanding the argument against this. If images are the same size both in read and edit mode, how will this contribute to editors wanted to resize them to "look right for them" if they already look correct? if anything this seems like it would lessen the desire to fiddle with image sizes.
I think I might be being unclear with the request…


As a user who sets my thumbnail preference to (120/180/220/250/300/etc)px while in visual editor I see "default sized" thumbnails display as (120/180/220/250/300/etc)px depending on my preference. 

I'm not sure I understand your point "we actively don't want people resizing images to look "right" for them, which this would encourage." which is the exact opposite of what this would do, if the images LOOK right when i get to VE then I'm much less likely to go on a resizing spree.
(In reply to Jared Zimmerman (WMF) from comment #2)
> I think i might have been unclear on this one. 
> 
> The gist is "Image should not change size when going from read to edit"
> 
> there are many possible fixes, but the one that seemed simplest was, for
> images which are at "default" size, look at users preference for what size
> "default" is and display them at that size when in edit mode.

And as I said, we have intentionally chosen not to do this.

> there might be other options, but the bug is that they change, size at all.

The simplest "fix" to this issue is to remove the user preference. But you probably don't want that.
I think i might have been unclear on this one. 

The gist is "Image should not change size when going from read to edit"

there are many possible fixes, but the one that seemed simplest was, for images which are at "default" size, look at users preference for what size "default" is and display them at that size when in edit mode.

there might be other options, but the bug is that they change, size at all.
This is verging on a WONTFIX; we actively don't want people resizing images to look "right" for them, which this would encourage.
The solution for this may be related to Bug 61049:

If you add a caption to an image, and you press return in the text area box at the end (perhaps several times), then the caption includes those pointless blank lines, which makes for ugly wikitext when the page is saved.

See https://en.wikipedia.org/w/index.php?title=Sugar_candy&diff=613063549&oldid=611921250

--------------------------
**Version**: unspecified
**Severity**: enhancement
I got bit by this bug again:  https://ca.wikipedia.org/w/index.php?title=Cloïssa_gegant&diff=prev&oldid=17846863 

Ed, does this really need a general solution?  I'd be happy to limit it to just text that's entered into a dialog.
The same is true for the main document, but I'd rather issue warnings than do automatic document modification (cf. typing wikitext into VE)
Go to this page:

https://test2.wikipedia.org/w/index.php?title=User:RYasmeen_(WMF)/sandbox&oldid=87309

Change the first image from Thumbnail to Basic and click on "Apply Changes"
The following error appears in the console and cannot save page or cancel editing the page with VE.
 

Uncaught Error: Offset could not be translated to a DOM element and offset: 55

--------------------------
**Version**: unspecified
**Severity**: normal
Now if I follow the minimal wikitext or the steps to reproduce in a page and try to change the first image from thumbnail to Basic, it moves the image inside the caption of the second image.

Is that how we want it now?
Change 144136 merged by jenkins-bot:
Fixes to getRelativeOffset and getRelativeRange

https://gerrit.wikimedia.org/r/144136
Change 144136 had a related patch set uploaded by Esanders:
Fixes to getRelativeOffset and getRelativeRange

https://gerrit.wikimedia.org/r/144136
Change 144004 merged by jenkins-bot:
Skip over nested handlesOwnChildren nodes in getRelativeOffset

https://gerrit.wikimedia.org/r/144004
Change 144004 had a related patch set uploaded by Esanders:
Skip over nested handlesOwnChildren nodes in getRelativeOffset

https://gerrit.wikimedia.org/r/144004
first case works perfectly in master
second case still results in the image being deleted
On test 2 wiki:
the first case still throws an exception
the second 'minimal' case results in the image being deleted
Marking as theoretically fixed, then. :-)
I... can no longer reproduce this. I tried the steps in comment 3 as well as the wiki page in comment 2. Maybe this got fixed by Ed's selection-after-deletion fix? Because when we change an image from block to inline, we delete the old image and insert a new one.
Found the steps to reproduce it from VE :D

1.Open a page with VE
2.Insert an image, keep it thumbnail-right
3.Go to next line of the added image by pressing enter
4.Add another image on the next line, make it frameless right
5.Now in the caption of the second image : Add another image and go to the next line of this image by pressing enter
6.Add anything on the next line of the caption
7.Apply changes
8.Save Page
7.Reopen the page
8.Try to make the first image Thumbnail to Basic

Observed Result:

Uncaught Error: Offset could not be translated to a DOM element and offset: 55
appears in the console and cannot cancel the edit or save the page in VE
This is the minimum wikitext required to reproduce this issue:
[[File:MO-supp-K.svg|thumb]]
[[File:IMA-johnson1.jpg|right|frameless|

[[File:S.M.R.JPG|thumb]]
{{Cite web|url = http://yahoo.com|title = }}

]]

You can try on this page:
https://test2.wikipedia.org/wiki/Test66604?veaction=edit
The problem seems to be in ve.ce.Document.prototype.getNodeAndOffset() where the stack ends up empty but the element is not a slug.

I am pretty certain this happens due to the image with the complex caption that includes {{Cite}} <math> <ref> and another image inside it. My attempts to sanitize the wikitext and try everything one-by-one failed when I added that piece: 


[[File:MO-supp-K.svg|thumb]]
[[File:MO-supp-K.svg|thumb]]
[[File:IMA-johnson1.jpg|right|frameless|caption
<ref>{{Cite web|url = http://yahoo.com|title = }}</ref>

<ref>reference</ref>{{Citation needed}}

<math>\pi</math>
[[File:S.M.R.JPG|thumb]]

{{Cite web|url = http://yahoo.com|title = }}

]]
(Now tracked as part of #VisualEditor-EditingTools.)

More keyboard shortcuts help users.

--------------------------
**Version**: unspecified
**Severity**: enhancement
[adding the #tracking project to tasks blocking (now deprecated) T4007 as part of T93366]
--------------------------
**Version**: unspecified
**Severity**: enhancement
A <br /> could be inserted when the user uses Shift + Enter (line break instead of change of paragraph).
This would be consistent with word processor software.
Where do we draw the line about being paternalistic and disallowing users to do things they want to do but we don't think are "good code" or "stylistically wrong" it seems like in many cases we go to great lengths to make things possible or easy even if we think the outcome may be that users misuse or use in unexpected ways and other times we block on them by saying we don't want to be enablers of bad behavior. Curious in this case how that logic is applied to do, or not do this?
(In reply to Jared Zimmerman (WMF) from comment #7)
> Two possible proposals that we could use one, both, or some variations
> 
> When consecutive breaks are found we could use
> 
> <br>
> <br>
> 
> which is what you'll commonly see on wikipages when people are trying to do
> some advanced formatting

… and is horrendous and explicitly deprecated.

> if the <br> is followed by a [[template]] or == Section == we could strip
> out any <br> and replace with {{Clear}}

This is verging on a WONTFIX, but leaving as a possible thing for later consideration.
Two possible proposals that we could use one, both, or some variations

When consecutive breaks are found we could use

<br>
<br>

which is what you'll commonly see on wikipages when people are trying to do some advanced formatting

if the <br> is followed by a [[template]] or == Section == we could strip out any <br> and replace with {{Clear}}
Closing temporarily as there's no proposed action. Please feel free to re-open.
Unfortunately MediaWiki has no representation of a blank paragraph, so they get destroyed when you save.

We could theoretically not let you insert a second new line (so "enter" in a blank paragraph does nothing), and though this is an extant UX in the wild – LyX does this because LaTeX has the same limitation – I think it's pretty crummy, and probably worse than the current behaviour.

What would you expect to happen?
Created attachment 15503
post-save

**Attached**: {F13877}
Created attachment 15502
pre-save

**Attached**: {F13876}
go to https://en.wikipedia.org/wiki/User:Jaredzimmerman_%28WMF%29/VEtest

1. place cursor after "line 1"
2. press enter/return on keyboard twice
3. save page

expected : there will be two blank lines after "line 1"
actual: there are no blank lines after "line 1"

see attached images for pre and post save appearance.
Please provide steps to reproduce - no idea at which stage/keyboard focus I press some key on my keyboard, and which browsers this was tested with

Please see https://www.mediawiki.org/wiki/How_to_report_a_bug
In the page options menu, you can add a category by typing its name in the "add a category" box and delete a category by clicking the the trash icon in the category inspector. However it's not currently possible to **edit** the name of the category.

For example, if the page is currently in [[Category:Admirals of World War I]] and I want to put it in [[Category:Admirals of World War II]], I can do that easily in the wikitext editor by simply typing an extra "I".  In VisualEditor, I have to completely delete the first category and then add the second from scratch.
{F4221948}

Being able to edit this would make a big difference for UX. Right now it's border-line inaccessible to make the intended change.

Additionally, the label is not selectable by cursor. The category object is shielded from text selection for some reason, requiring the user to retype it from scratch. This gets worse with T139189.
(In reply to Amir E. Aharoni from comment #1)
> Just noticed that the User guide[1] says: "On the Page options menu there
> are options [...] to add, edit, or delete categories."
> 
> I'd say that actual "editing" must involve the resolution of this bug, and
> otherwise it is just adding and deleting.
> 
> [1] https://www.mediawiki.org/wiki/Help:VisualEditor/User_guide

You can edit each category to add, change or remove the sort key for the page for that category.
Just noticed that the User guide[1] says: "On the Page options menu there are options [...] to add, edit, or delete categories."

I'd say that actual "editing" must involve the resolution of this bug, and otherwise it is just adding and deleting.

[1] https://www.mediawiki.org/wiki/Help:VisualEditor/User_guide
Steps to Reproduce:
1. Start with a page that contains:

(a) a template with a named ref inside it:  {{quote|Text.<ref name=Foo>Example citation</ref>}}

(b) Some text outside the template that re-uses that citation:  Text.<ref name=Foo />

2. Open the page in VisualEditor and remove the template.



Actual Results:  
The named ref becomes undefined.  VisualEditor doesn't "see" the citation inside the template, so it can't rescue the re-used template-based citation content when the template is deleted.

Expected Results:  
That the citation content would be preserved, just like it is preseved when the first instance of a re-used citation in regular page text (outside of templates) is removed.

Reproducible: Always

--------------------------
**Version**: unspecified
**Severity**: enhancement
Also, if the only refs are hidden in templates, then when you add a <references /> block, you get the error mesage that "There are no references on this page to include in this list."
**Author:** `admin`

**Description:**
Greetings,
Please enable the Translate and any related extensions to the affcom wiki (chapcom.wikimedia.org) to help us with drafting English based text that will later be utilized on Meta-Wiki. I recognize that actually marking the pages for translation could be problematic - the goal is primarily to utilize tags without making the wikipages difficult to proofread and edit.

Thank you!
-greg aka varnent
AffCom Member

--------------------------
**Version**: wmf-deployment
**Severity**: enhancement
> we can guess it was just a personal request

If so I'd consider it invalid rather than declined. There's never a good reason to decline enabling Translate if people want to use it.
I'm going to be bold here and close this task as declined. The requestor is no longer with AffCom, and we don't really know if the people there still wants this or not. No further tickets were filled asking for this feature, so we can guess it was just a personal request from Greg based on a need there back in the days. I've abandoned the gerrit change for this. Please reopen if you disagree. Thank you.
Change 275289 abandoned by MarcoAurelio:
Enable Translate extension on AffCom (chapcomwiki)

Reason:
Per task. Requestor is no longer with AffCom and no apparent renewed interest in this feature.

[[https://gerrit.wikimedia.org/r/275289]]
You can help being present at one of our SWAT windows, for example this night at 23:00 UTC.
You can help being present at one of our SWAT windows, for example this night at 00:00 UTC
@Dereckson - I am no longer connected to AffCom having joined WMF as a contractor. However, I still have access to their wiki, and am still in touch with their members and staff liaison (Jaime Anstee). As such, I am happy to help with this ticket in whatever ways would be helpful and logical.
@Varnent I discussed again last week the issue with Marco Aurelio, whom isn't really comfortable to process this change.

Would you be available during a SWAT window to help to test this change?
Well in such case, there is not a lot we can do for fishbowls.

So, you can see it deployed during a SWAT window with two strategies.

The first would be to ensure you have someone with access to test that at the moment the change is merged.

The second is a minimal check, then an async broader check:

# check the wiki homepage it's not broken with a fatal exception and all looks good as far as you can tell
# state during deployment it's not further testable as fishbowl
# leave the task open, move it in the Done column
# report here the change is deployed, and ask original task author (here @Varnent) to ensure all is fine
# You or @varnent can close it as resolved if it's actually fine. If not, you submit a fix or a revert change
Please do not assign this to me as I don't have access to the chapcom wiki, thus I won't be able to test if the change works when deployed. Thank you.
I missed the config rights mentioned above by @Nemo_bis, will try to do in PS2.
@Varnent @Nikerabbit Will https://gerrit.wikimedia.org/r/275289 achieve what's desired here?
Change 275289 had a related patch set uploaded (by MarcoAurelio):
Enabling Translation extension on AffCom (chapcomwiki)

[[https://gerrit.wikimedia.org/r/275289]]
Not stalled AFAICT.
Any progress, or has this stalled?
Well in that case it's pretty straightforward, just need to explicitly disable all Translate features when enabling.
Responses:

  - We just want to be able to setup <translate> tags while docs are being prepared to help make transitioning to Meta easier.
  - Most translations would not be happening on the wiki, so we are not concerned about export/import. If translate is used, it will be for things like email messages that are template and housed on AffCom wiki permanently.
  - Given that there are only a dozen active users, I am not too concerned about accidental markings.
  - The members who code our pages are familiar with translate extension - I do not anticipate needing additional support.
  - We do not use VisualEditor much, if at all, although a few members do - we do not anticipate that being a problem given the small percentage of draft pages we are talking about.

If this is too much of a hassle, that's fine, we'll continue to work without. However, it was something we felt would make prep work for draft wikipages going to Meta easier.
In addition to above:
* translation memory and other web services should be disabled
* <translate> tags do not currently work well with visual editor (in case you use it)
* related database tables must be created when Translate is enabled on a new wiki
So you want Translate without actually marking pages for translation? If so, what checks are you interested in?
* If you only want to check balanced translate tags and so on, the solution would be to enable Translate while revoking the pagetranslation right from all groups.
* If you need Special:PageTranslation for your checks/preparations, how do you plan to avoid accidental marking?
* If you want to actually mark the pages for translation and have them translated in private before publishing, do you already have a plan for export-import of translations?
* In any case, do you have users on the wiki who are comfortable using the Translate extension and have enough time to train and assist all the other users, so that you are self-sufficient?
Niklas, can this be done? I know almost nothing about that extension.
When you add text on the left side of a link (external, internal) in article core the content is not merge with the link. T55210 asks to change this.

When you add text on the left side of a link (external, internal) in the reference assistant the content is merge with the link. Someone asks to change this on https://fr.wikipedia.org/w/index.php?title=Wikipédia:ÉditeurVisuel/Avis&oldid=102556548#Gestion_des_liens

A solution might be : On clicking a link, show 2 sliders (left/right of the current link) to handle easily  what is In what is Out of the link

--------------------------
**Version**: unspecified
**Severity**: enhancement
These feels very confusing as a use paradigm; boxes suddenly flying out for links (just links? not bold/italics?) seems like it will get in the way of seeing what the existing content has. Marking as "lowest" priority and re-wording to be more general.
Right now if , a user inserts wikitext inside gallery inspector such as <gallery></gallery> or <ref> inside gallery inserter, it adds an empty gallery inside the page and if you switch to edit source you will see something like:
<gallery><gallery><ref></ref></gallery></gallery>


One possible solution to this issue could be let user know not to add any such wikitext/bad inputs inside gallery inspector

Test Environment: http://en.wikipedia.beta.wmflabs.org/
Browser: Chrome Version 26.0.1410.65 & FF 25
OS: MAC OS X 10. 8. 5

--------------------------
**Version**: unspecified
**Severity**: minor
Created attachment 14853
Screenshot

**Attached**: {F13152}
Moved out of bug 38129's wishlist into its own bug.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Moved out of bug 38129's wishlist into its own bug.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Moved out of bug 38129's wishlist into its own bug.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Moved out of bug 38129's wishlist into its own bug.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Moved out of bug 38129's wishlist into its own bug.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Until we have a data store to expose the generated files ( {T101545} ). There is not much we can do on this task.
Lowering priority from high to normal since nobody is apparently actively pushing for this change.  Whenever the feature teams figure out a good utility / way to do such visual differences we can work on integrating it on Jenkins/Zuul.
See https://github.com/subbuss/parsoid_visual_diffs for a version that is being used to compare Parsoid and PHP parser HTML output. That works quite well and has already exposed a few css issues and other non-css rendering/html diffs.

Something similar could perhaps be adapted for this purpose as well?
Mentionned by Subbu on IRC: an example of what visual diffs can bring to us http://diplograph.net/posts/visual_diffs
**jgonera** wrote:

See also: https://gerrit.wikimedia.org/r/#/c/126878/
See also: https://github.com/facebook/huxley
I assume that it's easier to roll our own than to re-use wraith or something similar, due to trying to integrate it into jenkins? Multi-platform screenshot regression testing is probably a secondary-level target, but…
The job would be non-voting of course, and we'd change the jenkins-bot comment to Gerrit to CHANGED/UNCHANGED instead of SUCCESS/FAILURE.
Some MediaWiki installations have images hosted on a different domain than the wiki, and in some cases do not have an 'Access-Control-Allow-Origin' header on the image server domain. This causes the XMLHttpRequest for MultimediaViewer to fail, and nothing but a black screen appears. So that the usability isn't completely broken in these (and similar) situations, if the XMLHttpRequest to get the image fails for any reason, MultimediaViewer should fall back to simply displaying the image using an <img> tag.

--------------------------
**Version**: unspecified
**Severity**: major
Mass-removing the Multimedia tag from MediaViewer tasks, as this is now being worked on by the Reading department, not Editing's Multimedia team.
**bryanhunt** wrote:

I can't comment on the rational other than to say that the behavior is common enough to indicate it would be condition worth considering. Due to the fact that the CORS header is requesting a browser to relax its security level it does sort of make sense that peripheral security would flag that as dangerous in that regard.

The being said switching over to https does resolve the problem so offering that as an option to the user when the error screen shows up could be the easiest way to handle condition.
We do fail more gracefully now (there is an error message, not just a black screen of deatch which is what the OP was complaining about). Could look nicer (we have some design notes in https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/299 ) but that's very low priority.

I'll think about adding a fallover, but we have too many of them already (the image loading can fail in other ways) and the logic is getting way too complex for its own good. Also, while the image could be loaded without CORS, some of the metadata API requests could not (we could probably recover from those requests failing, though).

All that said, stripping CORS headers is horribly broken behavior and makes zero sense from a security point of view. You should probably complain to the manufacturer / whitelist Wikipedia domains.
**bryanhunt** wrote:

Yes, while that is true (watchguard), it is far from an extraordinary configuration ( http://www.garysieling.com/blog/dont-use-access-control-allow-origin ) and the OP's comment was that the application should fail a bit more gracefully the headers don't exist. Web tech is far from my area of expertise but as a developer I would have to concur with the OP that it does make sense for Media Viewer to fail over to another mechanism to ensure a functional application in these situations.

An interesting note is that while Firefox & Chrome both exhibit the same failure mode, IE (11.0.9) does not appear to - making me assume that it either lacks similar security checks or is already using a different mechanism.
Wikipedia images are served with correct CORS headers:


$ curl -vo/dev/null 'http://upload.wikimedia.org/wikipedia/commons/thumb/8/8a/Media_Viewer_-_View_Original_File_-_Mockup_1024px.jpg/1024px-Media_Viewer_-_View_Original_File_-_Mockup_1024px.jpg' 2>&1 | grep Access-Control

< Access-Control-Allow-Origin: *
< Access-Control-Expose-Headers: Age, Content-Length, Date, X-Cache, X-Varnish

$ curl -vo/dev/null 'https://upload.wikimedia.org/wikipedia/commons/thumb/8/8a/Media_Viewer_-_View_Original_File_-_Mockup_1024px.jpg/1024px-Media_Viewer_-_View_Original_File_-_Mockup_1024px.jpg' 2>&1 | grep Access-Control

< Access-Control-Allow-Origin: *
< Access-Control-Expose-Headers: Age, Content-Length, Date, X-Cache, X-Varnish


Maybe you are you behind some sort of proxy which messes with the headers?
**bryanhunt** wrote:

Media Viewer handling of lack of CORS headers in Chrome

This seems to be the root cause of the chrome rendering problem of wikipedia images since media viewer is now enabled by default. I am quite surprised I couldn't find any other reference for media viewer simply not working for Chrome.

I have confirmed this behavior in Chrome Version 35.0.1916.153 m on windows XP, 7, & 8

**Attached**: {F12997}
There could be a flag (off by default) to enable AJAX image loading; when off, we could show a static (positionless) loading bar.
(In reply to Tisza Gergő from comment #5)
> George: the MultimediaViewer version you use is outdated, the current
> version loads images differently. Do you want to give a shot at updating to
> the current version? (The tip of the 1.23wmf17 branch should be a safe
> choice.)
> 
> I expect it will still fail, but for an entirely different reason, and that
> will be easy to fix.

Alright, I updated the extension. It works and does have the fallback, but the fallback also blurs the image a lot. I know why it's doing that, but maybe should it not upscale the img tag bigger than the image's thumbnail was?
For now I am setting this back to unconfirmed, most of the image loading code has been replaced since then.
George: the MultimediaViewer version you use is outdated, the current version loads images differently. Do you want to give a shot at updating to the current version? (The tip of the 1.23wmf17 branch should be a safe choice.)

I expect it will still fail, but for an entirely different reason, and that will be easy to fix.
Contents of the console:

XMLHttpRequest cannot load http://images.brickimedia.org/7/7d/Goodship1.jpg. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://dev.brickimedia.org' is therefore not allowed access. 

Uncaught TypeError: Cannot read property 'length' of null mmv.provider.Image.js:93
Image.binaryToDataURI mmv.provider.Image.js:93
(anonymous function) mmv.provider.Image.js:73
(...)
request.onreadystatechange mmv.performance.js:71
Tracked in Mingle as https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/295
(In reply to Tisza Gergő from comment #1)
> We do have an <img> fallback, but it sets img.crossOrigin = true on certain
> browsers where the fallback would otherwise result in downloading the image
> twice. Just to be sure that is really the cause of the problem, is there a
> public wiki where this bug can be reproduced?

Yes, here is an example: http://dev.brickimedia.org/wiki/VisualEditor You'll have to make an account so you can enable it in Beta Features (I think) but that only takes a minute or so.
We do have an <img> fallback, but it sets img.crossOrigin = true on certain browsers where the fallback would otherwise result in downloading the image twice. Just to be sure that is really the cause of the problem, is there a public wiki where this bug can be reproduced?
We apply red link styles to nonexistent titles in the link suggestions, so for redirects and disambig pages the corresponding styles/classes should be applied as well.

I don't actually know what these are, ask James :)

--------------------------
**Version**: unspecified
**Severity**: trivial
Change 345883 merged by jenkins-bot:
[mediawiki/core@master] mw.widgets.TitleOptionWidget: Apply styles for redirects/disambiguation links

[[https://gerrit.wikimedia.org/r/345883]]
>>! In T63072#3147540, @matmarex wrote:
> I don't think so – that one did it for links in the editing surface, but not in the link inspector suggestions dropdown. Looks like this code lives in mw.widgets.TitleOptionWidget now.
> 
> …and we actually handle redirects and disambigs there with custom icons. So this should be trivial.

Oh, hah, I thought we'd done it when the code was in VE but clearly I was wrong. :-)
Change 345883 had a related patch set uploaded (by Bartosz Dziewoński):
[mediawiki/core@master] mw.widgets.TitleOptionWidget: Apply styles for redirects/disambiguation links

[[https://gerrit.wikimedia.org/r/345883]]
I don't think so – that one did it for links in the editing surface, but not in the link inspector suggestions dropdown. Looks like this code lives in mw.widgets.TitleOptionWidget now.

…and we actually handle redirects and disambigs there with custom icons. So this should be trivial.
This was done by @matmarex way back in August 2014 (two weeks after my comment above) – 066283dde745fcc372ffab8d753962858813d032.
(In reply to Bartosz Dziewoński from comment #2)
> We actually don't apply any classes, ve.ui.MWLinkTargetInputWidget.css just
> has some styles defining a close-enough reddish color. (This is kind of bad
> since the color can differ per-skin.)
> 
> .ve-ui-mwLinkTargetInputWidget-menu .oo-ui-menuItemWidget[rel=newPage] {
> 	color: #BA0000;
> }
> 
> There are no styles by default for redirect and disambiguation links, some
> users choose to style them in various ways (usually green for redirects and
> maroon for disambigs). 

Presumably the styles will be ported over to Parsoid content, at which point we can just apply them directly?


> I'm not sure if we should do this for the link in the inspector; they are
> already visually distinct by being placed in separate sections. We might
> want to remove the reddish styles too...

I'm not sure. Consistency of hinting is important.
We actually don't apply any classes, ve.ui.MWLinkTargetInputWidget.css just has some styles defining a close-enough reddish color. (This is kind of bad since the color can differ per-skin.)

.ve-ui-mwLinkTargetInputWidget-menu .oo-ui-menuItemWidget[rel=newPage] {
	color: #BA0000;
}

There are no styles by default for redirect and disambiguation links, some users choose to style them in various ways (usually green for redirects and maroon for disambigs). 

I'm not sure if we should do this for the link in the inspector; they are already visually distinct by being placed in separate sections. We might want to remove the reddish styles too...
*** Bug 64584 has been marked as a duplicate of this bug. ***
VisualEditor has some deliberate/non-buggy differences in its display, compared to what readers will see on a saved page, such as the addition of blank lines/slugs to make adding new items at the top of a page.  These differences sometimes confuse users.

Add a preview button so that users can see the final version, rather than the slightly different VisualEditor version.

**See Also**:
*{T49790}
*{T44139}
*{T39931}
Suggestion from SarahTehCat:  Use the 'Live Preview' system (if it's stable).
comparison of screenshots

Currently, VisualEditor inserts blockSlugs around rellinks and dablinks (collectively known as hatnotes). This adds a lot of extra whitespace around them compared to how they are formatted normally. See attachment.

--------------------------
**Version**: unspecified
**Severity**: normal

**Attached**: {F13459}
Still exists (see testcase at https://en.wikipedia.org/wiki/User:Neil_P._Quinn-WMF/T62516). We now explain this inconsistency somewhat better by showing a "insert paragraph" message when you hover over one of the slugs (see screenshot), but this still falls short of our ideal of having the VisualEditor surface appear identical to the read surface.

{F160551}
**Author:** `gabriel.birke`

**Description:**
There is no way to make the VisualEditor Media selection to look only for local media (send iilocalonly when querying imageinfo). While this is ok for Wikipedia, it's not suitable for other wikis.

There should be a checkbox in the search dialog to switch to local only search.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Intention:
Remove a blank section heading (==<nowiki/>==) at the end of a page.

Steps to Reproduce:
1. Place cursor on blank section heading at the end of the page.
2. Try to select it.


Actual Results:  
Nothing.  Also, it's not possible to select the whole line (e.g., to cut and paste it, leaving nothing behind) even after you type something on the section heading.  If you type "abc", then you can select and cut "abc" (Note:  what it cuts is *not* "==abc=="), but the ==<nowiki/>== will remain.


Reproducible: Always

You can test this at https://en.wikipedia.org/w/index.php?title=User:Whatamidoing_(WMF)/sandbox2&oldid=589158823

--------------------------
**Version**: unspecified
**Severity**: normal
The bug confirmed  - <nowiki/> cannot be deleted from VE.
Screenshot

Steps to reproduce:

1.Open a page with VE
2.Add any image
3.Open the dialog box to add image again
4.Type a different string in the textbox to search for matching images.

Observed Result:
An error appears TypeError: jQuery1830683983782510787_1388777743220 is not a function

See the screenshot attached 
Test Environment: http://en.wikipedia.beta.wmflabs.org/
Browser: FF 25
OS: MAC OS X 10. 8. 5 
Page:http://en.wikipedia.beta.wmflabs.org/wiki/New_pageimage?veaction=edit

--------------------------
**Version**: unspecified
**Severity**: enhancement

**Attached**: {F12791}
*** Bug 58364 has been marked as a duplicate of this bug. ***
*** Bug 68059 has been marked as a duplicate of this bug. ***
Also:
* Upstream jQuery: http://bugs.jquery.com/ticket/8744 (status: cantfix)
* Closely related upstream Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=707154 (status: NEW)
As such, please don't waste any more time on this. This is harmless errors that we can't do anything about and are side-effects of behaviour that is very much intended and wanted by us. Just another one the category of browsers being ugly and/or minor issues upstream.
That patch, as far as I can see, did nothing. And if it did, it would actually have caused a regression.

The TypeError thrown is caused by the JSONP <script> tag request finishing and trying to invoke a temporary global function that jQuery exposed, but has revoked since because the consumer of $.ajax, VisualEditor in this case, has aborted the request.

All jqXHR objects have an abort method. Duck-typing it is useless because it is always there.

And while JSON-P doesn't have a native abort mechanism, jQuery does a good job of emulating it (it will do a best effort approach to cancel the http request for efficiency reasons, and in case it still makes it, it will make sure it reaches a dead end and not cause our application code to process its data[1]).

As I mentioned before, the dead end results in a Uncaught TypeError which sounds bad, but isn't, because it's in an asynchronous and independent call stack that has no influence on either our or jQuery's cod execution.

[1] Even if there was a way to not half-abort these requests, we wouldn't want that. We actually want these requests to reach a dead end. Otherwise we'd get race conditions where you type "a", "ab", "abc" and after "ab" is intended to be aborted, it might still arrive *after* "abc" and mess up our search results.
Change 140044 merged by jenkins-bot:
Media search dialog: Only try to abort request if possible

https://gerrit.wikimedia.org/r/140044
Change 140044 had a related patch set uploaded by Alex Monk:
Media search dialog: Only try to abort request if possible.

https://gerrit.wikimedia.org/r/140044
I already had InstantCommons enabled, but couldn't reproduce it before. Looks like I can now.
This can be reproduced when using the input field for the Media insertion dialog.

E.g. on https://www.mediawiki.org/wiki/VisualEditor/Basic_example_worksheet?veaction=edit

It might not throw the error on your local wiki if your wiki is not configured to use a separate wiki, e.g. Wikimedia Commons, as extra file repository. Enable wgUseInstantCommons if you haven't already.

https://www.mediawiki.org/wiki/Manual:$wgUseInstantCommons
Looks like we fixed this – possibly by resetting the search on open?
Although I can't actually reproduce this error.
(In reply to Krinkle from comment #5)
> This doesn't affect our callstack in any way, and from our perspective it
> works as expected (after the request is aborted, our callback must not fire).
> 
> This last part is a jQuery internal implementation detail that might change
> in the future, but either way, it is out of our hands, doesn't affect
> anything, and nothing we can do anything about.

I'm tempted to wontfix this, but apparently people are complaining that VE is broken because of it. I guess we'll just have to suppress the error.
Lowering priority as this is merely a console notice. It doesn't affect anything in any way, it is in fact "expected" behaviour by jQuery due to there not being another way to do what it does.

What it does is cancel a cross-domain ajax request. Short of CORS/XHR, there isn't actually such thing as a cross-domain ajax request. What it really does (and we rely on this) is JSON-P, which is a <script> tag to the api.php entry point with a temporary function as callback (this is a sort-of standard method called "JSON-P" which MediaWiki actively supports, it's not a VE intention or a hack beyond what it is).

As with many ajax-based content population requests (e.g. search suggestions, auto completion etc.) we abort pending requests when we fire off the next. When interacting with the local API, we use regular XHR which has an abort method.

When interacting with a foreign API, jQuery gives us an XHR-like interface but really underneath it is JSON-P, which means there isn't a way to actually abort the request. Instead, jQuery deletes the callback and does a best-effort approach to cancel the request. When the request does come back, it will try to invoke a callback that has already been revoked, which results in a TypeError in the asynchronous callstack of the ajax request.

This doesn't affect our callstack in any way, and from our perspective it works as expected (after the request is aborted, our callback must not fire).

This last part is a jQuery internal implementation detail that might change in the future, but either way, it is out of our hands, doesn't affect anything, and nothing we can do anything about.
This issue is happening on mw.org too
This issue is still occurring while inserting image inside Media Settings and Reference Dialog.

Steps to reproduce:

1.Click on a image inside VE
2.Go to Media Settings 
3.Type something as caption and add another image inside it

Second way to reproduce:

1.Click on a reference inside VE
2.Type something and add a image in this dialog box

Screenshot attached

Test Environment: http://en.wikipedia.beta.wmflabs.org/
Browser: FF 25
OS: MAC OS X 10. 8. 5 
Page:http://en.wikipedia.beta.wmflabs.org/wiki/Jan8th?veaction=edit
Created attachment 14258
Reproduced on 8th January

**Attached**: {F12793}
Not happening anymore.Possible fix for the bug might be: https://gerrit.wikimedia.org/r/#/c/102377/
as discussed with Moriel.
To reproduce:

0. Go to a page with two sections.
1. Click the "Edit" link on the second section.
2. Make some changes in the first section.
3. Press the save button.

Observed: The second section's name is shown in the summary.
Expected:
1. If only one section was changed, then that section's title should be shown in the summary.
2. If more than section was changed, no section title should be shown.

--------------------------
**Version**: unspecified
**Severity**: trivial
**See Also**: T53903
The current behavior 
- clicking on Edit in a section makes all page(sections) available for editing in VE. 
- if there are two sections  - 'Review your changes' in save box will display both section titles - no matter which section was opened or edited
- with three or four - only the section title to which changes were applied will be displayed
**Author:** `Wikifram`

**Description:**
When I edit a page, and add a reference to the text and a different reference to an image caption, all in one edit, then the reference text for the image caption is not saved but gets changed to the reference text from the text (this already happens in the preview). You now get two references with the same text, even though you gave them a different text. 

Example: [https://www.mediawiki.org/w/index.php?title=User%3AFram%2FSandbox&diff=840234&oldid=840227] (the image caption ref had a different text on typing)

--------------------------
**Version**: unspecified
**Severity**: normal
{T87106} isn't quite a duplicate of the outcome, but it's the same issue.
The key bug here is bug 47344, about using sub-documents instead of the current hack. This would affect media captions and references, and possibly other things.
See also bug 60919?
I can reproduce this issue.
Change 102386 had a related patch set uploaded by Aquifacae:
Changed wiktionary/en.ico favicon to proper image and resolutions

https://gerrit.wikimedia.org/r/102386
**Author:** `Wikifram`

**Description:**
This version of my sandbox at enwiki, [https://en.wikipedia.org/w/index.php?title=User:Fram/sandbox&oldid=585258547], is no longer editable in VE by me (FF25, W7). It opens, and I can make whatever changes I want, but the "save" button stays disabled, and when I open the reference interface, I can no longer close that one either. The category and media interface work allright though.

--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=57573
Yuck.

So the problem is that you've got a reference in an image's caption, which is inside a reference; this is not allowed in wikitext (as you can see from the "Cite error: A <ref> tag is missing the closing </ref> (see the help page)." error), and is because the restriction on media items' captions doesn't inherit the restriction of the reference block.

We'll need to build a way for restrictions to be explicit and inheritable.
**Wikifram** wrote:

[16:24:59.875] TypeError: itemNode is undefined @ https://bits.wikimedia.org/en.wikipedia.org/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki%2CSpinner%7Cjquery.triggerQueueCallback%2CloadingSpinner%2CmwEmbedUtil%7Cmw.MwEmbedSupport&only=scripts&skin=vector&version=20131210T024153Z:298
Could you please open the Error Console (or whatever it is called in your browser) and reload the page that you see the problem on? If there is a problem or an error with JavaScript it should be printed in that console.
For more information please see:
* Firefox ≥24: https://developer.mozilla.org/en-US/docs/Tools/Web_Console
* Internet Explorer: http://msdn.microsoft.com/en-us/library/ie/dn255006
* Google Chrome: https://developers.google.com/chrome-developer-tools/
* Apple Safari: https://developer.apple.com/library/safari/documentation/AppleApplications/Conceptual/Safari_Developer_Guide/PrototypingYourWebsite/PrototypingYourWebsite.html
* Opera: http://help.opera.com/Linux/12.10/en/errorconsole.html
Steps to reproduce:

1. Go to https://en.wikipedia.org/wiki/Wax_foundation
2. Click on "Edit".

The first image is automatically selected, and its four corners are replaced with image resizing icons, but "Media" image editing icon is not shown. I expected that the image would not be selected, or if selected that image editing icon is shown.

3. Click on the second image.
4. Click again on the first image. Now the image editing icon should be shown.
5. Click on the image editing icon.
6. Click on the word "frame". Link editing icon should be shown.
7. Click on the link editing icon.
8. Enter "Beehive frame" (without quotes) in the text box.
9. Click on "Apply changes".
10. Click on "Save page". "Save your changes" dialogue appears.
11. Click on "Save page" in the new dialogue.

The VisualEditor displays "Your changes to Wax foundation have been saved.", but nothing has actually been saved.

Now, I see three bugs here:

1) The first image should not be selected automatically.
2) Possibly I have to do something after entering the link target in order for the target to be "applied" to the image caption? But I don't see what it is that I should do.
3) The editor shouldn't display "changes have been saved" message when there are no changes to be saved; doing so prevents the people from knowing that what they did was not saved, regardless of whether there was an error on their part or on the VisualEditor part.

--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=58248
https://bugzilla.wikimedia.org/show_bug.cgi?id=62542
(Confirmed still an issue.)
*** Bug 62650 has been marked as a duplicate of this bug. ***
We now try to select the nearest content branch, so this bug is only reproduceable if the document consists of just an image.
1.1) I believe the image should not be selected, but I understand people might have different opinion about it.

1.2) But if the image is selected, then the icon must be shown as well. I see this as an obvious bug.

2)

OK, it appears that in order for the link to be applied, I have to click on < icon in the top left corner of the link editing box; or, I have to press Enter twice; or, click in the text editing box and then in the space below it(?).

To me, and I believe other editors, this is very unintuitive. Perhaps < icon could be changed to ✓ - I see < as signifying 'Undo' rather than 'Apply'. Perhaps "Apply changes" should be ghosted when there are no chages to apply. But even with these changes I don't see how I could intuitively know what I should do.

The "Review your changes" button shows correctly whether I have any changes.
I'll leave the first question to others, for the other ones:
2) You need to make sure that you select the word you want (then you click on it, press Enter, whatever). Try and review your changes before you save: is it there now? If it is, you should be able to save and your edit should stay in the page history. If it isn't, please let us know the browser (and its version) and Wikipedia skin you use.
3) I experienced something similar back in July: https://bugzilla.wikimedia.org/show_bug.cgi?id=51243 .
Intention:
Re-use a reference.


Actual Results:  
The ref naming scheme needs improvements so that humans can remember which ref name they want to re-use, especially if they are using the wikitext editor, where they will not have any of the possible hints that VisualEditor may provide.

Expected Results:  
A system that is "xxx:0", where "xxx" is text simply copied out from the beginning of the named ref would be an improvement.  We can assume that anything inside the ref is in a language that the editor is capable of coping with.  We can exclude the names of templates and their parameters, as well as "http" (otherwise, bare URLs in refs will produce a lot of equally unfriendly <ref name=htt:n> names).

Reproducible: Always

--------------------------
**Version**: unspecified
**Severity**: enhancement
*** This bug has been marked as a duplicate of bug 50568 ***
Speaking as an extensive editor, I just find the exist reference I want to re-use and manually copy the name; this is no extra work in VE. Clearly some people try to remember the name between uses, but given that random people write random names for references already…
I realize that any automagic system will have serious limitations, compared to prompting users for a human-created name (which VisualEditor ought to be doing).  But a semi-random string of letters is actually easier for most people to remember than a purely incremental number.  <ref name="sgd1"> and <ref name="iuo2"> are easier to keep straight than <ref name=":1"> and <ref name=":2">—and <ref name="usc1"> and <ref name="lee2">, when the ref's contents actually meantion USC and Lee, are even easier.

I don't understand how including some letters (taken from the ref's contents) in the ref name would fail to work anywhere, or at least would fail to work at any language that uses left-to-right typing (unless Arabic numbers are also typed right to left; I can imagine that combining RTL for letters with LTR for numbers would be irritating) and a non-IME/non-variant character set (which might also work just fine, but I don't know enough to have an opinion).
Why humans need to be able to remember the ref names:

Because actual humans actually have to be able to remember the ref name if they're going to re-use it.  They cannot re-use the ref any other way.

This is true for everyone now, because VisualEditor is only showing (at most) the ref names when you try to re-use a ref, which means that anyone trying to re-use a ref currently needs to know whether the ref they want to re-use ref name :0, :1, :2, :3, :4, :5, etc.—sometimes through a dozen or more meaningless numbers.

This is true permanently for anyone not using VisualEditor, because there is no other way to re-use a ref in the wikitext editor except to manually type (or copy) the name of the ref.
(In reply to comment #0)
> The ref naming scheme needs improvements so that humans can remember which
> ref name they want to re-use

Why?

This is an insane amount of work to do, won't work on wikis that do things in a different way (e.g. this might work for enwiki and frwiki but not dewiki or others), and will likely not actually result in what you want.

I'm hovering on WONTFIX, but will leave this as "Lowest" instead for now.
In the linked diff I added an external link within single brackets.
It didn't trigger the markup warning - I wouldn't know how to add such links in VE.
The markup guide for en.wp says these links are "Only used within article body for footnotes", but of course they might be used also outside ns0.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**URL**: https://en.wikipedia.org/w/index.php?title=User%3AElitre_%28WMF%29%2Fsandbox&diff=582808389&oldid=582806629
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=57419
On reflection, I'm WONTFIXing this as it'd be too disruptive for a temporary notice.
I worry that this would interfere with languages which use []s rather than ()s in text – remember that the wikitext warning is for rare, occasional chiding comments for users who've temporarily forgotten that they're using a rich editor rather than wikitext.

If you want to write "using sites like Amazon [http://amazon.com and its local country variants] or eBay [http://ebay.com etc.]" you're going to be rather annoyed by this…
(As far as I tested, it can't edit them, that's why I filed bug 57419.)
Steps:
1. Edit page
2. Add [http://example.org]


Yep, we should change our wikitext detection to account for external links. Widening scope of this bug for external links in general, not just unnamed ones.

Steps:
1. Edit page
2. Add [http://example.org Foo] (unnamed external link)
3. Add [http://example.org] (named external link)

(In reply to comment #0)
> [..] I wouldn't know how to add such links in VE.

VisualEditor currently doesn't allow (external) links to be created without names. It can edit them (afaik), but not create new ones. This is a separate issue from the wikitext warning not being triggered though.
Unless you have a good reason to kill any of these, this is expected and okay.

The noise refers either to:
* horrible hacks we need to support older browsers ("Expected
  'important' but found 'ie'.  Expected ';' or '}' to terminate
  declaration but found 'ie'.", "Expected declaration but found '*'.
  Skipped to next declaration." – both of these are for IE 6 and 7)
* browser-specific rules that other browsers do not understand (-ms-*,
  -webkit-*, …)
* or things your browser just does not support ("Unknown property
  'user-select'.").
Really depends on our browser version support.  
For example, "border-radius" property is supported since Firefox 4; deprecated "-moz-border-radius" is required for Firefox 3.x and older, and unsupported since Firefox 13.
So... those are just the CSS parser saying it doesn't recognize various things that are there for other browsers or older browsers.

Not sure how actionable this is?
It would be very nice if WikiEditor had a dialog to work with templates the way VisualEditor has. There is also a user script: [[User:קיפודנחש/TemplateParamWizard]], but IIRC this script doesn't use the informations provided by TemplateData, but uses its own format.

--------------------------
**Version**: unspecified
**Severity**: enhancement
>>! In T59232#610546, @Aklapper wrote:
> Michael: How is/was this request different from the (unmaintained) template editor which was just removed from WikiEditor recently? https://gerrit.wikimedia.org/r/#/c/123647/

The difference is, that it actually should work ;-) This wasn't removed because nobody wants such a feature, but because that module didn't do anything sensible.
Michael: How is/was this request different from the (unmaintained) template editor which was just removed from WikiEditor recently? https://gerrit.wikimedia.org/r/#/c/123647/
There should be a line break (ENTER) between "{{Álgebra}}" and "[[Categoria:Estruturas algébricas]]" on these edits:
https://pt.wikipedia.org/wiki/Anel_%28matem%C3%A1tica%29?diff=37240720
https://pt.wikipedia.org/wiki/Corpo_%28matem%C3%A1tica%29?diff=37240730

--------------------------
**Version**: unspecified
**Severity**: normal
I just [[https://pt.wikipedia.org/w/index.php?title=Usu%C3%A1rio%28a%29%3ANeil_P._Quinn-WMF%2FTestcase%2FT58530&diff=41959157&oldid=41959144|tested it]], and this issue still exists.
This issue [[https://pt.wikipedia.org/w/index.php?title=Usu%C3%A1rio%28a%29%3ANeil_P._Quinn-WMF%2FTestcase%2FT58530&diff=41959157&oldid=41959144|still exists]].
screenshot

While we can't yet just click into a <source> SyntaxHighlight extension chunk and edit it, I notice we can now click a "<>" button that opens a plaintext editor for the contents. Awesome!

Unfortunately the popup box for this seems really small, and there doesn't appear to be any way to resize it (no resize handles or zoom button that I can find).

Especially for editing source code blocks, being able to bump the size waaay up would be very helpful.

--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://www.mediawiki.org/wiki/Manual:CORS?veaction=edit

**Attached**: {F12119}
Change 247567 merged by jenkins-bot:
Use dialog for editing block level syntax highlights

[[https://gerrit.wikimedia.org/r/247567]]
Change 247567 had a related patch set uploaded (by Esanders):
Use dialog for editing block level syntax highlights

[[https://gerrit.wikimedia.org/r/247567]]
That inspector shown in that screenshot is not one from the SyntaxHighlight extension. Rather, it's the default dialog VisualEditor provides to allow editing of unknown MediaWiki tags (e.g. ones not registered elsewhere with a dedicated interface for known attributes and validating of values).

The SyntaxHighlight dialog or VisualEditor was merged only a few days ago:
{T45126}

It'll be deployed in wmf12 next week. Here's a screenshot from beta:

{F183659}
http://en.wikipedia.beta.wmflabs.org/wiki/Python?veaction=edit

Which.. is also not very big.  Keeping this task unresolved for now.

A few ideas:
* Button to turn dialog into "full page" size.
* By default, inner height unrestricted (however large the textarea is, autogrowing when changing it). With outer height providing scroll overflow based on browser window size.
* Or; default to OOjs UI "large" or "larger" size at least.
On the English Wikipedia, I'd like to be able to use the VisualEditor on any namespace, but especially the project namespace.

Given that VisualEditor is opt-in and already regularly breaks pages anyway, I don't think lifting the arbitrary namespace restriction on wikis where VisualEditor is opt-in (such as the English Wikipedia) will be problematic.

Submitted for consideration. CC'ing James and Roan.

--------------------------

See also: {T57968}
(In reply to comment #3)
> (In reply to comment #1)
> > If VE is OK to edit a namespace (and, in general, it's probably fine for
> > any that aren't signed, Template: or MediaWiki:) then we should just make
> > that config change and not vary it per wiki. Make a distinct bug for that?
> 
> I vaguely understand what you're saying here, but I think it would be best if
> you filed the bug.

Sure - bug 55968 filed.
This is not a site request but a VisualEditor enhancement.

The check in [1] needs to be moved somewhere else (one of the hooks in VisualEditor.hooks.php?).

[1] https://git.wikimedia.org/blob/mediawiki%2Fextensions%2FVisualEditor.git/a531b396981042da09280df2ea5dceb6be3fa106/ApiVisualEditor.php#L218
(In reply to comment #1)
> If VE is OK to edit a namespace (and, in general, it's probably fine for
> any that aren't signed, Template: or MediaWiki:) then we should just make
> that config change and not vary it per wiki. Make a distinct bug for that?

I vaguely understand what you're saying here, but I think it would be best if you filed the bug.
Let's take a step back here. Here's my use-case: I don't edit articles very much, but I still want to be able to test VisualEditor when I do occasionally edit non-articles. Today I came across [[Wikipedia:Meetup/DC]] and wanted to use VisualEditor to edit it. I wasn't able to. :-(

You bring up a good point about user signatures, but many project-space pages are informational in nature, not discussion-oriented.

Perhaps there's some way to programmatically detect whether a page is a discussion page?

Or perhaps we can remove the hard restriction on VisualEditor editing? For example, if I try to navigate to <https://en.wikipedia.org/w/index.php?title=Wikipedia:Meetup/DC&veaction=edit> directly, VisualEditor won't load. We could remove the hard restriction and leave in place the soft restriction (not exposing the user interface tab). This would allow people like me to just hack in an extra tab. Dirty, but probably fine for now.
Three things:

1 - If VE is OK to edit a namespace (and, in general, it's probably fine for any
    that aren't signed, Template: or MediaWiki:) then we should just make that
    config change and not vary it per wiki. Make a distinct bug for that?

2 - Project: is frequently signed, especially on enwiki, so I think giving a VE
    editor in this context would be confusing and actively wrong. There is no VE
    tool for signing comments, nor for creating the definition lists which are
    (ab)used so very widely for MediaWiki discussions right now. The intent has
    always been that signed content would be covered by Flow, and I think trying
    to build tools now for a few months' usage would be a diversion from the main
    task of improving VisualEditor.

3 - I think that this would end up being a rather broken user experience when a
    wiki switched from opt-in to opt-out, and all the pages that you used to be
    able to edit with VE suddenly vanish in a cloud of WT-only smoke, without any
    explanation or obvious cause.

Consequently, minded to WONTFIX, but am open to suggestions
We have been encountering a number of performance issues and race conditions with VE and Chrome in recent times, this is probably one more of those. 

* In a fresh instance of Chrome 30 or Chrome 29, as a logged in user, visit https://en.wikipedia.beta.wmflabs.org/wiki/Special:Flow/Flow_QA

* Enter a Message topic

The VE controls and CE field take significant time to appear while the user sees a spinner.  For an example causing a failure in a browser test, see https://wmf.ci.cloudbees.com/job/Flow-en.wikipedia.beta.wmflabs.org-linux-chrome/12/testReport/(root)/Create%20new%20topic%20logged%20in/Add_new_Flow_topic/ .  Note the test times out with the spinner still visible after 5 seconds. 

This is not seen in Firefox

--------------------------
**Version**: unspecified
**Severity**: normal
We removed the VE option in Flow long, long ago :) 

People should feel free to reopen this when we actually have the VE in Flow option up and running again.
I've tested it on my own box. It's this call that takes the long time:

'http://localhost/mw-dev/load.php?debug=false&lang=en&modules=ext.visualEditor.base%2Ccore%2Cdata%2Cicons-vector%2Cstandalone%7Cext.visualEditor.viewPageTarget.icons-vector%7Coojs%2Coojs-ui%2Crangy%7Cunicodejs.wordbreak&skin=vector&version=20131106T030133Z&*'

This typically returns in ~6 seconds. However, I've found that sometimes it works in ~200ms. When that happens, VE loads quickly on my local box.

So it does indeed seem to be caching, of a particular ResourceLoader resource.
Aha; thanks for letting me know :).
("RESOLVED LATER" was replaced with the "lowest" priority. Might want to use that instead.)
This is likely a problem with the Labs instance; no varnish == no caching of VE elements :/. Unfortunately that means it's something we're probably not going to be able to track or test properly until we go into deployment on production. Closing as WONTFIX since LATER is no longer available.
The WMF core features team tracks this bug on Mingle card https://mingle.corp.wikimedia.org/projects/flow/cards/324, but people from the community are welcome to contribute here and in Gerrit.
**Author:** `swalling`

**Description:**
The introductory dialog for VE is supposed to be seen only once per person. However, it seems that the way it is hidden for users is dependent on session information, probably a cookie? 

This means that every time I clear my cookies, open an incognito browser window, use a new browser, or use a new device, I get the intro again. Even if I'm using the same account. This stinks. 

In GuidedTours we solve this problem (not showing users repeated intro tours across devices/sessions) by setting a hidden preference when someone completes a tour. I'd like to suggest we do that for the VE intro, unless someone can think of a more elegant way to avoid this annoying behavior.

--------------------------
**Version**: unspecified
**Severity**: enhancement
(In reply to Tom Hart from comment #5)
> Where is this preference to turn of the Welcome overlay located? I am always
> getting the "Welcome..." dialog when I click Edit, while logged in on the
> same machine, same session... I'm using Chrome Version 35.0.1916.114 on
> Mavericks 10.9.2.

It's hidden, only the server interacts with it. This is bug 65821
**tahart** wrote:

Where is this preference to turn of the Welcome overlay located? I am always getting the "Welcome..." dialog when I click Edit, while logged in on the same machine, same session... I'm using Chrome Version 35.0.1916.114 on Mavericks 10.9.2.
Change 125914 merged by jenkins-bot:
mw.ViewPageTarget: Hide the welcome dialog via a preference if possible

https://gerrit.wikimedia.org/r/125914
Change 125914 had a related patch set uploaded by Jforrester:
Hide the beta welcome via a preference, not a cookie, for logged in users

https://gerrit.wikimedia.org/r/125914
**swalling** wrote:

(In reply to comment #1)
> Yay more preferences bloat (and a slower page load). :-(
> 
> Given that the welcome dialog is temporary, I was tempted to WONTFIX this,
> but
> if someone wants to code it up we might consider accepting it.

In this case, the preference is hidden so while it might be bloat, it's not the kind that clogs up Special:Preferences. I'm not sure what's worse: presenting an unnecessary modal repeatedly or slowing page load time. Have we actually quantified how much each preference slows page load?
Yay more preferences bloat (and a slower page load). :-(

Given that the welcome dialog is temporary, I was tempted to WONTFIX this, but if someone wants to code it up we might consider accepting it.
Per discussion with Krinkle on IRC, the "publish and submit" button in Gerrit should not be used.

If this is the case, it should not be present.

--------------------------
**Version**: wmf-deployment
**Severity**: normal
Interesting, "Publish and Submit" is gone via upgrading. You can't submit from the review box anymore.
Actually sometimes you are required to force merged.
* Our Gerrit config requires V+2 to be present. We can change Jenkins to do V+1 on the patch test so that it doens't clash with the V+2 vote for the submit test, that resolves the ambiguity and will make the submit button not appear before it should.

* Alternatively, like for various repositories already (including VisualEditor) we could remove the "Submit" right from regular users (e.g. only for JenkinsBot and l10nbot, and some ops maybe).
(Where the word is the actual working part of the element).
Probably not a real bug, since it is triggered by a user mistake (who should remove the brackets), but since it's easily reproduceable, here are the steps:
take any <nowiki>[[link]]</nowiki> created like this (by ignoring the markup warning).
VEdit the page and use the linking tool on the word inside the brackets.
Save, you now have [[[[link]]]], and of course the nowiki tags are gone.

https://www.mediawiki.org/w/index.php?title=User:Elitre_(WMF)/SandboxVE&diff=prev&oldid=794483

https://www.mediawiki.org/w/index.php?title=User%3AFram%2FSandbox&diff=794473&oldid=794472

Just interested in understanding whether VE wants or can do something about it.

(Note that it is absolutely possible to get the same result with the traditional editor as well, https://sl.wikipedia.org/w/index.php?title=Klerofa%C5%A1izem&diff=next&oldid=4101482 ).

--------------------------
**Version**: unspecified
**Severity**: normal
Change 104695 merged by jenkins-bot:
(Bug 54877) Tokenize [[[[Foo]]]] correctly

https://gerrit.wikimedia.org/r/104695
Change 104695 had a related patch set uploaded by Subramanya Sastry:
WIP (Bug 54877) Tokenize [[[[Foo]]]] correctly

https://gerrit.wikimedia.org/r/104695
Re-re-phrasing the title (and yes, this appears to be a Parsoid bug, but a very low priority one).
Rephrasing bug. A user would not have a goal to generate 4 brackets in wikitext, but the use case of typing (or editing existing pages that do have) [[ around a link, that is genuine content that VisualEditor should be able to create and edit.
This is probably a bug in Parsoid, not VisualEditor.

Given a page containing:

[[[[Sandbox]]]]

Which contains no <nowiki>, this is parsed as [[<a href=Sandbox>Sandbox</a>]] by the PHP parser and renders accordingly.

When editing that page in VisualEditor, the initial rendering is wrong (it renders as a text node "[[[[Sandbox]]]]", no anchor link).

If I add text to that line or change the word to something else, the serialisation from Parsoid is still the same (no <nowiki> is inserted, so Parsoid is unaware of it being a link both in parsing and serialising).


Given a page containing:

<nowiki>[[[[Sandbox]]]]</nowiki>

When editing that in VisualEditor, the initial rendering is correct (1 text node containing "[[[[Sandbox]]]]").

If I add text to that line or change the word to something else, the serialisation from Parsoid is no longer the same. It dropped the <nowiki>, thus effectively (according to the PHP parser) turning it into a link after saving.
[Unused; we don't do tracking bugs, post-Phabricator transition.]

A central place for people to keep track of tracking bugs for VisualEditor. (Yay for bug meta-ness.)

--------------------------
**Version**: unspecified
**Severity**: enhancement
[adding the #tracking project to tasks blocking (now deprecated) T4007 as part of T93366]
Missing scan and edit toolbar

I am posting three separate bugs and mentioning this in this first report because they are somewhat related.

The user defined edit toolbar, defined in my very simple
https://en.wikisource.org/wiki/User:Ineuw/common.js stopped functioning in this latest version of the mw software. In versions previous, it worked reliably and always, permitting me greatly increased productivity. The toolbar does show up intermittently and occasionally. 

Regardless of the toolbutton definition syntax used, the same intermittent functioning is the result. The syntax is either the current definition one, or an older one:

mw.toolbar.addButton(
        '',
        ' Æ ',
        'Æ',
        '',
        '',
        ''
);

I also used the definitions without image buttons, thinking that this may be the cause, but it doesn't make a difference.

The problem is also not browser related. I tried other browsers and OS's as well:

Firefox in Windows, Xubuntu, and Apple OSX.
Safari in Windows and Apple OSX.
Google Chrome in Windows and Linux (Xubuntu).
but the intermittent behaviour is the same. . . . . 

Finally, this is also true on the Commons and Wikipedia, where it's less critical because I am not so active on those wikis.

Please see attached image.

--------------------------
**Version**: master
**Severity**: normal

**Attached**: {F11589}
I ask that this bug be closed, since I accepted the demise of the old wiki toolbar.
(In reply to comment #8)
> I also got the same Firefox (23.0.1) error as Andre Klapper. If this seems to
> be the cause, can't it be corrected?

It might either be an issue in your code in common.js, or some changes in MediaWiki. Apart from Alex' cleanup which got merged at the beginning of September I cannot see any changes in
https://git.wikimedia.org/history/mediawiki%2Fcore.git/HEAD/resources%2Fmediawiki.action%2Fmediawiki.action.edit.js

> Finally, this is a very big disappointment because the replacement option is
> very awkward. Among other things, it takes up (and unnecessarily) a lot of
> screen real estate and I work on a 22" screen.

I don't see that big difference in size. Not sure if we refer to the same things?
The legacy toolbar had enough issues (e.g. it was never meant to be expanded so inserting required exposing and dealing with implementation details) so it got replaced by the current toolbar.
I am not the only one who is using the toolbar at Wikisource. While other users have occasional issues, theirs seem to work on most cases. 

I also got the same Firefox (23.0.1) error as Andre Klapper. If this seems to be the cause, can't it be corrected?

Finally, this is a very big disappointment because the replacement option is very awkward. Among other things, it takes up (and unnecessarily) a lot of screen real estate and I work on a 22" screen. Krinkle's opinion is akin to taking away a mechanic's trusted tools because he doesn't personally favor them. He should try his hand at some proofreading for a day or two.
To quote Krinkle: 
"The classic edit toolbar has long been deprecated. The default was replaced
with WikiEditor on Wikimedia in a 2010 deployment", plus VisualEditor is also around the corner.
Setting lowest priority, might be even a WONTFIX.
Created attachment 13327
Character selection moved too low in new mw software version

To the attention of Andre Klapper

This is the missing image of the drop down character set selector

**Attached**: {F11593}
Created attachment 13325
old style toolbar coding

This text contains the legacy toolbar layout, without captions by the elements, no images, and notice the function syntax difference. It doesn't matter which I use, the behaviour is identical.

mw.toolbar.addButton(

and NOT 

mw.toolbar.addButtons(

**Attached**: {F11592}
Created attachment 13324
Legacy edit toolbar displayed.

**Attached**: {F11591}
Hi. I am sorry to confuse you. The new edit toolbar was activated so that I could take a proper snapshot and I forgot to turn it off. Otherwise, it's not usable for me at the moment.

Wikisource users, who use edit toolbar buttons, use the "legacy" old style because it's more versatile. For my main project work of Popular Science Monthly, I only need the 12-14 extended ANSI to accommodate French and German and occasionally Greek. 

I am also working on Hebrew/Arabic texts, and not being able to access the dropdown box of character selections, this forced me to try using the "advanced" WikiEditor toolbar in which my language setting places things in reverse order.

I am attaching what should be the correct display of the legacy toolbar when it works.
Hi ineuw,

your screenshot looks like the old toolbar to me, instead of the WikiEditor toolbar. Is that intended or part of the problem?

The WikiEditor toolbar should look like your screenshot in https://bugzilla.wikimedia.org/attachment.cgi?id=13323

I went to 
https://en.wikisource.org/w/index.php?title=Page:Popular_Science_Monthly_Volume_63.djvu/155&action=edit
to reproduce the problem (Firefox 23.0.1) and switched to horizontal layout.

I also copied your "common.js" file to my user account (the file basically just has a number of "mw.toolbar.addButtons" calls).

The scanned image still loads for me, and I get the correct WikiEditor toolbar, but in Firefox' Error Console I get:

Timestamp: 09/19/2013 11:52:12 AM
Error: TypeError: mw.toolbar is undefined
Source File: https://bits.wikimedia.org/en.wikisource.org/load.php?debug=false&lang=en&modules=user&only=scripts&skin=vector&user=AKlapper+%28WMF%29&version=20130919T095201Z&*
Line: 1

I have bug 47872 in mind.
Created attachment 13321
edit toolbar is showing occasionally

**Attached**: {F11590}
I'm really not at all sure that the actual benefits of this task to the people who are at the sharp end are actually understood by the developers. There is a reason that this has been resurrected at least twice, has at least four duplicate tasks, and the requests for it continue more than 5 years after it was first requested. Indeed this is one of just two tasks (T51969 is the other, and this is far more important than that) that are standing between where we are now and VE being intuitively easy for both new and power editors to use simply and reliably for non-specialist editing in almost all reasonable circumstances without making unforced errors.

Links are utterly fundamental to the way wikis work and VE is intended to be used by inexperienced users, so it is completely and utterly mind boggling to be told that something that forces unintuitive workarounds to achieve something that should be absolutely basic skill level 0.2 (at most) will not be fixed.
There is an insane amount of complexity with links in wikis due to the nature of how much they're used. Any change in this area would divert a lot of product and design time away from other projects, thus making changes here incredibly costly. Given the limited benefit of doing work here compared to other projects, this task is not going to be worked on any time soon. That is, after all, why James declined it twice. The debate here is interesting, but it is mostly academic at this point.
There is an insane amount of complexity with links in wikis due to the nature of how much they're used. Any change in this area divert a lot of product and design time away from other projects, thus making changes here incredibly costly. Given the limited benefit of assigning work here compared to other projects, this task is not going to be worked on any time soon. That is, after all, why James declined it twice. The debate here is interesting, but it is mostly academic at this point.
>>! In T55973#3505027, @Whatamidoing-WMF wrote:
>> if a link targets a page that matches exactly the link label, and a user changes that label to the name of a different page, the software can suggest the target also to be updated.
> 
> That would be very annoying every time someone needs to change the ending of a link.  `[[Example]]s` is a good link.  `[[Example|Examples]]` is bearable.  Having Clippy ask you if you want to change the link from ``[[Example]]` to `[[Examples]]` every time you try to fix the grammar in a sentence is not bearable.

I think that whether the approach is annoying or not would depend on its execution, and how prominently the suggestion is presented. Clippy represents the annoying extreme of suggestion mechanisms: causing distraction as an animated character, and providing unreasonable suggestions ("what made Clippy think this could be a letter?"). In this case, the approach should be much more subtle (no animated characters) and the connection on why a suggestion is provided is quite clear (so even if it is not what you want, there is not a big surprise that the suggestion was provided). More like [[ https://www.youtube.com/watch?v=qcm0rG8EKXI | Google instant ]] than Clippy.

In that particular example, given that "Examples" is a redirect to "Example", we can probably show no suggestion at all.
> if a link targets a page that matches exactly the link label, and a user changes that label to the name of a different page, the software can suggest the target also to be updated.

That would be very annoying every time someone needs to change the ending of a link.  `[[Example]]s` is a good link.  `[[Example|Examples]]` is bearable.  Having Clippy ask you if you want to change the link from `[[Example]]` to `[[Examples]]` every time you try to fix the grammar in a sentence is not bearable.
> if a link targets a page that matches exactly the link label, and a user changes that label to the name of a different page, the software can suggest the target also to be updated.

That would be very annoying every time someone needs to change the ending of a link.  `[[Example]]s` is a good link.  `[[Example|Examples]]` is bearable.  Having Clippy ask you if you want to change the link from ``[[Example]]` to `[[Examples]]` every time you try to fix the grammar in a sentence is not bearable.
>>! In T55973#3500032, @Thryduulf wrote:
>>>! In T55973#3491393, @ssastry wrote:
>> When you want to change the label, can't you just change the label text without opening the link editor? 
> There is no way for the software to know which you intend, and no way for the naive user to know which has actually happened without actively opening the link editor, but it is likely that the assumption will be that both were changed (per @Whatamidoing-WMF).

There is no way for the software to know, but the software could pay attention to some clues. As I mentioned in T55973#2792012, if a link targets a page that matches exactly the link label, and a user changes that label to the name of a different page, the software can suggest the target also to be updated. That would give visibility to the user on the mismatch between label and target, and let the user to update the target in one click if needed as some word processors do with spellcheckers.
>>! In T55973#3491393, @ssastry wrote:
> When you want to change the label, can't you just change the label text without opening the link editor? 
The problem is that when you do that you could be intending to change the label without the link or you could be intending to change both label and link. There is no way for the software to know which you intend, and no way for the naive user to know which has actually happened without actively opening the link editor, but it is likely that the assumption will be that both were changed (per @Whatamidoing-WMF). Remember that VE is focused towards inexperienced and less-computer-literate users rather than power users, so there will be a very high proportion of users who do not know that you need to actively check what VE is doing. 

Related to this, some way of identifying in the VE editing surface whether a link is piped or not would be useful in many different scenarios. I've only just thought of this but I've run out of time to investigate whether there is an existing task for this or not, so I'll pop it on VE/F and return to it this evening.
>>! In T55973#3491393, @ssastry wrote:
> ... that hack is probably unpleasant, but at last for simple label text edit scenarios, it should work just fine?

It works okay, assuming that you actually know that you have to follow all of those steps.  However, I think that we've proven that this is an invalid assumption in at least a substantial fraction of cases.  We have thousands of editors who are accustomed to changing a link such as `[[2016]]` to `[[2017]]` by only changing the visible number.  When you do that in VisualEditor, you end up with `[[2016|2017]]`.
>>! In T55973#3224611, @Thryduulf wrote:
> Well that news is a big disaapointment as the inability to quickly, easily, reliably and unambiguously change the destination the destination and/or description of a link is the biggest single impediment to Visual Editor.
> 
> When changing a link you could want to do one of three things:
> 1. Change the label
> 2. Change the target
> 3. Chang both.
> 
> The only way to be sure that the change you want to make is the one being made is to:
> 1. delete the current link, making sure to note the exact title and capitalisation of any section links
> 2. type the label
> 3. select the label
> 4. open the link dialog
> 5. enter the link, appending section links if necessary
> 6. close the link dialog.

When you want to change the label, can't you just change the label text without opening the link editor? But yes, in certain label-edit scenarios, one hack you have to rely on is to make sure there is at least one character left behind with the link and delete that character last ... that hack is probably unpleasant, but at last for simple label text edit scenarios, it should work just fine?
Well that news is a big disaapointment as the inability to quickly, easily, reliably and unambiguously change the destination the destination and/or description of a link is the biggest single impediment to Visual Editor.

When changing a link you could want to do one of three things:
1. Change the label
2. Change the target
3. Chang both.

The only way to be sure that the change you want to make is the one being made is to:
1. delete the current link, making sure to note the exact title and capitalisation of any section links
2. type the label
3. select the label
4. open the link dialog
5. enter the link, appending section links if necessary
6. close the link dialog.

In Google Docs you need to.
1. select the link
2. open the link dialog
3. change what needs to  be changed
4. close the link dialog

Google Docs users, to my knowledge, don't find this unnecessarily heavyweight but rather simple and reliable.
For clarity, this task isn't likely to have work on it soon.

In general, this goes strongly against the design philosophy of the tools, making the process of adding links much "heavier" and context-switching. Re-validating the research results would take a lot of time and effort. In practice users don't have as many problems with this area as with others that are higher importance.
Another problem to take into consideration are disambiguation pages. Example:
1. I add a link to https://en.wikipedia.org/wiki/John_Quested_(producer)
2. I then change the label (which has automatically been set to "John Quested (producer)") to just "John Quested".
In this case I do not want any automatism to change the link, and actually not even a suggestion to do so.

In this case this can easily be detected, as https://en.wikipedia.org/wiki/John_Quested is marked as disambiguation page. But doing the same steps with https://en.wikipedia.org/wiki/Albert_Einstein_(album) should work, too, without changing the link accidentally to https://en.wikipedia.org/wiki/Albert_Einstein, even though that page isn't a disambiguation.
> This issue seems to happen when editing a link that uses the page title as label. This may bring expectations of such information to remain in sync when changing the link (or even not being aware of the target potentially being different from the textual representation).

I do think that's only half of the issue, mind you. There's:

* It's easy to let the link text and URL get out of sync, if they were initially the same. This will show up with internal wikilinks, and URLs which are shown in full.
* It's hard to change the link text completely. Selecting the entire thing by dragging is prone to accidentally selecting outside the link annotation and thus un-linking it when you start typing. Common case: people who paste in a URL letting it auto-link, and then want to add a descriptive label.

Your suggestion helps with the former, but not the latter. I grant that this is entirely anecdotal, but I started working on this task because the latter issue was bugging me in-practice while I used VE (whereas the former hadn't actually come up for me) so it's the one I have more personal connection to. :D

> Is that like T56947?
Sort of. T56947 proposes basically exactly what @Pginer-WMF suggested -- a "you might want to update this" popup -- whereas @matmarex's suggestion is a more-aggressive version of that which forces the update unless you explicitly opt out.

I think it's basically the system proposed there, yeah. We don't currently have a convenient "suggest a change" system in context popups like this, but it's certainly addable if we want it. Making it keyboard-accessible as suggested would break the current paradigm, but it's not like context popups are //currently// keyboard-accessible anyway, so...
>>! In T55973#2792226, @matmarex wrote:
> Another idea (strawman): If a wikilink's target is identical to label, we could just synchronize the target with the label when the label is changed. In both the link context and the link inspector, there would be a "lock/unlock" button to toggle this behavior for the currently focused link.
> 
> I think this would eliminate the user errors of the kind we see now. On the other hand, it would make it somewhat annoying when you actually wanted to change the label (especially when writing in languages with rich inflexion).

Is that like T56947?
Another idea (strawman): If a wikilink's target is identical to label, we could just synchronize the target with the label when the label is changed. In both the link context and the link inspector, there would be a "lock/unlock" button to toggle this behavior for the currently focused link.

I think this would eliminate the user errors of the kind we see now. On the other hand, it would make it somewhat annoying when you actually wanted to change the label (especially when writing in languages with rich inflexion).
>>! In T55973#2789271, @matmarex wrote:
>> As I understand it, the main problem occurs when adding a link without any previous text selection.
> 
> I think the biggest problem here is in editing links.

Thanks for the illustrative examples, @matmarex.
This issue seems to happen when editing a link that uses the page title as label. This may bring expectations of such information to remain in sync when changing the link (or even not being aware of the target potentially being different from the textual representation).

I think those cases (where the label and page name matches) could be detected by VE and provide some support to quickly solve the out-of-sync status. For example, I illustrated below how we can surface that once the user changed the label, the link is pointing to the old page but that can be changed to point to a page that matches the new label. Clicking on the suggestion (or using keyboard down arrow to select it + enter) will update the link target without writing it twice.

{F4723857, size=full}


In the example above, having separate fields for editing label and target won't be very useful since we are not accessing the editing mode where those would be shown. It can be argued that making the edit label non-editable on the editing surface could force users to access the link editing panel, but that makes other scenarios more complex (e.g., quick label corrections, or using more complex content as link labels).
What matma said.
> As I understand it, the main problem occurs when adding a link without any previous text selection.

I think the biggest problem here is in editing links.

For example, a user is editing a sentence like `[[Tim Berners-Lee]] was born in [[1965]].` and wishes to correct the typo (he was actually born in 1955). Editing the visible text in VisualEditor without correcting the link target will result in `[[1965|1955]]`; editing the link target without correcting the text will result in `[[1955|1965]]`; both of these mistakes are easy to make in the current interface and difficult to spot when reviewing, if you're not looking at the wikitext source code.
I think it is important to separate the problem from possible solutions. As I understand it, the main problem occurs when adding a link without any previous text selection. In that context, the way to add a label has not much visibility. This generates confusion about where is the label supposed to be edited and makes it difficult workflows based on a different order than the one supported by default.

Provide a separate field for the link label as suggested above, makes label editing more explicit, but it is duplicating content that is already in the document which causes some different problems.

I was trying to explore a way to make the label editing more inviting right where it is going to be, without any duplication:

{F4716647}

When adding a link with no selection, instead of showing no content in the text, a placeholder element can be added in-place (styled similar to the link that it will become later) for the user to indicate the label, while a selector can be also available to pick the link target.

The content provided by the user in one field can inform the other (e.g., if I write "rice" as label, the Rice article should be among the suggestions when I click on the page search).

This is just a rough idea, but I'm curious to hear whether a solution along these lines is considered to help with the issue identified, or use it to identify which parts of the problem that I may be missing.
> How do you deal with something like `[[Parrot|{{lang|fr|perroquet}}]]`, where the label is built on a template?

Most likely we will just not support cases where the link contains non-text through this particular interface, but they aren't that common.
>>! In T55973#2777160, @Quiddity wrote:
>>>! In T55973#2775922, @Trizek-WMF wrote:
>> How do you deal with something like `[[Parrot|{{lang|fr|perroquet}}]]`, where the label is built on a template?
> 
> Is that a regular pattern somewhere? I don't think I've seen it used before, and am interested to see examples.

I've quick-searched on articles I've written and found that exemple [[https://fr.wikipedia.org/w/index.php?title=Mod%C3%A9lisme_ferroviaire&action=edit&section=33|here]]:  `''[[Gorre & Daphetid Railroad|{{lang|en|Gorre & Daphetid Railroad}}]]''` 

I've also searched (ctrl+F) on [[https://fr.wikipedia.org/w/index.php?title=Histoire%20du%20communisme&action=edit|Histoire du communisme]], the biggest article on fr.wp, where I've found:
* `[[groupe Barta|{{citation|groupe Barta}}]] ` or `[[De chacun selon ses moyens, à chacun selon ses besoins|{{citation|De chacun selon ses facultés, à chacun selon ses besoins}}]]`
* `[[Kang Kek Ieu|{{citation|Douch}}]]`

There is also cases like `[[1er octobre|{{1er}} octobre]]` or `[[18e congrès national du Parti communiste chinois|{{18e|congrès}} national]]`.

Some cases can be rewritten for sure, but not always.
>>! In T55973#2775922, @Trizek-WMF wrote:
> How do you deal with something like `[[Parrot|{{lang|fr|perroquet}}]]`, where the label is built on a template?

Is that a regular pattern somewhere? I don't think I've seen it used before, and am interested to see examples.
One reason to consider keeping the internal-labels is that they're easier to slip into the existing MW extension version of the link inspector, since that has to accommodate the wiki search results alongside the fields.
>>! In T55973#2769070, @Quiddity wrote:

> Losing occasional text-formatting is an acceptable compromise.

I've slept on that and now I agree.

>>! In T55973#2773796, @Esanders wrote:
> Inline labels:
> 
> {F4698802}
> 
> Google docs for comparison:
> 
> {F4698804}
> 
> I think focusing the link field first, and labelling it "link" instead of "target" (which is a bit technical) will help. We could also live-update the link as the text field is changed, which would avoid surprises when 'done' is clicked.

I think that's the best for a link made on a raw text.
How do you deal with something like `[[Parrot|{{lang|fr|perroquet}}]]`, where the label is built on a template?
Inline labels:

{F4698802}

Google docs for comparison:

{F4698804}

I think focusing the link field first, and labelling it "link" instead of "target" (which is a bit technical) will help. We could also live-update the link as the text field is changed, which would avoid surprises when 'done' is clicked.
> Use a 'placeholder' and insert an invisible label somewhere for accessibility.
Worth considering that the common-case here is (probably) editing an already-existing internal-wiki link. With a placeholder as the only distinction, that's going to look like this:

{F4693560}

...which is perhaps initially confusing.

Then the secondary case is editing an external link, where keeping the URL field as wide as possible is preferred, because URLs can get pretty long. The advantage of the internal label there is that it really is pretty space-efficient -- no added vertical size, and it's a compact horizontal representation.
>>! In T55973#2763929, @matmarex wrote:
> * Just use a FieldLayout :)
> * Use a 'placeholder' and insert an invisible label somewhere for accessibility.


* This would make the inspector much taller, which may or may not be acceptable.
* When editing the link both fields will be non-empty so the placeholder will never be seen.

Google Docs uses an inline label, which may severely reduce the width if we need to make room for all languages, but this should be considered too.
>>! In T55973#2768853, @Trizek-WMF wrote:
> And what if we only display a read-only text for the label?
> 
> Label: //2013//
> Target: 2014
> 
> That way, people will notice there is something wrong and will be able to correct the text afterwards, using the full potential of VE.

That would leave a primary use-case as very difficult - pasting or writing a complete replacement for the link label.

I.e. As an experienced wikitext editor, I'm accustomed to writing/pasting the link first, and then writing/pasting the label after a space or pipe. -- With VE, it is hard to select the entire label, in order to paste my clipboard on top, or in order to write it from scratch.

I really like the design given in T55973#2761021 above.
Losing occasional text-formatting is an acceptable compromise.
>>! In T55973#2768853, @Trizek-WMF wrote:
> And what if we only display a read-only text for the label?
> 
> Label: //2013//
> Target: 2014
> 
> That way, people will notice there is something wrong and will be able to correct the text afterwards, using the full potential of VE.

That would leave a primary use-case as very difficult - pasting or writing a complete replacement for the link label.

I.e. As an experienced wikitext editor, I'm accustomed to pasting the link first, and then writing the label after a space or pipe. -- With VE, it is hard to select the entire label, in order to paste my clipboard on top, or in order to write it from scratch.

I really like the design given in T55973#2761021 above.
Losing occasional text-formatting is an acceptable compromise.
>>! In T55973#2768853, @Trizek-WMF wrote:
> And what if we only display a read-only text for the label?
> 
> Label: //2013//
> Target: 2014
> 
> That way, people will notice there is something wrong and will be able to correct the text afterwards, using the full potential of VE.

This is another good option (I may have suggested it in the past).

ps Note that we will be able to handle the example you gave just fine because the annotation (italic) spans the whole link. A better example would be:

Label: Season //2014//
Target: Season 2014
And what if we only display a read-only text for the label?

Label: //2013//
Target: 2014

That way, people will notice there is something wrong and will be able to correct the text afterwards, using the full potential of VE.
I do agree that showing wikitext is the wrong way to go. This is a prime user-facing tool, which a majority of users are going to be interacting with regularly, not something far more power-usery like templates.

If we want to preserve the rare cases of internal formatting, we should go all out and have a VE surface inside the inspector... which I think makes it far too heavy for what's normally an incredibly quick action.

Technically, I suppose there's alternatives like diffing/merging the change to the label so that we keep the annotations if the section they cover wasn't touched. But that's a bunch more work on our end, and moves towards being too magic for the user to understand why the formatting sometimes stays and sometimes goes.
Also, as a volunteer, I don't want to hear "quotes on the text are making italics, that's a bug" from a newbie. That's a request for my personal comfort, Sherry ;)

>>! In T55973#2768788, @Esanders wrote:
> Showing wikitext is not the right thing to do. Links with *partial* formatting are very rare, and editing their text rarer. Even in those cases the user can just edit the text directly. If the user edits the label in this very rare case they will get immediate visual feedback of the change. Let's not make perfect the enemy of the good.

Wise words!
Showing wikitext is not the right thing to do. Links with *partial* formatting are very rare, and editing their text rarer. Even in those cases the user can just edit the text directly. If the user edits the label in this very rare case they will get immediate visual feedback of the change. Let's not make perfect the enemy of the good.
Rich display would be nicer (but take up a lot of space).  OTOH, given a link such as `[[Example|the ''blue'' picture]]`, I'd rather see 

```
the ''blue'' picture
Example
```

rather than 

```
the blue picture
Example
``` 

– especially when the second item will silently remove the italics if I touch it.
No wikitext displayed, please!
@DLynch, would it be easy enough to make it show wikitext rather than "plain text" (i.e., like the template dialog does for parameters)?  Having the internal annotations silently disappear might be annoying (for the very small percentage of links that contain internal annotations).
The patch currently behaves as:

* If there's any block-level content in the link (e.g. an image), it disables the label field. (Cue taken from Google Docs, which completely hides the field in this case.)
* If there's annotations on the content (bold, italic, etc), the field is enabled, and contains the plain text version. Making a change to its contents will remove all internal annotations from the link. (i.e. if it's in a block of bold text, it'll stay bold, but if part of the inside was bold, that'll be lost)
I'm glad this is being worked on.

>>! In T55973#2761021, @DLynch wrote:
> {F4685690}
> 
> (Prior to any Design feedback.)

Please don't use these weird right-side labels. TextInputWidget's 'label' option should never have been created. :/

Unless design folks invent something new, there are two options that would be consistent with existing interfaces:
* Just use a FieldLayout :)
* Use a 'placeholder' and insert an invisible label somewhere for accessibility.
>>! In T55973#2763892, @DLynch wrote:
> The other options I came up with are context item:
> {F4688837}
> (With attendant "we need to think up an icon that intuitively symbolizes 'select all'" dilemma, which nobody else seems to have really cracked. My favorite, after a bunch of searching, was [Blackberry's](https://help.blackberry.com/en/blackberry-leap/10.3.1/help/hjo1405445343190_hiresdevice_en-us.png))
> 
> Or inspector:
> {F4688838}

I'm pretty sure that people will not edit the label with that version. Edit label is not as obvious as it is on your first proposal with two separate fields.

Speaking of which, how do you deal with a label which includes some wikitext formatting, like bold or, worse, an in-line template?
The other options I came up with are context item:
{F4688837}
(With attendant "we need to think up an icon that intuitively symbolizes 'select all'" dilemma, which nobody else seems to have really cracked. My favorite, after a bunch of searching, was [Blackberry's](https://help.blackberry.com/en/blackberry-leap/10.3.1/help/hjo1405445343190_hiresdevice_en-us.png))

Or inspector:
{F4688838}
{F4685690}

(Prior to any Design feedback.)
Regular users have a really understand creating a mental model of how links work, especially when the label (nearly) matches the target. Having both side by side in the edit area makes it a lot clearer what is going on. More experienced users will be able to use the edit surface as designed.
To elaborate slightly, 303956,2 adds some protection in to make sure it won't replace the current label text if it hasn't been changed from its initial value, so even internal annotations will be preserved if you're only editing the target.
Moving from gerrit:

**James F:**
This creates a TextInputWidget which is just wrong; the contents covered by the link annotation could be anything up to and including <span>s, <img>s and so on; this would need to be a complete SurfaceWidget, which would totally dominate this inspector and destroy the whole design of it being a lightweight, simple control. I'm pretty strongly against this change for exactly this reason.

**David L:**
James: This is totally cribbing from Google Docs' design for link labels. It shows the field... if the label is simple. If it's not simple, it hides it. That lets us give people a field that works in most cases, and won't break anything otherwise.
Admittedly, I just have it *disabled* if it's not-simple, on the theory that might be less confusing, but I could go full-hidden.

**Ed S:**
That is technically true, however in almost all cases additional annotations to the link are covering, and can be preserved. This is the same behaviour as Google Docs. Links containing content (e.g. img) are many times rarer still. For these cases we can block/and or warn (or not).
To clarify the issue about "display text", both Google Docs and the patch above will maintain all covering annotations, but will remove any partial annotations if the text is edited (e.g. <a><b><i>He</i>llo</b></a> -> <a><b>Bye</b></a>). Also if the label contains any non-text (e.g. an inline image) it will be uneditable, but this is a very rare edge case.

This should also make the editing of external links and numbered external links a bit cleaner, getting rid of the 'add label' button for numbered external links.
Change 303956 had a related patch set uploaded (by DLynch):
LinkAnnotationInspector: add a "label" field

[[https://gerrit.wikimedia.org/r/303956]]
Off in T124305 there's a patch to make it easier to select the link-contents, which avoids many of the issues a "display text" field has (most notably: it's not just text). It's held up on general "what design do we want?" concerns.
It's now approaching two months since this was declined without adequate explanation and reopened pending that explanation. Please can we now have the reasoning (or a pointer to it) that led to the decline - this remains the biggest single hindrance to simple, intuitive use in my experience.
Sorry Jdforrester, I re-opened this task. I don't doubt that a lot of thinking went into this idea - but could you please provide a concise summary of the reasons you don't want to see this implemented? Again, I don't doubt that there are good reasons, I just don't see any and haven't seen a discussion anywhere. Thank you!
Thinking more about it, that you have had to have discussions about it in "dozens of places" (none of which are linked so we can verify this) suggests that actually there is a very strong desire for a two-box solution. 

WONTFIXing something that is so strongly desired by the editing community needs justification, particularly why two boxes would "mak[e] the user experience too heavy" - the only explanation actually given, and that was a musing two years ago. 

The only current way to be sure that both link target and link title are correct when editing is to delete what is currently there, write the title, select it, and then create a link. I am unable to correlate this with the goal of creating an editing interface that makes editing easy.