I'd like to third this question. 
In informal discussions of VE this is one of the most frequent issues brought up. Indeed I'm astounded that anyone could be "happy" at this decision.
I'd like to second this question. You could at the very least state the reason why you decline this, as from this feature request it's not clear at all why one would not add this little, extremely helpful textbox in the link widget.
I'd like to second this question. You could at the very least state the reason why you decline this, as from this feature request it's not clear at all why one would not add this little, extremely helpful textbox in the link menu.
>>! In T55973#2052851, @Jdforrester-WMF wrote:
> With the benefit of four years' discussion in dozens of places, I'm now happy to conclude that this is indeed Declined.

Because of...?
With the benefit of four years' discussion in dozens of places, I'm now happy to conclude that this is indeed Declined.
[[ https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:%C3%89diteurVisuel/Avis#Am.C3.A9lioration_de_l.27insertion_de_lien | New feedback concerning the separate input fields ]]. I also strongly support this idea.
Changing a wikilink to an external link is not so smart, because text in the External links tab is not automatically selected, and therefore needs to be selected before being replaced by typing or pasting.
@Whatamidoing-WMF Works with Chromium, but not on Firefox (38.0 canonical 1.0 for Ubuntu).
@Trizek-WMF:  It's supposed to automagically switch to the External links tab if you type "http://" at the start.  Is the automatic detection not working for you?
I've made some edits yesterday evening with VE in order to add an external link. Here is what I did: 

  # select the text
  # click on the link icon
  # type my URL in the field
  # click on "Done" button
  # See a red link
  # Realize there is a special tab for external links
  # Start again...

The same happens to me quite all the time. :/
Copy Google Docs solution?

To elaborate, I don't think that labelling this solution as "ugly" is a strong rationale to why it shouldn't actually work for us. I'm fairly sure there must be a fair amount of research behind something that Google came up with for millions of people, and editors are constantly confused by our current interface instead.
Copy Google Docs solution?
*** Bug 51438 has been marked as a duplicate of this bug. ***
This is not a WONTFIX, but it comes close in terms of making the user experience too heavy (for detailed reasoning, see endless bugs passim).
<< Currently when you click on a template with the "VTE" (view, talk page, edit) links, Visual Editor gives you the option of adding parameters to the transclusion of the template. Most of the templates with the "VTE" links are navigational boxes or other transcluded items without parameters, but as the VTE links suggest, we want people to easily view the template page itself. Maybe if someone clicks on a template with VTE links in Visual Editor, rather than being given the regular option to add parameters they should instead be given a dialogue box saying something along the lines of "This is a template that appears on many pages. Would you like to open this template's page in a new tab?". —[[User:Arctic.gnome|Arctic Gnome]] <small>([[User talk:Arctic.gnome|talk]] • [[Special:Contributions/Arctic.gnome|contribs]])</small> 13:45, 20 August 2013 (UTC) >>

--------------------------
**Version**: unspecified
**Severity**: enhancement
Bug 49772 - VisualEditor: Transclusion dialogs panes should include a link to the template's definition page (for further documentation) 
looks relevant. 

The V.T.E links are a specific of the way things are organised on en.wikipedia See for example the nav box template at the bottom of 
http://en.wikipedia.org/wiki/When_an_Old_Cricketer_Leaves_the_Crease

I suspect bug 49772 will be a more general solution.
--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51527
This was re-filed as bug 56205 and fixed in October.

*** This bug has been marked as a duplicate of bug 56205 ***
With the VE being enabled in Help, File & Category pages, this message is now incorrect on en.wp (and others?) too.
(In reply to comment #1)
> Do you mean 
> https://www.mediawiki.org/wiki/Manual:$wgContentNamespaces

Presumably.

> Is VE enabled in other content namespaces?

Only on MediaWiki.org and the test wikis (where the alpha opt-in preference is not shown). Everywhere else, it's just NS0 (articles) and NS2 (user pages).
Do you mean 
https://www.mediawiki.org/wiki/Manual:$wgContentNamespaces
Is VE enabled in other content namespaces?
**Author:** `jonathan_haas`

**Description:**
It's currently impossible to change table cell background VE

See for example http://de.wikipedia.org/wiki/Suriyakati-Kalender

**See also**
* Open subtasks of {T49780}
>>! In T54180#2169644, @Whatamidoing-WMF wrote:
> If random color should not be "doable" on the grounds that there's no reasonable use case for it, then James F wouldn't have recommended using "random color" in this edit:  https://www.mediawiki.org/w/index.php?diff=1647707&oldid=1647704  But he did, and therefore there is a reasonable use case to be made for having that ability.

Please re-read my comment, where I accepted highlighting, as in a table, as a valid use case. But I'm also going to point out that the same information can and should be conveyed by a class, so that we can better enforce accessibility, if no other reason.

See also {T37704} and {T89134}.
>>! In T54180#2169644, @Whatamidoing-WMF wrote:
> If random color should not be "doable" on the grounds that there's no reasonable use case for it, then James F wouldn't have recommended using "random color" in this edit:  https://www.mediawiki.org/w/index.php?diff=1647707&oldid=1647704  But he did, and therefore there is a reasonable use case to be made for having that ability.

Please re-read my comment, where I accepted highlighting, as in a table, as a valid use case. But I'm also going to point out that the same information can and should be conveyed by a class.

See also {T37704} and {T89134}.
>>! In T54180#2169644, @Whatamidoing-WMF wrote:
> If random color should not be "doable" on the grounds that there's no reasonable use case for it, then James F wouldn't have recommended using "random color" in this edit:  https://www.mediawiki.org/w/index.php?diff=1647707&oldid=1647704  But he did, and therefore there is a reasonable use case to be made for having that ability.

Please re-read my comment, where I accepted highlighting, as in a table, as a valid use case. But I'm also going to point out that the same information can and should be conveyed by a class.

See also T37704.
>>! In T54180#2169644, @Whatamidoing-WMF wrote:
> If random color should not be "doable" on the grounds that there's no reasonable use case for it, then James F wouldn't have recommended using "random color" in this edit:  https://www.mediawiki.org/w/index.php?diff=1647707&oldid=1647704  But he did, and therefore there is a reasonable use case to be made for having that ability.

Please re-read my comment, where I accepted highlighting, as in a table, as a valid use case. But I'm also going to point out that the same information can and should be conveyed by a class. See also T37704.
If random color should not be "doable" on the grounds that there's no reasonable use case for it, then James F wouldn't have recommended using "random color" in this edit:  https://www.mediawiki.org/w/index.php?diff=1647707&oldid=1647704  But he did, and therefore there is a reasonable use case to be made for having that ability.
>>! In T54180#969564, @Juandev wrote:
>>>! In T54180#966351, @Jdforrester-WMF wrote:
>> There's a strong use case to //not// let this be something people do. The colour in your example adds almost no value but massively distracts from the readability, accessibility and utility of the information being conveyed.
> 
> Probably strong case not to use it in Wikipedia, but what about Wikiversity. You may need to highlight cells just to be more atractive for the students or to be able to count someting better. I thing advanced MS Excell of Google Tabs already allow to search by table cell bg color.

This looks like a (really) strong use case for a class to be applied to a row/cell, //not// random style, if in fact "highlighting" is being used in multiple places.

I would tend to agree that random color should not be "doable" in VE, while permitting the addition of classes may be valuable (especially .wikitable if no others).
>>! In T54180#966571, @Krinkle wrote:
> Note that standardised styles (by the software or by local wikis) for tables can be developed and provided through program code (instead of through article content) by declaring them in CSS stylesheets (such as `MediaWiki:Common.css`).
> 
> I'd say it'd be an improvement if VisualEditor has an interface that can apply certain css classes to a table. Especially ones provided by MediaWiki core, such as `wikitable`, `sortable`, and `mw-collapsible`. (Though ideally through an intuitive interface, and not a free-form text field; which requires users to know internal software class names.)
> 
> ...

Agreed. One of the most common "deviations" made to table element defaults is changing the `vertical-align` of all (or nearly all) of the table cells in a table to render //top// rather than default //middle//.

Most folks assume this requires changing the default `vertical-align` value per every TR or per each TD within a table but the default is actually ''inherit'' for these elements - set by tbody, thead or tfoot which actually has the `vertical-align:middle` setting.

Understanding the tbody element is not 'shown but always present' we can still simplify the table rendering of cell content throughout an entire table by making a simple .css addition to the default stylesheets such as...

``` lang="css"
.valign-td-top > tbody {
	vertical-align: top;
}
```
... in turn, setting `table class="valign-td-top"` is all the user needs to add (either manually or by design in a VE table option) to accomplish top rendering of content.

Worst case scenario is the user needs to [re]adjust the TH header row's vertical-alignment back to middle - far less work than applying inline styling to each TR or every TD as is the case now.
>>! In T54180#971085, @Whatamidoing-WMF wrote:
> I wonder if it could be a feature that is configurable per-wiki, or ideally per-namespace at each wiki.  Then you could get (for example) teaching materials at WIkiversity that use it, but keep it out of the article namespace at the English Wikipedia.  (It would still need to accept copied/pasted tables, and maybe have a 'remove this background color' button—which we need anyway, because of tables copied from other websites.)

So should I understand your statment like we need community consensus for that?
So the option per wiki is the best choise I guess. Namespaces are not standardized yet on some wv projcects.
I wonder if it could be a feature that is configurable per-wiki, or ideally per-namespace at each wiki.  Then you could get (for example) teaching materials at WIkiversity that use it, but keep it out of the article namespace at the English Wikipedia.  (It would still need to accept copied/pasted tables, and maybe have a 'remove this background color' button—which we need anyway, because of tables copied from other websites.)
>>! In T54180#966351, @Jdforrester-WMF wrote:
> There's a strong use case to //not// let this be something people do. The colour in your example adds almost no value but massively distracts from the readability, accessibility and utility of the information being conveyed.

Probably strong case not to use it in Wikipedia, but what about Wikiversity. You may need to highlight cells just to be more atractive for the students or to be able to count someting better. I thing advanced MS Excell of Google Tabs already allow to search by table cell bg color.
> The colour...distracts from the readability, accessibility and utility of the information being conveyed.

Making it possible and even moderately easy to render this image in a table instead of in an image would IMO be a significant improvement in the readability, accessibility and utility of the information.  For example, someone with a screen reader could actually read it, and anyone could edit the contents.

I'm not looking for fruit salad in encyclopedia articles, but when someone wants to create a table like this, I want them to think "Oooh, I can do that in VisualEditor", not "I'll draw this in Adobe Illustrator, export it as a jpeg, upload it to Commons, insert it on a page in mediawiki.org, and every time someone needs to have a simple typo fixed, I'll repeat that process."
> The colour...distracts from the readability, accessibility and utility of
the information being conveyed.

Making it possible and even moderately easy to render this image in a table
instead of in an image would IMO be a significant improvement in the
readability, accessibility and utility of the information.  For example,
someone with a screen reader could actually read it, and anyone could edit
the contents.

I'm not looking for fruit salad in encyclopedia articles, but when someone
wants to create a table like this, I want them to think "Oooh, I can do
that in VisualEditor", not "I'll draw this in Adobe Illustrator, export it
as a jpeg, upload it to Commons, insert it on a page in mediawiki.org, and
every time someone needs to have a simple typo fixed, I'll repeat that
process."





Whatamidoing (WMF)/Sherry Snyder
Community Liaison
Wikimedia Foundation, Inc.
Note that standardised styles (by the software or by local wikis) for tables can be developed and provided through program code (instead of through article content) by declaring them in CSS stylesheets (such as `MediaWiki:Common.css`).

I'd say it'd be an improvement if VisualEditor has an interface that can apply certain css classes to a table. Especially ones provided by MediaWiki core, such as `wikitable`, `sortable`, and `mw-collapsible`. (Though ideally through an intuitive interface, and not a free-form text field; which requires users to know internal software class names.)

And potentially a few other class-name / label combinations provided by the local wiki. There's definitely a use case for having more than one type of table for all of Wikipedia.
Note that standardised styles (by the software or by local wikis) for tables can be developed and provided through program code (instead of through article content) by declaring them in CSS stylesheets (such as `MediaWiki:Common.css`).

I'd say it'd be an improvement if VisualEditor has an interface that can apply certain css classes to a table. Especially ones provided by MediaWiki core, such as `wikitable`, `sortable` and `mw-collapsible` (though ideally through an intuitive interface, and not a free-form text field (which requires users to know internal software class names).

And potentially a few other class-name / label combinations provided by the local wiki. There's definitely a use case for having more than one type of table for all of Wikipedia.
There's a strong use case to //not// let this be something people do. The colour in your example adds almost no value but massively distracts from the readability, accessibility and utility of the information being conveyed.
In terms of the scope for this item:  I'd like (Howie) to be able to create this table in VisualEditor:  https://www.mediawiki.org/wiki/File:Product_stages_and_players.jpg

I'm not entirely sure how to do it in wikitext, but that's what I want to be able to do.
This issue of table cell paragraph formatting is now Bug 65416.
(In reply to WhatamIdoing from comment #1)
> "Other formatting" should include support for font size and line height, so
> that tables like the ones seen at
> https://en.wikipedia.org/w/index.php?oldid=608813235#Early_years will
> display with the correct row height.

No, that's a bug caused by VE assuming that table cells' paragraphs should be styled like other paragraphs. That's a fix to styling rules, nothing to do with editing them to have custom styles. Could you file a new bug?
"Other formatting" should include support for font size and line height, so that tables like the ones seen at https://en.wikipedia.org/w/index.php?oldid=608813235#Early_years will display with the correct row height.
Links are frequently placed in edit summaries but the user is currently perversely required to revert to wikicode to insert them.  The VisEd menu should be available for the edit summary and the text should be displayed as it will be seen.  Wysiwyg should apply to all elements of the edit summary (eg, the recently added section title is displayed as code rather than the grey italics as it will be seen).

=== Potential use cases/impacts/hypotheses 
- **[potential impact]**: if people publishing edits write more expressive edit summaries, these edit summaries will be compelling/interesting to people whose primarily relationship to Wikipedia is as as a reader
-- //See more in {T379405}
- **[potential use case]**: enable people to relate edits to the events/campaigns that inspired them to make them (T373232)
-- //Inspired @AlexHollender-WMF and @ifried...//
- **[hypothesis]** If people have an easier time doing things like mentioning other people, inserting links, and formatting text within the edit summary input, they will invest more effort into writing edit summaries.
- **[potential impact]** If people write more descriptive edit summaries, then machine learning models will become more effecting at learning from the actions volunteers are taking because these models will have to make fewer inferences/assumptions about the semantic meaning of a change/changes someone is making. //This thought is inspired by the conversation we (the Editing Team) had with @diego on 27 July 2022.//
- **[potential impact]** If people write more descriptive edit summaries, then people visiting an article's "page history"  will have an easier time: A) understanding how the article they are interested in evolved over time and B) identifying changes they are curious to learn more about
-- this could also open up the potential for edits/diffs being presented as small, standalone pieces of information people could "consume" 

=== Related
- T123529
- T323875
- https://hashtags.wmcloud.org/
Re-purposing this to flesh out bug 42139 comment 1.
Dupe of bug 42139 (specifically bug 42139 comment 1)?
There are many pages for which VisualEditor is broken.  In some cases, the page syntax can be changed to avoid the problem.  In other cases (such as nlwp's largethumb, dewp dab pages, enwp episode lists), the design affects many pages, and the only feasible solution is to fix the parser.  While we wait for fixes, the VE should be disabled on those pages known to be affected.

The set of pages to be VE-disabled could be a category, if you trust the villagers..:-)
Or a page title blacklist in MediaWiki: namespace so it is admin only
Or a page content regex blacklist in MediaWiki: namespace so it is easier to blacklist all pages which include a certain element.

**See Also**: {T55767} (also declined)
>>! In T54141#1568572, @Neil_P._Quinn_WMF wrote:
> @Kipod, whether it's easy or hard it not really the main issue. The main issue is whether the benefits outweigh the downsides—and unfortunately there //are// downsides. These magic words would increase complexity, sometimes stay on pages long after the need is gone, and risk confusing users when no visual editor tab appears on a page where they expect to see it.
> 
> Today, the visual editor corrupts pages //far// less often than it did when this bug was filed two years ago, which makes me think that the benefits of these magic words would be small. Are there other reasons for having them?

Has Paroid been round-trip tested against Wikisource pages in the main & Page: namespace?
I am guessing there will be a new batch of page corruptions on Wikisource when it is deployed for the Page: namespace, if there has not been specific testing for the Page: namespace. Wikisource has some very odd hacks. Many thanks if this testing has already been done and there are no serious problems when it is deployed.

An alternative would be for wikisource to add an editnotice, which is only shown for VE editors, for pages which have problems with VE. Then it can be more advisory:

"this page may have problems with VE; please check the diff after saving changes. Report bugs at <x> ; if there are no bugs, remove this editnotice by <do y>."
>>! In T54141#1568572, @Neil_P._Quinn_WMF wrote:
> Today, the visual editor corrupts pages //far// less often than it did when this bug was filed two years ago, which makes me think that the benefits of these magic words would be small. Are there other reasons for having them?

The primary benefit I see is that I'd like to enable VE on pages where it will not be enabled globally.
@Kipod, whether it's easy or hard it not really the main issue. The main issue is whether the benefits outweigh the downsides—and unfortunately there //are// downsides. These magic words would increase complexity, sometimes stay on pages long after the need is gone, and risk confusing users when no visual editor tab appears on a page where they expect to see it.

Today, the visual editor corrupts pages //far// less often than it did when this bug was filed two years ago, which makes me think that the benefits of these magic words would be small. Are there other reasons for having them?

>this should override the namespace default, but _not_ the user personal choice (i.e., if the user elects to disable VE. 
That only works for people who turn off the visual editor completely. If you disable the visual editor on a given page, I can no longer choose to use it. 

Peace to you as well :)
i see this is "closed, declined".
since another ticket, opened by me, was "closed, duplicate" pointing here, i would like to request to reconsider.
implementing my request should be very easy, controllable, requres no changes outside VE, and very simple change inside VE, and, oh, by the way, will also close/solve this one. so i paraphrase my previous request here:


there are good reasons (i guess) not to enable VE on some namespaces, and specifically "project" namespace, but it would be desirable to be able to override it for specific pages.
 
i was thinking something like adding two new magic words:


```
__ENABLE_VISUAL_EDITOR__
__DISABLE_VISUAL_EDITOR__
```
this should override the namespace default, but _not_ the user personal choice (i.e., if the user elects to disable VE.

implementing these two switches is 100% risk-free (currently there are no pages that use these magic words), and should be easy enough to implement, such that the switch that decides wheter or not to enable VE will test for these magic words, and make the correct decisiosn.

so, implementing it would be risk-free, easy, and will soleve at least two legitimate requests that came from the community (with some 19 members subscribing to this ticket).

maybe you should consider reopening. unfortunately i can't offer a patch to prove my claim that it's  "easy"...


peace.
i see this is "closed, declined".
since another ticket, opened by me, was "closed, duplicate" pointing here, i would like to request to reconsider.
implementing my request should be very easy, controllable, requres no changes outside VE, and very simple change inside VE, and, oh, by the way, will also close/solve this one. so i paraphrase my previous request here:


there are good reasons (i guess) not to enable VE on some namespaces, and specifically "project" namespace, but it would be desirable to be able to override it for specific pages.
 
i was thinking something like


```
__ENABLE_VISUAL_EDITOR__
__DISABLE_VISUAL_EDITOR__
```
this should override the namespace default, but _not_ the user personal choice (i.e., if the user elects to disable VE.

implementing these two switches is 100% risk-free (currently there are no pages that use these magic words), and should be easy enough to implement, such that the switch that decides wheter or not to enable VE will test for these magic words, and make the correct decisiosn.

so, implementing it would be risk-free, easy, and will soleve at least two legitimate requests that came from the community (with some 19 members subscribing to this ticket).

maybe you should consider reopening. unfortunately i can't offer a patch to prove my claim that it's  "easy"...


peace.
i see this is "closed, declined".
since another ticket, opened by me, was "closed, duplicate" pointing here, i would like to request to reconsider.
implementing my request should be very easy, controllable, requres no changes outside VE, and very simple change inside VE, and, oh, by the way, will also close/solve this one. so i paraphrase my previous request here:


there are good reasons (i guess) not to enable VE on some namespaces, and specifically "project" namespace, but it would be desirable to be able to override it for specific pages.
 
i was thinking something like

__ENABLE_VISUAL_EDITOR__
__DISABLE_VISUAL_EDITOR__
this should override the namespace default, but _not_ the user personal choice (i.e., if the user elects to disable VE.

implementing these two switches is 100% risk-free (currently there are no pages that use these magic words), and should be easy enough to implement, such that the switch that decides wheter or not to enable VE will test for these magic words, and make the correct decisiosn.

so, implementing it would be risk-free, easy, and will soleve at least two legitimate requests that came from the community (with some 19 members subscribing to this ticket).

maybe you should consider reopening. unfortunately i can't offer a patch to prove my claim that it's  "easy"...


peace.
Hello, @Jdforrester-WMF. You merged T107426 here, but it is not the same problem. The main part over there was an ability to ENABLE the VisualEditor on a page in VE-disabled namespace. Thank you.
Agreed.
>>! In T54141#1312318, @ssastry wrote:
> Yes, the largethumb template issue has been fixed since early 2014.
> 
> The only large-scale corruptions that have been reported have been due to transient bugs on deploys (which tend to be fixed quickly or deploys reverted). There are some pages on which Parsoid could potentially cause corruptions, but those one-off bugs tend to get fixed promptly. There are no large sets of pages that I am aware of that aren't handled properly on the Parsoid end. So, as far as I know, from the Parsoid perspective, this workaround shouldn't be needed.

@Jdforrester-WMF, what do you think about declining this bug?
Yes, the largethumb template issue has been fixed since early 2014.

The only large-scale corruptions that have been reported have been due to transient bugs on deploys (which tend to be fixed quickly or deploys reverted). There are some pages on which Parsoid could potentially cause corruptions, but those one-off bugs tend to get fixed promptly. There are no large sets of pages that I am aware of that aren't handled properly on the Parsoid end. So, as far as I know, from the Parsoid perspective, this workaround shouldn't be needed.
I'm pretty certain that the largethumb template issue has been fixed, and based on the lack of activity and concrete reports of ongoing large-scale corruptions it seems possible that the work-around described in this task might no longer be needed. @ssastry and @jdforrester-wmf: Could you chime in?
This is an old task, so it would be good to get some specificity around whether this is still an issue and under which circumstances. Can someone please re-validate this issue?
An interesting solution is to add a wikitext magic word `__NOVISUALEDITOR__` to disable it in contexts it might otherwise be enabled.

https://www.mediawiki.org/wiki/Thread:Extension_talk:VisualEditor/Behavior_switch_NOVISUALEDITOR
An interesting solution is to add a wikitext magic word __NOVISUALEDITOR__ to disable it in contexts it might otherwise be enabled.

https://www.mediawiki.org/wiki/Thread:Extension_talk:VisualEditor/Behavior_switch_NOVISUALEDITOR
(In reply to comment #6)
> Obviously VE/Parsoid shouldn't cause breakage - the goal would be to keep
> membership of that category close to zero at any given time. But if and when
> things do break, it'd be good to have an official mechanism to deal with it,
> rather than just template hacks.

Bugzilla is the official mechanism for dealing with breakages.

While it's easy to say that the goal would be to keep the category membership near zero, it sounds like (from reading comment 0) that this category would quickly include tens of thousands of pages.
Obviously VE/Parsoid shouldn't cause breakage - the goal would be to keep membership of that category close to zero at any given time. But if and when things do break, it'd be good to have an official mechanism to deal with it, rather than just template hacks.
I don't like the idea presented in bug 52489 (a blacklist category). VisualEditor simply shouldn't break pages ever. Users shouldn't be required to shield articles from it; that's a bit insane.
It would indeed be helpful to be able to selectively disable VisualEditor (we should indicate to a user who'd otherwise see VisualEditor that it is disabled, to reduce confusion).

A hidden blacklist category could be included in a page or template to achieve
the desired effect, and could be used by developers to prioritize roundtripping
issues.
*** Bug 52489 has been marked as a duplicate of this bug. ***
If WMF has spare compute power, Parsoid could flag which pages it _may_ break, and tell the VE extension to not enable itself on those pages.
A temporary solution is being developed: {{Disable VE top}} and {{Disable VE bottom}}

https://en.wikipedia.org/wiki/Template:Disable_VE_top
The Visual Mode editor of Wikia is able to check all the available parameters automatically without the need for editors to edit the TemplateData for each template manually which is unrealistic to be done for over 505k templates on English Wikipedia.
However, Wikia's template editor has a severe flaw that it cannot handle a template to be included inside another template. The visual editor will deem the coding to be too complex and forcibly switch back to source mode editor.

--------------------------
**See Also**:
T54581 / {T191756}
>>! In T54135#2501906, @Whatamidoing-WMF wrote:
> The GUI for TemplateData can detect (or attempt to detect) parameters now.  I wonder whether that could be 'borrowed' by the template tool?

It's not perfect, and in the GUI there is manual review involved before publication. However, from a user perspective, the only side-effect of the detection is suggestion of parameter names. Not anything beyond that. That's fairly harmless.

If we're ready to try and make this kind of detection available to users without review, then I propose to do this in the TemplateData API instead of in VisualEditor.

That way it will benefit all users of the data, not just VE. And it will keep the logic in the same repository. When VisualEditor fetches it from the API will automatically respond with either the authored data, or fallback to auto-detection for parameter keys.
>>! In T54135#2501906, @Whatamidoing-WMF wrote:
> The GUI for TemplateData can detect (or attempt to detect) parameters now.  I wonder whether that could be 'borrowed' by the template tool?

It's not perfect, and in the GUI there is manual review involved before publication. However, from a user perspective, the only side-effect of the detection is suggestion of parameter names. Not anything beyond that. That's fairly harmless.

If we're ready to try and make this kind of detection available to users without review, then I propose to do this in the TemplateData API instead of in VisualEditor.

That way it will benefit all users of the data, not just VE. And it will keep the logic in the same repository. When VisualEditor fetches it from the API which will automatically respond with either the authored data, or fallback to auto-detection for parameter keys.
The GUI for TemplateData can detect (or attempt to detect) parameters now.  I wonder whether that could be 'borrowed' by the template tool?
*** Bug 70228 has been marked as a duplicate of this bug. ***
(In reply to comment #2)
> This is something we're unlikely to get to do soon, as it would require a
> vast
> amount of work (and, indeed, Strong AI to do properly). However, it would be
> a
> great improvement, yes.

Indeed. It would help the newbies - not to push them to look for template page and/or template documentation and fill it slow, piece by piece. It is than much faster to add it copy&paste in wiki code, than use VE.
(In reply to comment #6)
> (In reply to comment #5)
> > Kipod do you have a direct link to templatewizard as I've like to link to it?
> 
> See bug 52581 comment 4

Or even
https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)/Archive_103#Template_Parameter_Wizard
mentioned on bug 39598 comment 1.
(In reply to comment #5)
> Kipod do you have a direct link to templatewizard as I've like to link to it?

See bug 52581 comment 4

The transclusion UI currently requires thousands of hours to implement on each and every wiki.  This is an enormous design problem that especially impacts small wikis without thousands of minions who have nothing better to do but create templatedata, so I've added this as a blocker for non-English Wikipedia (bug 51792).
It is dead easy all you need to do is scan for {{{1}}}, {{{name}}}, {{{1| {{{name| etc. I've implemented this at
http://en.wikipedia.org/wiki/User:Salix_alba/TDSkell
and there are a few other implementations about. 

Kipod do you have a direct link to templatewizard as I've like to link to it?

There are 300,000 templates on the English wikipedia so many will never have their TemplateData written making this an important enhancement. 

A slightly enhanced version of this request was asked at 

http://en.wikipedia.org/w/index.php?title=Wikipedia_talk%3AVisualEditor&diff=574762591&oldid=573484823

in addition to just getting the names it wanted to find the "mandatory" parameters, a much harder job.
Kipod's Template Parameter Wizard is exactly the thing I'm looking for. At least it works in Wikitext mode nicely.
templatewizard on hewiki implements this logic using 9 lines on JS, (so PHP  should probably be able to accomplish that with no more than 50 lines). might not be perfect, but it works for a long time now, and i did not get any bug report yet.

peace.
This is something we're unlikely to get to do soon, as it would require a vast amount of work (and, indeed, Strong AI to do properly). However, it would be a great improvement, yes.
i added a "see also" to bug 52581.

the idea is not to change anything with VE itself, but rather to teach teh TemplateData extension to return a "cookie cutter" templatedata through the API if it does not find "templatedata" tag on the template page.

this way, all existing functionality, with all the neat thing one can do with templatedata will still work, and still, VE will be usable for template editing even without it.

also, i think that programmatically, the right place to handle the issue is in the templatedata extension and not in VE itself (in addition to being cleaner and shorter code, there might be other scripts and tools that want to use the templatedata API. even if these were not a consideration, the templatedata extension is the right place to deal with templatedata shortcomings).


peace.
The editor an en.wp who signs as "Josh, linguist" has left the following suggestion about toolbar placement in the Visual Editor:

"I've encountered a sort of inconvenience which is the following: while editing, the toolbar occupies a significant area in the upper third visually and otherwise blocking the text, when we, at the same time, usually have an unoccupied area to the left (where the navigation column is which is often empty much below the existing items); the question is why not to devise a possibility, an option to change its place — I mean the toolbar could be opted to place it either where it's offered to be now – or, otherwise, on the left side of the pane – where it should not be blocking an essential area of the text to edit, in this case the text available without scrolling will be by, approximately (depending on your zoom), a half more than it is now."

For RTL wikis read "right" instead of "left".

--------------------------
**Version**: unspecified
**Severity**: enhancement
In that case, though, we'd only really have room for six toolbar options and then "…", which I'm not sure is much better. :-(
Hmm, interesting idea. Lack of vertical space is especially a problem when using an on-screen keyboard, like on a tablet.

{F56237}
This is an interesting idea, and one worth exploring; right now, the team are focussed on squashing bugs, performance fixes, and core usability experience improvements, so I'm marking this as "Lowest" priority for now to avoid cookie-licking.
one thing that makes life better with existing editor is the fact that when editing a specific section, the section name is automatically added to the edit summary. often, this ends up being the entire edit summary.

REQUESTED ACTION
1) when hitting "save", test to see if all the diffs are contained in a single section, and if so, add the section name to the edit summary automatically.
2) just like with existing editor, allow the user to modify or remove this part. i.e., the request is to pre-populate the summary box, not to add section name outside of summary box such that the user can't touch it.

peace.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**: T54859, T50274, T52872, T60488
>>! In T53903#959238, @matmarex wrote:
>> The scope of the bug is bigger than that?
>  
> Yes:
>  
> - When the user edits text in other sections too, this hint shouldn't appear.
> - When the user opens VE using the "Edit" tab at the top and only edits one section, the appropriate hint should appear.

what he said.
with VE, the "edit" links to the right (or left, in rtl wikis) of the section title are misleading: unlike wikieditor, where clicking one of those will limit the changes to this section, with VE there no such limitation. 

IMO, the current VE behavior is wrong and misleading (T60488 agrees with this view). when looking at page history, i don't care which thingy the editor clicked to start the editor - i want to know which changes this edit contains.
if you do not _know_ that the changes are limited to some section, please don't tell me they are. (and, on the other hand, if you _do_ know such a thing, it would be nice if you told me).

peace.
> The scope of the bug is bigger than that?
 
Yes:
 
- When the user edits text in other sections too, this hint shouldn't appear.
- When the user opens VE using the "Edit" tab at the top and only edits one section, the appropriate hint should appear.
Curret behavior in production:

- click on Edit on a section on a page
- make changes to that section - click Save
- Save dialog box - 'Edit summary' box will pre-populated with the title of a section that was edited: 
/* Section 3 */ 
- 'Review your changes' will have an additional pointer to the section that was edited:
Preview of edit summary:
(→‎Section 3: )

The scope of the bug is bigger than that?
(In reply to Elitre from comment #8)
> Isn't this the current behavior (for various meanings of "section editing")?

No. This is asking for VE-MW to insert the name of the section edited if only one section was edited, even if the editor was launched from a page-level link. Doing it when the user clicks a section edit link was bug 50872 and is indeed done. Not doing it when the user clicks a section edit link and then edits outside the link is bug 58488.
Isn't this the current behavior (for various meanings of "section editing")?
*** Bug 56891 has been marked as a duplicate of this bug. ***
(Thanks Matthew!)
(In reply to comment #4)
> 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.

Yes, in theory, but in my opinion, that's a separate bug.  Filed as bug 52859.
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.
You're right, this isn't a duplicate; I'm re-opening and titling it to be clearer.
**ignatzmice.wiki** wrote:

I agree with kipod's comments at bug 50872, this bug is not a duplicate if that one. This would be a very useful feature (if rather resource-intensive).
*** This bug has been marked as a duplicate of bug 50872 ***
Bulk unassigning bugs from Ori.
[mass-moving from Tools>MediaWiki-Vagrant to separate product. See bug 54041. Filter bugmail on this comment.]
See also https://www.heroku.com/

Juan,  I'll like what you're doing.  Emailing you.
**jtreminio** wrote:

Hi there, creator of PuPHPet here.

We're actually actively working on providing ready-made quick-start configurations for some popular projects.

Right now we have it done for Symfony2 (https://puphpet.com/quickstart/symfony) and for PuPHPet itself (https://puphpet.com/quickstart/puphpet).

If I could be given your exact requirements I could easily whip something up for you :)
The "clear formatting" button returns bold and italic text to its plain state, as expected. However it also removes any links in the selection, which is not expected, rather there should be a separate "unlink" button to do this job - conceptually I regard a link as an attribute not as formatting.

For example selecting a bolded sentence with an italicised title and a linked word in it. I clicked the clear formatting intending to clear the bold and italic, which it did but it also removed the link. Similarly if using it to remove a link it also removes bold/italic which is unlikely to be the intention.
*** Bug 70739 has been marked as a duplicate of this bug. ***
*** Bug 59191 has been marked as a duplicate of this bug. ***
(In reply to comment #3)
Also, removing a link takes three clicks if you don't use 'clear
> formatting'.
Which is why I said there should be a separate button to remove links with a single click.
 
> 'Clear markup' would be more descriptive, but probably less user-friendly.
"Clear markup" doesn't describe what it does either, because it doesn't remove paragraph style, text size, templates, colour, etc. It only removes text formatting and links.

My point is that bold and italic, etc. are a subset of formatting, but links aren't. I want the ability to remove formatting without removing links, and the ability to remove links without removing formatting.
I agree that links are fundamental to Wikipedia (and other wikis).  However, I think it is quite reasonable that 'clear formatting' removes links.  If you want to remove something in particular, you can use the individual buttons (click bold to unbold, etc.) in most cases.

Part of this is that I've already become used to using 'clear formatting' for links in VE.  But I don't think this seemed unintutive even when I started using VE.  Also, removing a link takes three clicks if you don't use 'clear formatting'.

'Clear markup' would be more descriptive, but probably less user-friendly.
Well "superscript/subscript/underline/strikethrough/big/small/code
formatting and <span>s setting arbitrary formatting annotations (like "color:
red;" or "font-family: serif;" are all just different sorts of text decoration formatting like bold and italic so the clear formatting button is appropriate for all of them.

"language settings (lang=fr and dir=rtl)" are not in my mind the same thing as bold, strikethrough, etc, but equally they're not the same thing as links. I haven't thought about them before now and I at this point I just don't know what my opinion is and I don't really know what the arguments for an against are, so more thinking needed before I can you a proper answer for those, sorry.

I think possibly the difference in our opinions about links is that you are approaching this from a "make it like a popular word processor that can edit Wikipedia" whereas I'm thinking of it from "make it an editor for Wikipedia that works like word processors". There might not sound much different in those philosophies, and in most cases I don't think there is. However from a word processing POV links are useful-to-have additional metadata, whereas from a Wikipeida editor POV links are fundamental to the structure and essence they don't conceptually fit with decoration.
This is exactly as designed. It also removes language settings (lang=fr and dir=rtl), superscript/subscript/underline/strikethrough/big/small/code formatting, and <span>s setting arbitrary formatting annotations (like "color: red;" or "font-family: serif;" or …). It's modelled against the same function in other editors, rendering the text down to completely plain text (except for objects like references or templates).

Do you think each of these formatting options should have a "remove" function? Only some of them? Only those that trigger an inspector rather than just a boolean state (like links, language and arbitrary settings)? Only links? Why/why not? Happy to change direction but it would need to be a pretty strong reason to change (amongst other things, we'd need to give users ways to break out of the other kinds of pre-annotations as well as removing the selected annotation).
One of the major advances in wiki editing in the last few years has been support for the short template-based referencing systems like SFN. I've made it a basic rule to use SFN if a reference is used more than twice within the article, and an inline only in the rare case where it is used once or twice. I realize my editing patterns are not normal, but I think support for these templated refs would improve the editor greatly. 

Perhaps a "toolbar-like" editor to one side of the main editor could list of global references created so far, and allow the user to drag a handle from them into the article to place the ref in the body.

Even better, perhaps the use could drag URLs or text into the bar to create semi-filled out master refs.

--------------------------
**Version**: unspecified
**Severity**: enhancement
JD, can you point to the "as discussed previously"? I am not familiar with the problem, so do I understand why this would be a "horrible hack".
I guess I agree that it may not be worthwhile to support creating new footnotes with the [[https://en.wikipedia.org/wiki/Template:Sfn| shortened footnotes (SFN) template]]. 

However, for the time being this system is still around on enwiki. And since this bug was filed, the citation reuse features was introduced in VE, and there it's an awkward and confusing user experience that one is not able to reuse already existing sfn footnotes. 

Compare the list of footnotes offered for reuse in
https://en.wikipedia.org/w/index.php?title=AI_winter&oldid=680877170&veaction=edit  (via "Cite" -> "Re-use")  with the actual [[https://en.wikipedia.org/w/index.php?title=AI_winter&oldid=680877170#Notes |list of footnotes in that article revision]]. The numbering is inconsistent, e.g. #7 (John Hutchins) in the article becomes #3 in VE, with the original footnots #3, #4, #5 and #6 mission. I had to search and think for a while to realize that I wasn't simply overlooking things and that the reason for the discrepancy is this template.
Cite.php is designed a certain (bad) way. It has issues, and we will replace it at some point, but the way to fix its issues is not to make horrible hacks in wikitext using loopholes over-looked when the code was written to try to re-design in.

This is one of those cases, and is not sanely supportable in VisualEditor, so I'm going to mark this as WONTFIX. I know I previously said "lowest", but I don't think that that's a justifiable direction for the product to go in.
As discussed previously, supporting this wikitext hack is exceptionally difficult to do, and it would be much more sensible to spend the effort on a proper cross-page, cross-wiki citations system instead which would solve the same problem (and lots more). However, it's not impossible, so keeping open as a lowest-priority enhancements.
Hi,

a: Currently language list displayed below MediaWiki:Visualeditor-dialog-meta-languages-readonlynote/mr does not open the respective language wiki but when that is possible along with that respective language item ULS should offer option to open up the respective language wiki with related display and/or input .May be this shall need to mingle three extensions VE,wikidata,ULS and also

b When in menubar languages displayed by wikidata if curser hover over any wiki language name options as requested in 4a should display and available. (Whether this needs to split as a separate bug ?)



*To understand further the need for above request,please do refer to survey
data and analysis provided at
http://www.mediawiki.org/wiki/Talk:Universal_Language_Selector#feature_to_make_content_language_input__default_28864

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51431
1(In reply to comment #6)
> (In reply to comment #5)
> However, is this a duplicate of bug 52383 maybe?

::No not at all,if I have read bug 52383 correctly,it is asking to scrap certain feature made avaialable by VE by some frustrated user.Unless you are ready to scrap parts of VE design in that sense it is not an enhancement bug at all and most likely bug 52383 need to be wont fix


* This bug 51355 assumes that any way you will be completeing the bug 52105. This bug is an enhancement over bug 52105 (So parsing job is happening at bug 52105)  and also expects bug 51431 enhancement also too take place.
::In other words this bug 51355 wants to mount bug 51431 enhancement over bug 52105 enhancement.
(In reply to comment #5)
> *In VisualEditor - Toolbar -Page settings - language Section shows languages
> heading with following message  
> http://www.mediawiki.org/wiki/MediaWiki:Visualeditor-dialog-meta-languages-
> section 
> *Below this message  VisualEditor - Toolbar -Page settings - language Section
> reproduces the same list of interwiki languages that I provided by Wiki data.
> *Currently these language links are not parsed. 

Not sure what you want to "parse" here, plus parsed by who?
However, is this a duplicate of bug 52383 maybe?

Please also update the bug summary to be descriptive. Thanks!
I have split point b in a separate bug 51431.  


*In VisualEditor - Toolbar -Page settings - language Section shows languages heading with following message  
http://www.mediawiki.org/wiki/MediaWiki:Visualeditor-dialog-meta-languages-section 

*Below this message  VisualEditor - Toolbar -Page settings - language Section reproduces the same list of interwiki languages that I provided by Wiki data.

*Currently these language links are not parsed. 

*This bug expects the same feature that is expected in bug 51431 but in context of Visual Editor toolbar -page settings languages
...and please provide a bug summary that describes the actual feature request.
Please provide exact and clear steps (click by click, as a numbered list) so anybody else could reproduce the problem, plus the expected and the actual outcome. I still don't know which page you are on, etc.
See https://www.mediawiki.org/wiki/How_to_report_a_bug for general info.
Created attachment 12860
Request for Wikidata interwiki wikis to open with respective language ULS display and input

**Attached**: {F11455}
Please provide a screenshot of the current problem that you would like to
solve, plus a link to a wikipage where the problem can be seen. 
Furthermore, please only file one problem per report. 
Also see https://www.mediawiki.org/wiki/How_to_report_a_bug

> *To understand further the need for above request,please do refer to survey
> data and analysis provided at
> http://www.mediawiki.org/wiki/Talk:
> Universal_Language_Selector#feature_to_make_content_language_input__default_2
> 8864

Please summarize the points made there instead of making me read a long thread.
The ability to sign posts is useful outside of talk name spaces. For instance http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback is in project space. While that might one day be in flow there are many other project space items where  its useful to be able to sign. For instance lists of project members. Some uses have guest books in the User: space which can be signed. 

You can't even enter them manually due to T51820.

A button to insert this would be good, possibly done at the same time as bug 38029 which would insert symbols.
 
This was discussed at http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback/Archive_2013_07#Let_me_sign.21

----

VisualEditor now allows you to insert signatures on pages that are in `$wgExtraSignatureNamespaces` (and any talk pages).

This was previously implemented as a user script / gadget is available at https://meta.wikimedia.org/wiki/User:Matma_Rex/visualeditor-signature.js.
@Trizek-WMF Sure, I know, @Urbanecm told us the same on cswiki on community forum. I think we also have got on cswiki some bugs subpage under WP:Flow page, where all the bugs found are listed. I'll take a look into tasks I sent here, if there is another one I forgot to mention on that subpage.
@Trizek-WMF Sure, I know, @Urbanecm told us the same on cswiki on community forum. I think we also have got on cswiki some bugs subpage under WP:Flow page, where all the bugs are listed. I'll take a look into tasks I sent here, if there is another one I forgot to mention on that subpage.
@Dvorapa, please contact me if you have any suggestions about Flow bugs which need to be fixed.
>>! In T53154#2399021, @Dvorapa wrote:
> @Jdforrester-WMF I see, thank you. Still looking for a good talk solution - Flow is too buggy, VisualEditor is not really designed for discussions and wikitext is not easy to learn for novice users.

I think getting the bugs in Flow fixed is the best option at this point, but I appreciate that there's a few things people would like to see added there.
@Jdforrester-WMF I see, thank you. Still looking for a good talk solution - Flow is too buggy, VisualEditor is not really designed for discussions and wikitext is not easy to learn for novice users.
>>! In T53154#2398111, @Dvorapa wrote:
> Is there any option how to add a signature button to the main VE bar (e.g. instead of the special symbol button or next to?) (discussed on cswiki; just asking if possible)

This is not possible. We intentionally do not allow the toolbar to vary in the position of buttons on the same wiki.
Is there any option how to add a signature button to the main VE bar (e.g. instead of the special symbol button or next to?) (discussed on cswiki; just asking if possible)
Is there any option how to add a signature button to the main VE bar (e.g. instead of the special symbol button or next to?) (cswiki; in discussion, just asking if possible)
Is there any option how to add a signature button to the main VE bar (e.g. instead of the special symbol button or next to?)
Change 251834 merged by jenkins-bot:
Provide a tool to insert a signature in namespaces that need it

[[https://gerrit.wikimedia.org/r/251834]]
Change 251834 had a related patch set uploaded (by Bartosz Dziewoński):
Provide a tool to insert a signature in namespaces that need it

[[https://gerrit.wikimedia.org/r/251834]]
Hmm, and so it seems that the $wgExtraSignatureNamespaces functionality provided by https://gerrit.wikimedia.org/r/87649 (T7645) was actually merged, even thought it looked hopeless a year ago. I think we can go ahead with migrating my gadget to VisualEditor proper, and enabling the signature inserting tool only in those namespaces.
>>! In T53154#1138179, @Juandev wrote:
> Thank you for the code. Could the user also add a special button to VE or is it a difficult cooding? 

Per the task description and per my previous comment, there is a gadget that implements this that you can easily enable for yourself, or on your wiki.
>>! In T53154#537004, @AdHuikeshoven wrote:
> Adding a signature with VisualEditor can be simulated using a template:
> 
> ---template code:---
> {{{Sign}}}
> <noinclude>
> This template allows to sign using Visual Editor by adding this template as you can't enter four tildes <nowiki>~~~~</nowiki> in VE. Enter the template in VE. Hit Add template. Enter <nowiki>~~~~</nowiki> in the field. Hit Insert template. Hit Save page. Enter edit summary. Hit Save. Doone.</br>
> <templatedata>
> {
> 	"description": "A template to sign using Visual Editor. ",
> 	"params": {
> 		"Sign": {
> 			"aliases": [
> 				"Signature"
> 			],
> 			"label": "Sign by entering ~~~~ in the field below",
> 			"description": "Field to enter signature, that is four tildes",
> 			"default": "Please enter four tildes here",
> 			"required": true
> 		}
> 	}
> }
> </templatedata>
> </noinclude>
> ---end of template code---
> 
> Usage:
> Enter the template in VE. Hit Add template. Enter ~~~~ in the field. Hit Insert template. Hit Save page. Enter edit summary. Hit Save.
> 
> Example:
> See https://www.mediawiki.org/wiki/Template:VESign. Application of template tested on https://www.mediawiki.org/wiki/User:Ad_Huikeshoven/test. 
> 
> Evaluation:
> There might be nicer methods to accomplish the same, maybe using JS (I have no experiene writing JS). When there is a switch over to Parsoid rendering the templates mid-edit rather than relying on PHP parser the above solution will probably break, as will probably do any solution to bug 51146.

Thank you for the code. Could the user also add a special button to VE or is it a difficult cooding?
I updated the description with information about the gadget implementing this feature.
@Pine: Yes I'd object. :) Please see T53154#536989
Would anyone object to bumping up the priority of this to normal?
Like @AdHuikeshoven, I just ran into the use case where I can't sign myself to a list of Wikimania talk attendees.
Yes, I've moved it to talk space. Sorry I didn't catch that earlier.
(In reply to Pine from comment #22)
> Perhaps someone enabled VE on talk pages when they shouldn't have?
> 
> It's enabled on https://meta.wikimedia.org/wiki/Grants:APG/Comments

Argh. That's not a talk page. You can tell because the talk page would be https://meta.wikimedia.org/wiki/Grants talk:APG – this is really unhelpful of people to use the wrong namespace. I'm sorry about that. :-(
Ah, I see. That's not really labeled as a talk page on Meta, but it probably should be. I'll try to take care of that.
Perhaps someone enabled VE on talk pages when they shouldn't have?

It's enabled on https://meta.wikimedia.org/wiki/Grants:APG/Comments
(In reply to Pine from comment #20)
> I am raising the priority of this bug. VisualEditor is now enabled for talk
> pages on Meta, yet I can't insert my signature using VisualEditor, which is
> a major shortcoming. Please fix!

What talk pages is it enabled for? Can you give an example? It doesn't appear on the talk pages I just looked at. This feels like a distinct bug.

Please read the history of this bug for why this is explicitly outside of the plans for VisualEditor; it's fundamentally the wrong approach. Resetting priority.
I am raising the priority of this bug. VisualEditor is now enabled for talk pages on Meta, yet I can't insert my signature using VisualEditor, which is a major shortcoming. Please fix!
It seems that bug 5645 which I thought to be a dependency is not going to be fixed in a useful way. The only way to proceed would be reimplementing the namespace selection logic in VE, which I'm wary of. I don't know how to proceed with this, I guess we'll be stuck with the gadget for the time being.
Actually, a $wg config variable for this is not a very good idea. We should just be smart and display the signature button in the namespaces that need it (and no others).

Core MediaWiki currently has no way to do this (other than the implied assumption that all talk namespaces need signatures), but there happens to be a patch pending that would introduce one (https://gerrit.wikimedia.org/r/87649). We should just wait for that to be implemented, and then use the same logic as wikitext editor when deciding whether to enable signatures or not.
(In reply to Bartosz Dziewoński from comment #16)
> That sounds fine by me. So it would be enabled with a $wg config variable?

That was my thought, yes.

> I wonder if it would make sense to let users enable it for themselves (by
> loading a RL module in common.js, for example).

It doesn't; either VE namespaces are signable or they're not. A per-user setting doesn't make sense.

"Assigning" to Bartosz given he's done all the work here. :-)
That sounds fine by me. So it would be enabled with a $wg config variable?

I wonder if it would make sense to let users enable it for themselves (by loading a RL module in common.js, for example).
(In reply to Lokal_Profil from comment #14)
> Being a basic building block of a wiki which is currently missing from VE I
> would not mark this as Resolved until there is a solution integrated in VE.
> Better then to leave it open and hope that some volunteer takes it on if it
> is deemed to be outside of the scope for Wikimedia to implement.

There is never going to be a "sign post" feature integrated into VisualEditor as deployed on WMF servers. That's the whole point of Flow. From a perspective of "VisualEditor for WMF users", this is WONTFIXed.

This bug is not marked as "WONTFIX" though, because it's entirely plausible that someone might want to run VisualEditor on a wiki without Flow (or LQT or Message Wall or whatever).

Maybe we should bundle up Bartosz's code into a VE plug-in that's available for users (but not on by default)?
Being a basic building block of a wiki which is currently missing from VE I would not mark this as Resolved until there is a solution integrated in VE. Better then to leave it open and hope that some volunteer takes it on if it is deemed to be outside of the scope for Wikimedia to implement.

Adding a signature should be as easy or easier (for the user) as adding an image or template. Also since there is nothing preventing signatures from being added to any namespace in the wikitext editor there should be no hard-coded exceptions in the VE-solution (although there could of course be site-wide setting disallowing them.
I wonder what should we do with this bug? I think it should be marked either RESOLVED WONTFIX or RESOLVED FIXED, but I'm not sure which is more appropriate.
I replied at [[meta:User talk:Matma Rex/visualeditor-signature.js]].
(In reply to SJ from comment #3)
> I think it is important to enable signatures in VE.  I have found it useful
> in a few circumstances; and regretted having to drop out of VE just for that
> one addition.

The use case I would like mention is adding your name to the list of interested attendees at the program pages of https://wikimania2014.wikimedia.org/. Bartosz tools works wonderfully outside content name space. However, it explicitly doesn't work on content name space in which the program pages at the Wikimania site reside.
Whoa, that's scary. Please don't do that.

I wrote a script to implement signatures properly. This definitely isn't what the editor was designed to do, but, as it was noted in earlier comments, this has its use cases.

https://meta.wikimedia.org/wiki/User:Matma_Rex/visualeditor-signature.js

Please comment about it on the script's talk page, not here :) I'd be happy to include more translations (there are just two words to translate).

I think the only thing missing is an icon that would match the look-and-feel of existing ones. I'd be happy to add it, too, if only someone drew one (SVG).
Adding a signature with VisualEditor can be simulated using a template:

---template code:---
{{{Sign}}}
<noinclude>
This template allows to sign using Visual Editor by adding this template as you can't enter four tildes <nowiki>~~~~</nowiki> in VE. Enter the template in VE. Hit Add template. Enter <nowiki>~~~~</nowiki> in the field. Hit Insert template. Hit Save page. Enter edit summary. Hit Save. Doone.</br>
<templatedata>
{
	"description": "A template to sign using Visual Editor. ",
	"params": {
		"Sign": {
			"aliases": [
				"Signature"
			],
			"label": "Sign by entering ~~~~ in the field below",
			"description": "Field to enter signature, that is four tildes",
			"default": "Please enter four tildes here",
			"required": true
		}
	}
}
</templatedata>
</noinclude>
---end of template code---

Usage:
Enter the template in VE. Hit Add template. Enter ~~~~ in the field. Hit Insert template. Hit Save page. Enter edit summary. Hit Save.

Example:
See https://www.mediawiki.org/wiki/Template:VESign. Application of template tested on https://www.mediawiki.org/wiki/User:Ad_Huikeshoven/test. 

Evaluation:
There might be nicer methods to accomplish the same, maybe using JS (I have no experiene writing JS). When there is a switch over to Parsoid rendering the templates mid-edit rather than relying on PHP parser the above solution will probably break, as will probably do any solution to bug 51146.
To clarify, this is a "WONTFIX" for VE as it is (and will be) enabled on WMF projects, but if someone wants to write a plugin for VE for other wiki hosts using it that want to try to make VE work in discussion namespaces (and don't want to use Flow).

There are a number of meanings of "Lowest" priority, and this is one of the confusing ones. Sorry. :-(
(In reply to comment #6)
> Will Flow be applicable to all namespaces? There are lots of article-style
> pages that temporarily or permanently would benefit from inline comments in
> the
> middle of what is otherwise a full-text long-form page.  In those cases* I
> don't see how the Flow design will help.

Like what? Some examples, please?

> 
> Signatures are useful in most namespaces, whereas "idiosyncratic protocols
> and
> templates and formats", with unknown amounts of associated work, seem like
> higher-hanging tasty fleshy vegetalia.
> 
Sure, and work on those namespaces is best done when we actually discuss _deploying_ in those namespaces - and when it is fully working for the primary target of the VE (i.e., the mainspace).

> * Examples: wikis that don't separate talk from content; wikis that have two
> layers of talk: limited inline v. permanent talk-threads; articles or main
> pages that tabulate membership or participation or otherwise include tables
> that include user signatures.

Actual examples for each example...?
Will Flow be applicable to all namespaces? There are lots of article-style pages that temporarily or permanently would benefit from inline comments in the middle of what is otherwise a full-text long-form page.  In those cases* I don't see how the Flow design will help.  

Signatures are useful in most namespaces, whereas "idiosyncratic protocols and templates and formats", with unknown amounts of associated work, seem like higher-hanging tasty fleshy vegetalia.

* Examples: wikis that don't separate talk from content; wikis that have two layers of talk: limited inline v. permanent talk-threads; articles or main pages that tabulate membership or participation or otherwise include tables that include user signatures.
That's probably something to do with the fact that the VE isn't really being used in discussion namespaces.

This is not, by far, the only feature blocking VE from being useful in many other contexts. A lot of the discussion namespaces have their own idiosyncratic protocols and templates and formats that parsoid and the VE will then have to directly support, which is likely to be some (unknown) additional amount of work, and that'll all be done just in time for us to start releasing Flow, which does auto-signing.

I can understand the low prioritisation ;).
I just noticed this is flagged as lowest-priority enhancement... again surprising considering the importance and prevalence of signing in wiki culture and other MW docs.
I think it is important to enable signatures in VE.  I have found it useful in a few circumstances; and regretted having to drop out of VE just for that one addition.

This is the only feature blocking VE from being useful in a much wider variety of contexts, in my opinion.  (And it's odd for all sig options to be missing when reminders about how to sign and where to sign are some of the most prominent in the MediaWiki interface otherwise.)
http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback/Archive_2013_07#Let_me_sign.21

^Updated link
The VisualEditor isn't going to be in project space at any point in the near future, however.
**Author:** `mcdevitd`

**Description:**
"Preformatted" is HTML jargon which most of VisualEditor's target users will not understand, and it actually produces an effect (text with less formatting) which is unexpected if you don't know what it means beforehand. It should either be given a plain-language name so that people will expect the behavior, or removed.

I actually don't understand why this style effect is in the header-level pull-down when it is not a header-level. My preference is to remove it, since it is uncommon and mostly adding noise, but it should be renamed if kept.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Also, a dictionary cite for usage of "pre-formatted": http://www.oed.com/view/Entry/149454?rskey=n6kMKv&result=2&isAdvanced=false#eid51449481 (not that it gives a definition or synonym we could use).
Eh, this is a bad wontfix. My dictionary doesn't contain "preformatted"; we can probably come up with a better term.

Regarding the user interface, it's a bit confusing why there's a text formatting menu (paragraph text and headings) next to another text formatting menu (bold, underline, computer code, etc.). It might make sense to move the artist currently known as preformatted to the bottom of the latter menu as it's not very commonly needed (about as commonly needed as needing to write "computer code" using VisualEditor, surely).
**mcdevitd** wrote:

(In reply to James Forrester from comment #6)
> (In reply to MZMcBride from comment #5)
> 
> I'm inclined to WONTFIX at this point…

I was under the impression that VisualEditor was about removing jargon and unneeded advanced features that clutter the user experience. All three of the other commenters here agreed that "Preformatted" is jargon that should at least be renamed using plain language. And it's not really even clear why we expect "preformatted" to be a common enough formatting choice among VisualEditor users that it even merits the inclusion in that menu.

Your comment on WONTFIXing the report doesn't address the actual problem being raised.
(In reply to MZMcBride from comment #5)
> Should this bug report continue to be assigned?
> 
> I think a mock would help here.

A mock of what? Moving some (but not all) paragraph-level formats somewhere else seems like a really bad design. We'd be talking about pre-formatted, blockquote, and maybe other like poem and so-on being in one menu, and other tools that operate in the exact same way (e.g. don't apply to a selection). I'm inclined to WONTFIX at this point…
Should this bug report continue to be assigned?

I think a mock would help here.
Now that we have the "more" menu I don't think the button issue exists (to the same degree at least) as it did.

As the "preformatted" name I agree it doesn't make sense, as this isn't really what it does. I was going to suggest "monospaced" but it's more than that - it's monospaced and indented with a shaded background. However, <code> also produces monospace and a shaded background but that is different.
**mcdevitd** wrote:

My confusion came from the fact that the user guide refers to it as the "Headings pull-down menu" (http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/User_guide#Getting_started:_the_VisualEditor_toolbar), and every other option in the menu is a heading level (or no level), not a style.

If there is somewhere else where styles like pre are going to go, or you intend to add other styles to this same menu, that's fine with me, but my original point about it being jargon still stands. (Though if you add more style options to the same menu, I think that is even more reason to remove pre as noise.)
This isn't a "header pull-down menu", it's a text style menu. Also, having yet another control in the toolbar (for blockquote, pre and whatever else) doesn't feel great. :-(
I agree.

It's strange that it's currently in the header menu. A separate menu for <blockquote> and <pre> may make sense.
I think we can (almost) remove Opera from the blacklist now, see blocking bug 36000. Opera < 12 should still probably be blacklisted, though, and < 10 should be blacklisted for sure (there's a bunch of people who insist that 9.64 was the ultimate version ever and stick to it).

It'd be cool if it could be added to the whitelist as well, but I guess that would be a promise to support it and you guys probably don't want to promise that ;)

--------------------------
**Version**: unspecified
**Severity**: normal
It was unblacklisted in the now-merged Ia80a6f53.
(In reply to comment #2)
> Note that the Presto engine-based Opera 12.x is being end-of-lined; the new
> Opera 15 is Chromium-based.

There is no release date or anything apart from a very early alpha of Opera 15 (which basically does nothing apart from showing pages). I'd say Opera 12 still has a bit of time before it.


> Is it worth worrying about Opera 12.x compatibility?

Still, objectively, maybe it's not. But I care personally. :)
Note that the Presto engine-based Opera 12.x is being end-of-lined; the new Opera 15 is Chromium-based.

Is it worth worrying about Opera 12.x compatibility?
(In reply to comment #0)
> I think we can (almost) remove Opera from the blacklist now, see blocking bug
> 36000. Opera < 12 should still probably be blacklisted, though, and < 10
> should
> be blacklisted for sure (there's a bunch of people who insist that 9.64 was
> the
> ultimate version ever and stick to it).
> 
> It'd be cool if it could be added to the whitelist as well, but I guess that
> would be a promise to support it and you guys probably don't want to promise
> that ;)

Very happy to add to the whitelist if you're sure that everything works perfectly. It's not a state a browser can only reach if supported by WMF, if you want to commit to doing that. The comprehensive testing is quite a high bar, however - does Opera now cope with everything at mediawiki.org/wiki/VisualEditor/Basic_example_worksheet ?
Because.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Call me boring, but… :-)
(In reply to comment #4)
> Articles mysteriously being littered with ♙ and ☃ doesn't count? :-)

No :P
Articles mysteriously being littered with ♙ and ☃ doesn't count? :-)
Maybe it already has them, and we're just not cool enough to know...
Maybe you're just not looking hard enough
When you add a new citation in VE, templates which wrap the `<references />` tag do not update to display it until the page is saved. Examples include [[https://en.wikipedia.org/wiki/Template:Reflist|`{{reflist}}`]] on the English Wikipedia and [[https://es.wikipedia.org/wiki/Plantilla:Listaref|`{{listaref}}`]] on the Spanish Wikipedia. This bug doesn't block any of the core citation workflows (creating, editing, and reusing) since those are accessed from the toolbar and the in-text reference numbers, but it's still very annoying. 

However, it remains unfixed because it's an //extraordinarily// hard technical challenge, verging on impossible given the current architecture of Mediawiki. No one has any idea what a workable solution would look like. Just to give one facet of the problem, you could implement this in VE right now //if// you completely re-parsed the entire page every time the user touched a template or a reference—which would be a //horrible// user experience and place //insane// loads on the servers. It's possible that in the future, someone will think up a brilliant solution that avoids all these huge issues, so this task remains open.

In the meantime, the planned solution is to update the `<references />` tag, which does update properly during editing, to support multiple columns and alternative list styles so they have all the functionality of these templates (T53260). When that task has been completed, communities will be able to replace the templates with references tags at whatever pace and with whatever tools they prefer (if there's demand for it, it would probably be possible to do a more immediate, bot-driven changeover).
Change 408604 **merged** by jenkins-bot:
[mediawiki/extensions/Cite@master] Treat template-generated reference lists as real ones

[[https://gerrit.wikimedia.org/r/408604]]
Change 408604 had a related patch set uploaded (by Esanders; owner: Esanders):
[mediawiki/extensions/Cite@master] Treat template-generated reference lists as real ones

[[https://gerrit.wikimedia.org/r/408604]]
>>! In T52769#541738, @Jdforrester-WMF wrote:
> Note that we can't currently see a way to do this without round-tripping the entire page, which would be a sub-optimal solution, to put it mildly.

So, if <references/> directly on the page are supposed to work (they're updated on edit) but when they're inside a template not, it should be possible to make parsoid tag the template with a special property so only that template region gets updated (or the references list) and not the entire page. Note that I'm speaking without knowledge about how the entire thing works.
So to clarify, it is a known bug that adding references will display the updated reference list when the <references /> tag is used in the article, but not when the {{reflist}} template is used?
*** Bug 51607 has been marked as a duplicate of this bug. ***
(In reply to comment #0)
> What it says on the tin; the addition of a reference is not reflected in an
> update to {{reflist}} or <references/> or whathaveyou.

I can't replicate the bug as described, but re-purposing to be about our desire to update fake reference lists inside templates on edit, rather than the current unhelpful not-updated-'til-page-save issue.

Note that we can't currently see a way to do this without round-tripping the entire page, which would be a sub-optimal solution, to put it mildly.
A user has requested a tool to alter the case of text that has been typed. Marking as lowest priority, since we've made clear it's not something anyone is likely to work on any time soon.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
{T55210}
{T52678}
{T55495}
{T52452}
Occasionally wiki links are being mangled adding ./ to the start and replacing spaces with underscores. For example replacing [[specific name (zoology)|specific epithet]] with [[./Specific_name_(zoology)|specific epithet]]. I've only noticed it with piped links.

Examples

https://en.wikipedia.org/w/index.php?title=Austropotamobius_pallipes&curid=3945333&diff=562783871&oldid=545518009
https://en.wikipedia.org/w/index.php?title=Ron_Davies_(songwriter)&curid=31118393&diff=562723238&oldid=553701771
https://en.wikipedia.org/w/index.php?title=Sibling_relationship&curid=22409572&diff=562636237&oldid=561958868
https://en.wikipedia.org/w/index.php?title=Double_Rainbow_(viral_video)&curid=28129724&diff=562626607&oldid=560477885
https://en.wikipedia.org/w/index.php?title=Roger_Mompesson&curid=39389398&diff=562625481&oldid=560045122 (also changed a category link)

possibly related to bug 50428

--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50539
https://bugzilla.wikimedia.org/show_bug.cgi?id=48769
Can no longer reproduce the test case given by Erik in FF13/14. Edited the link directly to avoid SelSer.

https://en.wikipedia.org/wiki/HELLP_syndrome?veaction=edit&vewhitelist=1

{F4089820}
>>! In T52720#2164275, @Schnark wrote:
> Should this task just be closed? I don't think anyone is going to put work into supporting  these really old Firefox versions.

I've been keeping this open as we //would// accept any patch doing this. Yes, there are relatively very few users, but it's not great to leave these users without an editor over something that's effectively trivial.
Should this task just be closed? I don't think anyone is going to put work into supporting  these really old Firefox versions.
Just wondering, has anybody tested VE on those old Firefoxes somewhat recently? The codebase is changing so fast this might as well be magically fixed now.
(In reply to comment #11)
> I think you viewed this bug solely as a blocker to bug 50848. I agree that it
> no longer is, but I don't believe this bug is now resolved/fixed. The issue
> hasn't been fixed, as I understand it, just worked around. I'm re-opening the
> bug, but removing bug 50848 as a blocker, lowering the importance fields, and
> clarifying the bug summary.

Well, had you given me more than 30 seconds I was in the middle of creating a new bug, but never mind. :-) Repurposing this one.
I think you viewed this bug solely as a blocker to bug 50848. I agree that it no longer is, but I don't believe this bug is now resolved/fixed. The issue hasn't been fixed, as I understand it, just worked around. I'm re-opening the bug, but removing bug 50848 as a blocker, lowering the importance fields, and clarifying the bug summary.
We believe that this should not recur due to the (hopefully-temporary) blacklisting of Firefox 13 and 14, which is now live in production. Consequently, I'm marking this bug as fixed. Please re-open if you find it happening again.
Change 72675 merged by jenkins-bot:
Blacklist Firefox 13 and 14 too

https://gerrit.wikimedia.org/r/72675
Change 72675 had a related patch set uploaded by Jforrester:
Blacklist Firefox 13 and 14 too

https://gerrit.wikimedia.org/r/72675
Can reproduce in Firefox 13 and 14; cannot reproduce in 15 or 17 or 20. Interestingly in Firefox 13 I get a little bit more normalization in the diff as well. Looks like we get more progressively more broken the further down we go. :P
Confirmed in Firefox 14. Steps to reproduce:

1) Open https://en.wikipedia.org/wiki/HELLP_syndrome?veaction=edit as a logged in user

2) Make an unrelated edit

3) Press "Save" and "Review your changes".

The link [[Right upper quadrant (abdomen)|right upper quadrant]] is transformed to [[./Right_upper_quadrant_(abdomen)|right upper quadrant]].
According to https://de.wikipedia.org/wiki/Wikipedia:Technik/Text/Edit/VisualEditor/Beta2013-07#VE_zerschie.C3.9Ft_Kats_und_Wikilinks this seems to be an issue in old Firefox: FF14 inserted the ./, while FF22 didn't.
I think it might be to do with having punctuation in the links in this edit
https://en.wikipedia.org/w/index.php?title=Soccer_in_the_United_States&diff=prev&oldid=563041224
this the links which have ' or ( in them which get mangled other links are ok so
[[United States men's national soccer team|men's national team]] gets changed to 
 [[./United_States_men's_national_soccer_team|men's national team]] but [[FIFA World Cup|World Cup]] is unchanged. And [[National Professional Soccer League (1967)|National Professional Soccer League]] is changed to [[./National_Professional_Soccer_League_(1967)|National Professional Soccer League]].
(In reply to comment #1)
> Escalating priority. Additional example:
> 
> https://en.wikipedia.org/w/index.
> php?title=OMICS_Publishing_Group&curid=35277259&diff=562944992&oldid=56157968
> 0
I can't reproduce this, and can in fact edit the page just fine: https://en.wikipedia.org/w/index.php?title=OMICS_Publishing_Group&diff=563024944&oldid=562947045

This bug must have some particularly nasty cache persistence properties; we've purged the Parsoid caches but that doesn't seem to have made it go away.
*** Bug 50539 has been marked as a duplicate of this bug. ***
Escalating priority. Additional example:

https://en.wikipedia.org/w/index.php?title=OMICS_Publishing_Group&curid=35277259&diff=562944992&oldid=561579680
Enhancement request for more informative error messages - as simple as "Syntax error in JSON on line foo." would be better than the current message, which is just "Syntax error in JSON."

| {F34099979} | {F34099994}
(In reply to comment #2)
> Presumably this could be done if bug 50169 was implemented, though. :-)

Well, in case of bug 50169 (VisualEditor plugin for TemplateData) there would never be a syntax error in the JSON because the user wouldn't be editing it directly. They'd be using a form-like interface to interact with it (VE would generate the JSON which is always valid).

However if the VE plugin would have a raw mode to edit the JSON (e.g. using an Ace surface like Extension:CodeEditor does), we could use its JSHint integration to get inline errors by line/char highlighting (e.g. like in Sublime).
For the moment, you can use TemplateDataEditor to be able to create the <templatedata/> without editing any real JSON.

http://en.wikipedia.org/wiki/User:NicoV/TemplateDataEditor
**weskaggs** wrote:

Displaying the contents of the line at which an error is detected, with a few lines around it for context, would be almost as useful as a line number.  Of course the actual error can be a long way off from the point at which a syntax error is detected, but the information would still be helpful.  Adding information about the type of error would make it even better.  Really any information at all about the nature of the error would be an improvement.
Presumably this could be done if bug 50169 was implemented, though. :-)
It is in my opinion not feasible to get line numbers because we use a native PHP extension to parse the JSON.

If the JSON syntax itself is invalid, there is nothing we can do. Best case scenario the parser gives the type of error ("Unexpected comma", "Expected closing curly brace" etc.) but a line number is unlikely.

Once the JSON is parsed, the TemplateData validation itself (e.g. sets referring to existing parameters) we have full control over and gives pretty informative errors with the full path to the property.

> Unexpected property "params.user.blabla".
> Property "params.timestamp.description" is expected to be of type "string|object".

etc.
Until a recent MediaWiki change the default behavior of edit section links was to float to the far side of the heading (right on LTR Wikis, assume this case in the following).

This was changed recently but almost all Wikis provide Gadgets to restore the old behavior (see http://en.wikipedia.org/wiki/MediaWiki:Gadget-righteditlinks.css or http://de.wikipedia.org/wiki/MediaWiki:Gadget-editsection-align-end.css for examples)

The problem is, that the VisualEditor's fly-out-links reserve space to the right for the "edit source" link. Therefore when aligning the links right they actually appear with a large distance to the page-margin. The fly-outs should therefore be modified to not reserve any space so the "edit" link is correctly aligned right.

To prevent the fly-outs to shift the whole "edit" link left as soon as they become visible they could be changed to fly-out to the left in this case or to the bottom.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Trivial patch idea

To add some content: Wouldn't a trivial patch along the lines of the attachment be sufficient to fix this problem?

I'm sure something like this could be implemented with minimal effort for somebody with a little experience!

**Attached**: {F11273}
I see your point but you have to admit that without changing the style of the edisection-links these Gadgets wouldn't have been necessary in the first place. They are basically "fixing" what WMF "broke" so it would be nice if you at least tried to supply a solution.
(In reply to comment #0)
> Until a recent MediaWiki change the default behavior of edit section links
> was
> to float to the far side of the heading (right on LTR Wikis, assume this case
> in the following).
> 
> This was changed recently but almost all Wikis provide Gadgets to restore the
> old behavior (see
> http://en.wikipedia.org/wiki/MediaWiki:Gadget-righteditlinks.css or
> http://de.wikipedia.org/wiki/MediaWiki:Gadget-editsection-align-end.css for
> examples)
> 
> The problem is, that the VisualEditor's fly-out-links reserve space to the
> right for the "edit source" link. Therefore when aligning the links right
> they
> actually appear with a large distance to the page-margin. The fly-outs should
> therefore be modified to not reserve any space so the "edit" link is
> correctly
> aligned right.
> 
> To prevent the fly-outs to shift the whole "edit" link left as soon as they
> become visible they could be changed to fly-out to the left in this case or
> to the bottom.

Note that in general WMF does not support gadgets and does not encourage their use; they are highly likely to break like this when the code they depend on changes, and this is a good example of that breakage. :-(

I've re-written this a bit to be clearer. As "lowest" priority, reflecting that we don't support gadgets. of course anyone who is interested in patching is welcome to suggest ideas/code that could address this.
It has been mentioned in some places[1][2] that the JSON syntax might be a problem for typical (non-technical) users, so I suggest creating a plugin for editing the content of the <templatedata> tags.

[1] https://commons.wikimedia.org/wiki/Template_talk:Information#Adding_TemplateData_information
[2] https://pt.wikipedia.org/wiki/WP:Café_dos_programadores#Mais_uma_novidade:_TemplateData

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51734
This was done as part of {T152230}.

{F5229438}
No, this is for editing TemplateData blocks nicely once we enable Template: namespace editing in VE (and the 2017 wikitext editor).
We created a template data editor a few years ago.
I've translated the script to enwiki : http://en.wikipedia.org/wiki/User:NicoV/TemplateDataEditor

and made a screenshot in Commons : http://commons.wikimedia.org/wiki/File:TemplateDataEditor.png
Created attachment 12786
Screenshot of the form provided by the user script from frwiki

(In reply to comment #2)
> A user on fr.wikipedia seems to have developed a user script to easily add
> TemplateData to a template:
> https://fr.wikipedia.org/wiki/Utilisateur:Ltrlg/scripts/TemplateDataEditor.js
> 
> This might be of interest while developing a similar VE module.

For convenience, I've attached a screenshot of the form generated by that script.

**Attached**: {F11686}
A user on fr.wikipedia seems to have developed a user script to easily add TemplateData to a template:
https://fr.wikipedia.org/wiki/Utilisateur:Ltrlg/scripts/TemplateDataEditor.js

This might be of interest while developing a similar VE module.
See also bug 50370 comment 1.
A retread of bug 42847 for issues in the run-up to wider deployment.

--------------------------
**Version**: unspecified
**Severity**: normal
Now replaced by https://phabricator.wikimedia.org/maniphest/query/V25BI8.HgRPz/#R instead.
Change 155841 merged by jenkins-bot:
Greylist IE11

https://gerrit.wikimedia.org/r/155841
Change 155841 had a related patch set uploaded by Jforrester:
[WIP] Greylist IE11

https://gerrit.wikimedia.org/r/155841
*** Bug 65688 has been marked as a duplicate of this bug. ***
One of our long-term objectives is for VisualEditor to be enabled by default on all (public) Wikimedia wikis; this is a tracker for that ambition.

As of August 2016, it isn't likely to be completed anytime soon, because some projects differ substantially from the Wikipedia use case for which VE has been primarily designed. For example, Wiktionary pages tend to be composed almost entirely of templates.
@Jdforrester-wmf, you are proposing to work on this task during the Wikimedia Hackathon in Lyon. Please consider associating this task or the specific related task(s) with #Wikimedia-Hackathon-2015.
Change 71259 merged by jenkins-bot:
Add ability to disable for anonymous users

https://gerrit.wikimedia.org/r/71259
Change 71259 had a related patch set uploaded by Jforrester:
Add ability to disable for anonymous users

https://gerrit.wikimedia.org/r/71259
OMG. It's bug number 50000.
Current deployments listed at [[https://www.mediawiki.org/wiki/VisualEditor/Rollouts|mw:VisualEditor/Rollouts]].
>>! In T51999#2735651, @Liuxinyu970226 wrote:
> What about Dutch, that's the only Phase 1 wiki that still haven't done?

Will create a task.
What about Dutch, that's the only Phase 1 wiki that still haven't done?
Change 102208 merged by jenkins-bot:
Enable VisualEditor by default on "phase 4" Wikipedias

https://gerrit.wikimedia.org/r/102208
Change 102208 had a related patch set uploaded by Jforrester:
Enable VisualEditor by default on "phase 4" Wikipedias

https://gerrit.wikimedia.org/r/102208
Change 96473 merged by jenkins-bot:
Enable VisualEditor as default to "phase 3" Wikipedias

https://gerrit.wikimedia.org/r/96473
Change 96473 had a related patch set uploaded by Catrope:
Deploy VisualEditor as default to "phase 3" Wikipedias

https://gerrit.wikimedia.org/r/96473
*** Bug 54866 has been marked as a duplicate of this bug. ***
###Problem
There are various workflows where a user wants to both interact with (or at least see) a page's content, and also interact with a potentially complicated form/process, which may have many controls/inputs.

Some VisualEditor examples:
 - Adding/editing categories (T51969#548266)
 - Adding/editing a template with many parameters
Some non-VE examples:
 - Rater dialog (T51969#2847958)
 - [[https://en.wikipedia.org/wiki/Wikipedia:Twinkle|Twinkle]] dialogs ([[https://github.com/azatoth/twinkle/issues/414]])

###Feature request
Dialogs that have no need to be modal (intended to interrupt the primary workflow, and requiring some action before you can get back to the primary workflow) should be draggable.
Gadget/script/other developers using OOUI should have a simple way to enable this feature, e.g. a config setting that can be set to `true` to allow dragging.

Some specific workflows may have viable alternatives to dialogs, e.g. {T52239}, but that doesn't solve the general problem for more complicated dialog-based workflows.

###Initial task description
Quoth requester: If I can't read the article, because the "page settings" box is large and un-draggable and hides all the article, how can I see what defaultsort or categories I want to add (especially as for defaultsort I probably want to copy and paste all or part of the article title).
>>! In T51969#3224607, @Thryduulf wrote:
> When editing in VE I sometimes have to load a duplicate copy of the page in a new tab so that I can see what I'm doing.
> 
> I dislike the split-screen approach as that uses more screen estate than required and divorces the dialog from its context. I wouldn't object to dockable diaglogs appearing like that at the bottom of the screen as an option, but simply being able to move a reasonably sized box around the screen to a convenient point for the task at hand would be vastly superior imo.

Yes, that exactly sums up the issues.  A moveable window is the best solution.  The issue is being clouded with these alternative solutions and we have ended up with no solution at all.
When editing in VE I sometimes have to load a duplicate copy of the page in a new tab so that I can see what I'm doing.

I dislike the split-screen approach as that uses more screen estate than required and divorces the dialog from its context. I wouldn't object to dockable diaglogs appearing like that at the bottom of the screen as an option, but simply being able to move a reasonably sized box around the screen to a convenient point for the task at hand would be vastly superior imo.
Three and a half years on from my initial complaint, and as far as I know the Visual Editor is still useless to me, so I don't use it. Let me know when it becomes a useful editing system for people who need to see the original article while adding categories or doing other tasks.
I still think something like a split-screen mode would be a better solution for these cases than movable dialogs (see mockup above in T51969#821409).
Yes - when someone tells me that VE is usable, I'll have another look at it. If the dialog box still obscures the content, then for my prolific WikiGnoming it's useless. Two years since I raised this, and no progress. Nice to feel appreciated.
Astonishing this is still open.  I stopped using VE a year or two back because this and other problems made for an inefficient worklow.  Still not time to give it another try I see.
I appreciate this discussion happening. It is strange that we are thinking that draggable dialogs create problems, so I will attempt to illustrate it with a use-case. I am trying to write a user script in oojs-ui, and the script work should be similar to the old gadget whose dialog is draggable to expose different parts of the article text in order to perform its assessment.

Here is the gadget documentation and source code: https://en.wikipedia.org/wiki/User:Kephir/gadgets/rater

Here is a screenshot attached, which I also uploaded to Commons and which is found at the gadget documentation page:

{F4983945}

I would like to be able to perform article rating on the new pages queue continuously one after another, and having draggable dialog reduces the working memory (and increases efficiency) of the process about tenfold, as I don't have to hold the article contents in my memory.
I agree that the dockable model is trying to modify something where we might better look for alternatives. For example, one way to create a new category might be to highlight some text, then select (say) Insert > Category. That could open a dialog (for example, to  allow a different sort key than the default, and to offer the opportunity to create a category if one being created didn't already exist.

This isn't perfect, of course - if a particular category didn't exist (as text) on the page, the user would have to add it, create the category, then delete the unneeded text. Still, maybe it's better, and at least it's something to think about.
>>! In T51969#821409, @matmarex wrote:
> I'm increasingly convinced that draggable dialogs in general are a solution in search of a problem. (It could be interesting to do, but shouldn't be applied to all dialogs.)
> 
>> You're saying that I've got a problem with my workflow: how else do you suggest that I add a category, a stub template, or a DEFAULTSORT to an article, if I can't read the text of the article? I could copy and paste the entire article content into a notepad, so that I could refer to it ... hardly seems reasonable.
> 
> I was thinking, perhaps the dialogs should be "dockable" at the bottom of the screen? Clicking an icon on dialog's title bar would hide the white overlay and dock it, revealing article content. We should think what to do with dialogs that were modal in this case, but I think this approach could work, and could work a lot better than clunky dragging of dialogs (which are often way too large for dragging to make sense, as they would cover most of the content anyway even when dragged aside).
> 
> Here's a rough mockup – note the docking icon on the right. Thoughts?

Eurgh. I really don't like the dockable model of modals. It feels like failure. I'd prefer instead that we provide secondary non-modal ways to do things people want to do that isn't modal. As @Whatamidoing-WMF says, this isn't going to work for anyone that doesn't have a huge desktop screen to use.
>>! In T51969#835122, @TrevorParscal wrote:
> In my view, editing categories should not be a modal experience.

Not **necessarily** modal. The HotCat gadget that this partially replaces is already effectively-modal too, for instance.

> The category editor should simply be embedded at the bottom of the page in place of the category listing.

That's {T52239}.
>>! In T51969#548465, @PamD wrote:
> (In reply to Trevor Parscal from comment #22)
>> I would like to avoid adding moving and resizing to dialogs, because I
>> believe it solving the problem in the wrong way. At it's root, this is a
>> workflow problem. Making the dialog resizable and movable does not
>> adequately address it.
>> 
>>....
> 
> You're saying that I've got a problem with my workflow: how else do you suggest that I add a category, a stub template, or a DEFAULTSORT to an article, if I can't read the text of the article? I could copy and paste the entire article content into a notepad, so that I could refer to it ... hardly seems reasonable.

I am not saying it's a problem with YOUR workflow, I'm saying it's a problem with the workflow we are providing you. I'm admitting we have failed you, and because we didn't understand how you actually use the software we modeled the workflow around our imagined way you might use the software.

In my view, editing categories should not be a modal experience. The category editor should simply be embedded at the bottom of the page in place of the category listing. If we do anything to try and get the dialog out of the way temporarily, we will still not be able to let you select text behind the dialog without breaking the entire concept of a modal dialog. By placing the category editor at the bottom, you are free to scroll around and select whatever you like. This is the experience you have with the Wikitext editor, and there's no reason we can't continue to provide it.
Making the dialog one-third the width of the screen is only going to make sense on a desktop system.  One third the width of a smartphone screen is not going to be functional (the entire dialog box would be a couple of centimeters wide).
The discussion is complicated by the unnecessary "Options" menu on the left side of the dialog box. (I believe this is the **only** place in VE where selecting a choice from a top menu results in a dialog box that shows all the other choices on that menu; that would make sense if an editor were likely to want to do two or three page-related things at once, but in fact he/she almost certainly does *not*.) While redoing the entire approach to how the three-line (should be "Page") menu choices work is probably outside the scope of this topic, I will note that what the requester needs (access to all the text on the page, *while* the dialog is open) is applicable only to **two choices** - categories and default sort. 

For those two menu choices, categories and default sort, I suggest that the dialog attach itself to the **right side** of the window, taking up 1/3 of the width of the window, and that the left side - the text on the page - be scrollable. (If it's easier to program, then perhaps the dialog should be attached on the left, with the scrolling done on the right.) For the other menu choices, a normal modal dialog box is fine.
>>! In T51969#821594, @PamD wrote:
>I don't know the term "dock"  but I think you mean what I'd call "minimise"? 

No, dock does not mean the same as minimise.  Docking is fixing the dialogue to one edge of the window, rather than plonking a popup in the middle of the window.  In the mockup example the dialogue is docked to the bottom of the window.  Applications often give the user a choice of which edge they want to dock to, but I don't know if that is what is propsoed here.

For me, this would work if the window could still be scrolled while the dialogue was open, thus uncovering any content hidden by the dialogue (or even off the boundary of the window at the time the dialogue was invoked).
Looks as if it might work: I don't know the term "dock"  but I think you mean what I'd call "minimise"? So click on that icon, the dialog box shrinks to an icon, I read what's behind it: I hope I can copy text from it, eg to fix a DEFAULTSORT? Then click on the icon to restore the dialogue box and carry on. Yes, could be a great solution. Probably better than my original suggestion, many moons ago, of dragging or resizing.  Thanks.
Indeed, but in this use case you then have to drag it back on-screen to input the category name or whatever.
>>! In T51969#821409, @matmarex wrote:
> ...and could work a lot better than clunky dragging of dialogs (which are often way too large for dragging to make sense, as they would cover most of the content anyway even when dragged aside).

Even if the dialog window is very large, it can still be pushed out of the way by dragging it until it is nearly completely off screen.
I'm increasingly convinced that draggable dialogs in general are a solution in search of a problem. (It could be interesting to do, but shouldn't be applied to all dialogs.)

> You're saying that I've got a problem with my workflow: how else do you suggest that I add a category, a stub template, or a DEFAULTSORT to an article, if I can't read the text of the article? I could copy and paste the entire article content into a notepad, so that I could refer to it ... hardly seems reasonable.

I was thinking, perhaps the dialogs should be "dockable" at the bottom of the screen? Clicking an icon on dialog's title bar would hide the white overlay and dock it, revealing article content. We should think what to do with dialogs that were modal in this case, but I think this approach could work, and could work a lot better than clunky dragging of dialogs (which are often way too large for dragging to make sense, as they would cover most of the content anyway even when dragged aside).

Here's a rough mockup – note the docking icon on the right. Thoughts?

{F19025,size=full}
(In reply to Trevor Parscal from comment #22)
> I would like to avoid adding moving and resizing to dialogs, because I
> believe it solving the problem in the wrong way. At it's root, this is a
> workflow problem. Making the dialog resizable and movable does not
> adequately address it.
> 
>....

You're saying that I've got a problem with my workflow: how else do you suggest that I add a category, a stub template, or a DEFAULTSORT to an article, if I can't read the text of the article? I could copy and paste the entire article content into a notepad, so that I could refer to it ... hardly seems reasonable.

If I want to add a stub template for a Russian footballer, and then discover that not only do I need {{Russia-footy-defender-stub}} but that it's subdivided by date of birth, I need to be able to look at the article and find his date of birth to use {{Russia-footy-defender-1960s-stub}}.  If I want to add a defaultsort, I need to be able to copy the surname, and then the forename, from the text of the article. How should I adjust my workflow?

For the foreseeable future, I've adjusted my workflow by abandoning any attempt to use VE as it makes my editing too difficult.
(In reply to Trevor Parscal from comment #22)
> I would like to avoid adding moving and resizing to dialogs, because I
> believe it solving the problem in the wrong way. At it's root, this is a
> workflow problem. Making the dialog resizable and movable does not
> adequately address it.
> 
> More of these processes should be non-modal, especially authoring edit
> summaries. This would allow users to contribute to edit summaries as they
> work, rather than having to write them at the very end, when the changes
> they've made are so temporally distant.
> 
> Even if the dialog is movable an resizable and movable, the contents below
> are only visible through a semi-opaque mask and the contents cannot be
> scrolled because the modal dialog is capturing events (on purpose, it's
> modal).

This is a good point, but I dont think, its related to this enhencment. You are right, that if I am doing a lot of different changes and/or editing the article several minutes, I forgot, what I was doing. But how this problem is related to the fact, I cannost drag the DW avay to see what is behind?
I would like to avoid adding moving and resizing to dialogs, because I believe it solving the problem in the wrong way. At it's root, this is a workflow problem. Making the dialog resizable and movable does not adequately address it.

More of these processes should be non-modal, especially authoring edit summaries. This would allow users to contribute to edit summaries as they work, rather than having to write them at the very end, when the changes they've made are so temporally distant.

Even if the dialog is movable an resizable and movable, the contents below are only visible through a semi-opaque mask and the contents cannot be scrolled because the modal dialog is capturing events (on purpose, it's modal).
> You can't edit anything, tables, Chinese or galleries, 
> if there is big immovable box in the way.

This isn't really true:  you can close the box.  With the box open (and movable), you can *see* the content on the page, but you still can't edit it.  When you've got a dialog box open, but all your typing ends up on the page underneath the box, then we call that a bug.

The problem here is that (depending on the size of the box and the exact location of your cursor when you open it), what you need to *see* on the page might be covered up by the box.  "Open box, realize that you've forgotten how to spell something, realize that the box is covering up that word, close box, check spelling, open box again, finally type" is not as efficient as "Open box, drag it out of the way, start typing".
(In reply to James Forrester from comment #18)
> (In reply to Spinningspark from comment #17)
> > Why is this languishing at low priority? Fixing something that is preventing
> > the editor from reading the thing he is editing is HIGH priority.
> 
> "High" priority would mean that it's more important than editing tables,
> editing in Chinese, or editing galleries. "High" priority is not appropriate
> for this relatively minor and very complex enhancement request.

You can't edit anything, tables, Chinese or galleries, if there is big immovable box in the way.
Just to be clear, this is a DESIGN TEAM problem, because it's a problem with the OOjs UI, which VE uses, but which is under the control of the Design team. The issue is that the OOjs UI WindowManager lacks a resizing event. That issue affects every use of windows in the OOjs UI, not just VE's use of windows.

Why isn't this bug showing on the list of problems that the Design Team is considering (https://bugzilla.wikimedia.org/buglist.cgi?keywords=design&keywords_type=allwords&list_id=335932&order=changeddate%20DESC%2Cvotes%20DESC%2Cpriority%2Cbug_status%20DESC%2Cassigned_to%2Cbug_id&query_format=advanced&resolution=--- )? (I got that list via https://www.mediawiki.org/wiki/Design ) 

Relatedly, why is the priority for fixing this bug being set by the VE team, rather than by the Design team?
(In reply to Spinningspark from comment #17)
> Why is this languishing at low priority? Fixing something that is preventing
> the editor from reading the thing he is editing is HIGH priority.

"High" priority would mean that it's more important than editing tables, editing in Chinese, or editing galleries. "High" priority is not appropriate for this relatively minor and very complex enhancement request.
Why is this languishing at low priority? Fixing something that is preventing the editor from reading the thing he is editing is HIGH priority.
*** Bug 67952 has been marked as a duplicate of this bug. ***
Moving to the OOjs UI product as that code is now shared.
Please see https://upload.wikimedia.org/wikipedia/commons/d/d9/Wide_edit_window_%28Proposal_for_Wikimedia_VisualEditor%29.png for an example of what a wide window might look like for reviewing changes.
The change review window is also too small to be useful for some editors, especially if a lot of changes have been made.
Understandable. You will receive a bugmail notification once this bug report is fixed.
Let me know when this is fixed, because I'm not going to stress myself by using VE until then - it just makes my everyday editing too much like hard work. When it's fixed (and perhaps a few more of my long-standing complaints - hidden comments, red links appearing as red, etc), I might carry on with debugging your system. Till then, why should I bother?
(In reply to comment #9)
> Two months since there's been any comment on this ... I admit I've pretty
> much
> given up using VE (too tedious because of this and other problems, plus some
> stuff going on in Real Life which makes me want to reduce Wikistress). Any
> chance of it getting fixed some time? I'm sure I'm not the only person
> affected.

Some time? Yes. Soon? No. In my view, it's not as important as fixing things like copy-and-paste or adding citation template quick-add support or editing tables.
Two months since there's been any comment on this ... I admit I've pretty much given up using VE (too tedious because of this and other problems, plus some stuff going on in Real Life which makes me want to reduce Wikistress). Any chance of it getting fixed some time? I'm sure I'm not the only person affected.
Prioritisation of work is done on how much it interferes with people using the software, not how long ago it was first mentioned as an issue. For example, bug 4 (!) is from 2004.

I'm sorry that this is getting in the way of your use of VisualEditor, but I think that adding copy and paste support (for example) should happen first. I could "upgrade" the importance of this to "high" but it wouldn't get the code written any faster. :-(
Six weeks on from first request it's depressing to see this is still "low enhancement". Example: stub-sorting a Russian icehockey player, I open the dialog box to remove the existing stub tag and then go to the dropdown menu to add "Russia-icehockey-bio-stub", only to discover that there are separate stubs for wingers, goalies, etc. I didn't notice what he was.  I have to quit the dialog box, find he's a winger, re-open it, re-delete the old stub, return to the dropdown menu to add the new stub template.  The inability to move or shrink the dialogue box makes ordinary routine wikignoming harder work. But I suppose the target market of newbies don't do things like that, and we established editors can be trusted to struggle on regardless (some of us, perhaps a diminishing number), however ignored our needs may be?  

Yes, I could abandon VE and this wouldn't trouble me any more, but I'm trying to help by persevering in using it to help you debug it. In return, how about a little attention to one of the first issues I raised?
How hard is it to make the dialog box moveable? Really? There is what, one parameter that needs to be changed? If this were a really hard problem, it would be understandable that the VE team was deferring this for more important things. But it's not that hard (I hope; if so, that bodes poorly for VE), and it impacts LOTS of editors. Yes, it affects the dialog box for page settings, when doing categories. But there is the identical problem when adding a caption for an image (Media settings dialog; might want to know how something in the article is spelled) and possibly for the other dialog boxes (for example, in the Media dialog, searching for an image where the search term has an unusual spelling).

Even better would be the ability to copy/paste from the main editing window to a field in the dialog box. I realize that has potential ramifications for loss of focus - it would be undesirable for the dialog box to disappear *behind* the main editing window. Still, in Mac OS X, the "Force Quit Applications" dialog box is moveable, and the user is able to copy text from other windows, but the dialog box remains on top of every window until it is closed. (Excessive, actually: the ideal is to have the VE dialog box float on top of the main editing window, ONLY.)

But we (as in, Wikipedia editors) would settle for a really minimal solution, initially - just make the dialog boxes moveable. Please?
Any movement on this? Low-priority according to the development team, I accept, but it's a pretty important chunk of the editing workflow for a lot of tasks.
If I want to add "Category:1917 births" and "Category 1987 deaths" to an article, is it undesirable multitasking to expect to be able to see the lead sentence which says "'''Joe Bloggs (1917-1987)...", rather than having to remember the two dates? Or if I want to assign "Category:Villages in ..." for some area whose placenames are unfamiliar and have difficult spellings? Please let me see the article while adding categories: a simple way would be to let me drag, or shrink, the dialogue box which at present totally obscures the article text. (I was the original reporter of this bug on 21 June, and the response above seems to misunderstand its importance.)
(In reply to comment #1)
> The idea of the dialog being modal is that you aren't multi-tasking with it
> at all.

This isn't asking for multi-tasking, it's asking for the ability to drag the dialog out of the way so that you can get context for the single-tasking, err, task. :-)
Makes sense.
The idea of the dialog being modal is that you aren't multi-tasking with it at all.

As far as adding a category or changing the default sort of a category directly from some other mode (such as reading, or editing paragraph text) we should look at those workflows rather than dissolve the intentional model-ness of the dialog.

For example:

- Perhaps categories could be edited at the bottom of the page, rather than inside a dialog.
- Maybe the category editor could use some other kind of UI container that isn't modal.

etc.
When in the template editing dialog, a link going to the [template:name] page, would be really helpful for:
* Reading detailed documentation
* Easy access to (edit or examine) template source code

**See Also**:
* {T52354}
* {T52656}
* {T53311}
Change 257443 merged by jenkins-bot:
MWTemplatePage: Show a link to the template even when there's a description

[[https://gerrit.wikimedia.org/r/257443]]
Change 257443 had a related patch set uploaded (by Jforrester):
MWTemplatePage: Show a link to the template even when there's a description

[[https://gerrit.wikimedia.org/r/257443]]
Exists templates with variable parameter names. If you create a tTD for a part of the parameters, then it just do not describe the other part of parameters and disappear link to the documentation. eg https://ru.wikipedia.org/wiki/Ш:Familytree
MediaWiki doesn't enforce any particular page being a documentation page, it's a thing made up by users.
If this wasn't clear enough, the user asks for a link to the template /documentation/ page.
Here's another example of the need to access documentation page:
https://bugzilla.wikimedia.org/show_bug.cgi?id=67986#c1
If the user doesn't read the template's manual, he currently has no way to guess that there may be several required parameters and which ones he needs to fill for the template to work correctly.
This is being asked at ru.wp even for templates which have TemplateData info;
quoting the reasoning, the user wants to be able to access:
-full template documentation 
-see more examples of which are difficult to describe in words 
-read about other similar templates 
-edit template data.
This was done two months ago for templates which lack documentation; I'm closing this as a "WORKSFORME" at this point, as if the user has to go read the template's page to understand what the documentation is telling them, the creator of the documentation has utterly failed.
This bug seems to have strayed/widened far from the original simple request (which I remember also making on the feedback page at some point many days ago): when one is adding a template ("transclusion"), a button to link to the template page would be very useful - to be able to read all the detailed description there. Look at [[Template:Genukiwry]] as an example - it couldn't all be coded up into TemplateData, but it could be made accessible by providing a simple link which would open in a new tab / new window / popup (ie anything which wouldn't spoil the ongoing editing operation). This facility would be an area where VE could provide a better editing experience than Edit Source, and surely wouldn't need a huge programming effort.
I googled "mediawiki glossary" and found this: 
*[[mw:Manual:Glossary]] - now bookmarked. :)

I am not using "parameter" correctly in the context of MediaWiki. I couldn't find "parser" listed in the glossary. :)

My point with both bugs is to get links to the template pages so that people can edit them in wikitext source mode there on the template page. Nothing more. I am not interested in being able to edit templates within VE at all. 

In fact, With the exception of reference templates I think editing of templates within VE should be disabled since it is not WYSIWYG, and only adds a new layer of abstraction. I think the only thing that should be provided by VE is a link to the template page. 

If an editor of Wikipedia like me with 26,000 edits does not understand the terms (parameter) used in VE template editing, then imagine the difficulty new editors have when they see those terms listed in VE template editing. 

I would like VE mainly to do text editing and references. Nothing more for now. I think people would be ecstatic with that. Since there are so many reference templates, I think that alone may require an increase in the number of paid full-time developers assigned to VE. 

I actually understand a lot about table editing and template editing, but only at the wikitext editing level. I can do it, but not always explain it, since my knowledge mostly comes from hacking at it over the years. :) I help edit this page:
*[[Help:Sorting]]
Here is a page that has a table and a couple transcluded navigation-box templates at the bottom:
[[List of countries by incarceration rate]]

With VisualEditor (VE) the table is editable and WYSIWYG.

But with VE the existing text in the 2 navigation boxes can not be edited as far as I can tell. At least not within VE from that page. I am talking about after clicking the edit icons for the navigation boxes. 

New parameters can be added to one of the templates, but not to the other. I don't see a way to edit the text for existing parameters in either navigation box. 

So to be able to edit one of those templates in source mode or otherwise it would be helpful to have a direct link to the transcluded template page, and not to the many templates that make up such a navigation box at the core level. 

See related bug 878.
This is more of a tracking bug than anything else, but it should be something people are aware of and something that's formally logged; the VisualEditor is very slow on large articles, to the point where it causes confusing output.

Using the example of https://en.wikipedia.org/wiki/OpenOffice - I edited this and it took a good 20 seconds just to render 'review changes', and another 20 to save. David Gerard did the same and the server popped up  "Error saving data to server: timeout." with both 'review' and 'save'. Despite this, it saved anyway.

Obviously as a long-term thing: we shouldn't have an editor so slow that someone in an industrialised, Western nation (i.e. the UK) can't make things work.[1] As a short-term thing, we shouldn't be informing users "something has gone terribly, terribly wrong, abort!" when it has actually saved.

[1] It's David Gerard, he's not going to be using dial-up.

--------------------------
**Version**: unspecified
**Severity**: normal
Let's use #VisualEditor-Performance instead.
Update on the test Oliver mentions at the top: on the same PC and the same Internet connection (though a current version of Firefox), it just now took:

* 10 seconds to open [[OpenOffice.org]]
* 176 seconds (nearly three minutes!) to render the "Review your changes" diff
* two minutes attempting to save, then "Error: Unknown error". The edit did, however, save: https://en.wikipedia.org/w/index.php?title=OpenOffice.org&diff=597641893&oldid=593809275

It's a ... test subject ... of a page.
another stopped sript warning

**Attached**: {F11497}
Firefox chokes

This happens /before/ script-stop warnings.

**Attached**: {F11496}
Stopped script warning

**Attached**: {F11495}
It was previously doing a very dirty diff; I just tried again on this article and it did a clean diff, but timed out when I hit "save", three times in a row, and didn't actually save any of them.
(In reply to comment #3)
> It may also be worth noting that this page takes ~30 seconds in my use to
> save when using the ordinary source wikitext editor - it's a complex page!

Yes, one of the problems is that VE being slow is rather more noticeable than MW being slow (because "it's a website" and so triggers different time response expectations in users). :-(
It may also be worth noting that this page takes ~30 seconds in my use to save when using the ordinary source wikitext editor - it's a complex page!
Listing the issues so it's clear what we mean by "performance issues" and their different causes and artefacts:

* [network] VE slow to load own JS - mostly provided by ResourceLoader and local cacheing so this would only be a slowness once per user's browser (assuming they don't clear their local cache); we could pre-load VE JS for all users on read, which would reduce load times when people press edit slightly, but that is evil

* [network] VE slow to fetch HTML from Parsoid - mostly fixed due to highly-aggressive caching at our cluster (the payload is slightly smaller in byte size than the read page fetch, i.e. not significant)

* [client] VE slow to render Parsoid HTML into an editable document - we're working on this (profiling etc.), but there's a tension between editability and simplicity of data structure. :-)

* [client] VE slow to respond to user action - same as above; this is the core "performance" area for VE itself, of course

* [server] VE slow to get a wikitext diff - this relies on two operations; a Parsoid serialise and an MW wikitext diff: we can work with Parsoid on that being faster, but there's a limit; theoretically we could pre-serialise as we go (but eww network traffic and load on the servers)

* [server] VE slow to save edit - this is essentially the same performance issue as getting the wikitext diff, above; theoretically we could optimise by saving the output of the serialise from a wikitext diff, but this won't be triggered for most users, so it's of marginal utility
Specifically, 8Mbit ADSL through Zen. Most of the slowness appears to be thinking - I could hear my laptop's CPU fan speed up.
From [[https://phabricator.wikimedia.org/T50429#518092|a comment]] on T50429.

>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 VisualEditor. That would be so convenient and so useful. Later on, this functionality could be extended to anything the VisualEditor can't edit. People could click on templates, tables, etc. inside the VisualEditor 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.

**See also:**
T50429
T51664
T49779
Is this still relevant now that {T49779} is resolved?
[From bug 48429 comment 20.]

Switching to "edit source" tab when VE was triggered via a section-edit link should enter the wikitext editor for that section, rather than the entire page.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=48429
https://bugzilla.wikimedia.org/show_bug.cgi?id=49665
In the end we went with bug 49666, which is now done (code to be deployed this afternoon). As discussed above (and I agree), changing behaviour between wikitext section edit behaviour as currently is and the way it works post-VE roll-out - but only on VE-enable-able pages (i.e., not talk pages/etc.) would be complicated and not add value to users.

Consequently, closing this as INVALID.
Bug 49665 may be another solution: "VisualEditor: Provide a get-me-into-the-wikitext-editor link on every header". 

It looks like there will be an "edit" link and "edit source" link (or icon) on every header.See bug 49666.

If the header "edit source" links (or icons) remain clickable (and/or right-clickable) from within VE, then that would be a solution for getting into the source editor for sections.
(In reply to comment #3)
> (In reply to comment #2)
> > "Edit Source" never even existed before Visual Editor
> 
> Not even remotely true. The "Edit Source" tab is the relabelling of the
> regular
> "Edit" tab.
> 
> I'm minded to agree with This, that and the other, but willing to be
> convinced.

I see now what you mean, but my point still stands: "edit source" is not something that warrants use of the word "always", as it's completely new, introduced with visual editor... there was no "edit source" anywhere before VE.
for all i care, we do not even need "edit source" on the page when reading it, "Edit" is enough, as long as there *is* "edit source" once VE fires up. as to what should be the action of this "edit source", i believe it should put you in the same spot you would have been if VE was not enabled. in the case you entered edit state through an editsection linkette, this means edit section.

however, it is possible in this case to eat the cake and have it too, by rephrasing the original ticket, so let me try to do this:

====== ORIGINAL TICKET REPHRASING ===========
When the user press the editsection linkette and VE is enabled, a new top menu item should be generated: "Edit section source", next to "Edit source". pressing this menu item is equivalent to pressing the editsection link when VE is disabled.

Not allowing this functionality basically means that there is no way to execute section edit of wikitext if VE is enabled, which, IMO, is a serious regression.
(alternatively, pressing the "edit source" linkette should open a dialog asking if the user wants to edit the whole article or just the section).
============== END REPHRASING ===============

peace.
(In reply to comment #2)
> "Edit Source" never even existed before Visual Editor

Not even remotely true. The "Edit Source" tab is the relabelling of the regular "Edit" tab.

I'm minded to agree with This, that and the other, but willing to be convinced.
(In reply to comment #1)
> This behavior would be confusing and would break the consistency of the "edit
> source" tab always going to the whole-page editor. 

forgive my bluntness, but this is plain silly.
what do you mean "source tab always going to the whole page"? we are not discussing "View Source" tab, we are discussing "Edit Source" tab, which is something completely different.
"Edit Source" never even existed before Visual Editor and the reference to "always" does not make any sense: this project is slowly making its way from alpha to beta, and there is no "backward compatibility" or past behavior this thing should feel obliged to.

peace.
This behavior would be confusing and would break the consistency of the "edit source" tab always going to the whole-page editor. 

Perhaps displaying the UI of bug 49666 while in VE edit mode would be a better solution to this. I'd be interested to see the resolution of bug 47779 first though.
These links being red at all come about because content of templates is rendered by the PHP parser, which sets class="new" (Parsoid itself doesn't hint about target colour yet). However, because dialogs are implemented as <iframe>s, we can't inherit MW's CSS for the body element, so they appear differently.

--------------------------
**Version**: unspecified
**Severity**: minor
Now fixed as of last month.
There's a search-and-replace tool in the wikiEditor which some users might miss and would like in VisualEditor somehow.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Change 174491 merged by jenkins-bot:
Find and replace

[[https://gerrit.wikimedia.org/r/174491]]
Same. See the commit above.
>>! In T50368#776888, @Esanders wrote:
> For now I think the tool can go in the hamburger menu on the right.

What about in non-MW integrations?
For now I think the tool can go in the hamburger menu on the right.
https://gerrit.wikimedia.org/r/#/c/174491/
(In reply to Eran Roz from comment #12)
> I can only think of "Language" and "Replace", so I guess we don't have
> enougth tools right now for a new menu.
> (or maybe the "advanced" options (page settings, categories etc...) is
> actually "tools" menu?)

We've been struggling with what to do with categories (which are pretty vital) compared to "don't show TOC" (which is pretty rare). Suggestions for improvements to the toolbar are always welcome. :-)
I can only think of "Language" and "Replace", so I guess we don't have enougth tools right now for a new menu.
(or maybe the "advanced" options (page settings, categories etc...) is actually "tools" menu?)
(In reply to Eran Roz from comment #10)
> Yes, I would like if it would be possible to create an extra different menu,
> instead of adding all the tools to mislabelled "Insert". I think the new
> "Language" option will also fit here.

Hmm. Possibly. I was thinking of putting it in the "text styling" menu, but it could live here.

Is there anything else that would live in the "Tools" menu? (Note that the obvious items to go in a "tools" menu – copy, cut, paste, paste formatting – can't be done in Javascript at all, sadly.)
Yes, I would like if it would be possible to create an extra different menu, instead of adding all the tools to mislabelled "Insert". I think the new "Language" option will also fit here.
(In reply to Eran Roz from comment #8)
> We have a first working draft for replace tool for VE:
> https://en.wikipedia.org/wiki/User:%D7%A2%D7%A8%D7%9F/veReplace.js

This ends up in the (mis-labelled) "Insert" menu, right? Would it be helpful it we created a category of tool to manipulate the contents (a spelling or grammar tool might also fit here, though again it's something you'd generally expect your browser to provide)?
We have a first working draft for replace tool for VE:
https://en.wikipedia.org/wiki/User:%D7%A2%D7%A8%D7%9F/veReplace.js

It works and replace the specified text, and undo&redo are properly supported (the last is just a claim that we didn't hack the VE too much :) ). 
Currently it does only "replace all" but it can be easily extended with simple replace function, regexs and more... 
We didn't "publish" it yet in village pumps since we want to do add at least some of this features before.
(In reply to Eran Roz from comment #6)
> As part of the work on
> [[meta:Grants:IEG/Visual_editor-_gadgets_compatibility]], I plan to work on
> [[meta:User:Pathoschild/Scripts/Regex menu framework]], that should give a
> quick&dirty workaround to this issue.

Consider using the new version of that script instead:
[[m:User:Pathoschild/Scripts/TemplateScript]]
I agree with Amir. This is regression as this option is already available in WikiEditor and it is very basic functionality (available even in simple notepad), so it isn't an enhancement but at least normal (or major?) bug.

As part of the work on [[meta:Grants:IEG/Visual_editor-_gadgets_compatibility]], I plan to work on [[meta:User:Pathoschild/Scripts/Regex menu framework]], that should give a quick&dirty workaround to this issue.
Somebody told me that my comment was unclear: when I say that it's a regression and not an enhancement, I mean that the *lack* of search and replace functionality is a regression, and the request to have it should be treated as a bug report and not as an enhancement request.
I'd say that it's a regression and not an enhancement.
This still seems to be a popular request from users at multiple Wikipedias.
*** Bug 53326 has been marked as a duplicate of this bug. ***
As long as it doesn't have the same performance issues which makes it unusable (bug 23510), I support this. :-)
The difference between editing and reading mode isn't obvious enough for the user.

(reported at http://de.wikipedia.org/wiki/Wikipedia:Technik/Text/Edit/VisualEditor/Alpha2013-04#Unterschied_Bearbeitungsfenster_und_gespeicherter_Artikel)

--------------------------
**Version**: unspecified
**Severity**: enhancement
This seems, well, almost trivial to implement. Here's what I have in my common.css to do this when I edit:

.ve-ce-surface { background: #FFFDD0; }

That's a personal color choice, of course. I'd be happy to defer to the consensus of a larger group of VE users about a better color. But other than choosing a color, this seems like an enhancement that can relatively easily be put in the "done" category.
What's the virtue of having no difference between reading and edit mode? I see none. If I'm in editing mode, I want to be reminded that I still need to close off the edit properly (give edit summary, save page), rather than accidentally just close down all tabs, or leave the computer and let it close itself messily after x hours). I may be juggling several open windows, in connection with the one edit or with other jobs (and because the page dialog obscures the article, I'm often opening a second copy of the page while I'm in VE so that I can actually see it while adding a category or stub template, as being quicker than closing the dialog box to see the information I need). Editing and reading are two different activities: someone editing has responsibilities - not to accidentally lean on keys and produce garbage, not to leave the page without a helpful edit summary. Someone reading... is just someone reading.
*** Bug 50456 has been marked as a duplicate of this bug. ***
Bug 48272 should help a little, changing the browser tab and title when editing. The reporter wanted a change within the content area, such as a red border while editing.
This is somewhat of a deliberate choice - indeed, a long term goal is to be able to have no distinction at all between 'read' and 'edit' modes (except that in one you'll have a cursor) - though we may not do this for Wikimedia's servers, and certainly not soon.

I'm willing to consider suggestions about making it a little more obvious without breaking the fundamental concept that editing and reading are two halves of the same participation, but marking this as Lowest/Enhancement to reflect this.
The link inspector doesn't open. Clicking the little button causes it to animate as if it was opening, then disappear completely.

I'm investigating.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Sweet, link editing is now possible. Now we just need bug 47793 fixed and Opera will be basically on par with other browsers in temrs of VE support.
Change 61365 merged by jenkins-bot:
Revert "Address error caused by changing focus from context menu to window."

https://gerrit.wikimedia.org/r/61365
Ie4f1334e is just a proof-of-concept, not really a patch yet.
Related URL: https://gerrit.wikimedia.org/r/61365 (Gerrit Change Ie4f1334e0beb7ba7d4f4aa3b42464fa219c4778c)
Something causes ve.ce.SurfaceObserver.prototype.stop() to be called without a subsequent call to ve.ce.SurfaceObserver.prototype.start().

Apparently happens after clicking on a link. I'm investigating.

--------------------------
**Version**: unspecified
**Severity**: normal
I'm hacking around mutation observers.. maybe we will get rid of SurfaceObserver soon (and get rid of those kind of problems).
Fixed a second time. Maybe. :-)
Change 77639 merged by jenkins-bot:
Actually fix bug 47793 for Opera for real this time

https://gerrit.wikimedia.org/r/77639
Change 77639 had a related patch set uploaded by Matmarex:
Actually fix bug 47793 for Opera for real this time

https://gerrit.wikimedia.org/r/77639
Hooray! This shouldn't be causing issues anymore now.
Change 71249 merged by jenkins-bot:
ve.ce.Surface: Prevent focus loss on the document node in Opera

https://gerrit.wikimedia.org/r/71249
Change 61358 abandoned by Matmarex:
Don't bind 'blur' and 'focus' on the document node in Opera

Reason:
A different approach in I7962f59bd02e0.

https://gerrit.wikimedia.org/r/61358
Change 71249 had a related patch set uploaded by Matmarex:
ve.ce.Surface: Prevent focus loss on the document node in Opera

https://gerrit.wikimedia.org/r/71249
Gotcha. Why does Opera have to be weird...
Related URL: https://gerrit.wikimedia.org/r/61358 (Gerrit Change Iaaa2a7993f3561dc663a064468c396ebfe951ce7)
ve.ce.Surface.getSelectionRect() throws errors in Opera. I think this is the root cause of bug 37861 and likely various other issues.

It seems that rangySel.get{Start,End}DocumentPos consistently fails in Opera, because nativeRange.getClientRects() inside of the private createClientBoundaryPosGetter() function returns an empty collection. This causes the "Cannot get position for range ..." error to be thrown.

I'm still investigating the why, I'm just putting this here. Changing getSelectionRect() to just always return some static value seems to work (or at least not fail miserably anymore).

--------------------------
**Version**: unspecified
**Severity**: normal
The fix is merged now. Marking as fixed.
(Done is PS2.)
Hmm, apparently this also happens for non-empty selections in some cases. We're gonna need a larger workaround...
Related URL: https://gerrit.wikimedia.org/r/61190 (Gerrit Change I4bad882d1d6fb83bcdcfd0de3bfc9af52960c2ff)
This seems to work:

>>> range = document.getSelection().getRangeAt(0)
Range 
>>> span = document.createElement('span')
<span/>
>>> range.getClientRects()
ClientRectList []
>>> range.surroundContents(span)
undefined
>>> $(span).offset()
{ left: 352, top: 1025 }

Now we just have to substract window.scrollY from the 'top' value and remove the <span> from the DOM again. (And don't call .getClientRects() on that Range again, as it returns a completely bonkers huge list of values.)
So, what happens is that in Opera, for zero-length ranges (ie, just a caret, no selection):

* .getSelection().getRangeAt(0) returns a Range
* but then .getClientRects() returns an empty ClientRectList
* and .getBoundingClientRect() returns a rectangle with all values being 0
**Author:** `suitongbowgn`

**Description:**
Feature request:

A feature that supports insertion and simple editing of source code snippets in a general article. It may include a simple grammar checking mechanism which checks some fundamental grammatical errors such as having a { without closing it, having a () with a trailing period and nothing else, having solely a pair of brackets, etc.; an indentation correction tool which will perform indentation formatting on the codes; a beautify code tool which will reorganize code formatting, including indentation to make the code more reader-friendly in format.


Features:
* Insert or edit a code block.
* Basic IDE features (perhaps re-use WikiEditor/CodeEditor)
 * Syntax validation (matching quotes/parenthesis/braces etc.)
 * Follow indentation level when breaking lines.
 * Live grammar highlighting.
Change 247474 merged by jenkins-bot:
Use Ace editor widget for code input

[[https://gerrit.wikimedia.org/r/247474]]
Change 247851 merged by jenkins-bot:
Introduce Ace editor widget

[[https://gerrit.wikimedia.org/r/247851]]
Change 247851 had a related patch set uploaded (by Esanders):
Introduce Ace editor widget

[[https://gerrit.wikimedia.org/r/247851]]
Change 247474 had a related patch set uploaded (by Esanders):
WIP Use Ace editor when available

[[https://gerrit.wikimedia.org/r/247474]]
A first step would be putting making an RL module for Ace in core. Each language is a separate JS file so we'd want submodules for each, like we used to do with GeSHi.
>>! In T49742#1645908, @Esanders wrote:
> I think the best approach would be to convert the editor to a dialog and drop in CodeEditor's existing code editor (Ace), or some equivalent (CodeMirror).

That could work.
I think the best approach would be to convert the editor to a dialog and drop in CodeEditor's existing code editor (Ace), or some equivalent (CodeMirror).
Change 114529 had a related patch set uploaded by Jforrester:
[WIP] Add VisualEditor support

https://gerrit.wikimedia.org/r/114529
Re-opening as this is now unmerged.
Marking this also as fixed by gerrit 68615 - congratulations again!
**suitongbowgn** wrote:

Yes.

(In reply to comment #19)
> GSoC "soft pencils down" date was yesterday and all coding must stop on 23
> September. Has this project been completed?
GSoC "soft pencils down" date was yesterday and all coding must stop on 23 September. Has this project been completed?
**suitongbowgn** wrote:

For now no codes from GeSHi are directly reused. I just used them as reference for regex patterns. I said 'port' due to this fact.

(In reply to comment #17)
> (In reply to comment #15)
> > Have you considered using an existing highlighter
> > library, or at least basing your implementation on a existing language spec
> > format (e.g. implementing GeSHi language specs in JS?)
> 
> GeSHi is GPLv2+, whereas VisualEditor is MIT.  So if any GeSHi code is
> reused,
> the authorship and licensing should be made clear.
(In reply to comment #15)
> Have you considered using an existing highlighter
> library, or at least basing your implementation on a existing language spec
> format (e.g. implementing GeSHi language specs in JS?)

GeSHi is GPLv2+, whereas VisualEditor is MIT.  So if any GeSHi code is reused, the authorship and licensing should be made clear.
**suitongbowgn** wrote:

The highlighter spec is ported from GeSHi's php into js. I didn't find spec for validator so I came up with myself.

(In reply to comment #15)
> Tongbo: Re: your implmementation so far: Is the language spec something
> you've
> come up with yourself? Have you considered using an existing highlighter
> library, or at least basing your implementation on a existing language spec
> format (e.g. implementing GeSHi language specs in JS?)
Tongbo: Re: your implmementation so far: Is the language spec something you've come up with yourself? Have you considered using an existing highlighter library, or at least basing your implementation on a existing language spec format (e.g. implementing GeSHi language specs in JS?)
CCing Andre who can give you editbugs.
If you don't have permission to do it yourself, it's probably because you don't have the 'editbugs' right.  Hopefully, someone on this bug can give it you.  If not, ask on IRC.
Change 68615 had a related patch set uploaded by Jforrester:
Source code editing

https://gerrit.wikimedia.org/r/68615
**suitongbowgn** wrote:

Somebody with the power could you change the bug status to assigned, and it was assigned to me.
Also anyone who is interested please feel free to give code review at the following patch.

> Related URL: https://gerrit.wikimedia.org/r/68615 (Gerrit Change
> I4adede9e05fd2236cee50ce03f597e8ff6b1914d)
Related URL: https://gerrit.wikimedia.org/r/68615 (Gerrit Change I4adede9e05fd2236cee50ce03f597e8ff6b1914d)
Just a note to say that Tongbo Sui has submitted a GSoC proposal related to this report: https://www.mediawiki.org/wiki/User:Beanixster

Good luck!
**suitongbowgn** wrote:

In a nutshell it would be a major front-end JS work and will leave backend as-is as much as possible. I'm pretty sure that it will only utilize tags currently available and won't affect backend at all.(In reply to comment #6)
Given that this is about desired enhancements to a VisualEditor plugin for the SyntaxHighlight extension - bug 43126 - moving this there and marking as a dependency.
**suitongbowgn** wrote:

I understand that the rich text is just a presentation and I can see in article source that the formats are defined using a set of markups. What I'm proposing is a plugin/feature which will take care of write the markup(plaintext) for the user when editing code snippets, just like what VisualEditor is intended to do (in my opinion). In addition source code needs special formatting that is different from natural written human language, so that's why I think the feature should include automatic indentation and such.
For editing just a part of the text, I'm thinking of an interface similar to a pop-up window, obscuring parts of the editing window. Just like when you insert an image the editor will have a new window pop up asking image url, alt text, target, etc. When you click insert the editor will convert your choice in that pop-up window to the plaintext with tags and other markups, which will be visually reflected in the main WYSIWYG editor.

(In reply to comment #5)
> Ah, it seems I misunderstood, sorry. I though you are talking about the
> source
> code *of the article itself*, and it appears like you meant source code in
> different languages, such as what's included in a <syntaxhighlight> tag.
> 
> Sorry and please disregard my comments :)

(In reply to comment #4)
> Making sure that arbitrary wikitext does not interact with other parts of the
> page is difficult. It is possible to enforce this for extension content, but
> generally not for arbitrary parts of a page.
Ah, it seems I misunderstood, sorry. I though you are talking about the source code *of the article itself*, and it appears like you meant source code in different languages, such as what's included in a <syntaxhighlight> tag.

Sorry and please disregard my comments :)
Making sure that arbitrary wikitext does not interact with other parts of the page is difficult. It is possible to enforce this for extension content, but generally not for arbitrary parts of a page.
If anything, it seems like this request would build on top of that one. It's currently just not possible to edit almost anything else than plaintext in VisualEditor (and it's not just an interface issue, but a backend one as well).

I'm reopening and marking as dependent on that one, then. Feel free to adjust this :)
**suitongbowgn** wrote:

I believe that request is too broad and this one is more specific. (In reply to comment #1)
> 
%%%> *** This bug has been marked as a duplicate of bug 43133 ***%%%
*** This bug has been marked as a duplicate of bug 43133 ***
I'm interested in thinking along/working on image recognition (and classification) on Commons. See also T155538.
@WereSpielChequers That sounds great! Thanks for willing to mentor :) I'm going to link your Phabricator username in the hackathon task, and if someone wants to reach out to you for questions, they can comment here or msg you on Phabricator?
I'm happy to mentor, though my availability is limited at present. Email me if a Skype chat would be useful.
I'm adding this task here T154988. Let me know if it is not a good idea to do so :) Also, if it's fine as it is in the linked task, would someone be willing to be a point of contact/ mentor/ available to answer questions for this task during the hackathon?
I'm adding this task here T154988. Let me know if it is not a good idea to do so :)
I'm not sure I'd call it "standard".  Image processing is a notoriously difficult problem.  See https://xkcd.com/1425/ for relevant discussion.
@Halfak this looks like an interesting and standard ML thing. Can this be structured as a research project to do a feasibility study of methods for image category suggestions for current round of GSoC, Outreachy, RGSoC internships?
(NOTE) This task was proposed in the #community-wishlist-survey-2016 and in its current state needs owner. Wikimedia is participating in [[ https://www.mediawiki.org/wiki/Google_Summer_of_Code_2017 | Google Summer of Code 2017 ]] and [[ https://www.mediawiki.org/wiki/Outreachy/Round_14 | Outreachy Round 14 ]].  To the subscribers -- would this task or a portion of it be a good fit for either of these programs? If so, would you be willing to help mentor this project? Remember, each outreach project requires a minimum of one primary mentor, and co-mentor.
IMPORTANT: This is a message posted to all tasks under "Need Discussion" at Possible-Tech-Projects. Wikimedia has been accepted as a mentor organization for GSoC '16. If you want to propose this task as a featured project idea, we need a clear plan with community support, and two mentors willing to support it.
Hi. I am new to image recognition, so I think this could be a great learning opportunity for me. I would really appreciate it if I could get some help understanding the scope of this project and also help me find mentors, or suggest how I could get in touch with possible mentors. I am interested in applying for this project in Outreachy 11, but if that doesn't work out, I think this would still be a really great learning opportunity for me and I would like to contribute to it nonetheless. Thanks.
The description says "Possible mentors: Kristian Kankainen (Keeleleek); WereSpielChequers?" CCing @werespielchequers, couldn't find Kristian.

I'm also adding #Community-Tech, since this feature looks like within their scope of tools helping experienced editors. Please remove it if this is not correct.

It looks like this task needs a bit of discussion to confirm that it is a good fit for #Possible-Tech-Projects. Is it a feature that is needed and the community would welcome? Is the estimated project time for a senior contributor around 2-3 weeks?
Hi. I think this project is very interesting. I want to work on this in the upcoming round of Outreachy and I want to know what is expected out of me in terms of the skills and background knowledge required. Please let me know how I can contribute. Thanks.
This is a message sent to all #Possible-Tech-Projects. The new round of [[ https://meta.wikimedia.org/wiki/Grants:IEG | Wikimedia Individual Engagement Grants ]] is open until 29 Sep. For the first time, technical projects are within scope, thanks to the feedback received at Wikimania 2015, before, and after ([[ https://phabricator.wikimedia.org/T105414 | T105414 ]]). If someone is interested in obtaining funds to push this task, this might be a good way.
This is a message posted to all tasks under "Re-check in September 2015" at #Possible-Tech-Projects. #Outreachy-Round-11 is around the corner. If you want to propose this task as a featured project idea, we need a clear plan with community support, and two mentors willing to support it.
Yeah, this idea is interesting but pretty much out of scope for Bugzilla as long as it's entirely unclear how to code it.
So we discuss a number of options here and it is not clear at all how to proceed. Wondering if an https://www.mediawiki.org/wiki/Requests_for_comment would be better.
Is this bug also apropriate for mw extension VisualEditor ?
Gather display and add few more options

option 6)At advance search give an option to compare and suggest a category. If selected Compare the categories also when advance search is being carried out.

Have a differentlly coloured column on right hand side of search results of uncatgorised pages 


Option 7)In special pages there is one tool called  Special:ComparePages .The tool is currently under utilised if enhanced with feature button assking to show uncategorised pages one after another. and suggesting pages for comparison . Utilisation of this good tool will improve and also rest of the data also will get improved.
I came across one edit filter Filter no1(http://ja.wikipedia.org/wiki/特別:不正利用フィルター/1)  on Japanese Wikipedia it has tagged more than 80000 new uncategorised pages , the data what is already available in special pages.But here purpose of using edit filter may be to be behind page creators to add a category.This is how an avarage wikipedian looks towards imporatance of categorisation it seems.
Where to display options and How to insert

1)Vis a Vis above first option: If a page is new or uncategorised , A button can be shown before save pages to add category.

:Horizontal category option display can be provided just above save button line ,and if clicked same as in edit tools it will get added to edit window

2)For option two same as First's option


3) For third option HotCat option display as some one clicks + button 

4) For fourth option to display and  add category from exmine page please also see bug no. 47497 also.

5)For fifth option either like first option or a pop-up after firt few sentences are typed on a new or uncategorised page.
Thanks for being prompt from your side and sorry for delay from my side.


*>>how this woould be gathered<< 

1)Some part of info is already being gathered for  "Special:Categories" ,'Special:UncategorizedPages' and other related pages.Analyse first copule of line of categorised pages and suggest categories to un categorised pages.

2)Second option is to gather information from (interwiki) Wikidata . 
Example: Say page 'abc' and its category page 'xyz' both are common for  language 'o' and language 'p'  wikipedia + may be more other languages; say page 'efg' also is connected on more than two wikis but category 'xyz' is mentioned on some wikis and not mentioned on some wiki's 

3)Third option enhancement on HotCat gadget side, when, a category is being added collect first two or three sentences of the article for statisticle comparison,or give a key line option and request editors to provide keyline  

4)fourth option, having few say 5 edit filters with upto 10 keywords each and allowing edit filter manager to add category from exmine page

5) Fifth option As and when Wikipedia goes for realtime editing analyse first couple of lines statistically.
Mahitgar: Please elaborate how this woould be gathered and displayed.
Note people have done things like this before. See CommonSense on toolserver. I have no idea how that tool works or if it could be feasible to use the same method in mw.

I agree with andre that how to display such information is very unclear.

P.s. I don't think the original poster was referring to the CategoryTree extension when s/he said category tree.
It's not clear to me how "automatic suggestion" would work - the only sentence you provide about your *expected* outcome is "The way bugzilla suggests automated summary".

What would proposals be based on? Only checking for strings that were previously used, or do you also have other heuristics in mind?

When would this be displayed, and where? Only when using CategoryTree?
The job will vote -1. But only in gate-and-submit, when working on it the tests should pass (or have this one be non-voting).

--------------------------
**Version**: wmf-deployment
**Severity**: enhancement
After all those years, it is not going to happen. Guess it is better handled directly in Gerrit eg via T135245.  Gerrit is replacing the draft system with private changes which would suit the WIP convention.
T135245 propose to add a new label in Gerrit `Workflow` to let users vote -1 and prevent it from being merged.
There is a patch proposed upstream:

* https://review.openstack.org/#/c/251373/
** Filter events by commit message,  Allow events to be filtered by commit messages

That might  let us prevent a change from entering gate-and-submit.
(In reply to Antoine "hashar" Musso (WMF) from comment #4)
> Revisiting after a while: Zuul does not have support to prevent merge based
> on a the content of the commit message.

Really?  The Jenkins jobs have a full git checkout, so presumably you could write a jenkins job for gate-and-submit that runs:

git log --oneline | head -1 | fgrep -q WIP

The actual test would be a little more complicated, since you'd want to be sure you were looking at the right side of a merge commit, but either HEAD^1 or HEAD^2 would name the actual patch you're committing in that case.
Revisiting after a while: Zuul does not have support to prevent merge based on a the content of the commit message.

A possibility is to use Code-Review: -2 which will effectively prevent Gerrit from submitting the patch.

Another way would be to add a new label in Gerrit that would be used to flag a change has being in progress which would trigger the gate-and-submit when voted +1. Something like:

 Approval:
  +1 Approved
   0 Pending review
  -1 Work in progress

Timo thoughts? Or should we just abandon this idea?
*** Bug 53405 has been marked as a duplicate of this bug. ***
Looking at the dashboard of VisualEditor extension that makes a lot of sense :)

https://gerrit.wikimedia.org/r/#/projects/mediawiki/extensions/VisualEditor,dashboards/default

$ git-review -l|egrep '(WIP|MERGE)'
70560  master  [WIP] Language Inspector Prototype                          
71641  master  [DON'T MERGE] Remove 'mw-editsection-bracket' hack    
71285  master  [WIP] Do not allow to resize thumb image to be bigger than original file
70346  master  [DON'T MERGE] Rich Copy and Paste from External Source
69796  master  [DON'T MERGE] Rich paste from external sources         
71661  master  [WIP] ve.dm.Transaction: Implement newFromDocumentInsertion, take 2
70981  master  [WIP] Math Node UI
68615  master  [WIP] Source code editing
70171  master  [WIP] Math Node Matcher
69281  master  [WIP] Link surface fix for RTL
$
I would prefer we do not rely on the commit summary having WIP or DRAFT in it, though we might warn about it.

OpenStack has a patch for Gerrit (might have been upstreamed), that let you flag a change has being a work in progress (see original feature request https://bugs.launchpad.net/openstack-ci/+bug/902953 ).


From Gerrit 2.5 release-notes, the drafts do not send patchset-created events so they should not trigger any job.  When they are published we have a new `draft-published`  event which is essentially the same as patchset-created.


I guess voting CodeReview +2 on a draft will thus send no event at all and the change will obviously never enter any pipeline.
This is a tracking bug for the creation of VisualEditor plugin editors, for each of which the primary bug should live in that product/component instead (where they're about an existing Extension etc.).

This task has been replaced by #VisualEditor-MediaWiki-Plugins

--------------------------
**Version**: unspecified
**Severity**: enhancement
Replaced by the #VisualEditor-MediaWiki-Plugins project.
(In reply to Elitre from comment #2)
> For documentation, see https://www.mediawiki.org/wiki/VisualEditor_gadgets.

No, that doesn't document how to create a proper VisualEditor plugin; the gadgets system uses a different way to work.
For documentation, see https://www.mediawiki.org/wiki/VisualEditor_gadgets.
Setting to "Lowest" priority as in general the WMF VisualEditor team won't itself be creating these, but instead helping others do so.
When you are editing an article the language links from Wikidata are not shown in the sidebar. Local links are shown.

(Reported at https://en.wikipedia.org/wiki/Wikipedia_talk:Wikidata/Archive_1#No_interwiki_links_when_you_are_in_edit_mode%3F)

**See Also**:
{T48488}
{T63768}
Should this still be fixed? see {T160931}
Still an issue in wikitext editor.
*** Bug 58518 has been marked as a duplicate of this bug. ***
Tested on fiwiki: Language links are shown when you click "Show preview". In VisualEditor, they are shown immediately. Is this enough?
Perhaps might be nice in MediaWiki core, but would definitely be nice as at least a MediaWiki extension, we should implement a "zen mode" capability from ?action=edit.

GitHub and it seems like the Cloud9 IDE both have this mode. It's demonstrated here: <https://docs.c9.io/zen_mode.html>.

In short, in the case of GitHub, it appears to be a bit of JavaScript that adds a "zen mode" button to the UI. When the user clicks this button, the non-essential page elements are hidden from the page, allowing the user to focus on the textarea (or other central input area) alone. Basically it reduces the amount of noise on the page in order to increase the signal.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=14501
So... I like the way that Phabricator does full screen. It's probably more accurately called full browser window. I think we should steal the (idea of) their code and put it in MediaWiki core. It can't be that much JavaScript... and then the wikitext edit toolbar (WikiEditor?) and the VisualEditor toolbar can be modified to expose this full browser window functionality. Does that seem reasonable?
Could easily be done as a gadget, rather than a extension.
Also knows as "Distraction free mode", e.g. in Sublime Text 2:

http://www.sublimetext.com/docs/2/distraction_free.html
**Author:** `Coiby.Xu`

**Description:**
I try a clean install of MW 1.20.2 and also install VE and Parsoid extension. When click "VisualEditor" button, the VE doesn't appear and there's a js error: "Uncaught TypeError: Cannot read property 'error' of null".

--------------------------
**Version**: unspecified
**Severity**: enhancement
Now that 1.23.x is released I suppose this is unnecessary.
(In reply to comment #8)
> I would suggest creating a backport and then ask for a review of it.  If a
> person can be found to implement and support the backport, I don't have a
> problem with shipping a 1.19 with it.

Thanks Mark; marking as lowest priority as (as said above) WMF won't be working on this, but if a third party would like to we'd be happy to help them out.
(In reply to comment #6)
> Copying Mark - Mark, what's policy for backporting functionality changes in
> core so that people can use extensions?

Andre is right -- depends on the complexity.  We did have some discussion of this on Wikitech-l, but I don't think a final decision was made.

I would suggest creating a backport and then ask for a review of it.  If a person can be found to implement and support the backport, I don't have a problem with shipping a 1.19 with it.
(In reply to comment #6)
> Copying Mark - Mark, what's policy for backporting functionality changes in
> core so that people can use extensions?

James: Have specific commits been identified? 
I guess it highly depends on the complexity of the task...
Copying Mark - Mark, what's policy for backporting functionality changes in core so that people can use extensions?
**Coiby.Xu** wrote:

Suddenly VE gave such error:"Uncaught TypeError: Cannot call method 'enable' of null" while it was normal a few days. I'm not sure if that error is related to this bug.
**Coiby.Xu** wrote:

Not really, I find it works on 1.20.0 :)
> This is correct - minimum current version of MW for the VE code is 1.21/wmf5
> (and this may go up as we add more functionality to MW core so that VE can
> work; it is possible that these changes will get back-ported to 1.19 and 1.20
> by some volunteers, but we at WMF won't be looking at this whilst the
> extension
> is still in an experimental stage.
> 
> Will change this to an enhancement for that to be done, with low priority
> (reflecting that if a volunteer wants to do it, that'd be great).
> 
> See my comment on the wikitech-l mailing list thread:
> http://lists.wikimedia.org/pipermail/wikitech-l/2013-January/065532.html
> 
> Have added this to the Extension page on MediaWiki.org - 
> https://www.mediawiki.org/w/index.php?title=Extension:
> VisualEditor&diff=628258&oldid=610234
**Coiby.Xu** wrote:

Hi Andre,
The skin I use is Vector. This Mediawiki is in the local network thus can't be accessed from outside:(
The version of VE is 72c121684c6edb6ab580258676759f62e3efd471 and Parsoid's is aa34a80a6e43fe4fe6c5a95b465bf10dee3ed922.
> Hi Coiby,
> which user interface skin do you use?
> Is this MediaWiki installation publicly accessible somewhere?
> Which versions of VE and Parsoid versions do you use?
This is correct - minimum current version of MW for the VE code is 1.21/wmf5 (and this may go up as we add more functionality to MW core so that VE can work; it is possible that these changes will get back-ported to 1.19 and 1.20 by some volunteers, but we at WMF won't be looking at this whilst the extension is still in an experimental stage.

Will change this to an enhancement for that to be done, with low priority (reflecting that if a volunteer wants to do it, that'd be great).

See my comment on the wikitech-l mailing list thread: http://lists.wikimedia.org/pipermail/wikitech-l/2013-January/065532.html

Have added this to the Extension page on MediaWiki.org - 
https://www.mediawiki.org/w/index.php?title=Extension:VisualEditor&diff=628258&oldid=610234
Hi Coiby,
which user interface skin do you use?
Is this MediaWiki installation publicly accessible somewhere?
Which versions of VE and Parsoid versions do you use?
Moving this back to WikiHiero for writing the VisualEditor rich editor, if someone ever wants to do this (the basic source one is now done).
The above tag lets you edit the hiero syntax and preview it.

This could be further extended to provide a hiero IME, but that's not going to be on our priority list any time soon.
Hieroglyphics support.

https://gerrit.wikimedia.org/r/77508
Change 37570 abandoned by Jforrester:
wikibugs: Set up #mediawiki-visualeditor

Reason:
We gave up and moved to using pywikibugs instead.

https://gerrit.wikimedia.org/r/37570
Change 54984 abandoned by Jforrester:
Filter VisualEditor product to new mediawiki-visualeditor.log

Reason:
We gave up and moved to using pywikibugs instead.

https://gerrit.wikimedia.org/r/54984
The bugs are now being reported in #mediawiki-visualeditor by pywikibugs.
Related URL: https://gerrit.wikimedia.org/r/54984 (Gerrit Patch-Set: I04e82cb392f1ad680db6c469f76fb717d435c20d/1)
Related URL: https://gerrit.wikimedia.org/r/37570 (Gerrit Patch-Set: Id7405c8ee9a8658ed7afae844a870e0253a73806/4)
gerrit-wm is done, but wikibugs is "an almighty pile of crap" and would need major work; moving to Lowest.
With bug 45061 all change marker code has been removed.
LiquidThreads has been replaced by #Flow on all Wikimedia production wikis (except one, which will be done soon). It is no longer under active development or maintenance, so I'm re-classifying all open LQT tasks as "Lowest" priority.
>>! In T43276#838397, @He7d3r wrote:
> Is this solved by Flow?

No. Flow's version of this same problem is {T59989}.
Is this solved by Flow?
See also [[mw:Thread:VisualEditor/Feedback/Eror on Feedback?]]
I guess LQT extension must be a good citizen and get along with other extensions? Under the exclusivity is there by design, this looks more like a bug (and a major one) rather than an enhancement request.

Setting to "Normal" because I lack the background. Feel free changing to Major if you agree that blocking other extensions deserves that.
> Maybe that bug can be reconsidered as "Support Firefox ESR version". That is currently version 52 released in March 2017.

No. That milestone was reached in mid-2013. This is specifically about very old Firefox versions. It's possible someone might want to do this in the future.
Firefox 10-14 are from the past.

From https://analytics.wikimedia.org/dashboards/browsers/#all-sites-by-browser/browser-family-and-major-hierarchical-view

In percent of Firefox traffic:


| v10 | 0.29%
| v52 | 8.9%
| v56 | 17%
| v57 | 65%

Maybe that bug can be reconsidered as "Support Firefox ESR version". That is currently version 52 released in March 2017.
>>! In T43245#1161468, @Krenair wrote:
> Do we know how many people are still using our sites with 10-14?

In Dec 2014, [[ https://stats.wikimedia.org/wikimedia/squids/SquidReportClients.htm | 305.8 M total requests ]].
Are we still interested in supporting these versions? FF ESR 24.8.0 is EOL now, based on the chart at https://www.mozilla.org/en-US/firefox/organizations/faq/
Do we know how many people are still using our sites with 10-14?
Re-labelling this to be about supporting Firefox versions 10-14; 15+ (inc. ESR 17 and ESR 24) should work fine.
(In reply to comment #5)
> The new warning about VE being in beta stage is not fully readable with this
> browser. This said, it might be interesting to know whether support is coming
> at some point or this is going to be closed as "won't fix". Thanks.

Note that the current ESR version of Firefox is 17 now instead of 10. What does your "this browser" refer to?
The new warning about VE being in beta stage is not fully readable with this browser. This said, it might be interesting to know whether support is coming at some point or this is going to be closed as "won't fix". Thanks.
Wikimedia has migrated from Bugzilla to Phabricator. Learn more about it here: https://www.mediawiki.org/wiki/Phabricator/versus_Bugzilla - This task does not make sense anymore in the concept of Phabricator, hence closing as declined.
Based on data how rarely this field has been set in the last 12 months (except for by the reporter and the bugwrangler), I am very tempted to just hide 
* field_label_cf_platform
* field_container_cf_platform
via "display:none" in CSS for the time being, wait if anybody will actually complain, and if nobody complains disable it entirely.
...by the way, Bugzilla query to see which reports use the "Mobile Platform" field is https://bugzilla.wikimedia.org/query.cgi?format=advanced and setting "Custom Search" to "Mobile Platform | is not equal to | ---".
Looking at this again, I wondered if there are cases apart from aforelisted components when the field is set. 
There are, especially when "Hardware" is set to "Tablet PC":
https://bugzilla.wikimedia.org/buglist.cgi?bug_id=43748,43414,43101,41984,38420,37875,38393,37160

Hence this is maybe not a good idea, and I currently think I shouldn't pursue this idea.
This is already provided:

Your friendly translatewiki.net notification system

--
To change your email notification settings, visit
https://translatewiki.net/wiki/Special:Preferences

To change your watchlist settings, visit
https://translatewiki.net/wiki/Special:EditWatchlist

To delete the page from your watchlist, visit
https://translatewiki.net/w/i.php?title=Summary:Support/About_Wikia:Wikia-visualeditor-dialog-wikiamediainsert-upload-label/en_(3)&action=unwatch

Feedback and further assistance:
https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Contents
**tomte** wrote:

By teaching groups for Wiki editing I found WYSIWYG support for tables most important. 

Even elder people I can get accoustomed to markups like bold, links, headers / TOC, bullets, categories etc without WYSIWYG, but not for tables.

Editing Wiki tables in Libre Office makes them huge and no longer editable manually.

So table support is not just an option but a minimum feature  - the "condition sine qua non" -  for WYSIWYG support. 
tomte , Member 542126 in WikiMedia Deutschland
Anything going on? It's high time that typography is corrected automatically; I don't get how you can classify this as lowest priority!
I actually can't promise that I'll implement this soon, so I'm unassigning myself; sorry. I'm still interested in this, and proper typography on the wikis in general :)
For German, that would mean changing "" in „“, like it is being suggested at de.wp.
en.wp user Ruud Koot requests "--" be converted to endash and "---" to emdash, which is slightly different to comment 0.
Re-visiting this, I'm not sure I agree with the premise any more.

Lots of the per-language localisations (and the per-wiki customisations) of the "edit tools" message have added useful characters for editors without the ability to insert them using their keyboard, but they all mix the semantic concepts of wikitext syntax fragments (e.g. "<nowiki>" or even "{{RLM}}") and accented characters; asking communities to de-merge these just so VisualEditor can re-use some of them seems impractical.

Consequently I'm going to mark this as a WONTFIX, but if you can think of a sane way to do this, please re-open. :-(
*** Bug 58323 has been marked as a duplicate of this bug. ***
Re-wording this and making it depend on bug 50296 - I have doubts about this, however. Many choices about availability of characters, or about their prominence, aren't appropriate in both contexts ("~~~~" isn't something needed in VisualEditor, for example). Not sure whether this should instead be a WONTFIX in lieu of 50296, but leaving open for now.
Another request for this today. It's regarded as one of the few key missing features by a significant content editor.
This seems coincidentally to have been the subject of two separate requests today in the VE feedback pages: many editors need access to accented characters, greek letters, em-dashes and other specialised symbols, etc. See http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Quick_insert_panel and the section below it.
**weskaggs** wrote:

I have a few comments; apologies if I misunderstand the issues or am commenting in the wrong place.

First, the ability to enter special characters should have higher priority.  They are very frequently used -- long dashes the most frequently of all, but many others too.

Second, the WikiEditor toolbar is probably overkill.  A better model may be the CharInsert gadget that can be enabled in the English Wikipedia preferences.  The JS code for the gadget can be found at

http://en.wikipedia.org/wiki/MediaWiki:Gadget-charinsert.js

The gadget depends on a very simple extension called CharInsert, whose php code can be viewed at

https://git.wikimedia.org/blob/mediawiki%2Fextensions%2FCharInsert/8fa1602e22324b73491004957f02d5309302505b/CharInsert.php

Of course none of this can be used without modification, but it may provide a model for a character insert interface that has been optimized for usability.
I'd generally prefer client-side drafts, but as discussed offline with @Jdforrester-WMF there is no blanket prohibition from the legal team on server-side draft storage.
About ability to recover from crashes, I wonder how complex would it be enable this "cache" that Phabricator offers in this very Comments textarea I'm typing it. Type something, reboot your laptop, come back to this URL, and your text is still here, in the textarea, where you left it.
Legal issues put aside, using client-side storage for drafts does have a lot of advantages: better performance, support for anonymous edits, ability to recover from crashes that happen while there is no network connection. The main disadvantage that I can see is that it is not privacy-friendly - using good privacy practices like incognito mode of the browser would cripple a client-side draft feature as it could not recover the text after a browser crash.
Thanks for the explanation of the legal issues relating to private drafts.  I've created bug  T57670 as a result.(In reply to comment #47)

Regarding the client-side hit of a VE->Drafts interface vs VE->Local storage, I suppose I was expecting that VE would be putting HTML+RDFa into local storage, in which case the client side hit is the same for both.  But that should be discussed on bug T57370. (I've raised a few other points to consider there)
Thanks for the explanation of the legal issues relating to private drafts.  I've created bug 55670 as a result.(In reply to comment #47)

Regarding the client-side hit of a VE->Drafts interface vs VE->Local storage, I suppose I was expecting that VE would be putting HTML+RDFa into local storage, in which case the client side hit is the same for both.  But that should be discussed on bug 55370. (I've raised a few other points to consider there)
James' answer above is very authoritative and the concerns about server-side private drafts apply whether we're talking about wikitext or about VE.

I like the general principle of using client-side storage for data recovery purposes (maximum privacy, avoids legal issues), and working towards better support for public drafts (inviting collaborators etc.) in future. That approach is more consistent with wiki-style collaboration in public while also safeguarding user actions.
I'm not sure this is should be discussed on this bug but...
(In reply to comment #44)
> Just a quick note, in case people are pushing hard on getting this done so it
> can be used for VisualEditor, it's not the direction we're looking at taking
> for VE.

Thanks for the comment. Really I'm just trying to get this extension to not suck ;-)

> * We would need something that lets us persist VE linear-models, or at least
> Parsoid HTML+RDFa (otherwise each save will take dozens of seconds of
> computation, slowing clients down and adding to burdens on the cluster; until
> server-side storage of Parsoid HTML+RDFa is undertaken, there's nowhere
> really
> appropriate for this to be saved for the Drafts extension to implement, which
> is currently wikitext-based)

Technically Drafts is set up to store anything that is text based, and I think HTML+RDFa can be serialized into text (or is already text)? We might need to add a column for contentmodel in the drafts db schema though...

> * We would want (but not strictly /need/) something very flexible, so we
> could
> persist undo stacks, etc. which could add a huge amount of complexity to the
> Drafts extension for just one use case/client.

Ideally the Drafts extension would also have some kind of history/undo, but this is kind of a slippery slope and at some point you end up with essentially private user sandboxes.

> 
> Though I think that the Drafts extension could be useful for wikitext users,
> I
> don't think it's right for VisualEditor; see bug 55370 for VisualEditor's
> take.
Just a quick note, in case people are pushing hard on getting this done so it can be used for VisualEditor, it's not the direction we're looking at taking for VE.

* We would need something that is client-side, not server-side (this makes things faster and avoids the really icky legal issues).
* We would need something that lets us persist VE linear-models, or at least Parsoid HTML+RDFa (otherwise each save will take dozens of seconds of computation, slowing clients down and adding to burdens on the cluster; until server-side storage of Parsoid HTML+RDFa is undertaken, there's nowhere really appropriate for this to be saved for the Drafts extension to implement, which is currently wikitext-based)
* We would want (but not strictly /need/) something very flexible, so we could persist undo stacks, etc. which could add a huge amount of complexity to the Drafts extension for just one use case/client.

Though I think that the Drafts extension could be useful for wikitext users, I don't think it's right for VisualEditor; see bug 55370 for VisualEditor's take.
(In reply to comment #42)
> It would also be helpful if there are people willing to do code review, it
> seems that's whats stalled the development of this extension in the past.

It seems Yuvi is willing. You can also e-mail wikitech-l if you can't find anyone. :-)
(In reply to comment #37)
> 
> Is it enabled on a WMF test wiki with VE?  Could it be enabled on
> mediawiki.org
> in order to encourage dev's playing with it?
> 

So I set up an instance at http://drafts.instance-proxy.wmflabs.org/wiki/Main_Page and attempted to install VE, except setting up parsoid failed with some cryptic error I didn't spent time debugging.

Digging through the code, there's a lot of cleanup (deprecated stuff, (ab)use of globals, etc) that needs to be done and a start has been made at https://gerrit.wikimedia.org/r/#/c/29749/

It would also be helpful if there are people willing to do code review, it seems that's whats stalled the development of this extension in the past.
(In reply to comment #39)
> Shouldn't be deployed on cluster until code has had relevant code review
> actioned against it, and any necessary remedial action completed.

Hmm, right, I forgot that this bug has a bunch of outstanding dependencies.

John V.: we'll need to find someone to work on the extension in order to eventually get it deployed on any Wikimedia wikis.
Well, and until Features and Product have confirmed it's something they're interested in supporting (unless Platform devs are comfortable explicitly saying 'yes, we will make sure it works forevermore')
Depends by what you mean as a wmf test wiki. Its not on the cluster, as its not branched. I don't think it is on beta either, but you van confirm it yourselves via NOC or mediawiki-config

Shouldn't be deployed on cluster until code has had relevant code review actioned against it, and any necessary remedial action completed.
(In reply to comment #37)
> Is it enabled on a WMF test wiki with VE?  Could it be enabled on
> mediawiki.org in order to encourage devs playing with it?

Greg: do you know?
The demo of this extension (http://kubo.wmflabs.org/wiki/Main_Page) now returns 404.  There are some non-WMF wikis using this extension: http://wikiapiary.com/wiki/Extension:Drafts

Is it enabled on a WMF test wiki with VE?  Could it be enabled on mediawiki.org in order to encourage dev's playing with it?

From a quick look at the code, a prototype of VE-support of Drafts can be done easily with only user: space custom JavaScript.

Proper VE-support would need a new API call to minimise data being sent back and forth.
Visual editor brings new dataloss scenarios due to its beta status. If VE could autosave the article as a draft, and could open the draft in VE, this would allow switching editor.
Change 339400 merged by jenkins-bot:
[mediawiki/extensions/VisualEditor@master] MWMediaTransferHandler: Allow uploading of dropped Blobs

[[https://gerrit.wikimedia.org/r/339400]]
Change 288773 abandoned by Bartosz Dziewoński:
WIP: Add possibility to paste a file to the document

Reason:
Apparently no longer needed? https://gerrit.wikimedia.org/r/339400 also works. It's not clear to me why we couldn't do that before.

[[https://gerrit.wikimedia.org/r/288773]]
Change 339400 had a related patch set uploaded (by Jforrester; owner: Esanders):
[mediawiki/extensions/VisualEditor@master] Allow uploading of dropped Blobs

[[https://gerrit.wikimedia.org/r/339400]]
Quick video of the change above:
https://youtu.be/IuWaxS7mOBA
Change 288773 had a related patch set uploaded (by Florianschmidtwelzow):
WIP: Add possibility to paste a file to the document

[[https://gerrit.wikimedia.org/r/288773]]
Change 288773 had a related patch set uploaded (by Florianschmidtwelzow):
WIP: Add possibility to paste a file to the document

[[https://gerrit.wikimedia.org/r/288773]]
Interesting idea, I'll try to upload a first change for it :)
Bumping down priority.
This shouldn't be happening anymore now that all dependencies are fixed. Rejoice!
This refers to the inspector menu trigger icon that was removed in late-2012. Marking as INVALID as it doesn't matter any more.
What arrow? I don't see one in neither Opera not Firefox.
No outstanding bugs against this tracker; closing.
Change 72738 merged by jenkins-bot:
Unblacklist Opera >= 12

https://gerrit.wikimedia.org/r/72738
Change 72738 had a related patch set uploaded by Matmarex:
Unblacklist Opera >= 12

https://gerrit.wikimedia.org/r/72738
[Reopening as a tracking bug and assigning to myself.]

The current dependencies are the things that IMO are blockers to enabling VE for Opera users again.
Raising priority per T59777. We're using more SVGs nowadays.
*** Bug 63491 has been marked as a duplicate of this bug. ***
I think we can apply the same as PNG files.

I don't know of any SVG files we have in our repository that we manually edit to the level that can't aren't already be minified (they might have some indentation, but that's about it, and we could actually minify those in the repository, like we optimise PNG files).

I know SVG is text where PNG is not, but unless we actually edit them, it should be fine.

As for solving this bug, if we want to minify SVGs in separate requests (e.g. fonts), that would get quite tricky. They'd need a url to be served from.

As for SVGs we embed in CSS (SVGs for icons like we do in VisualEditor), those could be easily minified before being base64 encoded (that is, once we have an xml minifier).
This will reduce instances where user submits changes and receives an error, possibly resulting in data loss. 
see — http://github.hubspot.com/offline/
Tagging with VE-ME and WikiEditor as this is the first time I've stumbled over this, and we might want to come back to it.

Dropping "easy" because it isn't. Anyone tempted to try to work on this needs to have a serious long conversation with me and Operations about how we could do this in a way that doesn't over-load the servers and take down Wikipedia.
Then we might want to only alert at critical times, like when edit summary is open or when save is pressed prior to actually submitting, e.g. disable save if connection can't be restored.
The editors do not keep a constant connection open to the server.
This task is now a #goal. I need to update the description.
I realize this is well-underway but I recently came across [[ https://hackshackers.github.io/misinfocon-event-calendar/ | this public events calendar ]] and really liked the format and the code is [[ https://github.com/hackshackers/misinfocon-event-calendar | up on GitHub ]] so I thought I would share as a stickie in case there are future revisions planned down the road.

(I also realize this could be a totally annoying update given the status of the project so if it's irrelevant, please ignore and forget this message ever existed. :))
>>! In T1035#3104260, @Aklapper wrote:
> * DONE: [[ https://secure.phabricator.com/T10747 | Import and export ICS from Calendar ]]

Pretty useless though in its current form as there is no stable export URL (the "export" link just takes you to a web page that initiates download of the actual file via JS) so you cannot plug an URL into your calendar client and get changes to the event automatically synced.

> * DONE: [[ https://secure.phabricator.com/T7929 | Integrate Calendar with external systems ]]

Declined, actually (upstream uses task statuses in weird ways), except for Google Calendar integration, which has not been done yet.
Removed parent task T136213 as the technical side seems to be done.
Agreed.
Status update of related upstream tasks:
* DONE: [[ https://secure.phabricator.com/T10747 | Import and export ICS from Calendar ]]
* DONE: [[ https://secure.phabricator.com/T7944 | Add Conduit support to Calendar ]]
* DONE: [[ https://secure.phabricator.com/T7929 | Integrate Calendar with external systems ]]
* [[ https://secure.phabricator.com/T7924 | Unprototyping the calendar application ]] in upstream has not happened. It only depends on 
** [[ https://secure.phabricator.com/T7930 | Let Calendar provide date services to other applications ]] 
** and potentially [[ https://secure.phabricator.com/T8022 | Implement a meeting autoscheduler ]] (listed in task deps but not in task desc).
The first item is likely still a blocker (Google Calendar being popular) for this very downstream task T1035, while I think the second might not be that crucial for us?
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.
We can use #devwish17 to check how much interest there is for this idea.
Re DevSummit: Hmm, I'm not convinced. "Dealing with calendar data in the Wikimedia movement"?
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
>>! In T1035#2698874, @Qgil wrote:
> I just 
> 
> # created {E329}
> # clicked "Export as .ics", and an .ics file was downloaded to my laptop
> # imported the .ics file to my Google Calendar
> 
> The event is now visible in my calendar. Progress!

So as in mine. I don't know if it was the expected result. ;)
There is more coming (just landing in Phabricator HEAD, not stable yet):

https://secure.phabricator.com/book/phabricator/article/calendar_exports/
I just 

# created {E329}
# clicked "Export as .ics", and an .ics file was downloaded to my laptop
# imported the .ics file to my Google Calendar

The event is now visible in my calendar. Progress!
I just 

# created {E329}
# clicked "Export as .ics", and an .ics file was downloaded to my laptop
# imported the .ics file to my Google Calendar

It's there. Progress!
I just created {E329}, then clicked "Export as .ics", then import to my Google Calendar. It's there. Progress!
(Aforementioned deployment postponed due to Ops offsite)
@qgil: That will land in our phabricator tomorrow night (midnight UTC) when I deploy #phab-2016-09-28
Initial support for ICS export is available in Phabricator HEAD, and the work is continuing as we speak -- see https://secure.phabricator.com/T10747

I am counting on this ICS support for this proposal: {T146749}
Punting to Oct-Dec for Dev-Rel. 
Not to happen this quarter as long as T136213 isn't resolved which is external.
@CKoerner_WMF - as I noted earlier, Semantic MediaWiki was declined for use on Wikipedia, in favor of Wikidata. (Which was the right choice.) I don't believe it has ever been reviewed for use on, say, mediawiki.org.

And - though I'm repeating myself - Cargo is, in my opinion, the better option. But either one would work.
Just to chip in my $.02, I would encourage us to look for a solution that can be used on-wiki. There's something about investing time/money/energy in on-wiki solutions that sits better with me. Maybe it has to do with an on-wiki solution being more inviting. People without or only entry level development skills will find the information easier than here in phabricator, where super dev skills are the norm. :)

I understand that SMW was declined many years ago. What were the reasons for the declination? It's not clear to me if those still stand today. Could those be addressed?

@Yaron_Koren You're far more savvy with this than I, but does SMW meet these requirements? https://wikitech.wikimedia.org/wiki/Writing_an_extension_for_deployment

My personal bias aside, SMW seems like a present solution that is free, on-wiki, adaptable, and within our own MediaWiki community. Much different than spending money on a one-time development of a feature from an outside vendor. Ok, that was totally biased.
Just a reminder that if, say, Cargo and Semantic Forms were installed on mediawiki.org today, there would be functioning event-entry forms and event calendars on the site, probably by the end of the day. (And at no cost.)
@Qgil  Wouldn't that require that each of our members created an account here? (Not that this was available until recently, so it's no wonder it hadn't been brought up as anoption). It may be worth trying, though.

And installing a local phabricator instance… no, thanks.
By the way, I just rewrote this page, to be clearer and more up-to-date:

https://www.mediawiki.org/wiki/Extension:Calendar
A solution that would work for the Wikimedia Tech community is not a suboptimal solution, is a valid solution for a specific problem (which doesn't conflict with potential solutions for the non-tech Wikimedia communities).

As for the general problem...

@Platonides, can you show the use of calendar by Wikimedia Spain? Installing OwnCloud on your own server looks like a much more technical and involved task than just using Phabricator Calendar for your org/project. For what is worth, every time there are more chapters and non-tech groups that are using Phabricator as a project management tool.

@BrillLyle, have you tried Phabricator Calendar? I think it is quite low barrier as soon as users don't make the mental connection "Phabricator == technical, not for me", but I would be very interested in discussing the details.

I am not proposing to rely on Google, Facebook on anything at Wikimedia, so we can take this topic out of this discussion.

Anyone can request funding to develop a MediaWiki extension that allows  native input of calendar data. It's just that such funding request will need to come from [[ https://meta.wikimedia.org/wiki/Grants | grants ]], because (for the bureaucratic-sounding but very real reasons I have explained) the budget that our team has right now will not be available on July 1.
A solution that would work for the Wikimedia Tech community is not a suboptimal solution, is a valid solution for a specific problem (which doesn't conflict with potential solutions for the non-tech Wikimedia communities).

As for the general problem...

@Platonides, can you show the use of calendar by Wikimedia Spain? Installing OwnCloud on your own server looks like a much more technical and involved task than just using Phabricator Calendar for your org/project. For what is worth, every time there are more chapters and non-tech groups that are using Phabricator as a project management tool.

@BrillLyle, have you tried Phabricator Calendar? I think it is quite low barrier as soon as users don't make the mental connection "Phabricator == technical, not for me", but I would be very interested in discussing the details.

I am not proposing to rely on Google, Facebook on anything at Wikimedia, so we can take this topic out of this discussion.

Anyone can request funding to develop a MediaWiki extension that allows  native input of calendar data. It's just that such funding request will need to come from [[ https://meta.wikimedia.org/wiki/Grants | grants ]], because (for the bureaucratic-sunding but very real reasons I have explained) the budget that our team has right now will not be available on July 1.
A solution that would work for the Wikimedia Tech community is not a suboptimal solution, is a valid solution for a specific problem, that is not in direct competition with other potential solutions.

As for the general problem...

@Platonides, can you show the use of calendar by Wikimedia Spain? Installing OwnCloud on your own server looks like a much more technical and involved task than just using Phabricator Calendar for your org/project. For what is worth, every time there are more chapters and non-tech groups that are using Phabricator as a project management tool.

@BrillLyle, have you tried Phabricator Calendar? I think it is quite low barrier as soon as users don't make the mental connection "Phabricator == technical, not for me", but I would be very interested in discussing the details.

I am not proposing to rely on Google, Facebook on anything at Wikimedia, so we can take this topic out of this discussion.

Anyone can request funding to develop a MediaWiki extension that allows  native input of calendar data. It's just that such funding request will need to come from [[ https://meta.wikimedia.org/wiki/Grants | grants ]], because (for the bureaucratic-sunding but very real reasons I have explained) the budget that our team has right now will not be available on July 1.
I agree that just because there is a budget and a time constraint doesn't mean that's the best approach -- especially because a bandaid and/or short-term solution may not provide what is needed in the long-term. 

The google calendar and folks using Facebook event pages seems to be working right now. Is it ideal? No. 

The lowest technical barrier on the end users and organizers is my biggest concern. Not sure any of these options is an improvement -- or needs to be a focus of this discussion. But wanted to mention it just in case. 

Erika
User:BrillLyle

>>! In T1035#2295720, @Platonides wrote:
> 
> Should we spend budget in a suboptimal solution because of time constraints for expenditure in the TC team?
> It may be worth it for the interim benefit. And while I prefer to spend money that way than developer hours, it's still a tough decision.
One important reason for WM-ES to install Owncloud was precisely so we could use its calendar features.
Storing calendars in external platforms like Google of Facebook is far from ideal. Even if people really had it in one of those unfree platforms{{citation needed}}, the problem is not just //showing// the ics calendar, but also //editing// it.
If it's stored in the wiki, that would be relatively straightforward, compare that to finding out it is included from a Facebook calendar, which requires  you to create a Facebook account, then ask for permission to someone else (which may not even be too active now) for changing the calendar, just to enter your local event.
And all of these duplicating the existing organization at a parallel site.

Storing the calendars in phabricator may work for the Wikimedia technical community, but doesn't solve the problem for the second group.


>>! In T1035#2295517, @Qgil wrote:
> Sure, the perfect solution would be a MediaWiki extension deployed in Wikimedia and available for 3rd parties, but let me share why I think this is not possible within the scope of this exercise:

Should we spend budget in a suboptimal solution because of time constraints for expenditure in the TC team?
It may be worth it for the interim benefit. And while I prefer to spend money that way than developer hours, it's still a tough decision.
Qgil wrote:

> SemanticMediaWiki is designed for semantic input, but I think it is safe to assume that Wikimedia is not going to increase its dependency on SMW when the trend on wikitech.wikimedia.org / Labs is the opposite.

If anyone's wondering, I assume he's referring to this ticket: T53642. To summarize that discussion: three of the DevOps people want to replace SMW on their system with dedicated DevOps tools. How relevant that is to this discussion is a matter of personal opinion.

I hate to sound like a broken record here, but SMW is already in successful use on hundreds of wikis, including probably dozens where it's used specifically to manage calendar and event data. It provides all the functionality that people are talking about here, as far as I can tell: data entry, standard calendars, customized views/queries, data export. Cargo is a newer extension (first released in 2015), so it hasn't gotten as much use so far, but it does essentially all the same stuff as SMW.
After a first wave of feedback it is clear that we have two different discussions that need solving:

# If we use WMF Technical Collaboration budget for Phabricator improvements, should we invest it the Calendar application? This is a well framed discussion with a clear deadline for decisions (very soon, or our FY2015-16 budget will be gone). I have created a task to discuss this specifically: {T135327}
# If we want to improve the announcement and promotion of Wikimedia tech events, is the best first step to improve Phabricator Calendar? This is a complex discussion with many ramifications that we can keep discussing here.
@JanZerebecki - actually, both Semantic MediaWiki and Cargo can have their data displayed on other wikis. They both can export their data via the API, in formats including JSON and iCalendar (well, Cargo doesn't currently support iCalendar, but it would be easy to add it in). To be able to get and display the JSON data, any other wiki would just need to have the External Data extension installed:

https://www.mediawiki.org/wiki/Extension:External_Data

As for getting iCalendar data and actually being able to display a calendar with that information, the Widgets extension, and specifically the Google Calendar widget, could probably be used for that:

http://www.mediawikiwidgets.org/Google_Calendar
I think we should be looking at the possibility of different solutions to serve the different purposes:

* Firstly (as the basis of this task) we want a solution for the Tech crowd, where we can use tags, cross reference teams, tasks, subscribe/cc to follow, ACLs and the likes, and since Phabricator is already our central point it may be the best contender or it may not be once we start looking at extended features (example: displaying inside MediaWiki, exporting via standard formats etc, syncing to personal devices).

* Secondary (probably best discussed in a separate task) appears to be where we want a calendaring solution for those that are primarily in the wiki-sphere and don't use Pharicator as a central discussion location and want to manage wholelly on a wiki based level (eg: WikiCons, meetups, EditThons).
I oppose spending money on this unless we first spend money on the Phabricator upstream bugs which Wikimedia users suffer from.
I would also like to see a calendar solution that is usable for 3rd party Mediawiki users.
@Qgil posted on wikitech-l asking for feedback about this. He writes:

> The Technical Collaboration team has some budget that we could use to fund the Phabricator maintainers to prioritize some improvements in their Calendar. If you think this is a bad idea and/or you have a better one, please discuss in the task (preferred) or here.

I'd personally prefer to see a calendar solution that integrates with MediaWiki. Many of the use-cases mentioned in this task relate to our wikis.

There are times when investing in another organization's platform makes sense, but in this case, I think investing in our own platform is probably more prudent. As demonstrated by the dozen MediaWiki extensions in this space, there's demand among "third-party" (i.e., non-Wikimedia) MediaWiki installations—including wikis that I administer—to have a usable calendar system.
The thing that us folks doing Wikipedia:Meetup editathons need is **something that can be maintained on the Wikipedia namespace **-- and probably for those still using Meta for use on that namespace as well.

For the WM NYC chapter, we have been putting our event pages on Wikipedia via Wikipedia:Meetup as it is a semi-passive way to onboard people onto the main Wiki. Plus a lot of templates don't play well with Meta -- blargh. So that functionality / integration especially would be super helpful for the chapter.

I think other chapters and probably more global meetups use Meta -- WM NYC doesn't really use our Meta that much, especially not for calendar-related activities. Again we are trying to point people to one main URI if possible. We have over 20 events (not including outliers) so far this year and it's only May, so this would be something used in a very robust way.

If MediaWiki is not implementable onto the main Wiki, and assume Wikidata obviously (?) isn't an option for calendaring (?), then would Phabricator Calendar be able to be embedded onto Wikipedia:Meetup namespaces? We would really really like that. A lot.

I'm probably using the term namespace incorrectly but it makes sense to my pea brain. Apologies for the lack of precision. I'm more of an end user experience person.

Also, is the afore-mentioned Calagator just completely not an option? It doesn't have the bells and whistles of Google calendar but it seems sort of cool.

– Erika 
User:BrillLyle
I would appreciate an improvement to the calendar situation, not just for tech events but also for finance, fundraising, community, and everything else. I haven't looked into Cargo or SMW calendars in any detail, but I'd like to see *some* kind of progress on an open source calendar that can be used widely including outside of WMF by affiliates. Thanks!
@Krenair - that was a discussion about including SMW on Wikipedia and the like; SMW was rejected in favor of Wikidata. It's unrelated to its use on "internal" sites like mediawiki.org and meta.wikimedia.org. Again, though, I personally think Cargo is the superior solution.
SMW was already declined years ago: {T10390}
There are already two MediaWiki extensions that handle the display of calendars very well: Semantic MediaWiki and Cargo. Both let you query events in any number of ways, displaying subsets of events and allowing for color-coding and so forth. When used in conjunction with the Semantic Forms extension for entering event data (which can be used with either SMW or Cargo), the whole system becomes fairly simple to use.

https://www.semantic-mediawiki.org/wiki/Semantic_MediaWiki
https://www.mediawiki.org/wiki/Extension:Cargo
https://www.mediawiki.org/wiki/Extension:Semantic_Forms

Personally, I think Cargo is a little nicer to use, but you can see here a nice demonstration of how SMW and SF were used together to enter the data for, and display, a conference schedule:

https://www.semantic-mediawiki.org/wiki/SMWCon_Fall_2015/Calendar

This is using the FullCalendar JS library:

http://fullcalendar.io/
I have updated the description adding the relevant information in the thread. If you are missing important bits, please add them.

I have sent an informal call for feedback to wikitech-l: https://lists.wikimedia.org/pipermail/wikitech-l/2016-May/085613.html

The goal is to make a decision soon-ish, and if that decision is to fund the Phabricator maintainers, sign the agreement by the end of the month, and get the work done during June-July:

# Unprototyping Calendar (mainly updating backend stuff?)
# A Good API (tm)
# .ics support
# Basic Google Calendar support

I wonder what would be the best way to proceed with the MediaWiki extension. If we get the Phabricator side done, it would be a decent candidate for the next Outreachy or Individual Engagement Grants rounds.
I have updated the description adding the relevant information in the thread. If you are missing important bits, please add them.

I have sent an informal call for feedback to wikitech-l: https://lists.wikimedia.org/pipermail/wikitech-l/2016-May/085613.html

The goal is to make a decision soon-ish, and if that decision is to fund the Phabricator maintainers, sign the agreement by the end of the month, and get the work done during June-July:

# Unprototyping Calendar (mainly updating backend stuff?)
# A Good API (tm)
# .ics support
# Basic Google Calendar support

I wonder what would be the best way to proceed with the MediaWiki extension. If we get the Phabricator side done, it would be decent candidate for the next Outreachy or Individual Engagement Grants rounds.
I have updated the description adding the relevant information in the thread. If you are missing important bits, please add them.

I have sent an informal call for feedback to wikitech-l: https://lists.wikimedia.org/pipermail/wikitech-l/2016-May/085613.html

The goal is to make a decision soon-ish, and if that decision is to fund the Phabricator maintainers, sign the agreement by the end of the month, and get the work done during June-July:

# Unprototyping Calendar (mainly updating backend stuff?)
# A Good API (tm)
# .ics support
# Basic Google Calendar support
>>! In T1035#2191801, @Quiddity wrote:
> 1. There's also https://www.mediawiki.org/wiki/Extension:Calendar (a linkhub for the ~12 different extensions or methods of integrating calendars with MediaWiki). If further work was done on one of those, to make it usable by us, many other MediaWiki users would also benefit. 

I went through the list and there was none surviving a basic check against our needs. In fact most of them are more than abandoned, and in general they focus on presentation, not on easy input, even less on semantic data (except the SemanticMediaWiki one, perhaps). [[ https://www.mediawiki.org/wiki/Extension:SimpleCalendar | SimpleCalendar ]] looks like the only candidaste if we would ever want to start from this point.

> There have been 12 attempts at this, for a reason!

Sure, and the reason may well be that MediaWiki was not designed to input calendar data, subscribe to events, etc.

After this short investigation, I still think that it is better to start from something other than MediaWiki, and the main candidate keeps being Phabricator. Then work separately in a way to import Phabricator Calendar data and present it in MediaWiki pages.
High priority because I need to decide whether we are investing some FY2015-16 budget on a Phabricator Calendar improvement or not, and that decision needs to be made soon.
>>! In T1035#2214477, @BrillLyle wrote:
> Wanted to mention that someone on one of the Wiki mailing lists recommended looking into the Calagator interface, Portland's Tech Calendar:

Calagator is really interesting. Thanks for sharing.
Wanted to mention that someone on one of the Wiki mailing lists recommended looking into the Calagator interface, Portland's Tech Calendar:

https://github.com/calagator

http://calagator.org/about

As far as I can tell there's no typical calendar grid format, which is non-ideal, and I'm not a code person so I don't know how Wiki-friendly this is. They do seem to be open source FWIW....

http://www.bizjournals.com/portland/blog/techflash/2016/01/after-8-years-of-connecting-portland-tech.html

– Erika aka BrillLyle, Secretary Wikimedia NYC
1. There's also https://www.mediawiki.org/wiki/Extension:Calendar (a linkhub for the ~12 different extensions or methods of integrating calendars with MediaWiki). If further work was done on one of those, to make it usable by us, many other MediaWiki users would also benefit. There have been 12 attempts at this, for a reason!

2. I've made an incomplete linkhub, for easier listing of all relevant and tangential pages, at https://meta.wikimedia.org/wiki/Calendars_events_and_meetings (I grok that this task is just about tech events/meetings, but it's a perennial issue throughout the movement.)
Quim started a discussion on this task on the teampractices mailing list (["Who doesn't love calendars?"](https://lists.wikimedia.org/pipermail/teampractices/2016-April/thread.html#1078)).  This comment is partly my response on that thread

The Phab calendaring tool is really good for a lot of things, and seems to hold promise as the core of an information hub about events.  The things I like about it for recurring [ArchCom RFC meetings](https://www.mediawiki.org/wiki/Architecture_meetings):
*  Automatically weekly event instances (e.g. [Phab query: list of all RFC meetings](https://phabricator.wikimedia.org/calendar/query/XJjy54s3PEFf/))
*  Each instance has a comment section
*  Comments are really well integrated with Phabricator.  We can refer to RFCs by Phab number, and get automatic linking ( #ArchCom-RFC process)

The upsides of using Phab made it really easy to drop useful comments about scheduling E159 //while we were having// meeting E158.  I find these features fit the #ArchCom workflow way better than the current MediaWiki-based template process on meta.

As @BrillLyle says in T1035#2191149, other non-MediaWiki tools are better for different forms of outreach.  Interoperability with a broad range of tools is going to be essential.  Phab upstream is very thoughtful about synchronization with other tools (see [Upstream:T7924](https://secure.phabricator.com/T7924)). Given that our instance of Phab is something Wikimedia has operational control over, it seems like a good repository as a "source of truth" about events that we can build on.

That's my longwinded way of saying that I'm excited about following through on this work, and more deeply integrating Phab events into our general workflows.
>>! In T1035#2189693, @Peachey88 wrote:
> My suggestion of RSS was more of just thinking the quickest way to get it into MediaWiki wikis on the WMF cluster.
> 
> But if we want to put time into a extension that can pull a calendar widget (etc) into a page would be fantastic and would be more versatile. 
> 
> But its more a side thing compared to the main goal of this bug (example: thinking of the tech events list on the main page of mw wiki).

I agree with @Peachey88's comments. I created a semi-complete calendar of the 2016 Art+Feminism events that happened globally and one of the noticeable realities was that it was often easier for folks to add a Facebook event page than an actual on-Wikipedia event page -- especially as a first organizational step. Also, most of the larger events had both Facebook event pages as well as Eventbrite registration. Additionally, WM NYC uses Meetup.com as a registration tool (see: http://www.meetup.com/WikimediaNYC/}

I think there needs to be the ability to subscribe to calendars that reflects these different realities. Not a huge fan of the whole Facebook thing, but it did seem to be the most user-friendly approach that would be easiest for event organizers.

see this link for the events, as well as the links to the Google calendar (which I should probably go back and update for posterity's sake, as well as to include some of the newer events).
https://en.wikipedia.org/wiki/Wikipedia:Meetup/ArtAndFeminism#2016_Art.2BFeminism_Wikipedia_Edit-a-thon

Long winded way of saying, yes, RSS. But also consider iCal, Facebook, etc.

– Erika aka BrillLyle, Secretary Wikimedia NYC
>>! In T1035#2189693, @Peachey88 wrote:
> My suggestion of RSS was more of just thinking the quickest way to get it into MediaWiki wikis on the WMF cluster.
> 
> But if we want to put time into a extension that can pull a calendar widget (etc) into a page would be fantastic and would be more versatile. 
> 
> But its more a side thing compared to the main goal of this bug (example: thinking of the tech events list on the main page of mw wiki).

I agree with @Peachey88's comments. I created a semi-complete calendar of the 2016 Art+Feminism events that happened globally and one of the noticeable realities was that it was often easier for folks to add a Facebook event page than an actual on-Wikipedia event page -- especially as a first organizational step. Also, most of the larger events had both Facebook event pages as well as Eventbrite registration. Additionally, WM NYC uses Meetup as a registration tool.

I think there needs to be the ability to subscribe to calendars that reflects these different realities. Not a huge fan of the whole Facebook thing, but it did seem to be the most user-friendly approach that would be easiest for event organizers.

see this link for the events, as well as the links to the Google calendar (which I should probably go back and update for posterity's sake, as well as to include some of the newer events).
https://en.wikipedia.org/wiki/Wikipedia:Meetup/ArtAndFeminism#2016_Art.2BFeminism_Wikipedia_Edit-a-thon

Long winded way of saying, yes, RSS. But also consider iCal, Facebook, etc.

– Erika aka BrillLyle, Secretary Wikimedia NYC
>>! In T1035#2189693, @Peachey88 wrote:
> My suggestion of RSS was more of just thinking the quickest way to get it into MediaWiki wikis on the WMF cluster.
> 
> But if we want to put time into a extension that can pull a calendar widget (etc) into a page would be fantastic and would be more versatile. 
> 
> But its more a side thing compared to the main goal of this bug (example: thinking of the tech events list on the main page of mw wiki).

I agree with @Peachey88's comments. I created a semi-complete calendar of the 2016 Art+Feminism events that happened globally and one of the noticeable realities was that it was often easier for folks to add a Facebook event page than an actual on-Wikipedia event page, and most of the larger events had both Facebook event pages as well as Eventbrite registration. Additionally, WM NYC uses Meetup as a registration tool.

I think there needs to be the ability to subscribe to calendars that reflects these different realities. Not a huge fan of the whole Facebook thing, but it did seem to be the most user-friendly approach that would be easiest for event organizers.

see this link for the events, as well as the links to the Google calendar (which I should probably go back and update for posterity's sake, as well as to include some of the newer events).
https://en.wikipedia.org/wiki/Wikipedia:Meetup/ArtAndFeminism#2016_Art.2BFeminism_Wikipedia_Edit-a-thon

Long winded way of saying, yes, RSS. But also consider iCal, Facebook, etc.

– Erika aka BrillLyle, Secretary Wikimedia NYC
My suggestion of RSS was more of just thinking the quickest way to get it into MediaWiki wikis on the WMF cluster.

But if we want to put time into a extension that can pull a calendar widget (etc) into a page would be fantastic and would be more versatile. 

But its more a side thing compared to the main goal of this bug (example: thinking of the tech events list on the main page of mw wiki).
My suggestion of RSS was more of just thinking the quickest way to get it into MediaWiki wikis on the WMF cluster.

But if we want to put time into a extension that can pull a calendar widget (etc) into a page would be fantastic and would be more versatile.
The fact is that RSS support is not in Phabricator plans, neither (I believe) RSS is a technology that comes to mind when handling calendar data. Yes, if that bridge would exist maybe we could use it but since it doesn't... should we invest on it?

What is the difference of embedding a calendar in a wiki page and offering that calendar with a link? At the end the most important feature is not viewing a list of events but being able to subscribe, RSVP, and add it to your own calendar application.
>>! In T1035#2026019, @Peachey88 wrote:
> RSS output would probably the most useful starter for us, For integration onto the wikis via E:RSS

RSS support doesn't seem to be on the official upstream roadmap https://secure.phabricator.com/T1928 so would need to be built by us or someone else (https://secure.phabricator.com/w/community_resources/), or to be funded (https://secure.phabricator.com/w/prioritization/).
We have three problems that need to be resolved, which are related but perhaps may be fixed separately, even at different points in time:

* **Introducing calendar data**. Now we are doing this in 1001 places. Ideally it would be just one. The assumption of this task is that the one place would be Phabricator's calendar ([[ https://secure.phabricator.com/T7924 | today a prototype ]]), but other candidates should be considered.
* **Pulling calendar data in other supports, mainly wiki pages**. While we could start linking from wiki pages to Phabricator calendar queries, the desired scenario would be a way for editors to embed calendars based on queries in wiki pages. This probably implies a Calendar API to query data ([[ https://secure.phabricator.com/T7944 | which is missing ]]) and a MediaWiki extension allowing to embed those queried calendars in wiki pages (which we don't have). Maybe this is just too much, and at least the tech-inclined Wikimedians would be fine clicking a Phabricator link.
* **Integrating calendar data with other systems (mainly Google Calendar)**. "[[ https://secure.phabricator.com/T7929 | Future work ]]" upstream, no plans today.

As we can see, deciding on Phabricator Calendar as the one place to introduce data would not provide a quick path to use that data out of Phabricator. However, what would be the alternatives? Other than defaulting to Google Calendar (which I think would be wrong as a matter of Wikimedia principles), I don't see a shortcut but others may have better ideas.
We have three problems that need to be resolved, which are related but perhaps may be fixed separately, even at different points in time:

* **Introducing calendar data**. Now we are doing this in 1001 places. Ideal it would be just one. The assumption of this task is that the one place would be Phabricator's calendar ([[ https://secure.phabricator.com/T7924 | today a prototype ]]), but other candidates should be considered.
* **Pulling calendar data in other supports, mainly wiki pages**. While we could start linking from wiki pages to Phabricator calendar queries, the desired scenario would be a way for editors to embed calendars based on queries in wiki pages. This probably implies a Calendar API to query data ([[ https://secure.phabricator.com/T7944 | which is missing ]]) and a MediaWiki extension allowing to embed those queried calendars in wiki pages (which we don't have). Maybe this is just too much, and at least the tech-inclined Wikimedians would be fine clicking a Phabricator link.
* **Integrating calendar data with other systems (mainly Google Calendar)**. "[[ https://secure.phabricator.com/T7929 | Future work ]]" upstream, no plans today.

As we can see, deciding on Phabricator Calendar as the one place to introduce data would not provide a quick path to use that data out of Phabricator. However, what would be the alternatives? Other than defaulting to Google Calendar (which I think would be wrong as a matter of Wikimedia principles), I don't see a shortcut but others may have better ideas.
>>! In T1035#19336, @Quiddity wrote:
> * https://www.mediawiki.org/wiki/Meetings
> * https://www.mediawiki.org/wiki/Architecture_meetings
> * https://www.mediawiki.org/wiki/Events
> * https://meta.wikimedia.org/wiki/Events
> * https://meta.wikimedia.org/wiki/Meetup

* https://meta.wikimedia.org/wiki/IRC_office_hours and related tag #IRC-Meetings
* https://meta.wikimedia.org/wiki/Community_Engagement/Calendar
* https://www.mediawiki.org/wiki/Category:MediaWiki_developer_meetings
>>! In T1035#19336, @Quiddity wrote:
> * https://www.mediawiki.org/wiki/Meetings
> * https://www.mediawiki.org/wiki/Architecture_meetings
> * https://www.mediawiki.org/wiki/Events
> * https://meta.wikimedia.org/wiki/Events
> * https://meta.wikimedia.org/wiki/Meetup

* https://meta.wikimedia.org/wiki/IRC_office_hours and related tag #IRC-Meetings
* https://meta.wikimedia.org/wiki/Community_Engagement/Calendar
>>! In T1035#2026016, @RobLa-WMF wrote:
> Of course, [Upstream:T7929 (Integrate Calendar with external systems)](https://secure.phabricator.com/T7929) may be a blocker for us seriously moving over to this, but it adds enough value for repeating meetings and Phab integration that it's worth it for me (ymmv)

RSS output would probably the most useful starter for us, For integration onto the wikis via E:RSS
There's a new #IRC-Meetings tag, per T114322.  This tag is for all [Phabricator events](https://phabricator.wikimedia.org/calendar/query/upcoming/) that have an anticipated IRC component (e.g. office hours on #wikimedia-office).  A couple of queries:

* **[All upcoming IRC meetings](https://phabricator.wikimedia.org/calendar/query/wiuSD6vCKuhA/)**
* [All IRC meetings](https://phabricator.wikimedia.org/calendar/query/q0gEvg_5.lM_/)

As of this writing, only #ArchCom-RFC meetings are in there, but hopefully that will expand as education grows.

Of course, [Upstream:T7929 (Integrate Calendar with external systems)](https://secure.phabricator.com/T7929) may be a blocker for us seriously moving over to this, but it adds enough value for repeating meetings and Phab integration that it's worth it for me (ymmv)
to: @Ogil
cc: @Aklapper

Calendars are a big issue for Meetups, especially for active chapters
https://en.wikipedia.org/wiki/Wikipedia:Meetup

re: Active chapters, to understand scope, see: **Event Archive:**  https://en.wikipedia.org/wiki/Wikipedia:Meetup/NYC/Event_archive

For Wikimedia NYC (the local New York City chapter), as Secretary, I created the following Google calendars:

  - **WikimediaNYC** - public, all events as well as some larger events like hackathons and national conferences: https://calendar.google.com/calendar/embed?src=nnvhsl9su019vngvb58qb68u6o%40group.calendar.google.com&ctz=America/New_York

  - **WM NYC Planning** - visible only to the WM NYC Board, used for planning and adding placeholder events to help schedule and de-cluster events

For EVERY event, the following gets updated:
- **WikimediaNYC Google calendar(s)** (see above)
- **Header box** (cream box on top of most pages {{Wikipedia:Meetup/NYC/Main|short=1}} ): https://en.wikipedia.org/wiki/Wikipedia:Meetup/NYC/Header
- **Meetup box** (pink box on right of most meetup pages {{meetup}})
- **Event Archive** on our namespace (see above)

**Issues:**
- Administrative burden on one or more people can be heavy
- Duplication of effort 
- Meetup calendar is not easy to update for forward events beyond 2 months (those that are visible in the pink Meetup box)
- Google calendars can't be embedded on Wikipedia
- Low sharability / visibility -- Google calendars are not super easy to add

re: Wikimedia Phabricator existing calendar
- Too many events: I think if there's too many events it will become unusable.
- Color coding: Also the calendar needs to be color coded so it is more usability
- Administrative burden: It doesn't seem fair to have only one person in charge of maintaining the calendar. Not sure if Community-Liaison is a person?
- Embeddability? Can the Wikimedia Phabricator calendar be updated? That would be ideal....

- Erika
User:BrillLyle
to: @Ogil
cc: @Aklapper

Calendars are a big issue for Meetups, especially for active chapters
https://en.wikipedia.org/wiki/Wikipedia:Meetup

re: Active chapters, to understand scope, see: **Event Archive:**  https://en.wikipedia.org/wiki/Wikipedia:Meetup/NYC/Event_archive

For Wikimedia NYC (the local New York City chapter), as Secretary, I created the following Google calendars:

  - **WikimediaNYC** - public, all events as well as some larger events like hackathons and national conferences: https://calendar.google.com/calendar/embed?src=nnvhsl9su019vngvb58qb68u6o%40group.calendar.google.com&ctz=America/New_York

  - **WM NYC Planning** - visible only to the WM NYC Board, used for planning and adding placeholder events to help schedule and de-cluster events

For EVERY event, the following gets updated:
- **WikimediaNYC Google calendar(s)** (see above)
- **Header box** (cream box on top of most pages {{Wikipedia:Meetup/NYC/Main|short=1}} ): https://en.wikipedia.org/wiki/Wikipedia:Meetup/NYC/Header
- **Meetup box** (pink box on right of most meetup pages {{meetup}})
- **Event Archive** on our namespace (see above)

**Issues:**
- Administrative burden on one or more people can be heavy
- Duplication of effort 
- Meetup calendar is not easy to update for forward events beyond 2 months (those that are visible in the pink Meetup box)
- Google calendars can't be embedded on Wikipedia
- Low sharability / visibility -- Google calendars are not super easy to add

re: Wikimedia Phabricator existing calendar
- Too many events: I think if there's too many events it will become unusable.
- Color coding: Also the calendar needs to be color coded so it is more usability
- Administrative burden: It doesn't seem fair to have only one person in charge of maintaining the calendar. Not sure if Community-Liaison is a person?

- Erika
User:BrillLyle
I wonder whether #Community-Liaisons have any opinion about this proposal, considering that they Help organizing many of these activities (i.e. office hours).
>>! In T1035#1960445, @Aklapper wrote:
>>>! In T1035#1958506, @BrillLyle wrote:
>> Is this still an active project?
> 
> @BrillLyle: Yes, people can [[ https://phabricator.wikimedia.org/calendar/event/create/ | create calendar events ]] in Wikimedia Phabricator. :)

@Aklapper: Thanks for letting me know. Public calendars are a huge issue for Meetups -- not sure if it would be helpful to add such specific to locale events to this calendar but the interface looks great. Thanks!
>>! In T1035#1958506, @BrillLyle wrote:
> Is this still an active project?

@BrillLyle: Yes, people can [[ https://phabricator.wikimedia.org/calendar/event/create/ | create calendar events ]] in Wikimedia Phabricator. :)
Is this still an active project? I stumbled upon this calendar when combing for national Wikimedia events. If this is active and is being used for local chapter meetup events, I would love to add the Wikimedia NYC events to this calendar so we can use this calendar in addition to the Google Calendar we are currently keeping. (Calendar ID: nnvhsl9su019vngvb58qb68u6o@group.calendar.google.com) -- Please let me know -- Erika aka BrillLyle
fwiw #archcom is using Phabricator' calendar to organize their weekly meetings i.e. {E61}
Email preferences have entries for calendar events that you could set to Ignore if you are not interested.

Watching https://www.mediawiki.org/wiki/Project:Calendar and/or other calendar pages is not superior to subscribing only to the projects for the types of events you are interested about (i.e. Tech Talks yes but not Wikimedia Tech San Francisco Meetup) or defining whatever specific queries you are interested about.

There is no iCal support in Phabricator (https://secure.phabricator.com/T7929). iCal for Wikimedia office hours is done via http://h2vx.com/, which doesn't seem to be able to digest our Phabricator URLs. Now idea when will upstream work on this, and how complex it is.

But... an important factor is how simple it is to create events and announce them to those who probably care. Doing this on-wiki is a pain, and ultimately not very effective. I know well because I have done it multiple times. And another evidence is that there is only a few people creating events, and probably only a few people watching the relevant pages. An email to wikitech-l and a couple of mailing lists more keeps being our main way to reach our potential audience.

When creating events is a pain, the rest of the process is broken. This is where Phabricator is clearly superior in the context of the Wikimedia tech community, because most potential users are already here, with the possibility to subscribe to the projects they care about.
Personally I don't see a benefit in this proposal. https://phabricator.wikimedia.org/settings/panel/emailpreferences/ doesn't have any useful notification setting for "calendar" things and I'm certainly not going to watch a project just for the sake of getting notifications of events which might be attached to it.

MediaWiki transclusion, watchlist and enotifwatchlist are vastly superior features and integration with iCal applications is not particularly difficult: as far as I know, it's provided successfully for https://meta.wikimedia.org/wiki/IRC_office_hours (see there).
Thanks for this list of pages, @quiddity. I have announced this proposal at

> * https://www.mediawiki.org/wiki/Meetings
> * https://www.mediawiki.org/wiki/Architecture_meetings
> * https://www.mediawiki.org/wiki/Events
> * https://meta.wikimedia.org/wiki/Events
> * https://www.mediawiki.org/wiki/Bug_management/Triage
> * https://meta.wikimedia.org/wiki/Meetup

Not at this one because it felt too off-topic:
> * https://en.wikipedia.org/wiki/Wikipedia:Meetup
Proposal completely revamped. Feedback welcome.
Furthermore, [[ https://www.mediawiki.org/wiki/Hackathon | mw:Hackathon]] redirects to [[ https://www.mediawiki.org/wiki/Events | mw:Events]] but [[ https://www.mediawiki.org/wiki/Hackathons | mw:Hackathons]] does not and that plural page includes stuff that should be merged as part of T85598.
Wasn't aware of this task and Quiddity's great list above (thanks!) when I wrote the following lines yesterday night in an email:

 Trying to get an overview as an outsider: https://www.mediawiki.org/wiki/Events seems to be about physical events that last longer than two hours and https://www.mediawiki.org/wiki/Meetings seems to be even deader though some recent tech talks are listed there too. Hmm. There's also office hours on https://meta.wikimedia.org/wiki/IRC_office_hours

 So currently there seems to be a division by either medium or format of activity, expressed via different pages. I can't easily get an overview of what's cooking or might be somehow "joinable" for me.

If I had too much time I might try to merge all into one table on one page, and have 
* 'medium' (IRC Office Hour? Physical Happening? Video hangout?) and 
* 'content/format' (TechTalk presentation? WMFMetrics presentation? ECT TeamMeeting? Techy Hackathon? Non-techy Edithon? Booth/stand at some conference? Q&A on Phabricator? Other?) columns/pre-defined classifications that allow filtering (does MediaWiki support that?).
Note that there is an additional risk (positive or not, I still don't know) of having yet another calendar: {T466}
Agreed. I'm often confused as to why "X" isn't mentioned, and then I realize it's at the //other// page...  ([[https://meta.wikimedia.org/wiki/Mergism|Mergism]] is often good, when a few short pages are involved. :)

Here are some more "scheduled/re-occurring" meetings, some or all of which should be considered for merging. (Or for upgrading, once there's a better system that we can recommend.)
* https://www.mediawiki.org/wiki/Meetings
* https://www.mediawiki.org/wiki/Architecture_meetings
* https://www.mediawiki.org/wiki/Events
* https://meta.wikimedia.org/wiki/Events
* https://www.mediawiki.org/wiki/Bug_management/Triage
* https://meta.wikimedia.org/wiki/Meetup
* https://en.wikipedia.org/wiki/Wikipedia:Meetup
actions such as adding projects or tags, adding cc's or assigning owner, changing security should be more easily added, removed or modified.
This is now implemented for status, priority, assignee, points, project tags subscribers and even workboard column.

The only fields that can't be edited in-line with the comment form are title, description and advanced things like visibility policy.
Tangentially, if you click "2 others" on this task, you get an in-browser pop-up window and even that window has no write capability. :-(

>>! In T870#933937, @Jaredzimmerman-WMF wrote:
> On your flickr photo pages, and on your facebook "about" section almost all fields are editable this way, If I remember correctly this is how Jira tasks were as well. I feel like some aspects of bugzilla were like this as well, but not that its locked I can't point to specific ones. 

Yep, JIRA has this functionality (using a standard pencil icon on hover) and Bugzilla had similar functionality.

Broadly the "Add Comment" box is probably mislabeled. But this task appropriately focuses on making the fields at the top of every task easier to modify. I think this is medium-ish priority, but definitely worth pursuing.
On your flickr photo pages, and on your facebook "about" section almost all fields are editable this way, If I remember correctly this is how Jira tasks were as well. I feel like some aspects of bugzilla were like this as well, but not that its locked I can't point to specific ones.
As I understand this request, users could click on the title of any field in a task page, and then such field would become editable, seamlessly.

Not like VisualEditor "all page is yours now", field by field. I have seen this behavior before somewhere, I just don't remember where. Giving real examples might help this task moving forward upstream.
@chasemp still 3, just a different 3
you can do all 3 in the action drop down with 2-ish?
@Aklapper I'm more referring to status, assigned, cc, currently these are all 3 actions, when they could just as easily be 1 or two
Might have been a fundamental design decision of upstream (though I cannot find any past discussions) to "hide" some not too common actions under a separate "edit" page. 
It also makes the task view less cluttered ("Visible To", "Editable By", "Security" checkbox not exposed, in my case at least).
Nice feature, but I have no idea about the complexity.
Allow shortcut keys for text formatting and action in description fields like CMD+B, CMD+K, CMD+I, etc.
@aklapper: [[ https://en.wikipedia.org/wiki/Repetitive_strain_injury | Repetitive strain injury ]]
What is "RSI"?
Task specific shortcuts:

* Edit task
* Subscribe / unsubscribe
* Assign to self
* Remove assignment
* Close task

Navigation shortcuts:

* Go to notifications
* Go to RSI help page
Task specific shortcuts:

* Edit task
* Subscribe / unsubscribe
* Assign to self
* Remove assignment
* Close task

Navigation shortcuts:

* Go to notifications
>>! In T816#3296416, @Aklapper wrote:
> See wontfix'ed https://secure.phabricator.com/T1931#144486 asking for use cases.

You're probably the most active phab user here, so maybe you could add a list of use-cases? (If you're generally a user of keyboard shortcuts, of course!) - I do my triage via email, so cannot really help.
See wontfix'ed https://secure.phabricator.com/T1931#144486 asking for use cases.
I'd love some navigational shortcuts. Go to notifications is an obvious one (ctrl + n).
"Shortcut keys for description fields" is too vague. I think we will have a better chance if specific shortcuts are requested, like in https://secure.phabricator.com/T704
2 Closed Phab bugs:
* Suggestion of going towards Github's standard of shortcuts, for Differential at least. (j/k for prev/next), done in https://secure.phabricator.com/T184
* Feature request for ctrl-Enter to submit a comment, https://secure.phabricator.com/T704
But nothing about bold/italic/link/code/etc.

----
Here are Mediawiki's shortcut standards: 
* Mediawiki (navigational): https://en.wikipedia.org/wiki/Wikipedia:Keyboard_shortcuts#Modifier_keys
* VE (text formatting): https://www.mediawiki.org/wiki/VisualEditor/Portal/Keyboard_shortcuts

Here are Github's and Gerrit's:
* https://help.github.com/articles/using-keyboard-shortcuts/
* https://git.eclipse.org/r/Documentation/images/intro-quick-hot-key-help.jpg
2 Closed Phab bugs:
* Suggestion of going towards Github's standard of shortcuts, for Differential at least. (j/k for prev/next), done in https://secure.phabricator.com/T184
* Feature request for ctrl-Enter to submit a comment, https://secure.phabricator.com/T704
But nothing about bold/italic/link/code/etc.

----
Here are Mediawiki's shortcut standards: 
* Mediawiki (navigational): https://en.wikipedia.org/wiki/Wikipedia:Keyboard_shortcuts
* VE (text formatting): https://www.mediawiki.org/wiki/VisualEditor/Portal/Keyboard_shortcuts

Here are Github's and Gerrit's:
* https://help.github.com/articles/using-keyboard-shortcuts/
* https://git.eclipse.org/r/Documentation/images/intro-quick-hot-key-help.jpg
2 Closed Phab bugs:
* Suggestion of going towards Github's standard of shortcuts, for Differential at least. (j/k for prev/next), done in https://secure.phabricator.com/T184
* Feature request for ctrl-Enter to submit a comment, https://secure.phabricator.com/T704
But nothing about bold/italic/link/code/etc.

----
Here are Mediawiki's shortcut standards: 
* Mediawiki (navigational): https://en.wikipedia.org/wiki/Wikipedia:Keyboard_shortcuts
* VE (text formatting): https://www.mediawiki.org/wiki/VisualEditor/Portal/Keyboard_shortcuts

Here's Github's and Gerrit's:
* https://help.github.com/articles/using-keyboard-shortcuts/
* https://git.eclipse.org/r/Documentation/images/intro-quick-hot-key-help.jpg
Phabricator saves the text you are typing with some persistence (which is very useful if your connection drops, your browser crashes, etc). My bet is that you had typed "test" at some point while creating a task, and then you created this task here without any description (tsk tsk)  :) , and you didn't notice that your "test" was still there.
I didn't type test… I see it there, but I didn't add it. Is there default description that is being added?
Sorry, for some reason reading "test" as sole description made me think this was a test.  :)
Wasn't an experiment, where do we log bugs against phabricator? bugzilla?
Hi, this is a production instance. Please file only legitimate tasks.

We have https://phab-01.wmflabs.org/ for experimenting and learning.
The [[https://secure.phabricator.com/book/phabricator/article/remarkup/|ReMarkup]] system is not wikitext and not Markdown. Sad.
//importing issue status//
**aklapper** wrote on `2014-09-04 11:06:07 (UTC)`

I do not see a reason to switch off markup (and I don't think it's possible). I don't see much "confusion" because **there is a preview of your comment**. Plus functionality like @aklapper is nothing I want to switch off.
**Svetlana** wrote on `2014-09-03 23:46:32 (UTC)`

Can we force it to go plaintext? That could be nice, to avoid confusion of people who see an 'italic' button which adds //.
**aklapper** wrote on `2014-09-03 14:23:49 (UTC)`

>>! In T100#48, @Nemo_bis wrote:
> Then just disable the phabricator-specific markup, no? Is there any reason we need a markup?

Same reasons phab-specific markup exists as any other markup: It's convenient.
**Nemo_bis** wrote on `2014-09-03 14:15:50 (UTC)`

> In fact, it takes less work to copy a Wikimedia URL from your browser and paste it here than typing the mw:etc custom strings manually.

Then just disable the phabricator-specific markup, no? Is there any reason we need a markup?
**qgil** wrote on `2014-09-01 07:26:21 (UTC)`

In fact, it takes less work to copy a Wikimedia URL from your browser and paste it here than typing the mw:etc custom strings manually.

After months of daily Phabricator use and after reading this discussion again, I think we can Decline this request.
**scfc** wrote on `2014-08-31 19:26:56 (UTC)`

FWIW, as @aklapper said, the preview function (dearly missed in Bugzilla) makes this a not-so-big problem.

Personally, I strongly favour full-fledged URLs over [[wikilinks]] because:

  # They prevent users from messing with "evidence" relevant to a bug; if they just have to copy & paste something, the chances are much higher that what they report is what they actually experienced.
  # They work //everywhere//, i. e. if you read a bug report in your mailbox, you don't have to set up a local filter and keep that in sync with the tracker, but you can just click on a link.
**aklapper** wrote on `2014-08-26 09:59:47 (UTC)`

For comparison, Bugzilla's [[https://bugzilla.wikimedia.org/buglist.cgi?bug_id=29506,41851,51720 | half-working]] ability to turn [[:mw:Extension:Flow]] into a link is a [[ https://git.wikimedia.org/blob/wikimedia%2Fbugzilla%2Fmodifications.git/HEAD/extensions%2FWikimedia%2FExtension.pm#L31 | custom patch on our side]]. Whether something similar is doable and feasible in Phabricator remains to be investigated by anybody willing to dive into the codebase (and upstream is very responsive in helping).

If you are strongly interested in performance differences I recommend to contact upstream development for more information.
**Svetlana** wrote on `2014-08-26 09:14:29 (UTC)`

There is the routine work of having to click through or type through many times to link to common things like [[:mw:Extension:Flow]]. There is another task of having to "learn a new markup". The latter appears to be discussed extensively in this task and a visual editor could indeed help (or we could kick and scream a little and have Parsoid service break into this site).

The former (routinely linking to mw and other sites) needs more attention. Implementing this would indeed be a repetition of the parser that Wiki uses which could probably be inefficient - some more insight is needed here; I wouldn't like to //assume// anything. If it is slower then //how// slower is it? Such feature would probably not be needed for other companies using Phabricator: they typically don't have a wiki farm, and may as-well do everything right in Phabricator itself. Phabricator is free software. Surely it's within its philosophy to be extensible and script-able to suit such specific needs?

I'd suggest to split this task and move over some interwiki-related comments over to a new task.
**aklapper** wrote on `2014-06-16 11:07:45 (UTC)`

>>! In T100#40, @Nemo_bis wrote:
> Ok, but at least not double brackets for external links, as Guillaume says in T100#14... And yes, I think such a decision must be before day 1.

The comment preview would tell that markup parsing expectations from MediaWiki do not work out in Phabricator. 
I expect a frustration level similar to Bugzilla and our custom regexes over there. Neither better nor worse. Which makes this not block day 1 for me currently.
 --~~~~ (Y signature no work on tis Phabicreator wiki?!?!)
**Nemo_bis** wrote on `2014-06-15 10:15:27 (UTC)`

>>! In T100#39, @aklapper wrote:
> I was missing a rationale for "we'd really like to switch it to something else if possible" in the task summary but I guess it translates to "I'm used to wikitext markup and don't see good enough reasons to learn something else".

Given it was set by James, it probably rather means "what's wrong with HTML after all". :P

Performance, really? Ok, but at least not double brackets for external links, as Guillaume says in T100#14... And yes, I think such a decision must be before day 1.
**aklapper** wrote on `2014-05-23 03:40:42 (UTC)`

I was missing a rationale for "we'd really like to switch it to something else if possible" in the task summary but I guess it translates to "I'm used to wikitext markup and don't see good enough reasons to learn something else".

In any case I don't think that this should //block// Day 1 of Phabricator in production so I've changed the project of this task and added Maintenance (after day 1) instead.

Reasons:
You can actually see in the preview how your text will look like (compared to Bugzilla commenting) so you can realize beforehand that wikitext parsing might not work as expected. In the worst case people will realize that they need to paste full URLs - slightly more inconvenient, but not a dealbreaker IMHO. Furthermore, see RobLa's comment 33 above.

> We definitely don't need to patch the parser to set links between bugs, with Gerrit, RT, or with Wikimedia wiki pages. The existing Bugzilla links can be converted during the migration.

Good point; Added a comment to T39.
**qgil** wrote on `2014-05-15 18:13:55 (UTC)`

We shouldn't maintain a local patch just because. If there is a very good reason to add some functionality, then it could be proposed upstream. 

We definitely don't need to patch the parser to set links between bugs, with Gerrit, RT, or with Wikimedia wiki pages. The existing Bugzilla links can be converted during the migration.
**robla** wrote on `2014-05-14 19:10:18 (UTC)`

The Phabricator folks explain their rationale for yet another markup language in https://secure.phabricator.com/T2849

In a nutshell, they've packed a bunch of functionality into a syntax that is very efficient to parse.  One of the things that makes Phabricator a pleasure to use is the performance, so I would be hesitant to implement a (likely) less efficient, feature poor parser in the name of making something that we hope is vaguely headspace compatible with Mediawiki markup.  If we're concerned about usability, I would rather we push the Phabricator folks to implement visual editing like we ourselves are doing.
**jdforrester** wrote on `2014-05-10 20:35:20 (UTC)`

◀ Merged tasks: T165.
**Krenair** wrote on `2014-04-20 16:06:21 (UTC)`

@Rillke If we implemented it again the default wiki obviously wouldn't be enwiki (probably mediawiki.org or maybe wikitech), so it wouldn't change much for them.
**qgil** wrote on `2014-04-20 15:24:50 (UTC)`

In general, I would be reluctant to any local patches, except when they provide functionality that we would not get with the stock software.

In any case, I don't think lack of wikitext parsing would stop us from migrating. Setting priority as Wishlist for now. My opinion is Wontfix.

No guideline would be needed. Plain MediaWiki and VisualEditor also have a chain icon to define external links. When users click this icon, the rest is also obvious.
**Rillke** wrote on `2014-04-20 11:57:05 (UTC)`

> Can we please not implement wikitext again?

@Krenair Yeah but then we should have some guide how to achieve the same, although phabricator has some nice toolbars and instant preview. I will not miss this feature very much because I mostly linked to `:commons:` and `:de:` (thus not a lot shorter or faster) but the `:en:`-guys may complain.
**Krenair** wrote on `2014-04-20 11:40:29 (UTC)`

Can we please not implement wikitext again?
**gpaumier** wrote on `2014-04-18 10:47:45 (UTC)`

@aklapper The problem is that Remarkup uses the same syntax for external links as well, e.g.:
  [[https://fr.wikipedia.org | Wikipédia]]

There is an alternate Markdown-like syntax for external links:
  [Wikipédia](https://fr.wikipedia.org)
but the one with double brackets is the one inserted by default by the toolbar. 

I don't know how customizable / fixable this is, but I just wanted to raise the issue for completeness :)
**aklapper** wrote on `2014-04-18 10:31:46 (UTC)`

...and that page says:

[[wiki page]]             # Link to Phriction
[[wiki page | name]]      # Named link to Phriction

so with a small (?) code change we could hopefully link to mediawiki.org or whatever instead. Maybe.
**aklapper** wrote on `2014-04-18 10:15:09 (UTC)`

For the records, https://secure.phabricator.com/book/phabricator/article/remarkup/ covers the auto-linking stuff.
**aklapper** wrote on `2014-04-17 12:45:09 (UTC)`

Also see T88
**aklapper** wrote on `2014-04-17 12:40:57 (UTC)`

Haven't checked Phab's code, but as it autolinks numbers followed by a certain letter I'd assume somebody could patch the code and reuse the regexes we have in https://git.wikimedia.org/blob/wikimedia%2Fbugzilla%2Fmodifications.git/HEAD/extensions%2FWikimedia%2FExtension.pm
**Rillke** wrote on `2014-04-15 15:39:46 (UTC)`

[[ :de:Test | Testcase ]]